and how did we end up in this situation?

There is a couple of wires inside your car which control many car components, from lights and signal to trunk, ABS and even brakes. This couple of wires is called “CAN bus”, CAN meaning Controller Area Network. Access to this bus by hackers gives them significant control of the car, and as has been shown in recently published car hacks, this is possible, and has been done.

At the source of the hack is the fact that CAN bus has no security, and anyone with the ability to intercept and inject messages can take over the car. Therefore right after reading about those hacks, many people who are familiar with security but not with car manufacturing process, often ask this question: why does the CAN bus is so insecure?

In this article I will try to explain, why CAN bus evolved this way, and what are security challenges to secure it.

Before the CAN bus

Imagine you are creating a new car prototype, and need to design the wiring for it. On the rear of the car you have several electrical components. Each of those requires power to operate, which is carried by the electrical wires. Most components can operate with only one power wire (car body is metallic and could be, and is often used as ground, so only the positive terminal need to be provided). However since each component needs to be powered separately – you do not want your stop lights blinking together with your turn signal – each of them still requires a separate wire.

So let’s look at the mandatory rear electric accessories in a car:

• Brake/stop lights. There are two of them, but both could be controlled with a single power wire;
• Parking lights (same as above);
• Rear / backing up lights (same as above);
• Turn signals. Now we cannot control both of them with one wire, so we need two wires.

So we got total of 5 power wires, which is minimum for a car. Those five power wires have to be routed from the control panel of the car in front to the back, and each of them must be quite solid – a 12W lamp would draw 1Amp, so a pair of stop lights could draw 2 Amps.

Now consider that many cars have even more electrical components at the back. There could be a trunk electronic lock, a liftgate, parking sensors or rear window wiper. There could be parking sensors, and the ABS sensors and brake controllers on the rear wheels are also on the back. Same goes for the tire pressure sensors on the rear wheels. The number of wires going from front to back quickly increases, making it hard to find more space for them. Each model requires a different number of wires based on components.

Housing all those wires is not an easy task. Those wires control important functionality (such as brake lights), so they have to be reliably protected from the environment. At the same time they have to be accessible enough so the service could replace them if necessary. There also must be room to accommodate the extra wires if the marketing decides to add one more device.

So one car manufacturer thought, instead of many power lines, why not we just run one power line capable to run the maximum combined load? This is easier (read: cheaper) from the manufacturing point, and it is more reliable. To control them, we can run the number of low-power wires which would trigger relays on the back, which in turn turn the power to the accessories.

This only solves half of the problem. Yes, we would have a smaller number of thick power wires, but we still have the same number (in fact one more) total wires, and we still need to add more each time we add a new electrical component.

Parallel to serial – CAN bus is born

This problem has exist in electronics industry for a while, and has a known solution. The scenario with many parallel wires, each controlling a single device, in electronics would be a parallel data connection. This connection can be turn into a serial connection. This means instead of having 8 “data” wires (even though they carry simple on-off signals), we can have a single “data” wire and use a serial wire protocol to control the devices. So when we want to turn on the stop lights, instead of powering the line #6 we issue a command on a serial line saying, “#6 on” followed by “#6 off” when we need to turn it off, such as on the plot below:

  An example of basic serial communication. The first pulse makes the start of the sequence at the fixed clock rate, and the whole sequence is 4 bytes, the first byte indicating whether the light is on or off, and the following three is the light number in binary. The last pulse indicates the end of sequence. Of course, the real CAN bus is much more complex than that.

More, this control line could be used for the devices sending the data back, such as tire sensors sending something like “pressure at right-back wheel is 35MPa”. This is what essentially makes the Controller Area Network.

Of course now this command cannot be wired directly to the accessory. Instead the manufacturer puts a small CAN controller at the back of the car, which is connected to the bus, receives the data and then routes the power to the accessories when needed. This allows the manufacturer to reuse the old accessories which are not CAN-aware. New accessories could be built CAN-aware, simplifying the connections.

CAN (lack of) security

Now we get to security. When the CAN bus was introduced, securing it made little sense – it was just a wire running somewhere under the hood, so anyone with access would hijack the wire the same way they could hijack the ordinary wiring; CAN bus actually makes it more secure as now the attacker couldn’t just rip the wire off and connect it to the battery like in movies – they would have to know and implement the wire protocol, which is significantly harder than shorting a wire. So this early implementation was pretty secure.

Things however quickly start changing when the car manufacturers started putting more and more devices on CAN bus, such as ABS, A/C control, volume control, and so on. Many of those controls are distributed – for example, the sound volume on a modern car could be changed from several places (such as the steering wheel and the knob), so putting the volume control on a CAN bus, and have the single logic receiving “change volume” commands made sense. Now the bus is being used for sensitive, potentially dangerous things, however at this moment it was still self-contained. One would still have to get physical access to the car to access the bus, and it was pretty isolated from the rest of the car. But not for so long.

Introducing car multimedia centers

In the early era the car “multimedia center” was a stereo, typically developed by a 3^rd party and which only had a connection to car power and speakers. However at some point someone decided that connecting them to CAN would make sense. First, this made implementations of multiple control sets (such as mentioned above independent volume/channel/AC/fan controls on steering wheel) easier, as the multimedia center now doesn’t even have to be aware of how many control knobs the car has – all it cares is to lower the fan speed when it receives a “fan down” CAN message. Second, it could now use some information from CAN itself – for example, the multimedia center can use the current car speed to help the navigation module, can show the external temperature or tire pressure, and so on.

This was already drifted to the land of dangerous, as those multimedia centers are typically developed not by the car manufacturer itself, but by third parties. Such third party typically sells their devices to multiple car manufacturers, but the customization typically is only related to the firmware, and rarely to the hardware itself.

Connected media centers

Now we have an insecure but powerful CAN bus, and a third-party multimedia center connected to it. All was needed to start the trouble was opening this multimedia center to Internet – and this happened. Now everyone who breaks into the multimedia center gets some kind of access to the CAN bus, and this is something the developers of multimedia centers probably never imagined.

I have stated in my previous article that companies building their first connected device often tend to underestimate the threat level of their device being hacked, and envision the amount of harm it would make. Some honestly believe that it is only banks, Pentagon and CIA should be worried for hackers, and nobody would waste time trying to break into a simple car MP3/radio player which offers Wi-Fi. What they fail to understand is that every connected device could be viewed as a gateway to the network, and for example a simple MP3 player installed on a nuclear plant, which is connected to some local Wi-Fi but also streams music from Internet, if hacked, becomes a gateway between Internet and this otherwise private network. Same here, the insecure multimedia center, once broken into, becomes a gateway to the otherwise protected CAN network, which then could be attacked directly.

Ok, let’s make it more secure!

The simple security solution, of course, would be to make the multimedia centers secure enough, so they would not be hacked. This is however not an easy goal. As stated in my prior article, even the seasoned software engineers developing Internet-faced software sometime have bugs; but for the engineers who do not have such prior experience and did not experience the hostility of the cruel security world, the chance to screw it up is much higher.

So far the proposals been the following.

Implement the security on the multimedia center

One company got funding for implementing what looks like a traditional whitelisting technology, which allows only certain whitelisted binaries (or signed binaries) to run. This approach however seems to be misfitted for this environment. It is suitable for the more open environment, where a user has control over the machine and is able to install new applications. In an environment where no new applications could be installed – such as a typical multimedia center on a car – typically an intruder breaks in through security holes in the existing applications. This is also how whitelisting types of solution are broken into as well – a bug in otherwise whitelisted Microsoft Word, Internet Explorer or Adobe PDF Reader is exploited through a crafted document, and since the documents cannot be whitelisted (due to unknown content), whitelisting does not protect against the exploit at all.

Notably, if we look at three car hacks, NONE of them could have been prevented by whitelisting. This is even assuming that the whitelisting system is secure itself, and couldn’t be disabled.

Implementing CAN authentication

Another discussed approach is to add authorization on CAN bus, so for example a brake controller would ignore the braking signals which do not come from an ABS module or brake pedal. Thus even if an attacker breaks into the multimedia module and start issuing CAN signals, they would be ignored.

Unfortunately implementation of this authorization would not be an easy task. An easiest solution would be to use something like a private key cryptography (and store a copy of a key both in sensor and brake controller), but even this would require major changes in otherwise simple CAN modules. For example, a more powerful CPU, and a Flash/programmable memory would be required on CAN controllers. Also the device deployment and replacement gets more difficult, as each vehicle would use a unique key which have to be securely generated, and stored somewhere else so they could be programmed into the replacement parts. More, the multimedia center itself would have a copy of the key – as it needs to decode some messages – and being private key, the same key could be used to sign the messages, making the security obsolete.

What about using public key cryptography?

The last issue could be avoided by using public cryptography – the CAN data for the multimedia center could be encrypted with a private key, and multimedia center would have a copy of a public key, which would allow it to decrypt the data, but not encrypt any CAN data itself. However public cryptography requires much more processing power to perform due to the size of the operands, and is very computing-expensive operation, and since it has to be performed very fast in cases such as ABS controllers, this would significantly increase the cost of CAN sensors.

Other concerns

Both solutions present above also suffer from the replay attack. An attacker who can listen to CAN messages, doesn’t even need to have a copy of any key, he can just listen to brake controller messages (guessing heuristically or experimentally when they are generated), recording the message as a sequence of bits, and replaying it later as-is. To work around this issue, the TLS-like protocol involving 3-way handshake with challenge is required, which makes the controllers enormously complex.

Conclusion

The reason CAN bus evolved this way was not the result of oversight or some kind of conspiracy. It was natural evolution of a closed system. And security is rarely part of such evolution. Unless the initial design plans for security, it is very hard to bring it in – and sometime plain impossible.

So does it mean nothing could be done? No, there are possible solutions. However the bus itself would likely stay as it is now, and the solutions would work on protecting it.

About me

My name is George Yunaev, and I’m a senior software engineer with over 20 years of experience, focusing on security and SDK development. I’ve been working for the anti-malware companies for the last 15 years. Here is my resume.