Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using RTL-SDR to Open Car Doors (2016)

anthonys.io

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Using RTL-SDR to Open Car Doors (2016)

#31

Post by exhilaration »

echion wrote: post #25
exhilaration wrote: post #20

Earlier quoted context omitted.

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?

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!

Re: Using RTL-SDR to Open Car Doors (2016)

#32

Post by weinzierl »

xgbi wrote: post #11

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.

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?

Re: Using RTL-SDR to Open Car Doors (2016)

#34

Post by dfox »

weinzierl wrote: post #32
xgbi wrote: post #11

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.

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.

Re: Using RTL-SDR to Open Car Doors (2016)

#35

Post by mseebach »

dfox wrote: post #34
weinzierl wrote: post #32

Earlier quoted context omitted.

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'…

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.

Re: Using RTL-SDR to Open Car Doors (2016)

#36

Post by ethbro »

mseebach wrote: post #35
dfox wrote: post #34

Earlier quoted context omitted.

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'…

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

Re: Using RTL-SDR to Open Car Doors (2016)

#37

Post by ethbro »

IshKebab wrote: post #21
xgbi wrote: post #11

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.

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 b…

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.

Re: Using RTL-SDR to Open Car Doors (2016)

#38

Post by norea-armozel »

grymoire1 wrote: post #10

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.

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

Re: Using RTL-SDR to Open Car Doors (2016)

#39

Post by mseebach »

ethbro wrote: post #36
mseebach wrote: post #35

Earlier quoted context omitted.

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

Re: Using RTL-SDR to Open Car Doors (2016)

#40

Post by dfox »

ethbro wrote: post #36
mseebach wrote: post #35

Earlier quoted context omitted.

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)

Post reply on HN