[gms7777]

So I don't know much about either these keyless ignition systems or security and encryption, but is it really that simple? According to my not-super-legitimate internet source (http://auto.howstuffworks.com/remote-entry2.htm), typical remote entry keys work with at least 40 bit codes, and different car manufactures use different systems/#s of bits. In additon, since the codes are encrypted with different random #s every time, you can't just enumerate every possible combination.

The concept of brute forcing, and doing it successfully for many different cars in a short period of time, just doesn't pass the smell test for me.

[emidln]

It's been a long time since I worked building ECUs responsible for RKE (Remote Keyless Entry) and SKIM (Security Key IMmobilizer), but IIRC, only one of the three used ciphers and systems that I recognized (it was an RC4-derivative).

They all had features to disallow brute-forcing though. The RKE system would track the number of requests for each authenticated FOB. If the FOB had too many requests or had been pressed too many times (either the stored count or the sent count being off), various features would be frozen until the FOB was repaired (by synchronizing via insertion into the key cylinder and/or successfully starting the engine).

Nobody talked about how good the encryption was or wasn't. I wasn't doing cryptography and we were just given things to implement. The protocol also wasn't really up for discussion, as we were just implementing a spec given to us.

It doesn't surprise me to learn that you can break this. We noticed a bunch of vulnerabilities during validation that required some knowledge to expoit (implementation details that you'd have to gain via fuzzing).

Another scary part is how lax ECUs talking on the CAN bus were w/parsing network messages. I'd like the opportunity to spend some time attacking various controllers on common systems (does GM still use their Common Architecture? if so that'd be a gold mine), but I'm now in a different field without funding or resources.

[gnaffle]

Not sure if it was the case here, but apparently some cars can unlock automatically if the key is nearby.

To hack this, you only need a sensitive receiver that can retransmit the signal from the key, and you need two people, on in proximity to the key, and another nearby the car when it unlocks.

[emidln]

That's not really the case. Some of them unlock via low frequency RF, but to my knowledge they still use encryption that uses their button click count as one of the variables plus a shared secret.

[gnaffle]

Yes, but the point of this scheme is that the car "believes" the key is in close range. If that is enough to get it to open the car, the thieves don't have to break any encryption, they just need to relay the RF signal. The faulty assumption on the part of the car manufacturers is that "RF signal present" equals "keyfob nearby".

[emidln]

No system I've been exposed to was defeated by a simple replay attack. You needed the shared secret and the click count (plus proprietary algorithm), which would be incorporated into the OTA message. Most LF systems are pretty low-bandwidth as well, and lock out quite quickly.

[gnaffle]

To clarify, I'm not talking about a replay attack. It's a _relay_ attack where they use the RF signal transmitted by the actualy car/key, just over a bigger distance than you would normally expect.