Software Crypto Stack for Automotive ECUs
The increasing need for cybersecurity in Automotive domain was discussed in our previous blog, Cybersecurity for Automotive ECUs – An Introduction. We investigated different mechanisms by which a hacker could exploit an ECU, like compromising the in-vehicle communication network, gaining unauthorized access to vehicle, tampering ECU firmware and rogue software updates. The blog covered threats that could be prevented by implementing features such as encrypting data transmitted within the vehicle (Secure On-Board Communication), securing access to vehicle diagnostics, authenticating the firmware before installation. These implementations make use of AUTOSAR Crypto Stack to facilitate cryptographic services like computation of hashes, asymmetrical signature verification, symmetric encryption of data, among others. Hardware and software-based implementation also makes use of additional hardware components like Hardware Security Module (HSM), Security Hardware Extension (SHE), to implement the cryptographic algorithms. These modules use stacks provided by third party vendors like Vector, Elektrobit & ETAS, to implement the firmware.
In this blog, we will deep dive into configurations that need to be done in AUTOSAR Crypto stack and the major crypto related configurations that a typical firmware stack of a hardware component like HSM will contain.
AUTOSAR Crypto Stack - General Configuration & Usage
AUTOSAR provides cryptographic services like computation of hashes, verification of asymmetrical signatures or symmetric encryption of data. This is done using Crypto stack which includes Crypto Service Manager (Csm), Crypto Interface (CryIf) and Crypto Driver (Crypto).
Crypto Service Manager (CSM):
Topmost layer of Service layer provides abstraction to the lower layers and access to cryptographic services to applications via RTE port mechanism.
This module is initialized by BSWM (Basic Software Manager). Csm provides API for manual null initialization of RAM variables. CSM provides one main function which is called cyclically at a task level when asynchronous processing is enabled. The main function is responsible for dispatching new jobs to the underlying CryIf and Crypto layers.
The different parameters that are configured in Csm include:
CsmPrimitives: These are static configurations which are used to define a cryptographic operation. The main configurations include algorithm family, algorithm key length, data length, result length, processing mode (asynchronous/synchronous), key reference and more.
CsmJobs: Primitives are assigned to Jobs which in turn determine further attributes like priority, mode of execution (asynchronous/synchronous) and what keys to be used for operation.
CsmKeys: These are references to keys present in Crypto driver.
CsmQueues: CsmJobs are configured in queues according to configured job’s priority. It also contains reference to CryIf channel.
Crypto Interface (CryIf)
This module resides in hardware abstraction layer and is responsible for mapping the features requested by Csm to features provided by registered Crypto modules. Like Csm, initialization of CryIf is done by BSWM. CryIf does not provide a main function; so all calls are synchronous in nature.
The major parameters in CryIf module are:
CryIfChannels: These are paths from Csm queue via the CryIf to a specific Crypto driver object. The main configurations include a reference to the corresponding Crypto driver object and channel id.
CryIfCryptoModules: CryIf can handle multiple Crypto driver objects at the same time. For e.g., one could be an external hardware module, and another could be holding a software library. The main configurations include reference to Crypto driver object.
CryIfKeys: These are references to keys present in lower Crypto driver.
Crypto Driver (Crypto):
The Crypto driver is invoked by CryIf and performs the specific cryptographic functionality. It offers a superset of algorithms which can be extended by custom algorithms. Multiple crypto driver objects can be configured in crypto driver for e.g., one could be an external hardware module and other could be a software library. Each driver object can provide many crypto primitives. Each driver object can perform only on Crypto Primitive at the same time.
Below are the major configurations to be done in the Crypto driver:
Pre-Configuration: Vendor of the Crypto driver will provide a pre-configuration file which will represent the capabilities of the Crypto driver. The file will be in BSWMD file format.
CryptoDriverObjects: A Crypto driver object represents an instance of independent crypto hardware device. There could be multiple driver objects configured. Some of the major configurations for driver objects include buffer size [size of the buffer allocated in global RAM for each driver object] and queue size [maximum number of jobs supported by the driver object queue].
CryptoKeyElements: KeyElements contain the configurations for each cryptographic key. For example, seed state for random number generation, an initialization vector, and so on. A single key can have more than one key element. Major configurations for key elements include initialization value which will be used during initialization, key element size and configuration for persisting key elements in NV memory. Another major configuration includes read & write access for the key elements i.e., if the key elements can be accessed from outside the Crypto driver or not.
CryptoKeyTypes: Key types consist of references to the Cryptokey elements. These are pre-configured by the Crypto driver vendor.
CryptoKeys: Here key configurations just include references to the key types configured.
CryptoPrimitives: These are instances of configured cryptographic algorithms realized in Crypto driver. Configurations for Crypto primitives include algorithm family (AES, MD5, RSA) algorithm mode (ECB, CBC) primitive service to be used (Signature Verification, Key generation).
NvMKeyConfigurations: For each Crypto key element which requires persisting NV storage requires an NV block to be configured in NVRAM Manager. The corresponding NVM blocks are referenced in the NvMKeyConfigurations.
The application component requests a cryptographic service of the Csm providing the necessary data and the id of the CsmJob which will be performed in the underlying CryptoDriverObject. The CsmJob contains all computational parameters for performing the cryptographic operation. At configuration time, each CsmJob is assigned to a CsmQueue, regardless of processing type (synchronous or asynchronous) of the job. Each CsmQueue is mapped to CryIfQueue and a CryIfQueue itself is mapped to a CryptoDriverObject of a crypto driver. At the crypto layer, multiple Crypto driver objects can exist simultaneously and do not interfere each other. The CryptoDriverObject must allocate the required workspace and support the cryptographic operational in general. A job in computation occupies the cryptographic workspace of the cryptographic service; therefore, jobs running in the same crypto driver object are processed in serialized fashion, whereas jobs running in different crypto driver objects or jobs of different cryptographic type may run in parallel.
HSM Crypto Stack - General Configuration
The advantage of using a hardware component like HSM to facilitate cryptographic algorithms is multifold, as it can:
- provide security services for the application
- store keys and certificates there by isolating them from the rest of the application
- manage keys and certificates
- execute cryptographic algorithm using hardware/software implementations
Now let’s look at the major configurations that are needed for facilitating cryptographic algorithms in a typical firmware stack of HSM.
Communication Registers: Generally, two registers are used to share information between application and HSM core, HSM2HOST register and HOST2HSM register. These are used to indicate startup of HSM, HSM is ready to receive interrupts, the initialization of the IPC memory etc. The addresses of these two registers need to be configured based on the controller and it must be ensured that no other software entity is using these registers.
HSM IPC: HSM uses Inter Process Communication (IPC) for communicating between application core and HSM core. The interface is placed in a shared RAM of microcontroller to which both HSM and application cores have access to. Each core using the security services needs to have a separate IPC instance. Parameters like number of IPC channels to be used, IPC protocol version etc., need to be configured for each IPC instance.
Memory Access: The memory areas that should be accessible by the HSM core should be whitelisted and should be regarded as valid memory for input/output depending on configuration. Parameters like memory priority, access rights, users, start and stop addresses should be configured for these memory regions.
HSM Interrupts: The application core triggers the interrupts when a new job is issued to the HSM. The HSM notifies the application core about a completed operation with the response interrupt. This interrupt communication is needed if OS is used. In that case, the interrupt set address, clear address etc., needs to be configured. Further, the interrupt mode, category should also be configured.
Crypto Driver Objects: Multiple driver objects that provide different functionality for e.g., secure start up implementation, software library, access to hardware accelerators, key storage etc. can be configured in HSM. Each driver will be providing access to different primitives. A primitive is a description of a cryptographic algorithm. Each primitive has certain parameters like algorithm family, mode etc. These primitives must be mapped for each driver object.
CryptoKeys: As with the AUTOSAR Crypto stack, new keys can be added, and it should include a reference to the key type. Apart from this, a reference to the non-volatile memory block can also be provided for persistent storage. Persistence of crypto keys could be achieved through an AUTOSAR like memory stack containing NvM, Fls, Fee modules.
CryptoKeyTypes: A key type is a structure containing a list of key elements.
CryptoKeyElements: Each key element has parameters like size, initialization value, read/write access, persistency configuration etc. The details of the NV block like the descriptor, id of the block, size etc., also need to be configured.
CryIf: This is responsible for dispatching crypto jobs internally to different crypto drivers by defining CryIf channels. These channel configurations do not have to match the host channel configurations. CryIf is also the source for key configuration exported to pre-config file. Each CryIf channel should be mapped to a corresponding Crypto driver object.
Csm: As with the AUTOSAR Crypto stack, HSM stack can also have a CSM module in which jobs & primitives for internal usage can be configured.
All these crypto configurations will be available in the pre-config file generated with the above-mentioned configurations. This pre-config file is then loaded in the host side to establish proper communication between the HSM and the application. In normal use cases, this pre-config file is first loaded, and the crypto stack configuration is done using a bottom-up approach at the host side i.e., the configurations are started from the lower most layer (Crypto driver) and then propagated to the upper layers (CryIf, Csm).
Conclusion
In the above sections, we discussed the major configurations to be done in AUTOSAR Crypto stack and how crypto configurations in a typical firmware stack of a hardware component like HSM look like. These stacks facilitate implementation of cryptographic algorithms for Secure On-Board Communication, Secure Diagnostics and Secure Boot.
References
- AUTOSAR Specification of Crypto Service Manager
- AUTOSAR Specification of Crypto Driver
- AUTOSAR_EXP_UtilizationOfCryptoServices
- AUTOSAR_SRS_CryptoStack.pdf
