Vehicle-to-Vehicle Security Credential Management System; Request for Information, 61927-61936 [2014-24482]

Download as PDF tkelley on DSK3SPTVN1PROD with NOTICES Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices will be evaluated which may include alternatives outside of the corridor selected in the Tier 1 ROD. All alternatives evaluated will connect Section 5 of I–69 in Martinsville with I– 465 in Indianapolis. FOR FURTHER INFORMATION CONTACT: Michelle Allen, Planning and Environmental Specialist, Federal Highway Administration, Indiana Division, 575 N. Pennsylvania Avenue, Room 254, Indianapolis, Indiana 46204, Telephone (317) 226–7344 or Laura Hilden, Director of Environmental Services, Indiana Department of Transportation, 100 North Senate Avenue, Room N642, Indianapolis, Indiana 46204. SUPPLEMENTARY INFORMATION: The FHWA, in cooperation with the Indiana Department of Transportation (INDOT), began in 2004 to prepare a Tier 2 EIS on a proposal to build Section 6 of the Evansville-to-Indianapolis I–69 highway. Section 6 is located in Morgan, Johnson and Marion Counties, Indiana. The NOI for these activities was published in the Federal Register on April 29, 2004. The proposed action described in that NOI involved the construction of an interstate highway generally following State Route (SR) 37 from SR 39 south of Martinsville and proceeding north for approximately 25.9 miles to Interstate 465 in Indianapolis. I–69 (formerly known as Corridor 18) is a strategic, high priority highway serving the east-central United States. I– 69 is planned to be a continuous northsouth corridor linking Canada, the United States and Mexico. FHWA has identified 32 separate sections of independent utility (SIUs) for the national I–69 corridor. The Evansvilleto-Indianapolis section of I–69 has been designated by FHWA as SIU 3. The FHWA approved the ROD on the Tier 1 Final EIS for the I–69 SIU 3 on March 24, 2004. The purpose of the Tier 1 study was to resolve: (1) whether or not to complete I–69 in Southwestern Indiana; and if so, (2) the selection of a corridor for I–69 between Evansville and Indianapolis. The Tier 1 ROD identified six (6) Sections of Independent Utility that would be advanced to Tier 2 studies. Tier 2 NEPA studies have concluded in Sections 1, 2, 3, 4, and 5. Sections 1 through 3 (connecting Evansville, Oakland City, Washington, and Crane Naval Surface Warfare Center) are completed and open to traffic. Section 4 (connecting Crane Naval Surface Warfare Center and Bloomington) is under construction, and is expected to be open to traffic in 2015. Section 5 (connecting Bloomington and VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 Martinsville) is under construction and major construction activities associated with Section 5 are anticipated to be complete by the end of 2016. The 2004 NOI for Section 6 stated that alternatives generally will be located within the corridor approved in the Tier 1 ROD. However, the Tier 1 ROD permitted alternatives outside the selected corridor to be considered when necessary to avoid significant impacts within the corridor while still connecting the Tier 2 termini designated in the Tier 1 ROD. Due to the potential for increased impacts and/or changed conditions, the resumed Tier 2 studies in Section 6 may consider alternatives outside the selected Tier 1 corridor. All alternatives considered will connect Section 5 of I–69 in Martinsville with I– 465 in Indianapolis. Scoping coordination occurred with appropriate state and federal resource agencies at the outset of Tier 2 studies in Section 6. Opportunities also were afforded the public to participate in the scoping process. These scoping activities resulted in the identification of preliminary alternatives within the Section 6 corridor between Martinsville and Indianapolis. When Section 6 studies resume, these preliminary alternatives will remain under consideration for the study. With the resumption of Section 6 studies, the appropriate federal and state resource agencies will be included in additional scoping activities. These scoping activities will identify additional alternatives connecting Section 5 in Martinsville with I–465 in Indianapolis. These alternatives may be outside the Tier 1 corridor for much or most of their length. The public will also have opportunities to comment during this scoping process and other stages throughout the development of the proposed project. A date for a scoping meeting for regulatory agencies to address Section 6 will be established at a later date. A public scoping meeting for this Tier 2 section will also be scheduled at a later date. Interchange location and preliminary design, access to abutting properties, and location of grade separations with intersecting roads will be determined in this Tier 2 EIS. The range of alternatives appropriate for the Section 6 Tier 2 EIS will be determined in consultation with resource agencies. Consideration of the No Build alternative will be included as a baseline for analysis, in accordance with applicable regulations. To ensure that the full range of issues related to this proposed action is addressed and any significant impacts are identified, comments and PO 00000 Frm 00082 Fmt 4703 Sfmt 4703 61927 suggestions are invited from all interested parties. Comments or questions concerning this proposed action and this Tier 2 EIS should be directed to the FHWA or the INDOT at the address provided above. Catalog of Federal Domestic Assistance Program Number 20.205, Highway Planning and Construction. The regulations implementing Executive Order 12732 regarding intergovernmental consultation on Federal programs and activities apply to this program. Authority: 23 U.S.C. 315; 49 CFR 1.48. Issued on: October 7, 2014. Richard J. Marquis, Division Administrator, Federal Highway Administration, Indianapolis, Indiana. [FR Doc. 2014–24453 Filed 10–14–14; 8:45 am] BILLING CODE P DEPARTMENT OF TRANSPORTATION National Highway Traffic Safety Administration Vehicle-to-Vehicle Security Credential Management System; Request for Information National Highway Traffic Safety Administration (NHTSA), Department of Transportation (DOT). ACTION: Notice—Request for Information (RFI). AGENCY: On August 18, 2014, NHTSA announced an advance notice of proposed rulemaking (ANPRM) for V2V communications, and concurrently released an extensive research report on the technology, as the formal start to the regulatory process. This notice, a Request for Information (RFI), seeks information related to the security system that will support V2V operations but will not be established by NHTSA regulation. This RFI will help the agency: (1) Become aware of private entities that may have an interest in exploring the possibility of developing and/or operating components of a V2V Security Credential Management System (SCMS); (2) Receive responses to the questions posed about the establishment of an SCMS provided in the last section of this RFI; and (3) Obtain feedback, expressions of interest, and comments from all interested public, private, and academic entities on any aspect of the SCMS. The Background section of this RFI provides an overview of the technical and organizational aspects of the current V2V security design, of which the SCMS is an integral part. The SCMS encompasses all technical, SUMMARY: E:\FR\FM\15OCN1.SGM 15OCN1 61928 Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices tkelley on DSK3SPTVN1PROD with NOTICES organizational, and operational aspects of the V2V security system that is needed to support trusted, safe/secure V2V communications and to protect driver privacy appropriately. The primary managerial component of the envisioned SCMS (called the SCMS Manager) would be responsible for managing all other component entities (called Certificate Management Entities or CMEs) which support the different V2V security functions that, together, ensure the operational integrity of the total system. DATES: Responses to this RFI should be submitted by 11:59 p.m., E.T., on December 15, 2014. ADDRESSES: Responses: You may submit responses, identified by Docket No. NHTSA–2014–0023, by any of the following methods: Internet: To submit responses electronically, go to http:// www.regulations.gov and follow the online instructions for submitting comments. Alternatively, go to http:// www.safercar.gov/v2v/index.html and click the yellow button labeled ‘‘Submit responses on the SCMS Request for Information’’ to go directly to the docket in regulations.gov. Facsimile: Written responses may be faxed to 1–202–493–2251. Mail: Send responses to Docket Management Facility, U.S. Department of Transportation, 1200 New Jersey Avenue SE., West Building Ground Floor, Room W12–140, Washington, DC 20590. Hand Delivery: If you plan to submit written responses by hand or by courier, please do so at U.S. Department of Transportation, 1200 New Jersey Avenue SE., West Building Ground Floor, Room W12–140, Washington, DC between 9 a.m. and 5 p.m. E.T., Monday through Friday, except Federal holidays. You may call the Docket Management Facility at 1–800–647–5527. FOR FURTHER INFORMATION CONTACT: For questions about the program discussed herein, contact John Harding, NHTSA, Intelligent Technologies Research Division, 202–366–5665, john.harding@ dot.gov. For legal questions, interpretations and counsel, please contact Rebecca Yoon, Office of the Chief Counsel, 202–366–8909, rebecca.yoon@dot.gov, 1200 New Jersey Avenue SE., Washington, DC 20590. SUPPLEMENTARY INFORMATION: Table of Contents I. Purpose of This Notice II. RFI Guidelines III. Background on V2V and the Agency’s Actions Thus Far IV. Security Overview and Operational Characteristics VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 A. Technical Aspects B. V2V Security Design Concept: Functions, Components, Communications C. Pseudonym Functions/Certificates D. ‘‘Bootstrap’’/Initialization Functions/Enrollment Certificate E. Privacy Considerations F. Device Non-Compliance and Potential Recalls V. SCMS Organizational Options VI. The Legal Relationship Between NHTSA and the SCMS VII. Specific Questions for This Notice I. Purpose of This Notice NHTSA seeks responses from parties potentially interested in establishing and operating a V2V SCMS. Respondents can express interest, provide comments concerning the establishment of an SCMS, provide information concerning security approaches for a V2V environment, and discuss the technical and organizational aspects of the SCMS. While comments are welcome on any area of the RFI, NHTSA is particularly interested in responses related to interest in establishing an SCMS, including but not limited to some or all of the legally distinct CMEs that make up the SCMS, along with responses to the questions detailed in the Summary of Questions section of this RFI. II. RFI Guidelines Responses to this notice are not offers and cannot be accepted by the Government to form a binding contract or issue a grant. Information obtained as a result of this RFI may be used by the Government for program planning on a non-attribution basis. This RFI notice is NOT a solicitation for proposals, applications, proposal abstracts, or quotations. This RFI notice is not to be construed as a commitment on the part of the Government to award a contract or grant, nor does the Government intend to directly pay for any information or responses submitted as a result of this RFI notice. The Government prefers that submissions NOT include any information that might be considered proprietary or confidential. The Government intends to publicly release a summary of responses to this RFI. Such a summary may identify the number and types of respondents (e.g., public agency, private entity, or academic institution). If you wish to submit any information under a claim of confidentiality, you should submit three copies of your complete submission, including the information you claim to be confidential business information, to the Chief Counsel, NHTSA, at the PO 00000 Frm 00083 Fmt 4703 Sfmt 4703 address given above under FOR FURTHER In addition, you should submit two copies, from which you have deleted the claimed confidential business information, to Docket Management at the address given above under ADDRESSES. When you send a comment containing information claimed to be confidential business information, you should include a cover letter, as specified in our confidential business information regulation (49 CFR part 512.), that delineates that information. Responses should clearly identify the name(s) of the responding organization(s) or individual(s) and a designated point of contact, to include address, email, and phone number. INFORMATION CONTACT. III. Background on V2V and the Agency’s Actions Thus Far The U.S. Department of Transportation’s (DOT) National Highway Traffic Safety Administration (NHTSA) announced on February 3, 2014, that it will begin taking steps to enable vehicle-to-vehicle (V2V) communication technology for light vehicles. This technology would improve safety by enabling nearby V2V devices to ‘‘talk’’ to each other using dedicated short range communication (DSRC) to exchange, up to ten times per second, basic safety data such as speed and position. This data could then be used by vehicles to warn drivers of impending danger from other vehicles, and ultimately could help avoid many crashes altogether. On August 18, 2014, NHTSA announced an advance notice of proposed rulemaking (ANPRM) for V2V communications, and concurrently released an extensive research report on the technology. The research report contains a comprehensive discussion of the agency’s current vision for an SCMS in terms of governance, design, and potential costs. The ANPRM contains a number of SCMS and security-related questions on which the agency is seeking responses, which may also assist those responding to this RFI. Although we provide a brief summary below, NHTSA believes that respondents will be in the best position to respond comprehensively to this RFI if they also review the research report and the questions in the ANPRM. Responses to this RFI will be maximally helpful to the agency if they are focused on the specific issue of commenters’ potential interest in operating an SCMS and how they might approach doing so, as well as the other points raised specifically in this RFI. Responses to the RFI will be collected in Docket No. NHTSA–2014–0024. NHTSA requests E:\FR\FM\15OCN1.SGM 15OCN1 Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices tkelley on DSK3SPTVN1PROD with NOTICES that respondents who wish to address V2V issues more broadly, including those issues related to SCMS and security beyond what is discussed in this RFI, please comment to the ANPRM and research report at Docket No. NHTSA–2014–0022. The response period for the ANPRM closes on October 20, 2014. In order to function safely, a V2V system must have trusted communication between V2V devices and message content that is protected from outside interference. In order to create the required environment of trust, a V2V system must include security infrastructure to secure each message, as well as a communications network to convey security and related information from vehicles to the entities providing system security (and vice versa). During the Connected Vehicle Safety Pilot Model Deployment (i.e., Model Deployment), concluded in the Ann Arbor, MI area in 2013 and 2014, V2V devices installed in roughly 2,800 light vehicles were able to transmit and receive messages from one another using security credentials supplied by a prototype security management system. This system was based on a design jointly developed by DOT and the Crash Avoidance Metrics Partnership (CAMP) Vehicle Safety Communications 3 (VSC3) Consortium, a consortium of eight automobile manufacturers. The security system successfully provided trusted and secure communications among the equipped vehicles deployed for Model Deployment. This was accomplished with relatively few problems given the magnitude of this first-of-its-kind demonstration project. In the future, however, if the agency mandates V2V communications devices for all new light vehicles, a much larger security infrastructure and communications network would be necessary to provide that required trust. At this point, DOT and NHTSA anticipate that private entities will create, fund, and manage the security and communications components of a V2V system. While NHTSA has identified several potential types of entities that might be interested in participating in a V2V security system, NHTSA has not identified any private entities that have expressed a willingness to do so. communications security issues associated with V2V, including the nature of the SCMS, as well as a discussion of the agency’s legal relationship with a private SCMS system. For a complete discussion of these issues, please see Part IX of the research report. IV. Security Overview and Operational Characteristics In this section, the agency provides an overview of the discussion of A. Technical Aspects In contrast to other types of safety technologies currently widespread, or increasingly present, in the vehicle fleet, safety applications based on V2V are cooperative—meaning that participating vehicles must exchange (i.e. broadcast and receive) and analyze data in realtime. This cooperative exchange of vehicle to vehicle messages, which represents a new opportunity for vehicle safety, supplies the information needed by a vehicle to prepare driver alerts and warnings about potential hazardous situations. It also gives vehicles the ability to use that information to generate information about mobility and environmental conditions, and communicate with road-side infrastructure. However, a cooperative system can only work when participants in the system are able to trust the alerts and warnings issued by their V2V devices that are based, at least in part, upon information received from other V2V devices. For this reason, a primary requirement for a V2V system is ‘‘trust’’—a requirement that thousands of data messages will be authenticated, in real-time, as being unaltered and coming from a trusted source. It is also a critical element in achieving ‘‘interoperability’’—so that vehicles of different make/model/year will be able to talk to each other and exchange trusted data without pre-existing agreements or altering vehicle designs. In furtherance of system-wide trust, a V2V system also needs to be secure against internal and external threats or attacks. Thus, the three primary elements of the V2V system that require security are the: • V2V communications (the medium, the messages/data, the certificates, and any other element that supports message exchange); • V2V devices; and • V2V security system itself (through organizational, operational, and physical controls). In addition to these requirements, the V2V system needs to be: (1) Ultimately scalable to meet the needs of over 350 1 Non-repudiation in public-key technology is traditionally defined as the inability of a person (to whom a public key has been bound by a recognized certification authority through issuance of a public VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 PO 00000 Frm 00084 Fmt 4703 Sfmt 4703 61929 million users across the nation (such as light vehicles, heavy vehicles, motorcycles, pedestrians, bicycles, etc.), (2) extendable to accommodate other types of applications (such as V2I mobility, traffic management, and environmental applications), and (3) financially sustainable to ensure its continued operation over time. In considering which security technologies would most effectively provide trusted message exchange and secure communications for safetycritical applications, DOT and NHTSA, along with CAMP security experts, compared three different security approaches —symmetric encryption, group signature, and asymmetric public key infrastructure (PKI). When assessing these alternatives, the V2V research team was looking for an option that: • Protects driver privacy appropriately by not requiring participants to disclose their identities; • Works quickly enough to fit within the bandwidth constraints of DSRC and the expected processing constraints of the V2V on-board equipment; • Does not require over-the-air bytes for security that exceed the constraints of DSRC bandwidth and size of the Basic Safety Message (BSM) in the message payload; and • Supports non-repudiation.1 After considering the characteristics of each security approach, the research development team preliminarily determined that the PKI option (asymmetric key) using the signature method offered the most effective approach to achieving communications security and trusted messaging for a very large set of users. For this reason, the research team chose that approach to secure the BSM that is at the center of the current V2V system design. Significantly, the effectiveness of this approach is highly dependent upon technical design decisions relating to how the approach is deployed in a given environment. B. V2V Security Design Concept: Functions, Components, Communications Figure 1 presents the high level, basic components/functions of the V2V security system. They are similar to the basic functions of any Public Key Infrastructure (PKI) security system. key certificate) to deny having made some digital signature. E:\FR\FM\15OCN1.SGM 15OCN1 61930 Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices TABLE 1—SECURITY RELATED ACRONYMS—Continued Acronym TABLE 1—SECURITY RELATED ACRONYMS Acronym tkelley on DSK3SPTVN1PROD with NOTICES BSM ....... CA ......... CME ...... CP ......... CRL ....... DCA ....... ECA ....... Definition basic safety message. certificate authority. certificate management entity. certificate policy. certificate revocation list. device configuration manager. enrollment certificate authority. VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 Definition FIPS ...... Federal Information Processing Standards. linkage authority. location obscurer proxy. misbehavior authority. pseudonym certificate authority. personally identifiable information. public-key infrastructure. registration authority. security credential management system. LA .......... LOP ....... MA ......... PCA ....... PII .......... PKI ......... RA ......... SCMS .... PO 00000 Frm 00085 Fmt 4703 Sfmt 4703 Figure 2 illustrates multiple security and privacy operations and components that DOT envisions for a V2V system to accomplish the distribution of certificates in a way that is trusted and that protects consumers’ privacy. The fundamental operations are indicated as (1) Overall Management, (2) Registration and Enrollment, (3) Certificate Management and (4) Misbehavior Management. The text following this illustration contains definitions for each component. BILLING CODE 4910–59–P E:\FR\FM\15OCN1.SGM 15OCN1 EN15OC14.000</GPH> For reference, Table 1 contains a list of abbreviations used to describe the system discussed in more detail below: 61931 Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices Figure 2 Current V2V Security System Design for Deployment and Operations2 2 4 at&. Store CRL Broadcast Devke COnlis. Manacer Legend ~~~J t. ,.Cent ai,.,Cho" " "lce" 'by-~ ~Centljlil i:Ni!l!l!onl l ira~l~ •.:CQa Device 2 - Devke:3 Replar Communieatfon Out-of-band Communk:atton ..... lnttfaf Deployment - Full Deployment 2 Thi• image presents both an initial deployment model as well as a full depiO)'DII'nt model. Note duJ.t thi• diagnm shows the initial deployment model in which there is no (ECA) (dolled lines). In the full deployment modeL these entities communicate with the Intermediate CA instead of the Root CA to protect the Root CA from unnoccssary exposure (solid line). BILLING CODE 4910–59–P The following discussion of SCMS functions focuses on communications VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 and activities within the SCMS. The technical design for the SCMS includes several different operating functions PO 00000 Frm 00086 Fmt 4703 Sfmt 4703 that, together, make up the overall SCMS structure. It is envisioned that single or multiple operating functions E:\FR\FM\15OCN1.SGM 15OCN1 EN15OC14.001</GPH> tkelley on DSK3SPTVN1PROD with NOTICES Intermediate Certificate Authority (CA) and the Root CA talks to the Misbehavior Authority (MA), P•ew!onym Certificate Au!hority,(PCA) and Enrollmont Certificate Authority 61932 Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices tkelley on DSK3SPTVN1PROD with NOTICES will be carried out by individual, legally distinct CMEs (including the SCMS Manager) that, together, will make up the SCMS organization. The agency is interested in respondents providing their views on potential structure of the entire SCMS organization, including the distinction, if one is needed, between separate components and responsibilities. That said, we note that the interaction between the components shown in Figure 2 is all based on machine-tomachine performance. No human judgment is involved in creation, granting, or revocation of the digital certificates. The functions are performed automatically by processors in the various V2V components, including the vehicle’s on-board equipment (OBE). The role of personnel within the SCMS is to manage the overall system, protect and maintain the computer hardware and facilities, update software and hardware, and address unanticipated issues.3 Generally, these SCMS operating functions fall into two categories: ‘‘pseudonym functions’’ and ‘‘bootstrap functions,’’ discussed further below. In order for the SCMS to support the security needs of the V2V system, the various SCMS functions (housed in different CME organizations) must work together to exchange information securely and efficiently. C. Pseudonym Functions/Certificates The security design employs shortterm digital certificates used by a vehicle’s V2V device to authenticate and validate BSMs that are sent and received. Since these BSMs provide the information needed for V2V-based safety warning technologies to operate, it is important that they are trustworthy. A valid certificate indicates the BSM was transmitted from a trusted source. A BSM with a revoked (invalid) certificate is ignored by other V2V devices. In order to protect privacy appropriately, these short-term certificates do not contain any information about the vehicles and their occupants (e.g., drivers/occupants or vehicle make/model/VIN), but they serve as credentials that permit vehicles to participate in the V2V system. Pseudonym functions create, manage, distribute, monitor, and revoke shortterm certificates for vehicles. They include the following functions: • Intermediate Certificate Authority (Intermediate CA), which is an extension of the Root CA, shielding it 3 The SCMS manager would establish policies and procedures that influence the configuration of the system parameters. VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 from direct access to the internet. It can authorize other CMEs (or possibly an Enrollment Certificate Authority [ECA]) using authority from the Root CA, but does not hold the same authority as the Root CA in that it cannot self-sign a certificate. The Intermediate CA provides flexibility in the system because it removes the need for the highly protected Root CA to establish contact with every SCMS entity as they are added to the system over time. Additionally, the use of Intermediate CAs lessens the impact of an attack by maintaining protection of the Root CA. • Linkage Authority (LA), which is the entity that generates linkage values. The LA comes in pairs of two, which we refer to as LA1 and LA2, in order to further protect privacy. The LAs for most operations communicate only with the RA and provide values, known as linkage values, in response to a request by the RA (see below) and PCA (see below). The linkage values provide the PCA with a means to calculate a certificate ID and a mechanism to connect all short-term certificates from a specific device for ease of revocation in the event of misbehavior. • Location Obscurer Proxy (LOP), which obscures the location of OBE seeking to communicate with the SCMS functions, so that the functions are not aware of the geographic location of a specific vehicle. All communications from the OBE to the SCMS components must pass through the LOP. Additionally, the LOP may shuffle misbehavior reports that are sent by OBEs to the MA (see below) during full deployment. This function increases participant privacy but does not increase or reduce security. • Misbehavior Authority (MA), which acts as the central function to process misbehavior reports, as well as to produce and publish the certificate revocation list (CRL). It works with the PCA, RA, and LAs to acquire necessary information about a certificate to create entries to the CRL through the CRL Generator. The MA eventually may perform global misbehavior detection, involving investigations or other processes to identify levels of misbehavior in the system. The MA is not an external law enforcement function, but rather an internal SCMS function intended to detect when messages are not plausible or when there is potential malfunction or malfeasance within the system. The extent to which the CMEs share externally information generated by the MA about devices sending inaccurate or false messages—whether with individuals whose credentials the system has revoked, regulatory agencies PO 00000 Frm 00087 Fmt 4703 Sfmt 4703 or law enforcement—will depend on law, organizational policy, and/or contractual obligations applicable to the CMEs and their component functions. • Pseudonym Certificate Authority (PCA), which issues the short-term certificates used to ensure trust in the system. In earlier designs their lifetime was fixed at five minutes. The validity period of certificates is still on the order of ‘‘minutes’’ but is now a variable length of time, making them less predictable and thus harder to track. Certificates are the security credentials that authenticate messages (BSM) from a device. In addition to certificate issuance, the PCA collaborates with the MA, RA, and LAs to identify linkage values to place on the CRL if misbehavior has been detected. Individual PCAs may be limited to a particular manufacturer or a particular region. • Registration Authority (RA), which performs the necessary key expansions before the PCA performs the final ones. It receives certificate requests from the OBE (by way of the LOP), requests and receives linkage values from the LAs, and sends certificate requests to the PCA. It shuffles requests from multiple OBEs to prevent the PCA from correlating certificate IDs with users. It also acts as the final conduit to batching short-term certificates for distribution to the OBE. Lastly, it creates and maintains a blacklist of enrollment certificates so it will know to reject certificate renewal requests from revoked OBEs. • Request Coordination, which is critical in preventing an OBE from receiving multiple batches of certificates from different RAs. The Request Coordination function coordinates activities with the RAs to ensure that certificate requests during a given time period are responded to appropriately and without duplication. Note that this function is only necessary if there is more than one RA in the SCMS. • Root Certificate Authority (Root CA), which is the master root for all other CAs; it is the ‘‘center of trust’’ of the system. It issues certificates to subordinate CAs in a hierarchical fashion (as well as MA, LAs and RAs), providing their authentication within the system so all other users and functions know they can be trusted. The Root CA produces a self-signed certificate (verifying its own trustworthiness) using out-of-band communications. This enables trust that can be verified between ad hoc or disparate devices because they share a common trust point. It is likely that the Root CA will operate in a separate, offline environment because compromise of this function is a E:\FR\FM\15OCN1.SGM 15OCN1 Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices tkelley on DSK3SPTVN1PROD with NOTICES catastrophic event for the security system. • SCMS Manager, which is the function that will provide the policy and technical standards for the entire V2V system. Just as any large-scale industry ensures consistency and standardization of technical specifications, standard operating procedures (SOPs), and other industrywide practices such as auditing, the SCMS Manager would establish SOPs, including in such areas as interoperability, security, privacy and auditing, and manage the activities required for smooth and expected operation of the SCMS. This could happen in a number of ways. Often in commercial industries, volunteer industry consortia take on this role. In other industries, or in public or quasipublic industries, this role may be assumed by a regulatory or other legal or policy body. Regardless of how the SCMS ‘‘industry’’ establishes and operates a central administrative body, it is expected that one will be established for the V2V SCMS. As no decisions about ownership or operation have been made, we do not advocate for public or private ownership of the CMEs that will make up the SCMS. Rather, in our discussions and analyses, we identify the basic functions that we expect the SCMS Manager will perform. The expectation is that the CMEs that make up the SCMS, either voluntarily or contractually, will agree to adhere to the SOPs, audit standards, and other practices established by the SCMS Manager. In accordance with input from DOT, the SCMS Manager will develop applicable guidance, practices, SOPs, auditing standards, or additional industry-wide procedures in coordination with, or so as to dovetail with Federal guidance or regulations applicable to V2V communications. NHTSA also assumes that the CMEs will endow the SCMS manager with authority to remove from the SCMS or revoke the ‘‘credentials’’ of CMEs that misbehave or do not comply with applicable standards. D. ‘‘Bootstrap’’/Initialization Functions/ Enrollment Certificate The security design also includes functions that carry out the bootstrapping process, which establishes the initial connection between a V2V device and the SCMS. The chief functional component of this process is the Enrollment Certificate Authority (ECA), which assigns a longterm enrollment certificate to each V2V device. Initialization functions include: VerDate Sep<11>2014 19:32 Oct 14, 2014 Jkt 235001 • Certification Lab, which instructs the Enrollment CA on polices and rules for issuing enrollment certificates, i.e. device enrollment criteria. This is usually done when a new device is released to the market or if the SCMS Manager releases new rules and guidelines. The Enrollment CA uses information from the Certification lab to confirm that devices of the given type are entitled to an enrollment certificate. At this time, specific details regarding the Certification and Enforcement are not defined.4 • Device Configuration Manager (DCM), which is responsible for giving devices access to new trust information, such as updates to the certificates of one or more authorities, and relaying policy decisions or technical guidelines issued by the SCMS Manager. It also sends software updates to devices. The DCM coordinates initial trust distribution with devices by passing on credentials for other SCMS entities, and provides a device with information it needs to request short term certificates from an RA. The DCM also plays a role in the bootstrap process by ensuring that a device is cleared to receive its enrollment certificate from the ECA. It also provides a secure channel to the ECA. There are two types of connections used from devices to the DCM: In-band and out-of-band communications. Inband communication utilizes the LOP, while out-of-band communication is sent directly from the device to the ECA, by way of the DCM. • Enrollment Certificate Authority (ECA), which verifies the validity of the device type with the Certification Lab. Once verified, the ECA then produces the enrollment certificate and sends it to the OBE. Once the OBE has a valid enrollment certificate, it is able to request and receive certificates from the SCMS. Individual PCAs may be limited to a particular manufacturer or a particular region. E. Privacy Considerations Risks to consumer privacy, whether actual or perceived, are intertwined with consumer and industry acceptance of V2V technologies. For this reason, 4 At this point, the extent and level of testing which the Certification Lab will actually perform is still to be determined. The role of the labs could range from simply managing a checklist of requirements to performing extensive technical certification tests, including: device performance, FCC compliance, cryptographic testing (at the level of FIPS–140), and/or interoperability testing. The intent is that the SCMS Manager, after it is created, will determine the full roles and responsibilities of the Certification Lab. Vehicle and device manufacturers may decide to rely in part on a certification lab to support their own certification of compliance with any relevant standards NHTSA may issue. PO 00000 Frm 00088 Fmt 4703 Sfmt 4703 61933 privacy considerations are critical to the analysis underlying NHTSA’s decision about how to proceed with regulation. At the outset, readers should understand some very important points about the V2V system as contemplated by NHTSA. The system will not collect or store any data on individuals or individual vehicles, nor will it enable the government to do so. There is no data in the basic safety messages broadcast by V2V devices or collected by the V2V security system intended to be used by law enforcement or private entities to personally identify a speeding or erratic driver.5 The system—presumably operated by private entities—will not permit tracking through space or time of vehicles linked to specific owners or drivers or persons. Third parties attempting to use the system to track a vehicle would find it extremely difficult to do so, particularly in light of far simpler and cheaper means available for that purpose. The system will not collect financial information, personal communications, or other information linked to individuals. It will enroll V2V enabled vehicles automatically, without collecting any information identifying specific vehicles or owners. The system will not provide a ‘‘pipe’’ into the vehicle for extracting data. While the system needs to enable NHTSA and motor vehicle manufacturers to find lots or production runs in the event of defective and/or non-compliant V2V devices, it will do so without use of VIN numbers or other information that could identify specific drivers or vehicles. There are two primary categories of V2V system functions that involve the transmission, collection, storage, and sharing of V2V data by, and between, the V2V system components and other entities: system safety and system security. The V2V system’s safety functionality (i.e., the safety applications that produce crash warnings) requires that V2V devices broadcast and receive a basic safety message containing information about vehicle position, heading, speed, and other information relating to vehicle state and predicted path. The BSM, however, contains no personally identifying information (PII) and is broadcast in a very limited geographical range, typically less than 1 km. Nearby devices installed in other vehicles will use that information to warn drivers of crash-imminent 5 Definition of the current basic safety message data elements is found in Table V–1 and Table V– 2 of the agency’s V2V research report, ‘‘Vehicle-toVehicle Communications: Readiness of V2V Technology for Application V1.0 August, 2014’’. E:\FR\FM\15OCN1.SGM 15OCN1 61934 Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices situations. Except as necessary to identify devices in the case of malfunction, the system will not collect, and motor vehicles will not store, the messages or data that are sent or received by V2V devices. F. Device Non-Compliance and Potential Recalls tkelley on DSK3SPTVN1PROD with NOTICES Currently, as discussed in the report, NHTSA may need to conduct further research into how to ensure that all V2V devices subject to a recall can be identified, and that owners can be notified about the issue and be provided instructions for how to remedy a potential condition. Section VIII.B.3 of the agency’s V2V research report discusses the possibility that for vehicles manufactured with V2V devices installed, the SCMS may be able to create a link at the time of manufacture between specific installed V2V devices or production lots of devices and enrollment certificates that later may help vehicle manufacturers and NHTSA identify defective V2V equipment, potentially linking device batches to enrollment certificates. However, it is not yet clear how such a linkage would be created for V2V devices that are not installed by the manufacturer. The agency welcomes discussion from respondents on the potential approach discussed in the report along with other potential approaches, based on a respondent’s experience, which NHTSA may employ to fulfill its defect and non-compliance identification responsibilities. The security needs of the V2V system require the exchange of certificates and other communications between: (1) V2V devices and (2) the entity or entities providing security for the V2V system (i.e., the Security Credential Management System). These two-way communications are encrypted and subject to additional security measures. These measures are designed to prevent SCMS insiders and others from VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 unauthorized access to information that might enable linkage of BSM data or security credentials to specific motor vehicles. NHTSA also needs to ensure that the V2V system is protected from defective and non-compliant devices. In order to do so, the V2V security system will likely need to collect and share with manufacturers, such that they can comply with Federal regulations, on a very limited basis, some V2V data linking V2V device production lots to security credentials. However, as currently envisioned, neither the V2V system nor NHTSA will collect, store, or have access to information that links production lots of defective V2V devices with specific VINs or owners. NHTSA and the DOT take privacy very seriously. If NHTSA moves forward with regulating V2V technologies, we are committed to doing so in a manner that both protects individual privacy appropriately and promotes this important safety technology. V. SCMS Organizational Options The above discussion of SCMS functions focused on activities and communications within the SCMS. The current section discusses the DOT research performed by Booz Allen Hamilton (BAH), with input from CAMP and the Vehicle Infrastructure Integration Consortium (VIIC), on the development of an SCMS organization. The purpose of BAH’s research was to generate organizational options for an SCMS capable of enabling secure and efficient communications, protecting privacy appropriately, and minimizing operational costs. BAH developed a number of different organizational options by grouping the SCMS functions in CAMP’s design into legally/ administratively distinct entities. BAH’s analysis of the organizational options for the SCMS, detailed below, focused primarily on organizational connections and separations, as well as the closely- PO 00000 Frm 00089 Fmt 4703 Sfmt 4703 related process of characterizing functions as ‘‘central’’ or ‘‘non-central’’ (which is intimately tied to the issue of system ownership and operation). It also examined the cost, security risk, and operational/policy implications of the different SCMS models. BAH began by identifying multiple organizational models that, together, captured all possible configurations of the SCMS functions identified by CAMP. DOT initially selected a small number of these organizational models for BAH to further consider. As CAMP’s technical design evolved, DOT instructed BAH to reconfigure the models to reflect additional SCMS functions added to the SCMS design by CAMP, as well as CAMP’s new categorization of functions as either ‘‘central’’ or ‘‘non-central.’’ Based on its independent PKI research, as well as new insights into the security design communicated by CAMP, BAH then simplified the initial organizational design proposed by CAMP to remove certain organizational separations of functions that BAH determined were not necessary for security or privacy reasons. Ultimately, the organization of the SCMS—the final grouping of functions and estimates of any efficiencies—will be controlled by the organization(s) that manage the SCMS and own and operate the component CMEs. However, NHTSA and DOT anticipate being able to influence the organization and operation of the SCMS (and thereby ensure adequate separation to assure secure, privacy-appropriate V2V communications) through an agreement or MOU with the SCMS Manager and/ or through participation on a SCMS ‘‘governance board.’’ BAH’s SCMS organizational model/ analysis, Figure 2, is based on CAMP’s current SCMS technical design and represents BAH’s perspective of how functions within the SCMS may be grouped. E:\FR\FM\15OCN1.SGM 15OCN1 Organizational separation of functions is an example of a policy control often used to mitigate privacy risks in PKI systems—but such separations come with increased costs and may negatively impact the system’s ability to identify and revoke the credentials of misbehaving devices. Ultimately, more than one function may be co-located within the same SCMS component organization. However, grouping of SCMS functions and any resulting efficiencies/risk trade-offs will depend, in large part, on: (1) The system’s ownership, operational structure, and governance in accordance with DOT, and (2) the preferences of the entity or entities that own and operate the SCMS Manager and CME component entities. The SCMS Manager is intended to serve as the entity that provides system management, primarily by enforcing and auditing compliance with uniform technical and policy standards and guidance for the SCMS system-wide. The uniform standards/guidance will need to establish and ensure consistency, effectiveness, interoperability, and appropriate security and privacy protection across the CMEs, in order to facilitate necessary communications, sharing of information, and operational VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 connections. The SCMS Manager will need to have mechanisms to ensure that all CME entities have policies, practices, technologies, and communications consistent with system-wide standards and guidance. The SCMS Manager may (but need not) be the body that develops the standards, guidance, or policies applicable system-wide; however, it would be the entity charged with overseeing standards and policy compliance by the CME entities that, together with the SCMS Manager, make up the SCMS. The agency anticipates existing PKI technical standards and industry best practices likely will form the basis for many of the policies and procedures applicable across the SCMS.6 VI. The Legal Relationship Between NHTSA and the SCMS As currently envisioned by NHTSA, deployment of V2V technologies requires existence of an SCMS to provide necessary security functions. In its February 3, 2014, announcement, NHTSA expressed its intent to begin working on a regulatory proposal to require V2V devices in new motor vehicles in a future year, and on August 6 BAH PO 00000 SCMS Design and Analysis Report, at 29. Frm 00090 Fmt 4703 Sfmt 4703 61935 18, 2014, NHTSA announced an advance notice of proposed rulemaking to start the regulatory process for V2V technology. A subsequent NHTSA V2V regulatory proposal, a notice of proposed rulemaking (NPRM), potentially could extend to many aspects of the hardware, software, and communications, making up significant parts of the V2V system. However, NHTSA, at this time, anticipates that establishment of the SCMS itself, which will provide security services necessary for secure reliable V2V messaging within the V2V system, will not be encompassed in its regulatory proposal. Instead, as discussed elsewhere in today’s RFI, NHTSA envisions that constitution and operation of the SCMS will be undertaken by one or more private entities, working collaboratively with NHTSA. NHTSA and DOT do not currently envision the Federal government being the owner or operator of the SCMS. There is a wide range of collaborative relationships that NHTSA potentially could enter into with the private entity or entities that manage or make up the SCMS. The overarching goal of the relationship(s) would be to ensure the existence and operation of an SCMS needed to support the V2V system in a E:\FR\FM\15OCN1.SGM 15OCN1 EN15OC14.002</GPH> tkelley on DSK3SPTVN1PROD with NOTICES Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices tkelley on DSK3SPTVN1PROD with NOTICES 61936 Federal Register / Vol. 79, No. 199 / Wednesday, October 15, 2014 / Notices way that appropriately protects consumer privacy and system security and does not impose inordinate costs on OEMs, vehicle drivers, or others. Ultimately, the nature and scope of the relationship(s) will turn on the specific terms upon which the parties agree. Section IV of the research report contains discussion of the agency’s authority to enter into agreements documenting the collaborative relationship between NHTSA and the private entity or entities that constitute and operate the SCMS supporting V2V communications. As discussed for the first time in this RFI, such an agreement would likely address or provide minimum requirements in the following areas: • Service Period: How long the entity or entities would commit to ensuring availability of security services required to support the V2V system; • Organization: Legal/administrative separation between, and the legal relationship among, CMEs that make up the SCMS; • Operation: Certificate, security, privacy, audit, interoperability, and related operational policies; • Governance: Initially, and on an ongoing basis, transparent mechanisms for obtaining input on issues relevant to SCMS constitution and operation from (1) the CMEs that make up the SCMS and (2) other stakeholders; • System Access: To ensure support for V2V, V2I, and V2X applications and users (consumers and manufacturers) in the U.S., Canada and Mexico; • Fees: Service and user classes for V2V, V2I, and V2X users (consumers and manufacturers); • Privacy: Controls, enforcement, reporting (internal and to NHTSA), and data policies that provide clear notice to consumers of (among other things) what data is being collected, how it is used, and, for opt-in services, giving consumers control over access to their data; • Security: Controls, enforcement, and reporting (internal and to NHTSA); • Continuity of Operation: Procedural mechanisms to ensure continued support for the V2V system; • Liability/Insurance: Liability and business interruption insurance; • Cooperation: Procedures for working with Federal and State law enforcement and consumer fraud authorities to address any issues that threaten the system’s safety or security. VII. Specific Questions for This Notice Specific questions posed in this notice follow. Respondents are reminded that feedback on any aspects of this notice is welcome from all VerDate Sep<11>2014 18:00 Oct 14, 2014 Jkt 235001 interested public, private, and academic entities. If your responses relate to how NHTSA should implement a requirement for V2V, and the agency’s authority to require V2V, rather than to the SCMS issues outlined in this notice, please submit such responses as comments to the rulemaking docket for the ANPRM (NHTSA–2014–0022) rather than this docket. While all feedback regarding the agency’s regulatory announcements and the ANPRM is welcome from all parties, NHTSA is particularly interested, regarding this request for information, in hearing from those entities interested in establishing an SCMS. Respondents may respond, to some, all, or none of these specific questions: 1. SCMS ownership and operation are inextricably linked to SCMS governance. DOT research to date has focused on the likelihood of private ownership and operation of the SCMS ‘‘industry,’’ with governance being largely ‘‘self-governance’’ by private industry participants and stakeholders. Other basic organizational models that could apply, besides this private model, are: public, and public-private. What model is most appropriate and what are the risks, if any, associated with a private ‘‘self-governance’’ approach and how would you mitigate them? 2. The SCMS has many functions that are needed to establish the trusted environment required for V2V communications. The SCMS consists of both central and non-central functions to be carried out by legally distinct CMEs that can be owned and operated by various individual entities. What is your interest in helping to establish an SCMS? Which SCMS functions are you most interested in performing, either on your own or as part of a larger consortium? What information or other resources do you need to initiate planning, development, and implementation of the identified SCMS functions? The agency would also appreciate respondents providing potential lead times associated with standing up an SCMS and making it fully operational to support a national implementation of V2V technology, because lead time will help the agency understand when V2V technology could potentially be rolled out most successfully. 3. In relation to the SCMS Manager function, will the establishment of either a binding or non-binding ‘‘governance board’’ provide the appropriate level of stakeholder guidance and direction to facilitate a viable and self-sustaining business entity? If not, why not, and what PO 00000 Frm 00091 Fmt 4703 Sfmt 9990 additional or other type of governance or oversight might be needed? 4. In order for the SCMS to function, what standards and policies applicable to individual CMEs will need to be developed and implemented? Who do you envision will establish the various standards, policies, procedures, auditing processes, and other related industrywide processes? 5. NHTSA and DOT anticipate being able to influence the organization and operation of the SCMS (and thereby ensure adequate separation to assure secure, privacy appropriate V2V communications) through some type of agreement with the SCMS Manager or through participation on an SCMS ‘‘governance board.’’ In the ‘‘Legal Relationship between NHTSA and the SCMS’’ section of this Request for Information, we identify some likely components of an agreement between NHTSA and the SCMS Manager or entities making up the SCMS. Are there other components that such an agreement should cover? If so, please identify them and explain their importance. If the SCMS established a ‘‘governance board,’’ how should the board be constituted? Should the board’s decisions be binding on the SCMS? Typically, NHTSA and other Federal government entities participate as non-voting liaisons or ex officio members of private boards (NHTSA, for example, regularly assigns agency employees to be non-voting liaisons on Society of Automotive Engineers (SAE) and Transportation Research Board (TRB) Committees and Boards). Would it be viable for NHTSA to participate in this manner? 6. The agency asks respondents to provide their projections of initial capital investment for SCMS functions overall and components they may potentially be interested in ‘‘standing up’’ and supporting. 7. Additionally, the agency welcomes feedback on how respondents envision SCMS financial sustainability and its relation to any data collection or fees, if any, that would be permitted under the agreement with DOT. 8. If you are interested in performing certain functions related to the SCMS, explain how you would ensure that privacy concerns are addressed in performance of those functions. Authority: 49 U.S.C. 30101 et. seq.; 49 CFR 1.95. Issued in Washington. Daniel C. Smith, Senior Associate Administrator for Vehicle Safety. [FR Doc. 2014–24482 Filed 10–14–14; 8:45 am] BILLING CODE 4910–59–P E:\FR\FM\15OCN1.SGM 15OCN1

Agencies

[Federal Register Volume 79, Number 199 (Wednesday, October 15, 2014)]
[Notices]
[Pages 61927-61936]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2014-24482]


-----------------------------------------------------------------------

DEPARTMENT OF TRANSPORTATION

National Highway Traffic Safety Administration


Vehicle-to-Vehicle Security Credential Management System; Request 
for Information

AGENCY: National Highway Traffic Safety Administration (NHTSA), 
Department of Transportation (DOT).

ACTION: Notice--Request for Information (RFI).

-----------------------------------------------------------------------

SUMMARY: On August 18, 2014, NHTSA announced an advance notice of 
proposed rulemaking (ANPRM) for V2V communications, and concurrently 
released an extensive research report on the technology, as the formal 
start to the regulatory process. This notice, a Request for Information 
(RFI), seeks information related to the security system that will 
support V2V operations but will not be established by NHTSA regulation. 
This RFI will help the agency: (1) Become aware of private entities 
that may have an interest in exploring the possibility of developing 
and/or operating components of a V2V Security Credential Management 
System (SCMS); (2) Receive responses to the questions posed about the 
establishment of an SCMS provided in the last section of this RFI; and 
(3) Obtain feedback, expressions of interest, and comments from all 
interested public, private, and academic entities on any aspect of the 
SCMS.
    The Background section of this RFI provides an overview of the 
technical and organizational aspects of the current V2V security 
design, of which the SCMS is an integral part. The SCMS encompasses all 
technical,

[[Page 61928]]

organizational, and operational aspects of the V2V security system that 
is needed to support trusted, safe/secure V2V communications and to 
protect driver privacy appropriately. The primary managerial component 
of the envisioned SCMS (called the SCMS Manager) would be responsible 
for managing all other component entities (called Certificate 
Management Entities or CMEs) which support the different V2V security 
functions that, together, ensure the operational integrity of the total 
system.

DATES: Responses to this RFI should be submitted by 11:59 p.m., E.T., 
on December 15, 2014.

ADDRESSES: Responses: You may submit responses, identified by Docket 
No. NHTSA-2014-0023, by any of the following methods:
    Internet: To submit responses electronically, go to http://www.regulations.gov and follow the online instructions for submitting 
comments. Alternatively, go to http://www.safercar.gov/v2v/index.html 
and click the yellow button labeled ``Submit responses on the SCMS 
Request for Information'' to go directly to the docket in 
regulations.gov.
    Facsimile: Written responses may be faxed to 1-202-493-2251.
    Mail: Send responses to Docket Management Facility, U.S. Department 
of Transportation, 1200 New Jersey Avenue SE., West Building Ground 
Floor, Room W12-140, Washington, DC 20590.
    Hand Delivery: If you plan to submit written responses by hand or 
by courier, please do so at U.S. Department of Transportation, 1200 New 
Jersey Avenue SE., West Building Ground Floor, Room W12-140, 
Washington, DC between 9 a.m. and 5 p.m. E.T., Monday through Friday, 
except Federal holidays. You may call the Docket Management Facility at 
1-800-647-5527.

FOR FURTHER INFORMATION CONTACT: For questions about the program 
discussed herein, contact John Harding, NHTSA, Intelligent Technologies 
Research Division, 202-366-5665, john.harding@dot.gov. For legal 
questions, interpretations and counsel, please contact Rebecca Yoon, 
Office of the Chief Counsel, 202-366-8909, rebecca.yoon@dot.gov, 1200 
New Jersey Avenue SE., Washington, DC 20590.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Purpose of This Notice
II. RFI Guidelines
III. Background on V2V and the Agency's Actions Thus Far
IV. Security Overview and Operational Characteristics
    A. Technical Aspects
    B. V2V Security Design Concept: Functions, Components, 
Communications
    C. Pseudonym Functions/Certificates
    D. ``Bootstrap''/Initialization Functions/Enrollment Certificate
    E. Privacy Considerations
    F. Device Non-Compliance and Potential Recalls
V. SCMS Organizational Options
VI. The Legal Relationship Between NHTSA and the SCMS
VII. Specific Questions for This Notice

I. Purpose of This Notice

    NHTSA seeks responses from parties potentially interested in 
establishing and operating a V2V SCMS. Respondents can express 
interest, provide comments concerning the establishment of an SCMS, 
provide information concerning security approaches for a V2V 
environment, and discuss the technical and organizational aspects of 
the SCMS. While comments are welcome on any area of the RFI, NHTSA is 
particularly interested in responses related to interest in 
establishing an SCMS, including but not limited to some or all of the 
legally distinct CMEs that make up the SCMS, along with responses to 
the questions detailed in the Summary of Questions section of this RFI.

II. RFI Guidelines

    Responses to this notice are not offers and cannot be accepted by 
the Government to form a binding contract or issue a grant. Information 
obtained as a result of this RFI may be used by the Government for 
program planning on a non-attribution basis. This RFI notice is NOT a 
solicitation for proposals, applications, proposal abstracts, or 
quotations. This RFI notice is not to be construed as a commitment on 
the part of the Government to award a contract or grant, nor does the 
Government intend to directly pay for any information or responses 
submitted as a result of this RFI notice.
    The Government prefers that submissions NOT include any information 
that might be considered proprietary or confidential. The Government 
intends to publicly release a summary of responses to this RFI. Such a 
summary may identify the number and types of respondents (e.g., public 
agency, private entity, or academic institution). If you wish to submit 
any information under a claim of confidentiality, you should submit 
three copies of your complete submission, including the information you 
claim to be confidential business information, to the Chief Counsel, 
NHTSA, at the address given above under FOR FURTHER INFORMATION 
CONTACT. In addition, you should submit two copies, from which you have 
deleted the claimed confidential business information, to Docket 
Management at the address given above under ADDRESSES. When you send a 
comment containing information claimed to be confidential business 
information, you should include a cover letter, as specified in our 
confidential business information regulation (49 CFR part 512.), that 
delineates that information.
    Responses should clearly identify the name(s) of the responding 
organization(s) or individual(s) and a designated point of contact, to 
include address, email, and phone number.

III. Background on V2V and the Agency's Actions Thus Far

    The U.S. Department of Transportation's (DOT) National Highway 
Traffic Safety Administration (NHTSA) announced on February 3, 2014, 
that it will begin taking steps to enable vehicle-to-vehicle (V2V) 
communication technology for light vehicles. This technology would 
improve safety by enabling nearby V2V devices to ``talk'' to each other 
using dedicated short range communication (DSRC) to exchange, up to ten 
times per second, basic safety data such as speed and position. This 
data could then be used by vehicles to warn drivers of impending danger 
from other vehicles, and ultimately could help avoid many crashes 
altogether.
    On August 18, 2014, NHTSA announced an advance notice of proposed 
rulemaking (ANPRM) for V2V communications, and concurrently released an 
extensive research report on the technology. The research report 
contains a comprehensive discussion of the agency's current vision for 
an SCMS in terms of governance, design, and potential costs. The ANPRM 
contains a number of SCMS and security-related questions on which the 
agency is seeking responses, which may also assist those responding to 
this RFI. Although we provide a brief summary below, NHTSA believes 
that respondents will be in the best position to respond 
comprehensively to this RFI if they also review the research report and 
the questions in the ANPRM. Responses to this RFI will be maximally 
helpful to the agency if they are focused on the specific issue of 
commenters' potential interest in operating an SCMS and how they might 
approach doing so, as well as the other points raised specifically in 
this RFI. Responses to the RFI will be collected in Docket No. NHTSA-
2014-0024. NHTSA requests

[[Page 61929]]

that respondents who wish to address V2V issues more broadly, including 
those issues related to SCMS and security beyond what is discussed in 
this RFI, please comment to the ANPRM and research report at Docket No. 
NHTSA-2014-0022. The response period for the ANPRM closes on October 
20, 2014.
    In order to function safely, a V2V system must have trusted 
communication between V2V devices and message content that is protected 
from outside interference. In order to create the required environment 
of trust, a V2V system must include security infrastructure to secure 
each message, as well as a communications network to convey security 
and related information from vehicles to the entities providing system 
security (and vice versa).
    During the Connected Vehicle Safety Pilot Model Deployment (i.e., 
Model Deployment), concluded in the Ann Arbor, MI area in 2013 and 
2014, V2V devices installed in roughly 2,800 light vehicles were able 
to transmit and receive messages from one another using security 
credentials supplied by a prototype security management system. This 
system was based on a design jointly developed by DOT and the Crash 
Avoidance Metrics Partnership (CAMP) Vehicle Safety Communications 3 
(VSC3) Consortium, a consortium of eight automobile manufacturers. The 
security system successfully provided trusted and secure communications 
among the equipped vehicles deployed for Model Deployment. This was 
accomplished with relatively few problems given the magnitude of this 
first-of-its-kind demonstration project.
    In the future, however, if the agency mandates V2V communications 
devices for all new light vehicles, a much larger security 
infrastructure and communications network would be necessary to provide 
that required trust. At this point, DOT and NHTSA anticipate that 
private entities will create, fund, and manage the security and 
communications components of a V2V system. While NHTSA has identified 
several potential types of entities that might be interested in 
participating in a V2V security system, NHTSA has not identified any 
private entities that have expressed a willingness to do so.

IV. Security Overview and Operational Characteristics

    In this section, the agency provides an overview of the discussion 
of communications security issues associated with V2V, including the 
nature of the SCMS, as well as a discussion of the agency's legal 
relationship with a private SCMS system. For a complete discussion of 
these issues, please see Part IX of the research report.

A. Technical Aspects

    In contrast to other types of safety technologies currently 
widespread, or increasingly present, in the vehicle fleet, safety 
applications based on V2V are cooperative--meaning that participating 
vehicles must exchange (i.e. broadcast and receive) and analyze data in 
real-time. This cooperative exchange of vehicle to vehicle messages, 
which represents a new opportunity for vehicle safety, supplies the 
information needed by a vehicle to prepare driver alerts and warnings 
about potential hazardous situations. It also gives vehicles the 
ability to use that information to generate information about mobility 
and environmental conditions, and communicate with road-side 
infrastructure. However, a cooperative system can only work when 
participants in the system are able to trust the alerts and warnings 
issued by their V2V devices that are based, at least in part, upon 
information received from other V2V devices.
    For this reason, a primary requirement for a V2V system is 
``trust''--a requirement that thousands of data messages will be 
authenticated, in real-time, as being unaltered and coming from a 
trusted source. It is also a critical element in achieving 
``interoperability''--so that vehicles of different make/model/year 
will be able to talk to each other and exchange trusted data without 
pre-existing agreements or altering vehicle designs. In furtherance of 
system-wide trust, a V2V system also needs to be secure against 
internal and external threats or attacks.
    Thus, the three primary elements of the V2V system that require 
security are the:
     V2V communications (the medium, the messages/data, the 
certificates, and any other element that supports message exchange);
     V2V devices; and
     V2V security system itself (through organizational, 
operational, and physical controls).
    In addition to these requirements, the V2V system needs to be: (1) 
Ultimately scalable to meet the needs of over 350 million users across 
the nation (such as light vehicles, heavy vehicles, motorcycles, 
pedestrians, bicycles, etc.), (2) extendable to accommodate other types 
of applications (such as V2I mobility, traffic management, and 
environmental applications), and (3) financially sustainable to ensure 
its continued operation over time.
    In considering which security technologies would most effectively 
provide trusted message exchange and secure communications for safety-
critical applications, DOT and NHTSA, along with CAMP security experts, 
compared three different security approaches --symmetric encryption, 
group signature, and asymmetric public key infrastructure (PKI). When 
assessing these alternatives, the V2V research team was looking for an 
option that:
     Protects driver privacy appropriately by not requiring 
participants to disclose their identities;
     Works quickly enough to fit within the bandwidth 
constraints of DSRC and the expected processing constraints of the V2V 
on-board equipment;
     Does not require over-the-air bytes for security that 
exceed the constraints of DSRC bandwidth and size of the Basic Safety 
Message (BSM) in the message payload; and
     Supports non-repudiation.\1\
---------------------------------------------------------------------------

    \1\ Non-repudiation in public-key technology is traditionally 
defined as the inability of a person (to whom a public key has been 
bound by a recognized certification authority through issuance of a 
public key certificate) to deny having made some digital signature.
---------------------------------------------------------------------------

    After considering the characteristics of each security approach, 
the research development team preliminarily determined that the PKI 
option (asymmetric key) using the signature method offered the most 
effective approach to achieving communications security and trusted 
messaging for a very large set of users. For this reason, the research 
team chose that approach to secure the BSM that is at the center of the 
current V2V system design. Significantly, the effectiveness of this 
approach is highly dependent upon technical design decisions relating 
to how the approach is deployed in a given environment.

B. V2V Security Design Concept: Functions, Components, Communications

    Figure 1 presents the high level, basic components/functions of the 
V2V security system. They are similar to the basic functions of any 
Public Key Infrastructure (PKI) security system.

[[Page 61930]]

[GRAPHIC] [TIFF OMITTED] TN15OC14.000

    For reference, Table 1 contains a list of abbreviations used to 
describe the system discussed in more detail below:

                   Table 1--Security Related Acronyms
------------------------------------------------------------------------
             Acronym                             Definition
------------------------------------------------------------------------
BSM..............................  basic safety message.
CA...............................  certificate authority.
CME..............................  certificate management entity.
CP...............................  certificate policy.
CRL..............................  certificate revocation list.
DCA..............................  device configuration manager.
ECA..............................  enrollment certificate authority.
FIPS.............................  Federal Information Processing
                                    Standards.
LA...............................  linkage authority.
LOP..............................  location obscurer proxy.
MA...............................  misbehavior authority.
PCA..............................  pseudonym certificate authority.
PII..............................  personally identifiable information.
PKI..............................  public-key infrastructure.
RA...............................  registration authority.
SCMS.............................  security credential management
                                    system.
------------------------------------------------------------------------

    Figure 2 illustrates multiple security and privacy operations and 
components that DOT envisions for a V2V system to accomplish the 
distribution of certificates in a way that is trusted and that protects 
consumers' privacy. The fundamental operations are indicated as (1) 
Overall Management, (2) Registration and Enrollment, (3) Certificate 
Management and (4) Misbehavior Management. The text following this 
illustration contains definitions for each component.
BILLING CODE 4910-59-P

[[Page 61931]]

[GRAPHIC] [TIFF OMITTED] TN15OC14.001

BILLING CODE 4910-59-P
    The following discussion of SCMS functions focuses on 
communications and activities within the SCMS. The technical design for 
the SCMS includes several different operating functions that, together, 
make up the overall SCMS structure. It is envisioned that single or 
multiple operating functions

[[Page 61932]]

will be carried out by individual, legally distinct CMEs (including the 
SCMS Manager) that, together, will make up the SCMS organization. The 
agency is interested in respondents providing their views on potential 
structure of the entire SCMS organization, including the distinction, 
if one is needed, between separate components and responsibilities.
    That said, we note that the interaction between the components 
shown in Figure 2 is all based on machine-to-machine performance. No 
human judgment is involved in creation, granting, or revocation of the 
digital certificates. The functions are performed automatically by 
processors in the various V2V components, including the vehicle's on-
board equipment (OBE). The role of personnel within the SCMS is to 
manage the overall system, protect and maintain the computer hardware 
and facilities, update software and hardware, and address unanticipated 
issues.\3\
---------------------------------------------------------------------------

    \3\ The SCMS manager would establish policies and procedures 
that influence the configuration of the system parameters.
---------------------------------------------------------------------------

    Generally, these SCMS operating functions fall into two categories: 
``pseudonym functions'' and ``bootstrap functions,'' discussed further 
below. In order for the SCMS to support the security needs of the V2V 
system, the various SCMS functions (housed in different CME 
organizations) must work together to exchange information securely and 
efficiently.

C. Pseudonym Functions/Certificates

    The security design employs short-term digital certificates used by 
a vehicle's V2V device to authenticate and validate BSMs that are sent 
and received. Since these BSMs provide the information needed for V2V-
based safety warning technologies to operate, it is important that they 
are trustworthy. A valid certificate indicates the BSM was transmitted 
from a trusted source. A BSM with a revoked (invalid) certificate is 
ignored by other V2V devices. In order to protect privacy 
appropriately, these short-term certificates do not contain any 
information about the vehicles and their occupants (e.g., drivers/
occupants or vehicle make/model/VIN), but they serve as credentials 
that permit vehicles to participate in the V2V system.
    Pseudonym functions create, manage, distribute, monitor, and revoke 
short-term certificates for vehicles. They include the following 
functions:
     Intermediate Certificate Authority (Intermediate CA), 
which is an extension of the Root CA, shielding it from direct access 
to the internet. It can authorize other CMEs (or possibly an Enrollment 
Certificate Authority [ECA]) using authority from the Root CA, but does 
not hold the same authority as the Root CA in that it cannot self-sign 
a certificate. The Intermediate CA provides flexibility in the system 
because it removes the need for the highly protected Root CA to 
establish contact with every SCMS entity as they are added to the 
system over time. Additionally, the use of Intermediate CAs lessens the 
impact of an attack by maintaining protection of the Root CA.
     Linkage Authority (LA), which is the entity that generates 
linkage values. The LA comes in pairs of two, which we refer to as LA1 
and LA2, in order to further protect privacy. The LAs for most 
operations communicate only with the RA and provide values, known as 
linkage values, in response to a request by the RA (see below) and PCA 
(see below). The linkage values provide the PCA with a means to 
calculate a certificate ID and a mechanism to connect all short-term 
certificates from a specific device for ease of revocation in the event 
of misbehavior.
     Location Obscurer Proxy (LOP), which obscures the location 
of OBE seeking to communicate with the SCMS functions, so that the 
functions are not aware of the geographic location of a specific 
vehicle. All communications from the OBE to the SCMS components must 
pass through the LOP. Additionally, the LOP may shuffle misbehavior 
reports that are sent by OBEs to the MA (see below) during full 
deployment. This function increases participant privacy but does not 
increase or reduce security.
     Misbehavior Authority (MA), which acts as the central 
function to process misbehavior reports, as well as to produce and 
publish the certificate revocation list (CRL). It works with the PCA, 
RA, and LAs to acquire necessary information about a certificate to 
create entries to the CRL through the CRL Generator. The MA eventually 
may perform global misbehavior detection, involving investigations or 
other processes to identify levels of misbehavior in the system. The MA 
is not an external law enforcement function, but rather an internal 
SCMS function intended to detect when messages are not plausible or 
when there is potential malfunction or malfeasance within the system. 
The extent to which the CMEs share externally information generated by 
the MA about devices sending inaccurate or false messages--whether with 
individuals whose credentials the system has revoked, regulatory 
agencies or law enforcement--will depend on law, organizational policy, 
and/or contractual obligations applicable to the CMEs and their 
component functions.
     Pseudonym Certificate Authority (PCA), which issues the 
short-term certificates used to ensure trust in the system. In earlier 
designs their lifetime was fixed at five minutes. The validity period 
of certificates is still on the order of ``minutes'' but is now a 
variable length of time, making them less predictable and thus harder 
to track. Certificates are the security credentials that authenticate 
messages (BSM) from a device. In addition to certificate issuance, the 
PCA collaborates with the MA, RA, and LAs to identify linkage values to 
place on the CRL if misbehavior has been detected. Individual PCAs may 
be limited to a particular manufacturer or a particular region.
     Registration Authority (RA), which performs the necessary 
key expansions before the PCA performs the final ones. It receives 
certificate requests from the OBE (by way of the LOP), requests and 
receives linkage values from the LAs, and sends certificate requests to 
the PCA. It shuffles requests from multiple OBEs to prevent the PCA 
from correlating certificate IDs with users. It also acts as the final 
conduit to batching short-term certificates for distribution to the 
OBE. Lastly, it creates and maintains a blacklist of enrollment 
certificates so it will know to reject certificate renewal requests 
from revoked OBEs.
     Request Coordination, which is critical in preventing an 
OBE from receiving multiple batches of certificates from different RAs. 
The Request Coordination function coordinates activities with the RAs 
to ensure that certificate requests during a given time period are 
responded to appropriately and without duplication. Note that this 
function is only necessary if there is more than one RA in the SCMS.
     Root Certificate Authority (Root CA), which is the master 
root for all other CAs; it is the ``center of trust'' of the system. It 
issues certificates to subordinate CAs in a hierarchical fashion (as 
well as MA, LAs and RAs), providing their authentication within the 
system so all other users and functions know they can be trusted. The 
Root CA produces a self-signed certificate (verifying its own 
trustworthiness) using out-of-band communications. This enables trust 
that can be verified between ad hoc or disparate devices because they 
share a common trust point. It is likely that the Root CA will operate 
in a separate, offline environment because compromise of this function 
is a

[[Page 61933]]

catastrophic event for the security system.
     SCMS Manager, which is the function that will provide the 
policy and technical standards for the entire V2V system. Just as any 
large-scale industry ensures consistency and standardization of 
technical specifications, standard operating procedures (SOPs), and 
other industry-wide practices such as auditing, the SCMS Manager would 
establish SOPs, including in such areas as interoperability, security, 
privacy and auditing, and manage the activities required for smooth and 
expected operation of the SCMS. This could happen in a number of ways. 
Often in commercial industries, volunteer industry consortia take on 
this role. In other industries, or in public or quasi-public 
industries, this role may be assumed by a regulatory or other legal or 
policy body.
    Regardless of how the SCMS ``industry'' establishes and operates a 
central administrative body, it is expected that one will be 
established for the V2V SCMS. As no decisions about ownership or 
operation have been made, we do not advocate for public or private 
ownership of the CMEs that will make up the SCMS. Rather, in our 
discussions and analyses, we identify the basic functions that we 
expect the SCMS Manager will perform. The expectation is that the CMEs 
that make up the SCMS, either voluntarily or contractually, will agree 
to adhere to the SOPs, audit standards, and other practices established 
by the SCMS Manager. In accordance with input from DOT, the SCMS 
Manager will develop applicable guidance, practices, SOPs, auditing 
standards, or additional industry-wide procedures in coordination with, 
or so as to dovetail with Federal guidance or regulations applicable to 
V2V communications. NHTSA also assumes that the CMEs will endow the 
SCMS manager with authority to remove from the SCMS or revoke the 
``credentials'' of CMEs that misbehave or do not comply with applicable 
standards.

D. ``Bootstrap''/Initialization Functions/Enrollment Certificate

    The security design also includes functions that carry out the 
bootstrapping process, which establishes the initial connection between 
a V2V device and the SCMS. The chief functional component of this 
process is the Enrollment Certificate Authority (ECA), which assigns a 
long-term enrollment certificate to each V2V device.
    Initialization functions include:
     Certification Lab, which instructs the Enrollment CA on 
polices and rules for issuing enrollment certificates, i.e. device 
enrollment criteria. This is usually done when a new device is released 
to the market or if the SCMS Manager releases new rules and guidelines. 
The Enrollment CA uses information from the Certification lab to 
confirm that devices of the given type are entitled to an enrollment 
certificate. At this time, specific details regarding the Certification 
and Enforcement are not defined.\4\
---------------------------------------------------------------------------

    \4\ At this point, the extent and level of testing which the 
Certification Lab will actually perform is still to be determined. 
The role of the labs could range from simply managing a checklist of 
requirements to performing extensive technical certification tests, 
including: device performance, FCC compliance, cryptographic testing 
(at the level of FIPS-140), and/or interoperability testing. The 
intent is that the SCMS Manager, after it is created, will determine 
the full roles and responsibilities of the Certification Lab. 
Vehicle and device manufacturers may decide to rely in part on a 
certification lab to support their own certification of compliance 
with any relevant standards NHTSA may issue.
---------------------------------------------------------------------------

     Device Configuration Manager (DCM), which is responsible 
for giving devices access to new trust information, such as updates to 
the certificates of one or more authorities, and relaying policy 
decisions or technical guidelines issued by the SCMS Manager. It also 
sends software updates to devices. The DCM coordinates initial trust 
distribution with devices by passing on credentials for other SCMS 
entities, and provides a device with information it needs to request 
short term certificates from an RA. The DCM also plays a role in the 
bootstrap process by ensuring that a device is cleared to receive its 
enrollment certificate from the ECA. It also provides a secure channel 
to the ECA. There are two types of connections used from devices to the 
DCM: In-band and out-of-band communications. In-band communication 
utilizes the LOP, while out-of-band communication is sent directly from 
the device to the ECA, by way of the DCM.
     Enrollment Certificate Authority (ECA), which verifies the 
validity of the device type with the Certification Lab. Once verified, 
the ECA then produces the enrollment certificate and sends it to the 
OBE. Once the OBE has a valid enrollment certificate, it is able to 
request and receive certificates from the SCMS. Individual PCAs may be 
limited to a particular manufacturer or a particular region.

E. Privacy Considerations

    Risks to consumer privacy, whether actual or perceived, are 
intertwined with consumer and industry acceptance of V2V technologies. 
For this reason, privacy considerations are critical to the analysis 
underlying NHTSA's decision about how to proceed with regulation.
    At the outset, readers should understand some very important points 
about the V2V system as contemplated by NHTSA. The system will not 
collect or store any data on individuals or individual vehicles, nor 
will it enable the government to do so. There is no data in the basic 
safety messages broadcast by V2V devices or collected by the V2V 
security system intended to be used by law enforcement or private 
entities to personally identify a speeding or erratic driver.\5\ The 
system--presumably operated by private entities--will not permit 
tracking through space or time of vehicles linked to specific owners or 
drivers or persons. Third parties attempting to use the system to track 
a vehicle would find it extremely difficult to do so, particularly in 
light of far simpler and cheaper means available for that purpose. The 
system will not collect financial information, personal communications, 
or other information linked to individuals. It will enroll V2V enabled 
vehicles automatically, without collecting any information identifying 
specific vehicles or owners.
---------------------------------------------------------------------------

    \5\ Definition of the current basic safety message data elements 
is found in Table V-1 and Table V-2 of the agency's V2V research 
report, ``Vehicle-to-Vehicle Communications: Readiness of V2V 
Technology for Application V1.0 August, 2014''.
---------------------------------------------------------------------------

    The system will not provide a ``pipe'' into the vehicle for 
extracting data. While the system needs to enable NHTSA and motor 
vehicle manufacturers to find lots or production runs in the event of 
defective and/or non-compliant V2V devices, it will do so without use 
of VIN numbers or other information that could identify specific 
drivers or vehicles.
    There are two primary categories of V2V system functions that 
involve the transmission, collection, storage, and sharing of V2V data 
by, and between, the V2V system components and other entities: system 
safety and system security.
    The V2V system's safety functionality (i.e., the safety 
applications that produce crash warnings) requires that V2V devices 
broadcast and receive a basic safety message containing information 
about vehicle position, heading, speed, and other information relating 
to vehicle state and predicted path. The BSM, however, contains no 
personally identifying information (PII) and is broadcast in a very 
limited geographical range, typically less than 1 km. Nearby devices 
installed in other vehicles will use that information to warn drivers 
of crash-imminent

[[Page 61934]]

situations. Except as necessary to identify devices in the case of 
malfunction, the system will not collect, and motor vehicles will not 
store, the messages or data that are sent or received by V2V devices.

F. Device Non-Compliance and Potential Recalls

    Currently, as discussed in the report, NHTSA may need to conduct 
further research into how to ensure that all V2V devices subject to a 
recall can be identified, and that owners can be notified about the 
issue and be provided instructions for how to remedy a potential 
condition. Section VIII.B.3 of the agency's V2V research report 
discusses the possibility that for vehicles manufactured with V2V 
devices installed, the SCMS may be able to create a link at the time of 
manufacture between specific installed V2V devices or production lots 
of devices and enrollment certificates that later may help vehicle 
manufacturers and NHTSA identify defective V2V equipment, potentially 
linking device batches to enrollment certificates. However, it is not 
yet clear how such a linkage would be created for V2V devices that are 
not installed by the manufacturer. The agency welcomes discussion from 
respondents on the potential approach discussed in the report along 
with other potential approaches, based on a respondent's experience, 
which NHTSA may employ to fulfill its defect and non-compliance 
identification responsibilities.
    The security needs of the V2V system require the exchange of 
certificates and other communications between: (1) V2V devices and (2) 
the entity or entities providing security for the V2V system (i.e., the 
Security Credential Management System). These two-way communications 
are encrypted and subject to additional security measures. These 
measures are designed to prevent SCMS insiders and others from 
unauthorized access to information that might enable linkage of BSM 
data or security credentials to specific motor vehicles.
    NHTSA also needs to ensure that the V2V system is protected from 
defective and non-compliant devices. In order to do so, the V2V 
security system will likely need to collect and share with 
manufacturers, such that they can comply with Federal regulations, on a 
very limited basis, some V2V data linking V2V device production lots to 
security credentials. However, as currently envisioned, neither the V2V 
system nor NHTSA will collect, store, or have access to information 
that links production lots of defective V2V devices with specific VINs 
or owners.
    NHTSA and the DOT take privacy very seriously. If NHTSA moves 
forward with regulating V2V technologies, we are committed to doing so 
in a manner that both protects individual privacy appropriately and 
promotes this important safety technology.

V. SCMS Organizational Options

    The above discussion of SCMS functions focused on activities and 
communications within the SCMS. The current section discusses the DOT 
research performed by Booz Allen Hamilton (BAH), with input from CAMP 
and the Vehicle Infrastructure Integration Consortium (VIIC), on the 
development of an SCMS organization. The purpose of BAH's research was 
to generate organizational options for an SCMS capable of enabling 
secure and efficient communications, protecting privacy appropriately, 
and minimizing operational costs. BAH developed a number of different 
organizational options by grouping the SCMS functions in CAMP's design 
into legally/administratively distinct entities. BAH's analysis of the 
organizational options for the SCMS, detailed below, focused primarily 
on organizational connections and separations, as well as the closely-
related process of characterizing functions as ``central'' or ``non-
central'' (which is intimately tied to the issue of system ownership 
and operation). It also examined the cost, security risk, and 
operational/policy implications of the different SCMS models.
    BAH began by identifying multiple organizational models that, 
together, captured all possible configurations of the SCMS functions 
identified by CAMP. DOT initially selected a small number of these 
organizational models for BAH to further consider. As CAMP's technical 
design evolved, DOT instructed BAH to reconfigure the models to reflect 
additional SCMS functions added to the SCMS design by CAMP, as well as 
CAMP's new categorization of functions as either ``central'' or ``non-
central.'' Based on its independent PKI research, as well as new 
insights into the security design communicated by CAMP, BAH then 
simplified the initial organizational design proposed by CAMP to remove 
certain organizational separations of functions that BAH determined 
were not necessary for security or privacy reasons.
    Ultimately, the organization of the SCMS--the final grouping of 
functions and estimates of any efficiencies--will be controlled by the 
organization(s) that manage the SCMS and own and operate the component 
CMEs. However, NHTSA and DOT anticipate being able to influence the 
organization and operation of the SCMS (and thereby ensure adequate 
separation to assure secure, privacy-appropriate V2V communications) 
through an agreement or MOU with the SCMS Manager and/or through 
participation on a SCMS ``governance board.''
    BAH's SCMS organizational model/analysis, Figure 2, is based on 
CAMP's current SCMS technical design and represents BAH's perspective 
of how functions within the SCMS may be grouped.

[[Page 61935]]

[GRAPHIC] [TIFF OMITTED] TN15OC14.002

    Organizational separation of functions is an example of a policy 
control often used to mitigate privacy risks in PKI systems--but such 
separations come with increased costs and may negatively impact the 
system's ability to identify and revoke the credentials of misbehaving 
devices. Ultimately, more than one function may be co-located within 
the same SCMS component organization. However, grouping of SCMS 
functions and any resulting efficiencies/risk trade-offs will depend, 
in large part, on: (1) The system's ownership, operational structure, 
and governance in accordance with DOT, and (2) the preferences of the 
entity or entities that own and operate the SCMS Manager and CME 
component entities.
    The SCMS Manager is intended to serve as the entity that provides 
system management, primarily by enforcing and auditing compliance with 
uniform technical and policy standards and guidance for the SCMS 
system-wide. The uniform standards/guidance will need to establish and 
ensure consistency, effectiveness, interoperability, and appropriate 
security and privacy protection across the CMEs, in order to facilitate 
necessary communications, sharing of information, and operational 
connections. The SCMS Manager will need to have mechanisms to ensure 
that all CME entities have policies, practices, technologies, and 
communications consistent with system-wide standards and guidance. The 
SCMS Manager may (but need not) be the body that develops the 
standards, guidance, or policies applicable system-wide; however, it 
would be the entity charged with overseeing standards and policy 
compliance by the CME entities that, together with the SCMS Manager, 
make up the SCMS. The agency anticipates existing PKI technical 
standards and industry best practices likely will form the basis for 
many of the policies and procedures applicable across the SCMS.\6\
---------------------------------------------------------------------------

    \6\ BAH SCMS Design and Analysis Report, at 29.
---------------------------------------------------------------------------

VI. The Legal Relationship Between NHTSA and the SCMS

    As currently envisioned by NHTSA, deployment of V2V technologies 
requires existence of an SCMS to provide necessary security functions. 
In its February 3, 2014, announcement, NHTSA expressed its intent to 
begin working on a regulatory proposal to require V2V devices in new 
motor vehicles in a future year, and on August 18, 2014, NHTSA 
announced an advance notice of proposed rulemaking to start the 
regulatory process for V2V technology. A subsequent NHTSA V2V 
regulatory proposal, a notice of proposed rulemaking (NPRM), 
potentially could extend to many aspects of the hardware, software, and 
communications, making up significant parts of the V2V system. However, 
NHTSA, at this time, anticipates that establishment of the SCMS itself, 
which will provide security services necessary for secure reliable V2V 
messaging within the V2V system, will not be encompassed in its 
regulatory proposal. Instead, as discussed elsewhere in today's RFI, 
NHTSA envisions that constitution and operation of the SCMS will be 
undertaken by one or more private entities, working collaboratively 
with NHTSA. NHTSA and DOT do not currently envision the Federal 
government being the owner or operator of the SCMS.
    There is a wide range of collaborative relationships that NHTSA 
potentially could enter into with the private entity or entities that 
manage or make up the SCMS. The overarching goal of the relationship(s) 
would be to ensure the existence and operation of an SCMS needed to 
support the V2V system in a

[[Page 61936]]

way that appropriately protects consumer privacy and system security 
and does not impose inordinate costs on OEMs, vehicle drivers, or 
others. Ultimately, the nature and scope of the relationship(s) will 
turn on the specific terms upon which the parties agree.
    Section IV of the research report contains discussion of the 
agency's authority to enter into agreements documenting the 
collaborative relationship between NHTSA and the private entity or 
entities that constitute and operate the SCMS supporting V2V 
communications. As discussed for the first time in this RFI, such an 
agreement would likely address or provide minimum requirements in the 
following areas:
     Service Period: How long the entity or entities would 
commit to ensuring availability of security services required to 
support the V2V system;
     Organization: Legal/administrative separation between, and 
the legal relationship among, CMEs that make up the SCMS;
     Operation: Certificate, security, privacy, audit, 
interoperability, and related operational policies;
     Governance: Initially, and on an ongoing basis, 
transparent mechanisms for obtaining input on issues relevant to SCMS 
constitution and operation from (1) the CMEs that make up the SCMS and 
(2) other stakeholders;
     System Access: To ensure support for V2V, V2I, and V2X 
applications and users (consumers and manufacturers) in the U.S., 
Canada and Mexico;
     Fees: Service and user classes for V2V, V2I, and V2X users 
(consumers and manufacturers);
     Privacy: Controls, enforcement, reporting (internal and to 
NHTSA), and data policies that provide clear notice to consumers of 
(among other things) what data is being collected, how it is used, and, 
for opt-in services, giving consumers control over access to their 
data;
     Security: Controls, enforcement, and reporting (internal 
and to NHTSA);
     Continuity of Operation: Procedural mechanisms to ensure 
continued support for the V2V system;
     Liability/Insurance: Liability and business interruption 
insurance;
     Cooperation: Procedures for working with Federal and State 
law enforcement and consumer fraud authorities to address any issues 
that threaten the system's safety or security.

VII. Specific Questions for This Notice

    Specific questions posed in this notice follow. Respondents are 
reminded that feedback on any aspects of this notice is welcome from 
all interested public, private, and academic entities. If your 
responses relate to how NHTSA should implement a requirement for V2V, 
and the agency's authority to require V2V, rather than to the SCMS 
issues outlined in this notice, please submit such responses as 
comments to the rulemaking docket for the ANPRM (NHTSA-2014-0022) 
rather than this docket. While all feedback regarding the agency's 
regulatory announcements and the ANPRM is welcome from all parties, 
NHTSA is particularly interested, regarding this request for 
information, in hearing from those entities interested in establishing 
an SCMS. Respondents may respond, to some, all, or none of these 
specific questions:
    1. SCMS ownership and operation are inextricably linked to SCMS 
governance. DOT research to date has focused on the likelihood of 
private ownership and operation of the SCMS ``industry,'' with 
governance being largely ``self-governance'' by private industry 
participants and stakeholders. Other basic organizational models that 
could apply, besides this private model, are: public, and public-
private. What model is most appropriate and what are the risks, if any, 
associated with a private ``self-governance'' approach and how would 
you mitigate them?
    2. The SCMS has many functions that are needed to establish the 
trusted environment required for V2V communications. The SCMS consists 
of both central and non-central functions to be carried out by legally 
distinct CMEs that can be owned and operated by various individual 
entities. What is your interest in helping to establish an SCMS? Which 
SCMS functions are you most interested in performing, either on your 
own or as part of a larger consortium? What information or other 
resources do you need to initiate planning, development, and 
implementation of the identified SCMS functions? The agency would also 
appreciate respondents providing potential lead times associated with 
standing up an SCMS and making it fully operational to support a 
national implementation of V2V technology, because lead time will help 
the agency understand when V2V technology could potentially be rolled 
out most successfully.
    3. In relation to the SCMS Manager function, will the establishment 
of either a binding or non-binding ``governance board'' provide the 
appropriate level of stakeholder guidance and direction to facilitate a 
viable and self-sustaining business entity? If not, why not, and what 
additional or other type of governance or oversight might be needed?
    4. In order for the SCMS to function, what standards and policies 
applicable to individual CMEs will need to be developed and 
implemented? Who do you envision will establish the various standards, 
policies, procedures, auditing processes, and other related industry-
wide processes?
    5. NHTSA and DOT anticipate being able to influence the 
organization and operation of the SCMS (and thereby ensure adequate 
separation to assure secure, privacy appropriate V2V communications) 
through some type of agreement with the SCMS Manager or through 
participation on an SCMS ``governance board.'' In the ``Legal 
Relationship between NHTSA and the SCMS'' section of this Request for 
Information, we identify some likely components of an agreement between 
NHTSA and the SCMS Manager or entities making up the SCMS. Are there 
other components that such an agreement should cover? If so, please 
identify them and explain their importance. If the SCMS established a 
``governance board,'' how should the board be constituted? Should the 
board's decisions be binding on the SCMS? Typically, NHTSA and other 
Federal government entities participate as non-voting liaisons or ex 
officio members of private boards (NHTSA, for example, regularly 
assigns agency employees to be non-voting liaisons on Society of 
Automotive Engineers (SAE) and Transportation Research Board (TRB) 
Committees and Boards). Would it be viable for NHTSA to participate in 
this manner?
    6. The agency asks respondents to provide their projections of 
initial capital investment for SCMS functions overall and components 
they may potentially be interested in ``standing up'' and supporting.
    7. Additionally, the agency welcomes feedback on how respondents 
envision SCMS financial sustainability and its relation to any data 
collection or fees, if any, that would be permitted under the agreement 
with DOT.
    8. If you are interested in performing certain functions related to 
the SCMS, explain how you would ensure that privacy concerns are 
addressed in performance of those functions.

    Authority:  49 U.S.C. 30101 et. seq.; 49 CFR 1.95.

    Issued in Washington.
Daniel C. Smith,
Senior Associate Administrator for Vehicle Safety.
[FR Doc. 2014-24482 Filed 10-14-14; 8:45 am]
BILLING CODE 4910-59-P