HSM Integration for Automotive ECUs: From EVITA Light to Full

A Hardware Security Module is the trust anchor an automotive ECU is built around. It stores keys that the application core must never see, runs the cryptographic primitives that Secure Boot, Secure Onboard Communication, Secure Flashing, and V2X depend on, and isolates that work behind a hardware boundary the rest of the system cannot reach by accident or by exploit. This post is the architect's view: how the EVITA tiers differ, how the AUTOSAR Crypto Stack maps the application into the HSM, what V2X imposes on the design, and where programmes lose months when integration is treated as an afterthought.

What “HSM” means in automotive (and what it does not)

In the data centre an HSM is a network appliance with a PKCS#11 interface. In a vehicle it is a discrete silicon block on the same die as the application MCU, with its own CPU, its own ROM, its own SRAM, and its own private bus to fused key storage. Three adjacent technologies are routinely confused with the automotive HSM and are not the same thing:

• SHE (Secure Hardware Extension): the HIS specification widely embedded in automotive MCUs. Functionally similar to EVITA Light, narrower than Medium.
• TPM (Trusted Platform Module): a TCG-defined module designed for IT platforms. Some automotive head units expose a TPM, but the in-vehicle network does not assume one.
• TrustZone: an Arm processor mode that isolates a secure world from a normal world on the same core. Useful, but not equivalent to a separate HSM core with its own memory and its own ROM-rooted trust.

The EVITA project in 60 seconds

EVITA (E-safety Vehicle Intrusion proTected Applications) was an EU FP7 research project that ran from 2008 to 2011 and published the architecture deliverables (D2.3, D3.2) that the automotive industry has used as the HSM taxonomy ever since. The project defined three protection profiles tied to the role of the ECU on the vehicle network. Silicon vendors then implemented the tiers (Infineon AURIX, NXP S32, ST Chorus, Renesas RH850, Microchip dsPIC and SAM all expose EVITA-class HSMs as industry references), and AUTOSAR codified how the application accesses them. The split between Classic and Adaptive matters here too: the Crypto Stack lives in both, with different orchestration assumptions on each. See AUTOSAR Classic vs Adaptive for the platform-level split.

EVITA Light, Medium, Full — feature comparison

The table below is the architectural decision aid we use when an ECU's Cybersecurity Goals land on the table for the first time. Match the feature column to the threat the control mitigates; do not over-tier or under-tier.

AUTOSAR Crypto Stack architecture for HSM access

Application code does not call the HSM directly. It calls into the AUTOSAR Crypto Stack, which routes the request down through four well-defined layers and back up with the result. Each layer is replaceable, which is what makes the stack portable across silicon families.

Csm — application-facing job and primitive API

The Crypto Service Manager is the API the application sees. It exposes job-based and synchronous-primitive interfaces: Csm_Encrypt(), Csm_MacGenerate(), Csm_SignatureVerify(). Csm schedules jobs, enforces key-handle scoping, and returns status without exposing the key material.

CryIf — channels and key-slot routing

The Crypto Interface routes Csm jobs to the right Crypto Driver instance and the right key slot. CryIf is what makes a dual-driver design possible: the application calls Csm without knowing whether the work runs on the HSM driver or the software-fallback driver.

Crypto Driver — vendor-supplied (HSM) and software fallback

The Crypto Driver is where the abstraction stops. Vendor BSW packages typically supply the HSM driver for the silicon's HSM block; a software-fallback driver provides the same primitives without hardware acceleration. The fallback exists for development and for non-key-bearing operations; production keys must live in the HSM.

KeyM — certificates, lifecycle, trusted time

The Key Manager handles certificates, certificate chains, key derivation policies, lifecycle states (provisioned, in-use, revoked), and the trusted-time service that V2X depends on. KeyM is the layer where production-grade programmes spend the most engineering effort.

HSM-host interaction sequence

The diagram below traces a single MAC operation through the stack — the most common HSM interaction in a SecOC-enabled ECU. Every other operation (Secure Boot verification, V2X signing, Secure Flashing) follows the same shape.

Secure Boot chain of trust with HSM

Secure Boot anchors trust in the HSM. The flow at power-on: ROM verifies the first-stage bootloader using a public key the HSM holds; the first-stage bootloader, now trusted, asks the HSM to verify the second-stage; the second-stage asks the HSM to verify the application. Each transition is a discrete signature verification; any failure halts the boot and enters a recovery path. OTA updates traverse the same chain — Secure Flashing produces a signed image that the HSM verifies before the application is allowed to boot. For the full chain-of- trust treatment see our companion post on Secure Boot implementation for automotive ECUs.

Key provisioning lifecycles

Key lifecycle is where most HSM programmes underestimate the work. Five activities have to be specified and tested:

• Factory PKI ceremony. Per-ECU key diversification at end-of-line, witnessed and logged.
• OTA re-keying. The protocol that allows a deployed ECU to receive new keys or rotated keys without a service-bay visit.
• Diversification. No two ECUs of the same part number share the same in-use key; compromise of one does not compromise the fleet.
• Rotation. Time-bound or event-driven; the HSM must support both in-use and pending key states.
• Revocation. The path by which a known-bad key is retired across the fleet, including the failure modes when an ECU is offline at revocation time.

V2X-specific HSM requirements

V2X is the load case that pushes ECUs toward EVITA Full. IEEE 1609.2 requires every outgoing message to carry an ECDSA signature over NIST P-256, and the application typically transmits at least 10 messages per second per channel. With certificate validation on inbound traffic the HSM is doing ECDSA verify operations at higher rates than sign operations. The latency budget is tight — a typical V2X ECDSA sign target is under 5 ms — and falls inside the HSM, not the application core. EVITA Medium can sometimes meet it; EVITA Full is the dependable answer. Post-quantum readiness on the V2X channel is an active research area; the production answer for firmware signing today is HSS or XMSS under NIST SP 800-208.

Common integration pitfalls

Across programmes the same handful of pitfalls account for the majority of schedule slip. Almost none of them are about algorithm choice. They are about lifecycle, timing, and the boundary between what runs inside the HSM and what runs outside it.

• Crypto-latency overruns. Measure on representative silicon during the architecture phase, not at integration. The principal cause of late silicon respins on cybersecurity programmes — and the easiest pitfall to avoid by spending a week with a bring-up board early.
• Missing key revocation. Provisioning is designed; revocation is forgotten. Both must be specified or the design is incomplete.
• Sleep/wake state mishandling. The HSM state across ECU sleep cycles is non-trivial; a key handle that is valid before sleep may need re-binding after wake.
• Secure storage versus secure use. Storing a key in the HSM is not enough if the application loads it into application RAM to use it. Use must remain inside the HSM boundary.
• Software fallback in production. The fallback driver exists for development. Releasing it in production silently downgrades the security posture and tends to be discovered only when an audit asks for the Crypto Driver provenance.
• Underspecified diagnostics. The HSM command set returns rich error codes; if the application logs only success or failure, post-mortem of a field incident is impossible. Plan diagnostic capture into the Csm wrapper from day one.
• Conflating secure storage with secure provisioning. The HSM holds keys safely, but the chain that puts them there at end-of-line is a separate work item. Programmes that design the runtime path and outsource the factory path discover the gap during the first production-line rehearsal.

Mapping HSM evidence to ISO/SAE 21434 Clause 10

Clause 10 expects evidence that cybersecurity controls are implemented and verified. The HSM-backed controls are usually documented under WP-10-01 (cybersecurity controls specification) and WP-10-04 (cybersecurity verification report). The work products are not the device datasheet; they are the design rationale for tier selection, the evidence that latency budgets are met on the chosen silicon, the key- lifecycle specification, and the verification results. For the broader Work Products view see our ISO/SAE 21434 Work Products checklist.

Silicon vendor landscape

The dominant silicon families in production all expose EVITA-class HSMs as industry references — Infineon AURIX, NXP S32, ST Chorus, Renesas RH850, and Microchip dsPIC and SAM are the names you will see in TARA artefacts. They differ in HSM core architecture, throughput, key-slot count, and post-quantum acceleration roadmaps. The integration path — AUTOSAR Crypto Stack down to the vendor BSW Crypto Driver — is the same; the work item is matching the tier and throughput to the ECU's Cybersecurity Goals before the silicon is locked in.

Take-aways

The HSM is the most consequential design decision in an automotive ECU's cybersecurity architecture. Tier selection drives BOM, latency, and what threats can credibly be mitigated — best decided with reference to the active TARA, including the STRIDE decomposition of the ECU's threats and a current Threat Analysis and Risk Assessment. AUTOSAR Crypto Stack integration drives where programme time goes; key lifecycle drives where production programmes get audited. Treat all three as architecture- phase decisions, instrumented with measurement on representative silicon, and the integration phase becomes what it is meant to be — verification rather than discovery.

Agnile Technologies designs and integrates Hardware Security Module-backed cybersecurity architectures across the major automotive silicon families. Reports and work products map directly to ISO/SAE 21434 Clause 10 evidence.