SOTA – Secure software updates over the air

Extra memory in ECUs enables efficient implementation

Martin Klimke, Ines Pedersen, Bjoern Steurich, Infineon Technologies

Automobile manufacturers are facing rising costs for recall actions. A large part of these costs stems from faulty software, and the need to fix it. An obvious step, therefore, is to use a mobile connection for Software updates Over The Air (SOTA). While software updates OTA are now commonplace in mobile devices, there are security, safety and convenience factors to consider before they can be implemented in automobiles. It is essential that the vehicle is protected against tampering (security), and that the update process is reliable, fast, and does not in any way impair functional safety.

The basic motivation for software over the air (SOTA) implementation is clear. The market research company IHS estimates in a recent Automotive Report that potential savings through SOTA will grow from around US$ 2.7 billion in 2015 to more than US$ 35 billion in 2022 (see fig. 1). Reduced recall costs, faster feature updates and greater customer satisfaction are good reasons for automotive manufacturers (OEMs) to introduce SOTA. OTA updates for navigation data and infotainment applications are standard practice today. But implementing SOTA for electronic control units (ECUs) outside of the infotainment sphere is a particular technological challenge. Typically, microcontrollers with embedded flash are used to control real-time applications in the automobile. Quality, safety and security standards have to be upheld. Vehicle safety must not be comprised by poor data security. Hence the requirements are much more demanding than for infotainment applications, where consumer products are now often used.

Protection against cyber attacks

An inadequately protected SOTA implementation makes it possible for potential attackers to manipulate safety-critical applications in the vehicle thus jeopardising 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. Infineon’s security microcontrollers such as products in the AURIX™ and OPTIGA™ TPM families have security functions and features of this kind (see fig. 2).

The SOTA process and the necessary security architecture

The SOTA process is usually performed in multiple 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 then 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 (transport layer security, TLS). Via this channel, the vehicle receives the new software package. After initial verification, it stores it in its central memory. The new software is received and stored in the background, without informing the driver or affecting the vehicle’s behaviour. 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 (see fig. 3).

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 – an OPTIGA TPM (Trusted Platform Module) – is recommended for this critical authentication function. A microcontroller from the AURIX family is normally used in addition to the actual application controller for the secure connection to the vehicle network.

An AURIX microcontroller 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 initialisation 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 by AURIX microcontrollers.

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. The OPTIGA TPM is a certified security controller that can be used specifically for the critical authentication function. Its task is to ensure that only authorised 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 an SHE (Secure Hardware Extension) module or HSM (Hardware Security Module). However, all MCUs concerned should have both to guarantee continuous (end-to-end) protection.

Typical cyber attacks 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. One example is the TPM, which stores the asymmetric keys in a separate, protected environment and uses them for cryptographic procedures. Microcontrollers, however, also have isolated security domains. For instance, the HSM in AURIX microcontrollers 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 (SHE or HSM check the memory contents using a cryptographic checksum).

The AURIX microcontroller family with its 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 consists in additional encryption algorithms. The bootloader itself should be excluded from any SOTA update process. Because the vehicle could 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.

Maximum availability is crucial for customer acceptance

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 minimised. Of particular interest in this regard are the existing onboard network architecture and special requirements at the ECU level. These are discussed 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 at all possible. For SOTA, therefore, the functionality of the diagnostic tool needs to be transferred to a central point in the onboard network architecture, and provided with the required functions for the additional SOTA process. These 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 (see fig. 4):

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 – and this is done in one step. There is no need for any hardware changes regarding the ECUs. The main limitation is the bus speeds, which determine 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½ 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

A/B swap

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 finalised 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. Plus there is the fact that many microcontrollers do not support “swapping” yet.

A third approach attempts 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 at ECU level” 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 as the AURIX family 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. However, adequate security provisions need to be put in place to prevent illegitimate access to the vehicle and to safety-critical applications. AURIX microcontrollers and additional dedicated security controllers such as the OPTIGA TPM at critically important points offer optimised functionality for this essential safeguarding of SOTA. Apart from specific security measures, OEMs also need to consider how they can minimise vehicle downtime during the update process, and hence the impact on the driver, through an optimised network architecture and memory strategy.