4 ms·
The fix for this doesn't need any cryptography. Nothing more than the key receiver and the main ECU agreeing on a randomized number in the "unlock" code. Allo
by MarkusWandel 4y ago
The fix for this doesn't need any cryptography. Nothing more than the key receiver and the main ECU agreeing on a randomized number in the "unlock" code. Allow unrandomized unlock once, agree on and store random number on both sides, from here on insist on this number. Sure this is insecure in the sense that a device listening to the bus can capture the fixed unlock code for that car, but who cares, it completely disables this attack (generic device can unlock ANY car of that model/series with no prior knowledge).
Of course some sort of override is needed to reset the pairing in case one or the other side is replaced in a repair. But this can be made cumbersome enough for a thief not to bother.
I'm sure this is well in scope for a field firmware upgrade, so hopefully this attack vector doesn't last long.
- flatiron 4y agoI believe you reinvented the one time pad.
- wallaBBB 4y agoIt's a CAN injection, has nothing to do with the immobilizer feature (between the fob and the car) that has a random SK exchanged on fob-car pairing and is mandated (by insurance companies to prevent hot wiring a car) for more than a decade.
- PinguTS 4y agoYou didn’t spent the time to understand what is being attacked, didn’t you? Ken has everything greatly documented. Ken is a long time fellow in the area. Btw, he has also solutions.