Hacker News Reader

Comment by kazinator | Hacker News Reader

> Key fobs are constantly broadcasting a signal that communicates with a specific vehicle, he said, and when it comes into a close enough range, the vehicle will open and start.

It's a poor design for the system to take any access-escalating action without an explicit command from the user that initiates a secured transaction that is resistant to MITM.

It's poor design to assume that the range is based on raw signal strength; it should use round-trip-time measurements (for packets exchanged with MITM resistance).

View on HN

> take any access-escalating action

I see I made a naive statement here. Let's consider the access-reducing action of the vehicle locking itself when the fob becomes distant. That is also open to exploit; if the attackers boost the signal when they spot a driver walking away from the car, then the locking neglects to take place as the driver enters a building and goes out of sight.

However, auto locking a car based on proximity is justifiable as a fall-back measure to explicit locking with a button. The rationale is that if the user forgot to lock, it is probably better to do it for them than to do nothing.

RTT measurements are hard to make reliable with wireless systems. You don't want to set the bounds to tight, to avoid locking out the car owner in circumstances with a lot of interference. But neither do you want a signal booster to be in those bounds.

But there are better solutions. I've heard about a car maker (I think it was BMW, but don't quote me on that) that put an acceleration sensor in the key fob. It would only broadcast the signal while the key fob is moving.

RTT measurements can give proof-of-proximity (due to relavity), but I think they're quite hard to get right (you'd need nanosecond RTT resolution in a cheap keyfob) -- I think analog signal repeaters would't add significant RTT. It's not impossible though, GPS decoders work in a similar fashion.

Requiring user iniciation seems like the adequate solution here...

The Apple Watch manages to handle RTT measurements to prevent exactly this attack.

You don't need complexity in the FOB; the car starts the clock, sends the signal, measures the time taken to reply. If it exceeds some threshold ignore the response.

There is no way to spoof this if the request/response itself is using proper cryptography.

It's the vehicle side system that measures RTT, not the fob. The fob just has to have consistent response latency so as not to perturb the RTT.

Reply on news.ycombinator.com