Know the Vehicle

Introduction

Many of the significant challenges in vehicle cybersecurity result from the automotive industry’s unique characteristics. For example, a typical consumer vehicle has over 100 electronic control units (embedded microcontrollers) connected by multiple intra-vehicle bus networks. This lesson will discuss the various types of in-vehicle networks, their purpose, and whether/how they should be considered for cybersecurity protection.

The Cost of Wires

The wide variety of vehicle networks and protocols each have unique use cases depending on the requirements of the modules that they connect. Security has historically been an afterthought when designing a vehicle’s network architecture. Instead, automakers have focused on designing networks with sufficient reliability and data rate to meet typical use cases while, most importantly, lowering cost.

To give an idea of the scale of things, in 2021 alone, Toyota reportedly sold more than 10 million vehicles. If engineers leave only one extra meter of wire by choosing a protocol that needs more wiring, the excess length would be enough to stretch from New York City to San Francisco and back.

At this kind of scale, automakers aren’t just saving pennies. Choosing simple two-wire or one-wire bus protocols like CAN or LIN (see Protocol Primer for more details) can save millions of dollars over networking strategies like multi-wire, point-to-point Ethernet. For this reason, automakers need to think about the most efficient systems they can implement while still achieving their security goals. One of the ways they can do that is by segmenting networks based on their function.

Functional Considerations

Designing vehicle network architecture is a somewhat complicated subject. For the sake of keeping it simple, let’s consider just the following factors:

• Timing
• Bandwidth
• Reliability

Vehicle functions requiring reliable information and fast response time, such as driving operations (powertrain, transmission, steering), are often safety-critical, where delays in information exchange could mean the vehicle does not react in time to a dangerous situation.

Less critical functions such as seat adjustment, interior lighting, and volume control require less stringent reaction time and reliability. So these functions are generally placed on a slower and less reliable network.

A relatively new type of information transmitted on vehicle networks is multimedia data, such as camera or map data for ADAS systems. This high volume of data requires lots of bandwidth, and if there is a problem with the data’s timing or reliability, the safety feature can become a safety concern.

Real-world examples:

Steering wheel buttons

A modern steering wheel has several buttons, levers, and sensors. Some of these, such as the media controls, voice assistant controls, and infotainment interaction buttons, only use elementary interactions. While the system it controls may be complicated, the button bank controller only needs to inform the vehicle which button is currently pressed. In this case, using a low-speed, one-wire protocol like LIN to communicate the button state to a larger combo control module, such as the steering column control module or the body control module, makes sense. After all, these systems don’t need more bandwidth or super-critical timing.

Driver Monitoring System

Some newer vehicles with driver-assist features may incorporate monitoring systems like eye-tracking cameras. These may transfer video data, requiring much higher data rates than a button, and use a protocol like Automotive Ethernet. Ethernet uses at least two wires instead of the single wire used by LIN and will incur more cost to implement. Depending on how the manufacturer decides to network the vehicle, the Ethernet cable may run a few inches to a module in the overhead console, a few feet to a central gateway, or a few meters if the driver assistance system is located in the vehicle’s rear.

Steering

Guess another function on the steering column that needs to transmit more data than just button pushes but less data than a video feed. Steering angle! The data is simple; the wheel position and speed could be communicated in just a few bytes. But this data needs a quicker and more reliable network such as CAN or FlexRay because of its sample rate and safety implications. If you’ve ever watched a low refresh rate video or played a stuttering video game, you’ll know just how rough the experience is and how difficult it can be to control the game. This is the last thing you want to face in a drive-by-wire car.

Vehicle Network Layout

Before discussing known attacks on these different vehicle networks, let’s look at how they come together and serve specific vehicle functions.

Look at the diagram below and see how the demands of each system control which type of network architecture is used. See how the systems critical for vehicle passengers’ safety use a faster network type than systems designed for creature comforts or diagnostics (as discussed earlier, safety-critical networks generally need a speedier reaction time to changes and failures). Ethernet mainly connects modules that require high bandwidth and connectivity.

Let’s take a look at the components of the collision avoidance feature. To simplify things, let’s assume that the camera detects a rapidly approaching object, and the Emergency Brake Assist activates the brakes. As you can see, these two components are on different networks. They could not directly communicate with each other except through the Gateway in this diagram. In practice, there are many Gateway ECUs throughout the vehicle called Domain Controllers. In this case, the central ADAS controller takes information from all ADAS-related sensors (such as cameras and radars) and sends commands to control units to activate different driving functions, such as steering and brakes. The camera would most likely never have to send a message to the EBA or vice versa directly.

A gateway is essential for translating protocols between networks and performing logical processing. Still, it also serves as a great potential tool for helping secure a vehicle’s networks from attackers. Because it helps break up networks from one another, certain attacks will require more effort and knowledge of network layout and possibly even multiple protocols. However, gateways must be configured correctly to take advantage of this. A gateway that passes through all messages will not be able to prevent any attacks.

The most common example of a security gateway is the one separating the OBD-II diagnostics port from the rest of the vehicle network. This prevents access to critical CAN traffic by just plugging in through the OBD-II port, which is easily accessible. Another typical design is placing a security gateway between connected or easily exposed modules, such as telematics and infotainment modules, and the high-speed CAN bus, where safety-critical and driving functions are performed. This could prevent a successful attack on the more vulnerable modules from affecting safety-critical vehicle functions.

Attacks on Different Networks

Next, let’s take a look at a few successful attacks that have been performed on today’s vehicles.

Earlier, we discussed the uConnect Jeep takeover and then gave an overview of the complicated network bundle in a modern car.

In the case of the Jeep hack, the attackers took advantage of an open port in the cellular internet connection which allows unauthenticated remote code execution on the head unit (infotainment system). This allowed the attackers to control the radio volume and air conditioning. Using this feature, the attackers could further access deeper functionalities outside of the head unit by reprogramming another controller to send arbitrary CAN messages, which could command the car’s wiper, turn signals, locks, and driving functions.

Before they found the uConnect weakness, the hackers had to connect to the vehicle CAN bus physically. They were able to control the car only from within. Also note from these earlier attacks, Miller and Valasek were able to reverse engineer the seed-key unlock algorithms on multiple vehicles due to poor security design.

Another access point to the CAN bus is the OBD-II port, a federally mandated connector for collecting information used in emissions testing. On vehicles developed before cybersecurity became a concern, this port would allow reading and sending on the CAN bus directly without a gateway. At this time, insurance companies pushed customers to plug proprietary OBD-II dongles into their cars so insurance could collect driving data for"good drive" discounts. Unfortunately, these dongles were very poorly designed and allowed car owners to spoof conservative driving data and attackers to remotely take over and have direct access to the CAN network of the car.

Known hacks have been discovered through various external connections such as cellular, Bluetooth, Wi-Fi, and media USB plug-and-play. To demonstrate the seriousness of these hacks, researchers target the CAN network as it carries most of the safety-critical real-time information. Other intra-vehicle networks have been scrutinized, but they usually carry too little valuable information, or it is complicated to manipulate the data for desired results.

For example,

• LIN networks contain safety-critical information, but there is no way to access them except through physical disassembly or taking over the LIN master controller on CAN.
• FlexRay, the direct competitor to CAN, saw low adoption rates due to the high complexity and cost of development. While the data on FlexRay is not secured by cryptographic means, it is tough to spoof on a FlexRay bus due to its strict timing and rejection of messages not aligned with the communication schedule.
• Automotive Ethernet has plenty of IT security experience to draw from. Due to the deterministic nature of vehicle networks, local connections may be protected by MACsec, while more complicated networks can leverage IPsec. If traffic is to be sent through the internet connection outwards, TLS is most often used. Most AE networks will have some form of security enabled, but some implementations may be insecurely configured due to the lack of experience.

In Short: Other than CAN (and maybe Ethernet?), physical networks are mostly too hard to hack or not worth the effort. OBD (and therefore CAN) access is mandated by federal law, except for a few electric vehicles. Any other bus requires more skills and instrumentation to expose the wires, making it less likely to be accessed in a vehicle attack.

News: More recently, researchers discovered it’s far easier to take over OEM web service infrastructure instead. Using insecure web APIs and endpoints, they could access dealerships and even engineering capabilities, therefore getting “authorized” remote access to cars and customer information, gaining more control in a few months than vehicle hackers were able to do in multiple years. Vehicle to Cloud (V2C) security measures are essential to preventing misuse of V2C interfaces and indirectly affect the safety and security of the vehicles themselves.