AUTOSAR Crypto Stack: Csm, CryIf, KeyM — Implementation Guide for Automotive ECUs

Why AUTOSAR Classic Needs a Dedicated Crypto Stack

Crypto in an automotive ECU has three constraints that general-purpose libraries do not handle well: keys must never reach application memory, primitives must execute on dedicated hardware whenever it exists, and operations must be sequenced with hard real-time requirements. A monolithic crypto library either pulls keys into RAM and defeats the threat model, or executes primitives on the MCU and misses control-loop deadlines. The AUTOSAR Classic Crypto Stack is the architectural answer: a layered set of modules where the application sees a uniform job-based API, the Hardware Security Module sees a direct primitive dispatch, and the key material never crosses the boundary in either direction.

The stack also serves a second purpose. ISO/SAE 21434 Clause 10 requires evidence that cryptographic protections are correctly specified, implemented, and verified. A single Crypto Stack — with documented configuration, deterministic dispatch, and qualifiable modules — gives the cybersecurity case a single point of audit rather than a tour of every Software Component that happens to call AES.

Layered Architecture

Csm — Crypto Service Manager

Csm is the application-facing module. It exposes two API shapes. The job-based API — Csm_Encrypt(), Csm_Decrypt(), Csm_MacGenerate(), Csm_MacVerify(), Csm_SignatureGenerate(), Csm_SignatureVerify() — submits a job descriptor that names the primitive, the input buffer, the output buffer, and the key slot. Each job is configured for asynchronous or synchronous processing; an asynchronous call returns immediately and completion arrives through a configured callback. Job priorities are configured per job and queue depths per queue; high-priority jobs (a brake command MAC verify, for instance) are queued ahead of lower-priority telemetry hashing.

The direct API serves a narrower purpose: synchronous key-management calls — setting, validating and reading key elements — that map one-to-one onto CryIf and the Crypto Driver. Low-latency primitives use a job configured for synchronous processing instead, where the caller can afford to block and the buffer is small. A typical use is a one-shot SHA-256 over a 64-byte challenge during diagnostic authentication. Synchronous jobs keep call sites simpler when async overhead is not justified.

CryIf — Crypto Interface

CryIf is the routing layer. It binds Csm jobs to channels, channels to Crypto Driver Objects, and key slots to driver instances. A typical configuration has one Crypto Driver Object for the Hardware Security Module path and one for the software fallback path; CryIf dispatches a given job to the Crypto Driver Object of the channel its Csm queue maps to, not based on the job content, and translates the job’s key reference into that driver’s key. This is the right place to enforce the rule that production key slots only ever route to the HSM driver.

CryIf also handles multiplexing. Multiple Csm jobs can be in flight against the same Crypto Driver Object, limited by driver queue depth; CryIf serialises them in configured order and propagates completions back through Csm. Misconfiguration in this layer is the failure mode that loses days during integration: a job that “should” run on the HSM but actually runs on the software driver produces correct functional output and silently undermines every cybersecurity claim built on it.

Crypto Driver — Vendor and Software

The Crypto Driver implements the actual primitives. In production, the driver is a vendor Basic Software package supplied for the silicon’s Hardware Security Module — for AURIX HSM, for the S32 family’s embedded security module, for RH850’s ICUM, for STM Chorus and Microchip parts. These vendor drivers expose a uniform interface to CryIf, so the higher layers do not need to be rewritten when silicon changes; the configuration changes, the application code does not.

A pure software driver is provided as a fallback. It executes AES, SHA, CMAC, HMAC, ECDSA, and RSA on the MCU using a vetted library. Its role is development and non-sensitive workloads only. Long-term keys, SecOC session keys, and secure-boot verification keys must live in HSM-protected storage; if the software driver touches them, the threat model collapses.

KeyM — Key Manager

KeyM owns the lifecycle. Key elements are referenced by identifier, never by raw value, throughout the rest of the stack. KeyM writes key elements into Csm keys held by the HSM-backed Crypto Driver (or in NvM), maintains certificate chains and validates them against a trusted-time source, surfaces revocation and renewal events, and brokers key derivation through Csm. Applications and Basic Software modules never handle key material: each Csm job references its key by identifier in configuration, and KeyM updates the key elements behind that identifier.

The trusted-time source is the integration question that programmes underestimate. KeyM cannot evaluate X.509 notBefore / notAfter windows without one. A defensible architecture sources signed timestamps from a backend over an authenticated channel, caches them with a bounded staleness, and gates certificate validation on time-source health. Without that, a stale certificate either slips through or every boot fails, and neither outcome is acceptable.

Job-API Call Sequence

The numbered sequence below traces a single job-based Csm_Encrypt() call from application to Hardware Security Module and back. The same shape applies to MAC generation, signature verification, and key derivation jobs.

Common Crypto Primitives

Modern Csm implementations supply a stable set of primitives drawn from NIST FIPS 197 (AES), FIPS 180-4 (SHA-2), FIPS 186-5 (ECDSA), and SP 800-38B (CMAC). In practice every Crypto Stack provides:

• Symmetric cipher: AES-128, AES-256 in ECB, CBC, CTR, GCM, GMAC, and CCM modes.
• Message authentication: CMAC-AES128, HMAC-SHA256, HMAC-SHA384.
• Hash: SHA-256, SHA-384, SHA-512; SHA-3 in newer drivers.
• Asymmetric: ECDSA-P256, ECDSA-P384, ECDH-P256, RSA-PSS-2048/3072/4096.
• Key derivation: PBKDF2, HKDF, KDF in counter mode.
• Random number generation: DRBG sourced from a hardware true random number generator on the Hardware Security Module.

Integration With SecOC, Secure Boot, Secure Diagnostics

The Crypto Stack is the single point of contact for every cybersecurity-relevant Basic Software module on the ECU. Three patterns recur:

• SecOC. Calls Csm_MacGenerate() on transmit and Csm_MacVerify() on receive, against a key slot allocated for the communication relationship. Detailed in the companion guide on AUTOSAR SecOC.
• Secure boot. Calls Csm_SignatureVerify() on each boot stage’s manifest against the chained verification keys held in KeyM. The chain of trust walkthrough lives in the post on secure boot for automotive ECUs.
• Secure diagnostics (UDS service 0x29). Authentication challenges and response signature verification flow through Csm using ECDSA-P256 against the OEM diagnostic-tester certificate validated by KeyM.

Tool Qualification and Clause 10 Evidence

When the Crypto Stack participates in a function with an Automotive Safety Integrity Level above QM, every module in the stack inherits that requirement. Csm, CryIf, and KeyM packages are available from Basic Software vendors with ASIL-B and ASIL-D qualification reports; the Crypto Driver comes from the BSW vendor or the silicon vendor with its own report. The qualification is per supplier, per target, per release, and the release recommendation in WP-06-04 must reference the specific report version. Custom adaptations — non-trivial configuration deltas, custom callbacks, custom Crypto Driver Objects — require explicit qualification treatment in the project Cybersecurity Plan and may shift evidence work onto the project rather than the tool.

The Clause 10 cybersecurity case benefits from the Crypto Stack’s centralisation. Rather than enumerating cryptographic correctness in every Software Component, the case can reference the Crypto Stack qualification and the project-specific configuration; reviewers see a single audit point rather than dozens.

Implementation Pitfalls

AUTOSAR Adaptive: ara::crypto in 60 Seconds

The Adaptive Platform’s ara::crypto Functional Cluster preserves the Classic stack’s architectural intent in a different API style. C++ objects replace job descriptors; synchronous calls that return ara::core::Result replace callbacks; keys and certificates live in the Key Storage Provider and X.509 provider, with access control through Identity and Access Management, rather than a standalone KeyM. The Hardware Security Module remains the root of trust, and the same primitive set (AES, SHA-2, ECDSA, CMAC, HMAC) is exposed. Programmes that run mixed Classic and Adaptive ECUs typically maintain the same key hierarchy across both, with cross-platform services anchored in the Hardware Security Module on each side. The trade-offs are detailed in the comparison of AUTOSAR Classic vs Adaptive.

Take-Aways for an Architect-Grade Crypto Stack Programme

The Crypto Stack is one of the highest-leverage parts of an AUTOSAR Classic Basic Software stack: it is the single audit point for cryptographic claims, the integration boundary for the Hardware Security Module, and the call site for every other cybersecurity Basic Software module on the ECU. Get the configuration right — production key slots routed only to the HSM driver, KeyM anchored to a trusted-time source, priority lanes that respect safety criticality — and the rest of the cybersecurity stack inherits a clean foundation. Get it wrong, and every downstream claim becomes contestable.

Agnile Technologies provides AUTOSAR Crypto Stack integration across the major silicon families used in Tier-1 ECU programmes. Engage us before you freeze the CryIf channel map — that is the design moment when the wrong default sets up integration debt for the programme’s lifetime.