Tons of the rolling key systems on the market are based on KeyLoq, and keyloq is a fairly well designed system with a big lynch pin.
It has something called a 'manufacturer key', which needs to be available to any device that allows field pairing of remotes. If that manufacturer key is known, it only takes two samples from an authenticator to determine the sequence key.
Absent the manufacturer key, jamming+replay attacks work, but brute forcing a sequence key is generally prohibitively costly.
However, since any receiver that supports field programming needs the magic "manufacturer key", one could purchase such a unit, and may be able to extract said key.
RachelF · 1h ago
This is why keyless "start button" functions on cars is a bad idea.
The old approach of keyfob to unlock the car and a real key for the ignition is safer.
Having multiple levels of security is good.
However, having worked in the car security industry many years ago, I discovered that car manufacturers actually like it when their customer's cars are stolen - Insurance payouts often result in another sale.
Terr_ · 2h ago
I sometimes imagine how much of this could be avoided if the communication signals weren't (a) broadcast or (b) a imperceptible to humans.
If it an electrical contact in the door handle, it would be very difficult for anyone to monitor or inject other signals.
If the signals were audible sound, you'd know when someone was jamming it.
In practice, my number one use of a fob from a remote distance is locking, rather than unlocking, and those two operations don't have the equivalent security risk.
misswaterfairy · 31m ago
> In practice, my number one use of a fob from a remote distance is locking, rather than unlocking, and those two operations don't have the equivalent security risk.
Wouldn't the risk be the same if the same rolling code keys was used for both locking and unlocking?
I would be surprised if automotive manufacturers used separate rolling code keys for locking and unlocking.
cakealert · 3h ago
Why are so many car manufacturers incapable of using cryptography properly?
ronsor · 5m ago
You can ask this question about almost every non-software company. Hell, you can ask this question about most software companies.
The real question is "why are most people and companies incapable of using cryptography properly?"; and the answer is that doing cryptography right is hard, especially if your use case isn't a common one.
tamimio · 3h ago
Car manufacturers are like automation/control manufacturers; they existed before cybersecurity and never caught up to the pace. If you ever audited any SCADA system, you will see nightmares. For cars, some new models of popular brands (not specifying any), you can access the CANbus from the headlight where you can reprogram the ECM to your new key. It's that simple to "own" a modern car.
dfex · 1h ago
PREACH!
Currently sitting in a control room at a greenfield manufacturing facility trying to describe why even VLANning the control network would be a good idea to some controls engineers who want a plant-wide subnet for all PLCs that will be remotely supported by 6 different vendors. The struggle is real
protocolture · 42m ago
Loosely aware a controller manufacturer who wanted a bluetooth/wifi based password recovery utility with a fixed or predictable recovery key.
They were asked what their exposure would be if someone walked into a datacenter and used their phone to disable all the airconditioning systems.
giantg2 · 1h ago
Do they want the passwords for all their systems to match so they don't need to remember as many?
dfex · 12m ago
My suspicion is that they want all the passwords on this site to match the one they use with all their other customers too.
Saves money on password management.
Terr_ · 40m ago
> It's that simple to "own" a modern car.
On the other hand, it's been a great excuse for a hobby project with 12V relays and learning how to write code for an ESP32. :P
I still haven't yet figured out which CAN-bus to tap and which undocumented byte-messages to interpret... but entering the Konami Code on the steering wheel to unlock the ignition is quite plausible. Or an NFC/RFID tag over a hidden reader, or an active bluetooth connection to my phone, etc.
Whatever the case, quite enough to stop the average thief that would target a cheaper vehicle like my own. You could also skip the ESP32, and have a purely analog switch tucked away.
bbarnett · 2h ago
I've seen one-manufacturer, 2024 models at least, which requires two keys in range, before a third key may be programmed.
Good idea, don't know how effective it is in reality.
bayindirh · 2h ago
Needing two keys for a third one is not new. My 25 year old car needs two keys for adding the third, old Fiats has “red master” keys which are also required during adding keys.
serf · 1h ago
Honda/Acura/Toyota have used similar systems for years; this is one of the reasons why cloning a key costs less flagged hours than making a new one for an owner that lost all of them : when you lose all of them you need to get the actual computer out and pair it with the ecm directly, when you clone them there is a ritual that can be done with the other keys+ the new one.
dzhiurgis · 20m ago
Man wish we could copy that key onto smartphone (Apple needs to add flipper zero's tech to iPhone) for easy keyless access.
dylan604 · 2h ago
Proper security is a total pain in the ass, and makes things nigh impossible to use in the manner people want to use them. This naturally makes things more expensive to recover from oopsies.
This is why YubiKeys will only ever work for people technical enough to understand them. Normies will loose it at the first chance, and then be locked out of everything. At that point, YubiKeys will be banned by Congress from all of the people writing in demanding something be done about their own inabilities to not be an ID10T
theamk · 1h ago
As far as car security is affected, "normies" really don't care what the algorithm is. The entire UX is "press button to open car, go to dealership if you need new key" and it allows a wide variety of choices re algorithms.
The only reason they use KeeLoq (with whopping 32 bits of security!) instead of something normal, like I dunno, AES-128 or something, is because they are trying to save $0.50 in parts on the item they sell for $100. Oh, and because they don't like any change and don't have organizational ability to use anything recent, like other poster says.
fc417fc802 · 39m ago
> The entire UX is "press button to open car, go to dealership if you need new key"
Ironically proper security in this case would likely improve the user experience as well. The car provides a 64 bit (or larger) secret value and you manually program a standardized fob with it. No need for custom parts that are only available from the dealer.
Terr_ · 37m ago
I wonder if it's less about the cost of silicon, and more about the energy budget for a device that uses a button-cell battery.
Even if it's a problem with off-the-shelf stuff, I imagine a car-manufacturer could easily get something all nice and tiny and special-purpose.
dylan604 · 1h ago
> (with whopping 32 bits of security!)
Ha! DVDs at least had 48 bits. /s
giantg2 · 39m ago
Proper security doesn't need to be perfect security. In the case of car manufacturers, most of their fob implementations are borderline negligent.
kube-system · 1h ago
The reason these vulnerabilities affect many brands is because they don’t use cryptography. They buy these electronics from other suppliers.
the_mitsuhiko · 3h ago
To some degree customers love it. It allows you to program your own replacement key without having to go through the manufacturer or an official dealer.
j1elo · 3h ago
No doubt they would charge $100 or more for just clicking a button and having the equivalent of an NFC writer.
hungmung · 1h ago
Well they don't call them stealerships for nothing.
pkaye · 2h ago
I wonder who make more money on this. The car dealer or the manufacturer.
colechristensen · 3h ago
When my favorite quadruped knocked my keys into the trash I had to get my car towed to the dealer for them to program me a new key. One one hand, top notch security as it was impossible to do any other way. On the other hand the total to get this done was something like $500 after everything.
dylan604 · 2h ago
I did this to myself by placing my keys in a pocket of a bag that I've never used before when returning to the airport parking. I found the keys in the bag after paying to have it re-keyed after paying for the tow from the airport to the closest dealer.
mh- · 7m ago
This is totally something I'd do. I'm very organized when I travel for work and everything has a place. If I absentmindedly slip something into the wrong part of my bag, it might as well be invisible..
theamk · 1h ago
You can have strong cryptography + ability to self-pair. See bluetooth or wifi or zigbee or many other technologies..
fc417fc802 · 37m ago
Maybe the car manufacturers should just give up and adopt BTLE. Proper security, and you could unlock with your phone.
IshKebab · 3h ago
What does? The article is very unclear about what exactly this does.
the_mitsuhiko · 3h ago
The attacks to rolling code keys are well known but these keys continue to exist. They allow you to pair a key yourself to the car that you buy online. Particularly in the US it's quite common that people buy used cars and then another key online that they pair themselves.
You won't be able to do this for instance with VAG cars that have KESSY. First of all the immobilizer is paired to the key, secondly the only way to pair a new key to it is via the manufacturer or a licensed dealership because you need a blob from their central server. But the consequence is that people feel like they are being fleeced when they need another key, because it can cost you hundreds of dollars to pair one.
In general these types of attacks are much harder in Europe where immobilizers have a legal minimum standard that manufacturers have to meet. On the other hand in the US immobilizer are entirely optional, which has famously led to KIA and Hyundai cars shipping without them and the Kia Boys TikTok phenomenon.
fc417fc802 · 33m ago
> But the consequence is that people feel like they are being fleeced when they need another key, because it can cost you hundreds of dollars to pair one.
Because the ARE being fleeced. It's an artificial dependency on the vendor on the one hand versus a blatantly insecure approach on the other.
Secure pairing that can be done by the end user isn't rocket science.
brk · 48m ago
It's not like the systems they used for physical keys were ever very robust either.
downrightmike · 24m ago
Like when just putting in a usb-A anything into the steering column and letting the car drive away? Nah man, no one will figure it out. We're good. Our backdoors are the best
nullc · 1h ago
Cryptography is actually difficult for the requirements of a key fob.
The principle issue is that requiring two way communication greatly increases hardware cost and lowers range/reliability. You also would prefer to minimize or eliminate any volitile storage on the devices.
Also you very much want to absolutely minimize the data sent, both for battery life and range/reliability reasons.
And whatever volatile storage the devices have you need to have some way of handling it being reset when its lost due to a dead battery or replaced device.
So standard replay resistant protocols like "door sends a random challenge, fob signs/decrypts/encrypts it and sends the result" are excluded due to the two-way requirement.
The next obvious set is along the lines of "device sends an encrypted counter, door enforces that the counter only goes up" requires nonvol storage in both devices, and then gets tripped up when the fobs counter goes back down due to being reset. (also harder to implement multiple fobs, as they each need unique state).
fc417fc802 · 23m ago
Agree about the requirements but disagree that it's difficult.
Two way communication and a few KiB of nonvolatile storage on the fob shouldn't be a deal breaker when an ESP32 dev board runs under $10 (an ESP32 being massive overkill for the described use case).
The device sending an encrypted counter is also trivially easy. There's no reason a modern vehicle can't store hundreds (or thousands, or tens of thousands ...) of { u64 fob_id, u64 fob_key, u64 fob_counter } triplets. Push it up to 128 bits if you're paranoid, it won't have a meaningful impact on resource usage.
Case in point regarding the car storing state, the (broken) rolling window algorithm they use requires that the car track the window and accept presses that are out of sync by a decently wide margin. That's likely more complicated and resource intensive than simply enforcing that the nonce only ever goes up.
The rational conclusion is that the manufacturers are either incompetent or malicious. I firmly conclude the latter given that the fobs they offer that are actually secure introduce vendor lock in and a charge to replace a key.
SoftTalker · 43m ago
If only almost everyone carried a computer with a radio and local storage and a good battery with them almost everywhere
nullc · 28m ago
with a battery life of two years? and durable against going through the washing machine?
SoftTalker · 1m ago
If you want simplicity and ruggedness we should never had moved away from steel keys.
sneak · 3h ago
They're not. There is AFAIK an ssh key infrastructure for OnStar that's modern and well-run, for example.
Things like key fobs are most likely very incremental changes on "this is the way we've always done it". These organizations are behemoths and steer with all of the inertia of a containership.
VoidWhisperer · 27m ago
And tend to get stuck in their ways like a container ship stuck in the suez canal
No comments yet
palata · 4h ago
> A consequence of this is that the original keyfob gets out of sync, and will no longer function.
I always wonder about this: what is the consequence of that? Can the user reset it, or does it have to be done by a retailer or something?
brk · 3h ago
Depends on the implementation. Most times you just have to click it a few times in a row. The receiver then realizes it missed a few button presses and it re-syncs. I’m not sure what that window is though, at some point it might get so out of sync that the receiver ignores it and assumes it is a wrong fob.
siffin · 40m ago
If I remember correctly the size of the rolling window differs, more modern vehicles may allow about 100 code discrepancy before ignoring the transmitter, while old models might have been 5 to 10.
geekamongus · 21m ago
This seems difficult when you can order a Ford fleet key off Amazon and get access to most Ford trucks and vans for about $15.
lq9AJ8yrfs · 4h ago
flipper zero implementation of a variant [1] of the rolljam [2] attack
Kind of insane that this works... Surely whoever implemented this knew it was insecure? I honestly wouldn't have thought to check for this vulnerability because... who would do that??
dylan604 · 2h ago
I don't think the word "secure" was ever part of the discussion on keyless entry for cars. They would have used something like "convenience". Secure would maybe be considered in that the car doors are now locked from the keyless. But as far as "secure" being used in regards to the transmission/receiving of the wireless signal? I doubt if it was ever mentioned by anyone other than PR.
antirez · 2h ago
I guess this attack is against the keeloq protocol. There are no known total breakage of this kind AFAIK, against the cryptography implemented in the chip. This will be interesting to understand, I mean: what they are exactly doing here.
tamimio · 3h ago
Cool, I was planning to get a spare car key, not anymore!
Also, glad I have one before they would ban it. It’s a neat tool that I have everything I want there, instead of having 4 fobs, one garage remote, plenty of IR remotes, it’s AIO. Plus I don’t have to pay fees to replace my lost fobs
imzadi · 3h ago
Sadly, it won't work as an extra key, because it causes the original key to stop working.
tamimio · 3h ago
Welp, that’s a bummer! Have you tried it?
Alejandro9R · 3h ago
It says in the article
tamimio · 2h ago
In that case, it mostly will be used in a bad way.
radicaldreamer · 1h ago
You can be sure that this attack has been well known to intelligence agencies for a while.
waltbosz · 2h ago
Jokes on them, I lost my key fob years ago.
seany · 1h ago
Why isn't a link to the repo/firmware the first link in the article?
xyst · 2h ago
cool, I needed a new car, thanks
jeffbee · 1h ago
Pretty sure you want an old car to avoid this one. A bicycle would also avoid it.
withinboredom · 1h ago
Unless you're my son who has to buy a new bicycle lock every month because he loses his bike keys.
egypturnash · 1h ago
Get your son a key ring with a chain and make him attach it to his bag or his pants somewhere.
hsbauauvhabzb · 2h ago
What practical use does this have? From my reading if I capture an unlock signal, the car will not unlock for the owner, so they’ll press their remote a few times.
If I capture a lock signal, presumably I can instead prevent it from locking. The only real world malicious action I can see is being viable is to block the car lock, meaning the car is still in an unlocked state, open the boot (which I’m guessing can be done from the car dash anyway) then locking it afterwards?
theChaparral · 2h ago
This attack lets you use all the functions of the key fob, and not just the action captured.
hsbauauvhabzb · 1h ago
It makes no suggestion that it’s possible to start a push-to-start car.
Someone looking to break into your car will probably use a brick, not a flipper zero.
fc417fc802 · 15m ago
Bricks attract lots of attention in busy parking lots. An unlock chirp, removing some bags, and walking off will appear legitimate to bystanders.
Suggests that it can be used to start a car. Whether it was a fob start or push start isnt specified.
theoreticalmal · 2h ago
If the attack causes the original key to no longer work, imo the major threat vector is someone sitting in a parking lot, capturing key presses, performing the attack, and forcing the user to tow+re-program the key as a nuisance, rather than stealing the vehicle
summermusic · 1h ago
In addition to being able to break in and steal anything that’s kept in the car
It has something called a 'manufacturer key', which needs to be available to any device that allows field pairing of remotes. If that manufacturer key is known, it only takes two samples from an authenticator to determine the sequence key.
Absent the manufacturer key, jamming+replay attacks work, but brute forcing a sequence key is generally prohibitively costly.
However, since any receiver that supports field programming needs the magic "manufacturer key", one could purchase such a unit, and may be able to extract said key.
The old approach of keyfob to unlock the car and a real key for the ignition is safer.
Having multiple levels of security is good.
However, having worked in the car security industry many years ago, I discovered that car manufacturers actually like it when their customer's cars are stolen - Insurance payouts often result in another sale.
If it an electrical contact in the door handle, it would be very difficult for anyone to monitor or inject other signals.
If the signals were audible sound, you'd know when someone was jamming it.
In practice, my number one use of a fob from a remote distance is locking, rather than unlocking, and those two operations don't have the equivalent security risk.
Wouldn't the risk be the same if the same rolling code keys was used for both locking and unlocking?
I would be surprised if automotive manufacturers used separate rolling code keys for locking and unlocking.
The real question is "why are most people and companies incapable of using cryptography properly?"; and the answer is that doing cryptography right is hard, especially if your use case isn't a common one.
Currently sitting in a control room at a greenfield manufacturing facility trying to describe why even VLANning the control network would be a good idea to some controls engineers who want a plant-wide subnet for all PLCs that will be remotely supported by 6 different vendors. The struggle is real
They were asked what their exposure would be if someone walked into a datacenter and used their phone to disable all the airconditioning systems.
Saves money on password management.
On the other hand, it's been a great excuse for a hobby project with 12V relays and learning how to write code for an ESP32. :P
I still haven't yet figured out which CAN-bus to tap and which undocumented byte-messages to interpret... but entering the Konami Code on the steering wheel to unlock the ignition is quite plausible. Or an NFC/RFID tag over a hidden reader, or an active bluetooth connection to my phone, etc.
Whatever the case, quite enough to stop the average thief that would target a cheaper vehicle like my own. You could also skip the ESP32, and have a purely analog switch tucked away.
Good idea, don't know how effective it is in reality.
This is why YubiKeys will only ever work for people technical enough to understand them. Normies will loose it at the first chance, and then be locked out of everything. At that point, YubiKeys will be banned by Congress from all of the people writing in demanding something be done about their own inabilities to not be an ID10T
The only reason they use KeeLoq (with whopping 32 bits of security!) instead of something normal, like I dunno, AES-128 or something, is because they are trying to save $0.50 in parts on the item they sell for $100. Oh, and because they don't like any change and don't have organizational ability to use anything recent, like other poster says.
Ironically proper security in this case would likely improve the user experience as well. The car provides a 64 bit (or larger) secret value and you manually program a standardized fob with it. No need for custom parts that are only available from the dealer.
Even if it's a problem with off-the-shelf stuff, I imagine a car-manufacturer could easily get something all nice and tiny and special-purpose.
Ha! DVDs at least had 48 bits. /s
You won't be able to do this for instance with VAG cars that have KESSY. First of all the immobilizer is paired to the key, secondly the only way to pair a new key to it is via the manufacturer or a licensed dealership because you need a blob from their central server. But the consequence is that people feel like they are being fleeced when they need another key, because it can cost you hundreds of dollars to pair one.
In general these types of attacks are much harder in Europe where immobilizers have a legal minimum standard that manufacturers have to meet. On the other hand in the US immobilizer are entirely optional, which has famously led to KIA and Hyundai cars shipping without them and the Kia Boys TikTok phenomenon.
Because the ARE being fleeced. It's an artificial dependency on the vendor on the one hand versus a blatantly insecure approach on the other.
Secure pairing that can be done by the end user isn't rocket science.
The principle issue is that requiring two way communication greatly increases hardware cost and lowers range/reliability. You also would prefer to minimize or eliminate any volitile storage on the devices.
Also you very much want to absolutely minimize the data sent, both for battery life and range/reliability reasons.
And whatever volatile storage the devices have you need to have some way of handling it being reset when its lost due to a dead battery or replaced device.
So standard replay resistant protocols like "door sends a random challenge, fob signs/decrypts/encrypts it and sends the result" are excluded due to the two-way requirement.
The next obvious set is along the lines of "device sends an encrypted counter, door enforces that the counter only goes up" requires nonvol storage in both devices, and then gets tripped up when the fobs counter goes back down due to being reset. (also harder to implement multiple fobs, as they each need unique state).
Two way communication and a few KiB of nonvolatile storage on the fob shouldn't be a deal breaker when an ESP32 dev board runs under $10 (an ESP32 being massive overkill for the described use case).
The device sending an encrypted counter is also trivially easy. There's no reason a modern vehicle can't store hundreds (or thousands, or tens of thousands ...) of { u64 fob_id, u64 fob_key, u64 fob_counter } triplets. Push it up to 128 bits if you're paranoid, it won't have a meaningful impact on resource usage.
Case in point regarding the car storing state, the (broken) rolling window algorithm they use requires that the car track the window and accept presses that are out of sync by a decently wide margin. That's likely more complicated and resource intensive than simply enforcing that the nonce only ever goes up.
The rational conclusion is that the manufacturers are either incompetent or malicious. I firmly conclude the latter given that the fobs they offer that are actually secure introduce vendor lock in and a charge to replace a key.
Things like key fobs are most likely very incremental changes on "this is the way we've always done it". These organizations are behemoths and steer with all of the inertia of a containership.
No comments yet
I always wonder about this: what is the consequence of that? Can the user reset it, or does it have to be done by a retailer or something?
[1] https://arxiv.org/abs/2210.11923 [2] https://news.ycombinator.com/item?id=10018934
Also, glad I have one before they would ban it. It’s a neat tool that I have everything I want there, instead of having 4 fobs, one garage remote, plenty of IR remotes, it’s AIO. Plus I don’t have to pay fees to replace my lost fobs
If I capture a lock signal, presumably I can instead prevent it from locking. The only real world malicious action I can see is being viable is to block the car lock, meaning the car is still in an unlocked state, open the boot (which I’m guessing can be done from the car dash anyway) then locking it afterwards?
Someone looking to break into your car will probably use a brick, not a flipper zero.
https://i.blackhat.com/USA-22/Thursday/US-22-Csikor-RollBack...
Suggests that it can be used to start a car. Whether it was a fob start or push start isnt specified.
Take the car while they are in the store.