Hacker News Reader

> UWB is essential for secure vehicle unlocking. Bluetooth isn't, because it can be relayed. It'll give Apple a nice integration point with your new car.

The radio technology involved should have almost nothing to do with the ability to perform a relay attack. There are two straightforward mitigations:

1. Timing. The two parties confirm that a message can round trip in a specified, very short time T. This proves that the distance between the parties is T/2c or less.

To be useful, T should be, say, 20ns or less, which requires a bit of clever crypto to make the actual exchange fast enough.

2. The transmitter attempts to localize itself, using GPS or other technologies, and refuses to authenticate unless it’s near the receiver.

There is reason to believe that UWB will help with localization. I see no reason it would be any better than any other technology for time-of-flight measurements unless sub-nanosecond resolution is needed.

Bluetooth uses frequency hopping, which is unsuitable for measuring TOF. This group tried it: https://hal.inria.fr/hal-01995171/document and even with a lot of cleverness they were seeing 100 foot RMS errors from Bluetooth. Not enough to prevent stealing someone's car parked in their driveway while their phone is in the house.

They’re using unmodified hardware and minimally modified software. It would be interesting to see how much precision could be achieved with hardware modifications.

Instead of Bluetooth (which Apple could totally fudge on their own devices if they wanted to), the TOF for the Apple Watch<>Mac auto-unlock uses Wi-Fi 802.11v. It seems really quick too (presumably the Mac is establishing a short-lived AP), would work fine for unlocking a car.

Here’s a good article further explaining it for those curious: https://networkingnerd.net/2016/09/21/apple-watch-unlock-802...

Well sure, but at that point is it still Bluetooth?

> To be useful, T should be, say, 20ns or less, which requires a bit of clever crypto to make the actual exchange fast enough

I don't think you even need crypto on the actual exchange.

The car and the key fob could negotiate a pair of random values, R1 and R2, using an encrypted protocol so that eavesdroppers cannot figure out R1 and R2. This negotiation does not have to be particularly fast, so no need for anything clever. This is also where you would do authentication to prove to the car that it is talking to an authorized key fob.

For the actual distance measurement, the car sends a message containing R1 and the key fob responds with a message containing R2. Each R1/R2 pair would only be good for one try, so it doesn't matter if an eavesdropper sees the distance measurement attempt.

This is not necessarily good enough. Suppose one party sends R1 at a rate of 1 bit per 10 ns, i.e. 100 Mbps. The other party checks R1, aborts if it’s wrong, and otherwise sends R2. The first party checks that R2 was received on time and correctly.

An attacker can relay all but the last n of R1 and guess the last n bits. With probability 2^-n, the guess is correct, and the attacker learns R2 n*10 ns early. If the attacker can attempt the attack a few times, then getting a 60ns advantage is entirely reasonable and is enough to break some use cases.

So some more cleverness really is needed.

I'm not seeing how this works. Let's say R1 and R2 are 8 bits each, and the attacker chooses n=2. Let the parties by C (car), F (fob), and M (attacker).

So C starts sending R1, M starts receiving R1, and after relaying 6 bits of R1 M guesses the last 2. Let's say M gets lucky and guesses correctly. So now M has the 6 bits of R1 it received from C, plus the 2 it correctly guessed, and so it has R1, 20 ns earlier than it should.

But to get F to send R2, M still had to send those 2 guessed bits on to F. That's 20 ns, assuming a fixed bit rate on the physical layer, which is how I assume these kind of systems would be designed. That should prevent M from learning R2 early.

The hardware I was envisioning for this would have a shift register on F that gets loaded with R1 xor R2. As the range finding bitstream comes in, it would shift out the bits from that shift register, xor them with the incoming bits, and transmit the result.

Similar on C. Load a shift register with R2. As echo bits come in, shift bits out of the shift register, xor with the incoming bit, and shift the result into another shift register (or get fancy and do this all with one circular shift register). At the end of the echo message, if the output shift register is all zero, it got the right R2.

Note that with this implementation there is no aborting on F if it receives the wrong R1. The wrong R1 simply makes it send back the wrong R2.

(Note: this design assumes that C and F both can simultaneously transmit and receive).

Hmm, I may indeed be wrong. I guess that the fob won’t start transmitting R2 until after it receives all of R1, so the early guess doesn’t help. This does assume that the fob doesn’t accept higher-than-expected data rates. That last bit could be a real issue if the physical later can operate at multiple data rates and the attacker can convince the car and fob to disagree on the rate.

But I think your xor register is no good. The attacker can just send all zeros to learn R1 xor R2 and then can emulate the fob at whatever range it likes when the car sends the real R1. Also, the radios are likely to be half-duplex, which may make it impossible. Instead, I think F just verifies each bit and stores a single bit of state indicating whether the bits were all correct. Then, after the last bit is received, it transmits R2 if all bits of R1 were correct.

Ah, but then I can learn R2 by simply sending F enough R1, no?

Why does the attacker gain a time advantage here? Is the attacker capable of transmitting at a much higher rate than the original sender? Even in that scenario, they just have to negotiate a send/receive rate up front, and that way the attacker can't jump the line because that would violate the negotiated rate (nor can the attacker intercept and increase the rate because then the original sender won't be transmitting fast enough).

R1 and R2 aren't reused. So you can't chain the attack to gain enough of an advantage.

My attack doesn’t need reuse. It’s based on the fact that cheating the protocol has a success probability that falls off too slowly with the amount of cheating.

This can be improved with multiple rounds. I’m not sure it’s possible, even in theory, to do better in a single round.

Maybe someone cares to speculate about replacing Bluetooth for AirPods.

It fits easily in the bandwidth of UWB. AirPods are ideal candidates for better locating ability. I can’t say for certain but a rough googling suggests that the radio accounts for the bulk of the energy used in an AirPod, and UWB appears to have better efficiency per bit.

Scooters could be using NFC/RFID payments today (e.g., Apple pay) instead of QR codes. So you could just walk up, tap your phone, and go. UWB offers no real usability advantage here. Scooter companies don't use these methods because they want you to install their app for user retention reasons.

So what's missing in your scooter use case is a loyalty mechanism rather than a lack of payment technology.

Also you want your scooters to work for the large portion of people who didn’t upgrade to a NFC enabled phone yet

QR codes are highly backwards compatible

Doesn’t preclude a NFC improvement, but my experience with Scan QR to Unlock has been very good, point the phone at the bike, bike unlocks, not much to improve

besides the cost of installation. Printing a qr code << NFC reader. On a 200 dol e-scooter, that is not trivial economy

>UWB will also improve the ergonomics of contactless payment. With the current system, you have to hold your phone really close to the reader for a few seconds. UWB could allow an instant gesture.

This is a security feature, intentionally.....

I’ve made guesses at specific product applications based on forthcoming tech from Apple before and the focus is too narrow. It may _also_ be good for secure vehicle unlocking but it wouldn’t make it in unless it has a dozen more useful and ecosystem expanding product applications.

I dunno, Apple's put some pretty single-purpose hardware into their devices in the past. Like the sensor array that's pretty much only useful for Face ID, and the Force Touch stuff. (And Macs used to have an IR receiver, which IIRC was only used for compatibility with the old Apple TV remote.)

Face ID can be used for eye tracking - paralysed people can already use it via app called Access. It's quite impressive.

Do you feel the object tracking tags (immediate global object tracking) eclipse or equal utility secure vehicle unlocking?

I could totally see Apple only ever using this for the tracking tags (with a hastily-thrown-together the AirDrop feature so they have something to show off when the phone launches) and never letting anyone use it for anything else, regardless of the potential utility.

> Like the sensor array that's pretty much only useful for Face ID

Isn't this used for Animoji as well?

Isn't that useless and dead?

Now that I think about it: Animoji may have been a justification for the sensor array as in "look, multiple purposes".

Definitely not dead. iOS 13 is adding new Animoji characters along with more customizable Memoji features. Plus the ability to use Memoji stickers across a variety of services, rather than just through iMessage.

Can't the relay problem be solved by having time of flight measurements as any relay attempt would inherently take more time than what a direct communication would?

I'm pretty sure that's what they're doing with the macOS Apple Watch unlock.

Yes, time of flight is what UWB measures. But Bluetooth isn't suitable for measuring TOF to a useful accuracy. (I'm not sure what the Watch unlock feature is using.)

There’s two ways to triangulate, another is using two antenas and attempting to estimate the power of the signal source.

In practice this sucks more than one would imagine. In a cluttered environment all you get reliably is close, near, far, somewhere else. Because you have 10-30db multipath fades and attenuation exponents are on the order of 2.5 to 3.5

You can spoof that too, with a relay. In fact, just putting the relay transmit antenna in the expected place should give the right ratio of RSSI.

Seems silly to imagine, but it is possible and I didn’t consider that.

I don't know which companies operate in your area, but you should be able to simply open the phone's camera and read the QR code, which will then pop open the app. Five seconds tops.

> Bluetooth isn't, because it can be relayed.

Angle of Arrival/Angle of Departure mitigates this. Attempting to relay will screw up the phase relationships.

UWB is basically Time of Flight.

>With the current system, you have to hold your phone really close to the reader for a few seconds

You do? Mine is almost scarily eager to pay the bill.