Connected mobility & V2X.
Every roadside unit and every on-board unit in a compliant V2X deployment is an active PKI participant — signing every safety message, verifying every received message, and doing both fast enough for traffic. Software-only key storage does not survive the threat model. Hardware-rooted identity does.
Why V2X infrastructure demands hardware-backed identity.
RSUs sit at roadsides. OBUs sit inside vehicles. Both are physically accessible. An attacker with a screwdriver, a JTAG probe, or a stolen vehicle has direct contact with the device that signs every V2X message it transmits.
If the device's private key is reachable by firmware — sitting in flash, sitting in RAM during a signing operation, sitting on a debug bus — that key is reachable by the attacker. Once extracted, the key can be replayed on a different device. The original RSU is then indistinguishable from an attacker's transmitter pretending to be that RSU. False road-hazard alerts, fake emergency-vehicle preemption, forged collision warnings — each becomes a one-time cryptographic-key-extraction problem.
A hardware secure element changes the equation. The key is generated inside the tamper-resistant boundary, used by signing operations that execute inside that boundary, and never crosses out of it. An attacker who owns the host MCU can ask the SE to sign things while the device is live, but cannot extract the key, cannot clone the device, and cannot impersonate the device once unplugged from the network.
An identity system with two layers and very different cadences.
Enrolment Credential (EC)
Long-lived. Hardware-bound to the SE. Issued by the Enrolment Authority once the SE has proven it is genuine certified hardware. Lives in the SE for the life of the device.
Pseudonymous Certificate (PC)
Short-lived. Issued by the Authorisation Authority in batches. Used to sign actual V2X messages. The AA never sees which EC requested it — the vehicle is authenticated but not identified per message.
High-velocity issuance
A national fleet rotating PCs every few minutes implies millions of certificate issuances per minute at peak. The PKI architecture has to scale to telecom volumes, not enterprise-CA volumes.
Offline trust on PC5 sidelink
A vehicle receiving a safety message from another vehicle 50 ms before a possible collision cannot wait for a cloud round-trip to verify it. Verification must be local, against trust anchors already on the device.
Revocation at scale
CRLs grow over the life of a deployment. Propagating them to vehicles that may be offline for days at a time means RSU-broadcast distribution paths, not just connected-device pull models.
Privacy as a design goal
Pseudonymity is not optional. A V2X message must be verifiable but must not trivially reveal the signer's identity or location-trace. The PKI is built around that constraint, not retrofitted to it.
How secure elements map to OBU and RSU requirements.
The role the SE plays in a V2X device is not "another peripheral". It is the trust boundary on which the entire deployment's safety claims rest.
Key generation inside the boundary
EC private key is generated inside the SE at first provisioning. The host MCU never sees it. The factory operator never sees it. The only artefact that crosses out is the matching public key, sent to the EA for certificate issuance.
Signing operations hardware-isolated
ECDSA-P256 / P-384 signing executes inside the SE. The host MCU hands over the message digest, receives the signature, never touches the key. A compromise of the host firmware does not yield a compromise of the credential.
Certificate lifecycle in-SE
EC storage, PC batch management, PC rotation scheduling — all happen inside the SE. The SE knows which PC is currently active, which are in reserve, and when to rotate.
Attestation to the EA
The SE produces a hardware-signed attestation response proving to the Enrolment Authority that the requesting key material resides in a certified secure element. The EA verifies this before issuing the EC.
Automotive operating range
An OBU in a vehicle in Indian conditions sees everything from cold-start mornings to dashboard-baking summer afternoons. Extended automotive range — −40°C to +105°C — is the right spec, not commercial range. See the IoT Security Co-Processor spec.
CC EAL5+ at the silicon level
The underlying secure-element silicon carries Common Criteria EAL5+ certification at the chip level. Automotive-grade certification (ISO 26262, ASPICE) of the integrated product is a target, not yet claimed.
How JavaCard applets support V2X certificate management.
The cryptography is one layer of the answer. The other layer is the certificate-management logic that decides which PC to use right now, when to rotate, when to discard, and how to fetch the next batch.
Putting that logic inside a JavaCard applet running on the SE itself — rather than in the host firmware — means the policy is enforced inside the trust boundary. A custom V2X applet can implement EC storage, PC batch lifecycle, the rotation schedule, and the signing-protocol surface against the host MCU. It can co-reside with the device's other identity applets (FIDO, PIV, IoT identity) on the same SE, selectable by AID; nothing prevents an OBU from being a FIDO authenticator for the vehicle owner's mobile app and a V2X signer at the same time, on the same chip, in different applet contexts.
And because applets are upgradable under GlobalPlatform SCP03, a change in V2X certificate policy — an extension to the validity-period model, a new revocation distribution path, a tweak to the rotation cadence — can be deployed to a fielded fleet via an OTA applet update. No device recall.
eSIM/eUICC architecture and V2X credential lifecycle share more than the name suggests.
The telecom industry has spent fifteen years building infrastructure to provision, rotate, and revoke credentials on field-deployed embedded devices without recalling them. That experience is directly relevant.
SGP.32 IoT eSIM defines a profile-lifecycle architecture (SM-DP+, SM-DS) that has structural parallels to V2X's EA/AA. Both domains require: automated remote provisioning under an authenticated channel, OTA rotation of credentials, and revocation paths that work without device recall. The cryptography differs, the volumes differ, the standards differ — but the operational shape of the problem is recognisably the same one.
For V2X programmes that want to learn from telecom-grade credential lifecycle work, the eSIM Initiative is the sister site where that work lives in detail.
The references that shape AmbiSecure's V2X engineering.
| TEC 31318:2021 | India IoT Security Code of Practice. Baseline cybersecurity requirements for IoT devices including no-default-passwords, hardware-isolated key storage, secure boot, secure OTA. The architectural floor for any V2X OBU/RSU shipped into the Indian market. |
|---|---|
| IEEE 1609.2 | V2X certificate format and trust model. Defines explicit and implicit certificate types, ECDSA P-256/P-384 signing, ECIES encryption, and the issuer chain back to the V2X Root CA. See /technologies/v2x-pki/. |
| ETSI TS 103 097 | V2X security header format. Secured-message structure (header / payload / trailer), certificate-included vs certificate-digest-referenced signing, validity period and geographic region restrictions, certificate-chain construction rules. |
| ETSI TS 102 941 | V2X trust and privacy management. Enrolment Authority and Authorisation Authority roles, the EC-to-PC issuance flow, the pseudonymity model, and the privacy guarantees the architecture is intended to deliver. |
| ISO 21177 | ITS station security services. Authentication, authorisation, data protection, and message integrity services across the ITS station stack. |
| GSMA SGP.32 | IoT eSIM profile lifecycle. The structural parallel from telecom; the operational pattern AmbiSecure draws on for credential-lifecycle design. |
Standards are described here as design-alignment references, not as formal certifications of the integrated AmbiSecure product unless explicitly stated. The underlying secure-element silicon’s CC EAL5+ certification at the chip level is the one factual certification claim on this surface.
Capabilities that map to V2X programmes.
Product: IoT Security Co-Processor
Dual-domain co-processor for connected devices. CC EAL5+ secure-element silicon, hardware key isolation, ECDSA-P256/P-384 signing, OTA verification applet.
Solution: V2X security architecture
How OBU/RSU PKI, EA/AA, pseudonymous certificates, and HSM-backed provisioning fit together end-to-end.
Technology: V2X PKI
IEEE 1609.2, ETSI TS 103 097, certificate fields, EC vs PC, Butterfly Key Expansion, revocation models.
Service: JavaCard development
Custom V2X certificate-management applets, EC storage, PC rotation, OTA-deployable policy changes.
Technology: Secure elements
The silicon class that V2X identity rests on — the role, the threat model, the integration patterns.
Sister: eSIM Initiative
Telecom-grade credential lifecycle. The operational parallel for V2X EA/AA architecture.
Tool: IEEE 1609.2 parser
Inspect a V2X certificate field-by-field, in your browser. Standards references on every row.
Tool: V2X chain validator
Structural validation: parse each link, check HashedId8 linkage, validity, signature scheme.
Solution: device identity at scale
The architectural unification across V2X, eSIM, IoT, and embedded fleets. V2X EA/AA, eSIM SM-DP+, and FIDO attestation in one architectural frame.
Reference: IEEE 1609.2
Structured V2X certificate-format reference — field-by-field, COER encoding, comparison table with X.509. Pair with the parser tool.
Reference: ETSI TS 102 941
V2X PKI architecture reference — EA, AA, EC/PC issuance, Butterfly Key Expansion, CRL/CTL distribution.
Designing a V2X OBU, RSU, or PKI integration?
We will sit with your hardware lead, your firmware lead, and your security architect, walk the trust model end-to-end, and show where the secure element, the applets, and the personalisation line fit in. Reference designs available under NDA.