11–20 of 53 posts
-Key asks car to unlock and sends public key for recognition,
-Car sends challenge encrypted with key Public key
-Key sends back private-key-encrypted challenge
Bing, authenticated.
Earlier quoted context omitted.
Many key fobs now (to my limited knowledge ) use an expanding one time use "code "essentially so once that transmission has been made, the same transmission won't unlock the car a second time. (On new vehicles at least )
This isn't a replay attack in the traditional sense. The attack works by simultaneously receiving the fob signal while jamming it to the car so it doesnt see it. Then, the car can't roll ahead its table. To say another way, it exploits the fact that you can be a hundred miles from your car and push the unlock button on your fob but then return next to your car, push the fob, and the car unlocks.
One has to wonder about a technical blog that starts off with "Using the orginal RTL and pair that with HDSDR software on linux". So I did a search, and HDSDR only runs on Windows.
Earlier quoted context omitted.
This isn't a replay attack in the traditional sense. The attack works by simultaneously receiving the fob signal while jamming it to the car so it doesnt see it. Then, the car can't roll ahead its table. To say another way, it exploits the fact that you can be a hundred miles from your car and push the unlock button on your fob but then return next to your car, push the fob, and the car unlocks.
Why aren't the previous codes invalidated though? If the attacker catches code X, and the owner presses the button again to send code X+1, why is code X still valid?
So, what is the solution? Implementing a PKI over between the key and the car? This would be quite nice, wouldn't it? -Key asks car to unlock and sends public key for recognition, -Car sends challenge encrypted with key Public key -Key sends back private-key-encrypted challenge Bing, authenticated.
So, what is the solution? Implementing a PKI over between the key and the car? This would be quite nice, wouldn't it? -Key asks car to unlock and sends public key for recognition, -Car sends challenge encrypted with key Public key -Key sends back private-key-encrypted challenge Bing, authenticated.
The car most probably lacks the hardware to send at 315 MHz. Not that the key had the ability to receive either, but that means that you'd not only have to replace the key fobs but do a full recall campaign with new hardware in the car.
The article states the need to jam the transmission (illegal in many countries) but does not explain why.
The car locks usually operate on a rolling code system, where each code is only used once. By jamming the signal, you record it but don't let the car receive it, so you have one code. Then, when the remote gets pressed again, you record the second code and send the first. So, you're always one code ahead, and you can use that single code to open the car once. AFAIK, if you let the car read a code straight from the re…
And I'm reasonably sure that the algorithm is now published. It wouldn't be hard to get 3 or 4 button presses, and then exhaustive search the space for the right serial and then attack it.
Earlier quoted context omitted.
Many key fobs now (to my limited knowledge ) use an expanding one time use "code "essentially so once that transmission has been made, the same transmission won't unlock the car a second time. (On new vehicles at least )
I just wonder if there are any car lock systems that don't use any rolling codes, but does a proper challenge-response auth with time-limited nonces.
So, what is the solution? Implementing a PKI over between the key and the car? This would be quite nice, wouldn't it? -Key asks car to unlock and sends public key for recognition, -Car sends challenge encrypted with key Public key -Key sends back private-key-encrypted challenge Bing, authenticated.