This article was posted on 03/28/2012

Authentication methods for automotive MCUs

New standards enhance automotive security and safety

In testimony to the U.S. Congress last year the Motor Equipment Manufacturers Association cited research estimating annual revenues lost to counterfeiting of components at $45 billion worldwide. Financial loss is just one of several problems that counterfeiting creates for both the original equipment manufacturer and aftermarket automotive supply chains; it also introduces potential risks to vehicle integrity and safety. With increasing use of electronic-based components, these risks are amplified. Fortunately, these electronic systems also hold the key to managing risk.

One long-recognized safety challenge is the practice of automotive chip-swapping and even chip tuning — changing the programming of the electronic systems of a vehicle. Manipulation of the factory settings of the application software or the calibration data seems, for some vehicle owners, to be a way to achieve better driving dynamics and more power in a vehicle.

However, altering performance through chip tuning is likely to lead to higher fuel consumption, higher exhaust emissions, higher wear and tear, and a safety risk. Preventing either swapping or tuning requires authentication and attack prevention mechanisms. To the extent that these mechanisms also protect against code manipulation, they provide security for the manufacturer’s intellectual property embodied in the system’s application code.

Industry initiatives, primarily driven by European auto manufacturers, are defining security architectures that have the potential to limit the financial loss of counterfeiting and protect the integrity of in-car electronic systems. One initiative has led to a specification called the Secure Hardware Extension (SHE). A second one, aimed at higher levels, is the Hardware Security Module (HSM).

SHE module functions, applications

A collaborative effort of five German auto manufactures addressed security issues as part of its mission of advancing the design of microprocessor based control units. The group released the SHE specification Version 1.1 in April 2009. The specification defines a module that protects secret keys against logical attack and reduces the risk of physical attack by avoiding use of global keys or series-specific passwords. The main cryptographic operations supported by the SHE are secure encoding and decoding of messages and authentication of messages and data of the various communication nodes.

Fig.1: ‘Secure Boot’ process of a SHE module in 32-bit MCU.

The SHE module supports a secure boot process — specifically, a check of the authenticity of the internal flash memory contents by means of digital fingerprint — every time the microcontroller is booted. Figure 1 illustrates a SHE module implemented in a 32-bit MCU. In a secure boot, the microcontroller runs a startup firmware from a boot ROM after a reset that checks the authenticity of the software sequence marked as SHE start program (bootloader).

After a successful check the stored program code is run and it is then decided whether further software sequences are to be checked successively before branching at the end to the unprotected parts of the application software. Another variety of the secure boot involves checking certain security-critical software sequences in the background after the application starts. This makes it possible to avoid delays in switching on the controller, and the reaction times in the controller network thus can be shortened.

The SHE module also supports secure communication between system nodes. The challenge-response-authentication method authenticates a communication node based on common knowledge. In this method a station sets a task that the other station must solve to prove that it knows certain information.

Depending on the encryption method used, there are numerous methods for this, all based on the same basic principle. If you want to authenticate one party (usually called Alice in cryptography) to another second party (usually called Bob), Bob sends, for example, a random number N to Alice. Alice encrypts this number N with its password and sends the result back to Bob. Bob has in the meantime encrypted the same random number with the password. If both encrypted messages are identical, Alice has authenticated itself. Such a security query can take place, for example, during the start phase, and then recur at certain intervals or at events.

Three applications of a 32-bit controller with SHE module implementation are described here:

Extended security architecture

In November 2011, a European-based project called EVITA ( presented the results of its work on security architecture for in-vehicle automotive networks. The EVITA project goals were to define an architecture that affords several levels of protection for security-relevant components in on-vehicle networks. The medium-security HSM variant is intended to protect on-board communication between ECUs.

Fig.2: HSM architecture implemented on multicore 32-bit MCU.

Whereas the SHE module operates using integrated control logic, the HSM (see Fig. 2) is equipped with a multitasking 32-bit processor. The 128-bit AES hardware accelerator, which in the SHE module contains ECB (Electronic Code Book) and CBC (Cipher Block Chaining), is extended with symmetrical computing modes such as CFB (Cipher Feedback), CTR (Counter Mode), OFB (Output Feedback for PRNG function), GCM (Galois Counter Mode) and XTS (XEX-TCB-CTS). A hardware accelerator for asymmetrical cryptographic computing operations is not added, since the goal of the medium HSM variant is the security of vehicle internal communication. If required for specific operations, asymmetrical operations can be realized on the 32-bit processor.

HSM has the ability to ensure that only authorized service centers can access an ECU. The challenge lies in opening a secured ECU within the local vehicle network temporarily to the outside for service work. Asymmetrical cryptographic methods are preferred because a whole fleet of vehicles can be equipped with only one public key without impairing the security of the whole series. To enable a service garage tester to be validated as authorized to access the ECU, the tester must have a private key issued by the vehicle manufacturer.

Fig. 3: SHE architecture is part of a currently available 32-bit MCU.

Hardware implementation

The EVITA project published the HSM specifications late last year and roadmaps are now defined for integration of the HSM with advanced multi-core automotive MCUs, including an upcoming 65-nm generation of the Infineon TriCore family. For powertrain and chassis system applications based on current-generation MCUs, the SHE module is implemented in TC179x microcontrollers with a clock speed of up to 300 MHz and a flash memory of up to 4 Mbytes. The module (see Fig. 3) checks the authenticity of internal flash memory by using digital fingerprint every time the microcontroller is booted. It has four main components:

Learn more about Infineon Technologies

Add Comment

Text Only 2000 character limit
Please login to comment on the article