CycurHSM An Automotive-qualified Software Stack for Hardware Security Modules Dr. Frederic Stumpf, ESCRYPT GmbH Embedded Security, Stuttgart, Germany 1 Introduction Electronic Control Units (ECU) are embedded systems that process information from different vehicle sub-systems, such as sensors or other ECUs, and control actuators to react on system events accordingly. One prominent example for ECUs is the engine control unit which is responsible for controlling a series of actuators on a combustion engine to ensure optimal engine performance. The engine's actuators are controlled based on complex system parameters, such as ignition timing, and are configured and adapted to the specific motor characteristic during vehicle production. Manipulation of these critical system parameters is an interesting attack target since manipulations may yield in modified motor characteristics which may give an attacker the ability to improve the performance of the engine. These attacks are commonly referred to as Chiptuning and are offered by an industry-wide tuning sector. The motor control unit is only one out of many ECUs which is susceptible to attacks. Other attacks on ECUs may cover the unauthorized activation of vehicle features or circumventions of the immobilizer system of a vehicle [HS11]. Due to the increased networking of ECUs and the fact that ECUs carry out more and more sensitive tasks, the attack surface and the resulting financial loss caused by a successful attack on an ECU will grow significantly in the near future. In addition, successful attacks on one ECU endanger the whole vehicle board network and can have an impact to the whole vehicle safety system, which at worst, may cause the safety-characteristics no longer being satisfied. In order to harden ECUs against attacks, security mechanisms which prevent reading out sensitive keying material and also prevent successful manipulation of the software of an ECU must be used. To provide the necessary trust primitives and resistance to physical attacks, the security mechanisms must be rooted in hardware. This approach prevents that sensitive information, e.g., cryptographic keys, are vulnerable to software attacks. Hardware Security Modules (HSM) are a promising technology to answer the requirements for such a secure hardware extensions for ECUs.
2 Automotive-qualified Hardware Security Modules Hardware Security Modules are dedicated hardware security components that encapsulate security functions and provide the necessary trust primitives. HSMs are integrated chips specifically developed and designed for security use-cases. Typically, implementations range from smart cards used for identification and authentication purposes, such as, national identification cards, to Trusted Platform Modules [Tru07] which are Hardware Security Modules for personal computers. HSMs typically consist of a CPU core, different types of data storages (e.g., RAM, ROM, Flash), a memory protection unit, a memory encryption unit, sensors, cryptographic accelerators, and further peripheral components. Most HSMs employ sophisticated countermeasures against physical attacks, such as active sensors to detect fault and glitching attacks, and also employ cryptographic implementations which are hardened against side channel attacks. However, typical Hardware Security Modules do not satisfy automotive requirements. Problematic characteristics that render integrating existing Hardware Security Modules as additional component inside of an ECU non-usable are especially: 1. High costs caused by integrating an external, additional chip inside an ECU 2. Sensitivity to attacks on the communication interface between ECU application core and HSM 3. The non-existence of debug/testing interfaces if a malfunctioned device needs to be analyzed 4. The high temperature range an automotive qualified product needs to satisfy The lack of existing technology has caused Bosch to develop an own HSM specification that satisfies automotive requirements [BGI+11]. In order to ensure a high market penetration, Bosch cooperated with the most important silicon manufacturers to ensure that the technology will be supported and implemented by a broad set of silicon manufacturers.
3 The Bosch HSM The basic architecture of the Bosch HSM is shown in Figure 1. Core of the HSM is a secure CPU where security critical tasks are executed. The HSM also possesses its own RAM, Boot ROM, AES engine as well as a True Random Number Generator (TRNG) as cryptographic peripheries. Parts of the HSM are also debug interfaces and an On-Chip Interconnect Interface which is used for communication with the host core and to access the flash. The host core is a typical automotive qualified application processor providing an execution environment for safety-critical tasks, achieved for example using additional lockstep cores. The flash is shared between host core and HSM, and the firmware both of the HSM and the host core is stored in shared flash. A memory protection unit (not shown in the figure) ensures that only the HSM is allowed to access its own HSM allocated data located in the flash. When the HSM is powered up, the local boot code is loaded from the boot ROM and the HSM is initialized with the code stored in the shared flash. The HSM provides a method to enable debugging the HSM including read out of all data stored in the flash and the internal data of the HSM (besides internal AES keys). The debug interface can only be activated internally by the HSM after a secure authentication protocol (e.g., challenge-response authentication) between the HSM and one external debugger has been performed. Figure 1: Main Components of the BOSCH HSM While the detailed realization and implementation of the HSM varies between the different silicon manufacturers, the basic concepts of providing a secure execution environment based on an additional secure core, are the same for all silicon manufacturers that provide an implementation which is compliant to the Bosch HSM.
4 HSM Security Functions The HSM implements a set of security functions which can be used to realize complex automotive security use-cases. For this purpose, the HSM offers the following primitives: AES-128 bit engine in Hardware A True Random Number Generator for secure generation of cryptographic keys Hardware-shielded protected storage for cryptographic keys or secure logging A secure system timer to realize a secure, replay protected logging Secure debug under control of the HSM 5 CycurHSM - A Secure Software Stack for Automotive HSMs The new CycurHSM product from ESCRYPT is a security firmware specifically designed for the Bosch HSM and its derivates. CycurHSM will support all available HSM implementations from the different silicon manufacturers and provides a standardized API to access the HSM. Besides making the existing HW security peripherals of the HSM available to software executed inside the HSM and applications on the host core, CycurHSM also implements a full cryptographic library with asymmetric cryptography support. CycurHSM provides all necessary interface to integrate the HSM inside of a typical automotive ECU, i.e., it consists of an AUTOSAR interfaces, required device drivers, and a PKCS#11 interface for non-autosar applications. As a result, CycurHSM fully encapsulates all required security functions needed to satisfy a broad set of automotive security requirements. The innovative design of CycurHSM is based on a real-time operating system to also ensure real-time characteristics of the HSM that will be required in future use-cases, e.g., for secure real-time critical on-board communication with the involvement of HSM technology. 5.1 Software Architecture The software architecture of CycurHSM is shown in Figure 2. Core component of CycurHSM is RTA-OS from ETAS. RTA-OS is a real-time operating system specifically designed to meet all requirements of automotive ECUs. Further, RTA-OS provides minimal runtime overheads, a very small footprint, and a MISRA C compliant implementation. RTA-OS provides a two-layer protection level to isolate trustworthy kernel tasks from non-trustworthy user tasks, thus providing an additional protection concept for the software of the HSM. Each task on the HSM is executed with the least privilege level required, as a result, potential security vulnerabilities in one task, do not cause the whole system to become insecure. The CycurLIB security library from ESCRYPT provides additional cryptographic primitives (ECC, RSA) and directly uses the cryptographic accelerators available in hardware on the HSM. CycurLIB encapsulates all cryptographic algorithms and functions and provides an interface to applications executed on top of the HSM. The software of the HSM implements customer specific security applications that directly use the provided security functions available on the HSM made available using the CycurLIB. In addition to the CycurLIB, a SHE emulation module
is executed on the HSM. This module uses the CycurLIB security library as underlying primitive and implements the SHE specification [Sof09] with additional extensions to SHE to satisfy extended automotive requirements (denoted as SHE+). The functionality is made available to applications executed on the host core using the HSM driver. The functionality of security applications can be fully implemented on top of the HSM but can also be distributed between host core and HSM if required. CycurLIB and all additional customer specific software applications are executed in user-mode on the HSM. The HSM is communicating with the host core using a specific HSM device driver which ensures secure communication between HSM and host core. The HSM driver on the host is fully compatible to AUTOSAR and provides an interface based on the AUTOSAR crypto abstraction layer (CAL). In addition, it provides a PKCS#11 compliant interface. Figure 2: Main SW Components of CycurHSM
5.2 Security Functions and Use-Cases Based on the HSM, a broad set of use-cases can be implemented. Since the HSM provides a standardized interface to security functions based on strong cryptography, security applications can be either realized on the HSM, the host core, or using a combination of both. Supported uses-cases include, but are not limited, to the following: 5.2.1 Secure Boot Secure boot ensures that the integrity of code stored in the flash has not been compromised and is in a trustworthy state. This is achieved by checking the integrity of code before being executed during the initialization of the ECU. To this end, each component in the boot chain, validates the integrity of the following component in the boot chain before handing over control to the next component in the chain. The initial component is integrated as Core Root of Trust for Measurement inside the boot ROM which is initially responsible for initiating the boot process and for triggering the boot loader. The integrity is validated by computing a cryptographic hash value of the code and comparing it with a pre-configured hash value stored in secure storage of the HSM. If the computed result does not match the pre-configured value, the HSM prevents further execution of the code on the ECU. The secure boot is initiated and completely performed by the HSM itself, i.e., without any explicit call by the host CPU. Figure 3: Secure Boot process with involvement of the HSM 5.2.2 Runtime Tuning Detection Runtime tuning detection verifies the code integrity of the flash content during the regular operation of the ECU. The goal is to detect manipulations on the original ECU flash. Runtime tuning detection takes advantage that the HSM is realized as one additional core with full access to the flash of the ECU. As a result, the HSM can independently validate the code integrity of the flash without causing any impact or delays on the safety-critical applications executed on the host core. Typically, the runtime tuning detection is a low-prioritized task implemented on top of the HSM that walks through the flash storage in regular intervals and compares the integrity of the flash code with pre-configured measurements. If the runtime tuning detection tasks detects an anomaly, a secure log entry is created that gives information about the detected anomaly. As an alternative, the runtime tuning detection may cause a specific reaction to an event, e.g., causing the ECU to go into fail-safe mode.
5.2.3 Secure Flashing Secure flashing is the process of updating the software of the ECU in a secure manner. Secure flashing supported by an HSM is typically divided into three phases. First, the authenticity of the flashing request of an external diagnosis tester is verified by the HSM. For this purpose, a challenge-response authentication protocol using symmetric or asymmetric keys is performed. After the HSM grants access, the download of the software can be initiated (step 2). Alongside to the software, a cryptographic signature is transmitted which was created by a trustworthy entity, e.g., the manufacturer of the ECU, that vouches for the trust level of the code. After the code has been transmitted, the HSM checks the signature of the code. If the signature verification succeeds and the code fits to the ECU, the internal flash structure is updated with the new code (step three).
6 Conclusion Hardware Security Modules are a necessary building block to harden embedded systems against attacks. HSMs are dedicated hardware security components that encapsulate security functions and provide the necessary trust primitives. This article gives a high-level overview of the CycurHSM product currently under development by ESCRYPT. CycurHSM is a complete software stack adapted to the available implementations of the Bosch HSM by different silicon manufacturers. In addition, it provides an own SHE(+) emulation module on a secure core. The innovative design of CycurHSM is based on a real-time operating system to satisfy future upcoming requests to also meet safety requirements. Based on CycurHSM, a broad set of security applications can be supported. CycurHSM provides the technology for fulfilling the requirements regarding a flexible HSM firmware that provides open and standardized interfaces to HSM-enhanced security applications. The full comparability of CycurHSM to AUTOSAR ensures a broad applicability and the usage of the technology in different types of ECUs. Contact & Further Information Email Web info@escrypt.com www.escrypt.com ESCRYPT GmbH Embedded Security Lise-Meitner-Allee 4 44801 Bochum, Germany Phone: +49 234 43870-219 ESCRYPT Inc. Embedded Security 315 E Eisenhower Parkway, Suite 214 Ann Arbor, MI 48108, USA Phone: +1 734 418-2797
References [BGI + 11] [HS11] Oliver Bubeck, Jens Gramm, Markus Ihle, Jamshid Shokrollahi, Robert Szerwinski, and Martin Emele. A hardware security module for engine control units. In Proceedings of the 10th ESCAR Conference, 2011. Johann Heyszl and Frederic Stumpf. Asymmetric cryptography in automotive access and immobilizer systems. In Proceedings of the 10th ESCAR Conference, 2011. [Sof09] HIS Herstellerinitiative Software. She - secure hardware extension version 1.1. Technical report, http://portal.automotive-his.de/, 2009. [Tru07] Trusted Computing Group. TCG TPM Specification, Architecture Overview. Technical report, TCG, 2007.