How V2X PKI Works: EA, AA, Pseudonymous Certificates, Lifecycle
V2X PKI looks superficially like web PKI: a root, intermediates, end-entity certificates, signatures over messages. Open it up and the resemblance stops. Two issuing authorities instead of one. Per-message credentials measured in minutes instead of years. A privacy property that is structural, not legal. And a revocation model built for vehicles that may never see a backhaul. This is the engineer’s walk-through of why the V2X PKI looks the way it does.
If you have built a web PKI — CA, intermediates, certificate issuance over ACME, OCSP responders, CRL distribution points — almost everything you know about lifecycle, revocation, and trust anchors is the wrong starting point for V2X. The cryptography is the same. The architecture above the cryptography is not. This piece walks the V2X PKI top-to-bottom: hierarchy, identities, credential types, the privacy-preserving split, the issuance flows, and the revocation channel.
Why V2X PKI is not web PKI
The four properties below are what force the architectural divergence. Hold them in mind as the rest of the piece unfolds.
- Pseudonymity. A signed safety message authenticates that the sender is a certified hardware-backed device. It must not identify which device. Web PKI does the opposite: a TLS certificate is meant to identify the server.
- Per-message credentials at telecom scale. An OBU broadcasting a Cooperative Awareness Message at 10 Hz signs a message every 100 milliseconds. A fleet of a million vehicles signs ten million messages per second. Even a per-second credential cycle issues credentials at sustained rates a single CA tier cannot serve.
- Offline trust. A vehicle on PC5 sidelink verifies messages from neighbours that may never have appeared on a network. There is no DNS lookup, no OCSP request, no real-time fetch. Trust material has to have arrived before the verification is needed.
- Hardware binding as a deployment-grade requirement. An OBU is a field-deployed device subject to physical access. A V2X identity stored in software is one extract away from a fleet-wide clone. The PKI assumes the device’s key material lives in a tamper-resistant secure element — not as an option, as the architectural baseline.
The hierarchy, top to bottom
The V2X PKI is six entities in a deliberate shape. The split between three of them — Root CA, Enrolment Authority, Authorisation Authority — is the architectural centre.
// V2X PKI hierarchy (ETSI TS 102 941 / IEEE 1609.2)
┌──────────────────────────┐
│ Root CA │ ← regulator-designated
│ (self-signed cert) │ (CCA in India proposal)
└────────────┬─────────────┘
│ signs
┌──────────────┴──────────────┐
│ │
┌───────▼────────┐ ┌───────▼────────┐
│ Enrolment │ │ Authorisation │
│ Authority │ │ Authority │ ← multiple per
│ (EA) │ │ (AA) │ region
└───────┬────────┘ └───────┬────────┘
│ issues EC │ issues PC batches
│ │
▼ ▼
┌────────────────────────────────────────────┐
│ ITS Station (ITS-S) — OBU / RSU │
│ • Holds EC inside secure element │
│ • Holds active PC batch │
│ • Signs V2X messages with current PC │
└────────────────────────────────────────────┘
Out-of-band trust anchor (not part of operational PKI):
┌──────────────────────┐
│ Manufacturer / EUM │ ← signs the per-device attestation key
│ │ injected at factory; verified by EA
└──────────────────────┘Root CA
The trust anchor. Self-signed. Sits in offline storage at the regulator-designated authority. In the European architecture the equivalent is the CAR 2 CAR Communication Consortium’s Certificate Policy Operating Centre; in the framework TRAI’s public consultation paper of 30 April 2026 proposes for India, the Root function maps onto the CCA. AmbiSecure does not operate a Root CA; this is a regulator’s responsibility.
Trust List Manager (TLM)
Signs and distributes the Certificate Trust List (CTL) — the list of currently trusted Root CAs. ITS stations fetch the CTL on a defined cadence so that their trust anchor set stays current. Distinct from the Certificate Revocation List: the CTL is "who is trusted", the CRL is "what is revoked".
Enrolment Authority (EA)
Knows which device is which. Verifies hardware attestation at enrolment. Issues a long-lived Enrolment Credential to the device. Sees the device’s identity exactly once, at enrolment, and never sees a signed V2X message from it. There is typically one EA per regional or operator jurisdiction.
Authorisation Authority (AA)
Issues the short-lived Pseudonymous Certificates an OBU actually uses to sign V2X messages. Receives requests authenticated under the device’s EC, but does not learn which EC issued the request. Cannot link a PC to a vehicle even with full record-keeping. There are usually multiple AAs per region for load distribution and operational isolation.
ITS Station (ITS-S)
The vehicle (OBU) or roadside unit (RSU). Holds the EC inside its secure element. Holds an active batch of PCs in the same boundary. Signs V2X messages with the currently-active PC; rotates PCs autonomously based on policy.
Manufacturer / EUM
Out-of-band trust anchor. Injects a per-device attestation key at the factory; signs an attestation certificate the EA verifies before issuing the EC. Not part of the operational PKI — the bootstrap authority that lets a fresh device prove "I am a genuine, certified-hardware ITS-S" before being enrolled.
What a V2X certificate actually looks like
The certificate format is defined by IEEE 1609.2 and shared by the ETSI ITS stack via the equivalence layer in ETSI TS 103 097. It is not X.509. It is a COER-encoded ASN.1 structure, schema-driven, no on-wire tags, designed to encode a credential in 120–250 bytes instead of the 1–2 kB an X.509 certificate would take.
// IEEE 1609.2 Certificate, top-level shape
Certificate ::= SEQUENCE {
version Uint8 -- = 3 in current spec
type CertificateType -- explicit | implicit
issuer IssuerIdentifier -- self | sha256AndDigest | sha384AndDigest
toBeSigned ToBeSignedCertificate -- the body
signature Signature OPTIONAL -- present for explicit certs
}
ToBeSignedCertificate ::= SEQUENCE {
id CertificateId -- linkageData | name | binaryId | none
cracaId HashedId3 -- revocation authority
crlSeries CrlSeries -- revocation series index
validityPeriod SEQUENCE {
start Time32 -- seconds since 2004-01-01 UTC
duration Duration -- µs | ms | s | minutes | hours | years
}
region GeographicRegion OPTIONAL
assuranceLevel SubjectAssurance OPTIONAL
appPermissions SequenceOfPsidSsp OPTIONAL -- PSID + SSP entries
certIssuePermissions SequenceOfPsidGroupPermissions OPTIONAL
verifyKeyIndicator VerificationKeyIndicator -- the public key
}The id field is where V2X identity diverges most visibly from X.509. An EC typically uses binaryId. A Pseudonymous Certificate uses linkageData — a value derived from a linkage seed held by the AA, used for privacy-preserving revocation. No vehicle identifier, no fleet identifier, nothing the receiver can tie back to a specific OBU.
The issuer field is a HashedId8: the last 8 bytes of SHA-256 over the issuer’s COER-encoded certificate. The HashedId8 is the V2X analogue of an X.509 Authority Key Identifier and is the link that lets a verifier follow the certificate chain compactly. The IEEE 1609.2 V2X Certificate Parser tool will compute the HashedId8 of any certificate you paste in.
The appPermissions entries are pairs of PSID (the V2X application identifier — CAM, DENM, SPaT, MAP, IVI) and SSP (service-specific permissions for that PSID). A certificate signs only the application traffic it carries an SSP for. This is how a PC issued for CAM signing is structurally prevented from being used to sign maintenance-management traffic.
Enrolment: how a device joins the PKI
Enrolment is the once-per-device flow that issues the long-lived EC. Three checks happen in sequence; if any fails, the device is not enrolled.
// Initial Enrolment Request (ETSI TS 102 941 §6)
ITS-S EA
│ │
│ 1. EnrolmentRequest: │
│ • manufacturer attestation │
│ • requested EC validity │
│ • verification key │
├────────────────────────────────────►│
│ │
│ │ 2. Validate attestation
│ │ against manufacturer chain
│ │
│ │ 3. Bind to device record
│ │
│ 4. EnrolmentResponse: │
│ • EC (signed by EA) │
│ • EA cert chain │
│◄────────────────────────────────────┤
│ │
│ 5. Install EC into secure │
│ element; never use it for │
│ signing V2X messages directly. │The attestation check at step 2 is the gate that decides whether a device is allowed to enrol at all. The EA asks: "does this attestation signature verify against a known manufacturer certificate chain, and does the attested platform meet the assurance baseline?" If the device’s factory identity is not recognised by the manufacturer chain the EA trusts, the device cannot be enrolled. The EC is then bound to the device record at the EA and returned to the device, where it lives inside the secure element for the rest of the device’s lifetime.
The EC is not used to sign V2X messages. Its job is to authenticate the device when it later requests Pseudonymous Certificates. Conflating the two is the most common conceptual mistake when first reading the standard.
PC issuance: where Butterfly Key Expansion lives
The interesting mechanism. The AA needs to issue a batch of PCs to the device. The device needs the batch to be unlinkable — from each other, and from the EC. The AA needs to do this without ever knowing the per-PC private keys or which EC requested the batch. Butterfly Key Expansion is what makes this work.
// Butterfly Key Expansion — conceptual flow
ITS-S AA
│ │
│ 1. Generate "caterpillar" key pair (Kcat_pub, Kcat_priv) │
│ and an expansion seed s. │
│ │
│ 2. Send AuthorizationRequest: │
│ • Kcat_pub │
│ • expansion function f │
│ • encrypted seed s │
│ • proof of EC possession (anonymised) │
├──────────────────────────────────────────────────────────►│
│ │
│ │ 3. (Optional) ask EA to confirm
│ │ EC is still valid (returns
│ │ yes/no, never the EC bytes)
│ │
│ │ 4. For i = 1..N:
│ │ derive Kpc_i_pub = f(Kcat_pub, s, i)
│ │ package PC_i = Sign_AA(Kpc_i_pub, attrs)
│ │
│ 5. AuthorizationResponse: │
│ • PC_1, PC_2, ..., PC_N │
│◄──────────────────────────────────────────────────────────┤
│ │
│ 6. For i = 1..N, locally re-derive Kpc_i_priv from │
│ Kcat_priv and s, store inside secure element. │
│ │
│ 7. Rotate through PC_1..PC_N over the batch lifetime. │The structural properties of this flow are what carry the privacy guarantee:
- The AA never sees a private key. It cannot impersonate the device.
- The AA cannot link the PCs in a batch to each other after issuance, because each derived public key is computationally independent.
- The AA cannot link the batch to a specific EC: the proof of EC possession is constructed so that the AA validates entitlement without learning the EC identity.
- An outside observer cannot link two consecutive V2X messages signed under different PCs from the same batch.
The unlinkability is mathematical, not policy. Even an AA operator who keeps every record possible cannot reverse the binding.
Signing a V2X message
Once the OBU has a PC batch, signing is local. The secure element holds the active PC’s private key; the host MCU asks the SE to sign the COER-encoded message. The signed message goes on the wire framed by ETSI TS 103 097 with the active PC’s HashedId8 in the signer_info field. Every Nth message (or once per second, depending on the profile) the full PC is included inline so that fresh receivers can verify without needing to fetch the certificate.
Rotation between PCs in the active batch is autonomous: the secure element advances to the next PC every few minutes, limiting the linkability window of any single PC. When the batch is exhausted, the OBU requests another. ETSI TS 103 097 covers the wire format in structured detail; the V2X Certificate Chain Validator walks an end-entity → intermediate → root chain and verifies the HashedId8 linkage between them.
Revocation: CRL, CTL, and the offline case
Revocation is the part of V2X PKI that has no comfortable analogue in web PKI, because the verifier in V2X may have no network connection at all. Three mechanisms operate in concert.
The CRL
Certificate Revocation List, signed by the issuing authority. Lists revoked ECs by HashedId8 and revoked PCs by their linkage values (not individual identifiers). The CRL is delta-published: each update extends the previous list rather than restating it. Verifiers cache the current state and apply deltas as they arrive.
Linkage-based PC revocation
Every PC in a batch carries a linkageData value derived from a per-device linkage seed. The seed is held only by the AA’s linkage authority — functionally a third partition that does not see the EA-side identity. To revoke an entire device’s PCs, the linkage authority publishes that one seed; every receiver computes the linkage values for each affected PC and rejects them. One published seed revokes an entire batch (and any future batches issued under the same seed) without listing PCs individually.
The CTL
Certificate Trust List, signed by the TLM. Updates the set of trusted Root CAs. Distributed alongside the CRL through the same channels. The CTL is how a regulator can rotate or retire a Root CA without breaking every deployed OBU.
The RSU-broadcast distribution channel
This is the mechanism that lets all of the above reach offline OBUs. RSUs cache the current CRL and CTL and rebroadcast them as part of their infrastructure messaging. An OBU passing an RSU picks up the latest revocation set without needing backhaul. The CRL update latency at any given OBU is bounded by "time until next RSU encounter" rather than "time until next network connection".
// V2X revocation distribution — connectivity-tier view
┌─────────────────────────┐
│ CRL / CTL Publisher │
│ (signed by EA / TLM) │
└────────────┬────────────┘
│
┌────────────────────┼────────────────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌────────────────────┐
│ Always- │ │ Intermittent │ │ Offline OBU on │
│ connected: │ │ OBUs: │ │ PC5 sidelink only: │
│ pull on │ │ pull on │ │ pick up via RSU │
│ schedule │ │ connect │ │ broadcast on pass │
└──────────────┘ └──────────────┘ └────────────────────┘The credential lifecycle, end to end
Pulling the previous sections together, here is the operational lifecycle of a single device, from factory to retirement.
- Factory. Manufacturer attestation key injected into the secure element under HSM-backed key custody on the personalisation line.
- First boot in field. Device generates a verification key pair inside the SE; sends an EnrolmentRequest to the EA with the manufacturer attestation.
- Enrolment. EA verifies attestation, issues EC, returns it. Device installs EC inside SE.
- First AA request. Device generates caterpillar key, requests a PC batch from AA. AA returns N PCs derived via Butterfly Key Expansion.
- Operational rotation. Device cycles through PCs, signing CAMs / DENMs / other V2X messages under the active PC. Refresh PCs from AA when batch is exhausted.
- CRL ingestion. Device picks up CRL updates from any connectivity channel available (always-connected pull, intermittent pull, or RSU broadcast on PC5).
- Re-enrolment. Before EC expires, device authenticates with the current EC, receives a new one. No factory return.
- Compromise scenario. If the device is suspected compromised, the linkage authority publishes the device’s linkage seed; all PCs issued under it are rejected across the network. The EC itself is added to the CRL.
- Decommission. SE is zeroised, EC is permanently revoked at the EA. The hardware is destroyed; identity does not migrate.
What this implies for the hardware
Every component of this architecture rests on the assumption that the device’s key material lives in a tamper-resistant secure element. The architecture could be expressed against software keys, but the threat model it was designed against assumes hardware binding. Three specific hardware requirements fall directly out of the architecture:
- ECDSA-P256 (and increasingly P-384) acceleration in hardware. A 10 Hz CAM cadence is 10 ECDSA signatures per second per vehicle, sustained, at automotive temperature ranges. Software-only ECDSA on a host MCU is too slow and too exposed. The signing hardware lives inside the secure element, where the private key never leaves.
- Per-device unique identity injection at factory. The EA-side enrolment depends on a manufacturer attestation that ties the device to a specific piece of certified silicon. This means the factory has to inject the attestation key into the SE under controlled conditions — an HSM-backed personalisation line with SCP03-equivalent wrapping. Device identity at scale covers the manufacturing-time provisioning architecture in depth.
- Applet-side PC batch management. An OBU holding 100–1000 PCs at a time needs SE-resident logic that tracks active PC index, schedules rotation, and re-derives PC private keys from the caterpillar key. A custom JavaCard applet is the typical way to ship this; the silicon is the IoT Security Co-Processor class.
India context: TRAI CP 30/04/2026
The Telecom Regulatory Authority of India released a Consultation Paper dated 30 April 2026 covering the security framework for V2X / ITS deployments in India. The paper is a public document; it is referenced here factually, not as an endorsement. Three architectural questions it raises are directly relevant to the PKI we have walked through.
- PKI governance. The CP proposes the Controller of Certifying Authorities (CCA) as the Root authority oversight body, with operational EA / AA functions delegated to designated entities. This parallels the existing X.509 trust hierarchy India already operates for digital signatures under RCAI, applied to a V2X-specific PKI.
- MTCTE for V2X cybersecurity. The Mandatory Testing and Certification of Telecom Equipment regime would extend to V2X devices; the question of whether MTCTE should mandate SE-backed key storage is one of the operative consultation questions. Section 5 of this piece argues the answer follows directly from the threat model the architecture was designed for.
- Convergence with eSIM lifecycle. SGP.32 IoT eSIM deployments and V2X PKI deployments share device populations (connected vehicles, fleet trackers) and architectural patterns (unattended credential lifecycle managed remotely). A coherent national approach treats them together. See device identity at manufacturing scale for the convergence detail.
Where AmbiSecure fits in this architecture
An explicit boundary. AmbiSecure provides the hardware-rooted identity primitives that an OBU / RSU / fleet integrator builds against. AmbiSecure does not:
- operate a V2X Root CA, EA, or AA;
- ship turnkey OBU or RSU products;
- claim ISO 26262 or ASPICE certification of the integrated AmbiSEC Module — that certification is a target, not a present claim;
- disclose specific city deployments or named customers on the public site.
What AmbiSecure does ship:
- IoT Security Co-Processor (AmbiSEC Module) — the secure-element silicon class that satisfies the hardware-binding, sustained-ECDSA-throughput, and key-isolation requirements of section 7. The underlying secure-element silicon carries CC EAL5+ certification at the chip level.
- JavaCard applet engineering — custom applets for V2X EC / PC management, attestation flows, applet-side revocation enforcement.
- HSM-backed personalisation lines — the manufacturing-time provisioning infrastructure that makes the EA-side enrolment defensible.
For the architectural unification across V2X, eSIM, FIDO, and IoT credential lifecycles, see device identity at scale. For the V2X-specific solution view, see V2X security architecture and the V2X PKI technology page.
Related reading
- Pseudonymous certificates and privacy in V2X — deeper treatment of the privacy property, unlinkability, and revocation challenges.
- Secure elements in connected vehicles — the hardware-binding case in detail.
- Device identity at manufacturing scale — the factory side of the lifecycle and the eSIM / V2X convergence.
- Why software-only device trust fails — the threat model that drives hardware-rooted V2X identity.
- IEEE 1609.2 certificate reference · ETSI TS 102 941 reference · ETSI TS 103 097 reference.
- V2X certificate parser tool · V2X certificate chain validator tool.