Cryptography is actually difficult for the requirements of a key fob.

The principle issue is that requiring two way communication greatly increases hardware cost and lowers range/reliability. You also would prefer to minimize or eliminate any volitile storage on the devices.

Also you very much want to absolutely minimize the data sent, both for battery life and range/reliability reasons.

And whatever volatile storage the devices have you need to have some way of handling it being reset when its lost due to a dead battery or replaced device.

So standard replay resistant protocols like "door sends a random challenge, fob signs/decrypts/encrypts it and sends the result" are excluded due to the two-way requirement.

The next obvious set is along the lines of "device sends an encrypted counter, door enforces that the counter only goes up" requires nonvol storage in both devices, and then gets tripped up when the fobs counter goes back down due to being reset. (also harder to implement multiple fobs, as they each need unique state).

▲

cyberax 6 days ago | parent | next [-]

> Cryptography is actually difficult for the requirements of a key fob.

No, it's not.

> The next obvious set is along the lines of "device sends an encrypted counter, door enforces that the counter only goes up"

That's already how rolling codes work. Running a strong crypto algorithm (even Ascon/Speck would be fine here) requires negligible power.

The issue is that this system is still susceptible to jam+replay attack. An attacker can jam the transmitter signal, while recording it at the same time. The user assumes that the button press just didn't register and tries again. The attacker also jams this and records the code. But then the attacker replays the _previous_ code that they stored, keeping the latest code for their future use.

This can _also_ be fixed with a simple capacitor-powered timer circuitry, charged during the keypress. The device can stay completely inert at all other times.

▲

fc417fc802 6 days ago | parent | prev | next [-]

Agree about the requirements but disagree that it's difficult.

Two way communication and a few KiB of nonvolatile storage on the fob shouldn't be a deal breaker when an ESP32 dev board runs under $10 (an ESP32 being massive overkill for the described use case).

The device sending an encrypted counter is also trivially easy. There's no reason a modern vehicle can't store hundreds (or thousands, or tens of thousands ...) of { u64 fob_id, u64 fob_key, u64 fob_counter } triplets. Push it up to 128 bits if you're paranoid, it won't have a meaningful impact on resource usage.

Case in point regarding the car storing state, the (broken) rolling window algorithm they use requires that the car track the window and accept presses that are out of sync by a decently wide margin. That's likely more complicated and resource intensive than simply enforcing that the nonce only ever goes up.

The rational conclusion is that the manufacturers are either incompetent or malicious. I firmly conclude the latter given that the fobs they offer that are actually secure introduce vendor lock in and a charge to replace a key.

▲

nullc 5 days ago | parent [-]

What you're describing is basically keeloq which is one of the most common rolling code systems. It sends a 28 bit serinal number a 4 bit button code, 2 bit code for repeat and low battery, and a 32-bit encrypted part with an incrementing sequence number.

The rx enforces the sequence goes up.

You press button to open. Attacker lets the first sequence go through and the door opens, while the button is still down the attacker jams your second transmission while capturing it themselves.

Now they have a code they can use to open again when you're not around, assuming you don't use it again in the meantime.

If you wonder how vulnerable systems keep getting deployed without it being malicious, you don't need to look any further than the nearest hotshot that thinks everything is "not that difficult" and that everyone else is incompetent.

Security of any kind is just hard. The defender must defend against any possibility while the attacker needs just one vulnerability. How much cost and range and battery life are worth losing when the attacker can just punch through a window with their fist?

	▲	fc417fc802 5 days ago \| parent [-]
		You misrepresent my position. The attack you describe isn't the one being discussed here. Unless I've completely misunderstood, the algorithm itself was broken here. As to the attack you reference. It's active and touchy to pull off. It doesn't particularly concern me but of course would be better if it weren't possible. To that end I'm not clear why there's a double transmission with two distinct and independently usable codes? What am I missing? I thought the attacker jammed, recorded two user attempts (ie two distinct button clicks, neither being permitted through initially), then rebroadcast the first attempt while retaining the second for later. > The rx enforces the sequence goes up. Except that there's apparently a rolling window to support recovering from desync. Which to me sounds more complicated and error prone than a simple nonce that can only ever go up. Really though the manufacturers ought to (IMO) accept the extra dollar or five on the BoM that it would take to get proper two way communication.

▲

SoftTalker 6 days ago | parent | prev [-]

If only almost everyone carried a computer with a radio and local storage and a good battery with them almost everywhere

▲

nullc 6 days ago | parent [-]

with a battery life of two years? and durable against going through the washing machine?

▲

SoftTalker 6 days ago | parent [-]

If you want simplicity and ruggedness we should never have moved away from steel keys.

▲

hollerith 6 days ago | parent [-]

Very few keys are made of steel. Brass is the most common material.

	▲	SoftTalker 6 days ago \| parent [-]
		The problem with brass is that it wears away and the small shavings of metal gunks up the lock mechanism. Mercedes used steel keys to avoid this.