Four trust models, and what India should take from each.
The cryptography is the same everywhere. The governance is not, and governance is what determines whether a national V2X deployment can be surveilled, whether one compromised root can ground a fleet, and whether Indian vehicles will ever be recognised abroad.
Unlinkability enforced by construction, not by policy.
| Entity | Role |
|---|---|
| Root CA | Offline, elector-managed trust anchor. Electors are independent entities validating SCMS Manager decisions — a distinctly North American construct with no European equivalent. |
| ICA | Intermediate CA, signs the operational authorities |
| ECA | Enrolment CA — issues the long-lived enrolment certificate after verifying the device's canonical key |
| RA | Registration Authority — authenticates the EC, checks PSID and permission policy, shuffles requests, returns batches |
| PCA / ACA | Pseudonym CA — issues short-lived pseudonym certificates, seeing shuffled cocoon keys rather than device identities |
| MA | Misbehaviour Authority — investigates reports, publishes the CRL |
| LA1, LA2 | Linkage Authorities — two, independent, running the forward-secure hash chains |
| LOP | Location Obscurer Proxy — strips network location from requests |
Standards: IEEE 1609.2 (certificate and secured-message format), IEEE 1609.2.1 (certificate management, elector-based root management), SAE J2735 and J3161/1, with device qualification through OmniAir certification. Multiple commercial SCMS operators run in parallel under a common policy; the trust model assumed more than one operator from the start.
Refresh: butterfly key expansion with RA shuffling; roughly 20 pseudonym certificates valid per week, with the week index fixed in policy and the active certificate rotating during the drive. Batches are pre-fetched ahead of expiry over cellular or a roadside unit, so an offline week is survivable. RSUs and other identified equipment take application certificates instead of pseudonymous ones, so their refresh is a conventional renewal cycle.
Trust is a list, not a single root.
| Entity | Role |
|---|---|
| CPA | Certificate Policy Authority — approves root CAs, owns the policy |
| TLM | Trust List Manager — a single entity appointed by the CPA; compiles and signs the ECTL |
| CPOC | C-ITS Point of Contact — operated by the JRC; receives root CA submissions, publishes the ECTL |
| Root CAs | Many, per member state, OEM or operator, all listed in the ECTL |
| EA | Registers ITS stations for an authorised subscriber, issues the Enrolment Credential |
| AA | Issues Authorisation Tickets, validating the EC with the EA without learning message traffic |
| ITS stations | Vehicle and roadside stations are both end entities under the same trust model, with different permissions |
Standards: ETSI TS 102 941, TS 103 097, TS 102 940 / 942 / 943, plus the EU C-ITS Certificate Policy, Release 3.0 (May 2024) and the CPOC Protocol Release 1.1. ISO 21177:2023 covers session-layer security — mutual authentication and the EC-versus-AT distinction at session level — complemented by RFC 8902, which lets IEEE 1609.2 and TS 103 097 certificates authenticate a TLS 1.3 handshake, so a station can bring its authorisation ticket into a unicast session rather than maintaining a parallel X.509 identity.
The key property: trust is a list, not a single root. The Certificate Policy deliberately fixes no number of root CAs, and no current enrolled-root count is published here — the CPOC ECTL page renders dynamically and returned no usable data.
Refresh: the station requests authorisation tickets from the AA over an authenticated channel and holds a local pool, so a PC5-only stretch of road never blocks signing. Ticket validity is short — typically about a week — with one active at a time and periodic change during a journey. The enrolment credential is long-lived and re-keyed before expiry, with the station signing the re-key request using the credential it still holds. The EU regulatory picture →
YD/T 3957-2021, and a trusted root certificate list.
YD/T 3957-2021, developed with CAICT, defines China's C-V2X credential management. The architecture is distinct from both: a Trusted Root Certificate List Authority maintains a Trusted Root Certificate List across multiple authorised root CAs, plus Trusted Domain CA Certificate Lists.
It is widely described as centralised and state-supervised, and as using Chinese national cryptographic algorithms — SM2, SM3, SM4. That cryptographic detail is asserted in TRAI's consultation paper rather than confirmed from the standard's own text, and is attributed accordingly. China's V2X programme →
The two mature models, function by function.
| Function | United States · SCMS | European Union · CCMS |
|---|---|---|
| Standards anchor | IEEE 1609.2, 1609.2.1, SAE J2735 / J3161 | ETSI TS 102 941, 103 097, 102 940 |
| Top of trust | Root CA with elector-based root management | CPA approves roots, TLM signs the ECTL, CPOC publishes |
| Long-term identity | Enrolment Certificate from the ECA | Enrolment Credential from the EA |
| Operational credential | Pseudonym Certificate from the PCA/ACA, via the RA | Authorisation Ticket from the AA |
| Batch issuance | Butterfly key expansion plus RA shuffling; ~20 valid per week | Pre-loaded AT pools; butterfly expansion also specified |
| Revocation | Misbehaviour Authority → CRL with linkage seeds; EC blacklisted at the RA | Short AT validity plus EA refusal to reissue; CA-level CRL and ECTL updates |
| Hardware requirement | Tamper-resistant secure element, keys non-extractable | Tamper-resistant secure element, keys non-extractable |
Both converge on the same device-side requirement — a non-extractable key in certified silicon. That layer is regime-agnostic. It is the layer AmbiSEC supplies.
Adopt the EU governance pattern, with Indian policy parameters and Indian key custody.
An engineering view, offered on its own terms. Nothing here implies endorsement by, or a relationship with, any authority.
- Policy authority — a National C-ITS Certificate Policy Authority: MoRTH for ITS policy, with DoT and MeitY/CCA represented.
- Trust List Manager — a single national TLM publishing a signed Indian Certificate Trust List, technically operated by a designated body of C-DOT or C-DAC class.
- Multiple approved Root CAs, audited against one published Certificate Policy — national road authority, state ITS programmes, OEM groups, licensed telcos. Cross-recognition through the trust list, not bilateral deals.
- EA — subscriber-accountable registration of on-board and roadside units, with hardware attestation mandatory.
- AA — pseudonymous credential issuance, blind to enrolment identity by construction.
- A separate Misbehaviour Authority, with unmasking permitted only under a defined legal process.
Why this shape. It avoids a single point of surveillance — whoever runs a monolithic root can correlate every vehicle. It avoids a single point of failure — one compromised root should not ground the national fleet. It matches how India already regulates PKI, since a policy authority licensing and auditing multiple CAs is exactly the CCA model. And it keeps interoperability open, because a trust-list model lets Indian OEMs be recognised abroad later without re-architecting.
Six parameters that decide the outcome:
- Hardware floor. Certified tamper-resistant secure element mandated for every on-board and roadside unit. MTCTE and TEC cybersecurity testing should treat key non-extractability as pass or fail.
- Key custody. HSM-backed personalisation on Indian lines, PKI data residency, audited Certification Practice Statement per operator, no foreign custody of enrolment key material.
- Privacy. No persistent identifier — VIN, registration number, IMEI or SIM identity — in any broadcast message. Rotation cadence set in policy and enforced by the applet, not by host software.
- Offline path. Roadside units broadcast CRL and trust-list deltas in normal beacon traffic; credential pools sized for multi-day offline operation.
- Test capacity. Accredited laboratory capability for V2X radio, protocol and security conformance has to exist before a fitment deadline, not after it. It is a longer lead item than the hardware, and today there is no accredited V2X test laboratory in India.
- Phasing. Copy the EU's staged trust domains: a test domain, a pilot domain on two or three instrumented corridors, then production — with certificates never crossing levels.
Where this fits.
V2X PKI
The certificate formats and protocol flows underneath all four models.
India regulation
The X.509-versus-1609.2 problem, and the six open questions.
US regulation
Why no federal SCMS governance rule has been adopted.
EU regulation
The Certificate Policy and the ECTL in their legal context.
Misbehaviour detection
What each model does when a device is found to be lying.
PKI test environments
Where to exercise an SCMS or CCMS round trip in development.
Questions this page answers.
What is SCMS?
The Security Credential Management System — the North American V2X trust architecture, built around an elector-managed root, an enrolment CA, a registration authority that shuffles requests, a pseudonym CA, two independent linkage authorities and a misbehaviour authority. Its distinguishing feature is that unlinkability is enforced by construction: no single component can connect a certificate to a device.
What is the difference between SCMS and CCMS?
SCMS is North American and built on IEEE 1609.2 and 1609.2.1; CCMS is European and built on ETSI TS 102 941 and TS 103 097. The deeper difference is governance. SCMS uses elector-based root management and linkage-value revocation; CCMS uses a Certificate Policy Authority, a Trust List Manager signing a European Certificate Trust List, and relies on short authorisation-ticket lifetimes rather than large-scale revocation. Both require the same thing of the device: a non-extractable key in tamper-resistant hardware.
Are V2X certificates interoperable between regions?
Not today. There are four broadly incompatible trust regimes — the US SCMS, the EU CCMS, China's model under YD/T 3957-2021, and whatever India adopts. A vehicle enrolled in one is not trusted in another. Cross-recognition is technically feasible through trust-list mechanisms and is one of the strongest arguments for a country adopting a list-based model rather than a single national root.
What is the ECTL?
The European Certificate Trust List — the signed list of approved root certificate authorities, compiled by the Trust List Manager and published by the C-ITS Point of Contact. It is the mechanism that makes multi-root trust work offline: a receiver accepts a certificate because its chain terminates at a root on a list it already holds locally.