Use Case 2: OBE Bootstrapping (Manual)

Table of Contents

Background and Goals

The bootstrap process enables the OBE to interact with the SCMS.

Bootstrapping is executed at the start of the OBE's lifecycle. At the start of bootstrapping, the OBE has no SCMS certificates and no knowledge of how to contact the SCMS. At the end of bootstrapping the OBE has the following:

Certificates and information that allows an OBE to trust the SCMS:
- The required Root CA certificate(s), optional Intermediate CA and Pseudonym CA certificates to allow it to verify received messages. The OBE can learn unknown PCA and ICA certificates in ongoing operation as defined in IEEE 1609.2 P2P CD. At minimum, any EE needs the certificate chain of the PCA that issued certificates to it.
- The latest CRL (includes the CRL Generator certificate, which in turn includes the FQDN of the CRL store)
- The MA certificate to encrypt misbehavior reports, before submitting them to the RA
Credentials and information allowing an OBE to communicate with the SCMS:
- A correctly issued enrollment certificate, private key reconstruction value, and ECA certificate.
- The RA certificate (which includes the FQDN of the RA).

Bootstrapping must protect the OBE from getting incorrect information, and the ECA from issuing a certificate to an unauthorized OBE. Any bootstrapping process is acceptable, that results in secure placement of this information on an OBE device.

Assumptions and Preconditions

A documented procedure for performing the enrollment process.
A “secure environment” as defined in Secure Environment for Device Enrollment, ensures that the OBE is under control of the operator running the bootstrapping operation.
One or more authorized devices (computers) for managing the enrollment process.
An activity log or recording of the enrollment operations performed.
A user account at the USDOT workflow tool.

Process Steps

Manual Bootstrapping Process - QA Environment

The CV Pilot will initially use a manual bootstrapping process that combines device initialization and enrollment. The following process applies to the SCMS QA stage. The vendor will initiate this process by requesting device initialization information and enrollment certificate from a DOT Workflow Approval tool, as depicted in this process:

Step	Actor	Description	Status	Assignee
1	Vendor	Logs into CVCS Samanage, initiates an enrollment certificate request. There is a dedicated form for that.	New	USDOT
2	USDOT	Logs into CVCS Samanage and reviews the enrollment certificate request form. They ensure that: The vendor is on the list of known vendors for CV device manufacture. If the request is not correct, USDOT will deny the request, and the vendor will need to correct the request and resubmit through Step 3. USDOT Personnel approve the request, if it meets the above criteria, and USDOT sends the request back to the Vendor for them add the enrollment certificate signing request.	Awaiting Customer Input	Leidos
3	Vendor	The vendor in his secure environment generates in each OBE a verification key pair (see Public Key Algorithms in CB2: Types of Cryptographic Algorithms). The private key is used to sign the enrollment certificate request (CSR) in step 4. The public key is added to the request and used by the ECA subsequently as input to calculating the public value within the implicit certificate, issued at end of this process. NOTE: The verification key pair must be generated using an algorithm approved for use (see Approved Cryptographic Algorithms, Approved Random Number Generators). Best practice is to generate the verification key pair inside the EE's HSM and the private key never leaves the EE.	Awaiting Customer Input	Leidos
4	Vendor	The vendor in a secure environment creates an enrollment certificate signing request for each device, a signed structure called SignedEeEnrollmentCertRequest. The CSR includes the verification public key to use to create the public key reconstruction value in the enrollment certificate. The enrollment certificate request permissions (PSIDs, SSPs, Geographic Region) and lifetime are stated in the CSR as well. The vendor signs the CSR with the device’s private key, and writes the CSR to a file with filename format <enrollment pub hex>.oer in OER encoding. The vendor then collects multiple CSRs, places them in a flat directory and zips the directory. The directory structure within the zip file should look identical to the following example. IMPORTANT: DUE TO AUTOMATED PROCESSING OF REQUESTS, DEVIATIONS FROM THIS ZIPFILE AND DIRECTORY STRUCTURE WILL RESULT IN REQUESTS FAILING TO BE PROCESSED. Enrollment Request Zip File Example Expand source + 4A2...BC1.oer + 61C...E1F.oer + ... + ... + 23B1...5FF.oer	Awaiting Customer Input	Leidos
5	Vendor	Vendor logs into CVCS Samanage and attaches the enrollment request zip file to the previous enrollment request form.	Awaiting Customer Input	Leidos
6	Leidos	Reviews Enrollment Request Form and ensures files have been attached and manually verifies the following fields: PSID Region	Assigned	SCMS Operations
7	SCMS Operations	Logs into CVCS Samanage and downloads the enrollment certificate request zip file.	Work in Progress	SCMS Operations
8	SCMS Operations	Executes their enrollment requests script to create enrollment certificates. If successful move to Step 9. The ECA generates and returns an enrollment certificate for each individual request. The response is a signed structure called SignedEeEnrollmentCertResponse. The SCMS operator collects all ECA responses, creates a directory structure that includes bootstrapping information as well as one directory per CSR using the filename of the CSR as directory name. Each of those directories contains the RA certificate to be used by the OBE to communicate with the SCMS, the certificate of the ECA that signed the enrollment certificate, as well as the enrollmentCert itself and the privKeyReconstruction. The SCMS operator zips all files into a single zip file. Following the example in step 4, the directory structure within the zip file would look like this (please be aware that the Root CA certificate is explicitly given in the file root.oer): Enrollment Resonse Zip File Example Expand source + root.oer: IEEE 1609.2 root CA certificate encoded as OER + LCCF.oer: current Local Certificate Chain File including ICA and PCA certificates. + LPF.oer: current Local Policy File + CRL.oer: current Certificate Revocation List + root.tls: TLS (X.509) root certificate RA’s TLS cert chains to + 4A2...BC1 (dir) \| +RA.oer: RA’s 1609.2 certificate \| +ECA.oer: ECA’s 1609.2 certificate \| +enrollment.oer: (EE’s enrollment certificate, see enrollmentCert as part of the ECA response SignedEeEnrollmentCertResponse) \| +enrollment.s: (EE’s Private key reconstruction value, see privKeyReconstruction as part of the ECA response SignedEeEnrollmentCertResponse) + 61C...E1F (dir) \| +RA.oer \| +ECA.oer \| +enrollment.oer \| +enrollment.s + ... + ... + 23B1...5FF (dir) \| +RA.oer \| +ECA.oer \| +enrollment.oer \| +enrollment.s	Work in Progress	SCMS Operations
8a	SCMS Operations	If SCMS Operations finds an error within the request, SCMS Operations will send the Error Response to the Vendor through the CVCS enrollment request.	Awaiting Customer Input	SCMS Operator
8b	Vendor	Requests help/clarification in understanding the error found in the enrollment certificate signing request as a comment to the Enrollment Request Form.	Work in Progress	Leidos
8c	Vendor	Looks for an existing solution that will fix the vendors error. If they find a solution they provide it to the vendor.	Awaiting Customer Input	SCMS Operator
8d	Vendor	If an existing solution cannot be found, Leidos requests the vendor submit the Technical Support form and sends the Vendor the link.	Awaiting Customer Input	SCMS Operator
8e	Vendor	Corrects the error and reattaches the enrollment certificate signing request to the Enrollment Request Form.	Awaiting Customer Input	SCMS Operator
9	SCMS Operator	Logs into the CVCS Samanage and creates an enrollment certificate response for the appropriate vendor and attaches the enrollment response zip file.	Resolved	Vendor
10	Vendor	Vendor logs into CVCS Samanage and downloads their device enrollment certificates in their secure environment.	Resolved	Vendor
11	Vendor	The vendor loads the appropriate enrollment certificate onto the appropriate device, in their secure environment.	Resolved	Vendor

Manual Bootstrapping Process - PROD Environment

The CV Pilot will initially use a manual Bootstrap Process that combines device initialization and enrollment. The process on the SCMS PROD stage is essentially the same as for QA (see QA process above) with the exception that the vendor must first submit their OBE device to a certification lab for certification before requesting the device enrollment certificate. The complete process is described below:

Vendor submits their device to one of the device certification companies for certification. Vendor logs into DOT Workflow Approval tool and creates a device certification request, for a specific model of device, selecting the appropriate device certification company.
Device certification company conducts device certification testing. After successful completion of certification, device certification company notifies DOT Workflow Approval tool of certification for the specific device model, and attaches certification documentation. DOT Workflow Approval tool notifies the vendor and USDOT of the approval, and maintains device certification documentation in database of certified devices.
to 11. Same as step 1-9 in QA

Enrollment certificate request checks

The following checks have to be done in step 6:

The CSR only contains PSID from SCMS PoC Supported V2X Applications
The CSR only contains PSIDs the device is eligible to
The CSR contains the right SSP values for the requested PSID
The CSR only contains SSP values the device is eligible to
The CSR only contains Region USA
The CSR does not contain a public key that was used with a previous enrollment cert request
The CSR does have a validity period that fits the ECA's validity period
The CSR contains the correct cracaId
The CSR contains the correct crlSeries
The CSR contains a useful CertificateId

OBE Bootstrap Process Logging Requirement

The following bootstrap operation information must be logged and maintained by the organization performing the PROD bootstrapping process, for each unique device, and for each enrollment certificate, if multiple enrollment certificates are requested for a single device.

OBE serial number or unique unit identifier
Initial Bootstrap Start Date
Bootstrap LCCF file version identifier
Bootstrap LPF file version identifier
Enrollment cert
Bootstrap Complete Date

Enrollment Certificate Request Example

The following clear text is an example for an enrollment certificate request that we provide in an OER encoded version, as it is supposed to be sent during manual enrollment.

Clear Text Before Signing/Encrypting

value ScmsPDU ::= {
  version 1,
  content eca-ee : eeEcaCertRequest : {
    version 1,
    currentTime 431026272,
    tbsData {
      id name : "obeenr",
      cracaId '000000'H,
      crlSeries 4,
      validityPeriod {
        start 431026272,
        duration hours : 4320
      },
      region identifiedRegion : {
        countryOnly : 124,
        countryOnly : 484,
        countryOnly : 840
      },
      certRequestPermissions {
        {
          subjectPermissions explicit : {
            {
              psid 32,
              sspRange opaque : {}
            },
            {
              psid 38,
              sspRange opaque : {}
            }
          },
          minChainDepth 0,
          chainDepthRange 0,
          eeType {app}
        }
      },
      verifyKeyIndicator verificationKey : ecdsaNistP256 : compressed-y-1 : '8751D2FDC5D7BF8CCE4A7FACE5E5AD7B92FA6B8CA0B202FBC93CBC08412AA934'H
    }
  }
}

Textual After Signing/Encrypting (SecuredScmsPDU Layer)

value SecuredScmsPDU ::= {
  protocolVersion 3,
  content signedCertificateRequest : '00018180000119B0F0604481066F6265656E72000000000419B0F0608410E083010380'H -- truncated --
}

Binary (Hexadecimal) After Signing/Encrypting

038381a500018180000119b0f0604481066f6265656e72000000000419b0f0608410e083010380007c8001e480034801018080010280012080010080012680010001008080838751d2fdc5d7bf8cce4a7face5e5ad7b92fa6b8ca0b202fbc93cbc08412aa934828080301d57f8d01e98c685428c49328be8164bae24e18d46030048911c5fd4275df73121b89c7919fd75d7ab411cfb254a44660997f7b1ae9235f2d0f1949198826

Textual After Signing/Encrypting (SignedCertificateRequest Layer)

value SignedCertificateRequest ::= {
  hashId sha256,
  tbsRequest {
    version 1,
    content eca-ee : eeEcaCertRequest : {
      version 1,
      currentTime 431026272,
      tbsData {
        id name : "obeenr",
        cracaId '000000'H,
        crlSeries 4,
        validityPeriod {
          start 431026272,
          duration hours : 4320
        },
        region identifiedRegion : {
          countryOnly : 124,
          countryOnly : 484,
          countryOnly : 840
        },
        certRequestPermissions {
          {
            subjectPermissions explicit : {
              {
                psid 32,
                sspRange opaque : {}
              },
              {
                psid 38,
                sspRange opaque : {}
              }
            },
            minChainDepth 0
          }
        },
        verifyKeyIndicator verificationKey : ecdsaNistP256 : compressed-y-1 : '8751D2FDC5D7BF8CCE4A7FACE5E5AD7B92FA6B8CA0B202FBC93CBC08412AA934'H
      }
    }
  },
  signer self : NULL,
  signature ecdsaNistP256Signature : {
    r x-only : '301D57F8D01E98C685428C49328BE8164BAE24E18D46030048911C5FD4275DF7'H,
    s '3121B89C7919FD75D7AB411CFB254A44660997F7B1AE9235F2D0F19491988265'H
  }
}

value ScmsPDU ::= {
  version 1,
  content eca-ee : eeEcaCertRequest : {
    version 1,
    currentTime 431026272,
    tbsData {
      id name : "obeenr",
      cracaId '000000'H,
      crlSeries 4,
      validityPeriod {
        start 431026272,
        duration hours : 4320
      },
      region identifiedRegion : {
        countryOnly : 124,
        countryOnly : 484,
        countryOnly : 840
      },
      certRequestPermissions {
        {
          subjectPermissions explicit : {
            {
              psid 32,
              sspRange opaque : {}
            },
            {
              psid 38,
              sspRange opaque : {}
            }
          },
          minChainDepth 0
        }
      },
      verifyKeyIndicator verificationKey : ecdsaNistP256 : compressed-y-1 : '8751D2FDC5D7BF8CCE4A7FACE5E5AD7B92FA6B8CA0B202FBC93CBC08412AA934'H
    }
  }
}

Requirements

Key	Status	Summary	Description	justification	notes	Component/s

Loading...

Refresh

Additional Reference Information

ASN.1 Specification

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Include Bitbucket Server for Confluence: File content cannot be shown

Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Page tree

Background and Goals

Assumptions and Preconditions

Process Steps

Manual Bootstrapping Process - QA Environment

Manual Bootstrapping Process - PROD Environment

Enrollment certificate request checks

OBE Bootstrap Process Logging Requirement

Enrollment Certificate Request Example

Requirements

Additional Reference Information

ASN.1 Specification

CAMP LLC Proprietary.