10

CAN (controller area network) is a bus used in all modern cars. You can read a lot of the cars information over this bus and I think (but I'm not too sure about this) that some critical control signals (breaks, e.g. for ESP?) get over that bus.

I know very little about the CAN:

Devices which communicate via CAN bus have to send their identifier before they start sending anything else. The protocol defines that devices with lower identifiers have priority. The protocol has a "dominant 0", that means if one device puts a 0 on the bus and another one puts a 1 on the bus, the 0 is on the bus. Devices listen all the time, including when they are sending. That means a device which puts its identifier on the bus which has a 1 at some position, but reads a 0 it knows that a higher priority device also wants to use the bus and it has to stop.

What happens when an attacker sends "0" all the time over the bus? For example, could it be possible to upgrade the software of a cars radio to put "0" all the time on the bus (see Comprehensive experimental analyses of automotive attack surfaces for many more sophisticated attacks) or are such low-level protocols implemented in a non-updateable way (e.g. hardware or ROM) so that such an attack could not happen? Is it possible to protect the bus against malicious devices / this kind of denial-of-service attack?

4

CAN is designed to be relatively simple and is often implemented between microcontrollers with very little processing power (that are busy doing stuff where timings are important), and is used to relay messages in real time. Adding some encryption and DoS protection would introduce too much complexity and given that it's just two wires shared by all controllers, I don't think DoS protection is even possible in this case (what are you going to do if a rogue device decides to flood the bus with garbage or continuously hold the data lines "high"?).

A partial solution would be to separate the network into multiple buses, like it's done in most (all?) cars, where a separate bus is used for critical elements, and gateways are used to relay specific messages between them. DoS on a single bus doesn't affect the other one.

It is indeed possible to reprogram the firmware of any controller :

evil software

There are even easy-to-use software and hardware for that. This particular screenshot shows a program capable of updating the firmware of engine controllers and instrument clusters, but I'm sure the same applies to all controllers, it's just that the demand for software capable of tampering with engine/instrument clusters is higher (for obvious reasons) than the ones capable of interacting with the airbag or ABS ones. I'm sure criminals are exploiting these flaws and it proves yet again that security by obscurity just doesn't work.

If you have the time to reverse-engineer the original firmware you can easily make your own malicious version, and all you need is 30 seconds of access to the car's CAN bus (via the diagnostic port) to install the new firmware. Of course, you can use the radio as an entry point (for example, by exploiting vulnerabilities in its MP3 decoding functions) to get onto the CAN bus and install malicious firmware on other controllers. The only security is obscurity of the protocol which decays over time.

Finally I don't think there is an efficient way of securing the CAN bus - encryption and authentication won't do much - it will indeed prevent intrusions on the bus (such as a rogue device connected to the diagnostic port) but won't prevent against compromising a device that's supposed to have access to the bus (like the radio) which would be the main entry point of an attacker.

About installing firmware, requiring a unique passphrase printed in the car's documents before any firmware can be installed is a good solution, it will prevent a compromised device on the bus from compromising other devices, while still allowing the legitimate owner of the car to tamper with the firmware if they want to (because having to pay 300€ and often more to the dealer to replace a lost key or reprogram an used controller is what I would call getting ripped off).

  • I thought an "intermediate device" developed by the car manufacturer could prevent this kind of attack. That means the access to the CAN bus gets controlled by a device between each "foreign" device and the CAN bus. This intermediate device would not do much. It would only check if the device sends its identifier and eventually if it sends too many packages. The intermediate device should have the possibility to cut the access to the CAN bus. Isn't that an efficient way of securing the CAN bus against this simple attack? – Martin Thoma May 8 '15 at 7:17
  • @moose you're talking about some kind of firewall. The problem is that if you can compromise a device, there's also a good chance you can compromise the firewall, and the gateway that connects different buses together already does this. Rather than developing such firewalls, car manufacturers should rather harden their firmware and use some real crypto instead of obscurity. That will also make the immobilizer an actually useful feature instead of something that causes extra costs while able to be disabled by a simple "immo off" button. – user42178 May 8 '15 at 9:40
0

Sending "0", thus, forcing the bus in a dominant state is an attack on availability. Consequently, every time another device wants to send, the bus arbitration algorithm tells it to back off. No message will get on the bus.

What is the consequence for the vehicle? When turning on the ignition, the security module and the Engine Control Unit (ECU) have to talk. If they can't talk, nothing will happen. If the attacker forces floods a bus at some point during driving, it is treated like a faulty bus. Fault tolerance will take care the the subsystem shuts down correctly and without hazard for the passengers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.