[xenadu02]

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.

[mcpherrinm]

That doesn't fix this exploit at all: This is merely an analog device amplifying other radio waves.

The only way to secure against the described exploit is to measure round-trip-time from the car -> key -> car and ensure it's under, say 5 light-meters: aka 16 nanoseconds, plus the carefully calibrated time it takes the key to compute its response.

16 nanos is a very short amount of time, and it'll be tricky to measure that reasonably accurately.

The real solution is to require the user to interact with the key in some way, like pressing a button, or perhaps moving it around (as would happen as you walked with it in your pocket).

[MertsA]

>perhaps moving it around (as would happen as you walked with it in your pocket).

One attack vector is stealing cars out of a supermarket parking lot. You just wait for someone to drive up in the model car of your choice and have your accomplice discreetly follow them into the store. When your accomplice texts you that they are at the bread aisle/back of the store you can just steal with impunity knowing that a bystander will see no difference between the actual owner who has the key in his pocket and you with your relay device in your pocket. You also know that your victim is in the back of the store and that they can't get within sight of you before you're already long gone.

[pandaman]

My car seems to be able to tell if the key is inside or outside pretty accurately so I think it can already figure out the distance to the key (though might be using something like RFID for that, which is not very secure).

[csours]

The whole point is the the car is using signal strength as a proxy for proximity, which is unreliable when you can use an transceiver and/or amplifier to boost the signal strength from a remote key.

[pandaman]

Not sure if you've miss-replied, but in case you imply the key location works on signal strength I doubt that very much.

[csours]

Do you have a source for your doubt? It would be more technically accurate to say that the car is dependent on signal fall-off than signal strength, but that seems to be a distinction without a difference to me.

>A PKES car key uses an LF RFID tag that provides short range communication (within 1-2 m in active and a few centimeters in passive mode) and a fully-fledged UHF transceiver for longer range communication (within 10 to 100 m). The LF channel is used to detect if the key fob is within regions Inside and Outside of the car. Figure 2(b) shows the areas in proximity of the car that must be detected in order to allow a safe and convenient use of the PKES system. The regions are as follows. [1]

1. http://www.syssec.ethz.ch/content/dam/ethz/special-interest/...

[pandaman]

As you can see on the picture yourself, the inside/outside zones are very close to each other. Locating a key with such a precision based on the signal strength alone does not seem possible for following reasons: the key's transmitter is too small to provide stable signal level, the key is located in very anisotropic environment, the car itself changes its shape and hence RF loss from different directions.

[kosievdmerwe]

How does this protect against an attack that connects the key to the car with a wireless range extender?

[TwoBit]

what are you talking about? This isn't about replay attacks. The car sends a message to the key, which is 200 feet away. This hack merely amplifies the signal so the key acts like it's only 2 feet away. The amplifier is a man in the middle, but it need know nothing about the contents of the signal. Encryption is powerless against this.