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

21–30 of 53 posts

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

#21

Post by IshKebab »

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

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

#22

Post by bjt2n3904 »

exhilaration wrote: post #20
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.

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.

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

#23

Post by ipunchghosts »

lunixbochs wrote: post #15
lucaspiller wrote: post #12

Earlier quoted context omitted.

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

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

#25

Post by echion »

exhilaration wrote: post #20
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.

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.

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

#26

Post by Unhackable »

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…

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

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

#27

Post by falsedan »

exhilaration wrote: post #20
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.

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?

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.

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

#28

Post by w8rbt »

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.

A physical key ;) like we used to have.

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

#30

Post by retSava »

exhilaration wrote: post #20
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.

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 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.
Post reply on HN