Digital signature from a certificate authority

    When a nearby device receives a properly formed BSM, it can use the
certificate included in the BSM to verify that the digital signature in
the BSM is valid. Furthermore, the receiving device can also verify
that the security certificate included in the BSM is valid as well. The
receiving vehicle can verify that digital signature on the certificate
included in the BSM is digitally signed by the certificate authority
that issued it to the sending device. The receiving device should
already have a copy of the authorizing certificate for the authority
stored on-board. In the event that it does not, the receiving device
would need to request the authorizing certificate from the sending
device. Once the authorizing certificate is obtained, the receiving
device can verify that the certificate authority is valid and the
certificate used to sign the BSM is also valid. This process can be
repeated for any number of certificate authorities that are in the PKI
hierarchy, up to the root certificate authority, which authorizes the
entire system. This process allows receiving devices to verify a
sender's credentials. For detailed information on the proposed Security
Credential Management System, see Hehn, T., et al., ``Technical Design
of the Security Credential

Management System'', 2014, Docket No. NHTSA-2015-0060-0004.
    The SCMS organization certifies that a device is indeed authorized
to participate in the V2V environment and then issues credentials to
the device. Thus, a receiving device can have more confidence in the
information contained in a BSM message because it knows that the SCMS
previously confirmed the sender is an approved device and issued these
credentials.
    In addition to the SCMS device certification, a device also needs
to properly sign the basic safety message. The following sections
discuss how the device utilizes the certificates from the SCMS and how
the agency can confirm that devices are doing so.
(a) Signing the Basic Safety Message for Transmission
    The process for signing the basic safety message involves the use
of two ``keys,'' one public and one private. \151\ The signature
process uses the private key and an original string of numbers as
inputs to generate an encoded string of numbers (an otherwise
meaningless set of numbers). The public key associated with that
private key is then used by the signature verification process to
reverse the signature process (i.e., take the encoded string of
meaningless numbers and reverse it to generate the original string of
numbers). Therefore, the receiving device takes the information from
the sending device and (using the characteristics of these equations)
can verify the signature of the sender.\152\
---------------------------------------------------------------------------

    \151\ The V2V device generates the private key & public keys.
The public key is sent to the SCMS to incorporate into a certificate
that is signed by the PCA. The private key is always kept secret
with the V2V device. The private key is vital to the signing process
and must be kept secured at all times.
    \152\ See ``Using the Elliptic Curve Digital Signature Algorithm
effectively'' http://www.embedded.com/design/safety-and-security/4427811/Using-the-Elliptic-Curve-Digital-Signature-Algorithm-effectively, Feb. 2, 2014 (last accessed Dec 7, 2016).
---------------------------------------------------------------------------

    The agency employed this signing process in V2V devices used
throughout its research activities and was proven through the Safety
Pilot Model Deployment activity. Devices in these activities have been
signing the basic safety message and constructing the security
credentials of the message by combining the message content with the
certificate, the signature, and the time stamp of the information.
    Table III-4 shows how the public key, private key, and signature
fit together with the other parts of the basic safety message.

                                Table III-4--Basic Safety Message Key Components
----------------------------------------------------------------------------------------------------------------
             Certificate                   Message content             Signature                Timestamp
----------------------------------------------------------------------------------------------------------------
Pseudonym Certificate
 Public Key..................  (i.e., the speed,        Produced from the        (i.e., when the
 Signature of the Pseudonym     heading, location,       following steps:         information is
 Certificate Authority.                 etc. information that    Compute hash     transmitted.]).
Validity Period......................   supports the safety      of the Message Content
 Says when certificate          applications).           and Timestamp.
 effective and when expires.                                     Use your
                                                                 private key to create
                                                                 an encoded string of
                                                                 numbers.
                                                                 The encoded
                                                                 string of numbers is
                                                                 your signature.
----------------------------------------------------------------------------------------------------------------

    When the transmitting device sends a basic safety message it
assembles each of the parts of the message in Table III-4 above. The
vehicle uses a combination of the message content, timestamp, and a
private key to generate the signature. The device also attaches the
certificate to the message. The certificate includes the public key,
corresponding to the private key used to sign the message, the validity
period of the certificate, and the signature from the Pseudonym
Certificate Authority. The pseudonym certificate contains the signature
of the PCA from the SCMS allowing message receivers to verify the
pseudonym certificate. The validity period is used to determine if the
certificate is valid or if the receiving device should reject the
credentials if they are expired.
    The vehicle constructs the signature by using the message content
and the time stamp portions of the message as inputs into the following
process:
    (a) Create a hash \153\ of the message content and timestamp (i.e.,
a shortened version of the message content/time stamp that is fixed
length--e.g., 32 characters). A standard NIST formula (SHA-2) \154\
governs the creation of the hash.
---------------------------------------------------------------------------

    \153\ A hash function is any function that can be used to map
data of arbitrary size to data of fixed size. The values returned by
a hash function are called hash values, hash codes, hash sums, or
simply hashes.
    \154\ See ``Secure Hashing'' http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html (last accessed Dec 7, 2016).
---------------------------------------------------------------------------

    (b) Input the hashed contents through an Elliptical Curve Digital
Signature Algorithm \155\ (the equation that creates the encoded string
of numbers). The resulting number is the ``digital signature.''
---------------------------------------------------------------------------

    \155\ See FIPS publication 186-4 at ``FIPS Publications'' http://csrc.nist.gov/publications/PubsFIPS.html (last accessed Dec 7,
2016).
---------------------------------------------------------------------------

(b) Verifying the Signature Upon Receipt
    A device receiving the basic safety message performs the following
sequence of steps in order to verify the signature:
    (a) Generate the hash of the basic safety message content and
timestamp using the same NIST defined formula used for generating the
signature.
    (b) Input the message hash, public key, and digital signature into
the signature verification function (ECDSA) to verify the BSM digital
signature is valid.
    (c) Verify the pseudonym certificate (from the sending device) is
within the validity period.
    (d) Verify the digital signature of the pseudonym certificate back
to the root certificate authority ensuring the SCMS issued the
credentials.
    (e) Verify the pseudonym certificate is not listed on the
Certificate Revocation List.

[GRAPHIC] [TIFF OMITTED] TP12JA17.009

    As discussed in the next section, the agency is considering a
potential test method that would mimic many of the functions of the
receiving device in order to assess whether devices are properly
signing their messages with valid credentials when they are
transmitting basic safety messages.
(2) Potential Requirements and Testing for Message Signing and
Authentication
    The agency is currently considering evaluating a device's ability
to properly sign the basic safety message by utilizing a test device to
receive basic safety messages during a static test. The test device
would perform the key functions described above to verify the
authenticity of the sender and of the message. Following is discussion
of the general testing framework and the potential performance
requirements that the agency is considering within the context of such
a test.
(a) Potential Message Authentication Test Method
    The agency currently envisions testing message authentication for
compliance as executing a message security and signage protocols test
in a static test environment (i.e., a ``security credentials test'').
The test would be conducted using a vehicle resident V2V device and an
agency developed test device positioned in close proximity to each
other.
    In effort to replicate real-world conditions, the agency's current
strategy is to define a test device that can perform the following
functions as described in SAE J2945/1 v1.0 \156\ (which itself
references specific clauses and sections of relevant IEEE P1609 and
802.11 standards).
---------------------------------------------------------------------------

    \156\ See ``On-Board System Requirements for V2V Safety
Communication'' at http://standards.sae.org/j2945/1_201603/ (last
accessed Dec 7, 2016).
---------------------------------------------------------------------------

     If the full pseudonym certificate is included in the BSM,
then the device will need to extract the public key from the pseudonym
certificate of the test vehicle.
     If the certificate digest (hash of the full certificate)
is included in the BSM, then the device will need to perform a look-up
in cached memory of the full certificate and then extract the public
key from the pseudonym certificate of the device under test.
     Confirm that the public key and the credentials in general
are indeed from the SCMS (i.e., verify the pseudonym certificate
authority all the way up to the root certificate authority).
     Use the public key to verify the signature section of the
basic safety message (i.e., execute the ECDSA verification algorithm).
    In terms of specific procedures, we tentatively believe that using
many of the test conditions from our static test evaluating the
transmission range and content of the basic safety message would be
appropriate. In essence, we believe that the same test could be used to
also evaluate whether the vehicle is appropriately signing its basic
safety messages. Tentatively, we believe that including the following
additional step in the static test would be sufficient to evaluate this
area of performance.
     Collect basic safety messages from a transmitting device
for at least 100 minutes and repeat the test at least seven days
later.\157\
---------------------------------------------------------------------------

    \157\ As discussed later in this section, the timeframes for
this test accommodate our current proposal for changing
certificates.
---------------------------------------------------------------------------

     Using the messages collected in this test, the agency's
test device should be able to verify the device under test is properly
signing the basic safety message.

     The data collected should also reveal that the device
under test is sending the required certificate (from the pseudonym
certificate authority) or the certificate digest.
     The agency's test device should also be able to determine
whether the device under test is using credentials issued by the
appropriate authority (i.e., is the root certificate ultimately one
that is authorized by the SCMS?).
     Finally, the test duration timeframes of this additional
step should enable our test device to determine whether the vehicle is
changing its certificates at the required interval.
    We request comment on this test method and commenter's input on a
potential test device that could be used to execute this proposed test
schema. Would a test device that performs all of the functions outlined
above sufficiently mimic real world conditions and also define those
conditions sufficiently to achieve a repeatable test method? What other
details should the agency explore and define? Are there other test
methods that the agency should consider that can confirm that the
transmitting vehicle signs the basic safety message properly with a
less complex test?
    The agency is also proposing to adopt a static test to evaluate the
transmission range and other requirements (see Section III.E.1.a)). As
testing experienced is gained, it may prove more efficient to combine
the security credential, RF transmission, and possible other tests. The
agency invites comment on the potential to combine and streamline test
where possible.
(b) Signing the Message
    Using the potential test method described in the previous section,
we believe the agency would be able to verify that V2V devices are
properly signing their basic safety messages, authenticating themselves
as accurate sources of information. In essence, by using a test device
that would be able to verify the digital signature using the ECDSA
algorithm, the proposed test schema confirms that:
     The sending device produced the correct hash of the
message content/timestamp;
     the sending device appropriately sent its pseudonym
certificate; and
     the public key could decode the signature created by the
sender's private key.
    By comparing the hash created by our test device to the hash
decoded from the basic safety message we received from the device under
test, our test procedure should be able to confirm the device under
test is correctly signing the basic safety message. Further, we
anticipate that the test device would also identify the root
certificate authority and validate up to the root certificate
authority.
(c) Certificates and Certificate Digests
    The agency is considering including requirements to reduce the size
of the basic safety message by requiring that vehicles not transmit
parts of the basic safety message when they are not necessary. In
theory, this could potentially conserve bandwidth in higher volume
scenarios. The pseudonym certificate included in the basic safety
message is an area under evaluation where message size could be
reduced.
    A receiving V2V device requires pseudonym certificates to decode
the signature and confirm the identity of the sender. However, the
agency does not anticipate that every message will need to carry the
full certificate as the pseudonym certificate does not change for every
message. This allows a period of time where the same certificate and
potentially allowing for messages to only part of the entire pseudonym
certificate. Therefore, the agency believes it would be appropriate,
under certain circumstances, for devices to transmit a certificate
digest which would be a hash of the full certificate.
    A potential challenge to this approach is requiring a receiving
device to support capture and storage of full certificates and
certificate digests, as transmitting only a digest necessitates
relating the digest to a full certificate. In addition to the capture
and storage of certificates, the agency is also evaluating a potential
requirement for the interval between the transmission of a full
certificate and certificate digests. Current research suggests that the
vehicle should transmit the full certificate twice per second and the
digest the remaining times. However, if there is an event flag (e.g.
hard braking event) in the BSM, the agency believes the full
certificate should be transmitted at the next immediate opportunity. At
this time our current proposed requirements do not cover this aspect of
the device and but the agency requests comment concerning the need to
employ certificate digests in place of the entire certificate.
    We tentatively believe that a final rule on V2V would need to
establish at least a minimum interval for transmitting the full
certificate so that surrounding vehicles will know the maximum amount
of time that they will need to wait in order to be able to confirm the
identity of a transmitting vehicle. Without such a requirement, we
question whether the standard would be able to ensure that vehicles
transmitted their pseudonym certificate at a sufficient frequency to
support the safety applications that other vehicles may use. However,
we request comment on whether a minimum requirement for transmitting
the full certificate is necessary. If so, what the minimum time should
be and whether a maximum time (or a specified interval such as 1 time
per second) would be appropriate for this aspect of performance.
    Thus, for this aspect of performance, our final performance
requirements could specify minimum (and potentially maximum) times for
transmitting the full certificate and requirements for what types of
information need to be in the certificate digest. Thus, in addition to
the testing method that we described above, our test device for that
test method would also need to ensure that:
     The vehicle is transmitting the full certificate at the
required interval;
     the vehicle is transmitting the certificate digest (which
identifies the full certificate and when the full certificate was
transmitted with all other messages that do not have the full
certificate; and
     the certificate or digest transmitted along with a basic
safety message is valid (i.e., it is a valid certificate issued by the
SCMS/has the appropriate credentials from the root certificate
authority).
(d) Changing Certificates and Privacy
    As part of the process of signing a V2V message using the proposed
SCMS approach, a vehicle could use a single certificate that is valid
for a long period of time (e.g., years) to sign all basic safety
messages that it transmits. This would help ensure that safety
applications would be able to differentiate between authenticated
sources of information and other less reliable sources of information
when making judgements about their surroundings.
    However, this approach could create additional privacy risk for
consumers, as use of a single certificate could enable an observer
collecting V2V transmissions to associate the basic safety messages
coming from a single V2V device with a single sender. While associating
a group of messages with a specific driver would need additional
information outside of the V2V system, additional information would not
be needed to know that all messages using the same certificate come
from the same vehicle. To help mitigate this risk, we propose that
vehicles frequently change or rotate certificates so that it will be
more difficult to associate a large

number of basic safety messages with the same V2V device or vehicle.
Also, we are proposing that certificates not be valid for long periods
of time to reduce the risk that they be collected and used to identify
a specific vehicle at a future date and time.
(i) Current Research on Changing Certificates
    Recent research evaluated several models for changing certificates.
In the Safety Pilot Model Deployment, certificates had a validity
period of 5 minutes and were completely discarded after use. Changing
certificates on a more frequent basis helps to minimize potential
privacy risk for individuals, it requires a large volume of
certificates for a vehicle to manage, approximately 100,000
certificates for one year of operation. Model Deployment researchers
determined that this approach would be inefficient as the majority of
the time a vehicle is not in operation but certificates were still
expiring even when the vehicle was not in operation. Based on the
experiences learned from this project, the researchers developed a more
efficient design where a vehicle will have 20 valid certificates per
week and changes certificates at least once every 5 minutes. Under this
design, only 1,050 certificates would be needed per year. This is
believed to strike a balance between privacy and efficiency by using
certificates that rotate every five minutes and are valid only for one
week. This alternative certificate usage model is currently under
development and will be tested in the field as a part of the SCMS
Proof-of-Concept projects.
(ii) Potential Performance Metric
    We recognize that methods of changing certificate credentials exist
on a spectrum between the competing interests of maximizing privacy
protections and technological practicability. For example, it would
afford the most privacy protection for consumers to use a different set
of credentials with every basic safety message (i.e., change
certificates 10 times per second). However, this would be impracticable
because it is unreasonable to expect the SCMS to produce enough
certificates to service all V2V devices when they use ten new
certificates every second.\158\ On the other hand, using the most
technically simplistic method for authenticating the sender of the
message would be to use one set of credentials for every message.
However, as we described above, that would create significant privacy
risk by associating all basic safety messages sent from a single source
with each other.
---------------------------------------------------------------------------

    \158\ A certificate is expected to be 117 bytes. The number of
unique certs/year * size of one certificate. (103680 * 117 = 12.13MB
for one vehicle for one year). *300 million vehicles =
3,639,168,000,000,000. Or 3.6 exabytes.
---------------------------------------------------------------------------

    In order to balance these competing interests, our tentative
conclusion is that the current method for changing certificates used in
the research would be a reasonable compromise that protects privacy in
a technically feasible way. By rotating among 20 certificates every
five minutes, we are ensuring that no group of basic safety messages
will be linked to more than 5 minutes of other safety messages at a
time. In other words, a person obtaining basic safety messages from a
device may not be able to associate those messages with each other
because their certificate is only used for 5 minutes out of every 100
minutes. Further, a device shutting off at one particular location
would unlikely use the same certificate upon startup. Finally, in order
to ensure that a person could not obtain all 20 certificates for a
particular device, we are proposing for devices to completely discard
their certificates each week and replace them with 20 new certificates.
    We request comment from the public on our proposed method for
changing certificates and privacy concerns. Have we appropriately
balanced the privacy interest with the interest in maintaining the
technical feasibility of producing and storing certificates in
vehicles? Is periodically rotating certificates the right approach to
limiting the privacy impact of having signed messages? Have we
established the appropriate thresholds for the method for changing
certificates (i.e., have we selected the correct duration for when
devices need to rotate certificates and change the certificates to new
ones altogether?). Further, should the agency establish requirements
for rotating the 20 certificates (i.e., should the device rotating
among 20 certificates every five minutes use the same order for
rotating through the certificates or should the device use a different
order the next time it cycles through the 20 certificates? What method
should the agency choose for changing the cycling order of the 20
certificates?).
(iii) Test Method
    As we discussed in Section III.E.3.b)(2)(a), our static test method
for assessing whether a device is appropriately signing their basic
safety messages can also assess whether a device is changing its
security credentials as required if our test lasts for an appropriate
amount of time. Based on our proposed requirements, we believe that it
is appropriate to test the device for 100 minutes twice, separated by 7
days.
    Testing the device for a 100 minute duration would sufficiently
assess whether the device is rotating certificates every five minutes
and using a different certificate every five minutes for the duration
of 100 minutes (i.e., 20 certificates x 5 minutes per certificate).
Finally, conducting this test twice (separated by 7 days) would allow
the test to confirm whether the device is using 20 new certificates
that are different from the certificates the device used in the first
test.
(e) Preventing Message Transmission Without Valid Certificates From a
SCMS
    The agency is also considering whether to require that devices stop
transmitting basic safety messages if they lack valid security
credentials, i.e. device transmission problems or being identified as a
misbehaving device. The purpose would be for devices to avoid sending
basic safety messages due to incorrect credentials. However, at this
time, the agency does not have performance requirements or a test
method for assessing this aspect of performance. In order to test this
aspect of performance, the agency would need a method for exhausting
the certificate supply of a vehicle and observing whether the vehicle
would continue to transmit basic safety messages. We request comment on
whether there is a practicable and repeatable way for producing these
conditions in a vehicle under test. We also request comment as to
whether this aspect of performance should be included in the final
rule.
(3) Potential Regulatory Text for SCMS Based Message Authentication
    The agency has included no regulatory text for SCMS-based message
authentication and instead has a bracked placeholder for where it would
be if this were to be part of a final rule. The agency expects that
regulatory text in any final rule would include:
     Additional definitions in S.4 Definitions for '' SCMS-
based message authentication, which would be consistent the discussion
in this proposed rule and any public comments.
     A provision on signing the BSM, which would require that
the device must generate a signature for each BSM.
     A provision on rotating certificates.
(c) Alternative Approach--Performance-Based Message Authentication
(1) Overview
    The agency is also bringing forth potential alternatives to the
SCMS-based

proposal for V2V message authentication. This first alternative takes a
far less prescriptive approach to authentication and defines a
performance-basedbased approach but not a specific architecture or
technical requirement for message authentication. The basis of this
alternative is to let V2V device implementers define their own approach
for improving the integrity and authenticity of V2V messages.
    The fundamental approach to this first alternative only requires
that the receiver of a basic safety message be able to validate the
contents of a message such that it can reasonably confirm that the
message originated from a single valid V2V device, and the message was
not altered during transmission. This alternative would broadly require
that implementations utilize government-audited and approved
cryptographic algorithms, parameters, and approaches.
(2) Illustrative Example
    For illustrative purposes, consider the following example technical
implementation. The sender of a BSM could use a security certificate
issued by a certificate authority to digitally sign each BSM. The
security certificate could be composed of the following elements:

 A date range describing the validity period for the
certificate
 A Public key corresponding to a private key
 Digital signature from a certificate authority
(3) Potential Requirements Under This Alternative
(a) Test Method and Test Device
    This alternative's less prescriptive approach for message
authentication results in a general testing requirement that would
similar in context as the proposed PKI based authentication but leaves
the extent of the proposed requirement undefined, or yet to be defined,
static test procedures. This approach is inherently aligned with
recognizing that potential future communication and their potential
message authentication needs would be varied and, therefore, requires
varied test methods for message signing and authentication.
    NHTSA seeks comment on potential test methods and the test devices
that could accommodate other, future, or yet-to-be-developed message
signing and authentication schemas that could be applied to V2V
communications. The agency is interested in details on how a test
device could fulfill the general requirement to sufficiently reflect
real-world conditions and also define those conditions sufficiently to
achieve a repeatable test method that ensure verified communications
between V2V devices, using varied communication mediums? What other
details should the agency explore and define? Are there other test
methods that the agency should consider that can confirm that a
transmitting V2V device signs the basic safety message properly?
(d) Alternative Approach--No Message Authentication
    This second potential alternative set out for comment does not
specify any message authentication requirements for devices
participating in a V2V communications. Under this second potential
alternative, BSM messages would still need to be validated with a
checksum or other integrity check and employ some form of through a
misbehavior detection system to attempt to filter malicious or
misconfigured messages. However, there would be no specific message
authentication requirement. Implementers would be free to include such
a feature as an optional function. The agency would not establish any
performance requirements or test procedures under this potential
alternative. The agency seeks comment on this no message authentication
approach.
4. Misbehavior Reporting
(a) Proposal--Misbehavior Reporting to a SCMS
    NHTSA is proposing to establish practices and procedures for
devices participating in V2V communications to recognize device
misbehavior, both internally and by other devices. The fundamental
purpose of misbehavior detection is to provide a means for V2V devices
to identify and block messages from other misbehaving or malfunctioning
V2V devices. V2V devices would be required to report device misbehavior
to a central authority, namely the Security Credential Management
System, once misbehavior is confirmed via a series of self-diagnosis or
plausibility checks on incoming messages. This includes identifying
methods for device self-diagnosis of both hardware and software to
ensure that the device has not been altered or tampered with from
intended behavior.
    If an anomaly is detected and confirmed by a series of secondary
plausibility checks, a ``misbehavior event'' would be identified, and a
sample of BSM information such as geo-location, time-stamp, and a
digitally signed (encrypted) certificate from the misbehaving device
would be recorded as ``evidence'' of the event. The reporting device
would then transmit its misbehavior report to the SCMS misbehavior
authority (MBA) using a secondary communications channel.
    The intent of the MBA is to gather misbehavior reports by all
devices participating in the network. These reports would be analyzed
in accordance with established and governed policies for global
misbehavior detection determine if and when a particular vehicle should
be placed onto a Certificate Revocation List (CRL). More accurately, is
and when information related to a particular device's certificates
should be placed onto the CRL such that other vehicles can use the
information to identify the misbehaving device, assume it cannot be a
trusted device, and ignore its messages. The CRL would be updated
periodically by the MBA and distributed to participating V2V devices.
    The agency views misbehavior detection as a key feature of the
proposed security architecture: That misbehaving devices are able to be
efficiently detected, and their identity made available to other
devices participating in the network. At the highest level, confidence
in the V2V messaging could be eroded if misbehaving devices are not
detected and reported to a centralized authority.
    As indicated in Table II-5, additional research is being conducted
to better understand the data, processing, and algorithm development
necessary to implement misbehavior detection at both the local (device)
level and global (SCMS) level. For misbehavior to be effective,
techniques must be identified, developed, and implemented in both
devices and at a central authority for the system to secure V2V
messages. The proposed requirements concerning detection and reporting
support misbehavior detection functionality, but do not include at this
time the actual techniques to detect and identify misbehavior. Research
is being conducted; however, the actual nature of misbehavior in the
V2V ecosystem has yet to be defined given the lack of misbehavior data
to support actual development of techniques and algorithms. Initial
data will be available once the SCMS Proof-of-Concept (Section V.B.6.e)
is operational and supporting the security of the Connected Vehicle
Pilot activities. The agency seeks comment regarding the requirements
to support misbehavior detection, the investigation of detection and
identification techniques, and possible implementation issues including
the need to evolve detection

and identification algorithm capabilities over time.
(1) Reporting
    The agency has worked extensively with its research partners to
develop a comprehensive set of proposed reporting requirements for
misbehavior detection. The reporting requirements attempt to strike a
balance between frequency, the amount of data reported, and the need to
effectively and efficiently identify misbehavior to mitigate any
potential effects. As described previously, the purpose of the
misbehavior reports is to:
     Indicate potential misbehavior and misbehaving devices,
and
     indicate suspicious activities around the reporting
device.
(a) Report Content
    The agency is proposing that a misbehavior report is a message
signed by the reporting device and shall include at a minimum the
following data:
     The reporter's certificate.
     GNSS coordinates (latitude, longitude and elevation) at
the location where the misbehavior was initially identified.
     The GNSS coordinates where the misbehavior appears to have
ended. This field is optional as it may not apply to all misbehavior.
This could be useful for indicating where a DoS attack begins and where
it ends.
     BSMs from both host device and remote threat device.
     Warnings present at time of misbehavior detection, if any.
     List of neighboring devices.
     The Coordinated Universal Time (UTC) at which the
misbehavior was detected.
     Information identifying the detection method that
triggered the report.
    The agency seeks comment on the proposed inclusion of the above
data in a misbehavior report. Specifically, we would appreciate
commenters providing any potential additional data that should be
included. The agency also asks commenters to provide feedback on the
potential for inclusion of any personally identifiable information
(PII) related to misbehavior and the potential positives and negatives
of such an inclusion.
    Additionally, the agency is also seeking comment on the potential
inclusion of the following items in the misbehavior report:

 The average Channel Busy Percentage observed if a Denial of
Service is detected
 List of vehicles (device/certificate IDs) within communication
range when misbehavior is detected
 Abstracted (non-V2V related) sensor information if such sensor
information is available to the device
 Averaged speed of vehicles within communication range of the
reporting vehicle
(b) Misbehavior Report Generation and Transmission
    A misbehavior report shall be generated as follows:

 A misbehavior report shall be created at the time a
misbehavior is detected
 Misbehavior reports shall be signed and transmitted with the
same credentials as those of BSMs
 A misbehavior report shall be signed by the reporting device
at the time of the report creation
 The misbehavior reports shall be encrypted with the public key
of the misbehavior authority and transmitted to the central authority
through a secured communication channel
(c) Misbehavior Report Storage
    Misbehavior reports shall be stored as follows:

 The V2V device shall allocate sufficient persistent memory
storage for 1600 KB of misbehavior event reports
 Misbehavior reports shall be stored persistently in non-
volatile memory to avoid report erasure during vehicle shut-down and
start-up cycles
 A misbehavior report shall be stored in persistent memory for
at least 20 weeks
 If the allocated misbehavior report memory capacity is to be
exceeded due to a new incoming misbehavior report, the oldest report or
reports shall be overwritten to allow the storage of the newest report
 If misbehavior reports are to be stored in unencrypted storage
medium, the content shall be encrypted
(2) CRL Processing
 If the credentials of a locally detected misbehaving device
are already on the locally stored CRL it shall not be re-reported to
the central authority
(3) SCMS Security
    The agency recognizes the misbehavior mechanism identifies
anomalies that could indicate malfunctions or malicious activities that
could adversely impact proper operation of individual devices or the
system; possibly causing unsafe or unreliable operation if trusted.
Misbehavior operations and subsequent device requirements ensure that
the device perpetrating the misbehavior can be rendered innocuous by
revoking the device's security certificates effectively making them an
untrusted source to properly functioning devices. The agency is
therefore proposing the following the requirement is applied to a
central authority, namely the SCMS, responsible for global misbehavior
and management:
     The agency requires that a central authority employ
protocols that establish a disposition based on reporting from various
sources to mitigate the potential for misbehavior detection to become a
gateway for an easy cybersecurity threat for denial of service.
(4) Request for Comment
    The agency believes the proposed misbehavior reporting requirements
could help reduce the number of misbehaving devices whose messages
would be accepted by the V2V network and thus help reduce the chance of
false safety warnings. The agency seeks comment on the misbehavior
reporting approaches describe in this section along with potential
other approaches the agency should consider.
    More specifically, the agency appreciates thorough explanation of
any suggested alternative approaches to misbehavior reporting, as well
as sufficient description of why you believe that the proposed approach
is, or is not appropriate. Additionally, the agency would appreciate
suggestions on how to properly and reasonably test for misbehavior in a
V2V system.
(5) Potential Regulatory Text for SCMS-Based Misbehavior Detection and
Reporting
    The agency has included no regulatory text for SCMS-based
misbehavior detection and reporting and instead has a bracked
placeholder for where it would be if this were to be part of a final
rule. The agency expects that regulatory text in any final rule would
include:
     A provision on detecting misbehavior related to both
malfunctioning sensors and physical tampering.
     A provision addressing a BSM failing any plausibility
check, which would require the device to generate a misbehavior report
that meets certain minimum requirements.
     A provision concerning creating and sending misbehavior
reports. This provision would set requirements about what data would
need to be included in a misbehavior report (which would include the
information listed above).

Further, it would include provisions on how a misbehavior report must
be generated and transmitted, which would include that it would need to
be created within 2 seconds after the misbehavior is detected, and
thensigned,encrypted and transmitted to SCMS.
     A provision detaling how misbehavior reports would need to
be stored
     A provision concerning the credentials of a locally-
detected misbehaving device already on the locally-stored CRL.
     A provision concerning communicating with the SCMS.In
addition, the agency would need to include additional regulatory text
on test procedures including the ability to detect misbehavior and
receive certificates from the SCMS.
(b) Alternative Approach--No Misbehavior Reporting
    In contrast to the primary misbehavior detection proposal, the
agency is seeking comment on an alternative approach to misbehavior
detection where there are no requirements to report misbehavior or
implement distribution of information to facilitate blocking based on
misbehavior reports to an authority. Implementers would be free to
include such features as reporting the detection of any misbehavior or
a malfunction as optional functions. Independent of this alternative
approach, the agency is proposing to require that implementers identify
methods that would check the functionality, including hardware and
software, of a V2V device ensuring that the device has not been altered
or tampered with from intended behavior.
    The agency appreciates commenter's views on this potential
alternative approach including reasons why or why not this potential
would be appropriate for identifying misbehaving or malicious devices
participating in V2V communications. We also encourage commenters to
provide any suggested alternative approaches to misbehavior reporting,
as well as sufficient description of why you believe that the proposed
approach is, or is not appropriate. Additionally, the agency would
appreciate suggestions on how to properly and reasonably test for
misbehavior in a V2V system.
5. Proposed Malfunction Indication Requirements
(a) Overview
    The agency is proposing to require that all V2V devices be equipped
with a mechanism for notifying users that the device and/or its
supporting equipment is not operating normally and some form of repair
is necessary. The requirements proposed in this section are consistent
across any potential technology employed in V2V communications. The
agency is not specifying a format for the notification mechanism, as
elaborated below--it can be an illuminated telltale, a message in the
message center, or something else--but it must be presented in the
vehicle itself for OBE or on the device itself for non-integrated
aftermarket products. This proposed requirement aligns with the
proposed misbehavior requirements and cost estimates, in that
misbehavior detection requires devices to perform self-diagnostics and
report to users a failure condition. Likewise, the cost estimates for
the proposal include costs for some type of malfunction indicator and
reflect what we would consider to be a ``minimalist'' approach.
    The agency has a long history of requiring both diagnostics and
malfunction indicators. FMVSSs for electronic stability control (No.
126), tire pressure monitoring systems (No. 138), and air bags (No.
208), among others, include requirements for indicating when the system
is in a failure condition. In these cases, the agency believed, and
therefore required, that proper maintenance to ensure system operation
is vitally important to driver and passenger safety. The agency has no
reason to believe any differently for V2V devices, other than
potentially strengthening those beliefs based on the cooperative nature
of V2V and how the benefits are a ``networked good,'' where one device
has the potential to benefitting many others.
(b) Malfunction Indication Requirements
     Any device participating in the V2V system shall clearly
indicate to their users a malfunction condition occurring in the
device, its supporting equipment or the inputs used to form, transmit,
and receive a basic safety message. Malfunction indication shall be
provided in instances such as:

[cir] Device components not operating properly
[cir] Input sensor data not within appropriate tolerances
[cir] On Board memory failures
[cir] GPS receiver failures
[cir] Unable to transmit or receive basic safety messages
[cir] Any other failure that could prevent normal operation
 Malfunction indication shall be clearly presented to device
users in the form of a lamp or message
 Owner's information shall clearly describe the malfunction
indication, potential causes, and if needed, the need to have the
device serviced
 The malfunction indication shall remain present until the V2V
device is returned to normal operating state
 The malfunction indicator shall illuminate the malfunction
indicator as part of power up initial system diagnostics to confirm the
indicator is operating properly

    The agency seeks comments on these proposed requirements. More
specifically, the agency would like commenters to give their views on
malfunction indication, the best ways to convey device malfunction to
users, and why they believe this to be the case.
6. Software and Security Certificate Updates
    The agency anticipates that, over time, V2V devices and the system
overall will require periodic updates to address functionality,
potential security, or potential privacy issues as they arise after a
vehicle owner or operator takes possession of a vehicle. The agency is
proposing that V2V devices allow for over-the-air (OTA) software and
certificate updates and those device users be notified of any consent
required for periodic device updates.\159\ The agency believes that
over-the-air devices updates will be viable and commonplace by the time
a final rule to this proposal is finalized.160 161
---------------------------------------------------------------------------

    \159\ See below for the agency's discussion of its legal
authority. This proposed requirement is similar to many other
existing requirements to warn drivers via telltales or messages
about potential issues with required safety technologies, for
example, the ESC or TPMS malfunction telltales. The difference in
this case is simply that the agency expects a need to illuminate the
telltale with some regularity, given that certificates will
periodically run out and need to be replenished.
    \160\ ``OTA updating brings benefits, challenges'' SAE
Automotive Engineering, August 16, 2016, http://articles.sae.org/14946/ (last accessed: Dec 7, 2016).
    \161\ ``International Truck offers over-the-air programming for
2017 Cummins engines'' SAE Automotive Engineering, May 19, 2016,
http://articles.sae.org/14834/ (last accessed: Dec 7, 2016).
---------------------------------------------------------------------------

    We anticipate this highest potential for periodic updates will come
in two primary forms: Device software updates and security credential
updates. In either case, the agency believes user notification and
consent would be required to execute the update. The approach of this
proposal is provide the basic platform to enable V2V communications
where the hardware needed is the most technologically basic enabler,
essentially a radio transmitter and receiver. The device complexity,
intellectual property and overall V2V operation is primarily rooted in
the firmware and software loaded into a V2V device's hardware. The
agency

anticipates any updates to the device hardware would be manifested by a
malfunction, device failure that would be subject a recall and/or
warranty provisions if the device warranty is still valid.
    Over the air updating will provide significant flexibility for
updates, not only to V2V devices but many vehicle-resident components,
to fundamental device operation but also, following suit of smartphone
devices, enable ``pushing out'' new applications to automotive devices.
The agency believes this approach can and will best exploit the V2V
communications ``platform'' contained in this proposal.
    As discussed throughout the proposal and more specifically, the
legal authority section, the agency believes V2V device users will need
to consent to both software and security certificate updates.
Therefore, the agency is proposing to require that devices
participating in the system provide users with indication, in the form
of a descriptive telltale or text message displayed in a vehicle
message center that is in clear view of the driver, that device
software or security certificate updates are available and that users
need to consent before the update can occur. The indication and consent
mechanism must reside in the vehicle or device.
    The agency seeks comment on this proposed requirement for software
and certificate update. Do commenters agree with the proposed approach,
why or why not? Do commenters have alternative suggestions for how V2V
device users can seamlessly consent, without burden, to software and/or
certificate updates? More specifically, how do commenters perceive
potential mechanisms for receiving notification and consenting, or not,
to any potential updates. What potential implications may result from
the anticipated need for updates and consent? What real-world
experience do commenters have performing over the air updates for
devices? Please provide any supporting information that may help the
agency explore and finalize an approach.
7. Cybersecurity
(a) Cybersecurity Overview
    Today's electronics, sensors, and computing power enable the
deployment of vehicle safety technologies, such as forward-collision
warning, automatic-emergency braking, and vehicle-to-vehicle
technologies, which can keep drivers from crashing in the first place.
NHTSA strongly believes in the need for cybersecurity, which is
essential to the public acceptance of increasingly computerized vehicle
systems, to the safety technology they govern, and to the realization
of the safety-enhancement potential they offer.
    Cybersecurity, within the context of road vehicles, is the
protection of automotive electronic systems, communication networks and
nodes that interface with vehicles, control algorithms, software,
users, and underlying data from malicious attacks, damage, unauthorized
access, or manipulation. The agency has been taking a holistic approach
to vehicle cybersecurity, considering that all access points into the
vehicle could potentially be compromised, and is focused on solutions
to harden the vehicle's electronic architecture against potential
attacks and to ensure vehicle systems take appropriate and safe
actions, even when an attack may be successful.\162\ A layered approach
to vehicle cybersecurity within a risk-based framework reduces the
probability of an attack's success and mitigates the ramifications of a
potential unauthorized access.
---------------------------------------------------------------------------

    \162\ See ``NHTSA and Vehicle Cybersecurity'', http://www.nhtsa.gov/staticfiles/administration/pdf/presentations_speeches/2015/NHTSA-VehicleCybersecurity_07212015.pdf (last accessed Dec 12,
2016).
---------------------------------------------------------------------------

    NHTSA's vehicle cybersecurity approach is built upon the following
principles:
     Based on the risk-based prioritized identification and
protection of safety-critical vehicle control systems and personally
identifiable information;
     Provides for timely detection and rapid response to
vehicle cybersecurity incidents in the field;
     Designs-in methods and measures to facilitate rapid
recovery from incidents when they occur, and;
     Institutionalizes methods for accelerated adoption of
lessons learned across the industry through effective information
sharing, such as through participation in the Auto ISAC.
    Our vehicle cybersecurity research program considers all access
points into the vehicle, more broadly than, but also including V2V.
This approach makes a distinction between
    (1) how vehicle architectures should be designed that interface
with the outer world such that risks to safety-critical system
functionality could be effectively mitigated; and
    (2) how each unique access point could be protected such that an
appropriate relationship could be established for the messages
exchanged over that medium.
(b) Agency's Cybersecurity Approach To Hardening Vehicle Architectures
in General
    Related to hardening the vehicle architectures to be cyber-
resilient agnostic of the type of communications interface, NHTSA is
pursuing a best-practices approach, which is based on the National
Institute for Standards Technology's (NIST) proven cybersecurity
framework that includes five principal functions: Identify, Protect,
Detect, Respond, and Recover.
    This approach suggests that all interfaces between the vehicle
electrical architecture and the external world (personal or aftermarket
devices, cars, infrastructure, cloud, etc.) need to be carefully
considered for risks and appropriate mitigation strategies be
implemented. These include not only protection methods, but also
intrusion detection techniques, rapid remediation strategies and fast
adoption of new lessons learned, because we assume that all entry
points into the vehicle, such as Wi-Fi, infotainment, the OBD-II port,
V2V, and other points of potential access to vehicle electronics, could
be potentially be or become vulnerable over time. We suggest that the
industry should make cybersecurity a priority by using a systematic and
ongoing process to evaluate risks. And, this process should give
explicit considerations to privacy and cybersecurity risks through the
entire life-cycle of the vehicle. Further, safety of vehicle occupants
and other road users should be an overriding consideration when
assessing risks.
    We continually monitor the industry as they move towards a more
cyber-aware and cyber-resilient posture and will take necessary actions
to ensure that there are no unreasonable safety-risks.
(c) V2V-Specific Cybersecurity Considerations
    NHTSA does not overlook the potential risks of interfacing the V2V
vector with vehicle systems; however, we believe that the holistic
approach we are taking in the broader sense as outlined above apply to
the common characteristics of various different communications
interfaces in the same manner.
    In this section, we will primarily focus on the unique attributes
of the V2V communications interface and present key steps that are
being taken to mitigate the potential incremental risks they could
pose.
    Key attributes of V2V communications interface, as they relate to
cybersecurity risks include the following:

    (1) Security and privacy by design through a message
authentication,
    (2) Broadcast-listen protocol,
    (3) Well-defined and fairly limited message structure,
    (4) Communications range is limited to about 1000ft,
    NHTSA's primary proposed message authentication alternative for V2V
communications employs a PKI-based security. Each broadcast message is
signed with cryptographic keys to facilitate a method for the receiving
units to validate the authenticity and integrity of the transmitted
message from its source.
    Both the primary and performance-based alternatives for message
authentication seek to ensure the integrity of messages between
communicating units to help assert that the message has not been
altered during transmission or been sent from a malicious sender. It is
important to note that this approach does not necessarily validate the
accuracy of the message content received.
    We consider the cybersecurity risks associated with

    (1) the PKI authentication method, and the infrastructure
supporting it,
    (2) the contents of the messages received, and
    (3) the V2V communication interface as a potential channel to
inject malware
(1) PKI-SCMS Cybersecurity Requirements
    In Section V, the primary message authentication proposal describes
the SCMS. The system described is focused on the security functions and
requirements necessary to help secure the V2V communications
environment. Implementations of the performance-based alternative for
message authentications may also need similar compensating approaches
depending on the approach taken. While the proposed primary message
authentication architecture provides well-recognized security
protections, we further consider the potential cybersecurity
vulnerabilities and discuss how they are expected to be mitigated.
(a) On-Vehicle Security Materials (Cryptographic Information)
     The OBE will contain security materials that are critical
to the operation of the V2V device, and the system as a whole. This
includes long term enrollment certificates, short term pseudonym
certificates, public/private keys, SCMS security policies, and
misbehavior reports. All of this data, if retrieved by unauthorized
parties, could allow potential ``bad actors'' to transmit messages that
may appear valid to the general ecosystem of devices because these
messages are using actual credentials given to a trusted device.
     Attempts to retrieve valid security materials could
involve targeting physical OBEs. In addition to having access to OBEs
on personal vehicles, OBEs on vehicles that are at their End-of-Life
(EOL) decommissioning phases (such as those that can be taken from
vehicles in junkyards) could also create a pathway. In the event that a
vehicle with a device has met with the end of its useful life, it is
foreseen that the device could have up to three years' worth of valid
security certificates, assuming that it has regular communication with
the SCMS.
     One method that could mitigate the risk associated with
retrieval of security information through physical access to the OBE
would involve hardware security against tampering such as the use of
FIPS \163\ Level 3 hardware security module. This specification level
is consistent with requiring the zeroisation of cryptographic
information in the event that the device is tampered with. While this
would protect against malicious attempts, it would likely result in
managing the legitimate serviceability needs of the units, likely
incurring additional costs for maintenance.
---------------------------------------------------------------------------

    \163\ The FIPS families of standards contain a set of standards
that pertain specifically to cryptographic storage models, FIPS-140
which the industry uses to store sensitive cryptographic
information. The device long and short term certificates along with
the devices public/private key pairs are generally regarded as
cryptographic information. The FIPS-140 set of standards define
various levels of security for cryptographic information storage
ranging from 1 through 4, with increasing security measures as the
levels get higher. Of particular interest to the OBE are levels 2
and levels 3. Amongst other differences, the agency is interested in
the tamper capabilities of these levels. Level 2 is considered
tamper evident storage. This can be achieved by placing seals on
enclosures (like stickers on over the counter medication that say
``do not use if seal is broken''), by using tamper evident screws
and mounting hardware, and other such methodologies. Level 3 adds to
this by requiring devices to be tamper resistant. There are many
ways to achieve tamper resistance; however, one common method for
protecting data is to have the device zero out cryptographic storage
in the event that a device is tampered with.
---------------------------------------------------------------------------

     The agency believes that the current environment regarding
cybersecurity and protecting the public warrants a level of hardware
security that goes beyond evidence of tampering to actually protecting
cryptographic information in the event of a device breach with
malicious intent. Therefore, the agency is proposing to require that
V2V devices have a minimum of FIPS-140 Level 3 security protection. The
agency also believes that at, a minimum, the following information
shall be stored in FIPS-140 Level 3 storage:

[ssquf] All individual pseudonym certificates
[ssquf] RA, Intermediate CA, and PCA certificates
[ssquf] the RA address
[ssquf] system configuration files
[ssquf] security policies
[ssquf] Root CA certificate
[ssquf] Device Enrollment certificate
[ssquf] All system private keys
[ssquf] The System CRL
[ssquf] All unsent misbehavior reports

     The level of security requirements defined by FIPS-140
Level 3 is somewhat different than the historical regulatory authority
approach exercised by NHTSA. NHTSA issues performance based
requirements which can be found in the many safety standards issued and
managed by the agency, although we can be specific in equipment
requirements if it is necessary to meet a safety goal. Evaluating
security protection ability does not necessarily conform to a
performance requirement and compliance test paradigm followed by the
agency. As such, NHTSA anticipates device compliance to be conducted by
the agency through third party testing laboratories with expertise in
confirming the appropriateness of device's hardware security.
     NHTSA seeks comments on this approach (FIPS-140 Level 3
requirement) and on what constitutes tampering, applicable triggers for
zeroisation, and how the triggers could be implemented such that
routine vehicle maintenance activities can be accomplished without
undue burden on the V2V device. The agency seeks comment on the
proposed FIPS-140 Level 3 device security requirements. In specific,
the agency seeks comment on the FIPS and CCP security approaches
briefly described in this section and the pros/cons of each, potential
compliance approaches including verification schema for information
that should be contained in a functioning, secure device, and views on
the whether the proposed level of protection is sufficient for
anticipate cybersecurity needs.
     Another approach that could address the more specific EOL
OBE security exposure could be for the SCMS to establish a process and
procedure by which responsible entities could notify the SCMS of end-
of-life devices (entities that deal with old, junked, crashed or
otherwise unusable vehicles that contain OBEs.) This would require the
entity that determines the device is at its EOL be able to report to
the security certificate information the SCMS would need to remove the
device from the system by including the

device's security credentials on the system ``blacklist,'' rendering
the security information useless. This approach could pose challenges
in practical application where the vehicle or device may not be
operating properly. Secondly, enabling a method to obtain security
information from a device could open up a potential security
vulnerability that could be used by others to obtain security materials
    We request comments on whether a process approach can succeed and
whether there may be other means to secure the on-unit security
information.
(2) Potential Regulatory Text for Physical Security for SCMS-Based
Message Authentication Proposal
    The agency has included no proposed regulatory text to support the
cybersecurity requirements discussed in the primary proposal for
message authentication based on the SCMS. However, the agency expects
that regulatory text in any final would include a provision requiring
that V2V devices have a minimum security protection of FIPS-140 Level
3, as described above.
    NHTSA seeks comments regarding the cybersecurity needs and
requirements and how regulatory language could be crafted to
appropriately express the requirements in terms that industry can
implement and in terms by which performance can be objectively
evaluated.
(3) Performance-Based Physical Security Alternative
    The agency has included no proposed regulatory text to support the
cybersecurity requirements discussed for a performance-based message
authentication alternative. However, the agency expects that regulatory
text in any final rule would include a provision requiring that V2V
devices have a minimum security protection of FIPS-140 Level 3 for
storage of cryptographic certificate, key, and other sensitive data. In
addition, a V2V device connected to a vehicle data bus would need to
incorporate isolation measures (firewalls) to prevent the V2V module
from being a conduit allowing malicious outside actors to gain access
to the vehicle data bus and other vehicle modules connected to the data
bus.
(4) No Physical Security Alternative
    The agency has included no proposed regulatory text to support the
cybersecurity requirements discussed for a no message authentication
alternative. However, the agency expects that regulatory text in any
final rule would include a provision requiring that a V2V device
connected to a vehicle data bus would need to incorporate isolation
measures (firewalls) to prevent the V2V module from being a conduit
allowing malicious outside actors to gain access to the vehicle data
bus and other vehicle modules connected to the data bus.
(d) SCMS Cybersecurity Considerations
    For the primary message authentication proposal, the SCMS provides
key services and security. Key functions of the SCMS include:
     Communications with DSRC devices to transfer of security
certificates,
     CRL maintenance and communications to the vehicles.
    Section III.E.3.b) explained how security certificates are
obtained, when and why certificates are changed, and how additional
certificates would be requested and obtained. SCMS provides this
service and uses encryption methods to facilitate secure communications
to protect security information in transit.
    CRLs are distributed to appropriate end-points in the same manner.
The credentials and message encryption protect the communication
between devices and the SCMS.
    The security system of the SCMS is complex and intricate; due in
part to privacy protection, therefore the agency requests comments
regarding the cybersecurity viability of V2V security and invites
comments concerning the relationship of V2V security to the larger
vehicle security universe.
(e) Cybersecurity and V2V Message Content
    While the security overlay of the V2V communications establishes
confidence between authentic entities, the message content indicating
the vehicle's behavior is obtained from sensors (such as GPS) and
vehicle data buses. It would be possible to manipulate the sources of
data to the OBE, which could send a BSM message with inaccurate message
content to its surrounding. In cases, the message could be constructed
intelligently that could make the messages sent from that vehicle not
correspond to the sending vehicle's physical behavior.
    Such manipulation could result in surrounding vehicles responding
with warnings to the driver early on. The misbehavior detection
mechanisms set out in this proposal are designed to detect the anomaly,
however it is possible that specifically crafted messages could be
delivered and accepted by safety applications.
    In the case of the primary misbehavior detection proposal, the
misbehaving sender would also hopefully be detected and the sender
added to the CRL. However, it is important to examine what could happen
if the message is not detected as misbehavior and the time period
before the sending vehicle is added to CRL. OEMs treat V2V as a new
sensor for the vehicle and applications designed using this message
would assess the safety-risks associated with this sensing mechanism
being wrong. Generally, warning systems imply less severity than active
control. OEMs indicate that they would take safety-conscious approach,
which would be different for different applications. They further
indicate that for active control, they tend not to rely on any single
sensor even in modern systems and expect that to be the same when V2V
becomes available to get in the mix of their sensor suite. The impact
of such malicious act would be limited vehicles within the
communications range of the unit (~1,000 ft).
    The broader impact on GPS or timing spoofing/jamming may have
similar impacts, or result in limited denial of service. Misbehavior
detection is projected to help in such cases and could also help
identifying and enforcing rules against jammers.
    Given there has been more reports of GPS jammers being used,\164\
we seek information and comment regarding how industry is addressing
the GPS jamming issue. Are there techniques to identify when GPS
jamming is occurring? If the GPS signal is being jammed or spoofed,
does industry have plans to notify the driver, and what will be the
context of the notification? During GPS jamming, will industry suspend
operation of systems that rely on GPS information?
---------------------------------------------------------------------------

    \164\ See ``GPS Under Attack as Crooks, Rogue Workers Wage
Electronic War'' at http://www.nbcnews.com/news/us-news/gps-under-attack-crooks-rogue-workers-wage-electronic-war-n618761 (last
accessed Dec 7, 2016).
---------------------------------------------------------------------------

    In addition, we solicit comment on whether our assessment of
cybersecurity risks due to spoofed and potentially malicious BSM
message data is reasonable. We also solicit input from OEMs and
Suppliers on how they expect to handle potential single point failures
associated with BSM signal contents. What risk-based criteria and
process would be appropriate for V2V safety applications to help ensure
the validity of the BSM message data received from other vehicles
relative to vehicle-local sensor readings? If data from a vehicle's
onboard sensors suggest a different outcome as compared to data from an
incoming BSM message, how

might V2V safety applications balance the trust on conflicting data?
How should V2V safety applications handle a situation where incoming
BSM message data is the only source of information available to make a
safety decision? How does the nature of the systems' planned reaction
(warning vs nature of control) impact such a decision? What new vehicle
sensors may be possible in the next 15-20 years that may significantly
improve such sensor fusion and decision processes?
(f) Cybersecurity and Potential Malware
    One of the cybersecurity risks that needs considered is whether V2V
communications could be used to insert malware to the OBE, unexpectedly
change configuration, or result in unwanted behavior. Since the V2V
channel will be mandated on all new cars, this medium would likely
become one of the dominant wireless access points on the vehicle fleet
in the field over time.
    Further, it should be considered that, since the V2V protocol is
based on broadcast and listen methodology, and does not establish
networks between participating units the way a traditional network
protocol does. Instead, communications takes place through a well-
defined BSM message structure.
     It is well established that many software and hardware
vulnerabilities occur at the communications interfaces of systems.
Security of the interfaces must be the highest priority when developing
a system. Therefore, we believe that implemented systems should provide
adequate controls to prevent malformed, incomplete or erroneous
messages that do not fit the specifications to pass to the OBE.
     The DARPA HACMS program has shown that formal verification
can be used to mathematically prove the correctness of systems or
interfaces. Formal verification uses mathematical techniques to
formalize software as a mathematical proposition to be proved. While
testing provides incomplete evidence of correctness, a proof guarantees
correctness of the system. In an active project, we are pursuing the
development of a formally verified reference parser for the V2V
communication interfaces that could provide the industry guidance on
one way to ensure that only expected range of BSM Part 1 and Part 2
would be accepted by the OBE. While we do not anticipate requiring the
use of a formally verified parser, we expect that industry will pay
attention and utilize such tools or other means to ensure that common
communication interface vulnerabilities do not exist in implemented V2V
units.
     NHTSA also anticipates pursuing fuzz-testing of
production-level implementations of V2V hardware with and without the
use of a formally verified parser. We also intend to develop a
framework of test protocols and message sets that manufacturers could
use to test their implementations.
     We reemphasize the importance of securing the V2V
communication channel. If the V2V interface is not properly secured
(whether by design or in implementation), we need to consider the
possibility of a ``worm'' \165\ type malware where the malware could
potentially self-replicate and propagate in an epidemic manner to other
systems with the similar vulnerability (e.g. systems from the same
manufacturer) that come into communications range. The potential
imminent-safety impact of such malware would depend on many factors and
most certainly depend of how the vehicle databus interfaces are
designed. Even if the impact may not be safety-critical, this risk
could potentially lead to large scale denial of service for the
mandated V2V technology. The manufacturers should plan for detection
and rapid remediation methods to address such issues. This need is
similar for other wireless channels. For example, in the 2014 hacking
of a Fiat-Chrysler vehicle,\166\ which led to eventual recall \167\ of
approximately 1.5 million vehicles, the researchers documented that
they could have designed a vehicle worm for the cellular communication
based vulnerability in that particular case.
---------------------------------------------------------------------------

    \165\ Worm refers to a standalone malware that replicates itself
in order to spread to other systems.
    \166\ ``Remote Exploitation of an Unaltered Passenger Vehicle'',
Charlie Miller and Chris Valasek. Page 48. Available at http://illmatics.com/Remote%20Car%20Hacking.pdf (last accessed Dec. 7,
2016).
    \167\ NHTSA Recall Campaign Number: 15V461000.
---------------------------------------------------------------------------

    We solicit input on whether the overall need for rapid remediation
methodologies would imply different requirements for the V2V
communication interfaces as opposed to others (such as cellular,
Bluetooth, Wi-Fi). Further, we solicit comment that exploitation of a
potential vulnerability in the V2V OBE does not immediately imply
safety-critical system compromise.
    The cybersecurity environment changes continually and at times
rapidly. Capabilities designed into systems should take the whole
lifecycle of the vehicle into account and provide for rapid response
methods to potential incidents in the field. These methods could take
various forms but should consider both the issue containment and
practical remediation needs.
    Generally, first important step is having a method to identify
cybersecurity issues and share them with the broader community. We and
the industry believe that the Automotive Information Sharing and
Analysis Center (Auto ISAC) established in 2015 will have a major role
in this respect. We anticipate that V2V related intelligence sharing
through Auto-ISAC will accelerate the identification of issues and
remediation actions. As part of this process, it should be foreseen
that various aspects of the V2V design may need updates over the life
of systems in the field, such as:

     Security certificates and protocols,
     Misbehavior detection algorithms and policies
     CRL contents and policies
     Device firmware

    In the case of primary message authentication approach, the SCMS
can update certificate and security protocols that are inputs to each
device, but the actual software that performs the security management
for different devices can and will be implemented differently by
different manufacturers. Each device supplier will need to manage
handling of potentially required security updates. It is likely that
there will need to be coordination among the SCMS and various devices
suppliers to facilitate such updates. It may be the SCMS through the
Misbehavior Authority that identifies the need for an update and
communicates this to suppliers so that updates can be prepared.
    There are many methods by which updates can be implemented. As seen
with the different kind of devices that exist today, like tablets/
iPads, there are various options and issues. Automated updates to
computer systems can be implemented wired or wirelessly. Some of the
updates; however, require consent; that screen that asks if you agree
to the terms related to the update that may go on for pages. Some
methods (personally updating device firmware) require technology savvy
that many consumers do not possess. Others require owners bringing
their cars to dealers, which are not often followed well.\168\ The
growing trend is towards building in capabilities for remote software
updates.
---------------------------------------------------------------------------

    \168\ According to online Web site Autotrader, the recall
completion rate in 2015 was approximately 48 percent, down from 56
percent in 2014.

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

    According to a study released by IHS in September of 2015,\169\
OEMs are going to begin implementing software updates over-the-air
(OTA); similar to how smart phones are updated currently. In fact the
study estimated that software-related repair might soon be able to be
wirelessly installed on the vehicle without the owner ever leaving
home.
---------------------------------------------------------------------------

    \169\ ``Over-the-air Software Updates to Create Boon for
Automotive Market, IHS Says'' at http://press.ihs.com/press-release/automotive/over-air-software-updates-create-boon-automotive-market-ihs-says (last accessed: Dec. 7, 2016).
---------------------------------------------------------------------------

    Japanese OEMs pioneered navigation map updates in Japan via their
telematics systems. BMW, VW, and Tesla have announced OTA procedures
for updating navigation maps. In fact, both Tesla and BMW have already
documented utilizing OTA updates to fix security issues onboard their
vehicles.
    With new vehicles having more connectivity with the Internet and
other wireless media, IIHS is predicting that upwards of 160 million
cars will partake of OTA updates globally by 2022. In fact many of
these may already be available to cars now. XM radios can potentially
be utilized to download OTA updates to vehicles and in fact are pre-
installed on upwards of 70 percent of all new light vehicles. 4G
services, as well as onboard Wi-Fi units are penetrating further into
the vehicle fleet as well.
    Given that V2V operational and security software may need to be
updated securely and widely while systems are in service, it may be
unreasonable to expect that non-OTA software updates may have the
desired impact and effectiveness (based on experiences in non-OTA
domains for recalls). As such, NHTSA is soliciting feedback on whether
it should consider requiring that V2V enabled vehicles have built-in
OTA capability to have critical software updates, and seeks comment on
the practicability of requiring this in future vehicles. NHTSA also
solicits feedback on whether vehicle owners should be given the option
to decline critical security updates.
    In addition, there will be situations when a security vulnerability
may be known to NHTSA and manufacturers but not all V2V-equiped
vehicles will have installed the patches or updates to mitigate the
flaw. During this period, vehicles in the fleet may be vulnerable until
the patch or update is installed. NHTSA is seeking comment on how this
period of vulnerability should be managed, the time period over which
updates or patches should be installed, how the number of patched and
unpatched vehicles should be measured to determine patch adoption, and
how to manage the situation when vehicles do not receive patches or
user refuse to accept or agree to the update.
(g) Enforcement Mechanisms
    The National Highway Traffic Safety Administration (NHTSA), under
the U.S. Department of Transportation, is the U.S. government agency
that was established to carry out safety programs under the National
Traffic and Motor Vehicle Safety Act of 1966, re-codified as Title 49
U.S.C. Chapter 301, Motor Vehicle Safety (the Vehicle Safety Act).
Under that authority, NHTSA issues and enforces Federal motor vehicle
safety standards (FMVSS) that apply to motor vehicles and to certain
items of motor vehicle equipment. Associated regulations are found in
Title 49 of the Code of Federal Regulations (CFR), Parts 500-599.
    The Vehicle Safety Act requires that motor vehicles and regulated
items of motor vehicle equipment as originally manufactured for sale in
the United States be certified to comply with all applicable FMVSS.
NHTSA does not play any part of the certification process. NHTSA does
not approve any motor vehicles or motor vehicle equipment as complying
with applicable FMVSS. Instead, under 49 U.S.C. 30115, each vehicle
manufacturer and equipment manufacturer is ultimately responsible for
certifying that its vehicles and equipment comply with all applicable
FMVSS.
    When establishing the FMVSS, NHTSA must ensure requirements are
practicable, meet the need for motor vehicle safety, and are stated in
objective terms. Each FMVSS specifies the minimum performance
requirements and the objective test procedures needed by the agency to
determine product compliance with those requirements.
    The Office of Vehicle Safety Compliance (OVSC) is the office within
NHTSA's Enforcement Division that is responsible for compliance
verification testing. OVSC funds independent test laboratories
throughout the United States to execute the verification tests. The
verification tests are not certification tests since the vehicle
manufacturers are ultimately responsible for vehicle certification, but
are used to verify that tested motor vehicles appear to meet the
requirements of the FMVSS. OVSC utilizes the test procedures specified
in each FMVSS as the basis for developing a more detailed test
procedure that includes test conditions, set-ups, test equipment, step-
by-step test execution, and data tables. Each funded test laboratory is
required to utilize the OVSC test procedure to establish even more
detailed test procedures with step-by-step approaches documented
including check-off lists and data tables.
    In most cases, when OVSC and a contracted test laboratory perform
FMVSS tests, the test vehicle appears to meet the requirements of the
applicable standard; however, in some instances, test failures are
identified. When an apparent test failure is identified, the following
steps will be followed by OVSC to resolve the possible noncompliance.
     The contracted test laboratory notifies OVSC of any
potential test failure.
     The test laboratory verifies that the test procedure was
executed exactly as required and that all laboratory test equipment
utilized has up-to-date calibration information attached.
     The test laboratory provides detailed test results to OVSC
for evaluation.
     The laboratory may be directed to recalibrate any critical
test equipment to ensure proper operation.
     The vehicle manufacturer is notified of the test failure
and the test data is shared.
     OVSC requests the manufacturer provide documentation and
its basis for certification.
     The vehicle manufacturer may choose to conduct additional
internal testing to gather additional data for evaluation.
     Meetings will be held as required with test laboratory and
vehicle manufacturer personnel to identify test execution related
problem or possible vehicle noncompliance.
     Additional verification tests on same vehicle or identical
vehicle may be executed to validate test results.
     If noncompliance is identified and confirmed by vehicle
manufacturer, the manufacturer is required to submit a 49 CFR part 573
report of noncompliance report within five working days after a
noncompliance has been determined.
     The manufacturer will work with NHTSA to ensure a fix has
been developed to correct the identified noncompliance.
     Follow-up tests may be executed to verify the fix does in
fact correct the problem.
     The vehicle manufacturer will work with NHTSA to ensure no
new noncomplying vehicles are sold and that the vehicles on the road
are recalled to fix the confirmed noncompliance.
    The above steps are not necessarily in the exact order they may
occur based upon the type of test failure and because

many of the steps are occurring simultaneously. Furthermore, the actual
steps required to resolve any potential test failure will be predicated
on the technical attributes of the failure and the difficulties
associated with the ultimate resolution of the problem.
(h) Compliance Test Procedures
    To ensure that light vehicles equipped with a V2V communications
system, On Board Equipment (OBE), is interoperable and compliant with
the minimum performance requirements, the regulatory text of this
proposal includes static, dynamic, and simulated performance tests.
These tests have the potential for evaluating the performance of the
V2V Radios and verifying the accuracy of the Basic Safety Message (BSM)
safety message, Part I.
    Overall, we anticipate devices being tested will be instrumented
with independent measurement sensors, devices, and a data acquisition
system (DAS) in order to collect V2V system data. The independent
measurement equipment will collect Differential Global Positioning
System (DGPS) information, vehicle speed, vehicle 3-axis accelerations,
vehicle yaw rate, vehicle systems status information, and radio
performance data.

IV. Public Acceptance, Privacy and Security

A. Importance of Public Acceptance To Establishing the V2V System

    In the Readiness Report, NHTSA extensively discussed the importance
of consumer acceptance to the success of V2V, given that as a
cooperative system that benefits from network effects, V2V depends on
drivers' willingness to participate. V2V needs vehicles to be equipped
in order to broadcast messages that other vehicles can ``hear,'' but in
order for equipped vehicles to join the roads, consumers must be
willing to recognize the benefits of a V2V system and support its
adoption by the U.S. vehicle fleet via the purchase of the new,
equipped vehicles, or by adding V2V capability to their existing
vehicles through aftermarket devices. Thus, consumers must want V2V in
order for V2V to reach its full potential. If consumers avoid the
technology for some reason, it will take longer to achieve the network
effect, and safety benefits will be slower to accrue.
    Additionally, the courts have determined that public acceptance of
a mandated technology is necessary to ensure that the mandate fulfills
the requirements of the Safety Act. As discussed further in Section V.C
below, if the public rejects a technology that the agency has required
for new vehicles, the courts have found that the standard may neither
be practicable nor meet the need for safety in the absence of public
acceptance. If vehicle manufacturers literally cannot sell V2V-equipped
vehicles because consumers en masse refuse to buy them, then it is
possible that a court would conclude that the standard was not
consistent with the Safety Act.
    NHTSA must therefore consider the potential elements of a V2V
requirement that may affect public acceptance, and do what we can to
address them, both through carefully considering how we develop the
mandate, and through consumer education to improve understanding of
what the technology does and does not do. Additionally, we expect,
simultaneously, that vehicle manufacturers subject to the eventual
mandate will likewise work to improve public understanding of the
benefits of V2V, boosting consumer acceptance overall. We also seek
comment on the extent to which an if-equipped approach potentially may
alleviate some consumer acceptance concerns.

B. Elements That Can Affect Public Acceptance in the V2V Context

    Based on our review of the research conducted so far and the
responses to the ANPRM and Readiness Report, NHTSA believes that the
several elements of the V2V system discussed below may affect public
acceptance.
1. False Positives
    A ``false positive'' occurs when a warning is issued to a driver
and the warning is unnecessary (or when the driver believes the warning
is unnecessary), because there is no immediate safety risk that the
driver has not already accounted for. False positives can startle and,
if there are too many, annoy a driver, causing drivers to possibly lose
confidence in the system's ability to warn them properly of danger and
desire to have the warning disabled; reducing overall system benefits.
If the driver does not notice immediately that a false positive is in
fact false, the driver might carry out an unnecessary evasive maneuver,
potentially increasing the risk of an accident.
    In the SPMD, we initially saw fairly high numbers of false positive
warnings for some V2V applications.\170\ Further analysis indicated
this was due largely to the fact that the safety applications under
evaluation were still prototypes. Part of the goal of the SPMD was to
provide vehicle manufacturers with the opportunity to gain real-world
experience with V2V safety applications; providing the opportunity to
improve their ``tuning'' to maximize safety while minimizing false
positives. Driver complaints, particularly regarding IMA warnings
triggered by cloverleaf highway on-ramps and elevated roads that
crossed over other roadways, led manufacturers to adjust the safety
applications to accommodate the these originally-unexpected ``warning''
conditions. The SPMD experience proved that these adjustments
significantly reduced false positive warnings for this application.
---------------------------------------------------------------------------

    \170\ See, e.g., Nodine et al., ``Independent Evaluation of
Light-Vehicle Safety Applications Based on Vehicle-to-Vehicle
Communications Used in the 2012-2013 Safety Pilot Model
Deployment,'' USDOT Volpe Center, DOT HS 812 222, December 2015,
Section 5.1. Available at Docket NHTSA-2016-0126.
---------------------------------------------------------------------------

    At this time, NHTSA cannot account preemptively for the possibility
of future false positive warnings. Given that we are only proposing
today to mandate V2V transmission capability and are not yet requiring
specific safety applications, we are not developing requirements for
how safety applications must perform, and we recognize that doing so
would be a significant undertaking. We do expect, however, that
manufacturers will voluntarily develop and install safety applications
once V2V communications capability is required available. As with
existing advanced crash avoidance systems and as in the SPMD, we expect
manufacturers to address false positive issues that arise in use in
order to improve customer satisfaction. Because false positive issues
with V2V-based safety applications are typically a software issue
rather than a hardware issue Manufacturers may even be able to solve by
deploying solutions to such problems through over-the-air software
updates, rather than requiring vehicles to be brought in for
adjustment. Data from the SPMD suggests that it is possible to reduce
false positives in production safety applications and thus we believe
it should not pose a significant public acceptance issue for V2V.
Additionally, if NHTSA determines in the future that false positives in
the field create an unreasonable risk to safety, NHTSA could pursue
remedies for them through its enforcement authority.
2. Privacy
    If consumers fear that V2V communications will allow their
movements to be ``tracked,'' either for government or private purposes,
and that such information could be used to their detriment, they may
avoid buying new cars with V2V systems installed, or attempt to disable
the V2V systems in

their own vehicles. Concerns about privacy directly implicate consumer
acceptance. For this reason, in addition to NHTSA's obligation under
federal privacy law to identify the privacy impacts stemming from its
regulatory activities,\171\ the Agency also must consider consumer
privacy carefully in our development of V2V requirements. For example,
as discussed above, SAE J2735 BSM specification contains a series of
optional data elements, such as vehicle identification number (VIN),
intended to be broadcast as part of the V2V transmission that enables
safety applications. Because the Agency has determined that
transmission of VIN and other information that directly identifies a
specific vehicle or its driver or owner could create significant
privacy risks for private consumers, this proposal contains performance
requirements that exclude from the BSM such explicitly identifying
data. The Agency also is concerned that other data elements in the BSM
potentially could be used to identify specific individuals when
combined over time and with data sources outside of the V2V system. For
this reason, we have proposed a more general exclusion of ``reasonably
linkable'' data elements from the BSM to minimize consumer privacy risk
that could result from associating BSMs with specific individuals. We
discuss our privacy risk analysis in more in detail in Sections IV.C
and IV.D, and in the draft PIA published concurrent with this NPRM.
---------------------------------------------------------------------------

    \171\ Section 522 of the Consolidated Appropriations Act, 2005,
Public Law 108-447.
---------------------------------------------------------------------------

    NHTSA expects manufacturers to pursue a privacy positive approach
to implementing the proposed V2V requirements. In furtherance of the
Fair Information Practice Principles (FIPPs), especially those of
transparency and notice, we have developed a draft privacy statement
that we will require manufacturers to provide to consumers, included in
the regulatory text below. In order to ensure effective notice, we
intend for manufacturers to provide this statement to consumers in
understandable, accessible formats and at multiple easily identifiable
locations and times, including but not limited to the time of sale. We
seek comment from the public on the most effective time and means of
providing such multi-layered notice to individuals purchasing new and
used vehicles with V2V systems. We note that the industry has developed
a set of voluntary privacy principles for vehicle technologies and
services, which have been accepted by members of both the Alliance and
Global Automakers, covering the significant majority of motor vehicle
manufacturers.\172\ We also seek comment from the public on how these
principles would apply to V2V communications, as detailed in this NPRM,
and the extent to which application of these voluntary minimum
principles in the V2V context would provide adequate notice and
transparency to consumers.
---------------------------------------------------------------------------

    \172\ ``PRIVACY PRINCIPLES FOR VEHICLE TECHNOLOGIES AND
SERVICES'' available at http://www.autoalliance.org/?objectid=865F3AC0-68FD-11E4-866D000C296BA163 (last accessed dec 7,
2016).
---------------------------------------------------------------------------

    To date, vehicle technologies that have raised privacy concerns for
consumers have been ``opt-in,'' meaning that either consumers expressly
agree to the use of these technologies in their vehicles (and thereby
provide explicit consent) or consumer purchase vehicles containing
technologies not mandated by NHTSA (and thereby, arguably, provide
implicit consent). V2V presents a somewhat different situation, as we
are proposing that at least 50 percent of new vehicles will be required
to have V2V devices starting in model year 2021. Since this would be a
mandated technology, consumer choice will be limited to the decision of
whether or not to purchase a new car (all of which eventually would
contain V2V technology, if mandated). From a privacy perspective, such
implicit consent is not an optimal implementation of the FIPPs
principle of consumer choice. However, as discussed below in Section
VI.C., the agency has determined that there are no viable alternatives
to a mandate of V2V technology. In the agency's view, the absence of
consumer choice is required to achieve safety in the V2V context,
increasing the significance of ensuring that industry deploys V2V
technology in a privacy positive, transparent manner and provides
consumers with effective, multi-layered privacy notice. Consumers who
are privacy-sensitive tend to feel more strongly when the government is
mandating something that creates potential privacy risks to
individuals, as compared to when they voluntarily choose whether to
purchase and use such technology. NHTSA and vehicle manufacturers will
continue to work to ensure that V2V does not create the type of privacy
impacts frequently raised in comments, and will need to educate
consumers about the potential privacy impacts and privacy-enhancing
controls designed into the V2V system. That said, NHTSA seeks comment
on the extent to which an if-equipped approach potentially may provide
consumers with more of a choice to ``opt in'' to V2V technology--or
whether, if mandated, consumers should be provided an ``opt out''
option for privacy reasons.
3. Hacking (Cybersecurity)
    If consumers fear that V2V will allow wrongdoers to break into
their vehicle's computerized systems and take control of vehicle
operation, then, as with privacy concerns, they may avoid purchasing
new vehicles equipped with V2V or attempt to remove already-installed
V2V in their own vehicles. This fear is really a two-part concern: (1)
That V2V equipment can be ``hacked,'' and (2) that if V2V equipment can
be hacked, the consumer's safety may be at risk.
    Regarding the concern that V2V equipment can be hacked, as
discussed in much more detail in Section III.E.7 above, counter
measures have been identified using a risk-based approach to determine
the types of threats and risks to the equipment that may occur. We are
proposing to require additional hardening of the on-board V2V equipment
beyond normal automotive-grade specifications to help reduce the chance
of physical compromise of V2V. In addition we have included
alternatives for message authentication and misbehavior reporting to
solicit comment regarding to further reduction of cybersecurity risk in
V2V message exchange. We seek comment on what additional requirements,
if any, we might consider adding to the standard to mitigate
infiltration risk yet further. If commenters believe additional steps
are needed, we ask that they describe the protection mechanism and/or
approach as fully as possible, and also provide cost information to
accomplish them--or whether, if mandated, consumers should be provided
an option to disable V2V for cybersecurity reasons.
    Regarding the concern that V2V equipment, if hacked, can create a
safety risk, NHTSA expects manufacturers to ensure that vehicle systems
take appropriate safe steps to the maximum extent possible, even when
an attack may be successful.\173\ These can include protective/
preventive measures and techniques like isolation of safety-critical
control systems networks or encryption and other hardware and software
solutions that lower the likelihood of a successful hack and diminish
the potential impact of a successful hack; real-time intrusion

detection measures that continually monitor signatures of potential
intrusions in the electronic system architecture; real-time response
methods that mitigate the potential adverse effects of a successful
hack, preserving to the extent possible the driver's ability to control
the vehicle; and information sharing and analysis of successful hacks
by affected parties, development of a fix, and dissemination of the fix
to all relevant stakeholders. In July 2015, in response to NHTSA's
challenge, the auto industry created an Information Sharing and
Analysis Center (``ISAC'') to help the industry proactively and
uniformly address cybersecurity threats, and we would expect that such
a body could be a useful forum for addressing V2V-related security
risks, if any. A number of auto manufacturers are also rapidly ramping
up internal teams to identity and address cybersecurity risks
associated with new technologies.\174\
---------------------------------------------------------------------------

    \173\ Additional information about NHTSA's approach to
automotive cybersecurity is available at http://www.nhtsa.gov/About+NHTSA/Speeches,+Press+Events+&+Testimonies/NHTSA+and+Vehicle+Cybersecurity (last accessed Sept. 23, 2015).
    \174\ See, e.g., King, Rachel, ``GM Grapples with Big Data,
Cybersecurity in Vehicle Broadband Connections,'' Wall Street
Journal, Feb. 10, 2015. Available at http://blogs.wsj.com/cio/2015/02/10/gm-grapples-with-big-data-cybersecurity-in-vehicle-broadband-connections/ (last accessed Dec 7, 2016).
---------------------------------------------------------------------------

    In March 2014, researchers from Galois, Inc. issued a white paper
with specific recommendations for reducing security risk associated
with V2V communications, which they stated would ``automatically rule
out a whole class of security vulnerabilities'' at low cost with known
technologies.\175\ The recommendations were as follows:
---------------------------------------------------------------------------

    \175\ See Launchbury, John, Dylan McNamee, and Lee Pike, Galois
Inc., ``A Technique for Secure Vehicle-to-Vehicle Communication,''
Mar. 9, 2014. Available at http://galois.com/wp-content/uploads/2014/07/whitepaper_SecureInterfaces.pdf (last accessed Dec 7, 2016).
---------------------------------------------------------------------------

     All legal inputs shall be specified precisely using a
grammar. Inputs shall only represent data, not computation, and all
data types shall be unambiguous (i.e., not machine-dependent). Maximum
sizes shall be specified to help reduce denial-of-service and overflow
attacks.
     Every input shall be checked to confirm that it conforms
to the input specification. Interface messages shall be traceable to
mission-critical functionality. Non-required messages should be
rejected.
     Parsers and serializers shall be generated, not hand-
written, to ensure they do not themselves introduce any security
vulnerabilities. Evidence should be provided that
    [cir] parse(serialize(m)) = m, for all messages m, and
    [cir] parse(i) = REJECT, for all non-valid inputs i.
     Fuzz testing shall be used to demonstrate that
implementations are resilient to malicious inputs.
     A standardized crypto solution such as AES-GCM shall be
used to ensure confidentiality, integrity, and the impossibility of
reply attacks.
    DARPA staff, in discussing V2V cybersecurity issues with DOT
researchers, recommended these techniques be included in any V2V
requirements going. NHTSA seeks comment on whether these specific
techniques should be incorporated into the proposed FMVSS requirements,
and if so, how; alternatively, NHTSA seeks comment on whether these
techniques should be incorporated prior to vehicle manufacturer
certification with the FMVSS, and if so, how, and how NHTSA would
verify their incorporation.
4. Health
    As discussed in more detail below in Section IV.E, a number of
individual citizens commented to the ANPRM and Readiness Report that
they were concerned about what they believed to be potentially negative
health effects that could result from a DSRC mandate. As discussed in
Section IV.E below, NHTSA has considered this issue carefully, and
whether there are ways to mitigate these concerns without obviating the
very real safety benefits that a V2V mandate will enable. We believe
that consumer education, undertaken both by the Federal government and
by vehicle manufacturers, may help to alleviate some of these concerns.
5. Research Conducted on Consumer Acceptance Issues
    Working with Booz Allen Hamilton, NHTSA has conducted additional
research on consumer acceptance issues since the ANPRM and Readiness
Report. The objective of the research was to conduct both qualitative
and quantitative research to broaden our understanding of consumers'
acceptance of V2V technology and to inform future outreach and
communication efforts to the public. The qualitative phase included
focus groups held in Spring of 2015. Focus group participants were
shown a brief video on what V2V communications are, how they work, and
how they contribute to vehicle safety, and then asked to discuss a
series of questions about the technology, their understanding of it and
interest in it, and benefits and drawbacks. Overall, on a scale of 1 to
10, the majority of focus group participants rated their interest in
V2V as a 5 or higher for the next car. However, participants also
expressed concern that the technology would not be effective if it were
not universally adopted, and that over-reliance on or distraction by
V2V warnings could cause drivers to become less attentive and increase
risk. Although most focus group participants believed that V2V would
allow drivers to be tracked, few were concerned with the privacy
implications of tracking.\176\
---------------------------------------------------------------------------

    \176\ ``Vehicle to Vehicle Crash Avoidance Safety Technology:
Public Acceptance Final Report'' December, 2015. Available at Docket
No. NHTSA-2016-0126
---------------------------------------------------------------------------

    Following the conclusion of the focus groups and analysis of their
findings, a survey was developed for online quantitative testing to
examine these issues further. The survey was conducted by Ipsos, under
contract to BAH. The survey sought to evaluate several objectives:
     What is the degree of public acceptance of V2V?
     What proportion of people are concerned about each
barrier? How much importance is attached to that concern?
     What proportion of people agree with the potential
benefits of V2V? How much importance is attached to that benefit?
     How does the population differ on the above viewpoints
(age, gender, urbanicity, etc.)?
     What are predictors of acceptance of V2V technology (age,
gender, urbanicity, etc.)?
    Over 1,500 people responded to the survey, and the sample was
matched to the target population on age, gender, ethnicity, income, and
region. Respondents viewed a brief informational video about V2V, and
then answered 35 questions. Approximately half of respondents were
interested in having V2V in their next car, with ``accepters'' tending
to be male, older, urban, and more educated. All responses had a margin
of error of 2.5 percent
    In terms of barriers or concerns, 69 percent of respondents
believed that V2V would encourage other drivers to be too reliant and
less attentive to the driving task, and over 50 percent expressed
concern about cybersecurity and the need for enough vehicles to be
equipped for the benefits to accrue. Between 30 and 40 percent
expressed concern about tracking by the government or law enforcement
and about the risk that they themselves could become too reliant and
inattentive to driving. Only 20 percent expressed concern about health
risk from electromagnetic activity. Of those concerns, however, some
were deemed

more important than others (that is, simply because respondents
identified a risk, did not necessarily mean that they considered it an
important risk). Respondents viewed law enforcement and government
tracking as less important, but cybersecurity, other drivers'
inattentiveness, and health risks as more important, when they were
concerned about them.
    In terms of benefits of V2V, 55 percent of respondents believed
that V2V would reduce the number and severity of vehicle crashes, 53
percent believed that it would make driving more convenient and
efficient, and 50 percent believed that V2V could lower insurance
rates. As for barriers, respondents tended to believe that benefits for
others would be somewhat greater than the benefits that they themselves
would experience. Importance did not vary as much for benefits as it
did for barriers.
    In terms of how opinions about benefits and barriers correspond to
whether a respondent wanted V2V in their next car, the survey results
found that, on balance, all respondents were concerned about barriers,
but ``accepters'' of V2V rated the benefits more highly. When asked how
much they would be willing to pay for V2V, 78 percent of respondents
were willing to pay less than $200.
    Based on the research conducted thus far and assuming that the
survey respondents are, as intended, reasonably representative of the
nation as a whole, it appears that while there may be work yet for the
agency and manufacturers to do in order to reassure consumers of V2V's
benefits, there may not be a sufficient public acceptance problem that
an FMVSS requiring V2V communications in new vehicles would face clear
legal risk on that issue. NHTSA intends to continue researching
approaches to consumer outreach on V2V and will work with industry and
other relevant stakeholders in doing so. We seek comment on what the
agency should consider in developing those approaches to best ensure
the success of a future V2V system.
6. User Flexibilities for Participation in System
    In the ANPRM, we sought comment on whether there were any issues
relating to consumer acceptance that the agency had not yet considered,
and asked how the agency should consider them for the NPRM. In
response, a number of individual commenters expressed concern that they
experience extreme sensitivity to electromagnetic radiation, and that
therefore DSRC should not be mandated, or that if it was mandated, that
the agency should allow drivers to disable it. Health issues raised in
comments are covered below in Section IV.E, but the question of whether
the agency should require or permit an ``off switch'' for V2V
communications arose when commenters suggested it as a way to mitigate
concerns over health effects. A handful of other individual commenters
stated that the agency should allow drivers to turn off DSRC for
privacy or security reasons, out of concern that DSRC transmissions
could allow their movements to be tracked, or that the device could be
hacked by malicious third parties to obtain personal information about
the driver. A number of individual commenters raising these concerns
about health or tracking suggested that they would attempt to disable
V2V in their vehicles, or only purchase older vehicles without V2V.
    While NHTSA had asked in the ANPRM whether commenters had thoughts
regarding whether V2V-based warnings should be permitted to be modified
or disabled,\177\ in the interest of maximizing safety benefits, NHTSA
had not considered allowing manufacturers to provide consumers with a
mechanism to disable V2V itself, whether temporarily or permanently.
---------------------------------------------------------------------------

    \177\ See 79 FR 49270, at 49272 (Aug. 20, 2014) (Question 13 in
the ANPRM asks whether commenters believe that V2V-based warnings
should be permitted to be modified or disabled).
---------------------------------------------------------------------------

    Generally, if NHTSA concludes that a vehicle system or technology
provides sufficient safety benefits that it should be required as an
FMVSS, NHTSA has not permitted it to be disabled. In fact, Congress
expressly prohibits manufacturers, distributors, dealers, and motor
vehicle repair businesses from knowingly making inoperative any part of
a device or element of design installed on or in a motor vehicle in
compliance with an applicable motor vehicle safety standard prescribed
by NHTSA.\178\ In some cases, however, NHTSA has established FMVSSs
that permit system disablement or alteration when there is a clearly-
defined safety need for doing so.
---------------------------------------------------------------------------

    \178\ See 49 U.S.C. 30122(b).
---------------------------------------------------------------------------

    For example, FMVSS No. 126 for electronic stability control (ESC)
allows manufacturers to include an ``ESC Off'' control that puts the
system in a state where ESC does not meet the FMVSS performance
requirements, as long as the system defaults to full ESC capability at
the start of the next ignition cycle and illuminates a telltale in the
meantime to warn the driver that ESC is not available.\179\ NHTSA
allowed the ESC Off control because we were aware that in certain
driving situations, ESC activation could actually make driving less
safe rather than more safe--if a driver is stuck in deep snow or sand
and is trying to free their vehicle, quickly spinning wheels could
cause ESC to activate when it should not. Additionally, the agency was
concerned that drivers who did not have the option of disabling ESC
when absolutely necessary might find their own, permanent way to
disable ESC completely. Having an off switch that reverted to full
functionality at the next ignition cycle at least allowed ESC to
continue providing safety benefits the rest of the time. NHTSA
concluded that allowing temporary disablement was better than risking
the permanent loss of safety benefits.\180\
---------------------------------------------------------------------------

    \179\ See 49 CFR part 126, S5.4. We note that despite the
overarching requirement to return to full functionality at the new
ignition cycle, S5.4 does not require ESC to return to full
functionality if the vehicle is in a mode for ``low-speed, off-road
driving,'' or if the front and rear axles are locked because the
vehicle is in some sort of 4WD mode.
    \180\ 72 FR at 17279-80 (Apr. 6, 2007).
---------------------------------------------------------------------------

    As another example, FMVSS No. 208 for occupant crash protection
allowed manufacturers to include a device up until September 1, 2012,
that deactivated the right front passenger seat air bag, but only in
vehicles without a second row of seating, or in vehicles where the
second row of seating is smaller than a specified size.\181\ Like the
ESC Off function, the ``passenger air bag off'' function also requires
a telltale to illuminate to warn the driver that the air bag is
disabled; unlike the ESC Off function, the passenger air bag off
function, if present, remains deactivated until it is reactivated by
means of the deactivation device (i.e., the driver presses the button
again, rather than the air bag simply reactivating at the start of the
next ignition cycle).\182\ In establishing this option, the agency
noted public acceptance issues with advanced air bags, and stated that
allowing on-off switches for some period after all vehicles were
equipped with advanced air bags would help parents feel more confident
about the system's reliability based on real-world experience.\183\
---------------------------------------------------------------------------

    \181\ See 49 CFR part 208, S4.5.4.
    \182\ Id.
    \183\ Deactivation of the ``advanced'' right front passenger air
bag was primarily intended to address the possibility that, in
vehicles with no (or very small) back seats, a child seat might have
to be placed in the front passenger seat rather than in the back.
The primary mechanism to mitigate the risk of the front passenger
air bag deploying when a child seat is present is a suppression
system, but the agency allowed vehicle manufacturers to include an
off switch for several years to improve parents' confidence that the
suppression systems were working successfully in the field. See 65
FR at 30723 (May 12, 2000).

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

    Thus, in prior instances when NHTSA has allowed drivers the option
of changing or disabling the functionality of a required safety system,
it has been in the interest of providing more safety. Similarly, were
V2V to impose substantial new safety risks, there could be a safety
reason to disable transmission and reception of messages. To the extent
that consumers may wish that the agency allow a way for them to disable
V2V because of concerns about privacy or cybersecurity, we reiterate
our position as discussed in Sections IV.B and IV.C on privacy and
Section V on security we have worked to design requirements that reduce
the possibility of such threats. To the extent that consumers wish a
mechanism to disable V2V devices out of concern over potential health
effects, we note simply that disabling your own V2V unit would not help
you avoid V2V transmissions, because other light vehicles will also be
equipped with the technology, and if you have your own vehicle it is
presumably for the purpose of traveling to places where other vehicles
also go. Turning V2V off for this reason would forfeit the safety
benefit of being ``seen'' by other vehicles'' and ``seeing'' other
vehicles, without providing any other benefit.
    Moreover, unlike for most of the prior technologies in which NHTSA
allowed drivers the option of changing or disabling the functionality
of a required safety system, allowing V2V communications to be disabled
would affect the safety of more drivers than just the driver who turned
off their own V2V device. A cooperative system like V2V protects you by
making you more ``visible'' to other drivers and by letting you know
when they pose imminent risks to you. A driver who disables V2V on
their vehicle makes their vehicle less visible to other drivers,
potentially affecting their own relative safety risk and the safety
risk to those around them. The safety benefits from a cooperative
system could be undermined by allowing drivers to opt out. If there is
no safety benefit from opting out, and doing so would undermine safety
benefits both for the driver who opts out and for drivers around them,
opting out may not be justified.
    However, V2V is a novel technology concept in the transportation
context, which differs in some ways from other technologies covered by
the FMVSS. NHTSA recognizes that, as discussed elsewhere in this
notice, any technology that is required to transmit and receive
information on a persistent basis creates potential privacy and
cybersecurity risks. NHTSA is making every effort to reduce these risks
while setting requirements that would provide life-saving benefits.
That said, we acknowledge that there may be circumstances when there
could be a need to deactivate the V2V device on a vehicle. These may
include individuals or groups with specific privacy needs, the
emergence of unanticipated cybersecurity threats, or other reasons. To
address these cases, NHTSA is requesting comment on possible approaches
to deactivating V2V related hardware and software as and when
appropriate, as well as the costs and benefits of such approaches.
These could include deactivations initiated by drivers, manufacturers,
or the government; with different scopes, such as vehicle-specific or
broader deactivations; with different lengths, such as for a single key
start or more long-lasting; and with different levels of ease, such as
an accessible consumer-friendly method or one that would require
mechanical expertise.

C. Consumer Privacy

    NHTSA takes consumer privacy very seriously. Although collection of
data by on-board systems such as Event Data Recorders and On-Board
Diagnostic systems is nothing new, the connectivity proposed by the
Agency will expand the data transmitted and received by cars. V2V
systems will create and transmit data about driver behavior and the
surrounding environment not currently available from most on-board
systems. For this reason, V2V and future vehicle to infrastructure and
pedestrian (V2X) technologies raise important privacy questions.
    The agency is committed to regulating V2V communications in a
manner that both protects individuals and promotes this important
safety technology. NHTSA has worked closely with experts and our
industry research partners (CAMP and the VIIC) to design and deploy a
V2V system that helps protect consumer privacy. As conceived, the
system will contain multiple technical, physical, and organizational
controls to reduce privacy risks--including those related to vehicle
tracking by individuals and government or commercial entities. As
proposed, V2V messages will not contain information directly
identifying a vehicle (as through VIN, license plate or registration
information) or its driver or owner (as through name, address or
driver's license number), or data ``linkable, as practical matter,'' or
``reasonably linkable'' to an individual. NHTSA intends for these terms
to have the same meaning, specifically: Capable of being used to
identify a specific person on a persistent basis without unreasonable
cost or effort, either in real time or retrospectively, given available
data sources. Our research to date suggests that using V2V
transmissions to track the path and activities of identified drivers or
owners, while possible, could be a complex undertaking and may require
significant resources and effort.\184\ The Agency has concluded that
excluding ``reasonably linkable'' data elements from the BSM will help
protect consumer privacy appropriately and meaningfully while still
providing V2V systems in vehicles with sufficient information to enable
crash-avoidance safety applications.
---------------------------------------------------------------------------

    \184\ See Reports: FHWA-JPO-15-237--``Final Design Analysis
Report'' September 18, 2015, FHWA-JPO-15-236--``Privacy Issues for
Consideration by USDOT Based on Review of Preliminary Technical
Framework (Final-Rev A)'' February 24, 2016, FHWA-JPO-15-235--
``Final Requirements Report'' September 11, 2015, and ``Technical
Memorandum: Modeling and simulation of Areas of Potential V2V
Privacy Risk'' March 8, 2016 located in Docket No. NHTSA-2016-0126.
---------------------------------------------------------------------------

    We request comment on the proposed mandate that the BSM exclude
data elements ``reasonably linkable'' to an individual (as that term is
defined above) and whether this appropriately balances consumer privacy
with safety. Additionally, will exclusion from the BSM of ``reasonably
linkable'' data elements undermine the need for a standard BSM data set
in furtherance of interoperability or exclude data required for safety
applications?
    NHTSA, with the support of the DOT Privacy Officer and NHTSA's
Office of the Chief Information Officer, conducted an interim privacy
risk assessment of the V2V system prior to issuance of the Readiness
Report and ANPRM. The interim assessment was intended to provide the
structure and serve as a starting point for NHTSA's planned PIA, which
is a more in-depth assessment of potential privacy impacts to consumer
privacy that might stem from a V2V regulatory action, and of the system
controls that mitigate those risks. On the basis of then available
information and stated assumptions, NHTSA's interim privacy assessment
identified the system's business needs, relevant system functions,
areas of potential risks, and existing/other risk-mitigating technical
and policy controls.
    NHTSA received a significant number of comments on the issue of
privacy in response to the ANPRM and Readiness Report. Generally, the
privacy comments related to consumer acceptance and reflected consumer
and industry concerns that the V2V system would be used by government
and

commercial entities to track the route or activities of individuals, or
would be perceived by individuals to have that capability. A vast
majority of the privacy comments addressed one or more of the following
areas:
    1. NHTSA's privacy impact assessment;
    2. ``privacy by design'' and data privacy protections;
    3. data access and privacy;
    4. consumer education; and
    5. Congressional or other government action related to V2V data.
    Since receiving these comments, NHTSA has worked closely with
privacy experts to identify and prioritize for further analysis
specific areas of potential privacy impact in the V2V system.
Additional privacy research, such as dynamic modeling related to
location tracking and analysis of PKI best practices, is underway that
will refine NHTSA's approach to mitigating potential privacy impacts
stemming from the V2V system. On the basis of the PIA, comments
received on the NPRM and PIA, and ongoing privacy research, agency
decision-makers will be in an informed position to determine whether
any residual risk (i.e., risk in the system that cannot reasonably be
mitigated) is acceptable--and, in the alternative, whether