Hacker News Reader

Hacker News

Comment by xgbi | Hacker News Reader

Parent Full thread

xgbi

So, what is the solution? Implementing a PKI over between the key and the car? This would be quite nice, wouldn't it?

-Key asks car to unlock and sends public key for recognition,

-Car sends challenge encrypted with key Public key

-Key sends back private-key-encrypted challenge

Bing, authenticated.

View on HN

I wonder if there is any (even theoretical) authentication method that works with a one way communication channel and is not vulnerable to the attack described?

Or maybe a proof that it isn't possible?

One thing that you can do with one way channel is to not use counter, but timestamp or preferably both at once. In this context it would require the keyfob to have reasonably accurate RTC which will certainly have some effect on battery life (which might be acceptable tradeoff given the fact that the CR2032 battery in VW's keyfobs seems to outlive the mechanical integrity of the receiver antenna on the car side).

It's certainly not complete solution to the problem but allows you to arbitrarily shrink the time window the attacker has to mount this attack.

That's how one-time password tokens like RSA SecurID and YubiKey works, and hardware/battery/cost wise, they seem to be well within scope for a car key.

How do you ensure the clocks are sync'd? Or is there a one-channel method that doesn't require synchronized times? E.g. window-based

Or is it that cheap to have ~5-10 yr accurate clocks implemented in hardware now? (Not that the margin on keyfobs seems exactly slim...)

The timestamps used in OTP tokens are usually quite coarse (30 - 60 second resolution is common), also it's common to use window of few accepted timestamps around the valid one. (IIRC SecurID has this window in default configuration surprisingly large, on the order of tens of minutes)

RTC with common 32768Hz xtal is probably accuratte enough for this application given reasonably stable temperature (ie. key stored in room temperature or near human body) with few minute acceptance window.

The problem with battery life for such keyfob is that it also has relatively high powered RF transmitter and combining low permanent current consumption with high current bursts is not something that cheap primary lithium cells are optimized for (you have to pick one or the other)

Edit: also given the fact that there is only one receiver and that it usually also has second bidirectional channel (immobilizer/keyless start) you can compensate for some limited clock drift in software or even periodically resynchronize the clock.

Manual for Fabia III even describes procedure to "resynchronize" the keyless fob by using it as if it were ignition key, which probably does exactly this. But who knows, almost all post 2000 VWs have similar procedure for central locking remote which probably simply overwrites the counter in car with whatever next value from the keyfob as there cannot be any bidirectional communication (the old procedure involves lock in driver's door, no NFC antennas there and the imobilizer NFC chip in keyfob is completely separate from the RF part)

A combination of good, accurate clocks (remember that a $10 digital Casio drifts less than a second per day) and some functionality on the server side to detect and correct for drift. When the key window is 30 seconds, the key won't drift more than 10 keys per year, which should be easy to correct for without compromising security (and if in doubt, it's easy to "ask" for a second code - just fail the attempt, the user will try again).

I don't think there's any reason to rely on a one-way channel. If the keyfob is in range to transmit, then it is definitely in range to receive (due to reciprocity); plus the car has a lot more electricity to spare.

There is fundamentally no reason why there can't be full authenticated PKI for keyfobs. It certainly isn't going to happen as part of a recall of current models, though.

A simpler solution is that the car should not accept a "skipped over" code. This attacks works by jamming code A and storing it for later use. The car owner assumes a signal loss and clicks again, opening their car with code B. If the car knows to reject code B in the future, why can't it also know to reject code A?

This is effectively how a rolling code works. You have a space of say, 2^16 keys that repeats. The car and keyfob share the same index to the keyspace, and increment one for every transaction.

If someone tried to "replay" an older key, the car would reject it. However, what if the user accidentally presses the button while not in range of the car?

To account for this, the system will "partially accept" keys "ahead of schedule" for about half the keyspace. The car advances its pointer (let's say N+5), and waits for N+6 to unlock.

Since most older keyfobs are simply "one way transmitters", PKI is out of the question. Newer keyfobs are able to receive as well, and could preform a handshake. However, car manufacturers are notoriously bad at security.

The car isn't being opened by B; it's being opened by A, and B is jammed and stored for later use. See other comment about the attacker always being "one [code] ahead" of the legitimate key fob user.

Thank you for the clarification!

That's not how the attack works though: the fob sends A, but the car doesn't see it because of the jamming. The fob then sends B, and the car still doesn't see it. Then the attacker stops jamming the car's receiver, and replays A, so the doors open. B is stored by the attacker to replay later.

This would break if you once press unlock while out of range of the car, unless you have some way to reset the counter - in which case you start creating complex stuff to handle complex situations.

Not necessarily. The car could accept future codes, but not an older one. Assume codes A through Z, you've used A, B, and C, then when out of range of the vehicle you send codes D and E (Or these are jammed and stored for later use). That afternoon, you return to your car and issue code F, now codes D and E are no longer accepted (Until you get so far down the line that looping becomes a concern)

This would prevent the attack but would be difficult to implement for existing car models.

The car most probably lacks the hardware to send at 315 MHz. Not that the key had the ability to receive either, but that means that you'd not only have to replace the key fobs but do a full recall campaign with new hardware in the car.

Speaking of the car, it has a receiver scanning that band, it should just detect that there's a jamming signal, and somehow prompt the driver to use the physical key to get in. Do modern cars still have physical keys?

You don't need PKI for this - the car and the key have pre-shared keys.

All you need is to include a counter in the signal that is incremented for each button press. The car remembers the last counter value it receives and ignores any before that. Obviously the counter needs to be encrypted in some way but it's not exactly difficult.

I'm kind of amazed this still happens in 2016. Or maybe it doesn't. The cars could be old.

Assume you're getting downvoted instead of commented on because, as above poster pointed out, the weak point is the counter in any one-way scheme. Specifically when the car doesn't see a fob press but the fob is pressed (e.g. out of range / blocked).

Thus, you have a broken keyfob if you ever press it outside the car's range (or require a "re-pairing" handshake to resynchronize the counters). Infeasible due to terrible usability.

Or you widen the window of accepted counters to avoid the above issus. Which is what this attack is preying on.

Err, no. You wouldn't require then counter to go up by exactly one each time. You just wouldn't allow it to go backwards.

This usually that attack method with the added benefit of making a mesh network out of it using LoRa signals.

A physical key ;) like we used to have.

This is vulnerable to high-resolution photograph and reproduction from that. Really it is a very analagous vulnerability to the one discussed in the article : an attacker in close proximity can get a good enough look at the key's secret to reproduce it.

I'd rather have to push a button on the key-fob then on the car...

Reply on news.ycombinator.com