Understanding Automotive Cyber Security – Electronic Control Units

The second in the Understanding Automotive Cyber Security series, this article examines the Electronic Control Units that form the main attack surfaces in the connected vehicle.

The second in the Understanding Automotive Cyber Security series, this article follows on from our exploration of the different types of In-Vehicle Network, and examines the Electronic Control Units that form the main attack surfaces in the connected vehicle.

Understanding Electronic Control Units

As the in-vehicle network (IVN) is the central nervous system of the vehicle, so the electronic control units or ECUs are its sensory and vital organs. The modern vehicle has a whole host of sensors and control units built-in, managing everything from braking and fuel consumption, to hands-free phone services, navigation and entertainment.

In current IVN design, each ECU connects directly to the control area network (CAN), and may communicate with any other ECU on that network. In today’s increasingly connected world, the modern vehicle is offering more options for hackers to access these ECUs. This basic guide is designed to help you understand the relevancy of the ECU in relation to automotive cyber security.

To begin with we will look at the anatomy of an ECU and then look at some of the different types, the domains they inhabit within the vehicle, and the vulnerabilities they present.

Anatomy of an ECU

When describing the form of an ECU it’s probably easiest to draw comparisons to PC components like graphics or sound cards, or the recent popular educational mini-PCs like the Arduino or Raspberry Pi.

Hardware

The basic anatomy of an ECU consists of the following components:

A Printed Circuit Board (PCB) to which all the other components and ports attach.

A Microcontroller. A central processing unit, much like the microprocessor that runs your computer, but specifically designed for embedded applications.

EPROM (Erasable-Programmable Read-Only Memory) or Flash memory. EPROM and Flash are non-volatile memory – solid state chips that don’t require a power supply to retain data.

RAM (Random Access Memory). Some, but not all ECUs contain RAM, which as volatile memory, requires power to retain data.

Proprietary Hardware. The ECU can contain proprietary hardware, be it sensors or actuators – i.e. the TmCU has a cellular modem and ADAS ECUs contain various sensors such as radar and cameras.

Power Supply. To enable RAM, sensors, and actuators to function, either via independent battery, or main vehicle supply.

Input and Output ports. The type depends on the placement and function of the ECU, as well as the IVN it connects to.

Software

Like all computerized technology, the ECU needs operational instructions in the form of program code. ECU software is commonly developed in Embedded C and C++*, and is executed by various operating systems such as Linux, QNX and Integrity. The XML data format may be used for various configurations. Once the code is compiled or assembled into the relevant file format, it is loaded to the EPROM or Flash memory as firmware, from where application files are loaded into the RAM in runtime.

*While software architecture for ECUs can be proprietary or bespoke, an open industry standard exists, and is defined by Automotive Open System Architecture (AUTOSAR). A global partnership established in 2003, AUTOSAR members include various OEMs and Tier suppliers such as BMW, Bosch, Ford and General Motors among others. AUTOSAR describes a common development methodology and layered architecture, enabling automakers to combine software and components from a variety of suppliers, reducing research and development time, and most importantly, cost.

Firmware Updates

Firmware is permanent software that runs on embedded systems. It is programmed into the ECU memory by ‘flashing’ the EPROM or Flash Memory chip with an image of the operating system or drivers. This differs from a software update in that instead of changing individual lines of code, firmware updates overwrite the old firmware image with a new version*. This makes it safer by being less prone to operational error. Updates can be conducted over-the-air (OTA) using a cellular modem connection, or via physical access to the CAN bus (USB, OBD-II).

*It is worth noting that incremental updates do exist for some firmware-heavy ECUs, where you don’t want to send the whole image, but rather part of it. In these instances, it is possible to change specific ‘pages’ of the flash memory, saving time and bandwidth (cost).

ECUs by Domain

While not exhaustive (some vehicles can contain as many as 50+ ECUs) this list attempts to group some core ECUs into domains within the vehicle. Current in-vehicle network architecture allows for ECUs to be placed in almost any position in the vehicle. As a result, there is no easy or standard classification.

Due to the nature and dual functionality of a lot of the components in telematics and infotainment units, there can often be confusion as to which domain those ECUs belong. Therefore, this list should be considered a basic, rather than definitive description.

Powertrain

The powertrain is the collective term for the all the parts of a vehicle that generate power and transfer that to the terrain. In a car this includes the engine and transmission (among other structural components) as well their respective ECUs, which can be combined to form the powertrain control module (PCM).

PCM – Powertrain Control Module

In some vehicles the ECM and TCU are combined to form the Powertrain Control Module.

ECM/ECU – Engine Control Module/Unit

The ECM (sometimes called the ECU for added confusion) pulls data from sensors layered throughout the engine and uses this data to control various functions such as idle speed, fuel injection and ignition timing.

TCU – Transmission Control Unit

The TCU controls automatic transmissions, using ECM and sensor data, such as vehicle and wheel speed, to manage gear changes as well as to optimize fuel usage and vehicle performance.

Vulnerabilities

Both the ECM and TCU connect to the CAN bus in-vehicle network leaving them vulnerable to attacks via other (compromised) ECUs on the IVN. Attacks in this domain could halt the vehicle while travelling at speed, or cause false data to be sent to other safety critical ECUs within the vehicle.

Vehicle Safety and Control

The vehicle safety and control domain encompasses a variety of ECUs and in-car sensors with a clear focus on safety and driver assistance systems.

VCM – Vehicle Control Module

The vehicle control module can be, but is not necessarily, an ECU in its own right. It may also refer to any high-level domain controller, those that collect and processes safety critical data from other ECUs and sensors; the majority of which are made up of advanced driver assistance systems (ADAS).

These ADAS systems can include but are not limited to: adaptive cruise control, electronic stability control, electronic power steering, airbag control systems as well as cameras, LIDAR and RADAR systems providing collision avoidance, lane departure warning systems, automatic parking, and traffic sign recognition.

EBCM – Electronic Brake Control Module

The EBCM, as it name suggests, controls electronic braking systems and is the governing ECU for the anti-lock braking system (ABS) and electronic stability control (ESC). It receives inputs from vehicle and wheel speed sensors, brakes, four-wheel-drive and ignition switches.

TPMS – Tire Pressure Monitoring System

The TPMS comprises of air pressure sensors in each tire which feed data back to a main ECU via wireless transceivers. The TPMS in turn, feeds data back to the VCM, which can then aggregate it with other data to control fuel economy, exhaust emissions, and a host of safety features.

The TPMS is a safety critical system. Mandatory in all new US vehicles, it is swiftly becoming standard in all new model vehicles globally.

Vulnerabilities

The VCM and EBCM connect to the CAN IVN and as such are vulnerable to malicious messages from compromised ECUs elsewhere on the network.

The TPMS system connects to the CAN and shares the same vulnerabilities as the VCM and EBCM. Additionally, the wireless transceivers in the system leave it vulnerable to remote hacking. Each tire also has a unique identifier that can be tracked by sensors placed by the roadside, raising privacy and personal safety concerns.

Attacks in this domain can potentially be the most severe, as non-functioning safety critical ECUs, or false data being sent/received, could be used in potentially any cyber-attack. Be that aimed at property theft, financial extortion, or life-threatening scenarios.

Interior Cabin Environment

The interior cabin environment encompasses all the comfort features you would expect from a modern vehicle.

BCM – Body Control Module

The BCM is a general label for any ECU that controls additional features within the body of the vehicle. These may include, but are not limited to, such areas as heating, ventilation and air conditioning (HVAC), as well as the electrical controls for body features like remote and central locking, windscreen wipers, lighting controls, seat controls, power windows, and the power roof in modern convertibles.

OBD-II – On-Board Diagnostic Port (II)

The OBD-II port has been standard in new model vehicles since the late 1990’s in the US, and early 2000’s in the EU. The port allows physical access to the IVN from within the vehicle’s cabin. While not an ECU, the OBD-II port connects directly to the CAN bus, allowing engineers to connect diagnostic tools for maintenance purposes. The OBD-II port can also be used to connect third party modules such as the driver behavior monitors advocated by many insurance companies.

Vulnerabilities

BCMs connect to the CAN, and whilst they have no direct surface for attack, access to a BCM via another, compromised ECU, can be used maliciously to cause driver distraction, a well-researched cause of driver deaths.

Generally, it’s assumed that the OBD-II port is vulnerable only after gaining physical access to the vehicle itself. However, it’s also possible that aftermarket telematics and infotainment modules connected to the port may offer wireless attack opportunities.

Infotainment

The infotainment domain encompasses a wide variety of components and units, and shares a lot of its data inputs with the Telematics domain. Infotainment ECUs are generally housed in the vehicles head unit, dash and central console, as well as in the driver facing instrument cluster.

Due to the wide array of components, the sections described below are not specific ECUs, but rather areas within the cabin which collect various functions, providing a surface for human machine interface (HMI).

Head Unit

Provides an HMI for control of comfort and entertainment features such as aircon, clock, analogue and digital radio, and other features within the central console.

Display Stack

Located in the central console, the display stack contains the display and touch screens for components which include GPS navigation, and entertainment center video, audio, and web browsing.

Media Interface Unit

Also located in the central console, this unit houses USB, Bluetooth and Data connectivity, enabling Wi-Fi LAN in-car internet, SMS-texting and hands-free calling.

Cluster Display

The cluster display is positioned above/behind the steering wheel. Usually composed of data outputs such as speed dials and fuel gauges, it is increasingly being used to display infotainment data; including navigation details and media player text output.

Vulnerabilities

Whilst not safety critical, the infotainment domain (like the interior cabin domain) offers opportunities for driver distraction. It also houses many connected features (with wireless and Bluetooth capability) which offer potential attack surfaces. The infotainment domain network connects to the critical CAN bus via a gateway, allowing access to safety critical ECUs.

Telematics

The Telematics domain governs telecommunications and informatics. Collecting diagnostic, sensor, safety, and location data for use by other ECUs on the network as well as aggregating this data for analysis by manufacturers and technicians.

TmCU/TCU – Telematics Control Unit

The primary role of the TmCU (also confusingly referred to as the TCU) is to transmit data between the vehicle and cloud. This includes the transmission of diagnostic and informatics data, and the reception of OTA updates and remote commands. The ECU features a GPS unit providing location data, two-way communications via a mobile/cellular communication unit, and provides remote access via a variety of communications protocols including GPRS and Wi-Fi.

eCall – Emergency Calling

eCall is an initiative by the European Union aimed at providing rapid response to accidents occurring anywhere within the EU. Notification of a vehicle collision is sent to emergency services following a crash, which includes a precise location of the vehicle at the time of the accident. The eCall initiative is set to become a mandatory feature of all new model vehicles from April 2018.

V2X – Vehicle-to-Everything

With the rise of the connectivity and the approach of autonomous vehicles, V2X has become an area of much interest. Vehicle-to-vehicle (V2V) technologies will enable vehicles to share data. Vehicle-to-infrastructure (V2I) technologies will allow vehicles to send data to, and receive data from, infrastructure, sending and receiving traffic data which can feed into larger traffic management systems.

Vulnerabilities

The TmCU sits directly on the CAN bus, and its wireless mobile/cellular communications channels offer a large target for hackers wishing to access the CAN network and the safety critical systems connected to it. As well as the safety risks posed by access to the CAN, attacks in this domain have the potential to access sensitive personal data, such as location and driving habits.

eCall guidelines suggest that data can only be sent and received in the event of an accident, however, so far, it appears there is no standardized technology designed to enable this feature. With each manufacturer left to decide how best to implement the requirement. This has the potential to leave the system open to attack.

V2X is still an unknown, but what is clear is that both the vehicle and the wider ecosystem it could interact with will require a multi-layered security approach. The potential scenarios available at this level of connectivity offer opportunities for rogue-states and other malicious actors to effect disaster level attacks. It is incredibly important that these technologies be developed with safety and security in mind, at all levels.

Securing the Vehicle

ECUs present a wide range of vulnerabilities in the modern vehicle. But even with growing standardization in ECU component and software development via groups such as AUTOSAR, much remains to be done to secure them against hacking.

ECU hardening will require a security-first approach to design, and until that becomes a priority for OEMs and Tier suppliers, components with easy physical access or wireless connectivity will remain a threat to the integrity of the in-vehicle network, and the safety-critical ECUs that connect to it.

Protecting this network should be considered a priority by all vehicle manufacturers, as it offers the simplest and most effective method of neutralizing compromised ECUs.