Hacker News Reader

Comment by mackman | Hacker News Reader

Can someone please help me understand how using a relay device defeats proximity detection by time of flight? It’s not like the relay device can talk to the remote device faster than the speed of the original signal.

View on HN

It isn't doing time of flight, but just getting under a latency threshold that these devices use as a cutoff to try and avoid things like this relay attack.

They say they got the added delay somewhere below 8ms to defeat the system. In 8ms, light/radio travels around 2500km.

Could latency/time-of-flight threshold be reduced to determine proximity? Requires very accurate clocks on both ends, and support in the wireless cards. Apple developed something similar for Apple Watch unlock on MacOS [1].

[1] https://networkingnerd.net/2016/09/21/apple-watch-unlock-802...

I don't see why you need an accurate clock on both ends, you simply need a precise clock on one end (which can be the car): do a challenge/response where the car sends the key a question and requires the answer back within the very short period of time. The key in that case doesn't need a clock at all.

This is exactly the kind of methodology the attack in the article uses though. BLE peripheral devices are usually allowed to miss connection events to preserve battery life, and to increase the reliability of the connection in noisy environments. The attack exploits the ambiguity between "the transmission was intercepted and relayed with an additional 8ms" and "the phone/keyfob skipped a connection event". Allowing no missed connection events would probably make the system frustratingly unreliable as you'd constantly be re-connecting and re-authenticating with the phone/keyfob.

I mean, that's not the methodology of the attack... if the methodology I described were used the attack would not be possible. You are saying it is not possible to implement this mechanism on BLE without affecting the user's experience and, if someone had tried for this key, they wasted their time as they didn't understand how BLE worked. While I am honestly skeptical of that--as I would expect I could use a different packet with a new local timestamp for each of these "reconnections"--I don't know much about BLE, and so am willing to take your word for it; but, as we clearly aren't going to want to synchronize the clock between the car and a silly little key fob so accurately as to allow us to deal with the time difference of the speed of light moving across a mere parking lot, the conclusion to me is that we can not use BLE (which I would think is overkill for a key anyway) and instead must use a more trivial radio scheme.

  > a more trivial radio scheme

Which would require hardware not available in typical - or low-end - consumer smartphones.

Interestingly enough, apple has UWB on some of their newer phones, which would make these attacks a lot harder. https://developer.apple.com/nearby-interaction/

I imagine you would use UWB for the location, and BLE for authentication/data transfer though.

Tesla uses BLE for their keyfobs as well. They probably just didn't consider it worth it to add additional hardware to prevent these attacks, especially when it has to be compatible with your average consumer smartphone back in 2017 (model 3 release date). You could have two separate radio systems, one for the keyfob, and one for the phone (and then correlate the phones GPS with the measured location), but that sounds expensive and complicated.

BLE has some other mechanisms for determining the proximity of a device, such as Time of Flight (ToF) and Angle of arrival (AoA). I'm unsure if Tesla uses these, or if the reachers were able to circumvent them.

Time-of-flight: https://software-dl.ti.com/simplelink/esd/simplelink_cc2640r...

Angle of arrival: https://dev.ti.com/tirex/explore/node?node=AOSUfCXMkNaUAy6wn...

The author of article stated it wrong. It's not the time-of-flight that is used as a proximity measure, it is the received signal strength (RSS). By limiting response times to 8 ms just demands better relaying equipment. 1 nanosecond means around 30 centimeters in air and you need very precise clocks (or by measuring ToF by roundtrip times with very precise local timestamping of messages) and much wider bandwidth (500 MHz+) if you want to measure ToF with such precision. Bluetooth doesn't have that functionality.

I would add that UWB chips do have that functionality so it would be nice to see them adopted widely in mobile phones. Currently only high-end devices have those chips in them (recent iphone and google/samsung flagships).

Reply on news.ycombinator.com