6 ms·

The auto manufacturers (and for that matter all the "IoT" creators) couldn't give two shits about protecting consumers. Building security into this stuff is tri

• proksoup 11y ago
  Could you say more about those things they should be doing? I'm naive but it doesn't seem trivial to me.
  • rachelbythebay 11y ago
    Round trip times? Can't cheat the speed of light, assuming you can't spoof the transmission.
    • mirimir 11y ago
      Yes! Also, the link ought to be fully authenticated and end-to-end encrypted. And one could require the user to press a button on the key fob.
  • kileywm 11y ago
    The car could log the signal strength of all successful auth attempts from the key fob and determine an acceptable range. Anything outside of the acceptable range could then require use of the mechanical key (for those fobs where the mechanical key is built in) as a precaution. Fobs could require a 'wake up' key press after a certain duration of inactivity. Fobs could have a physical switch on them, enabling an airplane mode. These ideas all give up some manner of ease-of-use.
• big_al337 11y ago
  How would you prevent this type of attack while retaining the keyless start and entry feature? (just curious)
  • xenadu02 11y ago
    Lots of ways. The ECU only goes into pairing mode if it gets a valid challenge-response from the manufacturer. If put into that mode, it provides a nonce encrypted with its own pairing mode public key that only the manufacturer knows (could even base-64 encode it and show it on screen to let people do this over the phone). You could make it two-phase where it requires the first response within 5 minutes of starting, then requires a second response that must come one hour later (also with a 5-minute entry window). This makes social engineering much more difficult and the delay makes it impractical for most car thieves, but it won't impact dealers or legit owners at all. If the registered owner provides a cell phone, the first attempt should send a text message to let them know the ECU will enter pairing mode and allow them to reply with "STOP" to cancel any further requests. Once in pairing mode, the physical key and ECU use standard public-key crypto (ala SSL) to setup a secure connection, then exchange keys. In theory you could allow boot-strapping another key so long as an existing paired key is present which would make the procedure above your failsafe for when all keys are lost/destroyed. If you wanted to take things a step further you could use a form of distributed Kerberos where the manufacturer sets up a physical key with a ticket allowing access to one (or a set) of allowed cars but that makes the manufacturer's systems a massive target for hacks/social engineering which is a problem because thousands of dealer technicians need access to those systems... that's the point of the delays and short acceptance windows above. An evil tech or hacker can't pre-create a bunch of keys on the sly. To unlock or remote start, the key broadcasts a HELLO message, encrypted with the ECU's public key. The ECU responds with an ACK+nonce encrypted with the physical key's public key. The physical key decrypts it and replies with an ACK+nonce encrypted with the ECU's public key. Congrats, you now have a reasonably secure system that prevents replay attacks. Ultimately it would require embedded software engineers and company management who a) understood security and b) gave a shit. Both are in extremely short supply.
    • kosievdmerwe 11y ago
      How does this protect against an attack that connects the key to the car with a wireless range extender?
    • TwoBit 11y ago