Module 67 - CSE 201
Module CSE 201: Introduction to Security Credential Management System (SCMS) Part 2 of 2
HTML of the PowerPoint Presentation
(Note: This document has been converted from a PowerPoint presentation to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)
Slide 1:
Slide 2:
Slide 3:
Module CSE201:
Introduction to Security Credential Management System (SCMS) Part 2 of 2

The title slide shows a graphic that provides an overview of the security credentials management system (SCMS) as defined in IEEE 1609.2.1. The figure shows a black cloud at the top labeled SCMS manager with two black boxes labeled "Policy" and "Management & Operations". Underneath the cloud is another black box labeled "Root Management Function" with three black boxes contained within it, labeled "Elector A", "Elector B", and "Elector C" and an ellipses. The Root Management Function box is connected via a "trust hierarchy" arrow to a green "Root CA" box. The Root CA box connects via a trust hierarchy arrow to a red "Misbehavior Authority" box on the right. The Root CA is also connected via a trust hierarchy arrow directed downward to an green "Intermediate CA" box. The Intermediate CA box is also connected via trust hierarchy arrows to an green "Authorization CA" box located immediately below it, to a green "Registration Authority" box located below the Authorization CA box, and to a green "Enrollment CA" box located off to the left. The Root, Intermediate, and Authorization CAs each have associated green "CRL Signer" boxes attached to and behind them. The red Misbehavior Authority box has SCMS communication arrows leading to the three CRL Signer boxes associated with the three CAs. It is also has bi-directional SCMS communication arrows connecting it to boxes representing the Registration Authority, the Authorization CA, and two green boxes labeled "Linkage Authority" 1 and 2. The Linkage Authority boxes are connected to the Registration Authority box via bi-directional SCMS communication arrows. The Registration Authority Box also has bi-directional SCMS communication arrows connecting it with the Authorization CA, and boxes representing the Enrollment CA and a green "Supplementary Authorization Server". The Enrollment CA also has a bi-directional SCMS communication arrow to a "Device Configuration Manager" box. Near the bottom of the diagram is a box depicting a car labeled "OBU" for on-board unit, a signal head labeled "RSU" for roadside unit, and a wireless handheld device labeled "ASD" for after-market safety device. This box is connected with bi-directional physical interface arrows to the Device Configuration Manager and Supplemental Authorization Server. It is also connected with a bi-directional physical interface arrow to the Registration Authority via a Location Obscurer Proxy. It also is designated as a receiver of a physical interface arrow via a Location Obscurer Proxy and from a "Distribution Center" box that receives SCMS communication from a box labeled "Certs, CRLs, and CTLs". The OBU/RSU/ASD box also has a logical interface arrow directly to the Enrollment CA and another to the Misbehavior Authority via the Registration Authority. Finally, the OBU/RSU/ASD box is a receiver of a logical interface arrow from the Authorization CA. The black boxes represent "Geo Domain Central" entities; the red box represents a "App Domain Central" entity, while the green boxes represent "non-central" entities.
Image source: IEEE P1609.2.1
Slide 4:
Instructors
Dr. William Whyte
Senior Director, Technical Standards
Qualcomm Technologies, Inc.
Dr. Virendra Kumar
Senior Staff Engineer, Technical Standards
Qualcomm Technologies, Inc.
Slide 5:
Learning Objectives-Part 2 of 2
- Identify the Vehicle-to-Everything (V2X) certification process for a device to enroll in the SCMS
- Illustrate how to make a deployment plan that uses SCMS services
Slide 6:
Recap of Learning Objectives 1-3

Text contained in the image:
- IEEE 1609.2 specifies security services cryptography and data validation services that can be used to protect data in transit
- In the 1609.2 system, a receiver knows a sender is trusted to send a message (or command) of a particular type because the sender has a certificate that says they are entitled to do so and the 1609.2 processing cryptographically links the certificate to the message to show that only that certificate holder could have generated that message
- The SCMS is in charge of issuing certificates to actors in the system. Its primary responsibility is to make sure that certificates are issued to actors who are entitled to them by carrying out checks that
- The actor was entitled to the certificate in the first place
- The actor has not become malicious, untrustworthy, or otherwise unreliable since the certificate was issued
- The SCMS and the 1609.2 certificate system is designed to preserve privacy from eavesdroppers in the field and from insiders at the SCMS
- Major challenges in SCMS deployment include
- Enrolling devices establishing that they are entitled to certificates, especially for specialized applications
- Keeping devices provisioned with certificates this requires regular access to the Internet
- Understanding which devices should have their certificates withdrawn (revocation)
- It is recommended that deployers work with an SCMS service provider rather than trying to run SCMS Services themselves
The list item that reads "Enrolling devices establishing that they are entitled to certificates, especially for specialized applications" is highlighted in gray to represent learning objective 4, and the items "Keeping devices provisioned with certificates this requires regular access to the Internet" and "Understanding which devices should have their certificates withdrawn (revocation)" are highlighted in purple to represent learning objective 5.
Slide 7:
Learning Objective 4
- Identify the Vehicle-to-Everything (V2X) Certification Process for a device to enroll in the SCMS
Slide 8:
Security Requirements for Devices
- The security requirements on a device are the security requirements for all the application activities that device is carrying out
- To determine the security requirements for a device, work out the requirements for each application it runs, and aggregate them
- The NIST Cybersecurity framework (PCB Course CSE202, Intro to Cybersecurity for Agencies) provides a way for the deployment manager to analyze the security requirements of devices in a deployment
- Determine the sensitivity of each "information flow" starting or ending at a given device to confidentiality, integrity and availability
- For many applications, this work has already been done
- ARC-IT contains security analysis for all applications
- To determine the security requirements for a device, work out the requirements for each application it runs, and aggregate them
- Four device security classes have been defined and can be referenced in procurement documents
- Classes refer to different combinations of confidentiality / integrity / availability capabilities
- Definitions are in CV Pilot Deployment documents
Slide 9:
Baseline Security Requirements
- For a device to be trusted to run a particular application, it must meet
- General security requirement common to all devices
- Application-specific requirements.
- Devices need to protect key material against being revealed
- Integrated / Connected / Networked architectures all possible
- "Architecture" refers to connection/link between application processor and Hardware Security Module (HSM)
- HSM protection is specified by standards such as Federal Information Processing Standard (FIPS) 140
- Integrated / Connected / Networked architectures all possible

This slide contains a figure of three architectures.
- At the top, the "Integrated architecture" is shown as a box labeled "Shared Processor (Host Processor and HSM)". HSM stands for Hardware Security Module. Inside of the box are two smaller boxes, labeled "Privileged Applications" and "Cryptographic Operations".
- In the middle of the figure, the "Connected architecture" is shown as two primary boxes. The first is labeled "Host Processor" and it contains a smaller box labeled "Privileged Applications". The Host Processor box is connected to the second primary box with a thick gray line. The second primary box is labeled HSM and contains a smaller box labeled "Cryptographic operations". The Host Processor has a network connection.
- At the bottom of the figure, the "Networked architecture" is shown. This includes three primary boxes connected to each other via a network. The first box is labeled "Host Processor" and contains a smaller box labeled "Privileged Applications". The second primary box is labeled "Other processor". The third primary box is labeled HSM and contains a smaller box labeled "Cryptographic operations".
Slide 10:
Baselines Security Requirements (2)
- Devices need to enforce secure update mechanisms
- Ensure that all changes to software, firmware, or configuration are made by an authorized party
- For higher security levels, operator authentication may be needed
- Different requirement documents exist
- OmniAIr Hardware/Software/OS Security Guidelines
- Car2Car Communications Consortium Protection Profiles
- It is up to the SCMS to say exactly which requirements apply - all sets of requirements are broadly similar, but details may differ
Slide 11:
Baseline Security Requirements (3)
- Devices need to protect against key material being used by illegitimate users
- Malware protection
- Ensure a key can be used only by approved processes on the devices
- Devices need to enforce secure boot
- Secure boot ensures that if a device is tampered with, this will be detected by the boot mechanism and access to sensitive or security-critical data can be cut off
- It is a local activity that does not need intervention from a network entity
Slide 12:
Security Certification via OmniAir
- The OmniAir testing consortium is defining formalized security requirements for V2X devices
- There is no formal, national policy that an SCMS operator requires OmniAir certification, but in practice existing SCMS operators respect OmniAir certification
- OmniAir runs several PlugFests a year where interoperability can be tested; full conformance testing for security is likely to be available by early 2021
Slide 13:
Special Permissions
- Conditions for certificate issuance are application-specific
- Some applications can be issued with certificates at the factory
- BSM signing
- Other applications need assertion from a real-world authority that certificates can be issued
- Police car certificates
- Different applications may need devices with different properties
- Devices that can do signal preemption may need the driver to sign in
- For a lot of applications, the conditions are still being worked out - talk to your SCMS provider

Slide 14:
Additional Functionality via New Software
- A device may in principle be deployed with an initial set of applications and later have new applications added
- In this picture, an RSU is deployed with SPaT, and later upgraded to support Signal Request / Status Message (SRM / SSM)
- In the original CAMP interface, the device would need a new enrollment certificate
- In the new interface defined in 1609.2.1, the SCMS can update the permissions associated with the enrollment certificate
- In order for it to do this, the deployment manager will have to demonstrate that the new application was valid and was validly installed
- Processes for doing this are still manual
- If you’re a deployment manager, discuss this with your SCMS provider before deploying new applications
Slide 15:
Slide 16:
Question 4
Which of these is required for a device to be secure enough to run V2X applications?
Answer Choices
- The device requires a user to log in before it will send any V2X messages.
- The device requires user permission for updates.
- The device supports virtualization.
- The device protects its keys with a hardware security module.
Slide 17:
Review of Answers
a) The device requires a user to log in before it will send any V2X messages.
Incorrect. Many types of devices, such as standard on-board units in cars, are expected to start broadcasting without requiring the user to log in.
b) The device requires user permission for updates.
Incorrect. Updates must be secured, meaning that they must be authenticated as coming from a trusted source, but they do not need the user’s explicit permission. It is a courtesy to inform the user that an update is taking place, but user permission is not required so long as the device can ensure that the update is taking place under safe conditions.
c) The device supports virtualization
Incorrect. Virtualization can improve security by sandboxing different applications, preventing one application from interfering with another’s operations, but it is not a requirement - especially for devices like standard on-board units that only send one type of message.
d) The device protects its keys with a hardware security module.
Correct! If the keys are not protected with a hardware security module, an attacker who gets access to the device can potentially obtain a copy of the keys and use them to forge messages.
Slide 18:
Learning Objective 5
- Illustrate how to make a deployment plan that uses SCMS services.
Slide 19:
SCMS Design: SCMS In ARC-IT
SCMS services are fully described in ARC-IT and their deployment can be planned using the same tools that are used to plan the deployment of other Connected Vehicle services.

Slide 20:
Security Management Operating Concept
- Deployments should develop a Security Management Operating Concept that
- Identifies security requirements on each information flow
- Uses this to determine device security requirements
- Uses this to identify security mechanisms for information flows
- 1609.2 certificates and signing may not necessarily be the correct security mechanism for each flow
- For information flows that use 1609.2 certificates
- Specify the "security profile" (basic profile already part of the standard)
- Identify the PSID to use
- Determine certificate issuance policy
Slide 21:
Security Management Operating Concept
- Deployments should develop a Security Management Operating Concept that
- Identifies security requirements on each information flow
- Uses this to determine device security requirements
- Uses this to identify security mechanisms for information flows
- 1609.2 certificates and signing may not necessarily be the correct security mechanism for each flow
- For information flows that use 1609.2 certificates
- Specify the "security profile" (basic profile already part of the standard)
- Identify the PSID to use
- Determine certificate issuance policy

Slide 22:
Slide 23:
Case Studies
- New York City Pilot Deployment:
- Central generation of TIMs and MAPs
- Generated centrally at the TMC
- Need a "security appliance" to generate the signatures - to protect keys and ensure messages are correct
- Generated centrally at the TMC
- SPaTs generated at RSU
- RSUs certified as appropriately secure
- Central generation of TIMs and MAPs
- Tampa: Roadside generation and signing of SPaT and MAP
- Need to get devices approved for certificates before installation
- Minneapolis: Allow snowplows to request signal prioritization
- Devices are issued with certificates when they are provided to the site
Slide 24:
Lessons Learned
- Production SCMS is needed for RSU certificate updates
- RSUs need to be able to access the SCMS at least once a week
- Production SCMS is needed for certificate top-off for the OBUs
- OBUs need to be able to access the SCMS at least once a week
- Test all connections, especially if OBUs are connecting through RSUs and especially if IPv6-to-IPv4 translation is to be carried out
- Test correct operation if the first certificate download fails; i.e., repeat download request
- Test that the system behaves correctly when devices transition between certificates, i.e., when one certificate expires and a new one is expected to be used
- Devices attempt to update certificates in a timely manner
- Devices stop using the old certificates and start using the new certificates at the appropriate time, i.e., before expiration of the old and after start-validity of the new
- If there are conditions that inhibit certificate change (e.g.. alert state per J2945/1) test that system transitions correctly after condition stops holding
Slide 25:
Lessons Learned Continued
- Integrate the CV needs into the agency’s cybersecurity program early on in the project
- Network traffic necessary for SCMS operation will require various firewall settings, proxy servers, etc., that will need to meet the agency’s overall cybersecurity standards
- Maintain a secure, trusted network environment for the CV pilot deployment system
- Try to isolate it from the general traffic management network
- Test the OTA download and upload mechanisms before extensive installation of the ASDs and RSUs
- For multi-application devices, understand whether there will be one certificate per application, one certificate per device, or something else
- Some RSU vendors only support a single application certificate covering all PSIDs.
- Ensure that the RSU firmware permits sending pre-signed messages (MAP, TIM).
Slide 26:
Other Lessons Learned
- Ensure certificate top-off is robust against losing connectivity mid-top-off
- Protocols are meant to give robustness, but implementations need to be tested
- Ensure certificate top-off succeeds even if a device has not successfully topped off for some time
- If certificate lifetime is a week and devices top-off up to 2 weeks in advance, make sure that a device that has been out of contact for a month can connect
- Ensure that repeated requests for a certificate for a particular time period cause only a single certificate to be generated, not one certificate per request
- Provides protection against "sybil attacks"
- Test enrollment certificate expiry and rollover
Slide 27:
Other Lessons Learned
- Test that certificate management software works across expiry of an ACA certificate or an ECA certificate
- Both for devices that get certs from that ACA/ECA, and for devices that trust them.
- Ensure that new CA certificates can be distributed in a timely way
- If there is a new ACA, ensure that trust of the new ACA certificate does not act as a gatekeeper for access to certificate updates.
- For example, in one case, network connectivity was provided by RSUs that started to use a certificate from a new ACA to advertise that connectivity: OBUs that did not already have the new ACA certificate could not trust the advertisement, and so could not connect to update the ACA certificate.
- Ensure there is a good way to get feedback to SCMS Manager and other governance bodies
Slide 28:
Misbehavior Reporting and CRL Download
- Messages with bad data / that will cause bad outcomes
- CV Pilot Deployments have implemented baseline misbehavior reporting mechanisms and some SCMS providers have implemented misbehavior investigation and revocation
- Deployments may want to implement additional revocation conditions
- For example, if a pilot deployment device is stolen, it may be easier to revoke it to prevent misuse
- SCMS Providers should be asked about performance metrics -the time between a report being submitted that leads to revocation and the CRL being issued
- Deployments may want to support other means of CRL distribution beyond direct download from the RA, such as broadcast by RSUs
- There is currently no standard that supports this, so this would be a custom development
Slide 29:
SCMS Design: Misbehavior Management - open questions
- Questions for SCMS provider
- …that affect operational interactions with the SCMS
- Is there another way to report devices that need to be revoked; for example, devices that have had their private keys extracted?
- …that provide information about expected system behavior
- What’s the "threshold" of bad behavior that a device must pass to be revoked?
- How many different reporters must report a device before it’s revoked? Are there different levels of trust in reporters?
- How quickly should it be possible to revoke a misbehaving device?
- How often do we create new CRLs?
- Is there any process of appeal against revocation?
- …that affect operational interactions with the SCMS
- Questions for device supplier and SCMS provider together
- How can a revoked device be trusted again?
- Is there any process of appeal against revocation?
- If a device is producing bad data because of bad configuration, can we notify and fix the device rather than reporting it?
Slide 30:
Traffic on the Infrastructure Owners and Operators (IOO) Network
- Most interactions between mobile devices and infrastructure in the V2X setting can naturally be confined to the traffic management network as they are primarily about exchanging local information
- SCMS network traffic is different as its natural endpoint is outside the Infrastructure Owners and Operators (IOO) network and remote on the Internet
- Contact RA to download certificates
- Contract RA to upload misbehavior reports

Slide 31:
Traffic on the IOO Network contd.
- Many mobile devices will have cellular connectivity to enable SCMS communications but for some devices it may be necessary to provide Internet access via the IOO network
- RSUs could potentially *only* be on the IOO network and will need specific consideration if so
- Network connectivity is required for certificate update, so even mobile devices may require connectivity through the IOO network to avoid the risk that connectivity is not available due to, for example, cellular subscription expiring and/or Wi-Fi not being available
- SCMS architecture makes hosting SCMS components within the IOO network problematic - this needs to be reconciled with firewall rules for ingress/egress to the IOO network
- Each IOO network will address this question in their own way depending on local network configuration but implications need to be thought through early in the process
Slide 32:
Incident Detection and Response
- In addition to misbehavior reporting, which is purely an SCMS activity leading to revocation, a deployment must be aware of other possible threats within the system
- These include various forms of denial of service as well as standard network cyberattacks
- IOO networks should already have network monitoring and other security mechanisms in place, but should review those to determine if a V2X deployment introduces new threats and, if so, whether the current security measures are adequate to defend against them
Slide 33:
Data Management
- Many instances of Connected Vehicle applications result in the generation and potential collection of large amounts of data that could be personally identifying
- Deployment should not happen without a site data management plan to ensure proper handling of data
- This is not an SCMS concern, but it is conceivable that future certificate policies could make issuance of certs dependent on having a data management plan
- NIST and DOT have created a privacy analysis process for use with Connected Vehicle deployments
Slide 34:
Slide 35:
Question 5
Which of these is a correct statement about data collection and management?
Answer Choices
- Only vehicles can produce personally identifying information.
- Individuals must give consent to their data being collected.
- If there is concern that data may reveal driver behavior that violates the law, it should be immediately shared with law enforcement.
- Data must be managed in a manner consistent with local data protection regulations.
Slide 36:
Review of Answers
a) Only vehicles can produce personally-identifying information.
Incorrect. A deployment might include pedestrian devices which directly generate personally-identifying information. Additionally, fixed devices like cameras can generate information that might be linked to individuals.
b) Individuals must give consent to their data being collected.
Incorrect. This depends on the applicable local data protection regulation.
c) If there is concern that data may reveal driver behavior that violates the law, it should be immediately shared with law enforcement.
Incorrect. This will depend on the applicable local data protection regulation and other laws, but there is, in general, no requirement to be proactive about sharing data with law enforcement.
d) Data must be managed in a manner consistent with local data protection regulations.
Correct! A deployer must be aware of local data protection regulations and ensure that they are complied with.
Slide 37:
Module Summary Part 2 of 2
- Identify the Vehicle-to-Everything (V2X) certification process for a device to enroll in the SCMS
- Illustrate how to make a deployment plan that uses SCMS services
Slide 38:
Module Summary
- Define communications security requirements in the Connected Vehicle (CV) environment
- Describe how the Security Credential Management System (SCMS) uses cryptographic building blocks to provide trust
- Understand how to get devices interacting with the SCMS in a deployment
- Identify the Vehicle-to-Everything (V2X) certification process for a device to enroll in the SCMS
- Illustrate how to make a deployment plan that uses SCMS services
Slide 39:
Introduction to SCMS Curriculum
CSE 201:
Introduction to Security Credential Management System Part 1 of 2
CSE 201:
Introduction to Security Credential Management System Part 2 of 2
Slide 40:
Thank you for completing this module. Feedback
Please use the Feedback link below to provide us with your thoughts and comments about the value of the training.
Thank you!