4 ms·

it's nothing new for cars to be susceptible to replay attacks, yet it's always a proof of incapacity of the involved developers. to even implement such a desig

it's nothing new for cars to be susceptible to replay attacks, yet it's always a proof of incapacity of the involved developers. to even implement such a design is audacious

lnsru 2y ago
No. The developers are very capable. Think about Volkswagen’s diesel defeat device. The managers are the ones running the show. And you can do anything you like as developer in such situation. Managerial decisions will not change. It’s hidden caste system where (somehow arrogant automotive) managers will never listen to (probably for particular project leased from some bodyshop) developers.
londons_explore 2y ago
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 2y ago
  > 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 2y ago
    > 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 2y ago
      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 2y ago
        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.
- BenjiWiebe 2y ago
  What kind of cheap low power clock do you propose to use that only loses a couple seconds over 20 years?!

it's nothing new for cars to be susceptible to replay attacks, yet it's always a proof of incapacity of the involved developers. to even implement such a design is audacious

lnsru 2y ago

No. The developers are very capable. Think about Volkswagen’s diesel defeat device. The managers are the ones running the show. And you can do anything you like as developer in such situation. Managerial decisions will not change. It’s hidden caste system where (somehow arrogant automotive) managers will never listen to (probably for particular project leased from some bodyshop) developers.

londons_explore 2y ago

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 2y ago
> 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 2y ago
  > 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 2y ago
    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 2y ago
      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.
BenjiWiebe 2y ago
What kind of cheap low power clock do you propose to use that only loses a couple seconds over 20 years?!