Early CV deployers must assess existing agency systems and networks as well as their change control procedures to accommodate the security needs of CV technology.

Lessons Learned from the Design/Build/Test Phase of the USDOT’s Connected Vehicle Pilot Program.

Wyoming; United States; New York City; New York; United States; Tampa; Florida; United States

Background (Show)

Lesson Learned

The following lessons address changes agencies may have to make to their existing systems and/or operations to accommodate the security needs of CV technology. Emphasis is particularly placed on the utilization of a Security Credential Management System (SCMS) that uses Public Key Infrastructure (PKI) to employ encryption and certificate management to facilitate trusted communication between the vehicles and the surrounding infrastructure.

Address security in all aspects of the CV and agency systems
    Recognize that the security requirements of the system extend to the agency’s networks and computer systems and will likely require changes to existing systems and/or operations. To address the security needs of CV technology, the Pilots made numerous changes to their security procedures regarding:
    • Operations – password control (strength) and expiration, physical access to facilities such as TMCs, encryption of databases
    • Communications – upgrades to the ITS environment to provide increased security – especially where NTCIP is concerned; VPN tunnels, DTLS and TLS protocols using x.509 certificates; disabling local access ports without security.
    • Maintenance – requiring authentication of field personnel in real time when replacing failed devices; devices have a collection of enrollment certificates; keypad interactions to use USB access to reload and re-initialize the device.
Maintain a physical separation between CV networks and any tolling networks
    For THEA, an agency that develops and owns toll highways, it was critical that the CV operations and data be kept separate from their revenue-producing toll operations and data. THEA purchased and implemented a firewall to ensure that a complete separation of the tolling network as a general standard would be maintained throughout the CV Pilot.

Tap limited available vendor and supplier resources to their fullest extent when certifying devices for enrollment in a SCMS
    One area that appeared to be more challenging and time consuming than originally envisioned was getting the CV devices certified through OmniAir (a USDOT requirement for the CV Pilot sites). OmniAir's V2X certification program offers conformance and interoperability testing for DSRC-based V2V and V2I devices to ensure that the products conform to industry protocol standards and specifications to bring about trusted device communications. Vendors supporting the CV Pilot deployments were the first group to attempt certification. As a result, there were uncertainties and risks related to certification that arose, which had to be managed and mitigated by both CV Pilot deployments and the device vendor community.

    To the extent that these factors were a barrier to timely progress toward deployment and operations, sites were encouraged to work with partners, suppliers, and vendors to establish clear priorities and identify critical path items and resource constraints and work holistically to maintain continued progress. In particular, dialogue with the SCMS vendor facilitated an understanding of what testing and certification-related results were critical predecessors to deployment and operations, and what items could be addressed incrementally during operations.

Implement a credential management misbehavior detection feature to address vulnerabilities to cyber attacks, spoofing and malfunctioning equipment
    The security credential management system (SCMS) does not currently have a standard Misbehavior Detection and Certificate Revocation List (CRL) distribution mechanism – both of which are essential to maintain the security of the CV infrastructures.

    Recognizing the absence of Misbehavior Detection and a CRL, the New York City team chose to load only one week’s worth of future certificates onto the OBUs (as opposed to the maximum three-year supply) to minimize the potential impact of compromised units.

    It should be noted that USDOT is currently facilitating close coordination among device vendors and the SCMS provider to deliver the software utilities for an early, minimum viable Misbehavior Detection capability to support the CV Pilot Deployment sites.

Identify all Provider Service Identifiers (PSIDs) for all applications being implemented prior to enrollment in the SCMS
    Each enrollment certificate is associated with a particular application that is mapped to a particular Provider Service Identifier (PSID) (enrollment certificates cannot have an empty PSID field). For this reason, users must decide on what applications the device will be supporting and their corresponding PSIDs before enlisting in enrollment. If additional applications are added later on, devices will have to go through the enrollment process again, which requires additional security mechanisms that may require bringing a device to a special secure facility. This was something that the Pilots were made aware of and have had to plan their operational deployments around.

Initiate message signing requirements for message types without pre-existing security protocols
    The SAE V2X Security technical committee is currently working to develop Service Specific Profiles (SSPs) specifications for a number of PSIDs, however in the meantime there is currently no standard SSP guidance for a number of PSIDs including the PSIDs utilized for TIM, SPAT and MAP. Following coordination on deciding what PSIDs that they would be using, the Pilots worked to develop their own independent SSPs for those PSIDs where official guidance was missing. Those SSPs are open source and available upon request. They provide a good starting point for other deployment agencies utilizing those PSIDs.

Provision vehicles with a sufficient number of pseudonym certificates
    The sites’ SCMS allocated light vehicles with just 20 certificates per week to use during their period of validity changing every 5 minutes or 2 KM – whichever came first.
    The NYC Pilot was concerned that 20 certificates per week would be insufficient to ensure anonymity for their taxi fleets that are in service an average of 14 hours per day. To provide better protection against “tracking?, the NYC team boosted the number of certificates provided to each device to 60 certificates per week. Note that while this is a change SCMS vendors can support, it would likely not be the default option. Deployment agencies should identify these types of use cases early and work with their SCMS vendor to address those use cases.

Implement proper certificate change requirements to prevent vehicle tracking
    During development, the New York City Connected Vehicle Pilot Deployment team identified an issue with the SAE J2945/1 Standard’s Certificate Change (CERTCHG) requirement criteria that was potentially putting the privacy of their participants at risk.

    The CERTCHG requirement calls for certificates to be changed every five minutes but contains an exception involving the "absolute distance" from the previous certificate change location. The exception states that a certificate change does not occur should the System be "separated by less than 2 kilometers in absolute distance from the location at which the last certificate change occurred." Under the current absolute distance assumption, a vehicle traveling within an urban grid network (such as a taxi in NYC) may not trigger the certificate change mechanism.

    The team concluded that the "absolute distance" was not the proper criteria for an exception for their Pilot, as it was still possible for a vehicle to operate in a large area for an extended time period and not be required to change its certificate. The NYC team decided to implement a change mechanism that required certificates to change every 2 KM traveled or every 5 minutes – whichever comes first.

Refresh application certificates periodically
    Application certificates, which is what RSUs use to advertise and provide their services, are only valid for a limited time (usually one week). These types of certificates are not pre-generated for future validity periods like pseudonym certificates and must be requested on a week-to-week basis. Deployment agencies need to have mechanisms in place to allow RSUs to connect to the SCMS on at least a weekly basis in order to request and download new certificates.

Return devices to a secure environment for re-enrollment in the SCMS infrastructure
    While certificates can be downloaded while a vehicle is on the go, devices must be returned to a secure environment for re-enrollment. Ideally enrollment should occur in the same environment where maintenance is being performed. Another option is to have a process in place to have the removed devices for suspected improper operation sent back to the vendor for repair and validation or replacement of the enrollment certificates.

Lesson Comments

No comments posted to date

Comment on this Lesson

To comment on this lesson, fill in the information below and click on submit. An asterisk (*) indicates a required field. Your name and email address, if provided, will not be posted, but are to contact you, if needed to clarify your comments.


Connected Vehicle Pilot Deployment Program Driving Towards Deployment: Lessons Learned from the Design/Build/Test Phase

Author: Thompson, Kathy

Published By: USDOT Federal Highway Administration

Source Date: 12/13/2018

Other Reference Number: FHWA-JPO-18-712

URL: https://rosap.ntl.bts.gov/view/dot/37681

Other Lessons From this Source

Lesson Contacts

Lesson Analyst:

Kathy Thompson


Average User Rating

1 (2 ratings)

Rate this Lesson

(click stars to rate)

Lesson ID: 2019-00889