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.
As long as you have two-way wireless communication (which any keyless entry/start system does), then you can simply do a Diffie-Hellman key exchange during the pairing process.
Diffie-Hellman is designed for exactly this usecase, allowing two parties to derive a shared secret key over a public channel without exposing it.
A one-time out of band authentication (usually some form of trusted physical interaction) is key if you don’t want to trust intermediaries.
It'd instantly mean there is 0% chance of someone figuring the key based on day-to-day operation.
Not if seed with appropriate length is used. Though I don't know how common that is, back in 2008 authors noted that "We would like to mention that none of the real-world KeeLoq systems we analyzed used any seed" (https://www.iacr.org/archive/crypto2008/51570204/51570204.pd..., section 4.3)
KeeLoq is also used for garage door openers.
Some KeeLoq receivers have a "learning mode" where it adds the next KeeLoq transmitter it hears provided it uses the same manufacturer key.
Learn mode is activated either with a button often on the PCB or with a "master" transmitter.
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.
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.
I don’t think this is true, for instance how does the key fob trigger a start sequence for vehicles equipped with remote start? They must be connected to the same CANBUS, so the key fob can interface with the start systems. This is also how a lot of vehicles are stollen, because of abuse/misuse of CANBUS (i.e. headlights being addressable in CANBUS)
> This is also how a lot of vehicles are stollen, because of abuse/misuse of CANBUS
On vehicles with poor cryptography architecture (Honda!), yes. On most other vehicles, no, because the immobilizer messages are cryptographically authenticated, usually by using an AES MAC where the key must encrypt random bytes transmitted by the immobilizer master using a shared AES key, and all participating immobilizer modules use a similar system to verify that every module shares the same secret material. Now of course if this secret material can be extracted the system breaks (see XHorse, Abrites, etc.) but this usually requires invasive and time consuming attacks far beyond the headlight thing (for example, removing and physically opening a control unit to use an exploit to dump its key material).
It’s also worth noting that European makes in general tend to have much
better cryptographic key security.
Counter point:https://www.usenix.org/system/files/conference/usenixsecurit...
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.
>The old approach of keyfob to unlock the car and a real key for the ignition is safer.
"Safe" feels like wrong word to use here. Safety is not same as security.
One could also argue that criminals being able to steal parked cars is safer over all for society as they then don't feel the need to car jack you while you are actually in the vehicle.
If you actually want to keep your car secure (meaning criminals wont break into it or steal it in this context) just drive old beater and do not leave anything valuable in the car or trunk. I am driving a car that is nearly as old as I am and its fighting a losing battle against rust and I have nothing more valuable than trash inside the car.
Here in the UK vehicle theft reached an all time low in 2014. It’s doubled since then. If there was an increase in car jacking it must have been minescule by comparison. It’s not really a crime that happens here.
I had an old beater van that got stolen. It turned out that model was known to be easy to steal. I suspect most car theft is done because it’s easy and fairly low risk. Walk up to a car in the night, fiddle around for a few minutes and drive off.
I still drive a car with a key. It’s completely fine. Who actually asked for keyless entry?
Me. I have problems with short-term memory and I kept forgetting my keys in the ignition.
This isn’t due to laziness or lack of trying. It’s a hardware problem that makes developing or following habits in certain situations nearly impossible. It’s like asking a blind man to organize things by color.
Now that I don’t have to take my keys out of my pocket, I’ve never left them in my car.
Probably the vast majority of consumers?
There is no reason why keyless entry cannot be more secure than a physical key, other than incompetence.
The cars stolen in New Zealand are usually, as you say, cars that are known to be easy to enter and drive away. Even then, they break a window. But I have also heard of break-ins at night targeting certain high-end cars and going as far as gaining entry to a garage.
Almost everyone?
It's one of the best feature I have in a car, the most convenient one.
I didn't ask for keyless entry, but I LOVE KEYLESS ENTRY!
Stealing a car is not the same as stealing a candy. In Europe all parts are marked so it takes significant effort to sell or modify such cars. It's not like people steal them and then sell it at yard sales.
As for the "beaters": shortly after Russian invasion on Ukraine plenty of cars were stolen in Poland. Not the expensive kind but usually 10-30 years old cars with big and reliable engines (V6, V8). I know 6 people that had Jeeps Grand Cherokee stolen (different generations).
My uncle wanted to renovate Isuzu Rodeo with completely rusty frame but V6 engine of a value of like 300€ and it was stolen too.
And it happened ~1 month after it started.
This is the same in the US, at least for the expensive parts. They won’t part it out or even sell it in your country, it gets shipped out to another country where your laws don’t apply.
https://www.krqe.com/news/crime/teen-given-max-sentence-afte...
One could also argue that most people didn't bother because violent crimes are much more severely punished, now that the bar is so low people steal much more. And the stats would back it up
https://images.vivintcdn.com/global/Blog%202022/01-Number-of...
So a bad person can just open your door and attack you because you can’t lock your door when your key is inside?
My Camry has incar fob detection and I can definitely lock the car while the fob is inside.
Adding in a stick of metal that can be trivially bypassed does nothing to make the car more secure.
Everyone can use a flipper zero to unlock a car. Not everyone can hotwire a car. Keyless ignition means criminals have a vastly larger recruitment pool of people they can offer money to do something stupid (like stealing a car for them).
Isn't it the same for old style key, but with even more actions? Like to navigate a keyhole, turn the key...
It’s especially nice when the key is my phone. I never have to worry about keys. I just get in my car and drive, and when I arrive I get out. I keep a key card in my wallet as a backup in case my phone explodes.
Hyundai and Kia have joined the chat
However, that wouldn't help with the "desyncing" or unlocking aspects of this attack.
It was a circular key below the steering wheel.
Not every problem needs a tech solution.
Of course, they wrapped it in some nerdy terminology, which IMO obscures the intent of their suggestion.
ok, if you mean a key that has a chip embedded, where the key cuts are just window dressing and the real magic is still in cryptographic proof of "something you have". i am not aware of any such key ever being produced, but i certainly do not have comprehensive knowledge. GM had something close to that.
Maybe never introduced into the US market? Would find that hard to believe.
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.
You could even take it a step further for extra safety: the door handle could have a slot that requires a specifically shaped piece of metal to be inserted. Only a piece of metal with the correct shape would allow the lock to be opened.
This has been attempted but unfortunately this algorithm is vulnerable to the #ScrewdriverHammer attack.
This would be very popular in East Asia. They love everything that beeps. Rice cookers play a melody, pedestrian crossings play a melody, garbage trucks play a melody. Japan is the country of beeps.
Yep, that's the simplest fix. Key is required in the door to open/unlock.
You'd think too that a firmware update to the car could enable that behavior. I mean most cars still have a physical lock on at least the driver's side door as a "back door" to getting into the car if the fob is non-operational.
This is exactly the benefit of the free software, and why having your own ability to fix, recompile and reinstall the software, is essential, even on things such as cars where you may think it's not needed or is too complex to handle.
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.
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.
Why is there so much politicatization and bait click of dark web stuff, it's still internet.
It's literally being sold on dark web. People call everything "dark web" but this time it's correct.
It's odd to throw in the dark web, thousand dollar firmware bit when third-party firmwares are developed in the open and have long ago already implemented KeeLoq, but I guess they aim for sensationalism and shock value.
Of course Storm argues that Tornado Cash is decentralized, but you can't just start a mafia branch, hand out free shares at the mall, and then claim that you actually didn't commit any crimes because you have 10,000 other voting shareholders.
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?
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.
I don't know the details of the attack in the article, but my speculation would be that it would be vulnerable.
Take the car while they are in the store.
The real cost will be in the software validation and road safety hardening, but there's no reason why the ROM size should be limited to kilobytes.
You can implement full passkey cryptography on a basic esp32 (https://github.com/polhenarejos/pico-fido). Cut out the cruft and you can definitely get a similarly secure algorithm on an actual car key or key receiver.
And honestly, with cars now unlocking over Bluetooth and WiFi, standardising that process to something like FIDO wouldn't even be that awful of an idea. It certainly beats the "we can do cryptography at home" many car manufacturers seem to be going for.
And there were a few years this seemed onerous, but most of the time, there were popular attack in use by car thieves that were prevented (or at least made much longer and more complicated) by this.
Chrysler, Dodge, Fiat, Ford, Hyundai, Jeep, Kia, Mitsubishi and Subaru
I’m curious why these and not some other major manufacturers like:
* Chevrolet
* Toyota
* Honda
* Nissan
* GMC
Does anyone have additional insights? Perhaps they just haven’t tested enough manufacturers yet? Or perhaps some manufacturers use a different technology that isn’t vulnerable to this type of attack?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.
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.
The left, right, left, right part I can see, but surely up, up, down, down, would be difficult on most steering wheels :)
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
If you're doing the "fingerprints implemented as a webcam" or software based facial recognition from a shitty webcam, you're risking quick and easy bypasses. Still good enough for a computer you leave at home (as long as you don't need to protect yourself against shady law enforcement) but definitely not that secure.
From what I've been able to gather online, nobody but Apple and phone manufactures seem to care much about actually doing biometrics securely, including the biometrics hardware companies. It's such a shame because it's definitely possible to do better.
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).
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.
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.
The rx enforces the sequence goes up.
You press button to open. Attacker lets the first sequence go through and the door opens, while the button is still down the attacker jams your second transmission while capturing it themselves.
Now they have a code they can use to open again when you're not around, assuming you don't use it again in the meantime.
If you wonder how vulnerable systems keep getting deployed without it being malicious, you don't need to look any further than the nearest hotshot that thinks everything is "not that difficult" and that everyone else is incompetent.
Security of any kind is just hard. The defender must defend against any possibility while the attacker needs just one vulnerability. How much cost and range and battery life are worth losing when the attacker can just punch through a window with their fist?
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.
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.
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.
I have a "smart" BMW car key and it inhales the battery. I don't think it can go more than a couple of weeks without having to be charged.
I don't really like the idea of short term key batteries, but it sounds like bmw can improve the current system a lot.
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
For this project let's say
Feels like getting rid of the light switches in your house in favor of "smart home" stuff.
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.
Also, smart people wire their smart home so that the light switches still work. If a smart home controller or some other part of the system fails, people still want to be able to control the lights manually.
Keyless start is a different thing, and uses a different wireless system.
I also have a smart home ;)
One of my older (collectible) car has various anti-theft helpers, including trackers. I also remove its steering wheel (easy, no airbag). Then I disconnect the battery. But then my favorite on that car is a kill-switch I had installed on the fuel pump: it's hidden and you flip the switch, car stops instantly. That one if thieves want to steal it they either have to come with a steering wheel, find the trackers, find the switch, hook up the battery or come with a tow truck (they'd still need to get rid of the trackers though).
But yup I'd like to know if there's a simple fuse-switch DIY that's non destructive: basically something I can remove and put back the regular fuse and the car dealership would be none the wiser that I used one.
Anyone know of such a thing?
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.