Keywords

1 Motivation

According to a publication by the MEMA Brand Protection Council [1], the global financial losses owing to forgeries amounted to 600 billion US Dollars in 2008. MEMA highlighted losses by the automobile industry of some 12 billion US Dollars (USA: 3 billion US Dollars, Europe: 9 billion US Dollars).

The forecast (Frost and Sullivan) for 2011 predicted an increase to over 44.7 billion US Dollars. While mechanical plagiarism (from windscreen wipers to oil filters to brake pads) has accounted for the majority of this to date, the number of cases involving falsified electronic components is on the increase and, apart from theft and replacement of controllers as well as chip tuning, is resulting in significant losses in the automobile industry.

Such offenses surely cannot be regarded as trivial if one considers that falsified or modified vehicle components:

  • Represent a not inconsiderable security risk both for the passengers and also for service personnel. The risk increases disproportionately with the complexity of the components.

  • Can result in the loss of valuable jobs.

  • Can endanger the image of established brands and lead to spurious liability claims.

  • Involve organized criminals.

It must also be considered that the intellectual property both of the vehicle manufacturers and the suppliers lies to a large extent in the software and therefore can in the case of inadequate protection represent easy prey for fraudsters.

The excerpt below is structured as follows:

Following an overview of the current implementation and application of the SHE module, a detailed comparison with the future HSM module is performed. In addition, other security measures implemented by Infineon are explained in relation to hardware interfaces, storage protection and chip ID. The article concludes with an appraisal of other possible application areas, a summary and a projection of future developments.

2 Secure Hardware Extension

The Secure Hardware Extension (SHE) is based on the Hersteller (manufacturer) Initiative Software (HIS) to which the OEMs Volkswagen, BMW, Audi and Daimler belong [2]. Infineon’s SHE implementation is based on the specification Version 1.1 dated April 01, 2009 of the HIS consortium (AK Security). The Secure Hardware Extension (SHE) is an on-chip extension for microcontrollers in the automobile area. The intention is to move the control of cryptographic keys from the application domain to the hardware domain and in so doing protect the secret keys from software attacks. In contrast to more robust solutions such as Trusted Platform Module (TPM) chips or smartcards, the specification declares that no resistance is needed in the face of physical attacks (such as differential power analysis (DPA), electromagnetic analysis (EMA), attacks with interference pulses). The priority is more so to reduce the risk of an attack to a commercially acceptable level. This means that the costs of a physical attack must be higher in any case than the possible financial gains that can be hoped to be achieved with a successful attack (e.g. through avoidance of global keys or series-specific passwords). Therefore, if a costly successful attack on a security system in a car only leads for example to the obtaining of a vehicle-specific crypto key, which cannot be transferred to the next automobile, then the effort required for a chip tuner for example is not in proportion to the effort invested in terms of the benefit gained.

The primary declared objectives of HIS can be summarized as follows according to [3]:

  • Protection of cryptographic keys against software attacks

  • Provision of an authentic software and hardware environment (referred to below as a “secure boot”)

  • Exclusive dependency of the target security level on the strength of the underlying computational algorithm and the confidentiality of the cryptographic keys

  • Distribution of ownership of keys to a number of electronic components (controllers)

  • Optimum flexibility with respect to provision and lower add-on costs (for example the possibility to exchange the key in the workshop)

2.1 Overview on Current Implementation

The SHE module has thus far been implemented by Infineon on the TC1798, TC1793 and TC1791 microcontrollers in 90 nm flash technology. These microcontrollers are the three premium components of the AUDO MAX family [4]. With an internal clock frequency of up to 300 MHz, the components are based on the TriCore™ CPU and were designed especially for powertrain and chassis applications. Apart from excellent real-time capability, development focused on the aspects of functional safety and data protection.

Figure 1 shows the arrangement of SHE within the AUDO MAX architecture. The module comprises the following four main hardware components [3]:

Fig. 1
figure 1

SHE architecture

Full size image

  • A hardware accelerator for symmetrical block ciphers based on the encryption standard AES-128 [5]

  • A true random number generator (TRNG) for generating 128-bit random numbers

  • A memory for storing cryptographic keys and data

  • Control logic for managing the arithmetic operations and memory access within SHE.

SHE (as well as HSM) relates to a hardware software co-design. The entire security concept only takes effect if the hardware is supported by corresponding application software and processes. The hardware components are described in detail below before their application is discussed in greater detail.

2.1.1 AES-128 Hardware Accelerator

All cryptographic operations of SHE are performed based on AES-128. The Advanced Encryption Standard (AES) is a symmetrical encryption algorithm that was published as a successor to DES and 3DES in October 2000 by the National Institute of Standards and Technology (NIST). The AES-128 variant has a fixed block and key length of 128-bits each. A hardware accelerator was implemented for the AES-128 block ciphers in order to speed up the cryptographic operations. The main cryptographic operations supported by SHE include the secure encryption and decryption of messages as well as the authentication of messages and data of various communication partners (external and internal hardware components):

  • The AES-128 hardware accelerator supports the two operating modes ECB (Electronic Cipher Codebook) for individual 128-bit data blocks and CBC (Cipher Block Chaining) for larger data volumes (n × 128-bit blocks) for encrypting and decrypting messages. Encryption and decryption of an individual 128-bit block is performed in both operating modes within <1 μs.

  • In cryptography, Message Authentication Code (MAC) refers to the generation of a digital fingerprint for authenticating a sent (unencrypted) message. It therefore provides protection against undetected manipulation of the sent message. A secret key issued to the sender and recipient is required beforehand. The sender generates the MAC based on the secret key and the message being transmitted (plain text). The message and MAC are transmitted. The recipient likewise generates the MAC from the message received and compares it with the MAC sent by the sender. The SHE module uses hash functions to create the MACs. “A hash function h can be defined here as a mapping \( {\text{h}}:{\text{ A}}^{*} \to {\text{A}}^{\prime \prime} \), which can be used to convert character strings of any length (character block) \( {\text{x}} \in {\text{A}}^{*} \) to character strings \( {\text{h}}\left( {\text{x}} \right) \in {\text{A}}^{\prime \prime} \) of a constant length n [5]”. The function value h(x) is called the hash value, hash code or also message digest of x. An iterative hash function is also referred to as a compression function. SHE uses the method based on Miyaguchi-Preneel as the compression function in order to generate hash values by means of AES-128 block ciphers and secret keys. A MAC based on block encryption is also referred to as CMAC (Cipher-based MAC).

2.1.2 Random Number Generator

The SHE module uses a pseudo random number generator (PRNG) to generate 128-bit random numbers for challenge-response authentication (see Sect. 3.2.2). The start value is generated by means of a true random number generator (TRNG). The task of a pseudo random number generator is to generate a bit sequence that cannot if possible be differentiated by means of statistical analysis from a real, random bit sequence. This means that:

  • The bits are distributed uniformly, therefore the same number of zeros occur as ones.

  • A specific bit in the sequence cannot be derived from the others, therefore is independent of the preceding and subsequent bits.

The TRNG implemented corresponds in all operating modes to at least the classification “P1 medium” under [6]. The pseudo random generator uses the AES-128 hardware accelerator in the ECB operating mode with PRNG_KEY as the key for calculating the feedback function. The random number generator is used for challenge-response authentication and for generating the initialization vector for CBC coding.

2.1.3 SHE Memory Area

The SHE module is attached to the peripheral bus and as the bus master can therefore initiate data transfer from and to other peripherals as well as memory areas. 48 Mbytes of RAM and a 2 × 8 kByte data flash have been implemented for storing confidential keys, MACs and temporary data. Access to this memory area is blocked for all other bus masters. SHE has write or read access to the separate flash area.

2.2 Application of the SHE Module

2.2.1 Secure Boot

A main requirement with respect to SHE is the enabling of a secure boot process, i.e. the checking of authenticity of the internal flash memory content each time the microcontroller boots. A short software routine is executed for this purpose immediately after the reset (part of the Boot ROM code of the application processor) and before the actual application software. This routine checks a memory area, which is referred to as the SHE boot loader, by calculating a CMAC (Miyaguchi-Preneel process with BOOT_MAC_KEY as the secret key—see 3.1.1). The result is compared with the expected value (BOOT_MAC) stored in the secure flash area. If the calculation does not arrive at the expected result (e.g. through prior manipulation of the memory content or by booting from external memory), the keys can be locked explicitly in the flash memory (see 3.1.3). As soon as the initialization of the microcontroller has concluded, the SHE boot loader is first executed. This can in turn initialize the checking of the other memory areas. The concept is based on the idea of “core root of trust for measurement” (CRTM) as proposed by the Trusted Computing Group [7].

The size of the tested memory area can be freely selected. The AES hardware accelerator used allows checking of 128 kBytes of the integrated flash memory in <10 ms. A further variety of the “Secure Boot” operating mode is the checking of certain security critical software sequences in the background following the start-up of the application. Delays while powering-up the controller can be avoided in this way and thus appropriately short response times can be achieved in the controller network cluster. Following authentication or unsuccessful authentication of a software sequence, it can then still be decided how a controller will react (for example because of an error entry in the error memory).

2.2.2 Challenge-Response Authentication

The challenge-response method is a secure authentication procedure used by a communication partner based on shared knowledge. One partner presents a question (“challenge”) and another partner must provide a valid answer (“response”) to prove s/he knows certain information. Depending on the encryption method used, a variety of different methods can be used, all of which are based however, on the same basic principle. If one partner (generally referred to as Alice in cryptography) wants to authenticate him/herself to another partner (generally referred to as Bob), Bob for example sends a random number N (Nonce) to Alice (Bob therefore presents the challenge). Alice encrypts this number N with her password and sends the result back to Bob (and therefore delivers the response). Bob has meanwhile encrypted the same random number with the password known to him for Alice and compares the result of this encryption with the response that he gets from Alice. If the two encrypted messages are identical, Alice has successfully authenticated herself. What is important here is that the partners do not transmit the password, rather simply have to prove that they know it. Such a security request can take place, for example, during start-up and can recur periodically or for predefined events.

A series of application cases arise of which three will be depicted below by way of example:

  • Electronic immobilizer: The immobilizer is activated automatically when the ignition is turned off. An RFID chip (radio frequency identification) is generally used to disable it again when switching on the ignition. In the case of the current third generation immobilizers, both the communication between the RFID transponder and the immobilizer (authentication of the approved driver) and the communication between the immobilizer and the engine control unit (release of vehicle/starting of engine) are secured cryptographically by means of challenge-response authentication.

  • Component protection: Following conclusion of the secure boot process, the domain controller (gateway ECU) for example checks the authenticity of the controllers of the associated system domain. According to the manufacturer’s guidelines, a variety of controllers meanwhile participate in the authentication queries. In the case of stolen or exchanged controllers, the cryptographic keys do not match and the component protection prevents the actual application software from booting for example (incl. air conditioning, CD changer, dashboard displays, body gateway).

  • Protection against chip tuning: Chip tuning, i.e. the subsequent modification of application software supplied ex works or calibration data, seems at first glance to be a temptingly easy way to increase driving dynamics and improve performance. Increasing the performance by chip tuning general produces results that vehicle manufacturers would prefer to avoid. Such results include shorter lifespan, deteriorating exhaust emission values or higher wear and tear. This gives rise to quite a significant risk potential. The chip internal flash memory (embedded flash) in the microcontroller is used almost exclusively today for storing the application software and calibration data. This gives rise to two potential attack scenarios—replacement of the microcontroller by a copy or manipulation of the memory data by means of a programming device via external memory or debug interfaces. The first procedure can generally be eliminated owing solely to the complexity of the chip package used (and can moreover be suppressed by the component protection described above). Challenge-response authentication therefore reliably prevents replacement of the microcontroller for a newly programmed off-the-shelf device. Furthermore, a series of additional measures are provided in the microcontroller hardware that protect against unauthorized reading of the memory content and also prevent the code in the internal program flash (PFLASH) area from being modified in an unauthorized manner by third parties for the purpose of engine tuning. Some of these additional measures are described in greater detail in the next section.

2.3 Additional Protection Mechanism

Among the additional protection mechanisms of the TriCore™ microcontroller family is the possibility to block read and write access to the internal flash memory (Read and Write Protection), as well as the option to lock the external debug interfaces (depending on the respective boot mode and selected memory protection). The primary goal is to protect both the IP of the vehicle manufacturer and the supplier against “Reverse Engineering”.

If the entire memory area is blocked with respect to read access, this automatically protects the entire memory against write access also (this protection can be disabled separately for the data memory). Furthermore, a choice can be made between write and OTP (One Time Programmable) protection for each individual sector of the program memory. OTP protected sectors are locked in this case to prevent further deletion and from this point on offer ROM functionality. Readout protection as well as sector-specific write protection can be disabled temporarily for a driving cycle via password protection. If read protection is activated and the program boots from the internal flash memory, the external debug interfaces are locked automatically.

Read protection can be canceled temporarily by means of a 64-bit password in order for example to change access rights or perform a programming action. Since only one (correct) attempt is permitted per boot cycle, up to \( 2^{64} \) attempts are required in order to hack the password (with 2 ms per boot cycle, this could take theoretically up to 1.17 billion years, which corresponds to approx. 26 % of the estimated scientific Earth age).

3 EVITA

3.1 Project Overview

The Hardware Security Module (HSM) presented below is a specific implementation of the hardware security extension presented in the framework of the European Research Project EVITA [8]. The aim is to create a secure system architecture for exchanging data within the vehicle as well as for external communication (vehicle to vehicle and vehicle to infrastructure). The objective here, as with SHE, is to protect the platform integrity, provide secure communication channels, access control, and detect and prevent infiltrations. In contrast to SHE, HSM is multi-tasking capable however and also offers programmability of additional cryptographic functions.

3.2 Overview of the Different HSM Variants

In order to enable optimally cost-effective hardware solutions for the various application scenarios in the automobile industry, three different HSM variants have been specified [9, 10]:

  • The HSM full version for protecting the vehicle’s board net from external attacks in the case of V2X communication. The variety of communication partners requires continuous creation and checking of electronic signatures. By using asymmetrical rather than symmetrical encryption, the key distribution problem, i.e. the distribution of keys via an unsecure channel, is simplified considerably. The total number of required keys is also comparatively small (2 keys per party). These are two criteria that favor the use of asymmetrical encryption owing to the variety of communication partners involved in V2X communication. However, this goes hand in hand with significantly increased computational effort (100–100 times slower than equivalent symmetrical encryption) and relatively large key length. To fulfill these performance requirements, a highly efficient asymmetrical cryptographic processing unit is required for the full version. In addition, the AES-128 hardware accelerator is extended by additional operating modes in comparison with SHE.

  • The medium HSM variant for protecting on-board communication. Owing to the limited number of communication partners (approximately 50 controllers for a medium class vehicle) and the possibility to exchange the key, for example, during end-of-line programming, asymmetrical cryptography can be foregone with the medium variant. With the exception of the missing asymmetrical cryptographic module, the medium HSM variant is similar to the full version. Depending on the processing performance of the CPU used, there is also the possibility to execute fewer time-critical asymmetrical encryption operations in software.

  • The HSM light version for secure communication between controllers, sensors and actuators. Only a symmetrical cryptographic processing unit is required in this case and a hardware interface reduced by the corresponding range of functions.

4 Extension to the Hardware Security Module

A detailed explanation was given in the last section which security applications are candidates for the various HSM variants (Light/Medium/Full) in the framework of the EVITA project. The current implementation of the SHE module within the Infineon 90 nm AUDO MAX Premium Controller TC179x assumes a mixed form when classified in the existing EVITA nomenclature, which fits in somewhere between Light HSM and Medium HSM.

When defining the next 65 nm powertrain microcontroller, Infineon took into account the customer’s requirements to develop some security functions in the direction of the Medium HSM hardware approach of EVITA.

4.1 Objective of Infineon

Having committed itself in the case of the automotive microcontroller applications mainly to application areas such as Powertrain (PT), Hybrid and Electrical Vehicle (HEV and EV) as well as active and passive Safety, it stood to reason to use the security hardware classification described in the EVITA project as a basis and to align it to the customer’s requirements. The result was clear and excludes the use of a special asymmetric hardware extension as described in the Full HSM approach. In concrete terms, this refers in particular to future driving operation-related communication services for vehicle to vehicle communication, which by preference use asymmetrical cryptographical methods based on hardware accelerator algorithms such as ECC-256 (Elliptic Curve Cryptography) or special symmetrical AES hash methods such as WHIRLPOOL for ensuring a secure communication channel.

The HSM implementation selected by Infineon will therefore focus on secure vehicle-internal communication. Compared with the already established SHE architecture, the HSM module is equipped however with a flexible, multi-tasking capable 32-bit processor. Furthermore, the 128-bit AES hardware accelerator is extended beyond ECB (Electronic Code Book) and CBC (Cipher Block Chaining), to include additional, higher-performance symmetrical processing modes such as CFB (Cipher Feedback), CTR (Counter Mode), OFB (Output Feedback for PRNG functions), GCM (Galois Counter Mode) and XTS (XEX-TCB-CTS).

4.2 Overview of the Implementation of the HSM

The aim of the HSM implementation (Fig. 2) is to develop an optimally flexible and high performance freely programmable microcontroller security subsystem, which can perform its tasks autonomously in the background completely independently of the primary application.

Fig. 2
figure 2

HSM architecture

Full size image

The implemented HSM IP essentially comprises the following IP blocks:

  • 32-bit processor with up to 100 MHz CPU processor speed

  • MPU (Memory Protection Unit)

  • Dedicated, local 24-40 kByte SRAM area (ECC protected)

  • Local ROM for autonomously booting the HSM

  • HSM password or OTP protected PLASH code sectors (2 × 64 and 1 × 16 KB)

  • Separate data flash (DFLASH) as key memory (non-readable and non-writeable for application software)

  • High-performance 128-bit AES hardware extension:

    • Supported modes: ECB, CBC, CTR, OFB, CFB, GCM and XTS

    • Data throughput:

      • Minimum 25 MByte/s @ 100 MHz for secure boot (Hashing for SHE: At least 10 MByte/s)

    • AES pipelining with separate, associated contexts for processing five data streams in time multiplexing mode

    • Context, operating modes and up to eight keys can be combined arbitrarily

  • True Random Number Generator (TRNG) based on AIS 31 “class P2 High” classification

  • Defined bus interface with firewall to the application software

  • Register for defined interrupt generation in both directions

  • 2 × 16-bit general purpose timer.

The HSM subsystem is started following a cold start (e.g. driving cycle with terminal 15 on) by means of an integrated local boot ROM and can start working in the background without any knowledge of the main application software.

Nevertheless, communication is possible at all times with the software tasks implemented in the controller via the integrated defined application interface with firewall functionality. For example, all SHE functions can, as described in the specification Version 1.1 of the HIS Consortium (AK Security) [3], be emulated from a combination of software and hardware functions. Discussion in the AUTOSAR Consortium is likewise already focusing heavily on AUTOSAR compatible security extensions, which ultimately will communicate in the future with the HSM module via a security framework API layer that is yet to be defined.

4.3 Comparison with SHE

As already mentioned in the last section, emulation of the complete SHE functionality with the accordingly specified features by means of the HSM hardware including a corresponding SHE software layer is possible at any time.

In addition, the following functions are also offered in the HSM extension:

  • The 128-bit AES hardware accelerator unit was extended beyond the ECB and CBC modes already required in the SHE specification to include the CTR, OFB, CFB, GCM and XTS modes.

  • With five free contexts in the AES unit and up to eight different keys and in conjunction with a flexible processor software layer, the system is now multi-tasking capable in contrast to the existing SHE implementation.

  • 2 × 16-bit general purpose timers extend the flexibility of the system.

  • The freely programmable 32-bit CPU enables the implementation of asymmetrical cryptographic algorithms in software (e.g. ECC-256) if these can get by with a lower performance. This should suffice at least for less time-critical asymmetrical cryptography, which for example could come into question for secure communication between the electric vehicle and charging station or control unit and the workshop tester.

4.4 Applications of the HSM Module

Further potential applications of the HSM extension compared with those already outlined in SHE Sect. 3.2 are:

  • Secure sensor communication e.g. on PSI5 bus in conjunction with an EVITA light module on a pressure senor

  • Secure communication to a workshop tester by starting with an asymmetric challenge-response authentication followed by a Deffi-Hellman to establish a session and then continued symmetrically. The necessary routines can thereby run on the freely programmable 32-bit CPU of the HSM module

  • Secure communication between electric vehicle (EV) and the charging station (implemented in a similar manner than the communication to the workshop tester)

  • Secure mileage storage to prevent tachometer turning.

5 Summary and Outlook

Based on the Secure Hardware Extension (SHE), the 90 nm TC179x powertrain microcontrollers already support a modular hardware and software security concept for automotive use. Thanks to the subsequent extension to the Hardware Security Module (HSM) of the 65 nm generation, new applications are opening up both in the area of engine and transmission control and in areas such as eMobility and active and passive safety.

At this point we would like to thank the Hersteller Initiative Software (HIS) Consortium as well as our partners from the EVITA project for their consistently good and constructive cooperation.