Hacker News Reader

Comment by jacobolus | Hacker News Reader

What I want to know is why the car will continue to accept 100 trial keys per second after the first 100,000 attempts failed.

Shouldn’t there be some kind of exponential back-off after failures? If after the first 1000 failed keys it would only accept e.g. one new try every few seconds, it would then take 2–3 orders of magnitude more time to brute force.

View on HN

It doesn't: according to the paper, when someone turns the ignition key, they car will generate about 20 challenges to the key fob, and if the fob does not successfully authenticate any of them, the car will give up and not start.

The attack works by overhearing the exchange between the car and the key fob, and then doing an somewhat brute-force analysis to calculate what the secret key on the fob must have been.

Could someone explain why there is no delay after each failed attempt? The system allowed 197k brute force attempts in 30 minutes. I just cannot wrap my head around it.

I tried reading the paper (not an expert). In the recommendation section, it does not suggest implementing a delay either. Is it just not physically possible with RFID?

I mean, a 4 digit pin with a 5 second delay would take 14 hours for all combinations (better than the half hour with Megamos)???

I have to be missing something.....It can't be this easy.....

As the previous comment says, there's a requirement to eavesdrop on at least one successful authentication.

My guess is that they're then doing the brute-forcing "offline", not against the vehicle's system. If you know the algorithm and the keysize, and you can see one successful authentication, you could ship the work of workig out which key replicates the authentication you just saw off to AWS or custom hardware (I wonder how readily Bitcoin mining ASICs can be tweaked to attack embedded or IoT authentication?) (Though it seems there's flaws somewhere in the crypto anyway - they somehow broke a 96bit key with under 2^18 attempts...)

That helps. Thanks.

Clearly, the fact that listening to an exchange helped them proves that the security is fundamentally flawed.

To a car owner, that's another security flaw of its own. An attacker can deny an owner access to their car with a simple code spammer hidden nearby.

Surely that's better than having your car stolen, right?

Security is about trade-offs, after all.

> Surely that's better than having your car stolen, right?

Stranded in hostile environment (middle of nowhere in the arctic or a desert) could be a death sentence.

Who is going to DoS your car in the middle of the arctic or a desert?

Eh, I dunno, I guess a very not-nice person could attach the device to your car and activate it remotely/later.

I think a more realistic exploit would be a corrupt tow-truck driver / mechanic targeting an area where tourists stop.

That could be exploited to produce a trivial denial-of-service attack.

Wouldn’t you need to have a device actively running within a few feet of the vehicle to run such an attack? Couldn’t the car start blaring an alarm or something in that case?

We’re not talking about a website here.

> Wouldn’t you need to have a device actively running within a few feet of the vehicle to run such an attack?

Nope. Just a high-gain antenna.

> Couldn’t the car start blaring an alarm or something in that case?

It could. But that might not help.

For example: you're driving your Mazerati down the road when it suddenly stops and the alarm goes off. The next day you get a letter saying, "If you don't want yesterday's little incident to become a regular event, send BTC500 to the following address...."

If the car responds to RFID keys at all when driving, that is a flaw.

If I get out of my car with the engine still running it starts beeping. I don't know if it will actually turn the engine off, but it obviously knows that the key has departed the vehicle.

Or it detected your bum leaving its seat.

No, because if I toss the key into the seat it stops beeping even if I'm not there.

My car also beeps when it detects that the key has left the car. The engine keeps running, but you obviously cannot turn it on again once you turn it off.

I had it happen without me leaving the seat (e.g. my wife has the keys in her bag/pocket, I had been driving, and she gets off the car to unarm the home alarm). The car is turned on by pressing a button, not by turning the key.

That seems like a reasonable setup. I'm having difficulty imagining how that could be hacked into the blackmail situation described above, since the sure way to avoid the beep is to keep the fob in the car.

..plus a high-gain antenna, and suddenly you have an attack that sets off every car alarm in the city at once.

Which would be of no use at all to car thieves.

True, but it might be handy for kidnappers.

We're veering into movie-plot territory here.

(not original responder)

That's true. On the subject of movies, though, a plot point based on an actual vulnerability would be way better than typical Hollywood hacking.

Carjackers, and parking lot muggers.

...and that achieves?

I can think of other, lower tech, DoS attacks against cars -- which are also not much exploited.

Someone once DoS'd my car, by slashing two tires. On a downtown public street.

That sucks to have happened to you, but that sentence made me lol.

People always say this about physical tech, but the difference is ease and scalability. Slashing all the car tires in a block is harder and more traceable than sending out a small RF signal.

Remediating slashed tires is a lot more difficult than waiting for your attacker to get bored and move on.

What if the car was parked in a handicapped spot near entrance of a football stadium? It could conceivably receive enough incorrect RFID signals to trigger a back-off.

Since this is an anti-theft system, not a safety system, I can totally see that VW made a rational decision "it's better for the anti-theft system to let a thief steal the car 50 times than for one person to legitimately get locked out of their car."

You can make up for car thefts with dollars.

I don't know anything about the protocols involved, but it would be possible for the first message to be "I'm a key that would like to unlock the vehicle with VIN# 123abc...". In that case there would be no mistaken protocol runs.

There is no key as such. The fob for my Hyundai never leaves my pocket. Just by standing next to the car, the unlock button on the door is enabled. So if I walk up and push the button, it unlocks. If I'm not around, the button does nothing.

So there's no discernible event from the fob, as far as I can see. It's just a "this is me" signal.

I guess the Hyundais I've driven were different, in that the unlock button was on the fob rather than on the car door. Could you say, if you have multiple cars, does the fob work with all of them? I doubt that's the case, so I don't see why your "this is me" signal couldn't actually be a "this is me, fob 123ABC..., and I can authenticate with the vehicle with VIN# 123abc...".

your "this is me" signal couldn't actually be a "this is me, fob 123ABC..., and I can authenticate with the vehicle with VIN# 123abc..."

You're right, that might be it.

the unlock button was on the fob rather than on the car door

Let me clarify: the fob does have buttons for lock, unlock, panic, and open trunk. But I don't normally use them. My normal usage is as I described: just walk up with the fob in my pocket, and press the button on the door handle.

I don't think a high traffic spot could ever cause an issue with this, unless each person tried to start your car. I believe this is referring to the immobilizer chip in the key that allows turning the key to start the engine. Incidentally, this is probably the chip that means that if you lose your key, you can't just get a new one cut, you need to get a new chip too.

I assume the software/hardware is so simple and specific that adding something like back off blocking would require memory chips, software, timers etc increasing the complexity dramatically.

Reply on news.ycombinator.com