Why software key storage does not survive the V2X threat model.
Every other page on this site describes a system that works if one assumption holds: that the private key which signs a V2X message exists only inside the device that is supposed to hold it. Break that assumption and nothing above it recovers. This is the page about that assumption.
A key in flash is a key in five places.
An on-board unit sitting in a vehicle is an object an attacker can buy, steal or salvage, take home, and work on for as long as they like with no time pressure and no observer. If the signing key lives in the application processor's flash, it is also:
- in RAM during every signing operation
- reachable over JTAG or SWD unless the debug interface is permanently fused, which it frequently is not
- present in the boot ROM's view of the world
- inside every firmware image and every OTA payload that provisions it
- on whatever machine built and signed that image
Extract it once and you can manufacture a clone. The clone transmits validly signed forged messages. There is nothing wrong with the signatures; the PKI is functioning exactly as designed; the receiver has no basis on which to reject them. And because PC5 verification is offline, the receiver cannot phone home to ask whether this is a device it should still trust. The trust decision is local and final.
Roadside units are worse. They are bolted to poles in public. They hold application certificates with broad service-specific permissions — an RSU is allowed to say things a vehicle is not, including things about signal state and emergency-vehicle preemption. A compromised RSU broadcasts to every vehicle in range, continuously, from a fixed and well-chosen location. How AmbiRSU handles that →
A tamper-resistant secure element, with four properties.
- Key generation inside the boundary. The key pair is created inside the secure element. The public key crosses the boundary; the private key never does, at any point, in any lifecycle state. This is where the keys actually live.
- Signing inside the boundary. The host processor sends a hash and receives a signature. It never sees key material.
- Policy inside the boundary. Certificate lifecycle rules — which credential is active, when to rotate, what to reject — live in the applet, not in host software that can be patched by whoever holds the device.
- Attestation out of the boundary. The secure element can prove to an Enrolment Authority that it is a specific instance of certified silicon rather than a software simulator. The EA verifies that hardware attestation before issuing, and refuses what it cannot attest.
Both regimes converge on this. IEEE 1609.2 and ETSI TS 103 097 assume it architecturally; the CAR 2 CAR Communication Consortium formalises it as the Protection Profile “V2X Hardware Security Module”, version 1.4.1, which is what the dedicated V2X security parts certify against.
The regulatory recommendation follows directly. MTCTE and TEC cybersecurity testing for V2X equipment should treat key non-extractability as pass or fail, not as a recommendation. It is the one property that, if absent, invalidates everything else in the certification. India's certification architecture →
EVITA is the reference vocabulary, and V2X sits at the top of it.
| Profile | Capability | Fit for V2X |
|---|---|---|
| AUTOSAR SHE | AES-128 only, key slots, secure boot | No. Cannot do ECDSA. |
| EVITA Light | Symmetric only, sensor and actuator level | No |
| EVITA Medium | Symmetric plus secure boot plus internal CPU, ECU level | No |
| EVITA Full | Adds asymmetric crypto engine, hardware ECC accelerator, tamper protection | Yes — this is the V2X profile, because V2X needs ECDSA at rate |
Certification frameworks worth naming precisely, because they are routinely conflated:
- Common Criteria EAL — evaluation assurance level for the security of the silicon and its evaluated configuration. The dedicated V2X security parts on the market sit at EAL4+ per their vendors' published certificates; AmbiSEC is built to EAL6+ secure-element requirements.
- FIPS 140-2 / 140-3 — a US cryptographic module standard, in practice applied to PKI back-end HSMs rather than in-vehicle secure elements. European V2X secure elements certify to Common Criteria, not FIPS.
- AEC-Q100 — automotive stress qualification, by grade; Grade 2 covers −40 °C to +105 °C ambient.
- ISO/SAE 21434 — road vehicle cybersecurity engineering: process, threat analysis and risk assessment, cybersecurity assurance levels.
- ISO 26262 — functional safety, ASIL A to D. Orthogonal to security, but co-engineered.
- UNECE R155 and R156 — type-approval regulations requiring a certified Cybersecurity Management System and Software Update Management System respectively. Both in force since January 2021; under EU Regulation 2019/2144, R155 became mandatory for new whole-vehicle type approvals in July 2022 and extended to all new vehicles registered in the EU in July 2024. An on-board unit is an in-vehicle ECU with an external radio interface, so it falls squarely inside R155's scope and its firmware inside R156. India's draft AIS-230 borrows the same logic. The EU type-approval picture →
Signing is easy. Verification is the engineering constraint, and the numbers are uncomfortable.
A vehicle signs one message per 100 ms. That is why Infineon's SLS37 V2X HSM specifies 20 ECDSA signature generations per second and considers that sufficient — it is.
Verification is a different order of problem. In dense traffic an on-board unit receives messages from every equipped vehicle in range, at 10 Hz each. The published figures:
- NHTSA's requirement: DSRC equipment must validate at least 5,500 Basic Safety Messages per second under congested conditions.
- Measured on real on-board units: approximately 35 verifications per second in software, and approximately 163 per second with a hardware crypto module.
That is a shortfall of roughly thirty-four times, even with hardware acceleration. It is the entire reason verify-on-demand strategies exist.
Verify-on-demand runs the application-layer threat assessment first and verifies only the messages that would actually trigger a warning. It works, and it fails under a targeted flood: published measurement puts processing beyond one second when receiving 2,000 threatening BSMs, which is precisely what an attacker with several certificates and several radios would generate.
Advanced verify-on-demand bounds it by construction: bucket threatening messages by safety application type × eight spatial zones × four relative directions — 160 categories maximum — and verify only the first message per category per time unit. Verification load is capped at 160 per second regardless of offered load. Denial of service becomes structurally impossible rather than merely difficult.
The alternative approach is to put verification in silicon. NXP's SAF5400 specifies ECDSA verification of up to 2,000 messages per second on-chip, and Autotalks' CRATON2 and TEKTON3 advertise line-rate hardware verification in their embedded HSM. Both are meaningful architectural answers, and both change where in the system the secure element sits: it becomes an inline element in the receive path, not a peripheral consulted occasionally. The parts, and what each publishes →
This is the single most important sizing question in OBU design, and it is routinely missed. Ask any V2X hardware proposal what its verification throughput is under a 5,500-message-per-second offered load, and what happens when that load is adversarial.
If the enrolment key leaks on the line, the deployment is compromised before it ships.
The enrolment credential is the device's identity for its whole life. If the EC private key exists in plaintext on a factory PC, or an operator can read a hex dump, nothing downstream matters. The correct pattern is HSM-backed:
- The key pair is generated inside the secure element on the line. The EC public key crosses the boundary; the private key never leaves.
- Personalisation traffic between the provisioning HSM and the secure element is wrapped under GlobalPlatform SCP03. No plaintext key material is exposed to the line, the operator or the factory network.
- Per-device unique identity is established through hardware attestation — the secure element proves it is a specific instance of certified silicon, not a soft simulator. The Enrolment Authority verifies that attestation before issuing, and refuses what it cannot attest.
This is not a theoretical process. It is the same HSM-backed personalisation line Ambimat operates for smart-card and secure-element personalisation today.
A 25 mm × 25 mm solder-down module with a Common Criteria EAL6+ compliant secure element at its centre.
AmbiSEC communicates with a host device and manages the security of that device's communication. The host keeps its radio stack, its application logic and its operating system. AmbiSEC owns key generation, key custody, signing, verification and credential lifecycle inside a tamper-resistant boundary.
| Layer | Specification |
|---|---|
| Silicon | Common Criteria EAL6+ compliant secure element, dual-domain co-processor |
| Cryptography | ECDSA P-256 / P-384 signing and verification; on-chip key generation; Ed25519, AES, HMAC, SHA-family |
| Key custody | Private keys never leave the tamper boundary — the host receives signatures only |
| Applets | JavaCard V2X applet: enrolment credential storage, pseudonymous certificate batch lifecycle, policy enforcement |
| Lifecycle | Secure boot, OTA verification, applet upgrade under GlobalPlatform SCP03 |
| Provisioning | Unique 128-bit identity key burned at manufacturing, non-extractable by hardware design |
| Environment | Automotive operating range available, −40 °C to +105 °C |
The dual-domain architecture. The MCU domain runs application firmware, connectivity stacks and sensor acquisition. The cryptographic security domain holds keys and credentials, performs sign, verify, encrypt and decrypt operations, maintains anti-replay counters and monotonic state, and authorises secure firmware updates. Long-term secrets are never exposed to application firmware.
The JavaCard applet differentiator, engineered by the AmbiSecure team over a decade: security logic fully isolated from application firmware; applets upgradable independently of full firmware, so a certificate-policy change deploys without a device recall; and structured domains, so multiple security applications coexist in isolated partitions — a V2X identity applet alongside FIDO, PIV and IoT functions on the same silicon.
Wording standard, applied site-wide. AmbiSEC's security level is stated as “Common Criteria EAL6+ compliant” — never “certified”, never with a certificate number, and never with a FIPS reference. This is deliberately the more conservative formulation: it describes what the hardware is built to, without asserting a formal award.
Third-party parts are a separate case. Where a vendor publishes a certification for its own silicon — Infineon's EAL4+ for the SLS37, NXP's EAL4+ for the SXF1800 — that is a factual, attributable vendor claim and stays on the site as such. It is attributed to the vendor, and not extended by analogy to our own parts.
AmbiSEC product page → · AmbiSEC IoT Security Co-Processor →
Where this fits.
V2X PKI
The credential lifecycle this hardware boundary exists to protect.
Threats and attacks
What a device holding valid credentials can still do, and how it gets caught.
Chipsets and hardware
The dedicated V2X HSM parts, with their published certifications and rates.
Secure elements in connected vehicles
The AmbiSecure engineering blog on in-vehicle key custody.
Why software-only device trust fails
The same argument, from the secure-element side.
Device identity at manufacturing scale
Provisioning-line architecture, in the detail section 5 compresses.
Selecting a secure element for an OBU or RSU?
Bring your BOM constraints, your SMT cadence and the PKI you have to interoperate with. We will bring an architecture sketch and, under NDA, a reference design.
Questions this page answers.
Why does a V2X device need a secure element?
Because the device is physically accessible to an attacker for an unlimited time, and because verification is offline. A signing key that can be extracted lets an attacker manufacture unlimited clones that emit validly signed forged safety messages, and no part of the PKI can detect or reject them. A tamper-resistant secure element generates the key inside its boundary and never lets it out.
Is a TPM or a TEE good enough for V2X?
A Trusted Execution Environment is a software isolation boundary enforced by the main processor, and it shares that processor's physical attack surface. A TPM is designed for platform attestation rather than high-rate ECDSA in an automotive thermal envelope. The V2X protection profile the industry actually certifies against — the C2C-CC V2X HSM Protection Profile — assumes a dedicated tamper-resistant device. Secure element versus TEE versus TPM, compared.
What is the difference between a secure element and an HSM?
Scale and location. A secure element is a single-chip, low-power, tamper-resistant device embedded in an endpoint — an OBU, an RSU, a smart card. A hardware security module is a rack-mounted or card-form device in a data centre or on a provisioning line, handling far higher throughput and typically certified to FIPS 140. A V2X deployment needs both: secure elements in the field, HSMs behind the Enrolment and Authorisation Authorities and on the manufacturing line.
How many V2X messages per second can hardware verify?
It varies by an order of magnitude across parts. NXP's SAF5400 specifies up to 2,000 ECDSA verifications per second on-chip. General-purpose secure elements are far slower — measurements on real on-board units found around 163 per second with a hardware crypto module. Against NHTSA's 5,500 messages-per-second validation requirement, that gap is why verify-on-demand strategies are used.
What does Common Criteria EAL6+ compliant mean?
Evaluation Assurance Level 6 is the second-highest level in the Common Criteria scheme, requiring semi-formally verified design and testing; the plus indicates augmentation with additional assurance components. “Compliant” means the secure element is built to those requirements. It describes the silicon, not the integrated product, the firmware around it, or the deployment — a component built to EAL6+ requirements does not by itself make a device compliant with anything.