Fundamentally, a cryptographic system that allows a key fob to authenticate itself with one-way communication to a car and does not require a real-time clock in the key fob is hard and maybe impossible to get right. One can certainly do better than what Honda did, but anything that checks all the boxes one would like needs some way to prevent replay even over many keypresses with no successful unlocks, and that needs either something visible to the car to change when the owner presses the button 100 times far away from the car (e.g. the time) or needs a form of communication in which the key isn’t simply broadcasting bearer tokens to the world.
These are another case where the sound engineering principle of KISS is forgotten. First introduce a more complex solution, find that it's broken, then keep adding more and more layers of complexity in the hardware, software and protocol to try to patch the problems that the initial complex solution introduced.
Meanwhile, my Honda has a physical key without a transmitter and the car has no receiver. There's nothing to intercept and I can go swimming with the key with no ill effect. No batteries to replace and if I need a new key it's $5, not $400. It's a brilliantly simple solution!
So someone can pick a lock on your door and hotwire your car and steal it. But with this attack they can only get access to the car. Hotwiring if there is an immobilizer is not possible.
Sure they can, but as pointed out elsewhere in the thread you have to physically go to the car and jimmy the locks to break in, which can (depending on circumstances) attract attention.
Attacks which can be performed by sitting a safe distance away while pretending to do something else can be more widespread as there's so little risk to the attacker.
Yup, but the real problem here is the chosen re-synchronization strategy of the Rolling code when de-sync occurs (performed by the BCM/vehicle) that is done in backward. This is described in the article, but most of the comments here seem not to read the details.
Also Honda does offer bidirectional fobs, that make this attacks a lot harder (still not impossible if the same resync strategy is used)
I would argue that both problems are real. Yes, Honda’s resynchronization system is very weak, and a good system would require the owner to actually repeatedly press the button to resync and/or should only ever resync forward. But one-way protocols are also inherently vulnerable to long-range replay attacks if the owner can be convinced to push the bottom near the attacker even if they’re far from the car, and this is not really excusable for a device costing at least $10 (retail) talking to a car that costs thousands of dollars. A microcontroller with a bidirectional radio is cheap. Heck, an NFC device communicating using backscatter modulation that works with no battery is cheap enough for this application. You can find them in disposable subway tickets!
What is a bidirectional fob doing resyncing at all? There is absolutely no need for any sort of state in a bidirectional if any reasonable protocol is used. The fob should not even need writable nonvolatile memory.
1) long range replay attack are what is a real issue, and is solved by bi-dir fobs. Only thing keeping them out of the market as a default is price. Issue described in the article is far less of a concern than what you mentioned, I put it in the category of Intel's Spectra - where if you already have such physical access to the device/CPU, there are easier ways...
2) Price - just the MCU is more than 10+ USD. Those MCUs are basically ASICs with a lot of stuff integrated (plus - automotive rating). Precise and stable OCX doesn't come cheap either...
3)There is no single chip solution in the automotive market that would integrate all functions (LF Rx, RF Tx+RX, transponder Rx+Tx). Additionally, RF bi-dir + passive LF is power hungry, and getting a year out of your standard CR2032 forget about it - so a more expensive power source needs to be used...
4)NFC is basically just only one of the aforementioned functions - similar to transponder Rx+Tx.
5) Oh it needs writable nonvolatile memory for a lot of reasons... - configuration to cover different vehicle/market/protocol variants, DTC, Secret Keys for pairing, unless you want your fob replacement price to skyrocket...
Regarding fob price - keep in mind it's not just the electronics, although automotive MCUs have harder requirements to satisfy (op. range of temperature, voltage, very low quiescent current, very low ppm failures). Mechanics are expensive, although deceiving when you look at them. Keep in mind they go through some pretty nasty tests - including (and I kid you not) a washing machine test - basically testing if it will survive a washing machine.
Why is it not a schoolbook example of public key crypto?
"I am fob", "Checks out, I am car", "Checks out, please open", "Ok".
Add some details such as nonces but not nothing out of the ordinary compared to things like mTLS or mobile phones that we use every day. What am I not seeing?
Your example involves two-way communication. These cheap key fobs are one-way. It’s more like:
(Press button) “hey, I’m the fob!”
(Press button) “hey, I’m the fob!”
There’s no communication back from the car because these systems are physically incapable of it.
Also, without some elaboration, your example is vulnerable to a replay attack too, but it’s not conceptually hard to fix. A simple arrangement that probably works (but would want a proof!) is:
“Hey, I’m fob #123”
“Hey fob #123, I’m the car. The challenge is abc. Answer after 5ms.”
“Hey car, HMAC(‘abc’, our secret) = ‘xyz’)”
And the car answers and also checks that the answer was received no more than 5.0000001 ms later. There are more clever variants of this sort of thing in the literature, and I don’t think cars use them because the manufacturers don’t seem to care. (The main problem with the scheme above that I’m immediately aware of is that it requires very good timing. If the microcontroller in the fob takes nearly 5ms to calculate the MAC and the goal is 100ns of allowable latency (100 ms is about 100 light-feet), then the timing precision needed is 20 ppm. Getting precision that good on a cheap key fob may be challenging. For that matter, getting that level of precision in the car, which may be rather hot, may cost more than the manufacturer wants to pay. More clever schemes don’t need this kind of precision. Also, my silly scheme has the fob broadcasting its identity every time a button is pressed, which isn’t great.)
Of course, hence "nonces and stuff", but that's nothing out of the ordinary compared to what we use every day.
I am surprised these things contains no receiver. Receiving is the easy part in a transducer, and there commercial off-the-shelf solutions to this for about a dollar. But that would explain it.
RSA SecureID has been doing this for decades and decades. They use a not-tremendously-accurate battery backed quartz RTC with some drift compensation built into the server side.
There are a ton of other options though. Atomic clock signals are broadcast nationwide in the US. GPS, Glonass, etc. signals broadcast the time. Cellular networks broadcast the time.
