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?
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.
Good idea, don't know how effective it is in reality.
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 messages to interpret... but using the Konami Code on my steering-wheel to enable the ignition is within the realm of possibility, and almost certain to stymie the average thief.
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.
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.
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.
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.
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.
Take the car while they are in the store.
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.
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.
lq9AJ8yrfs•4h ago
[1] https://arxiv.org/abs/2210.11923 [2] https://news.ycombinator.com/item?id=10018934
IshKebab•2h ago
dylan604•2h ago