Home Page SCMS CV Pilots Documentation : SCMS CV Pilots Documentation

Last modified on Feb 20, 2018

Security Credential Management System Proof–of–Concept Implementation

EE Requirements and Specifications Supporting SCMS Software Release 1.2.2




Notice and Disclaimer

The initial SCMS Proof-of-Concept (POC) system was developed jointly through US DOT and the Crash Avoidance Metrics Partnership (CAMP). The SCMS POC was formally closed in October 2018, however the key concepts, systems architectures and interfaces developed during the POC development are still utilized by SCMS providers today. The following sections provide the systems architectures, SCMS processes and interface descriptions that are still relevant and useful to any organization that is implementing connected vehicle devices that interface with an SCMS.

Introduction

The Security Credential Management System (SCMS) Proof-of-Concept (POC) Implementation Project (SCMS POC Project) was initial conducted by the Crash Avoidance Metrics Partners LLC (CAMP LLC) Vehicle Safety Communications 5 (VSC5) Consortium. The goal of the SCMS POC design was to provide security services to support Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications at current production levels of passenger vehicles (up to 17 million annually) for the first year of deployment. An important goal of the SCMS POC system was to provide a flexible architecture that was capable of scaling to support larger numbers of V2V and V2I devices in the years following initial deployment. It was anticipated that the SCMS POC design would provide both a stable platform and a research platform to support the USDOT and industry research needs prior to deployment. The work was originally sponsored by the National Highway Traffic Safety Administration (NHTSA) through Cooperative Agreement DTNH22-14-H-00449/0003 and was later transitioned to the Intelligent Transportation Systems (ITS) Joint Program Office (JPO) to support the Connected Vehicle (CV) Pilot Projects.

This document presents the requirements and specifications that were developed for the SCMS POC System Release 1.2 from the perspective of an End Entity (EE). An EE is any device that would enroll and receive certificates from an SCMS such as an Onboard Unit (OBU) or Roadside Unit (RSU). This document reflects the SCMS interfaces that were defined as part of the SCMS POC, which formally ended in October 2018. Although the SCMS POC has ended the interfaces described in this document are still relevant across the SCMS provider community and a useful reference for EE vendors and agencies deploying CV devices.

Introduction for EE Developers

The following paragraph will guide you as an EE developer through this documentation highlighting requirements and API documentation in the order of an EE's lifecycle. If you implement your EE software following this guide, you should have a device at the end that is able to communicate with the SCMS throughout the whole lifecycle.

  1. First of all you need a Secure Environment for Device Enrollment where initialization and bootstrapping of your device will be executed
  2. You need to have a device that applies to the requirements and descriptions laid out in Hardware, Software and OS Security Requirements
  3. You need to have a True Random Number Generator
  4. Your device needs to support in either hardware or software Approved Cryptographic Algorithms
  5. You need to have an HTTP client that is able to communicate securely (HTTPS) to the SCMS as described in EE-RA Communications - General Guidance and EE-SCMS Core Communication Requirements
  6. You need to know which Certificate Types you need to have on your device, which depends on the SCMS PoC Supported V2X Applications that you want to run on your device
  7. The EE lifecycle starts with Use Case 2: OBE Bootstrapping (Manual), respectively Use Case 12: RSE Bootstrapping (Manual) depending on your EE type (OBE vs. RSE). Currently both processes are exactly the same.
  8. Based on the EE type you are developing, you then create and send one of the following requests. All devices should always check for a new local certificate chain file (API: RA - Download Local Certificate Chain File) and a new local policy file (API: RA - Download Local Policy File) before sending subsequent request. All requests in this step #8 should be sent within the same HTTPS session.
    1. Pseudonym Certificates:
      1. Following the process in Use Case 3: OBE Pseudonym Certificates Provisioning, your OBE should create a pseudonym certificate batch request as described in Step 3.1: Request for Pseudonym Certificates and send it to the RA API as documented in RA - Request Pseudonym Certificate Batch Provisioning. Your OBE needs to create the butterfly seed pairs as described in SCP1: Butterfly Keys. Your OBE will get a response from RA with an URL and a download time.
      2. Once your OBE's clock reaches download time, your OBE can download the initial pseudonym certificate batch at URL following the process in Step 3.3: Initial Download of Pseudonym Certificates using the RA API as documented in RA - Download Pseudonym Certificate Batch and the .info file using RA's API documented in RA - Download .info File.
    2. Application Certificate:
      1. Following the process in Use Case 13: RSE Application Certificate Provisioning, your RSE should create an application certificate request as described in Step 13.1: Request RSE Application Certificate and send it to the RA API as documented in RA - Request Application Certificate Provisioning. Your RSE will get a response from the RA with an URL and a download time.
      2. Once your RSE's clock reaches download time, your RSE can download the application certificate at URL following the process in Step 13.3: Download RSE Application Certificate using the RA API as documented in RA - Download Application Certificate.
    3. OBE Identification Certificate:
      1. Following the process in Use Case 19: OBE Identification Certificate Provisioning, your OBE should create an identification certificate request as described in Use Case 19: OBE Identification Certificate Provisioning and send it to the RA API as documented in RA - Request Identification Certificate Provisioning. Your OBE will get a response from RA with an URL and a download time.
      2. Once your OBE's clock reaches download time, your OBE can download the identification certificate at URL following the process in Step 19.3: Initial Download of OBE Identification Certificates using the RA API as documented in RA - Download Identification Certificate and the .info file using RA's API documented in RA - Download .info File.
  9. Depending on the certificate type, the SCMS constantly pre-generates them and your EE can download top-offs like this:
    1. Pseudonym Certificates: Whenever it suits your pseudonym certificate download strategy at a point of time that is after the time given in the .info file, follow the process described in Step 3.5: Top-off Pseudonym Certificates using RA's API documented in RA - Download Pseudonym Certificate Batch to download additional pseudonym certificates.
    2. Identification Certificate: Whenever it suits your identification certificate download strategy at a point of time that is after the time given in the .info file, follow the process described in Step 19.5: Top-off OBE Identification Certificates using RA's API documented in RA - Download Identification Certificate to download the next identification certificate.
  10. Your EE should download the latest CRL as often as possible but no later than once a week using the process described in Use Case 6: CRL Download using the API documented in MA - Download CRL.
  11. Your EE must verify incoming messages. Part of the verification is to check if the senders certificate was revoked following the process described in Step 8.4: OBE CRL Check, respectively Step 16.4: RSE CRL Check, as well as if a CA certificate in their certificate chain was revoked.
  12. Report misbehavior: This is still TBD and will be supported with SCMS Release 2
  13. Re-enroll: This is still TBD and will be supported with SCMS Release 2

Available Pages