Using RTL-SDR to Open Car Doors (2016) | Hacker News Reader

Using RTL-SDR to Open Car Doors (2016)

anthonys.io

75 pointsweinzierl47 comments

Open articleView on HN

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.

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?

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)

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.

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

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.

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

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

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)

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.

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

The article states the need to jam the transmission (illegal in many countries) but does not explain why.

Many key fobs now (to my limited knowledge ) use an expanding one time use "code "essentially so once that transmission has been made, the same transmission won't unlock the car a second time. (On new vehicles at least )

This isn't a replay attack in the traditional sense. The attack works by simultaneously receiving the fob signal while jamming it to the car so it doesnt see it. Then, the car can't roll ahead its table.

To say another way, it exploits the fact that you can be a hundred miles from your car and push the unlock button on your fob but then return next to your car, push the fob, and the car unlocks.

Why aren't the previous codes invalidated though? If the attacker catches code X, and the owner presses the button again to send code X+1, why is code X still valid?

Both X and X+1 are jammed, then the attacker replays X. The car never sees X+1 to revoke either.

Yes. There is a rolling code both inside your car rx and the fob tx. They get out of sync (think of pushing your car unlock when your car is not around) but the fob can never be behind the car.

By jamming the the rx at the car it never gets code X+1 but the attacker does so the car never rolls ahead. Then, the attacker replays X+1 and the car unlocks.

This attack has been known for a quite a long time along with the TPMS hack (made famous but rutgers and U South Carolina http://www.sc.edu/news/newsarticle.php?nid=1202#.WRXDdVXythE)

https://www.theregister.co.uk/2010/09/21/car_jammer_vehicle_...

I just wonder if there are any car lock systems that don't use any rolling codes, but does a proper challenge-response auth with time-limited nonces.

Might be that the keyless entry systems use that - since they need a challenge from car to engage anyway. Really hard to find documentation though :/

The car locks usually operate on a rolling code system, where each code is only used once. By jamming the signal, you record it but don't let the car receive it, so you have one code. Then, when the remote gets pressed again, you record the second code and send the first. So, you're always one code ahead, and you can use that single code to open the car once.

AFAIK, if you let the car read a code straight from the remote, it will sync forward again, making all your stored codes invalid.

It I remember correctly, it's only a 32bit string on a rolling crypt thats protected by "Secrets"...

And I'm reasonably sure that the algorithm is now published. It wouldn't be hard to get 3 or 4 button presses, and then exhaustive search the space for the right serial and then attack it.

Hey author here, I have since removed the core information but left all the mechanisms to carry out the attack still. If anyone is interesting or have any questions I'll be here and Twitter.com/tech

There is no need to remove the info. We can talk about jammers in the USA. Here: cut a hole in the door of a microwave oven. That's a jammer.

Enjoy your subsequent trips to the oncologist.

samyk did it first: http://samy.pl/defcon2015/

One has to wonder about a technical blog that starts off with "Using the orginal RTL and pair that with HDSDR software on linux". So I did a search, and HDSDR only runs on Windows.

Maybe the post author used Wine[1] to run HDSDR on Linux.

[1]https://www.winehq.org/

There's GNU Radio which can work with the same RTL-SDR dongles as at least as I know it.

Can you listen for the communication and play it back... range maybe. Put a sticker under the car door handle haha

Does anyone know a good alternative for HDSDR for Linux?

I've used gqrx for some simple stuff and liked it: http://gqrx.dk/

Thank you.

I love GQRX. Use it a lot.

Unfortunately it has a rather severe bug that prevents it from even starting up in Ubuntu. The workaround/solution is to install a bunch of PPAs and software from them, which I didn't bother with.

Reply on news.ycombinator.com