Automotive ECUs: Architecture considerations to implement secure software updates over the air
August 03, 2017
Blog
With increasing recognition that our cars are evolving into rolling data centers, manufacturers are faced with the challenge of keeping software current.
With increasing recognition that our cars are evolving into rolling data centers, manufacturers are faced with the challenge of keeping software current. Part of the demand is driven by economics; the rising costs for recall actions make it essential that upgrades become automatic. At the same time, consumers are coming to expect the kinds of automatic upgrades that occur with their computer and mobile devices. An obvious step, therefore, is to use a mobile connection for software over the air (SOTA) updates. It has become relatively common to use SOTA updates in automotive infotainment systems, but there are security, safety, and convenience factors to consider before they can be implemented in the critical functional areas of automobiles. It is essential that the vehicle is protected against tampering and that the update process is reliable, fast, and does not in any way impair functional safety.
Researchers at IHS forecast the movement to SOTA updates will accelerate, estimating in a recent Automotive Report that potential savings through SOTA will grow from around $2.7 billion in 2015 to more than $35 billion in 2022 (Figure 1). Reduced recall costs, faster feature updates, and greater customer satisfaction are good reasons for automotive manufacturers (OEMs) to introduce SOTA.
[Figure 1 | Significant cost savings are the primary motivation for SOTA]
Implementing SOTA for electronic control units (ECUs) is much more demanding than for infotainment applications. Typically, microcontrollers with embedded flash are used to control real-time applications in the automobile. When performing updates, quality, safety, and security standards must be upheld. Vehicle safety must not be comprised by poor data security.
Without effective security, SOTA updates are vulnerable to attacks aimed at manipulating safety-critical applications in the vehicle. This potentially jeopardizes the security of the whole vehicle and in the worst case the lives of its occupants. A complex security architecture that supports the use of certificates and private keys as well as cryptographic operations is needed to prevent this. Suitable cryptography is based on standard algorithms such as RSA, ECC, AES, and SHA. Security microcontrollers have security functions and features of this kind.
The SOTA process and the necessary security architecture
Apart from the security and safety aspects of SOTA integration, it is extremely important for automobile manufacturers that the vehicle’s existing system architecture is minimally affected and that maximum availability is guaranteed, i.e. the update time during which the vehicle has to remain stationary is minimized. Of particular interest in this regard are the existing on-board network architecture and special requirements at the ECU level. These are addressed below.
Previously, reprogramming an ECU (or the whole vehicle) meant a trip to the garage. Updates of this kind use a diagnostic tool that plugs into the onboard diagnosis (OBD) socket. The diagnostic tool manages the complete update process (specifically the download of the new software or service pack), distribution to the target ECU, and final verification. OEMs want to keep a similar mechanism for SOTA if possible. For SOTA, therefore, the functionality of the diagnostic tool needs to be transferred to a central point in the on-board network architecture, and provided with the required functions for the additional SOTA process.
A SOTA update is typically performed in successive steps. Once a new software package has been produced and given a security “wrapper” (encryption and signature), communication with the target vehicle takes place. A secure connection is established between the vehicle (as client) and the OEM update server. The vehicle and the server platform carry out mutual authentication, and set up a secure, encrypted transport channel with transport layer security (TLS), to deliver the new software package to the vehicle. After initial verification, the update is stored in central memory. This stage of the update takes place in the background, without informing the driver or affecting the vehicle’s behavior while driving. The actual update process does not begin until initiated by the driver when the vehicle is safely parked. How long it takes can vary (from seconds to several minutes) depending on the bus architecture and intermediate storage location.
Architecture for SOTA
The vehicle architecture for SOTA can basically be subdivided into three ECU blocks in which different security microcontrollers perform different security functions: telematics controller, central gateway, and target control unit (Figure 2).
[Figure 2 | The main functional blocks for SOTA implementation: telematics unit, central gateway, and target ECU]
The telematics unit connects to the OEM server via its mobile radio interface and carries out the service authentication. For security reasons, implementation of a dedicated security controller (i.e., a Trusted Platform Module, or TPM) is recommended for this critical authentication function. An independent microcontroller (MCU) also is used in addition to the actual application controller for the secure connection to the vehicle network.
The MCU in the central gateway supports verification and intermediate storage of the received software. It would also be possible to move the security-critical authentication functions from the telematics unit into the gateway. In this case, it is recommended to position the TPM in the gateway, which can then take on other important security functions such as central key management.
The actual update is carried out in the target ECU after initialization by the driver. The data package is transferred from the memory to the target ECU, where it is decrypted, verified again and finally “flashed.” All of these security-relevant functions are supported today by automotive-grade MCUs.
Secure authentication and verification with “trust anchors”
As described above, security controllers, known as “trust anchors,” perform dedicated security functions to prevent manipulation and malfunctioning, especially during updates to critical safety-relevant applications. A TPM is a standards-based, certified security controller that can be used specifically for the critical authentication function. Its task is to ensure that only authorized devices can send data to the vehicle.
The TPM executes all the encryption algorithms for authentication. It saves long-term certificates and private keys for this purpose in a protected domain. TPM 2.0 supports the latest algorithms such as ECC, RSA, AES, and SHA 256. The TPM can be cryptographically linked to the application processor. The TPM’s key memory is scalable and can be safely loaded onto the application processor’s external memory. OEMs are therefore able to save further authentication certificates.
The TPM is produced in a security-certified manufacturing process in which a first key is securely saved in the TPM. The level of protection (e.g. against hardware or side-channel attacks) is much higher in a TPM than it is in a Secure Hardware Extension (SHE) module or Hardware Security Module (HSM). However, all MCUs concerned should have one of these integrated security modules to assure end-to-end protection.
Typical cyberattacks manipulate a system in such a way that it executes non-specified operations. To prevent this, systems are often broken down into different, isolated security domains. The TPM is an example of an isolated security domain which stores the asymmetric keys in a separate, protected environment and uses them for cryptographic procedures. Automotive microcontrollers also have isolated security domains defined. The HSM can isolate security functions from the application domain. A first important step is an integrity check on the program memory in the microcontrollers that are involved at the beginning of the driving cycle via secure boot; both SHE and HSM check the memory contents using a cryptographic checksum.
An MCU with embedded HSM also performs the vital verification of the received software. The verification process benefits from the HSM’s powerful encryption accelerators and fast communication buses. This verification is carried out by the gateway MCU using the HSM. Since the firmware verification only uses public certificates, the security requirements are lower than for the authentication process.
In the SOTA context, the HSM can also be used for an on-demand integrity check. In our example, both the telematics unit and the gateway securely exchange their integrity status, and only then start the software update. A similar procedure can be implemented on the target ECU. The target ECU also uses the HSM, but a secure flash bootloader (SFBL) is responsible for receiving and verifying the update. The difference between a flash bootloader (FBL) and an SFBL is that the latter implements additional encryption algorithms. The bootloader itself should be excluded from any SOTA update process. Because a vehicle can be attacked while it is being driven, the capability for an on-the-fly check of the application software is a key advantage of the HSM over the SHE module.
Designed for maximum availability
Authentication and related security functions are usually performed inside the gateway ECU, where the new software package is temporarily stored in central memory after it is downloaded from the OEM server. Since the new software has to get from the gateway’s central memory to the target ECU, the respective network topology has to be considered as it varies between OEMs. Essentially there are three different approaches (Figure 3).
[Figure 3 | Various approaches for secure OTA firmware updates: conventional method with central gateway memory, A/B swap with two flash memory blocks, and the method with extra local memory]
In the “conventional” method, to update an individual ECU, the relevant new software package is loaded from central memory via the onboard network into the embedded flash memory in the target ECU’s microcontroller. This is done in one step – there is no need for any hardware changes regarding the ECUs. The main limitation is bus speed, which determines how long the update takes. Table 1 shows the data rates for common bus systems. Let’s assume a service pack of 4 MB, as appears in the table. In this case, it will take almost five minutes to update a single ECU via the CAN bus; with 20 ECUs the vehicle will be out of action for more than 1.5 hours. Although there are various methods to increase throughput (clustering CAN bus sub-domains or data compression), they all lead to increased complexity and costs.
[Table 1 | Comparison of data transfer rates for various bus systems]
Another approach is the A/B swap. There are two blocks (A and B) in the flash memory for executing the code inside the microcontroller. The software download from central memory to the target ECU and reprogramming the free chunk of memory (e.g. block B) can happen in the background while the vehicle is in use and take as long as necessary. In the meantime, block A is unaffected and can continue to be used to execute the current code. Once all ECUs are “pre-programmed” in this way, the controller switches code execution from block A to block B. The swap process is finalized after a restart. This method has the great advantage of practically non-existent downtimes. The disadvantage consists in higher costs for the larger flash memory and additional validation mechanisms to rule out any impact on functional safety. Additionally, many microcontrollers do not support “swapping” yet.
A third approach aims to combine the advantages of the first two approaches: An additional “external memory at ECU level” is provided. The new service is loaded into this external memory in the background while the vehicle is in use, and here it waits until the actual update process. This method exploits the fact that modern microcontrollers such can very rapidly erase and reprogram their flash memory. For example, 4 MB can be erased and reprogrammed within 8 seconds from the external local memory via the SPI interface. The main benefits of this approach are minimal intervention in the existing system design, manageable extra costs, and small dimensions for the additional memory element. Table 2 offers a comparison of the three methods discussed.
[Table 2 | Advantages and disadvantages of various approaches for SOTA firmware updates]
Conclusion
An over-the-air update capability for software in cars promises great savings for the automobile industry and an improved ownership experience for customers. However, adequate security provisions need to be put in place to prevent illegitimate access to the vehicle and its safety-critical applications. Appropriate microcontrollers and additional dedicated security controllers at critically important points offer optimized functionality to safeguard SOTA. Apart from specific security measures, OEMs also need to consider how they can minimize vehicle downtime during the update process, and hence the impact on the driver, through an optimized network architecture and memory strategy.
eletter-08-03-2017 eletter-08-04-2017
