V2X / ITS · ETSI TS 102 941

ETSI TS 102 941 Trust & Privacy Management

The architectural specification that defines the V2X PKI hierarchy: Root CA, Enrolment Authority, Authorisation Authority, the EC and PC issuance flows, the CRL and CTL distribution model, and the privacy-preserving certificate split that lets a verifier authenticate a message without identifying its sender.

Scope & status

What 102 941 defines

The trust model and the operational PKI architecture for ETSI ITS. Designates the entities (Root CA, Trust List Manager, EA, AA), the protocols between them and the ITS-S (Initial Enrolment, Authorisation Request, Authorisation Validation), and the credential-distribution mechanisms (CRL, CTL).

What 102 941 does NOT define

It does not define the certificate format (1609.2 / 103 097), the on-wire signed-message format (103 097), or the ITS station security services (ISO 21177). 102 941 is the operational layer above the cryptographic primitives.

Privacy property

The central design property: no single authority in the PKI can link a signed V2X message back to a specific vehicle. The EA knows the device identity but never sees signed messages. The AA signs PCs but cannot link a PC back to a specific EC, even with full record-keeping. Architectural rather than legal.

PKI hierarchy

Root CA

Top-of-trust. Signs the certificates of Enrolment Authorities and Authorisation Authorities. Operated by the regulator-designated authority (CCA in India's proposed framework; the CAR2CAR Communication Consortium's CPOC in the European framework).

Trust List Manager (TLM)

Maintains and distributes the Certificate Trust List (CTL) — the authoritative list of trusted Root CAs and their public keys. ITS stations bootstrap their trust anchor set from the CTL.

Enrolment Authority (EA)

Verifies hardware-backed device identity at enrolment, issues long-lived Enrolment Credentials. One per regional or fleet jurisdiction. Sees device identity exactly once.

Authorisation Authority (AA)

Issues short-lived Pseudonymous Certificates in batches. Receives requests signed under EC; does not see which EC. Multiple AAs per region for load distribution and isolation.

ITS Station (ITS-S)

The vehicle or roadside unit. Holds the EC inside its secure element; rotates through PC batches issued by AAs; signs V2X messages with the currently-active PC.

Manufacturer

Out-of-band trust anchor. Injects a manufacturer attestation key at factory; the EA validates this attestation before issuing the EC. The manufacturer is NOT part of the operational PKI — it is the bootstrap authority.

Issuance flows

Initial Enrolment Request

ITS-S → EA. The device proves possession of a manufacturer-attested key (the hardware identity injected at factory), requests an EC. EA validates the attestation against the manufacturer certificate chain, issues the EC. One-time-per-device flow.

Authorisation Request

ITS-S → AA. The device proves possession of an EC (without disclosing it directly — via an EA-validated token or via Butterfly Key Expansion seeds). Requests a batch of PCs. AA issues the PCs without learning which EC requested them.

Authorisation Validation

AA → EA (optional flow). The AA may ask the EA to confirm an EC is still valid (not revoked) before issuing a PC batch. EA returns yes/no without disclosing the EC bytes back to the AA. Preserves the partition.

Re-enrolment

Periodic refresh of the EC before expiry. The device authenticates with its existing EC (which is still valid) and receives a new one. No return to manufacturer-attestation step unless the silicon is replaced.

Butterfly Key Expansion

The mechanism that lets an AA issue a large batch of PCs from a single device-supplied seed without learning the per-PC private keys. This is what makes the EA / AA split actually privacy-preserving in practice rather than only in theory.

Seed material

The ITS-S generates a caterpillar key pair plus an expansion function and sends the public caterpillar key + a seed to the AA. The AA cannot derive any private key from what it receives.

Public-key derivation

The AA computes a sequence of public keys from the caterpillar public key using the seed and the expansion function. Each derived public key is the verification key for one PC in the batch.

Cocoon keys

The AA signs each derived public key into a PC and returns the batch. The ITS-S, holding the private caterpillar key + the seed, can re-derive each corresponding private key locally inside the secure element.

Unlinkability

From the AA's view, every PC in the batch is independent — the AA cannot link them to the same requester after issuance. From an outside observer's view, each PC has an unrelated public key. Vehicles can rotate through the batch without exposing their identity.

Revocation: CRL & CTL

Certificate Revocation List (CRL)

Lists revoked certificates by their identifiers (HashedId8 for ECs; linkage values for PCs). Distributed by the issuing authority. RSUs cache and rebroadcast CRLs for offline OBUs.

Linkage-based PC revocation

PCs carry linkageData derived from a linkage seed held only by the AA's revocation function. To revoke all PCs of a compromised device, the AA publishes the seed; verifiers compute the linkage values, reject any matching PC. No need to list every PC individually.

Certificate Trust List (CTL)

List of currently trusted Root CAs and authorities. Signed by the TLM. ITS-S fetches CTL updates on a defined cadence to ensure its trust anchor set is current. Distinct from CRL: CTL is "who is trusted", CRL is "what is revoked".

RSU broadcast distribution

The architectural mechanism for offline OBUs. RSUs broadcast CRL deltas and CTL updates as part of their infrastructure messaging. An OBU passing an RSU receives the current revocation set without needing backhaul.

Implementation implications

EC storage

The EC is the device's high-value long-lived credential. Must live in the secure element with key isolation. Extraction = device compromise.

PC batch size

Trade-off: larger batches reduce AA round-trips but increase the consequence of a stolen batch. Production deployments target batches sized to a week or month of operation.

PC rotation cadence

Profile-dependent. Sub-10-minute rotation limits the linkability window of any single PC. The SE manages the rotation autonomously based on a clock + counter.

CRL caching

The verifier maintains a CRL cache local to the OBU. CRL distribution latency is part of the threat model — a revoked PC may continue verifying until the CRL update propagates.

Companion AmbiSecure pages

Hardware

IoT Security Co-Processor — secure-element silicon for EC storage and PC rotation.

External references

Standards bodies

ETSI Technical Committee ITS · ETSI TS 102 941 (current edition + amendments) · ETSI TS 102 940 (architecture overview) · ETSI TS 102 942 (access control)

Disclaimer

This page is a structural reference summary derived from the public ETSI TS 102 941 framework. For implementation conformance, consult the published ETSI standard directly.