PaperlayerView exact revision on arXiv

Source-linked AI summary

A Security Credential Management System for V2X Communications

Benedikt Brecht, Dean Therriault, André Weimerskirch, William Whyte, Virendra Kumar, Thorsten Hehn, Roy Goudy

arXiv:1802.05323v1cs.CR

TL;DR

V2X deployment requires security and privacy despite the enormous volume of certificates and the need to revoke misbehaving devices efficiently. The paper presents an SCMS using pseudonym certificates, separated certificate provisioning, and linkage values to address these requirements. The design supports identified V2X use cases and is positioned as a leading candidate for a US V2X security backend.

  • Problem

    V2X deployment must protect privacy and trust while efficiently revoking vehicles that receive large numbers of pseudonym certificates.

  • Method

    The paper designs an SCMS using pseudonym certificates, separation of duties, linkage values, and multiple certificate types for V2X applications.

  • Results

    The proposed SCMS supports identified V2X application categories and is designed to scale to approximately 300 billion certificates per year for 300 million vehicles.

  • Takeaways & Limitations

    The design provides a candidate security backend for a nationwide US V2X PKI while balancing security, privacy, and efficiency.

Abstract

from arXiv · show

The US Department of Transportation (USDOT) issued a proposed rule on January 12th, 2017 to mandate vehicle-to-vehicle (V2V) safety communications in light vehicles in the US. Cybersecurity and privacy are major challenges for such a deployment. The authors present a Security Credential Management System (SCMS) for vehicle-to-everything (V2X) communications in this paper, which has been developed by the Crash Avoidance Metrics Partners LLC (CAMP) under a Cooperative Agreement with the USDOT. This system design is currently transitioning from research to Proof-of-Concept, and is a leading candidate to support the establishment of a nationwide Public Key Infrastructure (PKI) for V2X security. It issues digital certificates to participating vehicles and infrastructure nodes for trustworthy communications among them, which is necessary for safety and mobility applications that are based on V2X communications. The main design goal is to provide both security and privacy to the largest extent reasonable and possible. To achieve a reasonable level of privacy in this context, vehicles are issued pseudonym certificates, and the generation and provisioning of those certificates are divided among multiple organizations. Given the large number of pseudonym certificates per vehicle, one of the main challenges is to facilitate efficient revocation of misbehaving or malfunctioning vehicles, while preserving privacy against attacks from insiders. The proposed SCMS supports all identified V2X use-cases and certificate types necessary for V2X communication security. This paper is based upon work supported by the USDOT. Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the Authors ("we") and do not necessarily reflect the view of the USDOT.

I. INTRODUCTION

V2X safety communications require a large-scale PKI that balances security, privacy, and efficiency. The proposed SCMS addresses privacy, certificate provisioning, and efficient revocation for V2V and V2I applications.

  • Threat model: Vehicles broadcast digitally signed Basic Safety Messages up to ten times per second, requiring security mechanisms that preserve trust without making vehicles easily trackable.BSMs contain time, position, speed, path history, and other relevant information.
  • System motivation: The SCMS is designed to support trustworthy V2X communications through a PKI managing digital certificates for participating devices.Its architecture was originally designed for V2V and later extended to V2I applications.
  • System motivation: 300 billion certificates per year are expected at full capacity for 300 million vehicles, far exceeding existing large PKI deployments.The comparison underscores the unusual scale of the proposed system.
  • Scope and contribution: The paper presents the SCMS design and provides rigorous arguments for its design decisions, while excluding cybersecurity aspects of the vehicle on-board DSRC platform and SCMS components.The authors identify component security as important to preserving the system’s safety-of-life benefits.
  • Threat model: Privacy threats from insiders and outsiders, along with authenticated bogus messages, are central threats addressed by the SCMS.The design uses privacy-preserving mechanisms for the first two threats and misbehavior detection with efficient revocation for the third.
  • Privacy and revocation: The SCMS uses pseudonym certificates and linkage-value-based revocation because each V2V device receives many certificates.Traditional certificate revocation lists would become too large in this setting.

2) Misbehavior Detection & Revocation:

The SCMS combines distributed components for certificate issuance, trust management, privacy protection, misbehavior detection, and revocation. Its architecture separates logical roles while supporting secure communication among components and end entities.

  • Misbehavior Detection: Misbehavior detection combines local vehicle analysis, device reports, and SCMS-wide analysis to identify devices for revocation.The paper states that the local and global detection algorithms remain ongoing work.
  • Privacy and Communication: Protected communication channels, application-layer encryption, and air-gap protection secure interactions among online and sensitive SCMS components.The architecture uses protocols such as TLS and adds protection when intermediate components should not see forwarded data.
  • Revocation: A central CRL store consolidates current revocation lists into one downloadable file, reducing the vehicle communication burden from multiple CRL signers.The architecture also distributes CRLs through pass-through broadcast and storage components.
  • SCMS Components: The SCMS includes distinct authorities for enrollment, pseudonym issuance, linkage, misbehavior processing, policy, trust, and revocation-list generation.These roles include the ECA, PCA, LAs, MA, PG, RCA, and CRL-related components.
  • Privacy and Communication: The LOP hides requesting devices’ locations by changing source addresses, while report shuffling prevents the MA from tracking reporters’ paths.These mechanisms protect privacy in communications and misbehavior reporting.
  • SCMS Components: The RA validates device requests, limits issuance to eligible devices and time periods, and supports configuration updates.It also prevents revoked devices from receiving new pseudonym certificates.

C. Certificate Provisioning Model

The provisioning model balances privacy, storage, connectivity, certificate waste, Sybil exposure, and revocation efficiency. It uses batches of simultaneously valid weekly certificates with automatic replenishment.

  • Design Requirements: The model addresses conflicting requirements involving certificate privacy, device storage, intermittent connectivity, CRL size, retrospective unlinkability, certificate waste, and Sybil attacks.These constraints arise because short validity periods improve privacy but increase storage and connectivity demands.
  • Design Requirements: More than 300,000 certificates could be required for three years under the Safety Pilot model, making automotive-grade device storage prohibitively expensive.The model used five-minute certificate validity periods, corresponding to 105,120 certificates annually.
  • Revocation: Avoiding CRLs by frequently requesting certificates would require connectivity that may not be reasonable under current circumstances.The paper therefore retains mechanisms for efficient revocation despite intermittent connectivity.
  • Provisioning Parameters: The proposed parameters specify a 1-week certificate validity period and a minimum batch size of 20 simultaneously valid certificates.The SCMS Manager can refine these parameters for device compatibility.
  • Privacy and Utilization: Certificates unused within a week cannot be linked, while certificate reuse makes a device linkable only within that week.This provides a stated level of tracking privacy while reducing storage needs through higher certificate utilization.
  • Provisioning Operation: The SCMS automatically issues certificate batches throughout a device’s lifetime, allowing topping-off without explicit certificate requests.Devices download week-long batches when connectivity is available.

III. CERTIFICATE TYPES

The SCMS defines certificate types for different V2X roles and applications, with features tailored to pseudonymity, unlinkability, encryption, continuous issuance, and revocation. Butterfly expansion supports efficient generation of many certificate keys.

  • Certificate Types: Analysis of 119 DSRC-based applications identified five end-entity certificate types for the SCMS.Certificate types are grouped by identical issuance process flows.
  • Enrollment and RSE Certificates: Enrollment certificates support bootstrap and later requests for signing or encryption certificates, while RSE enrollment certificates serve the equivalent RSE role.RSE application certificates support broadcast and service-announcement signing and may provide an encryption key.
  • OBE Certificates: OBE pseudonym certificates support pseudonymity, unlinkability, and efficient revocation for BSM broadcasts and authorization requiring unlinkability.Their privacy protections include shuffling, linkage values, butterfly key expansion, and PCA encryption.
  • OBE Certificates: OBE identification certificates identify devices but do not provide pseudonymity or unlinkability.Butterfly expansion remains available for continuous certificate generation.
  • Certificate Features: Linkage values support efficient revocation, and pseudonym certificates require them because each OBE receives many certificates.They are not used for OBE identification certificates because RSEs can store large CRLs.
  • Butterfly Key Expansion: Butterfly expansion lets the RA generate up to 2^128 cocoon public keys from one caterpillar public key, while corresponding private keys remain known only to the OBE.The RA includes the expanded public keys in certificate requests sent to the PCA.
  • Butterfly Key Expansion: The RA must prevent the PCA from learning which certificates belong to which OBE, using shuffling and encrypted certificate responses.Otherwise, the RA could recognize expanded public keys in issued certificates and track the OBE.

A. Security of Butterfly Keys

The paper defines butterfly-key security through an adversarial guessing game and proves security informally under the hardness of the elliptic-curve discrete logarithm problem.

  • Implementation Context: The SCMS implementation issues implicit certificates whose generation changes public keys so the RA cannot correlate inputs and outputs.The paper’s explicit-certificate security description is therefore related to, but distinct from, the implemented process.
  • Security Definition: Butterfly-key security requires every efficient adversary given polynomially many public keys to have only negligible probability of guessing a corresponding private key.The private keys have the form a + b_x for a randomly selected index x.
  • Security Result: The theorem states that butterfly-key construction is secure assuming the elliptic-curve discrete logarithm problem is hard.The proof proceeds by contradiction through a discrete-log adversary.
  • Proof Strategy: The reduction constructs public keys by adding randomly selected scalar multiples of the curve base point to the discrete-log challenge point.A successful butterfly-key adversary would yield a non-negligible-probability discrete-log solver.

V. DEVICE BOOTSTRAPPING AND CERTIFICATE PROVISIONING

The SCMS supports bootstrapping, certificate provisioning, misbehavior reporting, and revocation. Bootstrapping establishes device trust and enrollment credentials, while pseudonym provisioning separates roles to protect privacy and device efficiency.

  • The SCMS supports four use cases: device bootstrapping, certificate provisioning, misbehavior reporting, and global misbehavior detection and revocation.
  • Device bootstrapping: Bootstrapping securely equips a device with information needed to communicate with the SCMS and other devices.
  • Device bootstrapping: Initialization provides trust certificates and credentials for verifying messages, policies, CRLs, and encrypted misbehavior reports.
  • Device bootstrapping: Enrollment provides an enrollment certificate, ECA and RA certificates, RA connection information, and eligibility checks based on device models.
  • Certificate provisioning: Pseudonym certificate provisioning protects privacy and reduces device computation through location obscuring, certificate encryption, request shuffling, and butterfly key expansion.

C. Linkage Values

Linkage values combine independently generated values from two Linkage Authorities to support efficient certificate revocation while limiting certificate linkage. The design also addresses certificate misbinding through message hashing.

  • Linkage values: Linkage values let the SCMS revoke all certificates valid from a selected time onward for a device.
  • Linkage value generation: Each Linkage Authority generates a forward-computable, backward-infeasible hash chain from a random 128-bit initial seed.
  • Linkage value generation: Pre-linkage values are derived with AES-based pseudorandom processing, with the design suggesting v = 9 significant bytes.
  • Linkage value generation: The PCA XORs encrypted pre-linkage values from LA1 and LA2 to form linkage values, preventing any single component from linking one device’s pseudonym certificates.
  • Linkage value length: With 250 million vehicles and 40 certificates per week, 72-bit linkage values imply about one collision per year, and collisions matter only during revocation.
  • Misbinding attacks: Hashing each message together with its certificate prevents an attacker from attaching a false certificate to a valid signature.

E. Detailed Description of Pseudonym Certificate Provisioning Process

Pseudonym certificate provisioning distributes request handling, certificate creation, encryption, and bundling across SCMS components. The process preserves privacy while storing component-specific information for later revocation.

  • Step 1: Device request: The device generates butterfly key seeds, signs its request with its enrollment certificate, encrypts it to the RA, and sends it through the LOP.
  • Step 2: RA handling: The RA validates the request and enrollment certificate, checks revocation and duplicate requests, then performs butterfly key expansion.
  • Step 3: Singular requests: The RA sends the PCA one request per certificate, containing a to-be-signed certificate, response encryption key, encrypted pre-linkage values, and a request hash.
  • Step 4: PCA creation: The PCA computes each linkage value, adds it to the certificate, creates the pseudonym certificate and reconstruction value, and encrypts both to the device.
  • Step 5: Singular certificates: The PCA signs encrypted responses so the device can verify that packets were encrypted for it, preventing RA substitution of the response encryption key.
  • Step 6: RA bundling: The RA collects encrypted certificates and reconstruction values for one week, bundles them by device, and makes the batches available for download.

B. Global Misbehavior Detection

Global misbehavior detection identifies suspicious devices, investigates them through controlled linkage recovery, and supports revocation. The process relies on iterative algorithms and collaboration among SCMS authorities.

  • Global detection: The Misbehavior Authority owns global detection, which identifies potential misbehavior, investigates suspicious activity, and revokes confirmed misbehaving devices.
  • Global detection: Detection algorithms are expected to evolve iteratively as new threats and forms of misbehavior emerge.
  • Misbehavior reporting: Devices submit encrypted misbehavior reports through the RA to the MA, while multiple reports about one device can trigger detection algorithms.
  • Misbehavior investigation: The MA requires PCA and LA cooperation to determine whether multiple certificates belong to the same device and to support revocation.
  • Investigation safeguards: PCA and LA requests should require MA authorization, limit returned information, and be logged and regularly audited.
  • Misbehavior investigation: The investigation maps reported linkage values to encrypted pre-linkage values, then asks an LA whether selected values correspond to the same device.

D. Revocation and Blacklisting.

The SCMS revokes pseudonym certificates by coordinating the Misbehavior Authority, PCA, RA, and linkage authorities. Linkage seeds are published in CRLs so many certificates can be revoked efficiently while preserving backward privacy.

  • Revocation process: After misbehavior identification, the MA coordinates PCA, RA, and LA actions to identify the affected device’s certificate material and revoke it.The RA blacklists the enrollment certificate, while linkage authorities provide linkage information used for CRL-based revocation.
  • Revocation process: The PCA maps the identified linkage value to the hash of the corresponding RA-to-PCA pseudonym certificate request.
  • Revocation process: The RA supplies linkage-chain identifiers, and the LAs map them to the current-period linkage seeds for the MA.Multiple linkage-chain identifiers are used when a device owns certificates from multiple independent linkage chains.
  • Privacy property: Forward-only derivation from a published linkage seed preserves backward privacy for certificates from earlier time periods.
  • Revocation process: The MA adds the linkage seeds and corresponding LA identifiers to the CRL, which the CRL Generator signs and publishes.Entries may be grouped by LA-ID pair to reduce over-the-air bytes.

E. Global Misbehavior Detection & Revocation for Nonpseudonym Certificates

For certificate types without linkage values, the SCMS revokes each non-expired certificate individually. Its CRL-series structure separates revocation domains, improving checking efficiency and limiting the scope of compromised revokers, while multiple signers can increase distribution burden.

  • Nonpseudonym revocation: Without linkage values, all revoked certificates must be identified separately on the CRL.The pseudonym-certificate process is unique in using linkage values to revoke many certificates efficiently.
  • Nonpseudonym revocation: The MA obtains the reported certificate’s request hash, has the RA blacklist the enrollment certificate, and retrieves hashes for the device’s other non-expired certificates.
  • Nonpseudonym revocation: The MA adds truncated certificate hashes, called CertIDs, for all non-expired certificates to the CRL.Possible optimizations include retrieving only predecessor and successor certificates or storing CertIDs at the RA.
  • CRL constraints: CRL size grows linearly with revoked entities, while devices are assumed to support at least 10,000 entries, approximately 400 KB.The final design was still under development, and prioritization mechanisms were not yet clear.
  • CRL Series: CRL Series identify the relevant revocation sequence for each entity, enabling targeted checking and limiting false revocation by a compromised generator.A central CRL store combines current CRLs into one downloadable file, addressing the added communications burden from multiple signers.

VII. CRL PROCESSING AND DISTRIBUTION

The SCMS distributes revocation data through linkage-seed processing, CRL sequences, and device re-enrollment procedures. Devices derive current linkage values from published seeds, while re-enrollment addresses revocation, cryptographic changes, certificate rollover, and authority replacement.

  • Linkage-value processing: To revoke a device from period i onward, the CRL publishes two linkage seeds, their LA identifiers, and timing information.
  • Linkage-value processing: Devices forward-hash both seeds, derive the current-period pre-linkage values, and XOR them to obtain linkage values for later periods.The mechanism protects backward privacy because earlier certificates cannot be identified before seed publication.
  • CRL distribution: Collaborative CRL distribution seeds some devices through RSEs or cellular data, after which recipient devices distribute CRLs to peers.
  • Re-enrollment: Re-enrollment includes reinstatement, re-bootstrapping, re-issuance, and re-establishment, with re-bootstrapping required for CRL-revoked devices.Re-issuance reuses the enrollment public key, whereas re-bootstrapping wipes the device and executes bootstrap again.
  • Re-enrollment: Re-enrollment also handles cryptographic changes, enrollment-certificate rollover, and revocation of an ECA or root CA.

IX. ELECTOR-BASED ROOT MANAGEMENT

Elector-based Root Management lets the SCMS replace root trust relationships without relying on a single failure point. Electors authorize root and elector changes through signed ballots and quorum validation, supporting system recovery while EEs remain operational whenever possible.

  • Motivation: Installing a replacement root CA traditionally requires secure-environment access, which can leave the V2X system partly out of order until EEs update.
  • Root recovery: Elector-based Root Management adds distributed management so the SCMS can recover from singleton compromise or certificate expiration without physical EE access whenever possible.
  • Elector structure: The system uses 2n+1 electors when it must tolerate n simultaneous elector expirations or compromises.
  • Ballots and quorum: Electors individually sign ballots that endorse or revoke root CA and elector certificates, and a valid quorum authorizes execution.
  • Validation: EEs verify trust chains to root certificates and then verify endorsement by a quorum of non-revoked electors.Electors are outside the PKI hierarchy and may use different cryptosystems, improving resilience to cryptographic compromise.

C. Structure of Ballots

The SCMS organizes root-management decisions as ballots containing actions and elector signatures, while separating component responsibilities to protect pseudonym privacy. The design also identifies deployment work spanning revocation dissemination, proof-of-concept testing, and misbehavior detection.

  • Ballot structure: Each ballot contains a sequence of actions, with each action specifying an object certificate and a sequence of elector signatures.
  • Ballot structure: A ballot’s validity period is implicitly determined by the validity period of the action’s object.
  • Root management: Root-management design aims to keep enrollment entities operational without recalling or manually re-enrolling individual devices.
  • Privacy protection: Organizational separation prevents insiders from combining component-held information to link pseudonym certificates to devices or identify certificates belonging to the same device.The separation rules cover PCA, RA, linkage authorities, LOP, and MA combinations.
  • Outlook: Next steps include defining CRL dissemination, conducting large-scale proof-of-concept deployments, and implementing misbehavior reporting, investigation, and detection.
Loading 1802.05323v1…