V2X PKI — why vehicle identity is harder than web PKI.
A V2X certificate is not an X.509 certificate. The encoding is different, the identity model is inverted, the lifetimes are three orders of magnitude shorter, the issuance volumes are three orders of magnitude higher, and the verification has to work with the network unplugged. The cryptography is the same. The architecture above the cryptography is not.
Where the two PKI worlds diverge.
| Dimension | Web PKI (X.509) | V2X PKI (IEEE 1609.2) |
|---|---|---|
| Identity | Named subject — CN, SAN | Pseudonymous, no human-readable identity |
| Certificate lifetime | One to three years | Minutes to a week (pseudonymous) / years (enrolment) |
| Issuance volume | Thousands per day per CA | Millions per minute at national peak |
| Offline trust | Not required | Mandatory — PC5 sidelink has no network |
| Key storage | Software acceptable | Hardware secure element required by design intent |
| Encoding | ASN.1 DER | ASN.1 COER — ITU-T X.696 |
| Signature | Broad range of RSA and ECDSA | ECDSA P-256 / P-384 / Brainpool variants |
| Privacy | Not a design goal | Core design goal |
| Revocation | OCSP or CRL pull | OCSP-style for connected; RSU CRL broadcast for offline |
| Chain depth | Can be deep | Shallow — three levels in deployed practice |
COER matters more than it looks. It is a canonical encoding: any given structure has exactly one byte representation, which makes structures deterministic and byte-comparable. That property is load-bearing, because hashes are computed over the encoded form and certificates are referenced by digest.
The Enrolment Credential proves the device is real. The Pseudonymous Certificate signs the messages.
They are never the same thing.
| Dimension | Enrolment Credential (EC) | Pseudonymous Certificate (PC) / Authorisation Ticket (AT) |
|---|---|---|
| Lifetime | Years — device life, or until re-enrolment | Minutes to about a week, set by policy |
| Identity binding | Hardware-bound to a specific secure element | No persistent identity; one of a batch |
| Issuer | Enrolment Authority | Authorisation Authority |
| Used for | Authenticating to the AA when requesting operational credentials | Signing V2X messages in the field |
| Number per device | One, typically | Dozens to thousands |
| Issued in response to | Hardware attestation from the secure element | An anonymised request signed under the EC |
Factory to field in five steps.
Key generation
The secure element generates the key pair inside the tamper boundary. The public key and a hardware attestation leave. The private key does not.
Enrolment
The Enrolment Authority verifies the attestation and issues the long-lived Enrolment Credential — the device's proof of a right to exist in the system.
Authorisation
The Authorisation Authority receives an anonymised request signed under the EC and returns a batch of short-lived pseudonymous certificates.
Signing
The secure element signs every message with the currently active credential and rotates on schedule.
Verification
The signature is checked against the attached credential, chained to a trusted root, revocation checked against local material — all in milliseconds, all offline.
The privacy split is structural, not policy. The EA knows “this is genuine certified hardware” but never sees a signed message. The AA signs the credentials that sign messages but never learns which EC requested them. In the ETSI protocol this is enforced cryptographically: the proof-of-possession signature made under the EC is encrypted to the EA, so that the AA — which forwards it — cannot read it. Two independent parties must collude to link a broadcast message to a vehicle.
The AmbiSecure engineering blog works the same flow from the security-primitive side: how V2X PKI works.
The sequence that matters if you are implementing against TS 102 941 V2.2.1.
Enrolment (clause 6.2.3.2.1), nesting outward:
InnerECRequest— carries the canonical ID, or the HashedId8 of the current EC on re-enrolment, the certificate format, the verification key, and the requested subject attributesInnerECRequestSignedForPOP— self-signed with the new private key, proving possessionEtsiTs102941Data- Outer
EtsiTs103097Data-Signed— signerselffor first enrolment,digeston re-enrolment EtsiTs103097Data-Encrypted— ECIES to the EA's HashedId8
The rule is explicit: for each enrolment request, the ITS station shall generate a new verification key pair. The response carries a requestHash — the leftmost 16 octets of SHA-256 over the request's encrypted structure — and is encrypted by reusing the same AES session key the requester chose, with no new key agreement.
Authorisation (clause 6.2.3.3.1) — the privacy-critical part:
- The station generates a new verification key pair, an optional encryption key pair, and a random 32-octet HMAC key.
- It computes a
keyTag= HMAC-SHA256 over the serialised concatenation of the verification and encryption keys, truncated to the leftmost 128 bits. This lets the EA bind the request to keys it never sees. - The
SharedATRequestcarries the EA's ID, the keyTag, the certificate format and the requested attributes. It must containappPermissionsand must not containcertIssuePermissions. - The proof of possession is signed under the EC and encrypted to the EA, so the AA cannot read it.
- The AA decrypts, verifies the proof of possession, recomputes the HMAC and compares it to the keyTag, sends an
AuthorizationValidationRequestto the named EA, and issues the ticket only on a positive response.
The attestation step in stage one is the same architectural move FIDO makes at enrolment — a device proving to an authority that its key lives in certified silicon rather than in software. The protocols are different; the shape is not. Attestation in FIDO →
Explicit and implicit forms, one ToBeSigned skeleton.
| Field | Description |
|---|---|
version | Uint8, fixed at 3 in the current specification |
type | explicit (0) or implicit (1) |
issuer | HashedId8 reference to the issuing certificate, or a self-signed marker with a hash-algorithm identifier |
toBeSigned.id | CertificateId — a name, a linkage value for pseudonymous certificates, or none |
toBeSigned.cracaId | HashedId3 of the Certificate Revocation Authorization CA that may revoke this certificate |
toBeSigned.crlSeries | Which CRL stream lists revocations for this certificate |
toBeSigned.validityPeriod | SEQUENCE { start Time32, duration Duration } — microseconds to years |
toBeSigned.region | Optional — circular, rectangular, polygonal or identified-region restriction |
toBeSigned.assuranceLevel | Optional SubjectAssurance |
toBeSigned.appPermissions | Optional SequenceOfPsidSsp — which services this certificate may authenticate |
toBeSigned.certIssuePermissions | Optional — what it may pass on, if it is a CA certificate |
toBeSigned.verifyKeyIndicator | verificationKey for explicit, reconstructionValue for implicit |
signature | Explicit only — ecdsaNistP256, ecdsaBrainpoolP256r1, ecdsaNistP384, ecdsaBrainpoolP384r1 |
appPermissions is worth dwelling on. The PSID and SSP pair is what stops a vehicle from claiming signal-controller authority: permissions in the certificate decide what a sender is allowed to say. A roadside unit may sign SPaT, MAP and IVI; a vehicle may not. That is enforced cryptographically, not by convention.
The version position matters. IEEE 1609.2 moved in 2026. IEEE 1609.2-2022 is superseded by IEEE 1609.2-2025, approved by the IEEE-SA Standards Board on 10 December 2025 and published 29 May 2026; IEEE 1609.2.1-2022 is superseded by IEEE 1609.2.1-2026, board-approved 12 February 2026 and published 3 July 2026. IEEE has published no delta summary, so the specific technical changes are not publicly documented and none are described here. And ETSI TS 103 097 V2.2.1 (March 2026) now profiles IEEE 1609.2-2025 and states it is to be read together with that base standard — so the European profile has already tracked the update. Anyone writing 1609.2 code in 2026 should be working from the 2025 text.
To inspect a real certificate field by field, the AmbiSecure engineering team maintains a client-side IEEE 1609.2 certificate parser and a V2X certificate chain validator. Both run entirely in the browser.
Header, payload, trailer — and the digest that makes it fit on the radio.
ETSI TS 103 097 defines the envelope: a header carrying protocol version, header info, payload type and signer info; the payload — CAM, DENM, BSM, MAP, SPaT; and a trailer with the signature plus geographic and temporal validity restrictions.
The signer info field carries the operational compromise that makes V2X work on a congested radio. Including a full certificate in every message would saturate the channel, so messages reference the certificate by digest — its HashedId8 — and the full certificate is re-broadcast on a separate, slower cadence. A receiver that has not yet seen the certificate can request it through peer-to-peer certificate distribution, using a cheap three-byte HashedId3 hint.
TS 103 097 V2.2.1's certificate profile is tight: cracaId is zeroed, crlSeries is zero, and at least one of appPermissions or certIssuePermissions must be present. Europe zeroes the CRACA fields because it does not rely on linkage-based revocation the way the US SCMS does — it relies on short authorisation-ticket validity plus the EA refusing to reissue. The two models compared →
A structural problem nobody else has to solve.
An engineering view, offered on its own terms. Nothing here implies endorsement by, or a relationship with, any authority.
TRAI's Consultation Paper No. 08/2026 identifies a structural problem that is specific to India. India's existing digital-trust infrastructure, under the IT Act and the CCA-licensed certifying authorities, recognises only ITU-T X.509 certificates. Global V2X standards use IEEE 1609.2 and ETSI ITS certificate formats. Those are genuinely incompatible encodings, not variants.
The MoRTH ITS Task Force recommendation quoted in the paper is a harmonised approach based on ETSI TS 102 941, with the option of either a separate dedicated national ITS root CA, or a coexistence framework in which the national X.509 root CA countersigns ITS certificates.
Our engineering view: the V2X PKI should be a parallel hierarchy, not a sub-CA of RCAI, with the CCA providing statutory oversight of the V2X Root CA, a dedicated operating entity of C-DOT class running day-to-day EA and AA operations, TEC defining certificate profiles and test standards, and CERT-In handling incident response. X.509 remains appropriate for RSU-to-platform backhaul over TLS. Cross-recognition for non-safety contexts should be deferred until the safety framework is operational.
And one sequencing point that matters more than any technical detail: publish the Certificate Policy before the first RSU tender. Retrofitting a trust model onto deployed hardware is the one mistake that cannot be patched. India's V2X framework →
Telecom solved a version of this first.
Before designing a national V2X credential architecture from first principles, it is worth looking at the one the telecom industry already operates at that scale.
Remote SIM provisioning binds a long-term identity to tamper-resistant silicon at manufacture (the eUICC and its EID), uses that identity to obtain an operational credential (an operator profile), delivers it remotely to a device nobody will physically touch again, and withdraws it without a recall. SM-DP+ prepares and delivers profiles; SM-DS handles discovery. Structurally, those map onto the Authorisation Authority and the Enrolment Authority almost cleanly.
The differences matter too, and they are instructive. eSIM provisioning is a unicast, connected, acknowledged transaction — the device is online and the server knows it succeeded. V2X credential provisioning has to survive a device that is offline for a week and a verification step that happens with no server reachable at all. eSIM has no pseudonymity requirement; V2X's entire architecture is bent around one. So the telecom model is a good source of operational patterns — provisioning-line key custody, remote lifecycle, revocation without recall, multi-operator governance — and a poor source of privacy architecture.
eSIM and eUICC architecture → · Remote SIM provisioning, in detail → · Trust chain from manufacturing to device →
Where this fits.
Pseudonymity and privacy
Butterfly key expansion and linkage values, with the actual constructions.
Hardware root of trust
Why the enrolment key has to be generated inside the boundary in the first place.
SCMS vs CCMS
Four national trust models, and what each does with revocation.
AmbiSecure V2X PKI reference
The same certificate architecture from the secure-element side, with the parser tooling.
eSIM credential lifecycle
The telecom architecture this one rediscovered twenty years later.
PKI test environments
Where to run this flow end to end without a commercial contract.
Questions this page answers.
What is V2X PKI?
The public key infrastructure that issues and manages the certificates used to sign V2X messages. It has two distinguishing features against ordinary web PKI: certificates are pseudonymous, so a vehicle is authenticated without being identified, and verification works entirely offline, because the receiver has no network.
What is the difference between an enrolment credential and a pseudonymous certificate?
The enrolment credential is long-lived, hardware-bound, issued by the Enrolment Authority, and used only to authenticate to the Authorisation Authority when requesting operational credentials. The pseudonymous certificate — called an authorisation ticket in Europe — is short-lived, carries no persistent identity, is issued by the Authorisation Authority, and is what actually signs messages on the road.
Why can't V2X use normal X.509 certificates?
Three reasons. Size: an X.509 certificate is large relative to a 300-byte safety message on a congested 10 MHz channel. Privacy: X.509 binds a named subject, and a named subject broadcast ten times a second is a tracking beacon. Offline verification: the X.509 revocation model assumes the relying party can reach an OCSP responder, which a vehicle on a sidelink cannot.
How does a vehicle check whether a certificate has been revoked?
Two paths. Connected devices can pull revocation status from a trust-anchor service. Offline devices rely on roadside units broadcasting certificate revocation list deltas and trust-list updates inside normal beacon traffic, so a passing vehicle receives updates without any connectivity of its own. In Europe, short authorisation-ticket validity does most of the work: a compromised station is stopped by revoking its enrolment credential so the Authorisation Authority simply issues nothing further.
Who runs the V2X PKI?
It depends on the jurisdiction. In the US, multiple commercial SCMS operators run in parallel under a common policy. In the EU, a Certificate Policy Authority approves root CAs, a Trust List Manager signs the European Certificate Trust List, and the Joint Research Centre operates the point of contact. In China, a Trusted Root Certificate List Authority maintains a list across multiple authorised root CAs. India has not decided. SCMS vs CCMS.