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

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.pcb.its.dot.gov

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.

Image source: IEEE P1609.2.1

Slide 4:

Instructors

Photo of Dr. William Whyte

Dr. William Whyte

Senior Director, Technical Standards

Qualcomm Technologies, Inc.

Photo Dr. Virendra Kumar

Dr. Virendra Kumar

Senior Staff Engineer, Technical Standards

Qualcomm Technologies, Inc.

Slide 5:

Learning Objectives

Slide 6:

Learning Objectives - Part 1 of 2

Slide 7:

Learning Objective 1

Slide 8:

Security of deployments and the role the SCMS plays in that security

Slide 9:

Need for Trust

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.

Image source: USDOT

Slide 10:

Need for Trust contd.

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.

Image source: USDOT

Slide 11:

What’s Unique about Connected Vehicle (CV)?

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.

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.

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.

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".

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.

Image source: wikimedia.org

Slide 17:

Functional Requirements

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".

Image source: wikimedia.org

Slide 18:

System Security Requirements

Slide 19:

System Security Requirements

Please see extended text description below.

(Extended Text Description: This figure contains two bullet lists, the one on the left reads:

Additionally, the text "Limited capacity channels" is highlighted. On the right is another bullet list that is all highlighted:

)

Slide 20:

System Security Requirements

Please see extended text description below.

(Extended Text Description: This figure contains two bullet lists, the one on the left reads:

Additionally, the text "Role-based Access Control" is highlighted. On the right is another bullet list that is all highlighted:

)

Slide 21:

System Security Requirements

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).

Image source: IEEE P1609.2.1

Slide 22:

Privacy Requirements

Slide 23:

Privacy Requirements

Slide 24:

Privacy Requirements: Data management

Slide 25:

How Does the SCMS Address All This?

Slide 26:

How Does the SCMS Address All This?

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.

Slide 28:

Question 1

Which of the following statements about privacy is not true?

Answer Choices

  1. There are many ways to track drivers on the road.
  2. To preserve privacy, consideration must be given both to how data is created and transmitted, and also to how it is stored and managed.
  3. Protecting privacy uses both technological and policy approaches.
  4. The V2X system must always completely protect the anonymity of drivers.

Slide 29:

Review of Answers

A small graphical red and yellow X representing incorrect.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.

A small graphical red and yellow X representing incorrect.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.

A small graphical red and yellow X representing incorrect.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.

A small graphical green and yellow check mark representing correct.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

Slide 31:

Digital Signature

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.

Image source: wikimedia.org

Slide 32:

Digital Signature contd.

Slide 33:

Encryption

This slide depicts an envelope with a signature and a wax seal over the letter flap.

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

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.

Image source: wikimedia.org

Slide 35:

Chain of Trust

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.

Slide 36:

Chain of Trust

This slide includes the same graphic that was on Slide #35.

Slide 37:

IEEE 1609.2 Certificate

Author’s relevant description, example image only: The slide shows the contents of an IEEE 1609.2 certificate.

Image source: IEEE P1609.2.1

Slide 38:

SCMS Design

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.

Image source: IEEE P1609.2.1

Slide 39:

SCMS Design

Please see extended text description below.

(Extended Text Description: This figure contains a bullet list on the left and a graphic on the right. The bullet list reads:

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

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.

Image source: IEEE P1609.2.1

Slide 41:

SCMS Design: Contact points with the SCMS

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.

Image source: IEEE P1609.2.1

Slide 42:

SCMS Design: Contact points with the SCMS contd.

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.

Image source: IEEE P1609.2.1

Slide 43:

SCMS Design: Pseudonym certificate request

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".

Image source: USDOT, wikimedia.org

Slide 44:

SCMS Design: Authorization certificate request contd.

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.

Slide 45:

SCMS Design: Authorization certificate request contd.

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.

Slide 46:

SCMS Design: Misbehavior management

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.

Slide 47:

SCMS Design: Misbehavior management contd.

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.

Slide 48:

SCMS Design: Misbehavior management details -Certificate Revocation List (CRL)

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.

Slide 49:

SCMS Design: Misbehavior management details -Certificate Revocation List (CRL)

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.

Slide 50:

SCMS Design: Misbehavior management details - CRL contd.

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.

Slide 51:

SCMS Design: Misbehavior management 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 three CRL Signer, Misbehavior Authority, Authorization CA, two Linkage Authorities, Registration Authority, and OBU/RSU/ASD boxes are highlighted.

Slide 52:

SCMS Design: Misbehavior management - current status

Slide 53:

SCMS Design: 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.

Slide 54:

Multiple Root CAs

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.

Slide 55:

Electors

This slide shows the same diagram with description on slide #54.

Slide 56:

Electors contd.

This slide shows the same diagram with description on slide #54.

Slide 57:

Electors contd.

This slide shows the same diagram with description on slide #54.

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.

Slide 59:

Question 2

Which of the following is good practice for a CA? Answer Choices

  1. Share its private key with the authorities to assist with legal investigations of hackers.
  2. Issue certificates to anyone who pays a fee.
  3. Require end entities to submit a copy of their private key before receiving a certificate.
  4. Ensure that certificate requesters meet minimum standards for security and are entitled to the requested certificate.

Slide 60:

Review of Answers

A small graphical red and yellow X representing incorrect.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.

A small graphical red and yellow X representing incorrect.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.

A small graphical red and yellow X representing incorrect.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.

A small graphical green and yellow check mark representing correct.d) Ensure that certificate requesters meet minimum standards for security and are entitled to the requested certificate.
Correct!

Slide 61:

Learning Objective 3

Slide 62:

Parties Participating in the SCMS

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.

Slide 63:

Deployment Manager Responsibilities

This slide shows the same diagram as described on Slide #62, but the "Deployment manager" box is highlighted.

Slide 64:

SCMS Provider Responsibilities

This slide shows the same diagram as described on Slide #62, but the "SCMS provider" box is highlighted.

Slide 65:

Device Supplier Responsibilities

This slide shows the same diagram as described on Slide #62, but the "Device supplier" box is highlighted.

Slide 66:

Certification Lab Responsibilities

This slide shows the same diagram as described on Slide #62, but the "Certification lab" box is highlighted.

Slide 67:

Third-party SCMS Providers

This slide shows an image of a safe floating in the air in the mountains.

Image source: wikimedia.org

Slide 68:

Interactions between devices and the SCMS

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.

Slide 69:

Interactions between devices and the SCMS contd.

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.

Slide 71:

Question 3

What is the minimum number of Root CAs that must be supported in a deployment?

Answer Choices

  1. Zero.
  2. One.
  3. Two.
  4. All existing Root CAs.

Slide 72:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Zero.
Incorrect. If no Root CAs are trusted, the system cannot operate.

A small graphical green and yellow check mark representing correct.b) One.
Correct!

A small graphical red and yellow X representing incorrect.c) Two.
Incorrect. A system can operate correctly with only one trusted Root CA.

A small graphical red and yellow X representing incorrect.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

Slide 74:

Next Course Module

Module CSE 201: Introduction to SCMS Part 2 of 2

Concepts taught in next module (Learning Objectives):

  1. Identify the Vehicle-to-Everything (V2X) certification process for a device to enroll in the SCMS
  2. Illustrate how to make a deployment plan that uses SCMS services

Slide 75:

Next SCMS Module

A small graphical green and yellow check mark representing correct. CSE 201:
Introduction to Security Credential Management System Part 1 of 2

A small blank spacer for layout. 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