V2X PKI — IEEE 1609.2 & ETSI TS 103 097.
A V2X certificate is not an X.509 certificate. The encoding is different (COER, not DER). The identity model is different (pseudonymous, not named). The validity model is different (minutes, not years). The volume is different (millions per minute at peak, not thousands per day). This page is the technical reference for how the format actually works, why it diverges from web PKI, and how the lifecycle architecture wraps around it.
V2X PKI vs general-purpose web PKI.
Where the two PKI worlds diverge along the dimensions that matter for design.
| Dimension | Web PKI (X.509) | V2X PKI (IEEE 1609.2) |
|---|---|---|
| Identity | Named subject (CN, SAN) | Pseudonymous — no human-readable identity |
| Certificate lifetime | 1–3 years | Minutes (PC) / years (EC) |
| Issuance volume | Thousands/day per CA | Millions/minute at national peak |
| Offline trust | Not required | Mandatory (PC5 sidelink, no network) |
| Key storage | Software acceptable | Hardware SE required by design intent |
| Encoding | ASN.1 DER | ASN.1 COER (Canonical Octet Encoding Rules) |
| Signature | RSA / ECDSA broad range | ECDSA-P256 / P-384 / Brainpool variants |
| Privacy | Not a design goal | Core design goal — pseudonymity built in |
| Revocation | OCSP / CRL pull | OCSP for connected; RSU CRL broadcast for offline |
Certificate structure — explicit and implicit forms.
IEEE 1609.2 defines two certificate types — explicit (signature attached) and implicit (signature reconstructed from a curve point). Both share the same ToBeSigned skeleton.
| Field | Description |
|---|---|
| version | Uint8. Fixed at 3 in the current specification. |
| type | CHOICE: explicit (0) or implicit (1). Determines whether the signature is attached or reconstructed. |
| issuer | IssuerIdentifier — either a HashedId8 reference to the issuing certificate, or a self-signed marker with a hash algorithm identifier. |
| toBeSigned.id | CertificateId — the certificate's own identity, including a name (linkage value for pseudonymous certs) or none. |
| toBeSigned.cracaId | HashedId3 — identifies the Certificate Revocation Authorization CA, if any, that may revoke this certificate. |
| toBeSigned.crlSeries | CrlSeries — identifies which CRL stream lists revocations for this certificate. |
| toBeSigned.validityPeriod | SEQUENCE { start Time32, duration Duration }. Duration can range from microseconds to years; PC durations typically minutes. |
| toBeSigned.region (optional) | GeographicRegion — circular, rectangular, polygonal, or identified-region restriction on where this certificate is valid. |
| toBeSigned.assuranceLevel (optional) | SubjectAssurance — assurance level of the subject. |
| toBeSigned.appPermissions (optional) | SequenceOfPsidSsp — the application services this certificate is allowed to authenticate (PSID + Service Specific Permissions). |
| toBeSigned.certIssuePermissions (optional) | SequenceOfPsidGroupPermissions — what permissions this certificate can pass on if it is itself a CA cert. |
| toBeSigned.verifyKeyIndicator | CHOICE: verificationKey (PublicVerificationKey) for explicit certs, or reconstructionValue (EccP256CurvePoint) for implicit certs. |
| signature (explicit only) | CHOICE: ecdsaNistP256Signature, ecdsaBrainpoolP256r1Signature, ecdsaNistP384Signature, or ecdsaBrainpoolP384r1Signature. |
A client-side IEEE 1609.2 certificate parser is now live, matching the existing APDU, TLV, and ATR parsers. A companion V2X certificate chain validator performs structural-only chain checks (parse, HashedId8 linkage, validity window, signature scheme).
Secured-message structure — header, payload, trailer.
ETSI TS 103 097 wraps an application payload in a security envelope. The structure has three logical regions:
- Header: protocol version, header info, payload type, signer info. The signer info field is the critical privacy decision: the certificate is either included in full (large but self-contained) or referenced by digest (small but requires the receiver to have already seen the full certificate). For PC5 sidelink, message-by-message certificate inclusion would saturate the radio; in practice messages reference the cert by digest, and the full cert is re-broadcast on a separate cadence.
- Payload: the application-layer message itself — CAM (Cooperative Awareness Message), DENM (Decentralised Environmental Notification Message), BSM (Basic Safety Message), MAP, SPaT, etc. The signer of the secured message is asserting authority over the contents.
- Trailer: the signature itself, plus any geographic or temporal validity restrictions. A signature can be tied to a region (this OBU only signs messages valid inside its current geographic cell) and a time window (this PC is only valid for the next 7 minutes).
Certificate-chain construction in V2X is bounded: each certificate references its issuer by HashedId8, and the chain terminates at the V2X Root CA. A typical chain is two or three deep — Root CA → AA → PC, or Root CA → EA → EC. There is no equivalent of web PKI's deeper intermediate hierarchies.
Enrolment Credentials versus Pseudonymous Certificates.
| Dimension | Enrolment Credential (EC) | Pseudonymous Certificate (PC) |
|---|---|---|
| Lifetime | Years (device life or until re-enrolment) | Minutes to ~1 week, configurable |
| Identity binding | Hardware-bound to a specific SE | No persistent identity; one of a batch |
| Issuer | Enrolment Authority (EA) | Authorisation Authority (AA) |
| Used for | Authenticating to the AA when requesting PCs | Signing V2X messages in the field |
| Number per device | One (typically) | A batch of dozens to thousands |
| Privacy property | Identifies the certified device | Pseudonymous — rotated to prevent linkage |
| Issued in response to | Hardware attestation from SE | Anonymised request signed under EC |
Butterfly Key Expansion is the technique that lets the AA issue an entire batch of PCs from a single anonymous request without ever learning which EC made the request. The vehicle sends a single signed request derived from its EC; the AA derives n independent PC key pairs from a public seed using a chained derivation, signs each, and returns the batch. Because the derivation is one-way and the AA never sees the EC's identity, an attacker who later compromises the AA cannot link the PC batch back to a vehicle.
Provisioning → refresh → revocation.
Enrolment
SE produces hardware attestation; EA verifies SE is MTCTE-certified hardware; EA issues EC.
PC issuance
Vehicle sends anonymised request signed under EC; AA issues PC batch via Butterfly Key Expansion.
Rotation
SE rotates the active PC every 5–10 minutes (configurable). Older PCs go to history, then discarded after a retention window.
Revocation
CRL deltas distributed: pull-OCSP for connected, RSU broadcast for offline OBUs. SE rejects messages signed under a revoked certificate.
Re-enrolment is rare. An EC is replaced only on incident (suspected SE compromise, hardware fault, change of ownership). PC refresh is continuous and automatic: when the SE’s reserve PC pool dips below threshold, it asynchronously requests a new batch from the AA over the authenticated channel. The user, the OBU firmware, and the application layer are not involved.
TRAI CP 30/04/2026 and the shape of an Indian V2X PKI.
The TRAI Consultation Paper on V2X Communication (CP No. 30/04/2026) is a public consultation document. It frames the policy questions a domestic V2X PKI deployment has to answer:
- Trust anchor governance. The proposed direction is a V2X Root CA under CCA oversight, structurally parallel to the existing RCAI root authority but operating in a separate certificate hierarchy. CCA does not issue V2X certificates directly; it accredits the operators that do.
- EA and AA operator designation. Likely candidates are DoT / C-DOT or an entity nominated under their oversight. The EA and AA must be operationally independent to preserve the privacy property of the EC/PC split; an entity that holds both roles can in principle de-anonymise.
- MTCTE cybersecurity baseline. Equipment certified under MTCTE for V2X service should be required to demonstrate hardware-backed key storage. TEC 31318:2021 already articulates the property at the IoT baseline; the V2X profile sharpens it to ECDSA-P256/P-384 signing inside a tamper-resistant SE.
- Parallel hierarchy. The V2X PKI runs independently of RCAI. An EC is not an X.509 client certificate. A V2X Root CA is not RCAI. Cross-recognition between the two hierarchies is a separate policy question and is not assumed.
Nothing on this page should be read as endorsing any specific candidate operator or as anticipating the outcome of the consultation process. The consultation document is referenced here for technical alignment, not commercial positioning.
Where this fits in the bigger picture.
Secure elements
The silicon class V2X identity rests on — tamper resistance, key isolation, attestation.
IoT Security Co-Processor
AmbiSEC Module — the dual-domain co-processor product. CC EAL5+ silicon at the chip level.
FIDO attestation
FIDO’s attestation model is a useful analogy for V2X’s EA enrolment, not equivalent — same shape, different protocol.
Solution: V2X security
How OBU/RSU PKI, EA/AA, pseudonymous certs, and HSM-backed provisioning fit together end-to-end.
Industry: Connected Mobility
Why V2X infrastructure demands hardware-backed identity, with India-context positioning.
Sister: eSIM Initiative
SGP.32 telecom-grade credential lifecycle — the operational parallel for V2X EA/AA.
Tool: IEEE 1609.2 parser
Client-side COER decoder. Paste a V2X certificate in hex / Base64 / PEM and see the labelled field tree.
Tool: V2X chain validator
Structural validation of an end-entity → intermediate → root chain. HashedId8 linkage via WebCrypto.
Solution: device identity at scale
The unification page. V2X EA/AA in the same architectural frame as eSIM SM-DP+, FIDO attestation, and embedded fleet credential lifecycle.
Ref: IEEE 1609.2
Structured certificate-format reference — field-by-field, COER encoding, comparison table with X.509.
Ref: ETSI TS 102 941
V2X PKI architecture reference — EA, AA, EC/PC issuance, Butterfly Key Expansion, CRL / CTL distribution.
Ref: ETSI TS 103 097
SecuredMessage wire-format reference — header info, SignerInfo modes, CAM / DENM / SPaT / MAP profiles.
Ref: ISO 21177
ITS station session-layer security — secure-session establishment, certificate-based mutual auth.
Ref: GSMA SGP.32
IoT eSIM RSP architecture — eUICC, IPA, SM-DP+, SM-DS, parallel to V2X EA/AA lifecycle.