V2X & ITS security architecture.
Vehicle-to-everything safety messaging only works if every receiver can trust every sender. The cryptography is the easy part; the architecture — pseudonymity, hardware binding, offline trust, certificate rotation at telecom volumes — is what makes a V2X PKI deployable instead of theoretical.
An unsigned V2X message is, by definition, unverifiable.
The V2X threat model is not academic. The signed message a vehicle broadcasts could be a "collision imminent" warning to the vehicle behind it. The signed message an RSU transmits could be a "school zone, slow to 30 km/h" notice to every vehicle entering it. The signed message an emergency vehicle transmits could be a request that every traffic light on its path go green.
Every one of those messages, unsigned, is forgeable by any attacker with a software-defined radio. A V2X deployment that allows unsigned messages is a hazard-amplification system. A V2X deployment that allows extractable signing keys is a hazard-amplification system one stolen vehicle away.
Offline verification compounds the requirement. PC5 sidelink — the direct vehicle-to-vehicle radio link — carries safety messages that must be verified before a vehicle can react. A receiver cannot wait for a cloud round-trip. The trust anchors and the verification logic have to be local. That means the PKI architecture has to ship verification material to vehicles in advance and keep it up-to-date over the air.
EA, AA, and the privacy-preserving certificate split.
The V2X PKI structurally separates "which device am I?" from "what certificate did I just sign this message with?" — so the device is authenticated without being identified per message.
Manufacturing
SE generates EC key pair inside tamper boundary; public key + attestation sent to EA.
Enrolment Authority
Verifies hardware attestation; issues long-lived Enrolment Credential (EC).
Authorisation Authority
Receives anonymised request signed under EC; issues batch of short-lived Pseudonymous Certificates (PC). Does not learn vehicle identity.
Field signing
OBU signs each V2X message with the currently-active PC. SE rotates PCs on schedule.
Verification
Receivers verify the signature against PC; chain back to AA root; check revocation locally.
Reference: ETSI TS 102 941 trust and privacy management framework defines this split. The EA knows "this is a genuine certified-hardware device" but never sees signed messages. The AA issues the PCs that sign messages but never learns which EC requested them. Even an attacker who compromised both authorities could not by themselves link a message back to a specific vehicle.
Why software key storage is insufficient.
V2X devices are not in air-conditioned data centres. OBUs are in vehicles that get stolen, get crashed, get parked in salvage yards, get sold on the second-hand market. RSUs are bolted to roadside poles in cities where local contractors and curious passersby have physical access to them.
Software key storage means the credential is in flash, in RAM during a signing operation, on the JTAG / SWD debug interface if it has not been physically disabled, in the boot ROM if the boot ROM has access to it. An attacker with a soldering iron and time will find one of these. Once they have the key, they have the device's identity. They can manufacture a clone. The cloned device can transmit forged V2X messages indistinguishable from the original. The PKI cannot help: the messages are validly signed.
The standards-mandated answer is a tamper-resistant secure element: the private key never leaves the SE, signing operations execute inside the SE, the host MCU only sees the signature output. Common Criteria EAL5+ is the floor for the silicon — the integrated AmbiSEC Module product is a target for further automotive-grade certification (ISO 26262, ASPICE), not yet a claim.
MTCTE cybersecurity testing in India should mandate this property as a pass/fail criterion for V2X equipment, not as a recommendation. Both IEEE 1609.2 / ETSI TS 103 097 and TEC 31318:2021 already point to it.
EC injection on a controlled provisioning line.
The Enrolment Credential is the device's long-lived identity. If the provisioning step that creates it is sloppy — if the EC private key was ever in plaintext on a factory PC, if the operator could read a hex dump — the integrity of the whole deployment is compromised before the device ships.
The correct pattern is HSM-backed: the EC public key crosses the boundary; the EC private key never leaves the SE; the personalisation traffic between provisioning HSM and SE is wrapped under GlobalPlatform SCP03 (or an equivalent secure channel protocol). No plaintext key material is ever exposed to the factory line, the operator, or the factory floor's network.
Per-device unique identity is established through hardware attestation: the SE proves to the provisioning system that it is a specific instance of certified-hardware silicon, not a soft simulator. That attestation flows from the SE to the EA, which verifies it before issuing the EC. The EA refuses requests it cannot attest. See: smart-card personalisation for the same pattern in adjacent deployments.
Certificate rotation, OTA update, and revocation.
PC rotation
Automated. SE-managed. Typically every 5–10 minutes per OBU. No human involvement. The current PC is the one the SE picks; the next batch is fetched ahead of time over the connected channel.
OTA credential update
PCs and ECs flow over an authenticated channel between the device and the AA / EA. The SE gates application: a PC delivered out of band, or with an invalid issuer chain, is rejected at the SE boundary.
Revocation: connected path
For connected OBUs and RSUs, revocation information is pulled OCSP-style from a trust-anchor service. The SE evaluates the revocation status before accepting a counterparty's signed message.
Revocation: offline path
For OBUs that may be offline for hours or days, RSUs broadcast CRL deltas as part of their normal beacon traffic. Vehicles passing the RSU receive the update without needing connectivity.
Applet upgrade path
Certificate policy is enforced inside the SE’s V2X applet. Policy changes — new validity-period rules, additional revocation distribution paths, alternative signing schemes — deploy as applet upgrades under GlobalPlatform SCP03. No device recall.
Audit trail
EC issuance, PC batch issuance, revocation events — all logged with HSM-signed attestation back to the V2X Root CA. Each event is independently auditable.
Capabilities that map to V2X programmes.
| IoT Security Co-Processor | AmbiSEC Module dual-domain co-processor. CC EAL5+ secure-element silicon at the chip level. Hardware key isolation, ECDSA-P256/P-384 signing, secure boot, OTA verification applet. Automotive operating range available. |
|---|---|
| JavaCard applet development | Custom V2X applet engineering — EC storage, PC batch lifecycle, signing-protocol surface, OTA-deployable policy under GlobalPlatform SCP03. Same team that wrote the FIDO / PIV / OpenPGP applet portfolio. |
| Provisioning infrastructure | HSM-backed personalisation line, SCP03-wrapped key injection, per-device unique attestation chain. The pattern AmbiSecure already uses for smart-card personalisation; portable to V2X EC injection. |
| eSIM Initiative (sister) | esim.ambimat.com — telecom-grade credential lifecycle at SGP.22 / SGP.32 scale. The operational template AmbiSecure draws on for V2X EA/AA architectural choices. |
| FIDO Validation Server | Operator MFA for the management plane (EA / AA operators, trust-anchor administrators). Phishing-resistant authentication for the humans who hold the PKI’s keys. |
What AmbiSecure does not yet provide.
We are not the only piece of a V2X deployment, and we are deliberately specific about which pieces we are.
- AmbiSecure does not currently ship an ISO 26262 / ASPICE-certified V2X stack. Automotive-grade certification of the integrated AmbiSEC Module product is a target, not a claim.
- AmbiSecure is not a V2X Root CA operator. Root CA operation is a national-trust-anchor function; in the Indian context this would sit with a designated entity under CCA / DoT / C-DOT oversight.
- AmbiSecure is not a turnkey OBU or RSU vendor. We build the secure-element silicon, the applet platform, and the provisioning infrastructure that integrate into an OBU/RSU OEM's product.
- The TRAI Consultation Paper 30/04/2026 referenced on this site is a public consultation document. No reference here implies endorsement, procurement, or any other relationship with TRAI, CCA, DoT, or C-DOT.
Where we fit: SE silicon, custom applets, provisioning-line infrastructure, operator-side MFA. We integrate alongside the OEM, the system integrator, and the designated PKI operator.
Inspect a V2X certificate in your browser.
IEEE 1609.2 V2X Certificate Parser
Client-side COER decoder for V2X / ITS certificates. Hex, Base64, or PEM-wrapped input. Renders a labelled field tree with standards references on every row. Synthetic example certificates included; nothing leaves the browser.
V2X Certificate Chain Validator
End-entity → intermediate → root. Parses each link, computes HashedId8 via WebCrypto SHA-256, checks linkage. Structural validation only — cryptographic signature verification is explicitly out of scope.
Structured engineering references for the V2X / ITS stack.
IEEE 1609.2
Certificate structure, COER encoding, IssuerIdentifier, ValidityPeriod, ECCP256/P384 curve points, ECDSA signature shapes, X.509 comparison table.
ETSI TS 103 097
SecuredMessage wire format — header info, SignerInfo digest / certificate / chain modes, application-profile constraints (CAM / DENM / SPaT / MAP / IVI).
ETSI TS 102 941
V2X PKI architecture — Root CA, EA, AA, EC and PC issuance flows, Butterfly Key Expansion, CRL and CTL distribution including RSU broadcast.
ISO 21177
ITS station session-layer security — secure-session establishment, certificate-based mutual authentication, EC vs PC at session layer.
GSMA SGP.32
IoT eSIM RSP architecture — eUICC, IPA, eIM, SM-DP+, SM-DS, structural parallel to V2X EA/AA lifecycle.
Device identity at scale
The architectural unification page across V2X, eSIM, IoT, transit, and embedded fleets — the broader frame V2X security sits inside.
Designing a V2X integration?
We will walk the trust model end-to-end with your hardware lead and your security architect — SE selection, applet structure, provisioning-line architecture, EA/AA integration patterns. Reference designs under NDA.