Can We Move Beyond the CAN Bus for Vehicle Networks?

ethernet-1826_960_720Securing consumer automobiles against potential cyber attacks is a research goal that has attracted a lot of attention from industry, academia, government and the media in the past few years. A number of flashy examples of car hacking have circulated around tech websites, traditional news outlets, and even local nightly news broadcasts. Perhaps the largest and most alarming of these was the remote exploit performed on a Jeep while a reporter from Wired was driving it. The researchers, Miller and Valasek, were able to exploit a zero-day (a vulnerability that Jeep wasn’t aware of at the time) in the vehicle’s infotainment system to remotely send CAN bus commands that would kill the engine or cause other nuisances. Based on this media interest and the growth of research activity, vehicle cybersecurity is a problem that a lot of people are starting to look at closely. Much of this work takes the form of, “how can we better secure the CAN bus?” However, what if instead of adding security on top of CAN, we stop using CAN altogether? The two main alternatives to the CAN bus network that have been proposed are FlexRay and Ethernet.

The CAN bus specification currently in use was laid out in ISO 11898-1 in 1993 (updated in 2003). For the purposes that it was created, CAN works fantastically – it provides a way for the various Electronic Control Units (ECUs) inside of a vehicle to send and receive messages without any sort of host computer in a timely, reliable fashion that allows for some messages to take precedence over other messages. However, this protocol is designed only with safety in mind, meaning that being able to send reliable messages from one ECU to the other ECUs on the bus every n number of milliseconds is of tantamount importance. Since the concept of Internet security was mostly nonexistent when the CAN was standardized, and the idea of vehicles having any sort of access to the internet was still far off, the CAN standard includes no provisions for security. A number of the current problems with vehicle cybersecurity are based in this fact. There is no real form of authentication or authorization on the CAN bus, which means an attacker that gains access to the CAN bus theoretically has full access to all vehicle functions that are controlled through an ECU.

One way to concisely articulate the lack of security of the CAN is in terms of the traditional CIA model from computer networking. The CIA model calls for a security model to prciatriangleovide confidentiality, integrity, and availability for the system. Clearly, there is no confidentiality when all messages are readable in plaintext on the bus. The integrity requirement is also failed by the ability to spoof and inject any message onto the bus, due to the broadcast nature of CAN. The CAN bus fares better upholding the availability requirement, but even that fails on some implementations of CAN, since a flood of CAN messages can effectively overwhelm the legitimate messages on the bus, thanks to the arbitration system that allows messages with a higher ID to be arbitrated out when there’s a time collision on the bus.

In reality, it is much more difficult to attack an unknown vehicle with the level of sophistication shown by the Jeep attack, since arbitration IDs and other message identifiers change from vehicle to vehicle, and even from model year to model year. Nevertheless, once the messages on a particular vehicle have been mapped, any CAN functions are fair game if an attacker can gain access to the bus. However, this is more or less a “security through obscurity” argument, which does not pass muster in the computer networking world. Unfortunately, the specification for a CAN frame only allows for 8 bytes of actual data in the payload, which severely limits our ability to add security structures as we know them from the world of TCP/IP. So what other options are out there?

One alternative that has been proposed and in development since 2000 is called FlexRay. [1] FlexRay has several advantages over the standard CAN protocol: both synchronous and asynchronous transmission of messages (as opposed to only asynchronous on CAN), much higher data rate, clock synchronization, and predictable jitter. [2] However, research such as [3] has shown FlexRay to be susceptible to similar vulnerabilities that the CAN protocol is susceptible to. This includes the ability for an attacker to read all of the data present on the FlexRay bus, thus failing to provide confidentiality. An attacker can also create arbitrary messages and inject them onto the bus, since there is no authentication of what data gets transmitted on the bus. This means that an attacker can potentially, just like with the CAN bus, create messages that target a specific ECU or spoof messages from a specific ECU in order to cause dangerous vehicle activity.

Another option is to simply use Ethernet as the backbone for vehicular networks, as we do for standard computer networks. The Society of Automotive Engineers has, in fact, already published a specification for a time-triggered version of Ethernet that could potentially be used as a vehicular network backbone. A number of academic and professional researchers have also published research on the viability of various Ethernet specs as replacements for the CAN bus [4][5][6][7]. Most of this research focuses on validating that Ethernet would be able to satisfy the time-critical safety requirements of a vehicle network and does not touch on the security capabilities that Ethernet might provide over CAN or FlexRay.

However, one paper published by researchers in Germany [6] discusses the extant automotive uses of Ethernet, including smart charging stations which utilize a full TCP/IP stack for the charge control module. This includes the use of the DNS and TLS protocols, meaning the solutions for security that already exist in the computing realm could potentially be applied within a vehicle network as well. This is one of the largest advantages of making the move from CAN/FlexRay to Ethernet – along with the vastly increased bandwidth (100 Mbps or higher, compared to the 10 Mbps of FlexRay or 1 Mbps of CAN). Why try to reinvent the wheel by building security on top of the shaky foundation of CAN, when extensive security protocols already exist in the IP domain? The existing security model that is implemented through TCP/IP is already thoroughly tested and understood, meaning most of the heavy lifting would already be complete. Furthermore, as more vehicles become connected to the Internet, immediate IP compatibility would have a number of benefits for both users and manufacturers.

It seems clear that a major paradigm shift in the automotive space is needed when it comes to the networking of ECUs. Either security specifications need to be designed, tested, and mandated as a standard feature of CAN implementations going forward, or a switch needs to happen to some other architecture. The advantages of switching to Ethernet would be numerous – increased bandwidth, compatibility with IoT, Vehicle-to-Vehicle, and Smart Grid future tech, and existing security structures could be implemented within vehicle networks. Furthermore, several solutions for overcoming Ethernet’s lack of time-critical reliability have already been simulated and validated. The question of policy remains – will government intervention be required to mandate a switch to Ethernet, or can the consumer fear of vehicle cyberattacks be enough of a motivation for vehicle manufacturers to make the move voluntarily?


This post was written by: Mike Jaynes

References

[1] Makowitz, R., & Temple, C. (2006, June). Flexray-a communication network for automotive control systems. In 2006 IEEE International Workshop on Factory Communication Systems (pp. 207-212).

[2] Steinbach, T., Korf, F., & Schmidt, T. C. (2010, May). Comparing time-triggered Ethernet with FlexRay: An evaluation of competing approaches to real-time for in-vehicle networks. In Factory Communication Systems (WFCS), 2010 8th IEEE International Workshop on (pp. 199-202). IEEE.

[3] Nilsson, D. K., Larson, U. E., Picasso, F., & Jonsson, E. (2009). A first simulation of attacks in the automotive network communications protocol flexray. In Proceedings of the International Workshop on Computational Intelligence in Security for Information Systems CISIS’08 (pp. 84-91). Springer Berlin Heidelberg.

[4] Manderscheid, M., & Langer, F. (2011, October). Network calculus for the validation of automotive ethernet in-vehicle network configurations. In Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC), 2011 International Conference on (pp. 206-211). IEEE.

[5] Lim, H. T., Herrscher, D., & Chaari, P. (2012, April). Performance comparison of ieee 802.1 q and ieee 802.1 avb in an ethernet-based in-vehicle network. In Computing Technology and Information Management (ICCM), 2012 8th International Conference on (Vol. 1, pp. 1-6). IEEE.

[6] Hank, P., Müller, S., Vermesan, O., & Van Den Keybus, J. (2013, March). Automotive ethernet: in-vehicle networking and smart mobility. In Proceedings of the Conference on Design, Automation and Test in Europe (pp. 1735-1739). EDA Consortium.

[7] Lee, Y., & Park, K. (2013, June). Meeting the real-time constraints with standard Ethernet in an in-vehicle network. In Intelligent Vehicles Symposium (IV), 2013 IEEE (pp. 1313-1318). IEEE.