AUTOSAR CRYPTO STACK

Stack Architecture

1. The Crypto Service Manager (CSM)

The CSM controls one or more clients for one or more synchronous or asynchronous cryptographic services. It provides a priority queue to manage jobs that cannot be directly handled by the dedicated CRYPTO.

The functions of the CSM are as follows:

● HASH calculation.

● Message authentication code generation and verification.

● Digital signature generation and verification

● Symmetric and asymmetric encryption and decryption calculations

● Random number generation

● Security counters

● Key management operations, such as key setting and generation

CSM services are generic, and CSM allows different applications to use the same service with different encryption algorithms. Services can be configured and initialized individually. For example, one application may require a HASH service to calculate SHA-2, while another application may require a HASH service to calculate SHA-3.

The actual cryptographic routines are encapsulated by the CSM. The client does not need to care whether the routines are implemented in software or hardware, nor does it need to care which CRYPTO module actually maintains the requested cryptographic routines. The CSM provides an abstraction layer for all the cryptographic features available in the cryptographic stack.

The Crypto Interface (CRYIF)

CRYIF is between the upper layer CSM and the lower layer CRYPTO. It receives requests from CSM and maps them to the appropriate cryptographic operations in CRYPTO. CRYIF forwards the requests issued by CSM to a specific CRYPTO. If the request is asynchronous, the callback notification will report the result.

CRYIF can operate multiple CRYPTO modules. For example, there can be a CRYPTO module for external cryptographic hardware modules and a CRYPTO module for software cryptographic software libraries. CRYIF provides a common interface so that access from the CSM does not need to distinguish how the actual CRYPTO is implemented.

The Crypto Driver (CRYPTO)

CRYPTO implements the actual cryptographic services and supports key storage, key configuration, and key management for cryptographic services. It can have one or more Crypto Driver Objects (CDOs), each with a separate workspace. Each CDO can provide any number of cryptographic primitives. A cryptographic primitive is an instance of a configured cryptographic algorithm. A CDO can only execute one cryptographic primitive at a time.

The concept of multiple CRYPTO modules and multiple CRYPTO driver objects allows for different and concurrent implementations of the same cryptographic service. There may be variants of a CRYPTO module with different optimization goals. For example, the same hash algorithm may be implemented in two different CRYPTO modules, one with a faster (more expensive) hardware solution and the other with a slower (cheaper) software solution.

The following example describes a possible scenario of using several CRYPTO modules:

Two CRYPTO implementations are provided by two different vendors. One CRYPTO is an abstraction of a hardware solution ("CRYPTO_HW"), the other CRYPTO is a pure software solution ("CRYPTO_SW"), CRYPTO_SW is a software cryptographic library providing HASH services and a (pseudo)random number generator.

In order to enable parallel processing of both services, CRYPTO_SW has two crypto driver objects, one for the hash service ("CDO_HASH") and another for the random number generator ("CDO_RNG"). If some crypto routines cannot be run in parallel, they should be placed in the same crypto driver object.

2 Job Concept

The routine that requests the CSM to perform encryption operations is represented as a job. A job contains encryption routines and reference key operations but does not contain the actual key. Key management processing is not handled in a job manner.

Synchronous Mode

Synchronous mode: CSM service Job is executed immediately in the context of the caller, and the function return result is directly available

Asynchronous Mode

Asynchronous mode: Asynchronous job is processed later by dedicated CRYPTO in the pre-arranged main function context or in hardware. If the specific CRYPTO driver object refuses the job because it is busy, CSM puts the service request in the corresponding CSM job queue. CRYPTO uses CRYIF's callback function to notify CRYIF of the completion of the asynchronous job. CRYIF forwards the result through CSM's callback function.

Queuing and Priorities

A CSM Job may have multiple queues, each of which is mapped to a separate Crypto Driver Object (CDO), which can access the crypto primitives of CDO. After CRYPTO rejects the service request of CSM due to being busy, the specific job will be placed in the corresponding CSM queue according to its priority. During the Csm_MainFunction() loop call, the queued job is passed to CRYIF. CRYIF will forward the job to the specific CRYPTO. In order to optimize the hardware usage of CDO, CDO can also have job queuing selectively.

The priority of each job determines its priority according to its configuration. The higher the priority value, the higher the priority, and the job will be executed according to its priority.

Streaming Approach vs Single Call Approach.

The processing of encryption services includes "START", "UPDATE" and "FINISH" operations:

● "START" (CRYPTO_OPERATIONMODE_START) indicates a new start of a Job and initializes the encryption calculation.

● The input data can use the "UPDATE" mode (CRYPTO_OPERATIONMODE_UPDATE) and calculate intermediate results.

● "FINISH" (CRYPTO_OPERATIONMODE_FINISH) indicates that the final calculation will be performed.

Cryptographic Services can use either streaming or single call methods. The streaming method performs a single operation on a given data set. For example, the streaming method can be used to process very large input data by calling a service function with the "UPDATE" operation mode multiple times.

3 Key Handling

Key handling includes the generation, update, import/export, exchange, and derivation of cryptographic keys. Cryptographic keys can be stored in cryptographic hardware or using NvM.

Cryptographic keys are created from specific key types. CRYPTO provider implementations are pre-configured to adapt key types for use with the provided cryptographic primitives. A key type consists of one or more references to key elements. For example, a key element can be the key material required for AES encryption or a seed for random number generation.

During key configuration, a reference to the appropriate key type must be specified. The specific CRYPTO provides data storage for the key elements contained in the key type, where the actual key data is actually saved. HW CRYPTO implementations will typically use key slots. Whereas SW CRYPTO will use NvM to manage key storage.

4 Configuration Philosophy

Registration of Crypto Functionality

The concept of various CRYPTO modules allows flexibility in the available cryptographic features. In order for CRYIF and CSM to know the actual cryptographic features in the CRYPTO implementation, a registration mechanism is required. Otherwise, it is impossible to configure and use the actual cryptographic features in the CSM.

This scenario can be solved by vendor pre-configuration, which represents the functionality of each CRYPTO module. The pre-configuration is loaded from bottom to top, i.e. from CRYPTO over CRYIF to CSM. CRYIF mounts each registered CRYPTO module and integrates the specific cryptographic features into a common interface provided to CSM. CSM receives the available cryptographic features of the registered CRYPTO and gives specific cryptographic features for user configuration.

Project Configuration

The cryptographic stack is usually performed using a top-down approach, starting from the CSM on CRYIF to CRYPTO:

(i) In the CSM, the user selects and configures the cryptographic primitives and keys to be used, provided by CRYIF and CRYPTO. The user further defines jobs and job queues.

(ii) In CRYIF, the user mainly defines the mapping of CSM requested features to the features provided by the registered CRYPTO modules.

(iii) In CRYPTO, the user adjusts and extends the pre-configured cryptographic primitives and keys.

Example

The following outlines the use of the crypto stack using the "Message Authentication Code" (MAC) service.

The user creates a job, referencing the requested MAC cryptographic primitive and the cryptographic key to be used. The job is then further configured to be processed synchronously (CRYPTO_PROCESSING_SYNC) or asynchronously (CRYPTO_PROCESSING_ASYNC). If the job is asynchronous, he also defines the queue on which the job will be processed.

A MAC requires a key, at least a reference to the key element "key Material (CRYPTO_KE_MAC_KEY).

5 APIs involved

• The application (i.e. the runnable program of the SWC) communicates with the cryptographic stack (i.e. the CSM) through the RTE port.
• For each configured job, the RTE generates a port named {job}MacGenerate with a client/server interface CsmMacGenerate {Primitive}().
• This port has a port defined parameter value Crypto_OperationModeType and value CRYPTO_OPERATIONMODE_SINGLECALL.
• Thus, the SWC can call the MAC service by calling CsmMacGenerate_{Primitive} and provide all the data required to perform the MAC request in one call to the CSM.
• The BSW module or CDD uses the MAC service by calling the C-API Csm_MacGenerate() directly. Here, the job to be processed must be passed as an input parameter.
• Depending on the configuration of the application job, the processing of the job is either asynchronous or synchronous.
• In this example, we assume that the job must be processed synchronously in the context of the caller. The CSM dispatches the requested MAC service to CRYIF by calling CryIf_ProcessJob() and passes the job as an input parameter.
• CRYIF passes the processing of the job to CRYPTO by calling Crypto_ProcessJob(), which finally executes the crypto primitive configured in the job parameters.
• Note that if there are different CRYPTO implementations, the function naming will be differentiated using vendorId (vi) and vendorApiInfix (ai).
• Therefore, the call will be Crypto_ProcessJob(). Finally, CRYPTO stores the MAC in the memory space configured in the CSM job.