SCMS CV Pilots Documentation : Elector-based Root Management

After a root CA certificate's validity period ends or a revocation was necessary and a new root CA certificate has been established for replacement, how can an EE start trusting this new root CA certificate? The trust in an initial root CA certificate is implicit, as it is installed in a secure environment with out-of-band communication during bootstrapping of the device. One option would be to get the device back to that secure environment and use out-of-band communication to install the new root CA certificate. However, this is suboptimal due to the required effort and will render the overall V2X system partly out-of-order until all devices have installed the new certificate.

To manage the root CA certificate over time and gain resilience against compromises on any level, the SCMS needs the ability to heal itself, which means to bring itself into a state where it can endure another single compromise or end of the validity period of a Root CA. This recovery should occur while keeping the devices operational whenever possible, that is, capable of sending, receiving and validating BSMs, and be able to restore the system hierarchy without requiring physical access to devices. Elector-based Root Management is the solution that provides those means by installing a distributed management schema on top of the SCMS Root CAs.

Distributed Management & Electors

A distributed management scheme, like a democracy, contains within itself the power to replace an established hierarchy and does not succumb to a single failure. The concept of Electors, which together have the power to change and manage the trust relationships of the system, adds such a scheme to the SCMS design. Within a system like the SCMS, the number of electors should be 2n+1, where n is the number of simultaneous elector expiration/compromises that the SCMS can tolerate.

Like in a democracy the Elector-based Root Management introduces a Ballot with Endorsements. The electors cast Votes by signing an endorsement of a given root CA or elector certificate. A ballot aggregates all these endorsements. When a quorum of valid elector endorsements is on the ballot, any component in the system can trust the ballot.

The electors are not part of the PKI hierarchy, and therefore they can use a different crypto-system than the SCMS PKI. In fact, each of them can use a different one. This raises the probability that in case of a root CA or elector certificate compromise due to a broken cryptography, the system is still able to heal itself.

The resulting system may have multiple, self-signed root CA certificates, each of which operates at the top of their trust chain. Each root CA's certificate is endorsed by a ballot with at least a quorum of votes from non-revoked electors. Devices need to verify the trust chain up to a root CA certificate, at which point they must verify that a quorum of non-revoked electors has endorsed that root CA certificate.

Ballots & Endorsements

Electors operate by signing endorsements. A ballot can include the following basic types of endorsements:

• Add root CA certificate
• Add elector certificate
• Revoke root CA certificate
• Revoke elector certificate

Each ballot contains only one type of endorsement. SCMS components, including devices, receive ballots adding a certificate via a certificate chain file distributed by the PG. They receive ballots removing a certificate via the CRL distributed by the CRL store.

All components know the quorum and the certificates of the initial set of electors and therefore can validate the endorsements contained in the ballot. Once the ballot is validated, the component can follow the endorsed action to add or remove the ballot’s certificate from its trust store.

The SCMS Manager will coordinate the production of the ballot messages.

Structure of Ballots

The ballot which aggregates all independent elector endorsements is an ASN.1 structure. This structure contains the following elements:

1. The certificate of the root CA or elector to be endorsed
2. A sequence of endorsements, each containing:
   1. The type of endorsement
   2. The hash id of the certificate to be endorsed
   3. The generation time of the endorsement
   4. A signature of the elector.

Note that the validity period of a ballot is implicitly given by the validity period of the endorsed certificate.

Revocation/Endorsement Impact on Devices

A key consideration in the design of the root management system is to maintain secure operation of devices without requiring recall or manual re-enrollment of individual devices. The following table outlines the status of devices through the addition or revocation of Electors and Root CAs.

Effect of Voting Schemes on the GCCF

The Global Certificate Chain File (GCCF) contains all the trust chains needed by the SCMS (including EEs), including the Root CA certificates. With the elector model, the Root CA certificates are also accompanied with elector endorsements. The Root CA certificates in the GCCF will be supplied in the form of the "Add Root CA" ballots. The trust chain for certificates under a Root CA will be recorded in the GCCF as a list of IEEE 1609.2 certificates.

Structure of the Trust Hierarchy 

The diagram below shows how the SCMS-specific implementation of the elector-based scheme (shown in green) can be implemented in parallel with a standard PKI hierarchy, which supports all SCMS components and EEs. Note that all of the structures shown here can be implemented with standard IEEE 1609.2 certificates without modification. A significant advantage of the elector-based scheme is that, as new Electors are added at level 0, an existing root CA can receive new endorsements from an elector without having to change their certificates.