Analysis of CAN Architecture

In 2016 there were 261.8 million cars registered as they are a pivotal part of the economy and peoples’ everyday lives. Cars were once all mechanically made with carburetors but after development of technologies cars are now running off of fuel injection. The difference between the two is that a carburetor controls fuel flow with mechanical bits that allow a certain amount of fuel to mix with air to go to the cylinders and fuel injectors use a pressurized rail system controlled by a computer with carious camshaft and crankshaft sensors.

In the 1980’s cars started using computers called the Engine Control Unit( ECU’s), which control basic main engine functions such as airflow, fuel and spark. There are ECUs in every car on the road today because with a computer and a set of sensors, the ECU can dynamically tune the car live, increasing performance and lowering emissions. Cars do this with various sensors including Mass Airflow Sensors, temperature sensors, O2 sensors pre and post catalytic converter. The problematic issue arises from the fact that we went from computerizing basic components to computerizing everything. To understand the issue, look at the diagram below to go over some of the things that a typical ECU has control over.

Further increasing risk, cars now come with embedded GPS and cellular chipsets connecting the car to the outside world. With everything interconnected, it would not be hard for a hacker to gain access to the whole system through one point in in the system.

The way these components communicate is through the CAN bus. The CAN bus is a really bad system when it comes to security because everything is broadcasted on the CAN, requested or not. This is so when a component needs information from another, it doesn’t not need to request it, it is always broadcasting so its efficient. Can you guess why that’s a security issue?

I will now analyze the CAN architecture explaining its design flaws. The CAN protocol was developed because before it was released, every computer component had to be connected with wires to each other, but with CAN bus, everything connected to that central bus and it reduced the wiring complexity saving weight and money. Another reason for its development was for emissions control, and because data is always broadcasted on the CAN bus, the car can dynamically adjust fuel/air ratios to get the cleanest burn with the least emissions. The CAN bus is really good at what it is designed for, but it was never designed for security. The main security flaws that need to be addressed first are unencrypted traffic on the bus, lack of decoupling and segmentation and no authentication of devices. The major security flaw is the lack of encryption, but it was designed purposely like this. It was meant to be lightweight and encrypting data would go against that, especially in the 80’s when computing power was very slow. Today this is a critical flaw because the data can be sniffed. This would allow the hacker to sniff data packets, modify the CAN message and inject it back into the system. Another major flaw is the lack of decoupling and segmenting the CAN network. Since everything in the bus os connected to each other, it is possible to gain access to the whole system through something like the infotainment system. This could be devastating because new cars have electronic driven steering and ECU controlled brakes. The last main flaw is that the CAN interface has no authentication method for attached devices, meaning that a hacker can spoof messages and other parts of the ECU will react. For instance, if a hacker can spoof and broadcast a brake signal on the CAN bus, the brakes will activate without the drivers’ knowledge.

These are just some of the concerns I came across during my analysis, but has anyone exploited the CAN bus yet? The answer is yes and its been done multiple times by various research groups.

In 2010 researchers from the Center for Automotive Embedded Systems Security published a paper entitled “Experimental Security Analysis of a Modern Automobile”. They exploited vulnerabilities and discovered that it was possible to change a vehicle’s functions by injecting spoofed commands onto the CAN bus. They showed that an attacker could disable the brakes, the engine, and change the speedometer values (Koscher et al., 2010).

This research was dismissed by many because it’s very unlikely that someone would have a wired connection to the CAN bus. The team responded with a follow up analysis in 2011 with the diagram below. The electric bolts represent possible points of entry into the CAN bus system. Then put emphasis on “Telematics” as those are ways to gain access wirelessly, dismissing the media and automakers claims that a connection isn’t possible to a car without a wire.

more recently in 2015, Charlie Miller successfully exploited a Jeep Cherokee remotely and injected spoofed CAN commands, without making any physical contact with the car. This was groundbreaking as it showed cars could be hacked from anywhere with an internet connection. This was the first time an automaker had to take action, as the Fiat Chrysler Automotive group had to recall more than 1.3 million vehicles. Essentially what Miller did was that he exploited the vehicles infotainment system which governs media and cellular functions of the car. The cellular functions is what caught Millers attention because it gave him a remote way into the car. From there he discovered that the communications system had a microcontroller connected to the CAN bus! This was his point of entry, using this “door” he got access to everything connected to the CAN bus, which we now know controls the entire car since everything in computerized. To access the car though, Miller had to exploit the vehicles cellular microcontroller, which was supplied by sprint. All he had to do was port scan and find an open service port. According to sprint shortly after they patched this bug, any sprint device capable of 3g had access to this service port. Normally this port is entirely internal, but sprint did not make its scope private. Because of this bug, he used a 3G sprint device connected to his laptop to remotely gain access to the microcontroller and then the CAN bus. Just as we discussed in class, there is no perfect system and there is no single security solution. The recommended solution, although it might take a while to implement, would have to be encrypted data transmission, hardware backed or not; Device authorization protocols so outside devices can’t spoof CAN bus commands; And decoupling/segmentation of the CAN bus network. As professor Kathleen Fisher said, “the CAN bus is hopelessly insecure. it was developed decades before cars were connected to the Internet and lacks features to block malware programs or reject commands from unauthorized intruders.”