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.

Date Posted

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

Summary Information

In September of 2015, USDOT selected New York City Department of Transportation (NYCDOT), Wyoming Department of Transportation (WYDOT) and Tampa Hillsborough Expressway Authority (THEA) as the recipients of a combined $42 million in federal funding to implement a suite of connected vehicle applications and technologies tailored to meet their region’s unique transportation needs under the Connected Vehicle Pilot Deployment Program.
Following the award, each site spent 12 months preparing a comprehensive deployment concept to ensure rapid and efficient connected vehicle capability roll-out. The sites next completed a 24-month phase to design, build, and test these deployments of integrated wireless in-vehicle, mobile device, and roadside technologies. As of early 2019, the sites are entering a third phase of the deployment where the tested connected vehicle systems will become operational for a minimum 18-month period and will be monitored on a set of key performance measures.

Given the promising future of connected vehicle deployments and the growing early deployer community, experiences and insights across all stages of the Design/Build/Test Phase of the CV Pilots have been collected to serve as lessons learned and recommendations for future early deployer projects and efforts.

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.