Key steps to securing real-time systems in connected cars

As vehicles become increasingly connected, security has become a top priority for OEMs and the entire supply chain. This is driven by the need for over-the-air (OTA) software updates, remote diagnostics, and advanced driver assistance systems. However, these new capabilities also create new attack surfaces that can compromise safety and personal information.

Trends driving automotive security

The focus on security has also increased due to the adoption of zonal architecture over the traditional domain architecture. In the domain architecture, the electronic control units (ECUs) with similar functions are networked with each other in a subnet, resulting in many independent domains. The domains were divided into powertrain and transmission, body control, climate control domains, etc., and each of the domains could be developed to meet a different security level based on its criticality to the vehicles. However, in the zonal concept, the ECUs are networked to a local zonal controller and gateways. In zonal architecture the functions of various domain controllers are consolidated into a centralised controller. This consolidation decreases both the cost and complexity of the system, because of this zonal architecture is increasingly being favoured over domain architecture. One downside of the zonal architecture is that it requires ECUs from different domains to share the communication network which means all the ECUs in the zonal architecture need to adopt higher security standards.

To address security concerns in vehicles, government agencies and international standards bodies are requiring manufacturers to adopt new standards such as ISO/SAE 21434 and regulations like the United Nations Economic Commission for Europe (UNECE) WP.29 R155/R156, as well as other similar geography-specific regulations.

The UNECE regulation refers to the ISO 21434 engineering specifications and requires the implementation of a Cybersecurity Management System (CSMS). This system must cover the lifetime of the vehicle, from development to the end of the vehicle’s life. Over this lifetime, the CSMS requires monitoring of cyber threats and the implementation of a process to mitigate these threats. In some cases, the mitigation technique may involve patching the firmware in a vulnerable ECU in a timely manner. Therefore, OTA firmware updates have become necessary in all vehicles to meet UNECE regulations. The embedded system in the ECU needs to implement secure boot, secure firmware updates and secure communication to ensure a robust OTA firmware update.

Software and hardware security considerations

The secure boot feature is essential to establish the root of trust in the ECU, as the secure bootloader ensures that the firmware running on the device is authentic and has not been tampered with during and after factory production. Therefore, the bootloader is responsible for ensuring that the firmware which runs is genuinely from the OEM/Tier 1. The segment of the controllers’ memory that stores the secure bootloader needs to be immutable (or unmodifiable), as it should be write-protected and only one-time programmable during the initial factory programming. During the power-up sequence, the real-time digital signal controller runs the secure bootloader to check the authenticity and integrity of the application images.

The secure firmware update function can be in an immutable section of the real-time digital signal controller and is responsible for interacting with the central gateway using the vehicle network to receive the new application image. Since the application image carries the functional IP of the node, designers need to consider using encryption and node authentication over the communication interface to prevent exposing the firmware image. Figure 2a shows the memory map for a controller that has a firmware update feature. Typically, there needs to be three application sections: a section for the currently active image, a section to download the new image and a factory reset section to store the default image as a fault recovery mechanism. The firmware update also has to verify authenticity and integrity, just like the secure boot process, and it needs to implement an update policy like anti-rollback, where the firmware can only update to a newer version. The firmware update also needs to implement a system recovery method, which is beneficial in certain situations, such as when the active application image or the downloaded application fails an authenticity check.

To implement the above security use cases, the recommended approach is to use an external Hardware Security Module (HSM) paired with a security-enabled microcontroller (MCU) or Digital Signal Controller (DSC) or use an MCU/DSC with an integrated HSM in a single package. An MCU/DSC with an integrated HSM is advantageous when a design needs a compact form factor. Embedded Security Solutions with dsPIC33 DSCs for example support internal and external HSM. Both approaches are widely accepted by automotive OEMs. The HSMs serve as a security enclave where the secure key storage area and cryptographic function modules are separated from the main MCU/DSC system. This reduces the security risk compared to an MCU storing the keys in its internal memory. The security-enabled MCU/DSC complements an external HSM with features like immutable secure boot memory, One Time Programmable (OTP) Flash, and disabling entry into debug mode. An ECU platform based on an HSM and a security-enabled MCU family is easier to scale as you can move within the MCU family based on memory and feature requirements.

Cyber security is an endeavour that extends across the supply chain, from OEMs to component vendors

Development with either an external or integrated HSM requires in-depth knowledge of security and exploration of numerous configuration settings to meet an application’s security use cases and the target security profiles. Hence, it is important to start development with a tool ecosystem that features rapid prototyping hardware and graphical configurators. Another consideration is programming keys and secret data into the HSM during the product stage in a secure manner without exposing the secret information. This concern has been alleviated by some HSM semiconductor vendors by offering to securely provision the HSM. The pre-provisioned parts greatly ease the production challenges.

Modern ECUs are developed according to AUTomotive Open System ARchitecture (AUTOSAR). Hence, the security use case development needs the HSM and security-enabled MCU/DSC to be supported by off-the-shelf AUTOSAR software components. AUTOSAR has an inbuilt crypto stack that supports implementing security by offering several building blocks. Additional use cases, such as secure firmware updates, can be implemented using the crypto stack.

Conclusion

The market trend for connected cars leads to both privacy and safety concerns for government agencies, OEMs and drivers. Therefore, new regulations require cars to have comprehensive cyber security to protect data privacy and enhance safety. Cyber security is an endeavour that extends across the supply chain, from OEMs to component vendors. Designers can make use of either an HSM paired with a security-enabled MCU/DSC or use an MCU/DSC with an integrated HSM in a single package. Additionally, the ecosystem, such as rapid prototyping tools, libraries and graphical configurator for HSM, helps to simplify development. Off-the-shelf AUTOSAR libraries and provisioning support also reduce the development efforts. The ideal ecosystem for an automotive DSC or MCU needs comprehensive AUTOSAR support, ISO 26262 functional safety support, collateral for functional safety certification and security libraries.

About the author: Nelson Alexander is Principal Engineer and Product Marketer for Microchip Technology’s digital signal controllers business unit