Hacker News Reader

Comment by TheLoafOfBread | Hacker News Reader

That's a nice theory, now let's look into something called CAN bus load - i.e. there is limited amount of CAN messages which you can ram onto a bus. So adding multiple CAN messages to transfer same piece of information will drastically reduce throughput of the system and make it unusable.

View on HN

Not a theory. This is used in vehicles today, for instance authentication for tachograph downloading. The key is of course you are not authenticating all the time, in this case it's enough to do when starting the vehicle when the CAN-bus typically is quite quiet.

If it is only on specific communication channel, then you just need to get a private signing key, i.e. by dumping same type of ECU. And we are back at the beginning.

I'm not sure whether you are confused or intentionally trying to be confusing but that doesn't make sense in the context of the discussed issue.

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.

That private key needs to be stored somewhere otherwise your singing scheme does not work. Generating signing key is not really an option as you won't get enough entropy on the ECU and generated private keys will be oscillating around small group of prime numbers.

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.

> Generating signing key is not really an option as you won't get enough entropy on the ECU and generated private keys will be oscillating around small group of prime numbers.

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.

Reply on news.ycombinator.com