Note the use of software defined radio.
The rolling code approach has its vulnerabilities.
(It would be doable, and not so difficult, to e.g. implement true one-time pads, and upload new set to the keyfob whenever it is used to start the car by plugging it to the dashboard.)
The HackRF platform mentioned at the end of the article (USRP was used for the actual hack) deserves more attention.
There’s a fix for that “feature”:
Everything old is new again…
Nobody could possibly have foreseen.
But a heck of a job was done.
But slimjimming (on the many cars it still works on) is not conspicuous at all. It takes less than 2 seconds to do, and the tool can easily be concealed in a jacket and against the body of a car. I once was locked out of a car, called campus cops for help, and the officer opened my door without even stopping walking by it – I suppose he was showing off 
But yeah, it’s silly that the electronic approach is feasible, considering it should be easy to secure against with a little common sense.
Not exactly that kind. STU-III keyfobs (to call the key shaped physical device and avoid confusion with the crypto key) are only “dumb” stores for crypto keys. They don’t operate wirelessly and don’t have to be secured against a replay attack. (Though I wonder how they are secured against unauthorized copying, the non-wireless replay-attack equivalent - but making the owner responsible for keeping them in sight could be enough.)
Related thought: a Raspberry Pi based equivalent of a STU-III secure phone, using ethernet or cellphone as connection, acting as the red/black gateway.
Welcome to the Internet of things. Today your car. Tomorrow your thermostat, home security system, implanted medical device. Call me an old fogey but I totally do not understand the drive to put every device possible into crackers’ hands.
This has been known for some time. They could build a system that is virtually unbreakable but why they don’t implement it is beyond me.
…which is fixable with a hacksaw blade that cuts through the steering wheel, and still leaves the car steerable.
So that explains this monstrosity that I saw when looking for a “club” image – I guess that there is a steering wheel lock arms race.
The software defined radio aspect may be a new twist but otherwise this is old news. While it is still interesting, I stick with the adage “locks are there to keep out the honest.” It’s as simple as chucking a small chip of spark plug ceramic at your window if someone really wants in. Not very discrete, but still fast.
The problem as it stands is there is no incentive for auto manufacturers to switch from the same broken system they have been using for decades. I’m not going to be concerned unless (until) remote entry by cell phone or over the Internet catches on. HackRF looks fun though. I’ll need to check that out.
As far as the one time pad idea goes, that’s a better tool for encryption than authentication.
The problem may look like an opportunity from the other side, for aftermarket electronic lock mods.
You can use OTPs for authentication quite easily; send the pad to the recipient, who confirms receiving and then both pads are erased. (Better is a challenge-response protocol, where fob sends transaction request, car sends random challenge, fob encrypts it with one pad and sends it back.) The thing to watch for is how to prevent attacks that would convince the fob to divulge the pads before they are erased on the car’s side, so they cannot be obtained by Eve the Eavesdropper and then replayed to Bob the BMW. So send only after challenge reception, and receive challenges only after sending own transaction request. I’d have to think more in-depth about the actual protocol. But it is doable.
The same can be done with challenge-response via a proper hash function (SHA1, for example). (How many milliamp-seconds of power it would take to ATmega328 to calculate a SHA1 of (say) 256 bits? With the fobs, the battery life is one of the limits.)
Both hash with shared key and OTP (which can also be considered a shared key, or, a table of single-use shared keys) can do a good job here. Bidirectional communication is however required to do it well (maybe there is some workaround?), in comparison to the rolling-code fobs which talk one-way-only.
Edit: Thought for the lock mods: there are many cars but only few chip vendors. The lock device is something that provides a digital output that announces unlock to the car’s electronics. The replacement device can be a module that’s pin-compatible with the original chip, and installs instead of it (e.g. desolder the chip, solder in the adapter with short cable to the module, glue the module somewhere in the lock module compartment). That way only the chip’s behavior has to be emulated, and the rest of the car’s electronics won’t see a difference.
Criminals have been using this attack for years: https://www.youtube.com/watch?v=l7OadDz3Ums
All they can do is steal valuables (while doing you the courtesy of not leaving you with a broken window), they can’t steal the car.
Cars with remote-keyless-ignition are safe from this attack (those fobs use a proper two-way-radio and answer cryptographic challenges from the car). This attack only works on cheap one-way-radio rolling-code systems like garage-door-openers. Cars with these cheaper systems do not have them hooked up to the ignition, probably for exactly this reason.
If your car has remote keyless ignition, or offers a setting option to automatically lock and unlock the doors based on your proximity (ie you don’t have to fish out keys and press a button, you just walk away from the car or walk up to it) then this attack won’t work. There is a theoretical attack that could, but it’s crazy difficult, requiring far more technology and manpower and closely-coordinated teamwork, it’s more “Ocean’s Eleven” than real world problem. 
They’ve already made that (virtually unbreakable) system available for years now, if not decades. Part of the issue is that they want a range of products (cars) spanning a range of budgets, so they want a gradient of features so that high-end models sport better features than low-end models. Locks that are “good enough” vs locks that are unbreakable is part of that gradient.
Cost is also a factor, but costs of miniature wireless microprocessors have been coming down, and cryptographic fobs seem to be becoming standard on mid-range vehicles now.
Dear Wired, please don’t publish the make of my car, but enjoy this video of me demonstrating the hack on my 2004 Nissan Pulsar.
KTHXBAI
You can use OTPs for authentication quite easily; send the pad to the
recipient, who confirms receiving and then both pads are erased. (Better
is a challenge-response protocol, where fob sends transaction request,
car sends random challenge, fob encrypts it with one pad and sends it
back.)
I wasn’t saying it was not possible, it’s just cumbersome and you run into the problems of eavesdropping when transferring the pads, the need to protect against unauthorized overwriting with a different pad, the pads getting out of sync, the annoyance of getting locked out when you forget to upload a new pad to the car, etc. By the time you put in all of the safeguards for these, you’ve got a system that doesn’t really need the one time pads in the first place. There really isn’t a problem that using a one time pad solves in this case.
This topic was automatically closed after 5 days. New replies are no longer allowed.
