AUTOSAR Classic Crypto Services

The cluster bundles the CSM, CryIf, and Crypto Driver modules for hardware-independent provision of cryptographic services and key management functions in the AUTOSAR Classic Platform EXP_UtilizationOfCryptoServices p. 8. Cryptographic jobs are prioritized via the CSM, routed to logical channels in the CryIf, and executed synchronously or asynchronously in the Crypto Driver [SWS_CryIf_91003]. For consistency reasons, key persistences in the NVM strictly occur only after successful validation using KeySetValid SWS_CryptoDriver p. 37.

more ›

The "Crypto Services & Hardware Abstraction" module cluster comprises the AUTOSAR Classic modules Crypto Service Manager (csm), Crypto Interface (cryif), and Crypto Driver (crypto) EXP_UtilizationOfCryptoServices p. 8. It provides a hardware-independent abstraction layer for cryptographic operations (including encryption, signatures, MAC calculation, and random number generation) as well as for secure key management [SWS_Csm_00982], [SWS_Csm_00984], SWS_CryptoDriver p. 15.

Cryptographic requests are encapsulated as Crypto_JobType, which defines priorities, input and output buffers, and operation modes (start, update, finish for streaming or single-call) [SWS_Csm_01013], [SWS_Csm_01039]. The CSM accepts jobs, assigns them to software queues, and forwards them via CryIf_ProcessJob() [SWS_Csm_00017], [SWS_CryIf_91003]. The CryIf performs channel routing to the drivers and translates CSM key identifiers into module-specific driver key IDs [SWS_CryIf_00133].

Context diagram: Layered architecture and interface cascade of the AUTOSAR crypto stack. Sources: SWS_CryptoDriver p. 15, SWS_CryptoServiceManager p. 29

The periodic Csm_MainFunction() serves to synchronize asynchronous crypto jobs, emptying queues and triggering pending calculations [SWS_Csm_00479]. After completion of an asynchronous hardware calculation, the Crypto Driver notifies the CryIf via CryIf_CallbackNotification(), which passes the notification to Csm_CallbackNotification() and ultimately to the calling application [SWS_CryIf_91013], [SWS_Csm_00970].

Sequence diagram: Asynchronous crypto job flow with queuing and callback cascade. Sources: [SWS_Csm_00970], [SWS_CryIf_91013], AUTOSAR_CP_SWS_CryptoServiceManager p. 146

Key management is performed via standardized interfaces such as Csm_KeyElementSet() and CryIf_KeyElementCopy() under strict adherence to configured access rights [SWS_Csm_00957], [SWS_CryIf_91015], [SWS_Crypto_00219]. Persistence in the NVM is only triggered upon explicit validation via Crypto_KeySetValid(), thereby preventing incomplete key storage operations [SWS_Crypto_91014], SWS_CryptoDriver p. 37. Errors such as overloads or invalid key states are robustly handled via CRYPTO_E_BUSY or CRYPTO_E_KEY_NOT_VALID [SWS_Csm_00018], [SWS_CryIf_91003].

more ›

1. System Architecture & Role of the Module Cluster

The "Crypto Services & Hardware Abstraction" module cluster forms the functional foundation for cryptographic operations, software- and hardware-based key management, and secure on-board communication in the AUTOSAR Classic Platform EXP_UtilizationOfCryptoServices p. 8. The architecture is strictly structured along the AUTOSAR layer model into three standardized BSW modules: the Crypto Service Manager (csm) in the service layer, the Crypto Interface (cryif) in the ECU abstraction layer, and at least one Crypto Driver (crypto) on the microcontroller abstraction layer (MCAL) SWS_CryptoDriver p. 15. This layered structure completely abstracts security applications (such as SecOC, TLS connection setups, and UDS diagnostic authentication) from proprietary crypto coprocessors such as Hardware Security Modules (HSM) or Secure Hardware Extensions (SHE) SWS_SecureOnboardCommunication p. 78.

The Crypto Service Manager (CSM) acts as the primary service provider for application components (SW-Cs) and upper-layer BSW modules. It provides standardized programming interfaces for symmetric and asymmetric algorithms (e.g., AES, RSA), hashing, message authentication codes (MAC), random number generation (RNG), and AEAD schemes [SWS_Csm_00980], [SWS_Csm_00982], [SWS_Csm_00984], [SWS_Csm_01023]. In addition, the CSM implements software job queues and controls the prioritization of concurrent crypto jobs [SWS_Csm_00022], SWS_CryptoServiceManager p. 29.

As an abstraction layer, the Crypto Interface (CryIf) provides a uniform 1:n interface between the CSM and any number of crypto drivers. Its central task is dispatching: it forwards jobs based on configured logical channels (channelId) to the corresponding Crypto Driver instance and transforms logical key references (cryIfKeyId) into driver-specific identifiers (cryptoKeyId) [SWS_CryIf_00133], [SWS_CryIf_91003]. The Crypto Driver encapsulates the physical execution unit (Crypto Driver Object) and serves either pure software crypto primitives or dedicated hardware security modules [SWS_Crypto_00224], SWS_CryptoDriver p. 15.

Context diagram: Layered architecture and interface cascade of the AUTOSAR crypto stack. Sources: SWS_CryptoDriver p. 15, SWS_CryptoServiceManager p. 29

2. Interplay & Interaction Paths between the Modules

Job processing within the cluster is primarily performed via the job-based model using the structure Crypto_JobType [SWS_Csm_01013], AUTOSAR_CP_SWS_CryptoServiceManager p. 21. A crypto job bundles the job ID, priority information, key references, primitive metadata, and the structure Crypto_JobPrimitiveInputOutputType for managing pointers of input, output, and length parameters [SWS_Csm_01012]. The bitmask field Crypto_OperationModeType (with flags START, UPDATE, FINISH) controls whether a job is computed as a contiguous single call (SINGLECALL) or incrementally in streaming mode [SWS_Csm_01039], [SWS_Csm_01029].

If a CSM service function is called synchronously, the CSM checks the job state. If the driver is free or the job is configured as synchronous, the CSM directly calls CryIf_ProcessJob() [SWS_Csm_00017], [SWS_CryIf_91003]. The CryIf maps the key IDs and dispatches the job to the assigned driver instance via Crypto_ProcessJob() [SWS_CryIf_00133]. For asynchronous requests, if the driver object is busy, the job is queued in the CSM queue [SWS_Csm_00018], AUTOSAR_CP_SWS_CryptoServiceManager p. 30. After completion of the asynchronous driver computation, the driver triggers CryIf_CallbackNotification() [SWS_CryIf_91013], the CryIf forwards the notification to Csm_CallbackNotification() [SWS_Csm_00970], and the CSM finally notifies the requesting application via its configured callback [SWS_Csm_01044], [SWS_Csm_00928].

Sequence diagram: Asynchronous crypto job flow with queuing and callback cascade. Sources: [SWS_Csm_00970], [SWS_CryIf_91013], AUTOSAR_CP_SWS_CryptoServiceManager p. 146

In addition to primary crypto execution, key management constitutes an integral interaction path of the cluster SWS_CryptoDriver p. 24. A key consists of multiple logical key elements (such as key material, initialization vectors, or iteration counts) [SWS_Csm_00954], [SWS_Csm_01022]. Operations such as setting key material via Csm_KeyElementSet(), copying via Csm_KeyElementCopy(), or key derivation via Csm_KeyDerive() are forwarded synchronously via the CryIf (CryIf_KeyElementCopy(), CryIf_KeyDerive()) to the driver functions [SWS_Csm_00957], [SWS_Csm_00969], [SWS_CryIf_91015], [SWS_CryIf_91009]. Access to key elements is strictly monitored based on configured access rights (CRYPTO_RA_ALLOWED, CRYPTO_RA_ENCRYPTED, CRYPTO_RA_INTERNAL_COPY) [SWS_Crypto_00219].

3. Synchronization, Reentrancy, and Task Contexts

Cryptographic operations vary drastically in their execution duration. While fast block ciphers or hash calculations can be executed synchronously in the task context of the caller, asymmetric computations (e.g., RSA signature generation) or time-intensive hardware processes require asynchronous processing [SWS_Csm_00984], [SWS_Csm_00992]. For decoupling, the CSM provides the cyclically called main function Csm_MainFunction() [SWS_Csm_00479]. This function monitors queues, dispatches pending jobs to the CryIf, and drives internal state machines of asynchronous primitives [SWS_Csm_00019].

In modern multi-core and multi-sector architectures, the CSM supports multiple instances Csm_MainFunction_<shortName>() mapped to dedicated OS partitions [SWS_Csm_00479], AUTOSAR_SWS_CryptoServiceManager p. 170. In asynchronous driver execution, computations are completed either by polling in the driver MainFunction or by interrupt service routines (ISR) of hardware-based crypto engines [SWS_Crypto_00027], [SWS_Crypto_00028]. A single Crypto Driver Object can, by definition, process exactly one crypto job at a time; a driver with n objects processes n jobs truly concurrently [SWS_Crypto_00014], [SWS_Crypto_00117].

Regarding reentrancy, service interfaces such as Csm_MacGenerate() or CryIf_ProcessJob() are designed to be reentrant for different jobs, but forbid parallel multiple requests for the same job instance [SWS_Csm_00016], [SWS_CryIf_91003]. Key management functions such as Csm_KeyElementCopy(), CryIf_KeyElementCopy(), or Crypto_KeyCopy() are implemented as reentrant, but must not be applied concurrently to the same source key identifier (keyId or cryptoKeyId) to avoid data inconsistencies and race conditions [SWS_Csm_00969], [SWS_CryIf_91015], [SWS_Crypto_00155]. Hardware drivers may use internal exclusive areas for modifying internal workspaces and key registers to handle race conditions between ISR and task level SWS_CryptoDriver p. 27. Question Q-b1e9578255723a0e (open)

Activity diagram: Decision logic and queuing decoupling during job acceptance in the CSM. Sources: AUTOSAR_CP_SWS_CryptoServiceManager p. 30, [SWS_Csm_00017], [SWS_Csm_00018]

4. Typical Lifecycles and Operating Modes

Initialization of the crypto cluster takes place during BSW startup in hierarchical order. First, the EcuM or BswM initializes the driver layer via Crypto_Init(), passing the configuration Crypto_ConfigType [SWS_Crypto_91016], followed by the interface layer via CryIf_Init() with CryIf_ConfigType [SWS_CryIf_91118]. Finally, the CSM is started using Csm_Init(), where its configuration pointer must always be set to NULL_PTR according to the specification [SWS_Csm_00646]. Cryptographic jobs or key access requests may only be accepted after all layers are completely initialized [SWS_CryIf_00076], [SWS_Crypto_00196].

A central aspect of the key lifecycle is validation and persistence in non-volatile memory (NVM). After loading new key values via Csm_KeyElementSet(), the key remains in the state "incomplete or unknown" [SWS_Csm_00957]. Only the explicit call of Csm_JobKeySetValid() or Crypto_KeySetValid() verifies consistency and transitions the key state to valid [SWS_Csm_91027], [SWS_Crypto_91014]. For persisted keys, only this validation triggers storage in the NVM [SWS_Crypto_91026], SWS_CryptoDriver p. 37. This prevents multiple fragmented NVM write cycles and protects against incomplete key sets SWS_CryptoDriver p. 37. For synchronization with the NVRAM Manager, the Crypto Driver utilizes the callbacks Crypto_<vi>_<ai>_NvBlock_ReadFrom_<NvBlock>() and Crypto_<vi>_<ai>_NvBlock_WriteTo_<NvBlock>() as well as NvM_WriteBlock() [SWS_Crypto_91024], [SWS_Crypto_91025], [SWS_Crypto_91017].

Running streaming jobs can be interrupted if necessary via Csm_SaveContextJob(), saved in an application-owned buffer, and resumed later via context restore [SWS_Csm_91063], [SWS_Csm_01029]. Prior to an ECU shutdown or a transition to low-power modes, asynchronous jobs can be canceled in a controlled manner via Csm_CancelJob(), whereby the CryIf removes the jobs from driver queues and hardware channels via CryIf_CancelJob() [SWS_Csm_00968], [SWS_CryIf_91014].

5. Error Handling, DET Tracing, and Degradation

The cluster implements a multi-stage error detection and mitigation strategy. If tracing is enabled, development errors are reported directly to the Default Error Tracer (DET) module [SWS_Csm_91101], [SWS_Crypto_91017]. Typical DET events include module calls prior to successful initialization (CRYIF_E_UNINIT, CRYPTO_E_UNINIT), invalid handle or key parameters (CRYIF_E_PARAM_HANDLE, CRYPTO_E_PARAM_HANDLE), and null pointer passes [SWS_CryIf_00076], [SWS_CryIf_00134], [SWS_Crypto_00196], [SWS_Crypto_00217].

Runtime overloads and resource bottlenecks are handled deterministically via defined return values. If the CSM queue for an asynchronous job is exhausted, the CSM rejects the job with the status code CRYPTO_E_BUSY and generates the runtime error CSM_E_QUEUE_FULL [SWS_Csm_00018], [SWS_Csm_01089]. If a provided result buffer is insufficiently sized, the driver aborts the operation with CRYPTO_E_SMALL_BUFFER [SWS_Crypto_00195]. If a cryptographic service refers to an uninitialized or explicitly invalidated key (for example after calling Csm_JobKeySetInvalid() or Crypto_KeySetInvalid()), service requests fail in a controlled manner with CRYPTO_E_KEY_NOT_VALID or CRYPTO_E_KEY_EMPTY [SWS_Csm_91002], [SWS_CryIf_91003], [SWS_Crypto_91020].

Degradation and fallback mechanisms are enabled at the system level: applications can check the integrity status of keys via Csm_KeyGetStatus() before transmitting a job [SWS_Csm_91047], [SWS_CryIf_91012]. If a hardware crypto accelerator is permanently busy or fails, the CryIf channel configuration allows a software-based alternative route, provided a redundant software driver is integrated SWS_CryptoDriver p. 15.