Most garages with remote openers can be opened by hand anyway, and car doors can be opened with a prybar in about 4 seconds without causing damage (as I learned one snowy evening when I locked my keys in my running car and had to call AAA).
Sure, but this leaves no physical evidence and will bypass all car alarms.
Essentially a MITM. Clever!
Interesting workflow. Device, Eve, runs on two most common garage/car opener frequencies, 315 and 390 MHz. When Eve starts receiving Alice’s remote’s signal, the code C1, Eve transmits slightly off frequency, close enough to jam the car/garage receiver aka Bob. Alice, unable to get Bob to unlock, naturally sends another code, C2. Eve jams Bob, receives C2 from Alice, sends C1 to Bob. Voila, Alice unlocks (or locks) Bob as intended, and Eve now possesses a fresh code from the rolling sequence that can be used for unlocking Bob.
Because rolling code works in a single-direction way. There’s a sequence that both Alice and Bob (the communication partners) know. No code is repeated in any reasonably short period, so there’s no way to intercept and use later in a replay attack. But then there’s the cleverly exploited vulnerability like this.
If it was on me, I’d go for some cheapo chip like e.g. nRF24L01 (or the microcontroller-containing nRF24LE1, that has an onboard CPU that can run the math), and use bidirectional communication:
Both Alice and Bob have a shared secret SS.
Alice powers up, sends a communication request CR.
Bob receives request, generates a random number of sufficient size, sends it as a challenge CH.
Alice receives CH, calculates response RE=hash(CH+SS), sends it out.
Bob receives RE, calculates own expected response REexp=hash(CH+SS), if RE=REexp opens the lock.
Bob can also enforce timing and require immediate response from Alice, with some possibly pregenerated random number RN (generated at the moment of powering up, for example), and then the RE would calculate as hash(CH+RN+SS). The roundtrip time between sending CH and receiving RN then could be used to make proxy attacks more difficult. Packet retransmissions would have to be taken into account, though, and possibly disabled for this part of conversation. Retry rate can be limited, and perhaps scaled exponentially to tarpit a wannabe bruteforce attacker.
A good care has to be paid to design of the random number generator. A hardware trick with e.g. a diode noise, hash-whitened, would be a good idea here.
The chips needed are cheapo. The crypto needed is not that heavy, a hash function will take at most a couple dozen milliseconds (at ATmega chips at 16 MHz, one block of SHA256 takes some 4 milliseconds, according to here; the CPU in the nRF24LE1 should be roughly similar, though I am not certain if it has enough RAM for the SHA256 function, some other may have to be used; but processing time is apparently not a constraint here). If it wouldn’t cope, an external crypto coprocessor can be added with ease, and it can be realized on a microcontroller with more RAM (then a bare nRF24L01, just the SPI-operated packet radio, can be used) and no crypto-crap-export bureaucrap attached.
Cheap DIY gadget?
Seems faster and easier.
Heck, you might even be able to capture “remote start” signals.
Why not just have the car/garage send a nonce + timestamp as a time sensitive challenge and have the key reply with a MAC for the message? MACs don’t seem much harder than hashes and are well researched for sender authentication (in addition to message integrity, of course). Could even verify the car/garage by sending the challenge with a MAC based on its own key.
My first thought was PKI, but after reading your post I realised that 2048 bit RSA keys would probably be too difficult for a low power secure processor, and remembered that some MACs are also hash based and are already well accepted as means of authenticating a sender without transmitting sensitive data.
The scheme I proposed is pretty much a MAC.
The timing-sensitive part is too timing-sensitive and the microcontroller too slow. The RN to send has to be sent IMMEDIATELY after the challenge is received, every microsecond we can shave down from the maximum limit is a microsecond an attacker would sorely miss in any proxy-based scheme. Then there’s plenty of time to calculate the CH+RN+SS hash.
If we rely on the time to calculate CH+SS instead, the attacker can compensate for the roundtrip time for his shenanigans by using faster hardware for the hash. 4 milliseconds can be a plenty of time.
Nevermind, you’re absolutely right. Just to explain my thinking though: The MAC wouldn’t be keyed by the timestamp, that’s just a time bound part of the message to act as the challenge (with the MAC itself proving origin) to prevent replay attacks down the road with, say, minute resolution (in retrospect unnecessary assuming challenges aren’t repeated). I was thinking MACs would be better because they’re intended to solve issues with hashes potentially leaking info about inputs in some cases, but after reading your reply and thinking a bit more your scheme would do that. It wouldn’t be keyed asymmetrically, but that isn’t an issue here anyway.
Edit: on further reading MACs aren’t asymmetric anyway; not sure why I thought they were. That’s why I’m not a cryptographer.
The method of attack yields a potential defense.
Since the first press gets recorded, and the second does as well when the first blocked one gets transmitted, they have the newest code.
If you play with your keys at the office everyday…it’d have to be well out of range of this thing’s radio…but just pressing all the butto…
OFFS, I just realized why it doesn’t defend. Crap. Gonna put it up anyway so you can see the stupid.
Samy is my hero.
The reason these attacks work is that most solutions require the device to be able to talk to the key, instead of the key being just a simple transmitter, and the device being just a receiver. Even timestamps is problematic because you need a way to keep the key synced to the device clock, even if it hasn’t been used or had power in the battery for years (eg emergency spare key sitting in a drawer)
A simple transmitter is cheaper than a two-way communications protocol… aaaand there’s the problem. Pinching pennys. Because we like low price, but don’t necessarily know that corners were cut to give us that price.
For many cars these days, the key can talk to the car both directions, so this device doesn’t work - key requests access, car issues a crytographic challenge, key answers it, door unlocks.
Fifteen years ago I can understand that being a noticeably more costly system than a simple transmitting keyfob, but today? Wireless comms hardware is so cheap it should be standard on even the bare-bones car models… (matched with properly secured firmware, not some shoddy no-security out-of-the-box implementation.)
The solution I proposed earlier? Let’s go with the more capable and more costly way.
- For wireless, nRF24L01+, bare chip or ready-to-use module.
- For processing, ATmega32u4; a bit of an overkill but allows us having USB for user-friendly configuration and firmware uploads. A bare chip needs also a 8MHz crystal, we can also use a module.
- Assorted dirt where needed - battery with holder, resistors, capacitors, connectors. Buttons, LEDs, optocouplers and relays for the output sides.
If we’re generous, $10 per device. Maybe $7 if we’re bargain-hunting. Way less if we go with mass-produced boards that we populate ourselves.
Now, is the few bucks saved on a bog-standard rolling code transmitter worth the risk of losing a multithousand car or compromising a house and possessions stored there?
Yup - fifteen years ago the equation was different, so I assume the shoddy state of the status quo is mostly a holdover from what made sense in the olden days of yesteryear. The auto industry seems slow across the board to migrate to better technology, presumably because of commitment to managing supply chains, serious reliability and failsafe testing/requirements etc. Legacy has a lot of inertia.
I suspect that Tesla was able to go from nothing to industry leader, in part simply because it started without being boxed in by legacy, so every part of the production was modern.
This topic was automatically closed after 5 days. New replies are no longer allowed.
