A Cybersecurity Analysis of the CAN Bus in Vehicles - report summary

31 Aug 2020

My Analysis of the cybersecurity of the CAN Bus in vehicles

Introduction

When the CAN bus was initially created in the 1980s, cybersecurity threats were not an issue that was of great concern for non-militarized projects. As a result, all the modifications that have been applied to the CAN bus was to improve performance and electrical engineering convenience, and not to improve security. As all messages are sent to all ECUs without network control, any device that can connect to the CAN bus will be able to send uncontested commands to critical parts of the vehicle. The Onboard Diagnostic Port (OBD-II) allows such a connection and will allow any device with the appropriate software and cable adapters to gain direct connection to the CAN bus without any type of security check. 21 As all vehicles are federally required to have an OBD-II port, this vulnerability pertains to every vehicle on the road.

How Messages Are Delivered In A CAN Bus

The CAN bus is the current standard for all vehicle LANs. Figure 1 gives a simplified overview on the connectivity of the CAN bus across a vehicle. The red line is the CAN bus, which provides a communications path to various Electronic Control Units (ECUs) across the vehicle, marked as cubes on the figure. ECUs are responsible for specific subsystems including the engine, the infotainment display dash, and breaks. 2 These ECUs also connect to sensors, depicted on the figure as circles, to give information about the health and status of the car to the dashboard console. Upon receiving an appropriate signal, the ECU will perform the commands given including changing speed, turning off the engine, or in self-parking vehicles, move the steering wheel. There is no form of ECU verification, or qualification on what the commandoriginator is, and a laptop with appropriate software can also be seen as an ECU.

Any ECU may initiate a new message, which is transferred in a framed binary sequence called the data frame. 3 All the signals in the data frame are contained in the Data-Link Layer, and managed by the Logical Link Control (LLC) and Medium Access Control (MAC). 4 The purpose of the LLC is to transmit the bits to their appropriate destination. This includes message filtering, flow management, and recovery management. The purpose of the MAC includes message framing, acknowledgement, error detection, and message signaling. 5 These messages are Non-Return to Zero.

Figure 2: Visualization of the data frame 6

Figure 2 shows a visual representation of this data frame. There are 7 different fields, which are detailed in the BOSCH CAN 2.0 specification document: the Start of Frame, Standard Identifier, Remote Transmission Request, Control, Data, Cyclic Redundancy Check, Acknowledgement, and End of Frame.

The Start of Frame consists of one bit always “off” which enables the message to be transmitted upon the bus being idle. The Standard Identifier contains 11 bits that describe where the message should be received. As all messages are essentially broadcasted to all the ECUs, the Identifier is used to determine if the receiving ECUs should accept the data. Additionally, the Identifier is also used to determine the priority on a message for bus access. Only one message can be sent at a time on the CAN bus, and in case of a collision, the configuration with the most “off” bits in the Identifier will have priority. With this standard it is easy for an attacker to send multitudes of high priority messages in the CAN bus. The Remote Transmission Request bit will be “on”, identifying this message as a Data Frame transmission. The Control field consists of a four-bit code that tells the length of the Data field, and a 2 bit “off” buffer. The Data field consists of a maximum of 64-bits of data that is being transferred. The Cyclic Redundancy Check field consists of a calculation of the values of each field, used to ensure message integrity, saved in 15 bits. The last bit of this field will always be “on”. The Acknowledgement field contains the ACK slot bit and the ACK delimiter bit. The bit in the ACK slot will be “on” in a data frame message. The ACK delimiter stays as an “on” bit. The last Field is the End of Frame. This section consists only of seven “on” bits.

When a message is received by an ECU that accepts the Identifier, an integrity check is done on the calculation against the Cyclic Redundancy Check. If the ECUs own calculation does not match the Cyclic Redundancy Check the ECU will transmit an error flag and the originator will retransmit the message. If the Cyclic Redundancy Check is correct the ECU will transmit an acknowledgement message in the format of a remote frame. This message will have the identical fields of the data frame, with an identical Identifier, but the Data field will only have “off” bits, and the ACK slot bit will be “off”. 8 There is no verification on who the sender was.

Figure 3: A vehicular CAN bus interconnected to other complex subsystems 9

Figure 3 is a visual representation on the other systems that may be interconnected with the CAN bus via ECUs. As there is no scrutinization on the CAN bus, any command that gets sent through it will be delivered across all the ECUs. Once the message is successfully received by an ECU, the ECU will transmit the instruction to the subsystem it presides over. That subsystem can be a Local Interconnected Network for wireless key entry, Flexray for antilock brakes, Media Oriented Systems Transport for audio, or a different bus type network. Some vehicles may even have multiple CAN bus networks to manage the subsystems. 10 These multiple CAN bus networks may be slightly more secure due to being physically separated from an accessible CAN bus, but the CAN bus was never built with cybersecurity in mind.

Background on the CAN bus

Figure 4: Comparison of CAN bus network vs the conventional wiring network on a vehicle

Over the past 40 years the CAN bus went from creation to becoming the backbone of complex electronic systems in vehicles. 12 The CAN bus was introduced in 1986 by Robert Bosch as an alternative to the point to point wiring configuration which was standard at that time. 13 Figure 4 has a visual demonstration of the amount of wires saved by the utilization of the CAN bus. Originally designed for the purpose of better electrical communication in vehicles, security of these components was not even a consideration at the time. The ability of the CAN bus to create lighter, faster communication enabled it to be quickly adopted in various electronic devices, and was first used in elevators and textile machines before being used in cars. 14 In 1993 the International Organization for Standardization (ISO) officialized the international standard for the CAN bus in vehicles and it started becoming widespread among the automotive industry. 15 In 2012 Bosch released the first version of CAN FD (Flexible Data-rate). 16 This CAN FD proved to be able to transport more data at a faster rate and has been incorporated into the ISO. This design, known as CAN 2.0A, did not include any cybersecurity updates, and is what is used in cars to this date.

Figure 5: Diagram of a vehicle electrical elements 18

As vehicles grew more complex over the years, the adaptation of the CAN bus has incorporated every subsystem into one programmable network. Figure 5 is an image demonstrating the complex electronic components in a vehicle in which the CAN bus is a critical component of. Now as a standard in vehicles, all cars and trucks in the US and Europe use the CAN bus as part of their vehicular network system as a legally required part of the On-Board Diagnostic tool. 19 This CAN bus technology has since been incorporated into agricultural equipment, aviation and navigation systems, medical instruments, robotics, and space technology 20 . Despite the diversity in which the CAN bus is used, there is no policy for protecting the CAN bus from direct attacks.

CAN Bus Physical Vulnerabilities

Figure 6: SocketCAN program displaying CAN bus traffic 22

The simplicity and danger in which physical access to this port can have has been demonstrated multiple times. Figure 6 shows a result of running a program that analyzes all the CAN bus data. This laptop was plugged into the OBD-II port, located near the steering wheel, with the Linux program SocketCAN, and the reconnaissance of CAN bus signals were observed. This enabled a mapping of functions to code. The red texts in the image are the parts of the code that changed when physically interacting with the vehicle.

Once identified, the selected code wished to be emulated was continuously sent out with high priority in a denial of service attack against the vehicle. Vehicle systems were accessed including the speedometer and brakes. 23 When this information was initially released, it was classified as a low risk and dismissed by automotive companies since the ability to access the CAN bus would require physical access into the vehicle. This vulnerability has been identified by the CISA in ICS-ALERT-17-209-01, and the only mitigating recommendation is to limit access of people to those ports. 24

However, even with putting the OBD-II in a locked compartment, there are other locations across the vehicle that an attacker can use to access the CAN bus. As the ECUs do not scrutinize messages coming in, they also do not scrutinize messages coming out.The tire pressure ECU was discovered to be under the steering column of some vehicles, reachable without any disassembly, and effectively hardwired to send commands from a laptop to the CAN bus. 25 Wireless vulnerabilities have also enabled people to gain full access into vehicles, and the possibility of a bad actor tampering with the CAN bus of a target’s car still exists. Additionally, the emergence of driverless taxis will demand higher physical security against physical access to the CAN bus, as there will be people allowed physical access into unattended vehicles.

CAN Bus Wireless Vulnerabilities

As cars are presenting additional wireless features and conveniences, more access points are becoming available. AM/FM/XM radios, Cellular, Bluetooth, applications, WiFi, Tire Pressure Monitoring System and Remote Keyless Entry devices all accept remote signals and are therefore entry points that may have an exploit. 26 These entry points will be analyzed to understand if they have access to the CAN bus, and published vulnerabilities and exploits will be discussed in order to gauge where cybersecurity positions lie on these wireless devices.

While in America HD Radio is the standard for FM/AM radio, many countries including the UK use Digital Audio Broadcasting (DAB). Like HD radio, DAB emits a strong multi- spectrum FM or AM radio waves along with data that will display the title of the song. With the car dashboards presenting interactive infotainment features, the song data will interact with the system. A lab demonstration by NCC Group showed that the DAB can be used to emit signals that can access the CAN bus networks of multiple vehicles simultaneously through their infotainment systems. 27 This demonstrates that data that accompanies radio waves can access the CAN bus, and that the critical systems should be protected from this traffic. Ideally, there is no reason that a music station should be sending signals out to a critical systems CAN bus, and there should be either physical separation or a component in place to disallow such signals from communicating past the infotainment center.

The ability for the car to make phone calls is another area of potential vulnerability. Investigation into the cellular connection revealed that the potential for a buffer overflow attack may occur. 28 However, once a connection is established, the cellular protocol in the vehicle will only accept authentication responses, and commands to the CAN bus have not been able to be established. While there is no current resolution to the buffer overflow attack, there is no current risk to the CAN bus from the cellular network as that network scrutinized input data. This does not mean that future intrusion technology will not find a way to breach this protocol, and specific controls need to be in place to prevent access to the CAN bus.

The use of the Bluetooth allows individual phones to connect to the vehicle. This form of convenience follows a pairing sequence with a pin code that is regenerated with each start of the car, and brute forcing an unpaired device can take up to 10 hours. . 29 However, if the phone can download the appropriate Trojan, then once connected to the vehicle the software on the corrupted phone may access the CAN bus. Additionally, a new vulnerability in Bluetooth devices allows access to Bluetooth devices by what is now called the Bluetooth Impersonation Attack (BIAS). 30 While suppliers of Bluetooth devices are currently working on a solution, current items that use Bluetooth are vulnerable to their signals being intercepted and used to link a malicious device to a running car. Installing antivirus protection on cell phones and a firewall on the Bluetooth entrypoint, as well as ensuring that the car only accepts Secure Connection from the Bluetooth and will not downgrade to vulnerable connection requests, will protect the vehicle from an attack on this entry point. 31 Seperation of the Bluetooth from the CAN bus critical system will additionally protect the CAN bus from any activity on the mobile devices.

When the Uconnect application was initially made available in cars anyone on the Sprint network was able to exploit the open port and have unauthenticated access to the Uconnect. Upon access the perpetrator may issue commands down the CAN bus to directly affect display information, brakes, and steering 32 . This vulnerability was published in CISA in 2015, in which Sprint quickly closed the vulnerable port, and a voluntary recall on the 1.4 million affected vehicles occurred to patch the Uconnect Software. However as only 70-75% of recalls are completed on vehicles, there are approximately 420,000 vehicles that did not turn in their vehicle to get the patch. 33 Relying on customers to keep up with any recalls is not a method that should be depended on, as multitudes of vehicles will have vulnerabilities. The addition of all applications that require an external connection should be analyzed and determined if it should be connected to the CAN bus or run on a separate system. If the application needs to be connected to the same network as critical systems, additional cybersecurity protocols should be taken to prevent it from being an access point for an attack.

As vehicles become equipped with complex software for autonomous driving, the need for a means to connect to WiFi to download patches increases. The ability to identify open networks and connect to public ones puts the system at risk for waterhole connections. Additionally, the initial lack of encryption in their traffic allowed all WiFi traffic to vehicles to be monitored. This vulnerability was exploited with a man-in-the-middle attack as the vehicle connected to malicious WiFi while browsing on their car. The hacker was able to access the CAN bus 12 miles away and disrupt the breaks. 34 This exploit to a Tesla was patched shortly after it was reported, and communication traffic from Tesla vehicles are now encrypted 35 .

The tire pressure monitoring system uses wireless connections from each tire to alert the ECU of low tire pressure. This communication is not encrypted and is vulnerable to spoofing. 36 However, there is no direct access to the CAN Bus, as only tire pressure messages can be sent through the wireless receptor to ECU. While physical access to the ECU can reach the CAN bus, the only risk that spoofing tire signals may have is loss of confidence in the dashboard as tire pressure warnings blink on and off.

Remote Keyless Entry signals are very convenient tools, as drivers can keep the key in their pocket and through proximity access turn on their vehicles. Duplicating the signals is typically difficult, with only one vehicle having a record of its signal decrypted and cloned due to weak encryption. 37 However, with signal booster technology, the encrypted signals from the key are being boosted from entry areas where the keys are being kept, sent to an interceptor, and replicated to trick a remote-start vehicle that the key is near, allowing a perpetrator to physically access the entire vehicle. With this method physical access to the CAN bus can be achieved, and tampering may occur. This vulnerability is still ongoing, with 88% of stolen new cars happening without keys. 38 With the ability to physically access the CAN bus via signal boosting, physical hardening of access to the CAN bus needs to be reassessed.

Prevention

While mitigations from most identified threats have been applied, secure designs need to be in place to prevent the critical components from future zero-day attacks. Isolation of the critical components from the rest of the network on a separate CAN bus would be a recommended design. Tesla has applied this concept to parts of their network, and the infotainment dashboard can now only send a small list of messages to the rest of the system. 39 Firewalls built into the access points will prevent malicious software from accessing the system, even from a corrupted cell phone that has already been synchronized to the device. As autonomous vehicle designs are progressing, security needs to be a prominent feature within the design. The 5G network has developers excited about the ability to use it for autonomous vehicles, and cyber safeguards against emerging threats need to be implemented. 40 At this time, there is a lot of focus on wireless access to the CAN bus, but physical access is being overlooked. The ability to access an OBD-II port to manipulate the CAN bus is as easy as enhancing the remote keyless entry signal to gain entry to the vehicle. Additionally, as self- driving taxis become a reality, security measures need to be taken to prevent the customer having physical access to any ECU, especially the OBD-II. 41

Conclusion

The CAN Bus is not a device that currently has built-in cybersecurity. Sending every message to every ECU and allowing ‘new’ ECUs to appear without any administrative confirmation is a critical risk. The interconnectivity of every wireless device to the CAN bus has enabled many points of attack into this critical system. Access to a CAN bus that is connected to critical vehicle components can result in dangerous driving situations. While mitigations from some identified threats have been applied, cybersecurity needs to be incorporated into all future designs to ensure continued security in a developing industry. If the CAN bus itself will not be redesigned to provide better cybersecurity, then the network design of the vehicle must work around protecting critical components linked on the CAN bus. Vehicle networks are only projected to become more complex, and a cyber attack against a car could put human lives at risk.

Works Cited

BBC (January 28, 2019). Hundreds of popular cars ‘at risk of keyless theft’. Retrieved from https://www.bbc.com/news/business-47023003

Bosch(1991). CAN Specification 2.0. Retrieved from http://esd.cs.ucr.edu/webres/can20.pdf

CFA (September 18, 2018) Over 70 Million Vehicles On The Road With Open Recalls. Retrieved from https://consumerfed.org/press_release/over-70-million-vehicles-on-the-road-with-open-recalls/#:~:text=Huge%20GM%20and%20Ford%20Recalls%20Signal%20Need%20to%20Fix%20System&text=Issue%3A%20In%20the%20last%2010,the%20road%20with%20open%20recalls.

Checkoway, Stephen, McCoy, Damon, Kanto, Brian, et, al (2011). Comprehensive Experimental Analyses of Automotive Attack Surfaces. University of California, San Diego & University of Washington. Retrieved from http://www.autosec.org/pubs/cars-usenixsec2011.pdf

CiA (2020). History of CAN technology. CAN in Automation. Retrieved from http://www.can-cia.org/can-knowledge/can/can-history

CISA (July 28, 2017). ICS Alert (ICS-ALERT-17-209-01)CAN Bus Standard Vulnerability. Retrieved from https://www.us-cert.gov/ics/alerts/ICS-ALERT-17-209-01

CISA (September 17, 2015). ICS Advisory (ICSA-15-260-01) Harman-Kardon Uconnect Vulnerability. Retrieved from https://www.us-cert.gov/ics/advisories/ICSA-15-260-01#:~:text=Charlie%20Miller%20confirmed%20a%20missing,access%20to%20 the%20vulnerable%20port

CSS Electronics (2020). CAN Bus Explained - A Simple Intro. Retrieved from https://www.csselectronics.com/screen/page/simple-intro-to-can-bus/language/en

Currie, Roderick (May 18, 2017). Hacking the CAN Bus: Basic Manipulation of a Modern Automobile Through CAN Bus. SANS Institute. Retrieved from https://www.sans.org/reading-room/whitepapers/awareness/hacking-bus-basic-manipulation-modern-automobile-through-bus-reverse-engineering-37825

Davis, Andy (August 6, 2015). Broadcasting your attack-DAB security. Black Hat USA

Retrieved from https://www.nccgroup.com/uk/our-research/black-hat-usa-2015-presentation-broadcasting-your-attack-dab-security/

ESA(Dec 8, 2016). After a decade of development "can bus for space" is flight-ready. Retrieved from https://artes.esa.int/news/after-decade-development-can-bus-space-flight-ready EVO-ALL(2020). What is a CAN bus? Retrieved from https://canbuskits.com/what.php

Greenberg, Andrew (September 10, 2018). Hackers Can Steal a Tesla Model S in Seconds by Cloning Its Key Fob. Wired. Retrieved from https://www.wired.com/story/hackers-steal-tesla-model-s-seconds-key-fob/#:~:text=But%20one%20team%20of%20academic,car%20door%2C%20and%20driving%20away.

GreenBurg, Andrew (April 12, 2017). Securing Driverless Cars From Hackers Is Hard. Ask the Ex-Uber Guy Who Protects Them. Wired. Retrieved from https://www.wired.com/2017/04/ubers-former-top-hacker-securing-autonomous-cars-really-hard-problem/

Greenberg, Andrew (July, 21 2015). Hackers Remotely Kill a Jeep on the Highway— With Me in It. Wired. Retrieved from https://www.wired.com/video/watch/hackers-wireless-jeep-attack-stranded-me-on-a-highway

ISO(2015). ISO 11898-1:2015(en) Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling. International Standard Organization. Retrieved from https://www.iso.org/obp/ui/#iso:std:iso:11898:-1:ed-2:v1:en

Hartwich, Florian (2013). Bit Time Requirements for CAN FD. Robert Bosch GmbH. Retrieved from https://www.bosch-semiconductors.com/ip-modules/can-ip-modules/can-fd/

Metzer, Mike (November 7, 2013). Letting the Air Out of Tire Pressure Monitoring Systems. DEF CON 18. Retrieved from https://www.youtube.com/watch?v=gUsE9aTLYnk

Miller, Charlie & Vlasek, Chris (August 21, 2015). Remote Exploitation of an Unaltered Passenger Vehicle. DEF CON 23. Retrieved from https://www.youtube.com/watch?v=OobLb1McxnI

Natale, Marco Di (October 30, 2008). Understanding and Using the Controller Area Network. Berkeley. Retrieved from http://inst.cs.berkeley.edu/~ee249/fa08/Lectures/handout_canbus2.pdf

National Instruments (2020). Controller Area Network (CAN) Overview. Retrieved from https://www.ni.com/en-us/innovations/white-papers/06/controller-area-network–can–overview.html

ObdDiag.net(2020). Vehicle On-Board Diagnostic. Retrieved from http://www.obddiag.net/adapter.html

Oliver, Madison (May 18, 2020). Bluetooth devices supporting BR/EDR are vulnerable to impersonation attacks. Carnegie Mellon University. Retrieved from https://www.kb.cert.org/vuls/id/647177/

Renesas(2020). In-Vehicle Network Solutions. Retrieved from https://www.renesas.com/us/en/solutions/automotive/technology/networking-solutions.html

Solon, Olivia (September 20, 2016). Team of hackers take remote control of Tesla Model S from 12 miles away. The Guardian. Retrieved from https://www.theguardian.com/technology/2016/sep/20/tesla-model-s-chinese-hack-remote-control-brakes Telekom (2020).

5G network as foundation for autonomous driving. Retrieved from https://www.telekom.com/en/company/details/5g-network-as-foundation-for-autonomous-driving-561986

Trachtenberg, Ari (July 2015). On feedback-based rateless codes for data collection in vehicular networks. Retrieved from https://www.researchgate.net/publication/288994853_On_feedback-based_rateless_codes_for_data_collection_in_vehicular_networks

Vizcayno, Danielito (August 8, 2015). The Future of Technology, Privacy, Security and Risks. Retrieved from https://dcvizcayno.files.wordpress.com/2015/08/as1.png