Why are so many car manufacturers incapable of using cryptography properly?
Good idea, don't know how effective it is in reality.
I cannot think of a better word to describe the process. The ritual may involve some chanting. Thank you for that :D
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
Saves money on password management.
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 :)
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.
Ha! DVDs at least had 48 bits. /s
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.
Airtags transmit much more frequently than car remotes, use similar batteries, and yet do proper security.
I've become a big believer in leveraging some security features of the physical world, as it seems it's been long enough that everyone's forgetting Therac-25-style problems. (Or, perhaps more accurately, nobody cares because they aren't liable.)
Modern keyfobs actually detect motion and if they are motionless for a while, they stop transmitting the signal to both save battery and prevent such attacks.
For old keyfobs, you can get a battery sleeve with integrated motion sensor which does the same (cuts power when fob is not in motion for a while).
Alternatively, some cars let you disable the feature and just use the keyfob as you would use an older one - then you habe to push the button anytime you want to unlock the car.
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).
Mercedes used steel keys to avoid this.
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?
As to the attack you reference. It's active and touchy to pull off. It doesn't particularly concern me but of course would be better if it weren't possible. To that end I'm not clear why there's a double transmission with two distinct and independently usable codes? What am I missing?
I thought the attacker jammed, recorded two user attempts (ie two distinct button clicks, neither being permitted through initially), then rebroadcast the first attempt while retaining the second for later.
> The rx enforces the sequence goes up.
Except that there's apparently a rolling window to support recovering from desync. Which to me sounds more complicated and error prone than a simple nonce that can only ever go up.
Really though the manufacturers ought to (IMO) accept the extra dollar or five on the BoM that it would take to get proper two way communication.
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.
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.
Then anytime you misplace your keys, you can look at a map on your phone and it will show you where to go.
The map thing when you're nearby and it goes into the sonar-like mode is super cool. Especially combined with the ping noise.
I travel a lot for work and always take a pic of my parking space number. A few weeks back I forgot to, realized I forgot before I got in the security line and was like.. nah, I won't forget on a short trip.
When I got back later that week I walked the entire floor of the garage, about 25 minutes.
I also have a problem with thinking of wise places to leave something and then it is gone forever unless I dig through 75% of everything I own. After I find it I am reminded of what my thought process was.
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.
I don't think anyone will be surprised if the security is swiss cheese once you pop the hood open or bust a headlight out. Keep in mind that a brick to the window and tearing up the center console will get you physical access to the head unit on most vehicles.
1. Initiate pairing via the entertainment system interface.
2. Use rolling codes. Don't allow rewinding the codes.
3. Add a tiny tiny bit of non-volatile memory in the keys so that batteries can be changed without breaking the key. This is only necessary if the car can't be entered using the physical key, otherwise the user can just open the car with the physical key, turn on the ignition and re-pair the key.
I could make a secure system to do this and I'm no crypto genius. (Note this would still be vulnerable to rolljam but that's not a very practical attack, and defeating that is a bit difficult.)
To support car hire/share places if they want to prevent users pairing new keys you could allow setting a password on the pairing interface.
> KeeLoq is a proprietary hardware-dedicated block cipher that uses a non-linear feedback shift register (NLFSR).
Pretty much any proprietary encryption algorithm is going to qualify as "rolling your own".
"Not the most modern" is a gross understatement.
I can forgive the original authors since it dates to the 1980s and AES wasn't standardized until 2001. (Only just barely though given that DES dates to 1977.) I can't forgive vehicle manufacturers that are _still_ using it (or things significantly like it) 25 years later.
I hope that products manufactured post 2005 use strong publicly available cryptography. After 2010 I fully expect it. After 2015 I view any failure in that regard as gross negligence that ought to be legally actionable.
> it's just fundamentally possible to pair a key with physical access which is easy to get.
I don't follow?
It came out of a university and was acquired.
> I hope that products manufactured post 2005 use strong publicly available cryptography.
A lot of the challenges are related to key pairing and relaying of wireless information in combating with jamming. It’s a tricky thing to secure given the circumstances.
> I don't follow?
Cars stand around 99% of the time and easy to get into. pairing protocols assume that physical access is restricted / not possible. That’s why it’s so much harder to secure car key pairing. What would make it more secure is delegating the security to a remote service which is secured. Eg: what Tesla does with their keys.
> It’s a tricky thing to secure given the circumstances.
You are hand waving and you are wrong. If you are going to make claims then be specific and make solid points. The various algorithmic solutions are simple and common knowledge these days. I went into more detail in adjacent comments.
By your own logic the physical entry key isn't secure either. After all the car is just sitting around - anyone could jimmy the lock. Similarly all it takes is a decent photograph or two with a telephoto lens to reproduce your typical physical key that will get you in the door.
But all of that is entirely off topic. The broken and outdated wireless algorithm has nothing to do with the criteria used by the vehicle to decide whether or not someone is authorized to enroll or revoke a key. Tie that to possession of the physical key and problem solved. If you can't drive off with the vehicle then you can't pair a new fob either.
Honestly I'm not really sure what you are trying to get to. If you think this is a solved problem, it's really not. [1]
> The broken and outdated wireless algorithm has nothing to do with the criteria used by the vehicle to decide whether or not someone is authorized to enroll or revoke a key. Tie that to possession of the physical key and problem solved.
It has something to do with it in the sense that key pairing that just requires physical presence through the key is susceptible to rolljam type attacks. Likewise the NFC attacks against Tesla also involved enrolling a new key on the car via a relay attack to a present NFC key. You're saying this is so easily solvable, yet time and time again it's shown that this is just a really hard problem to solve.
What's the earliest reference to this attack you can actually provide?
RollJam is known since 2014 [1]. It was popularized later through a custom device [2].
[1]: https://spencerwhyte.blogspot.com/2014/03/delay-attack-jam-i...
[2]: https://www.wired.com/2015/08/hackers-tiny-device-unlocks-ca...
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.