The cybersecurity of the electronics used in automotive designs is crucial and must be considered very early during the architecture and design phase of development. An important set of guideposts for this process can be found in the MITRE CWE (Common Weakness Enumeration). The CWE list provides a solid framework for preventing security vulnerabilities during hardware development. By utilizing CWE, developers can take proactive measures to identify and address potential weak spots before they become security risks.
When it comes to automotive electronics, there are several unique aspects to consider from a security perspective, including:
- Long life span – A security weakness may not be easy to exploit today, but technology and attacker capabilities may be vastly different in 15 years.
- Physical security – Attackers have physical access to vehicles as well as remote access via wireless interfaces.
- Increased safety risks – A security breach can have severe consequences, including the loss of life. For instance, if an attacker can disable a vehicle’s brakes, the outcome can be catastrophic.
To address these security and safety risks, several industry standards have been developed, for example ISO/SAE 21434 – “Road vehicles – Cybersecurity engineering”. This standard covers the entire process from management, design, and verification all the way to product decommissioning. One of the requirements [RQ-08-01] in the standard is to identify sources for cybersecurity information. An excellent resource to address this requirement is the CWE list for hardware.
Getting Started with CWE
The CWE hardware list has over 100 entries, so where do you start? There is a list of “Top HW CWE” but let’s narrow it down a bit by doing some threat modeling. This will be different depending on what component you are designing, but here we’ll look at a generic microcontroller as an example.
Let’s assume the attacker has full physical access to the microcontroller and can connect analysis equipment to all interfaces while the vehicle is not driven. When the vehicle is driven, the attacker only has access to the vehicle via wireless interfaces. All interfaces need to be considered since an attacker may first gain access through a physical interface allowing him to disable access control on a wireless interface.
If a microcontroller is controlling an essential vehicle function such as braking, an attack that prevents the controller from communicating with the brakes so that nothing happens when the driver presses the brake pedal may cause a serious accident. If an attacker can inject brake commands without the driver intending to brake, this too can cause serious accidents.
Physical side channel attacks are also a concern since we assume the attacker has full access to the vehicle. An absence of a side channel that an attacker can use is difficult to verify prior to manufacturing since most of the effects are not modeled in RTL.
These security concerns fall into two main categories:
- Protecting keys – all in-vehicle, vehicle-to-vehicle and vehicle-to-Infrastructure communication will be encrypted, so keys are the most important asset to protect
- Denial of Service – preventing brakes or other essential functions from working may have serious consequences
Within these categories there are several security-sensitive assets found in an automotive microcontroller, for example:
- Boot code stored in flash memory
- Encryption keys stored in One Time Programmable (OTP) memory
- Control and Status Registers
With traditional verification methods, it’s difficult to ensure that security sensitive assets don’t have breaches in integrity and confidentiality. The most effective security verification method is information flow tracking, as detailed below and used in our Radix technology.
Top CWEs for Automotive Security
Reviewing the Hardware CWE list, considering the assets and attacker capabilities we come up with this list of most relevant CWEs for Automotive cybersecurity:
- CWE-1191: On-Chip Debug and Test Interface with Improper Access Control
- Device internal information may be accessed via the scan chain through the JTAG interface. If authorization, authentication, or other forms of access control are not implemented or not implemented correctly, an attacker may be able to bypass on-chip protection mechanisms
- CWE-1244: Internal Asset Exposed to Unsafe Debug Access Level or State
- Device sets incorrect access privileges for debug interface providing unintended access to assets
- CWE-1231: Improper Prevention of Lock Bit Modification
- Device uses a lock bit, set during secure boot, to restrict access to registers or address regions but an incorrect implementation allows modification of the lock bit after it has been set
- CWE-1233: Security-Sensitive Hardware Controls with Missing Lock Bit Protection
- Device uses a lock bit for register write protection but missed to protect security sensitive registers
- CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code
- The device transfers bootloader code from Non-Volatile Memory to SRAM during the secure-boot process but does not have sufficient access control for the SRAM
- CWE-1262: Improper Access Control for Register Interface
- Memory mapped I/O registers act as an interface to hardware for software, but it has insufficient access control to those registers
- CWE-1314: Missing Write Protection for Parametric Data Values
- The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure
- CWE-1300: Improper Protection of Physical Side Channels
- A device doesn’t have sufficient protection mechanisms to prevent physical side channels from exposing sensitive information due to observable phenomena such as variations in power consumption, electromagnetic emissions, or acoustic emissions
An Electronic Control Unit (ECU) in a vehicle containing a microcontroller has multiple external interfaces, for example JTAG/Debug, CAN bus and Ethernet. CWE-1191 & CWE-1244 address weaknesses in test and debug interfaces but it can be extended to cover all external interfaces of the ECU. For example, it must not be possible for an attacker to read the boot code via JTAG. This can be expressed in terms of information flow.
There should be no information flow from secure assets such as boot code in flash to the debug interface unless the access is properly authenticated. In addition, it should not be possible to modify or affect secure assets from the debug or any other external interface. Expressing the security requirement as an information flow requirement: There should be no information flow from JTAG, CAN bus or Ethernet to encryption keys in the crypto subsystem.
Control and Status Registers (CSR) are used to configure the ECU during secure boot. CWE-1231 & CWE-1233 address weaknesses related to protection of these registers. If a lock bit is set to prevent modification of certain registers after boot is complete, we need to ensure the lock bit can’t be cleared by an attacker. The requirement may be expressed as: There should be no information flow from any external interfaces to the lock bit at any time. We also need to ensure that all security affecting control registers are protected by a lock bit. This requirement may be expressed as: There should be no information flow from external interfaces or processors after secure boot to any security affecting CSR unless the lock bit is not set. In addition to the weaknesses listed in CWE-1231 & 1233, status registers may contain information that would assist an attacker and thus should be confidential i.e., there should be no information flow from the status registers to any external interfaces.
The boot process in an ECU involves copying and validating a boot loader and boot code from external Non Volatile Memory (NVM) to an internal SRAM. CWE-1274 & CWE-1262 identify weaknesses that could enable an attacker to interrupt the boot process and install his own boot loader or modify the code in SRAM after it has been validated. The security requirement says that there should be no information flow from external interfaces or a memory mapped register interface accessible to an attacker to locations storing boot code.
Vehicles contain multiple sensors that send information to ECU’s to be processed. The sensor itself could be replaced or damaged in a physical attack or the usage of the sensor information could be affected by an attacker as described in CWE-1314. To avoid the weakness, there should be no information flow from an external interface to any register that process sensor information.
The information flow requirements related to the CWEs listed above can be addressed by our Radix technology, except for CWE-1300 (side channel attacks). As the automotive industry moves forward with evolving cybersecurity standards, Cycuity is here to help. Radix enables semiconductor suppliers in the automotive space to efficiently comply with ISO/SAE 21434 by introducing systematic scalability and traceability to hardware security verification, simplifying the data collection needed for the compliance process.
For more information on incorporating CWE into your security program, download the “Measurable Hardware Security with MITRE CWEs“ white paper.