Authentication without identification.
A vehicle broadcasting its position, speed and heading ten times a second, signed with a stable certificate, is a tracking beacon that works at 800 metres and never runs out of battery. The entire pseudonymity apparatus exists to make that broadcast trustworthy and untrackable at the same time — and it is one of the more elegant pieces of applied cryptography in deployment anywhere.
The C2C-CC Basic System Profile — the numbers European OEMs build to.
| Requirement | Parameter | Value |
|---|---|---|
| RS_BSP_403 | Maximum pseudonyms per interval | 20 |
| RS_BSP_402 | Authorisation ticket validity | ≤ one week plus an overlapping period |
| RS_BSP_410 | Pseudonym change during a trip | Random interval between 10 and 30 minutes |
| RS_BSP_177 | Change at every ignition-on | Unless restarting within 10 minutes |
| RS_BSP_409 | Change completed within | 1 minute |
| RS_BSP_178 | Maximum preloading | 3 years |
| RS_BSP_170 | Mandatory signature algorithm for sending | ECDSA-256 on NIST P-256 |
The US SCMS profile is comparable: one-week certificate validity, at least 20 simultaneously valid certificates per period, and one to three years of preloaded coverage — which works out to 1,040 to 3,120 certificates per device. The Registration Authority delivers a week's worth per batch and the device controls download timing.
A change of certificate alone is not a change of identity. ETSI TS 102 940 is explicit: all identifiers across all layers must change synchronously, coordinated through an ID Change Notification service, because a rotated certificate under a stable MAC address or a stable GeoNetworking address is trivially re-linkable. The specification also defines Lock and Unlock services so that an application in the middle of a manoeuvre can prevent a change that would break it — and, equally importantly, prevent a partial change that would be correlatable.
How an authority issues a thousand certificates in response to one request, without learning who asked.
The mechanism, from the SCMS reference design.
The device generates a caterpillar key pair (a, A = aG) and sends only the public half.
The Registration Authority expands it into a series of cocoon keys using a deterministic expansion function:
B_ι = A + f_k(ι)·G (cocoon public key — the RA can compute this)
b_ι = a + f_k(ι) (cocoon private key — only the device can compute this)where the expansion function is built from AES in Davies-Meyer mode:
f_k(ι) = f_int_k(ι) mod ℓ
f_int_k(ι) = DM_k(x+1) ‖ DM_k(x+2) ‖ DM_k(x+3)
DM_k(m) = AES_k(m) ⊕ m
x = 0³ ‖ 2i ‖ j ‖ 0³²The Pseudonym CA then adds its own secret randomiser c_ι, so the certified public key is B_ι + C_ι and the device reconstructs b'_ι = b_ι + c_ι.
The security property, stated plainly: the RA knows who is asking but cannot compute the final key, because it does not know the PCA's randomiser. The PCA knows the key but not who asked, because the RA shuffles requests. Two independent components must collude to track a vehicle. The construction is secure on the assumption that the elliptic curve discrete logarithm problem is hard.
The original SCMS design uses two independent caterpillar keys, one for signing and one for encryption. The Unified Butterfly Key construction collapses these into a single seed serving both roles, reducing provisioning bandwidth and computation. No specific percentage saving is quoted here; the source paper could not be retrieved.
One CRL entry that revokes an unbounded number of future pseudonyms — without breaking past privacy.
Two independent Linkage Authorities each run a forward-secure hash chain.
ls_x(0) = random 128-bit seed
ls_x(i) = H₁₆( la_id_x ‖ ls_x(i−1) )
plv_x(i,j) = [ E(ls_x(i), la_id_x ‖ j) ⊕ (la_id_x ‖ j) ]₉The Pseudonym CA XORs the two pre-linkage values to produce the nine-octet, 72-bit linkage value embedded in the certificate:
lv(i,j) = plv₁(i,j) ⊕ plv₂(i,j)To revoke, the Misbehaviour Authority publishes the two linkage seeds for period i on the CRL. Every receiver runs both chains forward from that point, derives every future pre-linkage value, XORs them, and obtains every linkage value that device will ever present from period i onward.
Backward privacy survives. Certificates issued before period i remain unlinkable, because a hash chain cannot be run backwards. That is the trick, and it is why linkage values are a genuinely good idea rather than merely a clever one.
At scale: with 250 million vehicles and 40 certificates per week, 72-bit linkage values produce roughly one collision every 64 linkage periods — about one collision system-wide per year. How revocation is actually distributed →
Things that break pseudonymity even when the certificates are rotating correctly.
- Cross-layer identifier persistence — a stable MAC address, GeoNetworking address or station ID under a rotating certificate. Addressed by synchronised ID change.
- Rotation in an empty field — changing pseudonym when no other vehicle is in range links the old and new identities trivially. Mitigation is silent periods and mix-zone strategies; deployment practice is mixed.
- Kinematic linkage — a vehicle's trajectory is continuous across a pseudonym change. Position, speed and heading before and after the change are trivially matchable by anyone recording the channel. This is the hardest unsolved problem in V2X privacy and no deployed profile fully addresses it.
- Correlation with an external identifier — a toll transaction, a charging session, or any other event recorded at the same time and place. This is a system-design and data-governance problem rather than a cryptographic one; no amount of pseudonymity in the radio layer helps if a separate system records the same vehicle at the same moment.
Where this fits.
V2X PKI
The EA/AA split these constructions enforce, and the ETSI exchange in detail.
Misbehaviour detection
Who publishes the linkage seeds, and under what process.
SCMS vs CCMS
Why Europe zeroes the linkage fields and relies on short ticket validity instead.
Pseudonymous certificates and privacy
The AmbiSecure engineering blog on the same construction.
How V2X works
The same privacy property, explained without any mathematics.
Threats and attacks
Sybil attacks, and why the pseudonym pool is bounded at twenty.
Questions this page answers.
Can a V2X message be traced back to a specific vehicle?
Not from the message alone, and not by any single party in a correctly implemented system. The Enrolment Authority knows the device but never sees a message; the Authorisation Authority signs the message-signing certificates but never learns which device requested them; and the mathematical construction of butterfly keys means neither can unilaterally link the two. Unmasking requires collusion between independent authorities, which is exactly why the standards separate them and why a national deployment should place the Misbehaviour Authority in a separate organisation under a defined legal process.
How often does a vehicle change its certificate?
In the European profile, at a random interval between 10 and 30 minutes during a trip, plus at every ignition-on unless the vehicle restarts within 10 minutes. Certificate validity is typically one week with about 20 valid at any time.
How many certificates does a vehicle need?
Between roughly 1,000 and 3,000 for one to three years of preloaded coverage, at 20 valid per week. Butterfly key expansion is what makes issuing that many practical from a single small request.
Does V2X track drivers?
The design intent is explicitly the opposite, and the architecture is built to make tracking require collusion. Whether a given national deployment preserves that property depends on choices no standard can enforce: whether the authorities are genuinely independent, whether any persistent identifier such as a VIN or SIM identity leaks into a broadcast message, whether rotation cadence is enforced by the device or merely recommended, and whether unmasking requires a legal process or is available as an operational convenience.