• Automotive E/E
  • Our Resources
  • Blog
  • Finding the Cybersecure Place for Automobile Can Bus Networks
Connected Vehicles

Finding the Cybersecure Place for Automobile Can Bus Networks

December 2, 2020

CAN: The Communication Network Since 1991

Controller Area Network (CAN) buses have been used in cars since 1991. Prior to that, automobile electronics communicated over simple UART-like links. CAN was a significant advancement in noise resilience and bandwidth and includes more subtle benefits, like native multicast, frame priority enforcement and non-destructive collision detection arbitration. As a testament to this, CAN is still the backbone networking technology that automobile E/E architectures are based on.

As communications needs have exploded, CAN has been increasingly asked to do more and more. Today, connected vehicles (with a connection to the internet), nearly universally use CAN as the internal networking backbone of the vehicle. CAN is a robust bus network that has performed admirably up to this point, but as the cyber-attack landscape grows, additional system and architectural mitigations are required to keep using CAN in connected cars.

Illustration of CAN bus in connected cars and the vulnerability for CAN bus hacking

CAN Do: Why CAN Remains Widespread

CAN’s immense success is due to great features and its stellar track record of robustness. Let’s take a look at some of the technical features that make CAN great, and, particularly well suited to the automotive environment:

  • High noise tolerance (the physical layer and protocol support noise robustness)
  • Supports long single buses (tens of feet) without especially careful design
  • Superior performance for use case to UART/K-Line, I2C/TWI or SPI
  • Native multicast and broadcast
  • Built-in frame priorities
  • Non-destructive collision resolution
  • 100% distributed in operation (no bus master(s))
  • CANnot Do: Error Handling

In addition, CAN is now quite mature. It enjoys broad hardware support, both for production and test systems. There is a deep base of knowledge within the automotive industry for using CAN successfully.

CAN Don't: Stretched to the Limits

In recent years, CAN has been showing its age. A replacement is badly needed for the core networks of vehicles today. To start simply, CAN doesn’t provide much bandwidth. At around 50% data payload throughput and with a 1 Mbps baud rate (not many systems are running this fast in the field and faster is vanishingly rare), a single CAN bus can provide, at best, 500 kbps payload throughput (i.e., goodput) which is pretty meager by today’s standards.

However, because CAN is reliable, automakers are not keen on changing it. To be really blunt, making cars is complicated and competitive and CAN works well. To solve the bandwidth problem, automakers have added more and more CAN buses. It is not unreasonable to believe a car produced today might have upwards of ten CAN buses. These buses are generally connected together in an ad hoc manner, with gateway(s) to pass messages as deemed appropriate for functional design but with less thought to the security implications.

CAN has a number of other features that make it less-than-secure. For example, each CAN ID can have one and only one sender. (The protocol does not include a sender ID or address, but that can be worked out from the ID and knowledge of the network.) However, there is no enforcement of this, and any ECU can actually send any ID. The receiver(s) cannot tell an authentic from inauthentic sender. Furthermore, the protocol cannot deal with a collision between two ECUs each attempting to send the same ID at the same time. Bad and even unpredictable results would occur. While CAN can be manipulated in a number of ways, this example really highlights the fundamental limitations of the CAN design from a security perspective. Another example of exploiting the way CAN is designed without going around the hardware peripheral itself is to simply flood the bus with very high priority frames (the lowest CAN IDs have highest priority).

TU Automotive Webinar

How CAN’s Environment has Changed Over the Last 30 Years

While networking technology has advanced significantly since CAN’s introduction, the CAN bus itself has remained largely unchanged. What were once small buses of a few controllers, originally connected over UART-based links, have become full computing networks, complete with different domains and gateways to pass data back-and-forth.

Just like the computing capabilities inside the vehicle, the computing capabilities of potential attackers have also grown exponentially. Moore’s law suggests that computing power has doubled 20 times since 1990; that’s roughly 1,000,000X! Attacks that would have been very expensive in the 1990s have become trivial today. For example, attaching an internet connected device to the vehicle to remotely exfiltrate data or even execute diagnostic requests can be done with little investment by the malicious actor. What was once good enough is not necessarily still good enough today. While CAN may not be retired any time soon, it’s days as the backbone networking technology in vehicles are numbered.

Post-CAN Networking Backbone

Ethernet has been on the horizon for automotive networks for many years. After success in avionics, it seemed that automobiles would be a logical landing place, given the exponential growth of computing inside and the resulting bandwidth crunch.

Time-deterministic variants of Ethernet (and CAN) are of particular interest. TTEthernet/TTCAN. However, a straightforward CAN-for-Ethernet swap, with the high line rates, higher payloads and higher resulting goodput of Ethernet, should make Ethernet very attractive. Latency is the key variable for control systems. Time-deterministic networking is targeted for hard real-time systems, but the best-effort delivery of Ethernet is sufficient for the vast majority of communications that currently take place over CAN. 

CAN-FD and CAN-XL are somewhat intermediate upgrades (although CAN-XL perhaps more than intermediate) to CAN. CAN-FD, which is already in production microcontrollers and application processor SoCs, having already gone through a specification issue and fix, is more mature. It allows for more payload to be transmitted than standard CAN (i.e., CAN 2.0b) by downsampling and/or changing the sampling frequency during the data payload only. The remainder of the frame is transmitted as before (with very small differences). Theoretically it can offer 8-16x the goodput of CAN, but the first production systems will be more conservative. CAN-XL is newer and, as the name hints, “bigger.” With even faster line rates (up to 10 Mbps) and larger frame sizes, CAN-XL seems that it will compete with Ethernet as much as CAN-FD. However, CAN-XL is still in the design phase. 

Where do We Go from Here?

CAN is a relatively simple bus-based technology that has fantastic noise tolerance and broad hardware support. It still has a place in the vehicle architectures of tomorrow. CAN control networks with very well-defined external interfaces and rock-solid enforcement will remain a part of vehicles for a long time to come.

Moving forward, CAN will still be utilized, but its role and capacity will diminish moving forward as the industry transitions to Zonal E/E Architectures with Ethernet network backbones. GuardKnox, the first Cybertech Tier supplier specializing in core E/E products for the automotive market, is interface and technology agnostic, meaning it is backward and forward compatible, covering existing, upcoming and future architectures.

GK-LI+FB-OTA_Whitepaper - 1

 

Lets’s Talk