Field infrastructure footprint analysis

2.4.6.Bootstrap and Device Certification

The current Security Credential Management System (SCMS) includes a variety of inconsistencies and known issues. For example:

1. 
   There is uncertainty about the scope of pseudonym certificates. One interpretation of the security standard is that certificates are associated with only a single application. However, if this is the case, then each vehicle will be required to support a full set of certificates for each application that requires pseudonym certificates (there are currently five such applications identified in the SAE Message sets). This approach will result in much larger revocation lists and substantially more SCMS activity that currently envisioned. The alternate interpretation is that each pseudonym certificate will include permissions for all applications installed in the vehicle that require anonymity. While this is a simple approach in concept, and it substantially reduces the number of certificates and the size of the revocation list, it carries the added burden that the vehicle system must be re-certified when new software is installed. While this is useful from a platform assurance perspective (See Gap 15), the details of such application related certification have not been worked out.
   
2. 
   Related to the above issue, the Safety Pilot SCMS bootstrap process did not include methods to limit the capabilities for certificates requested from devices authorized using a specific bootstrap ID. For the Safety Pilot, a valid bootstrap ID authorized a device to request any certificates that the SCMS was configured to produce.
   
3. 
   The Safety Pilot bootstrap ID process was an ad hoc approach meant to overcome a security weakness exposed by the fact that the bootstrap process would not occur via a secure connection to the SCMS. The implications of requiring a secure hardwired interface for bootstrap processing have not been addressed.
   
4. 
   The standards that define connected vehicle messages use PSIDs to restrict the messages that can be authorized with a certificate. However, there is no specific process for associating PSIDs with operations and connected vehicle messages – this is a gap related to connected vehicle security management rather than the certificate management system in particular. There are similar gaps that are related directly to the certificate management system.
   
5. 
   The SCMS does not include any specific features for managing information about PSIDs. For example, the SCMS does not include a list of valid PSIDs, so cannot verify that the PSIDs in a bootstrap or certificate request are valid. The SCMS does not include features for implementing device-specific restrictions based on PSIDs (as suggested previously).
   
6. 
   The number of certificates installed each vehicle and the period of update for these certificates as defined in the current (and rapidly evolving) security design is such that moderate levels of revocation (resulting from moderate levels of misbehavior, faults, and attacks) will produce a significantly large revocation list (50MB to 150 MB). This large list may require excessive data storage, and processing in the vehicles, and itself may present a viable denial of service attack surface (create enough revocations that the system collapses because the CRL is too large).
   

There appear to be multiple parties involved in the security system design and the design appears to be in flux as the system is changed to address newly identified issues. It is unclear if this approach is convergent. As noted above, some changes are taken to address issues and these changes invalidate basic system assumptions, or create additional vulnerabilities.

Gap : Misbehavior Reporting and Detection Processes Are Not Sufficiently Defined, and May Not Be Effective

The current implementation of the certificate management system does not include any capabilities related to misbehavior identification other than support methods that allow devices to submit messages to the SCMS for misbehavior report processing. These methods support submission of casual reports (i.e., samples of messages) and suspicious messages. However, the SCMS does not include specific processes for acting on these reports, such as:

• 
  Processes for reviewing casual reports to identify suspicious behavior.
  
• 
  Processes for reviewing reports of suspicious behavior and determining whether the suspicious behavior (identified by the SCMS from casual reports or from device reports of suspicious messages) warrants revocation of certificates.