Certificate Management Protocols for 1609.2 Certificates

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/309354289
Certificate management protocols for 1609.2 certificates
Presentation · October 2016
DOI: 10.13140/RG.2.2.26599.44962
CITATIONS
0
READS
34
1 author:
Some of the authors of this publication are also working on these related projects:
V2X Security Credential Management System Proof-of-Concept View project
William Whyte
Security Innovation, Inc.
39 PUBLICATIONS 568 CITATIONS
SEE PROFILE
All content following this page was uploaded by William Whyte on 22 October 2016.
The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.

Certificate management
protocols for 1609.2 certificates
William Whyte, 2016-09-09
Updated, 2016-10-13

Structure of this presentation
• Intro material – terminology, etc
• Use case overview and topology
• Interfaces
• Source material:
• http://www.its.dot.gov/pilots/pdf/SCMS_POC_EE_Requirements.pdf
• https://stash.campllc.org/projects/SCMS/repos/scms-asn/browse
2

Terminology
• Operational cert – a cert used for any purpose
other than cert request
• Authorization cert – a cert used for any
purpose other than cert issuance or cert
request
• End-entity – an entity that uses a cert for a
purpose other than cert issuance.
• End-entity cert: a cert belonging to an end-entity
• Types of authorization cert:
• Pseudonym cert: used by OBE when it needs
some level of privacy
• Identification cert: used by OBE when it doesn’t
need privacy, e.g. when doing signal preemption
• Application cert: used by RSE
• Identification and application certs are very
similar to each other
ICA
Cert
PCA
Cert
ECA
Cert
Enrol-
ment
Cert
Enrol-
ment
Cert
Enrol-
ment
Cert
Pseudo
nym
Cert
Authorization Cert
ICA
PCA ECA
Identified OBE
Identif-
ication
Cert
Root CA
RSE
Appli-
cation
Cert
OBE
Operational Cert
End-Entity Cert
Root
Cert
3

Full SCMS Structure
Interfaces addressed in
this presentation
4

PKI Components Unique to SCMS
5

Basic Overview
To Enrollment
Certificate
Authority: prove
eligibility
Receive ONE
enrollment
certificate
Certificate
Provisioning
Participate
in V2X
Enrollment
To Registration
Authority: Show
enrollment
certificate
Receive SET of
pseudonym
certificates
Or ONE
identification
certificate (vehicle)
Or ONE
application
certificate (non-
vehicle)
6

Device lifecycle SCMS interactions
• Basic cycle
• Bootstrap
• Initialization – load device with certs that let it trust others
• enrollment – request an enrollment cert that it uses to get operational certs
• Certificate request
• Certificate download
• Special cases
• Misbehavior reporting
• Revocation
• Re-enrollment?
• End-of-life
• Update management information (throughout lifecycle)
7

Functional entities
Bootstrap Operational cert provisioning
PCA
RA
LOP
1. Request pseudonym
certificates
2. Strip location data
and forward
3. Validate request,
strip enrolment
certificate, expand
into individual
requests, shuffle with
other requests and
forward to PCA
4. Issue individual
pseudonym
certificates, encrypt
for end-entity, send
back to RA
5. Aggregate
responses belonging
to individual devices
and store for
download
6. Allow download
through LOP when
download request is
authenticated with
enrolment cert
7. Download batch,
decrypt, check for
correctness
End-Entity
1. Request containing
public key for
certificate
3'. Forward response containing
enrollment certificate, plus
other information
2. Issue enrollment
certificates
1'. Authenticated request
containing public key
for certificate
3. Response containing
enrollment certificate
Secure Environment
ECA
DCM
End-Entity
8

Types of operational cert and how they’re
requested
• Pseudonym certificate
• Typically for an application sending from a vehicle
• Holder (the application) has multiple pseudonym certs for a given application valid at one time to allow cert tumbling
• Requested using an enrollment certificate
• Identification certificate
• For an application sending from a vehicle
• Holder has one at a time and does not change frequently
• Used to carry out activities that don’t have a need for pseudonymity, e.g. high-priority emergency response activities
• Application certificate
• For an application running on a non-vehicle device
• Holder has one at a time and does not change frequently
• SCMS component certificate
• Typically not requested using an enrollment certificate; instead requested manually or using the canRequestRollover field
• Not a focus of this presentation, this presentation focuses on certs for end-entities
9

Certificate lifecycle
• Initialization: same process for all types
• enrollment: same interface for all types, though enrollment for different types of cert may be
carried out in different environments
• E.g. enrollment to sign BSMs might be carried out at the OEM while enrollment to be a police car might be
carried out at an upfitter
• Initial Operational Cert Request: similar interfaces, though pseudonym certificates fill in different
fields from application and identified certs
• Download and ongoing top-up: different approaches
• Pseudonym and identification certs: Cert request is created once; certs are pre-generated by the SCMS and
stored by the RA; device downloads certs when possible.
• Application certs: Certs are not pre-generated; the device submits a certificate request every time it wants a
new cert, waits for it to be generated, then downloads it
• Revocation: download CRL from the CRL Store
• Re-enrollment: not currently supported as anything other than enrollment from scratch; support
planned for version 2.0
• Security management: same process for all types
10

Connectivity assumptions
• Assume that basic OBE, i.e. OBE that just sends BSMs, has connectivity at
least once in every three-year period
• Assume that OBE that carries out more highly-privileged operations, i.e.
has an identification cert, can get connectivity at least once a day
• Assume that RSEs can have connectivity when necessary but don’t
necessarily have it immediately
• Once devices are in the field, they connect to the SCMS for bidirectional
communication via their RA or via some other CDN
• RA manages cert request, cert download, configuration / policy
• CRLs may come from the RA or from a different CDN
• Information that can be broadcast may be distributed via other means, e.g. peer to peer /
mesh networking; techniques still being worked out
11

Configuration / management information
• Certificate chain file
• Information about added or removed root certs
• Each device is provisioned with initial set of root certs and “electors” to manage them
• This file contains the changes to that set
• Other trusted CAs
• Global and local versions
• Global CCF (GCCF) contains all trusted certs
• An RA can create a Local Certificate Chain File (LCCF) to reduce download size for its client devices; it must contain at least the CA certs
the device needs to trust its own certs
• Policy file
• Configuration information about cert request – how many pseudonym certs per batch, lifetime of pseudonym certs, etc
• Global (GPF) and Local (LPF) versions, Local is created by RA but signed by policy generator.
• CRLs
• Configuration update
• When connecting to the RA for cert download, a device should first download the LCCF and LPF
• It can indicate which version of LCCF and LPF it has in the request and RA can inform it if that is the most recent one, avoiding need to
download again.
• Device downloads CRL from MA
12

Interfaces
Underlying design: ASN.1 module structure
13

SCMS diagram again
Interfaces addressed in
this presentation
14

Interface specification
• What is specified?
• PDUs – ASN.1
• Transfer process – how PDUs are moved around
• All interfaces are optional and can be replaced with a different one that
accomplishes the same goals subject to approval by SCMS Manager
• Procedure for approving interfaces is still TBD
• WW personal expectation is that almost all devices will use standardized
PDUs and transfer process
• Note (1): There may be a lot of proprietary EE-DCM interfaces, both at PDU and
transfer level, used for initialization
• Note (2): Different devices may have different means of obtaining connectivity (e.g.
WSA + 5.9 / cellular / WiFi / …) but this is at a level below the interface spec
15

ASN.1 – module structure
• Available from
https://stash.campllc.org/projects/SCMS/repos/scms-
asn/browse.
• File structure:
• Two files for each interface, one for PDUs, one for error codes
• Names are xxx-yyy.asn, xxx-yyy-errors.asn, xxx and yyy are the
names of the components on either side of the interface in
alphabetical order
• Each file is one ASN.1 module with an identifier from the tree
• Ieee1609dot2Scms {iso(1) identified-organization(3) ieee(111)
standards-association-numbered-series-standards(2) wave-
stds(1609) dot2(2) scms (2)} interfaces(1)}
• PDU modules have an identifier from the tree
{Ieee1609dot2Scms interfaces(1)}
• Error modules have an identifier from the tree
{Ieee1609dot2Scms errors(2))}
• There are also files that don’t fit this model:
• Common files: scms-base-types.asn, scms-common-errors.asn
• GPF, LPF: scms-policy.asn. GCCF, LCCF: cert-chain-files.asn.
• Hierarchy files: scms-error.asn, scms-protocol.asn
• Discussed on the next slide
Interface File name Module name base string Identifier
Issuing CA –
SCMS
component
component-cert-
management.asn
Ieee1609Dot2ScmsComponentCertificateManagement 3
DCM – ECA dcm-eca.asn Ieee1609Dot2DcmEcaInterface 4
ECA – End
Entity
eca-ee.asn Ieee1609Dot2EcaEndEntityInterface 5
End Entity –
LOP
ee-lop.asn Ieee1609Dot2EndEntityLopInterface 6
End Entity –
MA
ee-ma.asn Ieee1609Dot2EndEntityMaInterface 7
End Entity –
RA
ee-ra.asn Ieee1609Dot2EndEntityRaInterface 8
LA – MA la-ma.asn Ieee1609Dot2LaMaInterface 9
LA – PCA la-pca.asn Ieee1609Dot2LaPcaInterface 10
LA – RA la-ra.asn Ieee1609Dot2LaRaInterface 11
LOP – MA lop-ma.asn Ieee1609Dot2LopMaInterface 12
MA – PCA ma-pca.asn Ieee1609Dot2MaPcaInterface 13
MA – RA ma-ra.asn Ieee1609Dot2MaRaInterface 14
PCA –RA pca-ra.asn Ieee1609Dot2PcaRaInterface 15
DCM – End
Entity
dcm-ee.asn Ieee1609Dot2DcmEndEntityInterface 127
16

ASN.1 – PDU format: overview
• Each interface file exports a single top-level CHOICE structure
containing all PDU payloads that flow across that interface
• Each of these has its own version number for maximum
flexibility
• All exchanges are of a PDU of ASN.1 type Ieee1609Dot2Data
containing a PDU of type ScmsPDU
• Ieee1609Dot2Data is exported from the 1609.2 ASN.1 module
• May be unsecured, signed, encrypted, or certificate request
• ScmsPDU is a CHOICE between the interfaces
• XxxYyyPDU is a CHOICE between the messages on the
interface
• The ASN.1 encoding therefore ensures that each encoded
payload starts with a unique identifier of (interface, message
type)
• This is the case whatever encoding mechanism is used
• An alternative way of doing it would have been with Object
Identifiers -- extensibility is even easier but encodings tend
to be noticeably longer
17

ASN.1 – PDU format: overview
• Each interface file exports a single top-level CHOICE structure
containing all PDU payloads that flow across that interface
• Each of these has its own version number for maximum
flexbility
• All exchanges are of a PDU of ASN.1 type Ieee1609Dot2Data
containing a PDU of type ScmsPDU
• Ieee1609Dot2Data is exported from the 1609.2 ASN.1 module
• May be unsecured, signed, encrypted, or certificate request
• ScmsPDU is a CHOICE between the interfaces
• XxxYyyPDU is a CHOICE between the messages on the
interface
• The ASN.1 encoding therefore ensures that each encoded
payload starts with a unique identifier of (interface, message
type)
• This is the case whatever encoding mechanism is used
• An alternative way of doing it would have been with Object
Identifiers -- extensibility is even easier but encodings tend
to be noticeably longer
18

Example: Pseudonym Cert Provisioning ACK
ee-ra.asn
scms-protocol.asn
• Define contents of RA-End Entity Pseudonym
Cert Provisioning ACK
• EndEntityRaInterfacePDU is CHOICE of all PDUs
on the end-entity/RA interface
• ScmsPDU contains all interface PDU CHOICE
types
• ScopedXxx type within scms-protocol.asn
automatically adds PDU identifier
• Define SignedXxx type with profile saying
which SignedData fields are present
• PDU is application-layer encrypted so
SecuredXxx is EncryptedData
• So process for receiving is:
• Strip off 1609.2 headers till you get to an
unsecured data
• Assume that is an SCMS PDU
• Identify interface and ensure you are an entity
on that interface
• Identify payload and ensure you are the entity
meant to receive the payload
• Process the message
19

ee-ra.asn
scms-protocol.asn
types
unsecured data
on that interface
20

ee-ra.asn
scms-protocol.asn
types
unsecured data
on that interface
21

ee-ra.asn
scms-protocol.asn
types
unsecured data
on that interface
22

ee-ra.asn
scms-protocol.asn
types
unsecured data
on that interface
23

ee-ra.asn
scms-protocol.asn
types
unsecured data
on that interface
24

types
• Strip off 1609.2 headers, decrypting as
necessary, till you get to an unsecured data
on that interface
ee-ra.asn
scms-protocol.asn
25

types
on that interface
ee-ra.asn
scms-protocol.asn
26

ee-ra.asn
scms-protocol.asn
types
• Interpret as SCMS PDU
on that interface
27

ee-ra.asn
scms-protocol.asn
types
on that interface
28

ee-ra.asn
scms-protocol.asn
types
on that interface
29

ee-ra.asn
scms-protocol.asn
types
on that interface
30

ee-ra.asn
scms-protocol.asn
types
on that interface
31

Scope/impact of future interface
modifications
• Modifying an existing payload on XX-YY interface
• Change xx-yy.asn only
• Add a PDU on XX-YY interface
• Add PDU in xx-yy.asn
• Add the corresponding Scoped and Secured types in scms-protocol.asn
• Change how PDU Xxx is secured
• Modify SecuredXxx in scms-protocol.asn.
32

Interfaces
Transfer mechanisms
33

SCMS Protocol Messages
• The EE uses HTTP POST to send the SCMS protocol APDU to RA.
• The EE ASN.1 serializes the APDU and sends it as the HTTP POST Message
Body in binary form.
• All HTTP transfers are carried out over SSL
• The RA X.509 SSL certificate contains the RA URI and the EE rejects the
connection if the name is wrong.
34

File Download
• EE establishes a secure server-authenticated
TLS connection with RA (RA authenticates to
EE).
• The EE uses HTTP GET to make download
requests.
• There are two different kind of download
requests: authenticated and non-
authenticated
• Authenticated messages described on the next
slide.
• Non-authenticated download are plain HTTP GET
messages with an optional HTTP Header 'If-
None-Match' to identify the version of an
already downloaded file.
• The HTTP GET Range option may be used to
request a partial download for the purposes
of resuming a previously interrupted
download.
35

Authenticated download
• A HTTP Header named “Download-Req” is included in the
HTTP GET message.
• The value of this header is Base64 encoded ASN1
serialized SignedAuthenticatedDownloadRequest APDU
• This APDU is passed up to the application layer where it is
verified before the request is redirected to the appropriate
file
• RA validates the enrollment certificate against the internal
blacklist, and then verifies the enrollment certificate.
• RA validates the time-stamp against a configurable time
tolerance, and then digitally verifies the signature of the
current time.
• RA grants access to the file to download, if all verifications
were successful. Otherwise, RA closes the connection.
• A device can make multiple download requests within a given
TLS session; each request is authenticated.
36

Authenticated download
• A HTTP Header named “Download-Req” is included in the
HTTP GET message.
• The value of this header is Base64 encoded ASN1
serialized SignedAuthenticatedDownloadRequest APDU
• This APDU is passed up to the application layer where it is
verified before the request is redirected to the appropriate
file
• RA validates the enrollment certificate against the internal
blacklist, and then verifies the enrollment certificate.
• RA validates the time-stamp against a configurable time
tolerance, and then digitally verifies the signature of the
current time.
• RA grants access to the file to download, if all verifications
were successful. Otherwise, RA closes the connection.
• A device can make multiple download requests within a given
TLS session; each request is authenticated.
37

PATH /download/policy/local
HTTP Method GET
HTTP Request Body Empty
Parameters Optionally, the request may include the standard HTTP Header 'If-None-Match' containing the
filename of the local policy file that the EE currently possesses, excluding any path. For example:
If-None-Match: "lp_01_01.oer"
This is used to prevent the same policy file from being downloaded by the device multiple times.
Response File containing the local policy. The file name returned is of the form: lp_<X>_<Y>.<Z>
Where:
•X is the Policy Id, up to 32 octets in hexadecimal (this could be a truncated SHA-256 hash of policy file
content)
•Y is the i-value in hexadecimal (when the policy becomes active, for easier roll-over from an old to a
new policy)
•Z is one of the permitted encoding formats (oer) from the file name in the request message.
OR
An HTTP code of 304 (Not Modified), if the provided file name in the 'If-None-Match' header matches
the current version available on the RA server.
File download example: policy
(unauthenticated)
38

Interfaces
Certificate chain file, policy file, electors
39

GCCF->LCCF and GPF->LPF
• Global CCF (GCCF) contains all trusted SCMS component certs
• An RA can create an LCCF to reduce download size for its client devices; it
must contain at least the CA certs the device needs to trust its own certs
• Global Policy File contains global info about cert lifetimes, etc
• RA can create an LPF which is a subset of the GPF
• If it does that, the LPF must be signed by the global Policy Generator
• These files are not ScmsPDU types but ScmsFile, another “collection”
structure defined in scms-protocol.asn
• Certificate Chain File is defined in cert-chain-files.asn
• Policy File is defined in scms-policy.asn
40

GCCF -> LCCF
• Device must be provided with the CA certs that enable it to
determine that its own certs are trustworthy
• Device may obtain CA certs to trust other devices during normal
operation using P2PCD, or RA may choose to provide them in the
LCCF.
41

Electors
• Electors issue ballots that
<VERB> a <NOUN>:
• VERB: Endorse or revoke
• NOUN: Root CA or Elector
• Elector ballots are included in
the LCCF
• How Electors decide to endorse
or revoke is out of scope
• Currently provides technical
recovery w/o single point of
failure, may in future provide
some form of governance
42

Electors
• Electors issue ballots that <VERB> a
<NOUN>:
• VERB: Endorse or revoke
• NOUN: Root CA or Elector
• Elector ballots are included in the
GCCF and distributed to devices in
the LCCF
• How Electors decide to endorse or
revoke is out of scope
• Currently provides technical recovery
w/o single point of failure, may in
future provide some form of
governance
43

Interfaces
Underlying design: Cert request authentication
44

Authentication of Signed SPDUs v Cert
Request
• Rationale: It just ended up being cleaner
45

Request
Authorization Certificate
appPermissions certIssuePermissions certRequestPermissions
PSID = 0x20
SSP = default
Time + Geographic
Signed SPDU
PSID = 0x20type = signed payloadTime + Geographic
Enrolment Certificate
appPermissions certIssuePermissions certRequestPermissionsTime + Geographic
Signed Cert Provisioning Request
PSID = 0x20
SSP = default
Requested Permissionstype = certificate request crypto infoSubtype
PSID = 0x20
SSP = default
0 Î chain depth
app Î eeType
Time
46

Request
Authorization Certificate
appPermissions certIssuePermissions certRequestPermissions
PSID = 0x20
SSP = default
Time + Geographic
Signed SPDU
PSID = 0x20type = signed payloadTime + Geographic
Enrolment Certificate
appPermissions certIssuePermissions certRequestPermissionsTime + Geographic
Signed Cert Provisioning Request
PSID = 0x20
SSP = default
Requested Permissionstype = certificate request crypto infoSubtype
PSID = 0x20
SSP = default
0 Î chain depth
app Î eeType
Time
47

Interfaces
Underlying design: Errors
48

Errors
• HTTP reponse indicates an error
• HTTP error status indicates base reason for error – 400, 401, 500
• May contain additional, nonstandard, SCMS-POC-Error or SCMS-POC-
Error-Message header fields
• Currently only enabled in QA mode to avoid giving out status information
about SCMS to potential attackers

Interfaces
PDU contents for end entity bootstrapping
50

Bootstrap: Initialization
• Transfer mechanism: Unspecified
• What is transferred:
• Current root cert and elector certs (see later)
• Current Local Certificate Chain File
• Current Policy File
• Elector certs need to be transferred over a secure connection, others
don’t (but may as well be)
53

Bootstrap: Enrollment Request
• Transfer mechanism: via HTTP POST as
specified above
• What is transferred: enrollment request
• Defined in eca-ee.asn
• Contains contents of cert being requested
• The ECA knows that the request can be
trusted because it knows by out of band
means that that particular DCM is trusted
to forward enrollment cert requests for
those particular PSIDs/SSPs
• Request is signed by the private key
corresponding to the verification key in
the cert request, proving possession of
that private key
• In contrast to the C2C approach there is
no proof that the private key was
generated in hardware, only proof of
possession
54

Enrollment Processing
• ECA checks that request is valid
and issues cert in enrollment
response (next slide)
• DCM provides cert along with
LCCF, etc
55

Bootstrap: Enrollment Response
• Transfer mechanism:
• Response to HTTP POST
• What is transferred: enrollment
response
• Defined in eca-ee.asn
• Contents:
• Identifier for request
• ECA cert
• RA Hostname
• RA cert (to allow pseudonym cert
request to be encrypted)
• enrollment cert
56

Interfaces
General approach to RA interactions
57

General RA interface
• All Registration Authority Services use
the same scheme (HTTPS) and
port 8892.
• All requests to RA have URLs of the
form https://<SERVER>:8892/<PATH>
where
• <SERVER> is the IP or host name
• PATH is the name of the service.
• For all the services, the HTTP Content-
Type is set to application/octet-
stream.
• No information is returned in case of
error, just an HTTP code of 500, in a
production environment.
Service Name <PATH>
Request Application Certificate
Provisioning
/provision-application-certificate
Download .info file /download/info
Download local policy file /download/policy/local
Download Pseudonym Certificate Batch /download/batch
Retrieve Registration Authority
Certificate
/retrieve-ra-certificate
Request Identity Certificate
Provisioning
/provision-identity-certificate
Download Identity Certificate /download/identity-certificate
Request Pseudonym Certificate Batch
Provisioning
/provision-pseudonym-certificate-batch
Download Application Certificate /download/application-certificate
Download Local Certificate Chain File /download/local-certificate-chain
Submit Misbehavior Report /process-misbehavior-report
59

Interfaces
Pseudonym certificate provisioning
60

Certificate Provisioning
LAs are only used for
pseudonym cert
provisioning, not for
identified or
application certs
61

Pseudonym cert request flow
• (Optional but recommended) OBE downloads
the Local Policy File (LPF) and the Local Certificate
Chain File (LCCF)
• OBE applies all changes to its trust-store (necessary for
PCA Certificate Validations) if there is an updated LCCF
• OBE applies those changes if there is an updated LPF
• OBE creates the request, signs it with the
enrollment certificate, encrypts the signed request
to the RA and sends it to the LOP
• The LOP strips any information that could be used
to determine the OBE’s location and forwards it to
the RA
• In practice, this simply means that it replaces the OBE’s
IP address with its own – standard proxy behavior
• When RA receives certs back from the PCA it stores
them until they’re downloaded
• Download also happens through the LOP
62
LOP

Pseudonym certificate provisioning overview
• Pseudonym certificates are provisioned using the butterfly key process
• The request contains a “caterpillar key”, which is an ECC point, and “butterfly parameters” which allow a
series of public keys to be generated from that caterpillar key by an “expansion function”
• These new public keys are called cocoon keys
• The requesting device can run the expansion function to obtain the private keys corresponding to the public cocoon keys;
no-one else can obtain these private keys unless they know the caterpillar private key and the butterfly parameters
• Anyone who does not know the butterfly parameters cannot tell whether two cocoon keys were derived from the same
caterpillar key
• The RA expands the caterpillar keys to the cocoon keys; the CA does not know which cocoon keys go together
• When the CA issues the certificates, it too modifies the public key
• This means the RA, which saw the cocoon keys, does not know which of the final keys correspond to the cocoon keys and
cannot tell which certificates belong to which end-entities
• The CA sends the device information to allow it to perform an update to the private key that corresponds to the update the
CA performed on the public key
• This means the SCMS can pre-generate pseudonym certificates and store them at the RA for immediate
download when the device connects
• Significantly reduces quality of service requirements on the PCA
63

A
a
Device
Butterfly keys
• Use fundamental ECC property: ECC: (a+b)G = aG + bG
• Device generates
• A seed or “caterpillar” keypair
• An expansion function
• Cost: ~1 key generation
• RA runs the expansion function to generate “cocoon” public
keys from the caterpillar public key
• Cocoon public keys from the same caterpillar keys are not
correlated
• Expansion function lets you generate arbitrarily many cocoon
keys
• RA submits cocoon keys to CA for certification
• CA randomizes each public key separately so the RA can’t
recognize them
• Certs contain the resulting “butterfly” keys
• CA returns certs and private randomization values to the OBE
• Private key = a + f(i,j) + c
• Public key = A + f(I,j) G + C
64

B3B2
Bn
B1
Expansion
A
a Exp.
bn
b1
Device
RA
Butterfly keys: concept
correlated
keys
recognize them
• Public key = A + f(I,j) G + C
65

Butterfly keys: concept
correlated
keys
recognize them
• Public key = A + f(i,j) G + C
66

Butterfly keys with implicit certificates
• CA has private/public key (u, U = uG)
• Instead of adding c*G to the public key in the request, CA:
• Generates random integer c
• Calculates C = cG
• Calculates “Reconstruction Value” R = [A + f(i,j) G] + C
• Issues Cert as [Cert contents, R]
• Now, the public key associated with the cert is: H(Cert) * R +
U
• H(Cert) as defined in 1609.2, includes hash of issuing CA cert
• Anyone who knows cert and U can derive this
• R is derived from [A + f(i,j) G] but totally hides it, so RA can’t
associate the cert request with the cert
• Private key is H(Cert)*r + u
• = H*(a + f(i,j) + c) + u
• So if CA provides the cert and H*c + u to the device:
• Device can calculate H*(a + f(i,j) locally and so recover private
key
• No-one else knows a, so no-one knows private key
• The value H*c completely hides u, i.e. no information is leaked
to the device about the CA’s private key
67

Privacy in certificate request / download
Against RA
• LOP hides geographic location
• PCA adds its contribution to cert to
disguise original (A + fG) from RA
• PCA encrypts certificate for the
requesting end-entity so RA can’t read it
• PCA signs encrypted certificate to provide
guarantee that it encrypted that
certificate with the encryption key from
the end-entity
• Prevents the RA from submitting its own
encryption key to PCA, decrypting cert, and
re-encrypting with the device’s encryption
key
Against PCA
• Butterfly expansion prevents PCA
using cryptographic contents of
request to learn which requests come
from same device
• RA shuffle prevents PCA using timing
to learn which certificates come from
same device
• PCA doesn’t see enrolment certificate
• Every certificate comes with a
different response encryption key,
PCA can’t link them
68

(Shuffle at the RA)
• RA receives requests from multiple
end-entity devices
• Combines requests so that PCA
doesn’t know that two individual
cert requests received at the same
time come from the same vehicle
• Tracks responses so they can be
sent to the right device
• (All this is transparent to the end-
entity – doesn’t affect interfaces)
69

Privacy in certificate request / download
Against RA
• LOP hides geographic location
• PCA adds its contribution to cert to
disguise original (A + fG) from RA
• PCA encrypts certificate for the
requesting end-entity so RA can’t read it
• PCA signs encrypted certificate to provide
guarantee that it encrypted that
certificate with the encryption key from
the end-entity
• Prevents the RA from submitting its own
encryption key to PCA, decrypting cert, and
re-encrypting with the device’s encryption
key
Against PCA
• Butterfly expansion prevents PCA
using cryptographic contents of
request to learn which requests come
from same device
• RA shuffle prevents PCA using timing
to learn which certificates come from
same device
• PCA doesn’t see enrolment certificate
• Every certificate comes with a
different response encryption key,
PCA can’t link them
70

Encrypting
responses
71
• Device provides
butterfly
parameters for
two keys, signing
and encryption
• RA expands both
to give unique
keys for both
signing and
response
encryption
• PCA uses
expanded
response
encryption key to
encrypt response
• PCA signs
encrypted
response to
prevent RA from
substituting its
own response
encryption key
Asig
ksig
Asig
ksig i, j
f Bsig(i, j)
Aenc
kenc
Aenc
kenc i, j
Benc(i, j)f
asig
aenc
Bsig(i, j)
Benc(i, j)
C
Cert [R]+
c (s, Cert)
encrypt
u
EncCert
sign
SigEncCertSigEncCertSigEncCert
End Entity RA PCA
i, j
U
verify
i, jf
valid?
benc(i, j)
EncCert decrypt
(s, Cert)

Pseudonym certificate request: PDUs
• Contents:
• Butterfly params for signing
• Butterfly params for encrypting individual responses
• Start time
• Not contents: PSIDs or geographic region – those
are identical to the ones in the enrollment certs
• PDU is signed with the enrollment cert
• No proof of possession or proof of hardware generation
• Signed PDU is encrypted with the RA public key
from the RA cert provided in the LCCF
• Device is supposed to download the LCCF immediately
before the request
• If it doesn’t, it uses the RA public key provided at
enrollment
• Pseudonym request happens basically immediately
after enrollment, so this key will still be in use at the RA
72

Pseudonym certificate request: transfer
• Request sent using POST as
described earlier
• ACK contains
• Download URL
• Time when the certs will be ready
for download – no point in the
device attempting to download
before that
PATH /provision-pseudonym-certificate-batch
HTTP Method POST
HTTP Request
Body
ASN1
serialized SecuredPseudonymCertProvisioningRequ
est PDU Message
HTTP Response
Body
SecuredPseudonymCertProvisioningAck with
a requestHash property containing the lower 8
bytes of the request hash. This value will identify
this device from this point on, and it is to be used
in subsequent download calls. The reply property
contains a PseudonymCertProvisioningAck with
a certDLTime property containing the expected
time of the requested batch, and
a certDLURL property containing the URL where
the batch can be downloaded from.
73

Pseudonym certificate download: transfer
• Download managed via GET as
defined earlier
PATH /download/batch
HTTP Method GET
HTTP Req. Body Empty
HTTP Request
Headers
HTTP Header 'Download-Req' containing a Base64 encoded
ASN1 serialized EndEntityRaInterfacePDU containing
an AuthenticatedDownloadRequest with filename property
of the form [0-9A-F]{16}_[0-9A-F]{1,8}.zip
where:
First group of 16 hexadecimal digits is the device's Request
Hash obtained from the initial Provision Pseudonym
Certificate Batch request, and the second group of up to 8
hexadecimal digits is the i-value. Example:
AB09281C9867DE53_F.zip corresponds to i value 15, for
device with request hash AB09281C9867DE53.
Range (optional) as defined in RFC 2616:
To support partial downloads for resuming interrupted
transfers. Examples:
1.From byte offset 500 to 700: Range : bytes=500-700
2.Starting from byte offset 1000 to the end: Range :
bytes=1000-
HTTP Response
Body
If no Range header is present, the entire zip file
corresponding to the requested batch. If a Range header is
present, the specified bytes of the referenced file.
74

Ongoing pseudonym certificate operations
• SCMS generates, OBE downloads
• No re-enrollment
• No change of butterfly key params
75

Pseudonym Certificate Provisioning – full
process
76

Next steps
• Final output of CAMP SCMS v1 project will be provided to USDOT by
end October
• Will be reviewed by DOT and published
• Please review after that!
• An additional project is expected to start in CAMP shortly
• A number of outstanding issues on SCMS interface
• Minor revisions to interface expected
• Feedback based on published interfaces will be possible and welcome
• Early in the next project the end-entity interfaces should be stabilized
based on internal review and external feedback
• At that point standardization should proceed
77
View publication statsView publication stats

Certificate Management Protocols for 1609.2 Certificates

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Certificate Management Protocols for 1609.2 Certificates

Similar to Certificate Management Protocols for 1609.2 Certificates (20)

More from OnBoard Security, Inc. - a Qualcomm Company

More from OnBoard Security, Inc. - a Qualcomm Company (13)

Recently uploaded

Recently uploaded (20)

Certificate Management Protocols for 1609.2 Certificates