[londons_explore]

The problem is most cars remotes are one-way comms, and the car remote has no concept of time.

Given those constraints, there is no fix possible.

However, a more modern car remote could easily send a signed message saying "Open car, Time is 1/1/2025 17:53, Signature: 7F82SA42ad==". The car would then check the time against its clock and only accept the command if the message is only a few seconds old.

The battery in a car remote should be able to keep a clock ticking for the 20 yr lifespan of the car (and a sync procedure for keys where the battery gets replaced).

The clock doesn't need to use wall time, but some custom "seconds since birth of key" would do just fine too, eliminating bugs due to leap seconds, incorrectly manually/auto set clocks, timezone changes etc.

[wolrah]

> The problem is most cars remotes are one-way comms, and the car remote has no concept of time. > Given those constraints, there is no fix possible.

There are in fact multiple "fixes" which have been widely implemented in devices that care to get it right for decades.

The simplest of course being a basic rolling code, where a counter is transmitted along with the command and this has to increment compared to the last press.

That would be easy to spoof based on a single capture and likely could just be brute forced, so with a slight bit more effort you make it skip a fixed amount forward and lock out for a short period of time if it receives values outside of the expected possibilities.

This could still be spoofed by logging multiple uses, so a bit more complexity for a massive amount more security can be had by using a PRNG for the code instead of an incrementing counter. Now you have to have a pairing process to sync the transmitters up, but that could be as simple as a button under the remote's battery cover that makes it transmit the RNG seed.

In any of these cases you accept the next however many potential codes in the cycle based on how many times you want to tolerate someone using their remote as a fidget toy (or how much you want to support low battery operation).

[londons_explore]

> The simplest of course being a basic rolling code, where a counter is transmitted along with the command and this has to increment compared to the last press.

These attacks typically rely on jamming the receiver in the car (eg. with a tone at a frequency between the two frequencies used by the FSK of the key), whilst capturing the signal sent by the remote.

Then the attacker replays the signal to the car at a later date.

Since the car has never seen this signal, it defeats any rolling code mechanism. Without both sides having a clock, there is no defence.

[wolrah]

That would only work if the car has also not seen any further valid messages since the one that was blocked, so I'm not seeing how this technique could be useful for anything other than preventing someone walking away from their car from successfully locking it and being able to go through the car before replaying the signal and locking it yourself to cover your tracks.

Even then if they're the sort of person who does the double click for horn/flash thing they'll just assume their fob batteries are dying and return to the vehicle until they're close enough to defeat the jammer.

If the rolling code is predictable and the attacker can generate their own valid "next message" that's an entirely different matter, but a pure replay is only useful in very specific situations.

[londons_explore]

The typical process, which I see active in London pretty frequently, is to jam and record everything on 433.92 Mhz.

Then, when you have received at least one lock and unlock request for a car, start retransmitting lock and unlock requests, but delayed by one request.

That way, the owner of the car thinks their key is working, and it unlocks and relocks reliably, but in fact the attacker always has one code 'spare'

Then, at 3am they come use their spare code to unlock the car and steal stuff or drive it off (the car only needs to see to fob present briefly to start the engine, but I believe that bit is done with a relay attack. I see the guys who do this waving their suitcase antenna around peoples doors regularly).

One giveaway to know on my car that such an attack is underway is that if you press the lock button 5 times in a row, it would normally flash the indicators with every press. However, when an attack is underway, it will only flash the indicators the first time, and won't do it again till after the next unlock, which makes sense because the command (lock or unlock) is not independent of the rolling code.

[wolrah]

> Then, when you have received at least one lock and unlock request for a car, start retransmitting lock and unlock requests, but delayed by one request.

For this story to play out with a non-spoofable implementation the attackers would have to be present for and able to jam/intercept every use of the fob between the first one in their sequence and the present.

I'm not saying it's not technically possible, but any use of the fob that slips through the cracks resets the sequence so if the target takes the vehicle somewhere else or even just uses the fob while close enough to not be jammed the idea falls apart. Unless the target is in the habit of going back out to their parked car to retrieve things and then locking it back up it seems like that'd be a rare catch.

> (the car only needs to see to fob present briefly to start the engine, but I believe that bit is done with a relay attack. I see the guys who do this waving their suitcase antenna around peoples doors regularly).

Relay attacks on pushbutton start vehicles are an entirely different matter as they do involve two-way communication and if you have the ability to start a car with one you also have the ability to unlock it with the same method. I'm just talking about traditional long range one-way fobs here.

[BenjiWiebe]

What kind of cheap low power clock do you propose to use that only loses a couple seconds over 20 years?!