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.