> For this new attack to work, all that is needed is a single button-press capture from the keyfob, without any jamming. Just from that single capture, it is able to emulate all the keyfob's functions, including lock, unlock, and unlock trunk.
If I don't press the buttons on my keyfob am I safe from this?
The only keyfob functionality I normally use is that when it is outside the car but within about a meter of the door handle the door can be locked or unlocked by pressing a button on the door handle.
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.
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.
As far as I know no vehicles use this kind of rolling code algorithm for push button start, only key fob functions. Certainly not in Europe (due to immobilizer regulations) but I don’t believe anywhere else either.
Generally, long range key fob button functions and the short range start release functions are separated, both intentionally for security reasons and due to the different problem space occupied by each.
It’s also worth noting that European makes in general tend to have much better cryptographic key security. My understanding is that this is due to a combination of regulation, a relationship between insurance and automakers which requires some security standard, and a high rate of theft leading to an adversarial environment.
Pretty short sighted, given how much we've seen insurance rates climb for specific makes. People know you'll be paying through the nose for certain Hyundais models. That kind of brand damage can't be cheap
Sure, but in my experience, people never attribute high insurance costs to the underlying risks being high, rather they blame that on the insurance companies and then vote for people who promise to “do something about it“.
I’m sure there is brand damage from people hearing that a particular car is frequently stolen, because having your car stolen as a pain. I am skeptical the analysis reaches deeper than this first level tho.
As a DIY option, there are definitely ways you could add MFA-like security with a simple switch/relay (attached to said authentication factor) in most ignition systems.
However, that wouldn't help with the "desyncing" or unlocking aspects of this attack.
I had a used VW gti (late last century) with an imobilizer. It let the engine crank but wouldn’t start. It also locked the hood from opening, leading to some panic when first getting the car and forgetting it had this feature.
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.
> 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.
> Wouldn't the risk be the same if the same rolling code keys was used for both locking and unlocking?
Yes, what I meant is that such symmetry is not strictly required, and breaking the symmetry opens up ways to enhance security (of unlocking when you arrive) while keeping most of the convenience (of locking while leaving.)
For example, imagine "Lock" is a typical broadcast from anywhere within X meters, but "Unlock" requires touching the fob to an infrared port, and they use independent codes.
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.
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.
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.
Am I the only one that just hates push to start in every way? Sure, I don't need to have the "insert key and crank" to be real, but physical key seems so superior.
Feels like getting rid of the light switches in your house in favor of "smart home" stuff.
I liked my old 'rolla that I could start with any key at all.. or even a paddlepop stick.
Every time I start thinking about these little modern inconveniences, I re-arrive at the idea that this is yet another example of the difference between a product and a tool.
A product ideally works the same for everyone, with as little friction to the immediate function as possible. All other functions are hidden or deleted. Trying to use a product as a tool is slow and frustrating, because the experience never gets better than the first time you use it.
A tool on the other hand needs learning. Sometimes that learning curve is shallow and long, like a hammer, or steep and long like CAD.
Smart home stuff can be pretty great if you treat it like a tool, and only use it where it is the right tool for the job (so, not light switches).
I mean, keep using your key if you like it. I for one love never having to touch my car keys. I touch my door handle the car unlocks, I touch the start button the car starts.
I'm on the other of the spectrum apparently, I'm annoyed that I even have to carry a key/fob. I'd rather have a fingerprint sensor or something, with the key as a backup (i.e. when I let some borrow it).
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
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
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.
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
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.
That's common, and it's often a bit stricter. E.g. my Ford Lightning has a pocket you have to put the fob into for this kind of activity. For certain things you need both fobs, so you do one, and then the other, as part of a sequence in the programming. Just being in range isn't good enough.
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.
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.
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
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.
> 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.
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.
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.
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.
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.
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..
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.
> 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.
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).
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.
> Cryptography is actually difficult for the requirements of a key fob.
No, it's not.
> The next obvious set is along the lines of "device sends an encrypted counter, door enforces that the counter only goes up"
That's already how rolling codes work. Running a strong crypto algorithm (even Ascon/Speck would be fine here) requires negligible power.
The issue is that this system is still susceptible to jam+replay attack. An attacker can jam the transmitter signal, while recording it at the same time. The user assumes that the button press just didn't register and tries again. The attacker also jams this and records the code. But then the attacker replays the _previous_ code that they stored, keeping the latest code for their future use.
This can _also_ be fixed with a simple capacitor-powered timer circuitry, charged during the keypress. The device can stay completely inert at all other times.
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
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.
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??
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.
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?
> For this new attack to work, all that is needed is a single button-press capture from the keyfob, without any jamming. Just from that single capture, it is able to emulate all the keyfob's functions, including lock, unlock, and unlock trunk.
If I don't press the buttons on my keyfob am I safe from this?
The only keyfob functionality I normally use is that when it is outside the car but within about a meter of the door handle the door can be locked or unlocked by pressing a button on the door handle.
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.
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.
As far as I know no vehicles use this kind of rolling code algorithm for push button start, only key fob functions. Certainly not in Europe (due to immobilizer regulations) but I don’t believe anywhere else either.
Generally, long range key fob button functions and the short range start release functions are separated, both intentionally for security reasons and due to the different problem space occupied by each.
It’s also worth noting that European makes in general tend to have much better cryptographic key security. My understanding is that this is due to a combination of regulation, a relationship between insurance and automakers which requires some security standard, and a high rate of theft leading to an adversarial environment.
Pretty short sighted, given how much we've seen insurance rates climb for specific makes. People know you'll be paying through the nose for certain Hyundais models. That kind of brand damage can't be cheap
Sure, but in my experience, people never attribute high insurance costs to the underlying risks being high, rather they blame that on the insurance companies and then vote for people who promise to “do something about it“.
I’m sure there is brand damage from people hearing that a particular car is frequently stolen, because having your car stolen as a pain. I am skeptical the analysis reaches deeper than this first level tho.
As a DIY option, there are definitely ways you could add MFA-like security with a simple switch/relay (attached to said authentication factor) in most ignition systems.
However, that wouldn't help with the "desyncing" or unlocking aspects of this attack.
I had a used VW gti (late last century) with an imobilizer. It let the engine crank but wouldn’t start. It also locked the hood from opening, leading to some panic when first getting the car and forgetting it had this feature.
It was a circular key below the steering wheel.
A physical steering wheel lock works too.
Not every problem needs a tech solution.
They're basically describing a hidden kill switch/toggle, which is just as much of a tech solution as the one you're describing.
Of course, they wrapped it in some nerdy terminology, which IMO obscures the intent of their suggestion.
So I guess it's back to locking the door manually before I close it, and being absolutely sure I don't leave the keys in the car.
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.
> 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.
> Wouldn't the risk be the same if the same rolling code keys was used for both locking and unlocking?
Yes, what I meant is that such symmetry is not strictly required, and breaking the symmetry opens up ways to enhance security (of unlocking when you arrive) while keeping most of the convenience (of locking while leaving.)
For example, imagine "Lock" is a typical broadcast from anywhere within X meters, but "Unlock" requires touching the fob to an infrared port, and they use independent codes.
> 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?
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.
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.
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.
Am I the only one that just hates push to start in every way? Sure, I don't need to have the "insert key and crank" to be real, but physical key seems so superior.
Feels like getting rid of the light switches in your house in favor of "smart home" stuff.
I liked my old 'rolla that I could start with any key at all.. or even a paddlepop stick.
Every time I start thinking about these little modern inconveniences, I re-arrive at the idea that this is yet another example of the difference between a product and a tool.
A product ideally works the same for everyone, with as little friction to the immediate function as possible. All other functions are hidden or deleted. Trying to use a product as a tool is slow and frustrating, because the experience never gets better than the first time you use it.
A tool on the other hand needs learning. Sometimes that learning curve is shallow and long, like a hammer, or steep and long like CAD.
Smart home stuff can be pretty great if you treat it like a tool, and only use it where it is the right tool for the job (so, not light switches).
Anyway, I prefer tools.
You mean the key and crank that could be started with a screwdriver and some elbow grease?
I also dislike it when people "fix" things that are not broken.
I mean, keep using your key if you like it. I for one love never having to touch my car keys. I touch my door handle the car unlocks, I touch the start button the car starts.
I'm on the other of the spectrum apparently, I'm annoyed that I even have to carry a key/fob. I'd rather have a fingerprint sensor or something, with the key as a backup (i.e. when I let some borrow it).
I also have a smart home ;)
Is there a cheap device you can make yourself or buy from India? Flipper zero is not easy if not impossible to buy.
For this project let's say
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
In addition to being able to break in and steal anything that’s kept in the car
Capture the lock as they walk into a store.
Take the car while they are in the store.
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
Sadly, it won't work as an extra key, because it causes the original key to stop working.
Welp, that’s a bummer! Have you tried it?
It says in the article
In that case, it mostly will be used in a bad way.
Why are so many car manufacturers incapable of using cryptography properly?
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.
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
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.
Do they want the passwords for all their systems to match so they don't need to remember as many?
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.
> 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.
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.
That's common, and it's often a bit stricter. E.g. my Ford Lightning has a pocket you have to put the fob into for this kind of activity. For certain things you need both fobs, so you do one, and then the other, as part of a sequence in the programming. Just being in range isn't good enough.
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.
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.
Man wish we could copy that key onto smartphone (Apple needs to add flipper zero's tech to iPhone) for easy keyless access.
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
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.
> 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.
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.
The encryption only needs to happen when button is pressed, and I am pretty sure the radio energy consumption will be much higher that CPU one.
Airtags transmit much more frequently than car remotes, use similar batteries, and yet do proper security.
Modern keyfobs keep listening and transmitting all the time, as you no longer need to push a button. Just get close enough to the car and it opens.
> (with whopping 32 bits of security!)
Ha! DVDs at least had 48 bits. /s
Proper security doesn't need to be perfect security. In the case of car manufacturers, most of their fob implementations are borderline negligent.
The reason these vulnerabilities affect many brands is because they don’t use cryptography. They buy these electronics from other suppliers.
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.
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.
No doubt they would charge $100 or more for just clicking a button and having the equivalent of an NFC writer.
Well they don't call them stealerships for nothing.
I wonder who make more money on this. The car dealer or the manufacturer.
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.
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.
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..
You can have strong cryptography + ability to self-pair. See bluetooth or wifi or zigbee or many other technologies..
Maybe the car manufacturers should just give up and adopt BTLE. Proper security, and you could unlock with your phone.
What does? The article is very unclear about what exactly this does.
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.
> 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.
It's not like the systems they used for physical keys were ever very robust either.
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).
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.
If only almost everyone carried a computer with a radio and local storage and a good battery with them almost everywhere
with a battery life of two years? and durable against going through the washing machine?
If you want simplicity and ruggedness we should never have moved away from steel keys.
Very few keys are made of steel. Brass is the most common material.
The problem with brass is that it wears away and the small shavings of metal gunks up the lock mechanism.
Mercedes used steel keys to avoid this.
> Cryptography is actually difficult for the requirements of a key fob.
No, it's not.
> The next obvious set is along the lines of "device sends an encrypted counter, door enforces that the counter only goes up"
That's already how rolling codes work. Running a strong crypto algorithm (even Ascon/Speck would be fine here) requires negligible power.
The issue is that this system is still susceptible to jam+replay attack. An attacker can jam the transmitter signal, while recording it at the same time. The user assumes that the button press just didn't register and tries again. The attacker also jams this and records the code. But then the attacker replays the _previous_ code that they stored, keeping the latest code for their future use.
This can _also_ be fixed with a simple capacitor-powered timer circuitry, charged during the keypress. The device can stay completely inert at all other times.
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
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.
And tend to get stuck in their ways like a container ship stuck in the suez canal
[dead]
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??
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.
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.
You can be sure that this attack has been well known to intelligence agencies for a while.
Who needs an attack when you've got backdoors and secret courts?
Jokes on them, I lost my key fob years ago.
Why isn't a link to the repo/firmware the first link in the article?
cool, I needed a new car, thanks
Pretty sure you want an old car to avoid this one. A bicycle would also avoid it.
Unless you're my son who has to buy a new bicycle lock every month because he loses his bike keys.
Get your son a key ring with a chain and make him attach it to his bag or his pants somewhere.
Combo lock
[dead]
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?
This attack lets you use all the functions of the key fob, and not just the action captured.
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.
Its flipper zero performing this
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.
which slide suggests this? i didnt find anything suggesting you could start a car with rollback
Bricks attract lots of attention in busy parking lots. An unlock chirp, removing some bags, and walking off will appear legitimate to bystanders.