01

Security-related functions have been deployed in vehicles for a few years now. Cryptographic operations like encryp-tion and signature checking are used, for example, in immo-bilizers and in secure reprogramming of ECUs. A sustained trend towards connectivity is extending the functional scope of vehicles e.g. with over-the-air (OTA) software updates, remote feature activation and communication between vehicles and infrastructure (V2X). These use cases lead to the creation of interesting and very promising busi-ness models for the automotive industry. But the more connectivity grows, the greater the number of potential cyberattacks on vehicles.

Keys: The Basis for CybersecurityTo counteract the risks of cyberattacks, the automotive industry is implementing both its own specific security measures and/or deploying protocols from the traditional IT security field. For example, Secure Onboard Communica-tion (SecOC) [1], which is standardized in AUTOSAR, pro-tects communication between the ECUs within a vehicle

network. Depending on the bus technology and the specific application, for instance, the TLS (Transport Layer Security) and IPSec (Internet Protocol Security) protocols, which are familiar from the IT field, might be used. One trait that all modern security mechanisms must share is that their secu-rity is not based on the secrecy of the details of the employed cryptographic algorithm but rather on the confi-dentiality of the keys that are used. To improve security even more, any given key may only be used for one security mechanism.The growing number of cybersecurity applications results in the need for many ECUs to securely store large amounts of cryptographic material such as secret keys, private/public key pairs and certificates. The concepts of Key Storage and Vehicle Key management are often used in this context. Their differences are discussed below.

Saving Cryptographic Keys SecurelyRecent years have seen advances in the standardization of hardware support for cybersecurity. A special hardware

No Cybersecurity without Key SecurityProtect ECUs with standardized key managementMore and more, vehicles are being connected to external IT systems to support new functions and business models. To protect the connected vehicles against cyberattacks, cryptographic methods are being used whose security is based on the corresponding key material. But what challenges need to be addressed by key management? And what benefits are realized by its standardization within AUTOSAR?

02

Technical Article / September 2019

be considered in the following vehicle life cycle phases (Figure 3):1. ECU development: Saving initial keys in the ECU.2. Vehicle integration: Replacing initial keys with develop-

ment keys.3. Vehicle production: Replacing initial or development keys

with production keys. In addition, it is often necessary to install other key material from external sources or derive it from keys that exist in the vehicle. If secret keys are shared between the ECUs, the confidentiality and integ-rity of these keys must always be assured. For example, secret keys must never be sent over the bus in plaintext.

4. Aftersales and decommissioning: Updating or installing additional key material. For example, remote feature activation also requires suitable new keys. When replacing defective ECUs, steps must also be taken to ensure that no critical key material can be read out from the defective ECU or be manipulated in any way. And the new ECU must be supplied with suitable key mate-rial so that it can execute its functions.

Key Management StrategiesAn application that illustrates the wide variety of key man-agement strategies well is Secure Onboard Communica-tion. It is used to validate in-vehicle communication between ECUs. SecOC gives the receiver of messages the ability to detect a replay of recorded messages, check the authenticity of the sender and evaluate the integrity of the transmitted data. For this purpose, the receiver checks what is known as a Message Authentication Code (MAC). The MAC is essentially a cryptographic checksum which the sender generates and the receiver checks for validity. If the MAC check fails, the receiver rejects the message. For per-formance reasons, a symmetric cryptographic algorithm is used to compute the MAC.

unit in the microcontroller – the Hardware Security Module (HSM) – enables secure storage of keys and acceleration of cryptographic computations.The AUTOSAR Consortium has standardized a Crypto Stack within the basic software for modeling keys and using cryptographic services [2] (Figure 1). It offers standardized interfaces for accessing security functions, which are provided by a software-based library or by an HSM (Figure 2). This combination of hardware and soft-ware makes it possible to store key material efficiently and securely in ECUs.

Life Cycle of Cryptographic KeysIn vehicles, the use of keys is not limited to the regular daily operation mode. The topic of key management must also

Figure 1: The purpose of the AUTOSAR Crypto Stack is to model keys and to make use of cryptographic services.

Figure 2: Architecture of a Hardware Security Module (HSM)

03

Technical Article / September 2019

Keys Generated On-Board without a CoordinatorHere too, the key material for SecOC is generated on-board. However, the call for generating the key is not sent to a coordinating ECU, rather it is sent directly to a group of ECUs. The individual ECUs know the members of their group, and they start a multi-stage key agreement protocol. The members of the group exchange messages to generate a shared key without actually sending this key over the bus. As soon as all the ECUs in the group calculate a shared key, each group member generates the SecOC key it needs based on a key derivation specification.

Status of StandardizationSince there was no standardization of key management previously, but solutions were needed, automotive OEMs followed individual approaches. Developing and maintain-ing these different approaches for solving the same types of problems leads to additional costs for all stakeholders involved. Another consideration is that key management is typically not a competitive, differentiating product charac-teristic. This optimization potential was recognized and exploited in the standardization of key management in the AUTOSAR 4.4 Security Extensions. The dedicated module KeyM [3] for key management was specified (Figure 4). This module consists of the two sub-modules Crypto Key and Certificate.The Crypto Key sub-module offers functions for negotiat-ing keys. The process is divided into different phases. In a final phase, the key material may be derived and/or stored via the Crypto Stack in the HSM of the ECU. Due to the challenges described above, the logic defined by the automotive OEM is not implemented in the KeyM module. Instead, it is implemented in software components known as Key Handlers (Figure 4).The Certificate sub-module offers functions for parsing, verifying and installing certificates. The application can read out the values of defined elements of a certificate for further processing. In a final phase, the certificate is stored in the ECU’s nonvolatile memory (NVM) or in the HSM.

In this method the sender and all receivers of a message use the same secret key for creating and checking the MAC. The key must be kept confidential over its entire life cycle. Therefore, it must not be transmitted unprotected over internal vehicle networks or over networks external to the vehicle.The focus of the following example strategies is on gener-ating and installing keys during production. These different strategies are not evaluated here but it is shown that in practice there are many different solutions for key man-agement – even when the use case is the same. In this example, key material is generated and distributed for SecOC.

Keys Generated Off-BoardOne strategy is to have an off-board key management server that generates the keys needed for SecOC. This server must have information about the ECUs installed in a vehicle and their needs for SecOC keys. The ECUs get the keys they need during vehicle production. Since they are confidential, the keys must be protected cryptographically during their transmission. The receiving ECU checks the keys for authenticity and integrity before storing them.

Keys Generated On-Board with a CoordinatorIn this strategy, the tester creates an authenticated request to generate SecOC keys during production, and it sends this request to a coordinating ECU. In the first step, the coordinating ECU generates a common vehicle-specific key. The coordinating ECU uses a key agreement protocol to set up a temporary secure connection to each of the tar-get ECUs, and it transmits them the key it generated beforehand. Based on this key and a key derivation specifi-cation, each target ECU generates a suitable SecOC key. The Key Agreement Protocol requires rather long execution times, so it is only used to generate and distribute the keys. Using the keys that have just been generated, all target ECUs communicate with one another securely and effi-ciently over SecOC. They do so without needing a new key distribution.

Figure 3: Key management ranges over the entire vehicle life cycle.

04

Technical Article / September 2019

Production performance requirements also affect key management. E.g., if just a few seconds are available to transfer the keys for all vehicle’s ECUs, the key manage-ment strategy must be designed for this.

Reducing Numbers of Variants by StandardizationCryptographic algorithms and the related key material form the foundation of modern security mechanisms in ve-hicles. They are used to secure innovative functions and underlying business models against attacks.An initial step towards standardization is the KeyM module that was introduced with AUTOSAR 4.4. It does not stan-dardize a specific key management strategy, rather it offers generic interfaces for implementing various strategies.The automotive community should focus more intensively on harmonizing strategies for key management. This will make it possible to standardize the Key Handlers for rele-vant strategies and thereby reduce the number of variants in practice. A high degree of standardization has the poten-tial to reduce costs and reduce the number of solutions.

In its leadership role in the AUTOSAR Security Extensions concept group, Vector has been involved in the standard-ization of key management from the start. The require-ments set by this group have flowed directly into the devel-opment of its AUTOSAR basic software MICROSAR.

Challenges for StandardizationKey management is closely linked to development, produc-tion and aftersales processes at OEMs and suppliers. Since key material has already been used for some years now for a few functions, some of the IT infrastructures already exist, such as Public Key Infrastructures (PKI) and key servers. Because OEMs tend to reuse their existing infrastructure, standardization potential is limited here. The existing or planned infrastructure also affects whether an on-board or off-board method is chosen to generate cryptographic keys.Moreover, key management is also influenced by the security goals defined by the automotive OEM. These goals are based on different factors such as assumptions about security in the development, production and service envi-ronments. There are differences of opinion, for instance, about whether in-house production environments can be assumed to be secure. Such assumptions have direct effects on the protective measures that are taken when introducing keys during production and in aftersales.

Dr. Falco K. Bapp is Product Manager of MICROSAR Classic veHsm – the Vector software stack for Hardware Security Modules. He defines its ar-chitecture and functional scope.

Translation of a German publication in Automobil Elektronik, issue September 2019. In 2021 the product name of Vector’s HSM software has changed and was corrected in this article.

Image rights: Vector Informatik GmbH

Literature References:[1] AUTOSAR 4.3 WP-X-SEC (2016), Requirements on Module Secure Onboard Communication[2] AUTOSAR 4.3 WP-X-SEC (2016), Requirements on Crypto Stack[3] AUTOSAR 4.4 WP-X-SEC (2018), Specification of Key Manager

Dr. Antonio Almeida is Product Manager in the area of Security Governance. He takes care of the conformity of development processes to automotive security standards.

Figure 4: In AUTOSAR, key management is implemented by the KeyM module with its two sub-modules Crypto Key and Certifi-cate.

Dr. Eduard Metzkeris Product Manager of the Vector Cybersecurity Solution, and he defines the security mechanisms for the MICROSAR basic soft-ware. Dr. Metzker heads the AUTOSAR 4.4 Security Extensions concept group, which defined numerous security mechanisms for AUTOSAR.