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.
Figure
3:
Secure
Boot
The secure boot is initiated and completely performed involvement of the HSM
by the HSM itself, i.e., without any explicit call by the
host CPU.
process
with
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]
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.
[HS11]
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.