Hacker News Reader

Comment by BluSyn | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com