Module 66 - CSE201
Module CSE201: Introduction to Security Credentials Management System (SCMS) Part 1 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:
![This slide contains a graphic with the word "Welcome" in large letters. ITS Training Standards "WELCOME" slide, with reference to the U.S. Department of Transportation Office of Assistant Secretary for Research and Technology](cse201p1ppt1.jpg)
Slide 2:
![This slide contains a graphic with the word "Welcome" in large letters, photo of Kenneth Leonard, Director ITS Joint Program Office - Ken.Leonard@dot.gov - and on the bottom is a screeshot of the ITS JPO website - www.its.dot.gov/pcb](cse201p1ppt2.jpg)
Slide 3:
Module CSE 201:
Introduction to Security Credential Management System (SCMS) Part 1 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.](cse201p1ppt3.jpg)
Image source: IEEE P1609.2.1
Slide 4:
Instructors
![Photo of Dr. William Whyte](cse201p1ppt4.jpg)
Dr. William Whyte
Senior Director, Technical Standards
Qualcomm Technologies, Inc.
![Photo Dr. Virendra Kumar](cse201p1ppt5.jpg)
Dr. Virendra Kumar
Senior Staff Engineer, Technical Standards
Qualcomm Technologies, Inc.
Slide 5:
Learning Objectives
- 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 6:
Learning Objectives - Part 1 of 2
- 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
Slide 7:
Learning Objective 1
- Define communications security requirements in the Connected Vehicle (CV) environment
Slide 8:
Security of deployments and the role the SCMS plays in that security
-
The security of Connected Vehicle deployments depends on the security of many different aspects of the system
- Support networks must be secure against cyber attack
- Stored data must be managed in an appropriate way with suitable access control
- Each individual component or subsystem within the overall system must also be secure
- Communications between components must be secure
-
The SCMS helps with
- Communications security - by providing certificates that allow devices to communicate securely
- Security of individual components - by checking that certificates are only provided to components that are secure
-
Having access to an SCMS is a vital part of a secure deployment, but other security issues must also be addressed
- See CSE202, Cybersecurity!
Slide 9:
Need for Trust
- Electronic communications can be intercepted, read, and altered
- Secure communications mechanisms allow us to protect against this
- Cryptographic algorithms are mechanisms we use to meet security goals for protecting data in transit
-
These goals are:
- Confidentiality
- Integrity
- Authenticity
![This slide displays an image of two people having a conversation. Bob says, "Let me tell you a secret. Hope no one is listening." Alice responds, "Wait, let me turn on crypto protections." Above the figure is a green happy demon face; it is happy because, so far, it is able to understand the conversation.](cse201p1ppt6.jpg)
Image source: USDOT
Slide 10:
Need for Trust contd.
-
With the security mechanisms, the receiver can trust that
- The message received is the same as the message sent
- The sender was legitimate
- The message has not been read by anyone who shouldn’t read it
-
Without trust, there would be no point sending messages
- Receivers could not be sure they were correct
- The system could be flooded with false messages
- Receivers would not be able to act on received messages
- In any communication system, including Connected Vehicle, trust in received messages is vital for the system to achieve its goals
![This slide displays an image of the same two people who were shown on Slide 9, but now the contents of their conversation is shown merely as a series of asterisks to reflect the fact that crypto protections have been enabled. The demon face above the picture has now turned blue and is sad.](cse201p1ppt7.jpg)
Image source: USDOT
Slide 11:
What’s Unique about Connected Vehicle (CV)?
-
Trusted communications in the context of the Web
- If I go to eCommerceGiant.com, my browser makes sure that the server is actually owned by that e-commerce company
- It does this using Transport Layer Security and X.509 certificates - digital documents that attest identity or ownership of a specific resource
-
What’s special about the CV system requirements compared to online shopping?
- Many-to-many communications
- Need to be able to make real-time decisions
- Limited bandwidth
-
Low-latency network connectivity not assured
- Different actors in different roles but the identity of the actor isn’t important, the role is
- Concern about privacy
- Limited connectivity for security updates
Slide 12:
Many-to-many communications
![This slide displays a multi-lane freeway with many cars, many of which are shown as connected with radio transmission circles around them. The connected vehicles appear to be communicating with roadside equipment, the cloud, and with each other. The variety of vehicles are connecting to a variety of connected services.](cse201p1ppt8.jpg)
Image source: USDOT
Slide 13:
Need for local, real-time decisions
![This slide shows two connected vehicles with an X over their connection to the SCMS diagram, which is shown with detailed description text on slide 3, indicating that vehicles do not always have a live connection to the SCMS resources.](cse201p1ppt9.jpg)
Image source: USDOT
Slide 14:
Identity v. Role
![This slide displays a signalized intersection with a police car on one approach, a passenger car on a second approach, a bus on a third approach, and a pedestrian with a smartphone on a corner. All four entities are connected and are communicating with the traffic signal with an indication that they can send basic safety messages while the police car is also able to request signal preemption.](cse201p1ppt10.jpg)
Image source: USDOT
Slide 15:
Concern about Privacy
![This slide depicts two vehicles traveling in opposite directions on a two-lane road. Each vehicle is connected and is shown radiating blue radio waves. The blue waves being sent out are compositely labeled "shared information" and individual waves have distinct labels, including "position", "brake status", "speed", "acceleration", and "vector". However, each vehicle is also contained within a smaller red stripped circle labeled "non-shared information". Inside of this circle are examples of personally identifiable information (PII), including "driver identifier", "vehicle identifier", and "license plate number".](cse201p1ppt11.jpg)
Image source: USDOT
Slide 16:
Limited connectivity for security updates for vehicles
![Author’s relevant description: This slide presents a map of the Detroit, Michigan region. Two traffic signals are shown, one in the downtown area and the other on the outskirts of town – symbolizing the fact that connectivity to the SCMS might not always be present.](cse201p1ppt12.jpg)
Image source: wikimedia.org
Slide 17:
Functional Requirements
-
Devices get issued with credentials that state their properties / permissions
- Credentials state everything that the receiver needs to know about the sender to decide whether to trust its messages.
-
We use cryptography to make sure that only the credential owner can use it
- Credential issuer and receiver cannot use the credential
- A Credential Issuer makes sure that the device is entitled to the credentials
-
The system recovers from compromise
- Misbehaving devices (sending bad data or otherwise harming the system) are detected and removed or fixed
- Bad actors on the system management side (e.g. bad credential issuers) are detected and credentials they issued removed from circulation
![This slide includes an image of a poster with a hand turning a dial of a safe and is labeled "A safe combination: Security and you". The image is overlaid with a stamped image with the word "Denied".](cse201p1ppt13.jpg)
Image source: wikimedia.org
Slide 18:
System Security Requirements
-
System properties and requirements drove the development of a different certificate format than is used on the Internet
- Internet: X.509
- Vehicle-to-Everything (V2X) : 1609.2
- Limited capacity channels
- Role-based Access Control
- Many-to-many communications
-
Need to be able to make real-time decisions
- Limited bandwidth
- Low-latency network connectivity not assured
- Different actors in different roles but the identity of the actor isn’t important, the role is
- Concern about privacy
- Limited connectivity for security updates
Slide 19:
System Security Requirements
![Please see extended text description below.](cse201p1ppt14.jpg)
(Extended Text Description: This figure contains two bullet lists, the one on the left reads:
-
System properties and requirements drove the development of a different certificate format than is used on the internet
- Internet: X.509
- Vehicle-to-Everything (V2X) : 1609.2
- Limited capacity channels
- Role-based Access Control
Additionally, the text "Limited capacity channels" is highlighted. On the right is another bullet list that is all highlighted:
- DSRC supports 10 MHz, 6Mbps channels can be saturated if too many vehicles present
- C-V2X with 20 MHz channels has higher capacity but can still become saturated, especially if security overhead is excessive
- Small certificate format is necessary
- 1609.2 is smaller by design than X.509
)
Slide 20:
System Security Requirements
![Please see extended text description below.](cse201p1ppt15.jpg)
(Extended Text Description: This figure contains two bullet lists, the one on the left reads:
-
System properties and requirements drove the development of a different certificate format than is used on the internet
- Internet: X.509
- Vehicle-to-Everything (V2X) : 1609.2
- Limited capacity channels
- Role-based Access Control
Additionally, the text "Role-based Access Control" is highlighted. On the right is another bullet list that is all highlighted:
-
1609.2 certificates naturally identify participants by role
- Role is identified by Provider Service Identifier (PSID), an identifier managed by IEEE to ensure each use of that PSID means the same thing
-
X.509 certificates naturally identify participants by identity
- In the V2X system, a receiver might need to know identity, but certainly does need to know if the sender is a traffic signal or an ordinary car
- 1609.2 certificates meet system requirements
)
Slide 21:
System Security Requirements
-
System properties and requirements drove the development of a different certificate format than is used on the internet
- Internet: X.509
- Vehicle-to-Everything (V2X) : 1609.2
- Limited capacity channels
- Role-based Access Control
- New certificate format = new certificate management protocols ==> SCMS
![This slide includes the same graphic used on the title slide 3 with description that provides an overview of the security credentials management system (SCMS).](cse201p1ppt16.jpg)
Image source: IEEE P1609.2.1
Slide 22:
Privacy Requirements
- Privacy means you have a right to go about your business without other people knowing what you’re doing
-
…with some exceptions
- If they need to know what you’re doing to provide a service
- If there’s a public safety reason for them to know what you’re doing
- If you give your active consent
- Depending on local privacy regulations
- Even in these cases, others should not get more information than they need
Slide 23:
Privacy Requirements
- Privacy means you have a right to go about your business without other people knowing what you’re doing
-
BUT V2X data potentially leaks information about your movements
- You can be identified with a vehicle (e.g., through a crash report)
- If vehicle’s movements are known without there being a good reason or need for it, this means your privacy has been violated
- Design goal for V2X: Ensure that V2X communications are never the cheapest way to track you
-
Note: there are lots of other ways you can be tracked in real life
- License plate and toll tags
- Shops track your visits; your cellphone is somewhat trackable
- Tire pressure sensors in your car give out low-power unique identifiers
- MAC address readers
- So "not the cheapest way" is an appropriate goal
Slide 24:
Privacy Requirements: Data management
-
The V2X system generates a huge amount of data
-
Vehicles send 10 Basic Safety Messages / second
- Application payload ~ 30 bytes
- Total size ~ 150-250 bytes
- In one hour’s driving generate ~ 9 MB per car
- One day of 2 hours’ driving each by 300m cars = 5.4 x 1015 bytes
- Must ensure that the data is appropriately managed, and gathered only when necessary
- Data management isn’t really an SCMS issue, but it must be addressed for deployment
Slide 25:
How Does the SCMS Address All This?
- 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
Slide 26:
How Does the SCMS Address All This?
-
Major challenges in SCMS deployment include:
- Enrollment: establishing that devices are entitled to certificates, especially for specialized applications
- Provisioning: keeping devices provisioned with certificates - this requires regular access to the Internet
- Revocation: understanding which devices should have their certificates withdrawn
Slide 27:
![Activity Placeholder: This slide has the word "Activity" in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.](cse201p1ppt17.jpg)
Slide 28:
Question 1
Which of the following statements about privacy is not true?
Answer Choices
- There are many ways to track drivers on the road.
- To preserve privacy, consideration must be given both to how data is created and transmitted, and also to how it is stored and managed.
- Protecting privacy uses both technological and policy approaches.
- The V2X system must always completely protect the anonymity of drivers.
Slide 29:
Review of Answers
a) There are many ways to track drivers on the road.
Incorrect. Drivers can be tracked by cellphones, toll tags, license plates read by cameras, and many other means.
b) To preserve privacy, consideration must be given both to how data is created and transmitted, and also to how it is stored and managed.
Incorrect. Data at any stage of its lifecycle may be personal identifiable information and must be protected.
c) Protecting privacy uses both technological and policy approaches.
Incorrect. Technology can prevent data from being used by unauthorized users, but policy is necessary to ensure that authorized users do not use data in ways that were not intended.
d) The V2X system must always completely protect the anonymity of drivers.
Correct! Driver privacy is important but cannot be fully guaranteed by V2X as it is somewhat compromised by many other mechanisms. The V2X system design aims to ensure that V2X is not the cheapest method available to an attacker to compromise privacy.
Slide 30:
Learning Objective 2
- Describe how the Security Credential Management System (SCMS) uses cryptographic building blocks to provide trust
Slide 31:
Digital Signature
-
Trust is essential to CV system: if receivers can’t trust the messages, they are useless
- Digital signatures are the cryptographic building block that we use to construct systems of trust
-
Senders sign messages with digital signatures and receivers verify the digital signatures
- For verification receivers use the sender’s certificate (sent with every message or periodically)
- Certificate is issued by the SCMS
- Message signers for applications are called "end entities"
-
End entity certificate shows
- Sender is a correctly implemented application
- Sender is running on a properly secure device
- Sender is allowed to send a message of that type.
![This slide includes images of modern US currency in denominations from $1 to $100, which emphasizes how higher denominations use higher levels of security designs to enable better authentication.](cse201p1ppt19.jpg)
Image source: wikimedia.org
Slide 32:
Digital Signature contd.
- The fundamental cryptographic mechanism used in these secure communications is known as digital signatures
-
Signatures provide the communications security services
- Authenticity: message came from the stated sender
- Integrity: message wasn’t modified on the way
- Non-repudiation: message sender can’t deny creating the signature
-
Before generating any signatures, the sender generates a pair of mathematically related keys
- Public key: can be distributed widely, and are used to verify the signature
- Private key: hard to derive from the corresponding public key, and are used to create the signature
- Algorithm used in Connected Vehicle is based on elliptic curves, called the Elliptic Curve Digital Signature Algorithm (ECDSA)
Slide 33:
Encryption
- Encryption ensures message can’t be read by an outsider
-
Encryption scheme examples
- Symmetric: AES, DES
- Asymmetric: RSAOAEP, ECIES
-
Standard V2X messages are not encrypted, only used in special use cases
- Secret data exchange between end entities and the SCMS
- Protection of financial information, for example in tolling
-
Hybrid encryption is used in CV
- Asymmetric algorithm is used to exchange a symmetric key
- Efficient symmetric algorithm is used to encrypt the data
![This slide depicts an envelope with a signature and a wax seal over the letter flap.](cse201p1ppt20.jpg)
In this presentation we focus on asymmetric (or "public-key") cryptography as this enables digital signatures and asymmetric encryption, which in turn enable secure ad hoc networking
Image source: pixabay.com
Slide 34:
Certificate Authorities
-
Certificate Authorities (CAs) are essential for asymmetric crypto
- Establish trust between two previously unknown users
- CAs issue certificates (using their private keys) to qualified users
-
CAs are trusted to
- Keep their private keys secure
- Ensure that users are entitled to the requested certificate, often delegated to a Registration Authority (RA)
![Author’s relevant description: This slide shows an image from Wikimedia that depicts the public key of "Mario Rossi" along with his contact information. The key is transmitted using a certificate authority that verifies the identity of Mario Rossi and encrypts the message with its private key producing a larger packet that includes the original public key and contact information, with an added validity time and a digital signature of the certificate authority.](cse201p1ppt21.jpg)
Image source: wikimedia.org
Slide 35:
Chain of Trust
-
Bob gets a certificate from a CA
- Bob’s certificate is signed by his CA’s certificate
- Bob’s CA’s certificate comes from another CA
- …and back to a CA that issued its own certificate, called a "root CA"
- Root CA certificate management is complex and will be dealt with later
![Author’s relevant description: This slide shows a green and a blue vehicle wishing to communicate with each other. The green vehicle has been assigned a certificate from a certificate authority (CA), which obtained an appropriate certificate from the root CA. The blue vehicle is presented as receiving this certificate and attempting to understand it by searching through the chain of the green car’s certificate, the issuing CA’s certificate, and the root CA’s certificate.](cse201p1ppt22.jpg)
Slide 36:
Chain of Trust
-
Bob gets a certificate from a CA
- …which is part of a chain of trust
-
When Alice receives a signed message from Bob, in order to trust it, she must:
- Already trust Bob’s certificate, or…
- Already trust Bob’s CA’s certificate, and have Bob’s certificate, or.
- Already trust the Intermediate CA certificate that issued Bob’s Authorization CA certificate and have the certificates below it, or…
- Already trust the Root CA certificate at the top of the chain, and have the other certificates
![This slide includes the same graphic that was on Slide #35.](cse201p1ppt23.jpg)
Slide 37:
IEEE 1609.2 Certificate
-
Main features of IEEE 1609.2 certificates
- Smaller size
- Suitable for machine-to-machine communications
- Allows pseudonym certificates
-
Allows the SCMS to issue certificates for all types of CV applications
- Use of PSID to identify applications allows new applications to be added ° Including drones, autonomous delivery robot identification,…
![Author’s relevant description, example image only: The slide shows the contents of an IEEE 1609.2 certificate.](cse201p1ppt24.jpg)
Image source: IEEE P1609.2.1
Slide 38:
SCMS Design
- At the core, SCMS is a standard PKI with Root CAs, Intermediate CAs, and end-user (authorization) CAs
-
Diagram shows that standard PKI chain of trust running up the middle
-
There may be a different number of Intermediate CAs - 0, 1, or more
- In Europe the convention is 0, in the US the convention is 1
-
Participating devices need:
- Root CA management to know which incoming messages to trust
- Authorization CA interaction to obtain certificates to sign messages
![Author’s relevant description: This slide includes the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). This time, the "Root CA", "Intermediate CA", "Authorization CA", and "OBU/RSU/ASD" boxes are shaded in green.](cse201p1ppt25.jpg)
Image source: IEEE P1609.2.1
Slide 39:
SCMS Design
![Please see extended text description below.](cse201p1ppt26.jpg)
(Extended Text Description: This figure contains a bullet list on the left and a graphic on the right. The bullet list reads:
-
The SCMS has a lot of different components
- More details on the next slides
-
In principle each component could be run by a different company
-
Design is modular and internal interfaces are documented though not formally standardized
- Root CA by Alice’s SCMS Services
- Intermediate CA by Bob’s SCMS Services
- Authorization CA by SCMS-R-Us,…
- In this case, a deployer would engage with a Registration Authority operator who would interface to the rest of the SCMS operators
-
In practice, currently a deployer will engage with a single SCMS provider who runs everything from the Root CA down
- If different deployers use different SCMS providers, their devices can still trust each other – see later discussion of root CA management
Additionally, some text in the bullet list is highlighted to correspond with sections of the diagram on the right, which is the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). On this variation of the title slide SCMS graphic, everything other than the Root Management Function and the OBU/RSU/ASD boxes are shaded in yellow with the Root CA highlighted in purple to associate it with Alice’s SCMS services, the Intermediate CA is highlighted in blue to associate it with Bob’s SCMS services, and the Authorization CA is highlighted in red to associate it with what the body of the slide describes as "SCMS-R-Us" (i.e., "SCMS are us").)
Image source: IEEE P1609.2.1
Slide 40:
SCMS Design: Two types of certificates
-
Authorization certificates
- Used for application interactions with other end-entities
- Specify the application activities that the holder is entitled to
-
Enrollment certificates
- Used for certificate management interactions
- Authorize authorization certificate request and download
-
Long-term "identity", used by SCMS component as a key for metadata
- What permissions can go in the authorization certificate
- Whether the enrollment certificate holder is entitled to auth certificates at all
- Separating Enrollment CA (ECA) and Authorization CA (ACA) improves robustness and privacy
![Author’s relevant description: This slide includes the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). This time, the Enrollment CA and Authorization CA boxes are highlighted.](cse201p1ppt27.jpg)
Image source: IEEE P1609.2.1
Slide 41:
SCMS Design: Contact points with the SCMS
- End entities directly contact only three components of the SCMS
- Enrollment Certificate Authority (ECA) -enrollment certificates
-
Registration Authority (RA) - gateway for SCMS interactions while in the field
- Authorization certificate provisioning -gateway to authorization CA
- Misbehavior report upload - gateway to MA
-
Security management info download
- Certificate revocation list
- New Root CA information
-
Distribution Center (DC) - alternative path to download security management info
- RAs provide security info only to devices that they also provide cert management services to - DC may provide security info to wider population
![Author’s relevant description: This slide includes the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). This time, the Enrollment CA, Authorization CA, Registration Authority, and Distribution Center boxes are highlighted.](cse201p1ppt28.jpg)
Image source: IEEE P1609.2.1
Slide 42:
SCMS Design: Contact points with the SCMS contd.
-
Contacting the ECA: happens at start of EE lifetime, can be proprietary interface
- 1609.2.1 provides standardized interface but this is not required
-
Contacting the RA:
- Each EE has a single "home" RA which it is hard-wired to use
- The RA is identified by a URL, has a certificate including that URL
-
Contacting the DC:
- DC accessed by URL
- There may be multiple DCs
- Standards do not address how EEs are configured with DC URLs
-
Interfaces are standardized in IEEE 1609.2.1 (pub. 2020-12)
- Connected Vehicle Pilot Deployments used a previous interface, the "CAMP Interface"
- The CAMP interface is still widely supported but deployments are migrating to 1609.2.1
![Author’s relevant description: This slide includes the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). This time, the Enrollment CA, Registration Authority, and Distribution Center boxes are highlighted.](cse201p1ppt29.jpg)
Image source: IEEE P1609.2.1
Slide 43:
SCMS Design: Pseudonym certificate request
-
To preserve privacy, Basic Safety Message (BSM) senders use a special type of authorization certificate: pseudonym certificate
- Pseudonym certificates don’t contain any identifying information about the sender
- A BSM sender has multiple pseudonym certificates all valid at the same time and can change from using one to using a different one at will
- This makes it hard to track vehicles
- Typically, pseudonym certificates are valid for a week
- Revocation of pseudonym certificates is complicated
![This slide shows a section of roadway with two connected vehicles on it sharing information, including acceleration, location, and speed. A hacker is overlaid on the image, but the image is also labeled with an image showing a person with a line through it and labeled "No Personal Information Shared".](cse201p1ppt30.jpg)
Image source: USDOT, wikimedia.org
Slide 44:
SCMS Design: Authorization certificate request contd.
-
Authorization cert request optionally uses a technique called butterfly keys
- This allows the end entity to send a single request and all of its certificates for the rest of its operating life can be generated using that request as a seed
- A single request generates all 20+ certificates for a given week, and also the certificates for all future weeks
- Greater efficiency: allows the certificates to be generated at the time that makes most sense within the SCMS, not tied to the time of request
- Better privacy: decouples the time of generation from the time of request, so the ACA can’t link different requests together as they were received at the same time
![Author’s relevant description: This slide displays a figure similar to Figure 3 from IEEE 1609.2 and depicts the butterfly key expansion. The top portion of the figure is labeled "Device" and contains three sets of boxes. The first set is a bounded set with one box labeled "a" and the other labeled "A". The "a" box is connected to an "expansion" box, which is connected to the second set of boxes, where the first box is labeled "b1" and the other box is labeled "bn". The b1 box is connected to another box labeled with a plus symbol, which is connected to the third set of boxes. The third set of boxes is a bounded set with the top box labeled "Private Key" and the lower box labeled "Cert". Box A then connects to the middle section, which is labeled "RA" for registration authority and connects to a box labeled "expansion". The expansion box connects to a series of boxes labeled "B1", "B2", …, "Bn". the B1 box connects to the bottom section of the diagram. The bottom section is labeled "PCA" and the arrow from "B1" connects to a box labeled "Cert", which is next to a box labeled "C". The Cert box connects to the Cert box at the top of the diagram and the C box connects to the plus arrow at the top of the diagram.](cse201p1ppt31.jpg)
Slide 45:
SCMS Design: Authorization certificate request contd.
-
An end entity device can run any number of applications.
- For example, RSU running WSA and SPaT
-
Applications can share a certificate (one cert authorizes messages for multiple applications) or have distinct certificates (one cert per application)
- Tradeoff: storage space v authorization complexity
-
The SCMS may make policy about which applications can share a certificate
- In principle the SCMS may make policy about which applications can share a device, but this is currently not a subject of SCMS policy
- Unless there is a good reason to couple applications, it is often easier to have separate certificates for separate applications
![Author’s relevant description: This slide shows the green and blue cars previously encountered in this presentation such as on slide #35 with the green car presenting its certificate. There is now a third, red car which is presenting a certificate with an "X" over it.](cse201p1ppt32.jpg)
Slide 46:
SCMS Design: Misbehavior management
-
The system allows for devices that send bad data to be removed
- Examples: Cars in mid-air, two cars in the same place, cars that say they’re braking but speed up
- End entities report misbehavior to their RA
- The RA passes the reports to a central Misbehavior Authority (MA)
- The MA analyses the reports and decides whether the bad data an end entity is sending is having a significant effect on the system
![Author’s relevant description: This slide includes the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). This time, the Misbehavior Authority, Registration Authority, and OBU/RSU/ASD boxes are highlighted.](cse201p1ppt33.jpg)
Slide 47:
SCMS Design: Misbehavior management contd.
- If the bad data is sufficiently impactful, the MA revokes the end entity
- A Certificate Revocation List (CRL) is issued telling other end entities not to trust the revoked end entity
- The end entity’s RA is told not to let it have any more certificates
- The CRL is distributed via the RAs and distribution centers
![Author’s relevant description: This slide includes the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). This time, the three CRL Signer, Misbehavior Authority, two Linkage Authorities, Registration Authority, Distribution Center, and OBU/RSU/ASD boxes are highlighted.](cse201p1ppt34.jpg)
Slide 48:
SCMS Design: Misbehavior management details -Certificate Revocation List (CRL)
-
The CRL is a list of revoked certificates
- When a receiver gets a signed message, it checks to see if the signing certificate is on the CRL
- If the signing certificate is revoked, the receiver considers the message invalid
-
The CRL only revokes currently valid certificates -expired certificates are automatically not trusted
- If a device’s certificate(s) will expire in the near future relative to when misbehavior is detected, it may not be necessary to revoke it depending on policy
![Author’s relevant description: This slide shows an image of a certificate revocation list (CRL) as showing an identifier and a listing of various revoked certificates.](cse201p1ppt35.jpg)
Slide 49:
SCMS Design: Misbehavior management details -Certificate Revocation List (CRL)
-
Each CRL signer can only revoke a particular set of devices, and each device can only be revoked by one CRL Signer
- This limits the damage that a "rogue" CRL signer can do
![Author’s relevant description: This slide shows the same example image of a CRL but shows the CRL ID being checked and then zooms in on a specific revoked certificate and shows that the CRL ID must be authorized to revoke each certificate in its list.](cse201p1ppt36.jpg)
Slide 50:
SCMS Design: Misbehavior management details - CRL contd.
-
Pseudonym certificates are revoked using a field called a linkage value that appears in the certificate
- This allows a single CRL entry to efficiently revoke all of that vehicle’s pseudonym certificates
![Author’s relevant description: This slide shows the same example image of a CRL but shows a series of revoked certificates all associated with one vehicle.](cse201p1ppt37.jpg)
Slide 51:
SCMS Design: Misbehavior management and privacy
- To investigate misbehavior, the MA may need to work out which certificates belong to the same EE
- For privacy, the SCMS builds in a complex set of components
- Misbehavior investigation and revocation involve: ACA, CRL signer, Linkage Authorities (LA1, LA2), MA, RA
-
The components interact through standardized, auditable processes to ensure that privacy-breaching requests cannot be made
- These processes are not complete but the principles behind them are well understood
![Author’s relevant description: This slide includes the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). This time, the three CRL Signer, Misbehavior Authority, Authorization CA, two Linkage Authorities, Registration Authority, and OBU/RSU/ASD boxes are highlighted.](cse201p1ppt38.jpg)
Slide 52:
SCMS Design: Misbehavior management - current status
- CRL generation and distribution is fully standardized but the rest of the misbehavior management system is not complete (as of 2020-12)
-
No standards for misbehavior reporting by end entities
- ETSI is producing a survey of proposals and options in TR 103 460
- Pilot Deployments have defined baseline misbehavior detection and reporting algorithms
- University of Michigan is doing more advanced research
- It’s unlikely that there will be standardized mechanisms before 2021
-
No systematic process for detecting misbehavior by SCMS entities
- The assumption is that if there is significant bad issuing of certs, it will be caught by noting high levels of misbehavior by those end entities
Slide 53:
SCMS Design: SCMS Manager
-
SCMS Manager
- Sets overall SCMS policies
- Coordinates the approval or removal of an elector or a root CA
- Examples: security and certificate policy from the EU and the DG GROW
- As of 2020, a US SCMS Manager has been established as an industry organization with observer participation from USDOT
- For deployments in the near future, there will probably be a single SCMS provider who will effectively act as the SCMS Manager
![Author’s relevant description: This slide includes the same graphic used on the title slide #3 that provides an overview of the security credentials management system (SCMS). This time, the SCMS Manager cloud is highlighted.](cse201p1ppt39.jpg)
Slide 54:
Multiple Root CAs
- Devices usually get certs that chain back to a single Root CA
-
Different devices could chain back to different Root CAs
- For interoperability, devices must trust each other’s Root CAs
- At the time of writing only one Root CA is widely used in the US but there are multiple Root CA suppliers
-
Deployment managers determine if support for multiple Root CAs is required
- Client software supports installing multiple root CA certificates in a "trust store" - if this is a requirement for the deployment, it can be supported
- Future: Elector system, standardized in 1609.2.1
![Author’s relevant description: This slide shows a SCMS manager cloud connected to the Root Management Function by a line that says "OK to add". The Root Management Function is noted with an indication that a quorum is more than 50% of members and that each member/elector has a key (in this case, three are shown as blue, yellow, and green keys). Each key is linked to an associated colored entry within a Certificate Trust List along with entries provided by keys for three Root CAs (in this case shown as a red, cyan, and orange color). Finally, the CTL is locked/signed by all three elector keys.](cse201p1ppt40.jpg)
Slide 55:
Electors
-
Electors are entities that sign Certificate Trust Lists (CTLs)
- CTLs are trust statements about Root CAs and other electors
-
The trust decisions are made by the SCMS Manager - Electors act effectively as notaries for those decisions
- The end entities trust the Electors as a matter of crypto, but the Electors are just validating the SCMS Manager’s decision
![This slide shows the same diagram with description on slide #54.](cse201p1ppt41.jpg)
Slide 56:
Electors contd.
- Electors are entities that sign Certificate Trust Lists (CTLs)
-
A CTL is trustworthy if it is signed by a quorum ("m of n") Electors
- The number of Electors and the quorum are system parameters selected by the SCMS Manager
- Having multiple Electors gives robustness against compromise and smoother transitions when an Elector certificate is retired
![This slide shows the same diagram with description on slide #54.](cse201p1ppt42.jpg)
Slide 57:
Electors contd.
- Electors are entities that sign Certificate Trust Lists (CTLs)
- A CTL is trustworthy if it is signed by a quorum ("m of n") Electors
-
When the Elector system is rolled out, deployment managers will no longer have to be concerned with specifying which Root CA to trust - everything will be handled automatically and transparently
- Electors currently exist under scmsmanager.org, client software support is under development
![This slide shows the same diagram with description on slide #54.](cse201p1ppt43.jpg)
Slide 58:
![Activity Placeholder: This slide has the word "Activity" in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.](cse201p1ppt44.jpg)
Slide 59:
Question 2
Which of the following is good practice for a CA? Answer Choices
- Share its private key with the authorities to assist with legal investigations of hackers.
- Issue certificates to anyone who pays a fee.
- Require end entities to submit a copy of their private key before receiving a certificate.
- Ensure that certificate requesters meet minimum standards for security and are entitled to the requested certificate.
Slide 60:
Review of Answers
a) Share its private key with the authorities to assist with legal investigations of hackers.
Incorrect. If the CA shared its private key this would allow anyone who knew the private key to issue certificates.
b) Issue certificates to anyone who pays a fee.
Incorrect. The CA should ensure that requesters are entitled to the requested certificate, not just that they have paid a fee.
c) Require end entities to submit a copy of their private key before receiving a certificate.
Incorrect. End entity private keys should exist only on the end entity device to ensure that no-one can forge signatures from that end entity.
d) Ensure that certificate requesters meet minimum standards for security and are entitled to the requested certificate.
Correct!
Slide 61:
Learning Objective 3
- Understand how devices participate in the SCMS to get certificates
Slide 62:
Parties Participating in the SCMS
- Deployment manager
- SCMS provider
- Device supplier
- Certification lab
![ANIMATIONS. This slide shows four boxes labeled: "Deployment manager", "SCMS provider", "Device supplier", and "Certification lab". The boxes are connected by labeled arrows indicating the following relationships: The Deployment manager engages the SCMS provider; The Deployment manager engages the Device supplier; The SCMS provider creates requirements and policies for the device supplier; The Device supplier follows requirements of the SCMS provider; The SCMS trusts the Certification lab; The Certification lab certifies the Device supplier.](cse201p1ppt46.jpg)
Slide 63:
Deployment Manager Responsibilities
- Selecting and contracting with SCMS provider
- Determining device suppliers
- Determining which set of Root CA certificates should be trusted
![This slide shows the same diagram as described on Slide #62, but the "Deployment manager" box is highlighted.](cse201p1ppt47.jpg)
Slide 64:
SCMS Provider Responsibilities
-
States certificate and security policies for devices with "standard" applications
- May include a requirement for third party type certification by certification labs - SCMS provider will indicate which certification labs are approved/accredited
- Works with deployment manager to specify certificate and security policies for deployment-specific applications
-
Runs
- Enrollment CA (ECA), Registration Authority (RA) (points of contact for devices as described in LO2)
- Authorization CA (ACA)
- In the future it will probably be possible to select ECA, RA, ACA from different providers
![This slide shows the same diagram as described on Slide #62, but the "SCMS provider" box is highlighted.](cse201p1ppt48.jpg)
Slide 65:
Device Supplier Responsibilities
- Provides deployment manager devices with 1609.2 and SCMS client software
- Responsible for meeting security and interoperability requirements
- May need to interact with certification lab
![This slide shows the same diagram as described on Slide #62, but the "Device supplier" box is highlighted.](cse201p1ppt49.jpg)
Slide 66:
Certification Lab Responsibilities
- Works with device supplier to determine that device meets requirements
- Trusted by SCMS Manager
- Not necessarily directly engaged by deployment manager but may interact with deployment manager
- Currently some certification services are provided by OmniAir
![This slide shows the same diagram as described on Slide #62, but the "Certification lab" box is highlighted.](cse201p1ppt50.jpg)
Slide 67:
Third-party SCMS Providers
- It is recommended to use a third party SCMS provider
-
Running SCMS components is not easy, specially Root CAs
-
Secure key storage
- Some SCMS providers use a vault in a mountain!
- Waking the CA up and using it
- Enforcement of policy
- Audit
- Potential liability
- SCMS should be run internally only if the manager has significant experience running Public Key Infrastructure (PKI)
![This slide shows an image of a safe floating in the air in the mountains.](cse201p1ppt51.jpg)
Image source: wikimedia.org
Slide 68:
Interactions between devices and the SCMS
- All devices that use certificates should come fully equipped with certificate management software
- Deployment sites may also want centrally generated messages, e.g., map messages or traveler information messages
![This slide shows a "Map Generation Center" as a map residing on a cloud on the left-hand side of the diagram. In the middle left of the diagram there is a picture of a "Traffic Management Center" (TMC). In the middle right, there is a picture of a controller cabinet representing a "Connected Vehicle Roadside Unit" (RSU) coupled with a picture of a "Short Range Wireless Radio" that is wirelessly connected to a connected vehicle, represented by a car icon. Underneath the figure there are notes explaining that the map is generated at the Map Generation Center and forwarded by the TMC to the RSU, which stores and repeats the broadcast of this map to connected vehicles. By comparison, Traveler Information Messages (TIMs) are generated and signed at the TMC and sent to the RSU, which stores and repeats the broadcast of the TIM to connected vehicles. Finally, the signal phase and timing message (SPaT) is generated and signed by the RSU and sent to connected vehicles directly – with updates in real-time.](cse201p1ppt52.jpg)
Slide 69:
Interactions between devices and the SCMS contd.
-
These should be signed centrally rather than at RSUs
- Messages should be signed at the point of generation not distribution
- If all RSUs can sign a "centrally generated" message, then a compromised RSU allows the system to be (temporarily) flooded with fake messages
-
This will require negotiation with the SCMS provider to set the security requirements
- Is it enough to generate the message on a box at the Traffic Management Center (TMC) with a smartcard or is an appliance with heightened security needed?
- What are network security requirements to ensure correct operation on the box at the TMC?
- Existing deployments have successfully used certificates for centrally generated messages, so the problem can be addressed
- If centrally generated messages will be part of a deployment, then security requirements should be addressed early in the process
Slide 70:
![Activity Placeholder: This slide has the word "Activity" in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.](cse201p1ppt53.jpg)
Slide 71:
Question 3
What is the minimum number of Root CAs that must be supported in a deployment?
Answer Choices
- Zero.
- One.
- Two.
- All existing Root CAs.
Slide 72:
Review of Answers
a) Zero.
Incorrect. If no Root CAs are trusted, the system cannot operate.
b) One.
Correct!
c) Two.
Incorrect. A system can operate correctly with only one trusted Root CA.
d) All existing Root CAs.
Incorrect. When the Elector system is stood up, devices will automatically trust all Root CAs, but this is not necessary for a deployment.
Slide 73:
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
Slide 74:
Next Course Module
Module CSE 201: Introduction to SCMS Part 2 of 2
Concepts taught in next module (Learning Objectives):
- 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 75:
Next SCMS Module
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 76:
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!
↑ Return to top