Why does the lights need a can bus connector nearby?
No serious company put an ethernet port outside the building or use a wifi without encryption.
I wonder what lunatics are this car designers/manufacturers .
I think the light can also report a failed lightbulb to the dashboard.
Any message sent to a security critical part of the car (eg. the door locks) would be signed by the ECU. The signature would use the current date/time as a nonce to prevent replay attacks. The signing certificate would be pre-programmed in at the factory.
Now anyone can say malicious things over the bus, yet still can never unlock the car.
ECUs are already tightly paired with immobilizers and dashboards, so they already need to be swapped together. Let's not do this with other parts which frequently break such as lights, locks and windows, please.
Once you replace the key fob, you must reprogram your engine ignition.
What prevents a thief from reprogramming the engine ignition for some other key? The same thing that prevents the thief from starting ignition manually: it's buried in the car. Notice that in this case, thieves rely on CAN buses running in easily accessible places.
If the thief can access your car's ignition directly, you can't stop them anyway.
Reprogramming of 2nd hand components to a different vehicle might also be possible, but using some procedure which is hard to do from outside the car. For example, short two pins on the back of the lock.
So basically I need to pretend to be a new part to steal a car. Some common key as an attack vector.
I guess the attack vector would rather be some unscrupulous mechanic replacing the part with a bogus one that would accept every unlock command, and the thief, in cahoots with said mechanic, would show up and unlock the car once the owner got it back from the shop.
- Open a hood
- Connect new, unprogrammed ECU (no immobilizer loaded)
- You can now start the car without chip in your key
As I see, people are reinventing wheel here, and are creating same problems as OEMs did 10-15 years ago.
My dad used to have a Citroën that would require taking out the whole front bumper assembly to change a freaking light, so it would be beyond stupid to have the ECU easily accessible...
ECU is on the right side in plastic cage next to a battery.
To get into the car thief will use a relay attack on your key, so no damage to the car will actually occur.
That ECU swap happens only if you have car with keys. If you have keyless car (start/stop button) then you can relay your way into starting engine.
Of course, they seem harder and harder to come by for some reason...
However even mechanical token can be generalized as this video shows: https://www.youtube.com/watch?v=9NtDH-8z95M
So I think that in the end it probably does not matter. When somebody wants to steal your car, you have probably no chance to prevent it.
1. They're already in the car. So how you authenticate the ECU and door modules to each other is really irrelevant. They bypassed that already.
2. They can just go ahead and replace the ECU and all the door modules with their own. So, again, how auth works doesn't matter.
3. At some point, you have to ask: Am I replacing the electronics in the car, or am I replacing swapping all the non-electrical parts from one car to another?
Each device that needs to sign messages (which probably should be only the ECU) is provisioned with a certificate signed by the carmaker. The device is also provisioned with a public-key pair, which is signed by the certificate (so you have chain of trust back to the manufacturer). The public key pair could be either programmed when the firmware is first flashed or generated at first boot.
A new door BCM accepts the first broadcasted public key from the ECU which is correctly signed. This would happen inside the factory for a new car, or when a new BCM is installed to replace a faulty one.
A used door BCM from a junk yard car could be programmed to accept a different (signed) public key by:
1. Being in the unlocked (and perhaps window-down) state; and 2. Pressing some combination of door buttons; and 3. Sending an appropriate command over the CANbus
It, of course, then verifies that the new key is correctly signed and reprograms itself to the new key.
The signing key would of course be unique per ECU/keyfob that needs to sign stuff so dumping another ECU doesn't help you crack it.
Loading a new private key from the server? Well, thief's device can probably pretend to be a server and load a new private key into the control unit behaving as a master of immobilizer. Then the thief will get car and instantly new set of keys.
Erm... using the LSB of a network RX timer is common way to add entropy (and perfectly feasible here). You could also use the LSB of the +voltage rail sense or the thermometer that probably exists on your MCU.
Just use a simple rolling code, like a garage door opener, HOTP, or the key fob itself, and enforce a rate limit for bad codes. 3 bytes can hold 6 packed digits, which is plenty.
The threat model here is that the thief walks up to your car and tries to broadcast messages to the door controller. If they can't observe prior messages to the controller, the chance that they will correctly guess the next code is, literally, 1 in a million.
Let the door controller start rate limiting (ignoring messages) after 10 bad attempts, and then only listen to one code per second. The thief will have to stand here for a week for a 50% chance of correctly guessing a 6 digit code.
Congratulations. Everyone is now potentially DDoS'ing everyone else's car, and all it takes is one a-hole with a gibberish screamer to lock everyone out of their cars within range.
You have solved nothing, and in fact, made plain old keys the more attractive alternative. I swear, people want to throw cryptography, radios, and security buzzwords at everything, but completely forget that the easiest way into the car will be taken. The tumbler lock. Once in there, hoods can be popped. Replace brain box. Move right along.
Btw it's "fun fact" and it typically means there is something factual, not just guesswork.