The National Highway Traffic Safety Administration and the Department of Transportation have issued a Notice of Proposed Rulemaking for autonomous and connected cars. The NPRM “proposes to establish a new Federal Motor Vehicle Safety Standard” under 40 CFR 571 to mandate vehicle-to-vehicle (V2V) communications for new light vehicles and to standardize the message and format of V2V transmissions. The V2V communications focus heavily on the use of “short-range radio communications (DSRC)” devices to transmit “Basic Safety Messages (BSM)” about a vehicle’s speed, heading, brake status, and other vehicle information to surrounding vehicles, and receiving the same information from them.” The NHTSA claims that without such a protocol, the auto industry itself will be unable to move forward together meaningfully.
The NPRM is critical for the cybersecurity industry and all those who intend to enter into connected cars as it describes a proposal for a new paradigm of data communications that will have important and persistent privacy implications. First, the proposal is for vehicles to deploy “omnidirectional radio signals that provide 360 degree coverage along with the ability to ‘see’ around corners and ‘see’ through other vehicles,” supplemented by information from other nearby vehicles. Vehicles would communicate parameters such as speed, heading, trajectory, and other information, under the BSM protocol proposed – all of which is relatively weather-proof due to the nature of DSRC. Second, using DSRC allows the industry to leverage off of existing technologies, thus allowing for earlier and more widespread deployment than other proposals. The NHTSA and DOT hope that the use of more readily-adaptable technologies such as DSRC will allow for wider and quicker industry support and adoption of their proposal, in turn helping to save lives and ensure public safety.
There are a number of critical proposals of which privacy professionals need to take note:
- The NHTSA “proposes to exclude from V2V transmitting information that directly identifies a specific vehicle or individual regularly associated with a vehicle, such as owner’s or driver’s name, address, or vehicle identifying numbers, as well as data ‘reasonably linkable’ to an individual,” citing to the Federal Trade Commission.
- The “NHTSA proposes [that] V2V devices sign and verify their basic safety messages using a Public Key Infrastructure digital signature algorithm … for BSM transmission and the signing of BSMs.”
- The “NHTSA proposes to mandate requirements that would establish procedures for communicating with a Security Credential Management System to report misbehavior; and learn of misbehavior by other participants.”
- The “NHTSA proposes that V2V equipment be ‘hardened’ against intrusion (FIPS-140 Level 3) by entities attempting to steal its security credentials.”
- “V2V systems would be required to be designed from the outset to minimize risks to consumer privacy.” The publication also imposes a number of other requirements on manufacturers.
In addition to the peer-to-peer BSM communications, the NHTSA is requesting comments for two innovative proposals for V2V device credentialing, both of which would complement the use of PKI. The first approach is the Federated Security Credential Management model, which envisions a system “established, funded, and governed primarily by one or more private entities – possibly a consortium of automobiles and V2V device manufacturers.” It would include the following functions in the issuance, management, and revocation of short-term certificates for vehicle transmissions: (1) SCMS managers; (2) registration authorities (RAs); (3) root certificate authorities (Root CAs); (4) intermediate certificate authorities (Intermediate CAs); (5) pseudonym certificate authorities (PCAs); (6) linkage authorities (LAs); (7) misbehavior authorities (MAs); (8) location obscurer proxies (LOPs); and (9) request coordination. Each of these functions are envisioned to be part of a system wherein certificate management entities (CMEs) would manage short-term certificates for participating vehicles, with both centralized CMEs and federated CMEs.
As the NHTSA’s figure above shows, few CMEs should handle central functions, whereas many CMEs can compete and handle non-central functions. The CMEs with central functions would likely need to work with the NHTSA and be subject to future rulemaking. Notably, by dividing identifying information among different CMEs – centralized and federated – the hope is that safety is achieved with little compromise of security and personally identifiable information. The NHTSA compares its proposed paradigm to that of the multi-stakeholder Internet Corporation for Assigned Names and Numbers (“ICANN”).
As an alternative to SCMS, which has single security certification roots, the NHTSA is also considering a Vehicle Based Security System (“VBSS”). The major difference is in the “generation of short-term certificates.” The NPRM states, “The SCMS approach relies on individual vehicles to periodically request pseudonym certificates from infrastructure-based entities (most notably a Pseudonym Certificate Authority, or PCA) which in turn generates and signs short-term certificates. Vehicles then download batches of certificates which are used to digitally sign BSM messages. In contrast, the VBSS concept calls for delegating this authority to individual vehicles, and as a result the communications with the infrastructure are reduced.”
A number of functions required under SCMS are thereby eliminated, and the whole process is simplified. Instead, “VBBS establishes a Group Manager/Group Managers (GM) to provide credentials that make it possible for each vehicle to act as a [subordinate] certificate authority – an entity that can generate short-term certificates. … All member signing keys for a particular group are associated with a single group certificate.” The NHTSA indicated that the VBBS is further behind SCMS currently because “while Group-based signature schemes are an active area of research they are evolving and much less mature than other cryptography systems.”
 49 CFR 571, p. 232-237.