4 ms·

CAN message usually has max 8 bytes, how would you sign it to actually transfer some useful data and without signature being laughably simple to crack?

londons_explore 4y ago
You can send the command and signature split over multiple messages. It is already common to tunnel other data over CAN with this method.
- TheLoafOfBread 4y ago
  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.
  - anon4242 4y ago
    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.
    - TheLoafOfBread 4y ago
      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.
      - anon4242 4y ago
        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.
        TheLoafOfBread 4y ago
        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.
        labcomputer 4y ago
        > 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.
labcomputer 4y ago
Besides what others have mentioned: 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.
- salawat 4y ago
  >Let the door controller start rate limiting (ignoring messages) after 10 bad attempts, and then only listen to one code per second. 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.

londons_explore 4y ago

You can send the command and signature split over multiple messages. It is already common to tunnel other data over CAN with this method.

TheLoafOfBread 4y ago
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.
- anon4242 4y ago
  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.
  - TheLoafOfBread 4y ago
    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.
    - anon4242 4y ago
      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.
      - TheLoafOfBread 4y ago
        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.
        labcomputer 4y ago
        > 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.

labcomputer 4y ago

Besides what others have mentioned: 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.

salawat 4y ago
>Let the door controller start rate limiting (ignoring messages) after 10 bad attempts, and then only listen to one code per second. 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.