Hacker News Reader

Comment by big_al337 | Hacker News Reader

How would you prevent this type of attack while retaining the keyless start and entry feature? (just curious)

>How would you prevent this type of attack while retaining the keyless start and entry feature

I get that regular keys could be copied and locks picked, but I feel that if you can't securely do wireless unlock and keyless start, then don't put it in.

The car industry has a lot to learn about security. I almost refuse to believe the stories where hackers take over the onboard computers via the entertainment systems in a car, because I can't believe that anyone would be stupid enough to link the two system. Yet, companies like Jeep seems to believe there's a reason that the computer running the GPS and radio needs access to the breaks.

> The car industry has a lot to learn about security.

Not only security; with GPS and radio having access to the breaks, the car industry has a lot to learn about safety.

The entire industry that allowed this kind of terrible design needs to study the lessons of the Therac-25. Nobody seems to understand what "fail safe" means anymore.

And yet cars have got both dramatically safer and much harder to steal

The simplest defeat is to require the key ping round trip to complete in N microseconds, where N is sufficiently low. Researchers have demostrated that this is a practical solution.

Theoretically, a attacker can transmit an amplified message 300 m in 1 microsecond. So the car must limit the RTT to only a few dozen nanoseconds. This is fairly easy with modern electronics.

A good search term is distance bounding protocol.

Wikipedia has an article with links to research:

https://en.wikipedia.org/wiki/Distance-bounding_protocol

Timing.

Proxying the radio signal over this link introduces a req/res delay. The handshake starts when the car detects fob proximity but there is still a communication with the key for authentication (otherwise you could have a replay attack). So if the car side is programmed to be strict about req/res timing you can defeat a proxy like this (in theory at least) at the expense of a higher false-negative rate.

Like they did it in the 90'ies? Have an actual button on the key that you need to press to open the doors and authenticate. Same goes for starting the car, if you want to offer the "feature" of remote start/stop.

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.

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

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.

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).

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).

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.

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

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/...

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.

Let's assume that each of us knows what we are talking about.

Yes, the actual key itself is located by the car based on Low Frequency RFID.

The attack described is a relay attack, which means that the key can be spoofed in real time by relaying short range radio transmissions to two locations.

The mistaken assumption of the security system is that the short range communication protocol used by the car and the key requires the key to be in close proximity to the car.

Since the communication may be relayed, the range assumption is invalid. The main suggestion is to use high precision timing to determine the range, as it is very difficult to cheat on the speed of light.

I agree that "signal strength" is not the best way to phrase the above in a technical discussion.

I have not seen any indication that triangulation or any other physical location system is used in vehicle PKES.

>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.

Requiring the key fob to be activated in some way would prevent a good number of these attacks. For instance, a capacitive sensor could be installed on the fob that would only begin transmission when picked up by someone's hand and cease wireless transmission after some timeframe, say 2 minutes. This would at least stop many of the burglaries that occur at night when people are at home.

Well, for existing cars, keep your key in a faraday cage.

My friend (who's not particularly technical and probably didn't know what a faraday cage was previously) told me that's what we has doing with his Prius key after it had been broken into with no sign of forced entry twice.

Make the driver press a button on the fob to unlock the door.

tinfoil pocket liner

Reply on news.ycombinator.com