Conference PaperPDF Available

A security credential management system for V2V communications

  • Security Innovation, Inc.

Abstract and Figures

We present a security credential management system for vehicle-to-vehicle communications, which has been developed under a Cooperative Agreement with the US Department of Transportation. This system is currently being finalized, and it is the leading candidate design for the V2V security backend design in the US, subject to review by the US Department of Transportation and other stakeholders. It issues digital certificates to participating vehicles for establishing trust among them, which is necessary for safety applications based on vehicle-to-vehicle communications. It supports four main use cases, namely, bootstrapping, certificate provisioning, misbehavior reporting and revocation. The main design goal is to provide both security and privacy to the largest extent reasonable and possible. To achieve the latter, vehicles are issued pseudonym certificates, and the provisioning of those certificates is divided among multiple organizations. One of the main challenges is to facilitate efficient revocation while providing privacy against attacks from insiders.
Content may be subject to copyright.
A Security Credential Management System for V2V Communications
William Whyte, Andr´
e Weimerskirch, Virendra Kumar, Thorsten Hehn
{wwhyte, vkumar}
Abstract—We present a security credential management system
for vehicle-to-vehicle communications, which has been developed
under a Cooperative Agreement with the US Department of
Transportation. This system is currently being finalized, and it
is the leading candidate design for the V2V security backend
design in the US, subject to review by the US Department of
Transportation and other stakeholders. It issues digital certifi-
cates to participating vehicles for establishing trust among them,
which is necessary for safety applications based on vehicle-to-
vehicle communications. It supports four main use cases, namely,
bootstrapping, certificate provisioning, misbehavior reporting
and revocation. The main design goal is to provide both security
and privacy to the largest extent reasonable and possible. To
achieve the latter, vehicles are issued pseudonym certificates, and
the provisioning of those certificates is divided among multiple
organizations. One of the main challenges is to facilitate efficient
revocation while providing privacy against attacks from insiders.
Vehicle-to-Vehicle (V2V) communications among nearby
vehicles in the form of continuous broadcast of Basic Safety
Messages (BSMs) has the potential to prevent up to 75% of
all roadway crashes through active safety applications [1]. Fol-
lowing a series of field operational tests, the US Department
of Transportation (USDOT) is expected to announce in 2013
whether it plans to seek a mandate for V2V communications
equipment, to be included in all new build vehicles after a
particular date.
The correctness and reliability of BSMs, which contain
information like sender’s position, speed, etc., are of prime im-
portance as they directly affect the outcome and effectiveness
of safety applications based on them. To prevent an attacker
from inserting false messages, most studies recommend that
the sending vehicles digitally sign each BSM, and the receiv-
ing vehicles verify the signature before acting on it [2], [3],
[4], [5], [6], [7], [8].
A Public-Key Infrastructure (PKI) that facilitates and man-
ages digital certificates is necessary for building trust among
participants and for proper functioning of the system. Our
Security Credential Management System (SCMS) implements
a PKI with some additional new features. This SCMS is
currently the leading candidate design for the V2V security
backend design in the US, subject to review by the USDOT
and other stakeholders. It is distinguished from a traditional
PKI in several aspects, the two most important ones being
its size (i.e., the number of vehicles that it supports) and
the balance among security, privacy, and efficiency. At its
full capacity, assuming 300 million vehicles, it will issue
approximately 300 billion certificates per year1. The largest
current PKI, deployed by the US Department of Defense,
is several orders of magnitude smaller and issues under 10
million certificates per year. At the core of its design, the
proposed SCMS has several novel cryptographic constructs
to provide a high level of security and privacy to the users
while keeping the system very efficient. As a result, the
presented SCMS design is significantly different from any
previously implemented PKI due to the underlying security
objectives and size, however, it is somewhat similar to the
design of the European V2X PKI [2]. The main differences
to [2] include an increased focus on privacy against attacks
from SCMS insiders, efficient handling of revocation, and an
efficient method for updating certificates based on the butterfly
key expansion algorithm. An early version of the proposed
SCMS has already been implemented, operated and tested [9].
In this section, we present the design of the proposed SCMS
by briefly explaining its components and then discussing the
rationale behind the design. We say that an SCMS component
is intrinsically-central, if it can have exactly one distinct
instance for proper functioning. A component is central, if it
chosen to have exactly one distinct instance in the considered
instantiation of the system. Distinct instances of a component
have different identifiers and do not share cryptographic mate-
rials. Central components do support load balancing. Figure 1
gives an overview of the overall system architecture. The
lines connecting different SCMS components in that figure
are relationship lines, meaning that one component sends
information or certificates to the other. Additionally, there is
a bold line connecting a device to the SCMS, to indicate out-
of-band secure communication. The conceptual model of the
SCMS is the most flexible and full-featured system. It can be
simplified at the expense of losing some flexibility, e.g. making
all the components central. We considered two deployment
models for initial and full deployment stages, respectively. Due
to space limitations, we focus only on the full deployment
model here.
A. Threat Models and Application Concepts
Besides its standard functionality as a PKI system, the
SCMS is designed to handle the following types of attacks.
Attacks on end-users’ privacy from SCMS outsiders
1This number may be even greater if pedestrian and cyclist-borne units
become part of the system.
Attacks on end-users’ privacy from SCMS insiders
Authenticated messages leading to false warnings
We address the first two items by “Privacy by Design”. The
third item is addressed by revocation, which uses misbehavior
detection and reporting scheme to identify devices to revoke.
1) Privacy by Design: A key goal of the system is to
protect the privacy of end-users. Since most vehicles are
primarily operated by a single user, the system should be
designed to make tracking hard, i.e. it should difficult for two
eavesdroppers in physically distant locations to tell whether
two transmissions came from the same vehicle. To maintain
privacy against attackers from outside the SCMS, we propose
frequent certificate changes (e.g. every 5 minutes). Another
key requirement is that these attacks should be difficult to
mount for SCMS insiders. In order to do so, the SCMS
operations are divided among its different components, and
those components are required to have organizational sepa-
ration between them. At a high level, the SCMS operations
are divided such that at least two SCMS components need to
collude to gain enough information for tracking a device. A
device sending BSMs may potentially be tracked in other ways
that are not addressed by the SCMS: by its RF fingerprint [10],
by deploying a large-scale sniffer network, etc.
2) Misbehavior Detection & Revocation: The SCMS sup-
ports revocation by distributing a Certificate Revocation List
(CRL), which are used to reject certificates from a misbehav-
ing device. In addition, the SCMS maintains a blacklist, which
is internal to the SCMS, to deny future certificate requests
by revoked devices. Misbehavior detection is used to identify
devices that need to be revoked. The novel concept of linkage
values (cf. Section IV-B) allows for efficient revocation.
B. Full SCMS Structure
Below we briefly describe the SCMS components2as shown
in Figure 1. The figure shows different components within
the system by their logical roles. An implementation of the
system may combine multiple logical roles within a single
organization with proper separation of the logical roles.
SCMS Manager: Ensures efficient and fair operation of
the SCMS, sets guidelines for reviewing misbehavior
and revocation requests to ensure that they are correct
according to procedures.
Certification Services: Provides information on which
types of devices are certified to receive digital certificates
and specifies the certification process.
CRL Store (CRLS): Stores and distributes CRLs. This is
a simple pass-through function since CRLs are signed by
the CRL Generator.
CRL Broadcast (CRLB): Broadcasts the current CRL,
may be done through Road Side Equipment (RSEs) or
satellite radio system, etc. This is a pass-through function.
Device: An end-entity device that sends BSMs, for exam-
ple On-Board Equipment (OBE) or After-market Safety
Device (ASD).
2For space considerations, we skip the standard components of a PKI, such
as Root CA, Intermediate CA, etc.
Device Configuration Manager (DCM): Provides authen-
ticated information about SCMS component configura-
tion changes to devices, which may include a component
changing its network address or certificate, or relaying
policy decisions issued by the SCMS Manager. It is also
used to attest to the Enrollment CA that a device is
eligible to receive enrollment certificates.
Enrollment CA (ECA): Issues enrollment certificates,
which act as a passport for the device and can be
used to request pseudonym certificates. Different ECAs
may issue enrollment certificates for different geographic
regions, manufacturers, or device types.
Linkage Authority (LA): Generates linkage values, which
are used in the certificates and support efficient revoca-
tion. There are two LAs in the SCMS, referred to as LA1
and LA2. The splitting prevents the operator of an LA
from linking certificates belonging to a particular device.
Location Obscurer Proxy (LOP): Hides the location of
the requesting device by changing source addresses, and
thus prevents linking of network addresses to locations.
Additionally, when forwarding information to the Misbe-
havior Authority (MA), the LOP shuffles the reports to
prevent the MA from determining the reporters’ routes.
Misbehavior Authority (MA): Processes misbehavior re-
ports to identify potential misbehavior by devices, and if
necessary revokes and adds devices to the CRL. It also
initiates the process of linking a certificate identifier to
the corresponding enrollment certificates, and adding the
enrollment certificate to an internal blacklist. The MA
contains three subcomponents: Internal Blacklist Man-
ager (IBLM), which sends information required for up-
dating the internal blacklist to the RA; Global Detection
(GD), which determines which devices are misbehaving;
and CRL Generator (CRLG), which issues certificate
revocation lists to the outside world.
Pseudonym CA (PCA): Issues short-term (pseudonym)
certificates to devices. Individual PCAs may, for example,
be limited to a particular geographic region, a particular
manufacturer, or a type of devices.
Registration Authority (RA): Validates, processes, and
forwards requests for pseudonym certificates to PCA.
Request Coordination (RC): Ensures that a device does
not request more than one set of certificates for a given
time period. It coordinates activities between different
RAs, and is only needed if a device could request
certificates from multiple RAs.
C. Pseudonym Certificate Provisioning Model
We need a pseudonym certificate provisioning model that
provides an appropriate balance among several conflicting
Privacy vs. Size vs. Connectivity: Certificates should be
used only for short periods of time for privacy, but the
devices can neither store a large number of certificates,
nor do they have frequent connectivity to the SCMS to
download certificates on demand.
SCMS Manager
Regular communication
Out of band communication
Fig. 1. Overall System Architecture
CRL Size vs. Retrospective Unlinkability: The SCMS
should be able to revoke misbehaving devices3, but
putting all valid certificates of a device on the CRL would
make it very large. We need a mechanism to revoke a
large number of certificates efficiently, but this must not
reveal certificates that were used by a device before it
started misbehaving.
Certificate Waste vs. Sybil Attack: Certificates must be
changed periodically for privacy. One option is to have
a large number of certificates, each valid one after the
other for a short period of time. This would result in
a large number of unused certificates4. Another option
is to have multiple certificates valid simultaneously for
longer time periods. This would enable masquerading as
multiple devices by compromising a single device (the
so-called Sybil attack [11]).
In the Safety Pilot [9] model, a certificate was valid for
a specific 5-minute period, and the devices were given 3
years’ worth of certificates, amounting to more than 300,000
certificates. This approach is prohibitively expensive in terms
of automotive-grade storage requirements on the device. We
3CRLs can be avoided, if devices were required to request new certificates
frequently such that misbehaving devices could be refused new certificates.
This would require frequent connectivity to the SCMS, which may not be a
reasonable assumption.
4Based on the US Census Bureau’s annual American Community Survey
for 2011, the average daily commute time is less than 1 hour, so more than
95% of certificates would be wasted.
studied different variants of this model, but none of them offer
a good balance among all the properties listed above. Instead,
we decided to adopt the model used by CAR 2 CAR Commu-
nication Consortium (C2C-CC) [2], with certain modifications
to suit our requirements.
In the C2C-CC model, multiple certificates are valid in a
given time period, the certificate validity period is days rather
than minutes, and the certificate usage pattern can vary from
device to device, e.g. a device could use a certificate for
5minutes after start-up, then switch to another certificate,
and use that either for 5minutes, or until the end of the
journey. This model offers enough flexibility to find a good
balance among our different requirements except “CRL size
vs. retrospective unlinkability”, which we address by our novel
construct of linkage values (cf. Section IV-B). In particular,
our proposal is to use the C2C-CC model with the following
parameter values:
Certificate validity time period: 1week
Certificates valid simultaneously (batch size): 20 40
Overall covered time-span (super-batch size): 13years
These parameters can be further fixed by the SCMS Man-
ager so that devices are compatible with each other. Two points
are worth noting:
1) This model provides a reasonable level of privacy against
tracking while keeping the storage requirements low
due to a high utilization of certificates (e.g., far fewer
certificates are wasted compared to the Safety Pilot
Model Deployment). A device that uses fewer than the
number of certificates granted for a week cannot be
linked. Moreover, if a device re-uses certificates, it is
linkable only within a week. Privacy-conscious users
could potentially buy additional certificates so long as
their device had the storage space and demonstrated that
it had appropriate physical security against compromise.
2) It allows for an easy topping-off mechanism (without
losing any other benefits) of certificates at a granularity
level of certificate validity period within the life cycle
of a super-batch. For example, if a device comes to the
dealer one year after the last certificate loading, it is
easy to delete the outdated certificates, freeing up space
to provide it with another year’s worth of certificates.
Butterfly keys are a novel cryptographic construction that
allow a device to request an arbitrary number of certificates,
each with different signing keys and each encrypted with a
different encryption key, using a request that contains only
one verification public key seed, one encryption public key
seed, and two expansion functions. Without butterfly keys,
the device would have to send a signing key and a unique
encryption key for each certificate. Butterfly keys reduce
upload size, allowing requests to be made when there is only
suboptimal connectivity, and also reduce the work to be done
by the requester to calculate the keys. Butterfly key expansion
is described below for elliptic curve cryptography, but it
could easily be adapted to any discrete log-based problem.
In the following, we denote integers by lower-case characters
and curve points by upper-case characters. The elliptic curve
discrete logarithm problem is basically the statement: Given
Pand A=aP , but not a, it is hard to compute the value of
Butterfly keys make use of this as follows. There is an
agreed base point, called G, of some order l. The caterpillar
keypair is an integer, a, and a point A=aG. The certificate
requester provides the RA with Aand with an expansion
function, fk(ι), which is a pseudo-random permutation in
the integers mod l. For example, for points on the NIST
curve NISTp256 [13], fk(ι)could be defined as AESk(0128
ι)||AESk(1128 ι), where AES is the Advanced Encryption
Standard block-cipher, ι < 2128, and xy,x∈ {0,1}, refers
to an array of values xof length y; this means the expansion
function is defined by k. Now RA can generate up to 2128
cocoon public keys as Bι=A+ fk(ι)G, where the
corresponding private keys will be bι=a+fk(ι), so the public
keys are known to the RA but the private keys are known only
to the device. The RA includes the cocoon public keys in the
certificate requests sent to the PCA.
If these expanded public keys were used unaltered by the
PCA, the RA, which knows which public keys come from
a single request, could recognize those public keys in the
certificates and track the holder. To avoid this, for each input
public key Bi, the PCA generates a random cand obtains
C=cG. The butterfly public key which is included in the
certificate is Bι+C. The PCA returns both the certificate and
the private key reconstruction value cto the RA to be returned
to the device5. To prevent the RA from working out which
certificate corresponds to a given public key in a request, the
certificate and the reconstruction value cmust be encrypted. To
prevent the PCA from knowing which certificates go to which
vehicle, each certificate must be encrypted with a different
key. The encryption keys are also generated with the butterfly
key approach: the device provides a caterpillar public key
H=hG, the RA expands it into cocoon public encryption
keys H+Jι=H+fe(ι)G, and the PCA uses these keys to
encrypt the response.
The SCMS supports four main use cases: device bootstrap,
pseudonym certificate provisioning, misbehavior reporting,
and global misbehavior detection & revocation.
A. Device Bootstrap
Bootstrap is executed at the start of the life cycle of a
device. It equips the device with all the information required
to communicate with the SCMS and with devices. Bootstrap
must provide correct information, and the CAs must issue
certificates only to certified devices. Any bootstrap process
is acceptable that results in this information being established
securely. We anticipate that the DCM will establish a secure
channel with the SCMS, and will communicate with the device
to be bootstrapped in a secure environment. Bootstrap consists
of two logical operations, initialization and enrollment. Initial-
ization is the process by which the device obtains certificates
it needs to trust received messages. Enrollment is the process
by which the device obtains certificates it will need to send
messages. Information received in the initialization process
includes (1) the certificate of all root CAs and possibly of
intermediate CAs as well as PCAs, (2) the certificate of
the misbehavior authority and the CRL generator to report
misbehavior and learn about revocation, and (3) the certificate
of the DCM. In the enrollment process, information required
to actively participate includes (1) the enrollment certificate,
(2) the certificate of the ECA, and (3) the certificate of the
RA and information necessary to locate the RA. During the
enrollment process, the certification services provide the ECA
with information about device models which are eligible for
enrollment. This requires that the ECA receives trustworthy
information about the type of the device to be enrolled, from
the device itself or from the DCM.
B. Pseudonym Certificate Provisioning
The pseudonym certificate provisioning process is illustrated
in Figure 2, and is designed to protect privacy from inside
attackers. The SCMS is designed to ensure that no single
component knows or creates a complete set of information
5This description covers explicit certificates, i.e. certificates that include
the public key explicitly. In fact, the SCMS as currently implemented issues
implicit certificates [14]. The implicit certificate generation process inherently
changes the public key in a way that leaves input and output uncorrelatable
by the RA and is consistent with the motivation for butterfly keys.
1. Pseudonym certificate request signed
with enrollment certificate
2. Validate request, perform butterfly
key expansion, collect enough
requests and shuffle them
At any time: pre compute
pre linkage values
3. Send butterfly key pair,
pre linkage values
from both LAs, and (i,j),
hash of RA to PCA
4. Generate pseudonym certificates,
encrypt it for the devie, and then sign it
5. Bundle pseudonym certificates
for a device and send it
Store linkage seeds and
all pre linkage values Store pre linkage values, (i, j), linkage value,
Certificate, and hash of RA to PCA cert request
Store device’s enrollment
certificate and hash of RA
to PCA certificate request
Only needed if external CRLs are implemented
Symmetric crypto
Asymmetric crypto
Fig. 2. Certificate Provisioning
that would enable tracking of a vehicle. For example, the
RA knows the enrollment certificate of a device that re-
quests pseudonym certificates, but even though the pseudonym
certificates are delivered to the device by the RA, it never
gets to see the content of those certificates; the PCA creates
each individual pseudonym certificate, but it doesn’t know
the recipient of those certificates, nor does it know which
certificates went to the same device. Privacy mechanisms in
the SCMS include:
Obscuring Physical Location. The LOP obscures the
physical location of an end-entity device to hide it from
the RA and the MA.
Hiding Certificates from RA. The butterfly key expan-
sion process ensures that the public keys in requests
cannot be correlated with the public keys in the resulting
certificates. More details are given in Section III.
Hiding Batch from PCA. The RA splits incoming
requests of devices into requests for single certificates,
and shuffles requests of all devices before sending them
to the PCA. This prevents the PCA from figuring out if
two different certificates went to the same device, which
would violate our privacy goal by enabling the PCA to
link certificates. The RA may, for example, aggregate and
shuffle all requests received in a six month period.
Linkage Values. For any set of pseudonym certificates
provided to a device, the SCMS inserts linkage values
that can be used to revoke all of the certificates with
validity equal to or later than some time i. These linkage
values are computed by XORing the pre-linkage values
generated by the Linkage Authorities LA1and LA2, and
can be generated in advance of the request for a set of
pseudonym certificates. Let la id1,la id2be 32-bit iden-
tity strings associated with LA1, LA2, respectively. For a
set of certificates, first the LA1(resp., the LA2) picks a
random 128-bit string called the initial linkage seed ls1(0)
(resp., ls2(0)), then for each time period (e.g., a week) i >
0calculates the linkage seed ls1(i) = H(la id1ls1(i
1)) (resp., ls2(i) = H(la id2ls2(i1))). In this coher-
ence, H(m)denotes the 16 most significant bytes of the
SHA-256 hash output on m, and for bit-strings xand y,
xydenotes their bit-wise concatenation. Furthermore,
we will use E(k, m)to denote the 8 most significant
bytes of AES-128 block-cipher operation on message
mwith key k. For each value j > 0(which specifies
the number of overlapping certificates in a given time
period, e.g., 20), the LA1(resp., the LA2) calculates the
pre-linkage value plv1(i, j) = E(ls1(i),la id1j)(resp.,
plv2(i, j) = E(ls2(i),la id2j)). Pre-linkage values are
encrypted (individually) for the PCA but sent to the RA
for association with a certificate request.
Hiding Linkage Information. The PCA computes the
linkage value to be included in a certificate by XOR-
ing together the two pre-linkage values from the LAs,
which are generated independently by the two LAs and
encrypted for the PCA to prevent the RA from colluding
with one of the LAs and mapping pre-linkage values to
linkage values. Therefore, no single component is able to
link pseudonym certificates of a single device.
Below we present a detailed step-by-step description of the
pseudonym certificate provisioning process.
Step 1. When LOP receives a request (signed with
the device’s enrollment certificate, containing a public
Butterfly Key seed, and encrypted to the RA) from a
device for a specified time period, it obscures the device’s
identifiers (e.g., IP address), and forwards it to the RA.
Step 2. The RA first decrypts the request, and checks if
the signature and the device’s enrollment certificate are
valid and that the latter is not revoked, and then also
checks (with the help of RC, if necessary) if this is the
only request by the device for that particular time period.
If all checks succeed, the RA sends an acknowledgement
to the device, and performs the butterfly key expansion as
explained in Section III. Otherwise, the request is denied.
The RA collects several such requests from different
devices along with the sets of pre-linkage values received
from the LAs. Once enough such requests are available,
the RA shuffles them. Note that in follow-up requests by
a device, the RA might request pre-linkage values from
each of the LAs for a particular initial linkage seed that
is associated with that device.
Step 3. The RA sends requests for pseudonym cer-
tificates to the PCA, for one certificate per request,
where each request consists of a butterfly key-pair,
an encrypted pre-linkage value from each of the LAs
(plv1(i, j),plv2(i, j)), the certificate validity time period
iand index j, and the hash of the request.
Step 4. The PCA completes the butterfly key expansion
hiding the certificate’s public key from the RA. It then
generates a pseudonym certificate with linkage value
lv(i, j) = plv1(i, j)plv2(i, j ), encrypts the private key
reconstruction value and the certificate for the device,
signs the encrypted packet, and sends it to the RA6.
Step 5. The RA collects and bundles the encrypted
pseudonym certificates and the corresponding private key
reconstruction values for a given device and delivers it via
LOP to the device. These bundles are called super-batch.
For revocation purposes, the SCMS components involved
in the pseudonym certificate provisioning store different in-
formation corresponding to a given pseudonym certificate as
listed in Table I.
6Signing the encrypted packet provides a guarantee to the device that the
PCA encrypted the packet with the device’s public key. This prevents a man-
in-the-middle attack where an insider at the RA substitutes their public key
for the valid response encryption key, which is also known to the RA.
Component Information Stored
LA Initial linkage seed, pre-linkage value
Pre-linkage values from both LAs and their correspond-
ing (i, j)values, linkage value, certificate, and hash of
RA-to-PCA pseudonym certificate request
RA Enrollment certificate and its validity period, hash value
of RA-to-PCA pseudonym certificate request
C. Misbehavior Reporting
Devices will send misbehavior reports to the MA via the
LOP, which will, additionally to obscuring the source, shuffle
the reports from multiple reporters to prevent the MA from
reconstructing the reporter’s path based on the reports. The
format of a misbehavior report is not fully defined yet, but
a report will potentially include reported (suspicious and
alert-related) BSMs as well as the reporter’s signature and
certificate, and will be encrypted by the reporter for the
MA. Note: A device will also have misbehavior detection
algorithms which work on a local level.
D. Global Misbehavior Detection & Revocation
The algorithms of global misbehavior detection have not
been developed yet, but the interface to the other components,
which allows for obtaining linkage information, is already
specified. Linkage information is required at the MA to find
whether multiple misbehavior reports point to the same device.
The following actions are required from the components:
1) The PCA and both the LAs have to collaborate to
determine external revocation information for the CRL.
2) The PCA and the RA have to collaborate to determine
the enrollment certificate of the misbehaving device for
the internal blacklist.
Below we present a detailed step-by-step description of the
process of identifying the linkage seeds and the enrollment
certificate corresponding to a pseudonym certificate as illus-
trated in Figure 3. Some of the communications in the steps
below need to be digitally signed.
Step 1. The MA receives misbehavior reports, including
a reported pseudonym certificate with linkage value lv =
Step 2. The MA runs global detection algorithms to
determine which reported pseudonym certificates are of
interest, i.e. whose linkage seeds and the corresponding
enrollment certificates need to be determined.
Step 3. The MA makes a request (signed) to the PCA
to map the linkage value of the identified pseudonym
certificate, lv, to the corresponding pre-linkage val-
ues (plv1,plv2)and the hash value of the RA-to-
PCA pseudonym certificate request, all from the PCAs
database. The PCA returns these values to the MA.
Step 4.a. The IBLM sends the hash value of the RA-
to-PCA pseudonym certificate request (signed) to the RA
so that it can add the corresponding enrollment certificate
Look up (plv1, plv2), hash of
RA to PCA certificate request
Add the enrollment certificate to
internal blacklist
Look up ls1(i) Look up ls2(i)
1. Misbehavior reports, including a reported certificate
with time period i and linkage value lv = plv1 XOR plv2
2. Decision to analyze
behavior, or revoke a device
3. Map lv to (plv1,plv2) and hash
of RA to PCA certificate request
4.a Send hash of RA to PCA cert request
so that RA can add the corresponding
enrollment certificate to its
internal blacklist
4.c Map plv2 to linkage seed ls2(i)
4.b Map plv1 to linkage seed ls1(i)
5. Add the linkage seeds and
the time period i to the CRL
Only needed if external CRLs are implemented
Symmetric crypto
Asymmetric crypto
Fig. 3. Revocation
to the internal blacklist. The RA does not return a value,
i.e., does not give the enrollment certificate to anyone. If a
device is allowed to make pseudonym certificate requests
to multiple RAs, the RC needs to manage the internal
blacklist. For simplicity, the RC is not shown in Figure 3.
Steps 4.b., 4.c. The MA makes a request to the LA1
(resp., the LA2) to map plv1(resp., plv2) to the linkage
seed ls1(i)(resp., ls2(i)), where iis the currently valid
time period. Both the LAs return the linkage seed to
the MA. Note that given a linkage seed ls1(i), only the
forward linkage seeds (i.e., ls1(j)for ji) can be
calculated, and thus backward privacy of the revoked
device is maintained.
Step 5. The linkage seeds ls1(i)and ls2(i), and the time
period iare added to the CRL. When the next CRL is
due, the CRLG signs the CRL and publishes it.
The size of the CRL grows linearly with the number of
entries. We think that the size of the CRL needs to be upper-
bounded, and that the entries need to be ordered in terms
of priority. Note that currently there is no way to undo a
revocation, and a revoked device can be reinstated only by
repeating the process of bootstrapping, cf. Section IV-A.
Different SCMS components represent different logical
functions. For privacy, some distinct logical functions must
be provided by distinct organizations. This section identifies
which SCMS components must be organizationally separate.
The general rule is that two components cannot be run by the
same organization if the combined information held by the
components would allow an insider to track a vehicle.
PCA and RA: If these two components were run by
one organization, the organization would know which
pseudonym certificates had been issued to which device.
This is because the RA knows the requests to which
certificates correspond, and the PCA knows the corre-
sponding pseudonym certificates.
PCA and one of the LAs: If an organization ran the
PCA and either (or, both) of the LAs, it could link all
pseudonym certificates (from a super-batch) issued to any
device since LA knows a set of pre-linkage values that
go into the certificate set, and PCA sees these pre-linkage
values at certificate generation time.
LA1and LA2:If an organization ran both the LAs, it
would know all the pre-linkage values and XOR them
opportunistically to obtain the linkage values, which
appear in plaintext in the certificates.
LOP and (RA or MA): The LOP is supposed to hide
the location from the RA and the MA, respectively, and
may not be combined with any of these components.
SCMS Manager: This component issues policies and
rules defining the behavior of all the components of the
SCMS. It is advisable to run it completely independently.
MA and (RA, LA, or PCA): The MA should not be
combined with any of the RA, the LA or the PCA. If
combined, the MA could circumvent protocols which
have to be in place for the MA to request information
on the linkage of a set of certificates.
Root CA: The root CA should be run separately and by
a very trustworthy and well-monitored organization.
This section presents potential simplifications of the SCMS.
A. Remove Intermediate CA
This shortens the chain of trust and reduces the number of
CAs to be run at the cost of reducing flexibility and potentially
increasing the Root CAs vulnerability to attacks, as the root
CA will now be active and online for more time.
B. Remove RC
In order to remove the RC, the system may have only one
RA or one has to make sure that each device can access only
one RA. The main benefit of this simplification is that the
SCMS structure is simpler to implement. The restriction to
one RA makes it more difficult for a service provider to enter
the system running a new RA.
C. Remove LOP
Removing the LOP simplifies the implementation further
but also has a drawback. Both the RA and the MA can now
observe the IP address of the requesting device. For the MA,
the shuffling functionality of the LOP is also gone. There needs
to be processes and practices in place so that these authorities
do not abuse that knowledge.
D. Use Hardware Security Modules to Merge LAs
The SCMS is significantly simplified by merging the two
LAs into one. Two separate LAs prohibit the operators from
linking certificates. The proposed simplification relies on the
idea to use a Hardware Security Module (HSM) [15], which
limits the access of the operator to data on the device.
This simplifies the design and lessens the requirement for
computational power, and it has positive effects on the size of
the CRL and the computational power required at the device
for revocation purposes. Public perceptions of this approach
would need to be weighed alongside the technical and business
advantages of this simplification.
E. System Not Using CRLs
The last simplification is to abstain from CRLs. In this case,
revocation is handled only by means of the RAs internal black-
list. Not using CRLs allows for removing the LAs completely
and simplifying the MA by removing the CRLG as well as the
CRLS and the CRLB. The resulting system is attractive due
to its simplicity. However, in order for revocation by internal
blacklisting to be effective, the super-batch of pseudonym
certificates need to have a short validity period such that the
devices need to request certificates frequently. This, again,
requires the presence of frequent two-way communication.
We introduced a Security Credential Management System
for V2V communications that is currently the leading candi-
date design for the V2V security backend design in the US,
subject to review by USDOT and other stakeholders. One of
the main challenges is to find a right balance among security,
privacy, and efficiency for a possibly mandated system. The
proposed solution uses pseudonym certificates to sign mes-
sages and additionally, in the backend, separation of duties to
provide a good trade-off between security and privacy. Follow-
up studies include a cost and performance analysis, based on
which a refined system will be designed and specified. More
details on the SCMS can be found in [16].
The presented results are a culmination of efforts by many
parties and people. This includes members of the US Depart-
ment of Transportation (USDOT), the Crash Avoidance Met-
rics Partnership Vehicle Safety Consortium (CAMP VSC3),
and the Vehicle Infrastructure Integration Consortium (VIIC).
Funding was provided by the USDOT and OEMs participating
in CAMP VSC3. The OEMs Daimler, Ford, GM, Honda,
Hyundai-Kia, Nissan, Toyota, and VW-Audi participate in
CAMP VSC3 and the VIIC. BMW and Chrysler participate
in the VIIC. The authors are deeply grateful to Bill Anderson,
Stephen Farrell, Scott Vanstone, and members of the USDOT
and CAMP VSC3 for reviewing the manuscript and providing
important suggestions for improvements.
[1] U.S. Department of Transportation - Research and Innovative
Technology Administration. Vehicle-to-Vehicle (V2V) Communications
for Safety. [Online]. Available:
[2] N. Bißmeyer, H. St¨
ubing, E. Schoch, S. G¨
otz, J. P. Stolz, and B. Lonc, “A
generic public key infrastructure for securing Car-to-X communication,
in 18th World Congress on Intelligent Transport Systems, 2011.
[3] ETSI. TR 102 893V1.1.1 (2010-03) Intelligent Transport Systems (ITS);
Security; Threat, Vulnerabilty and Risk Analysis (TVRA).
[4] ——. TS 102 731V1.1.1 (2010-09) Intelligent Transport Systems (ITS);
Security; Security Services and Architecture.
[5] ——. TS 102 867 v1.1.1, Intelligent Transportation Systems (ITS);
Security; Stage 3 mapping for IEEE 1609.2.
[6] Secure Vehicle Communication. Security Architecture
and Mechanisms for V2V/V2I. [Online]. Available: Deliverable D2.1 v3.0.pdf
[7] Vehicle Safety Communications Consortium. Appendix H: Final Report
[8] 1609.2. Annex E.4.1: Why sign data instead of us-
ing a message authentication code? [Online]. Available:
[9] U.S. Department of Transportation. Safety Pilot Model Deployment.
[Online]. Available:
[10] V. Brik, S. Banerjee, M. Gruteser, and S. Oh, “Wireless device identifi-
cation with radiometric signatures,” in MOBICOM, 2008, pp. 116–127.
[11] J. R. Douceur, “The sybil attack,” in IPTPS, 2002, pp. 251–260.
[12] IEEE. (2000) Std 1363-2000, standard specifications for public-key cryp-
tography. [Online]. Available:
[13] National Institute of Standards and Technology. (1999, July) Recom-
mended elliptic curves for federal government use. [Online]. Available:
[14] SEC, Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV),
SEC Std. 4, 2011.
[15] Wikipedia. Hardware security module. [Online]. Available: security module
[16] Anonymous. Defensive publication. [Online]. Available: priorart-
... In IEEE based architectures, ITSSs use Basic Safety Messages (BSM) [13]. One example of the importance of these messages is where BSM has the potential to prevent up to 75% of all roadway crashes according to [14] [15]. Thus, the correctness and reliability of the exchanged messages have a direct impact on the efficiency and effectiveness of the proposed services and the applications used. ...
... However, the PC is used for the ITSS communications. In order to protect the privacy of road users, a regular change of pseudonyms is required, for example in the SCMS project [14], an ITSS uses more than 1000 PCs per year and this number can even reach 100000 according to [39]. In the SCOOP@F project an ITSS uses 520 PCs per year [40]. ...
Full-text available
In the context of current smart cities, Cooperative Intelligent Transportation Systems (C-ITS) represent one of the main use case scenarios that aim to improve peoples’ daily lives. Thus, during the last few years, numerous standards have been adopted to regulate such networks. Within a C-ITS, a large number of messages are exchanged continuously in order to ensure that the different applications operate efficiently. However, these networks can be the target of numerous attacks. The sybil attack is among the most dangerous ones. In a sybil attack, an attacker creates multiple identities and then disguises as several fake stations in order to interfere with the normal operations of the system or profit from provided services. We analyze recently proposed sybil detection approaches regarding their compliance with the current C-ITS standards as well as their evaluation methods. We provide several recommendations such as network and attack models as well as an urban and highway datasets that can be considered in future research in sybil attack detection.
... In the European approach, vehicles periodically reload unrevocable pseudonyms from an online authorization authority. In the American approach, vehicles come preloaded with three years' worth of revocable pseudonym certificates [WWKH13]. ...
... Recovering the long-term identity of rogue vehicles is commonly known as identity resolution. It has been established as an essential requirement to balance the privacy and accountability needs in vehicular communication systems [SMK09,WWKH13,PSFK15]. In the current C-ITS proposal, identity resolution is realized by keeping mappings between pseudonyms and long-term identities [WWKH13, Section IV.D]. ...
This manuscript proposes new cryptographic protocols that are respectful of users’ privacy and which have real-world applications. In a first part, the focus is on group signatures, a primitive which allows members of a user group to anonymously sign on behalf of the group, and on message confidentiality. To remove the trust on single authorities, group signatures are here defined in a setting with multiple authorities and support both threshold issuance and threshold opening. These group signatures are then used as authentication mechanism for vehicle-to-vehicle communication, and combined with zone encryption, a new primitive whereby vehicles can efficiently encrypt their communication, they provide strong, well-defined privacy guarantees for cooperative intelligent transport systems. Thereafter, public-key encryption is studied in a more general context in which users do not have access to secure storage to protect their secret keys, but can leverage passwords and interaction with servers to obtain comparable security guarantees without renouncing their privacy. In a second part, the topic of study are general-purpose cryptographic primitives which have privacy-preserving applications. First come zero-knowledge arguments, a type of cryptographic schemes which enable a computationally bounded prover to convince a verifier of a statement without disclosing any information beyond that. More specifically, we study arguments to prove the satisfiability of Diophantine equations which have logarithmic communication and round complexity, as well as their applications to privacy-preserving cryptography. Then, we tackle the problem of proving that a user algorithm selected and correctly used a truly random seed in the generation of her cryptographic key, a problem of fundamental importance to the security of any public-key cryptographic scheme.
... There is a compromise between the waste of certificates and the Sybil attack as explored by [5] since, on the side of the authority, we can not differentiate between the "honest" vehicles that only use the certificates excessively and the others that use the pool of pseudonyms to run Sybil Attacks. This contribution focuses on improving the privacy of V2X communications by proposing a dynamically adaptive system that allows certificate authorities to monitor the pseudonym-changing process. ...
... Standards provide detailed requirements on how a policy must be implemented. In VANET, many groups [5,8] have presented the credential security architecture. The privacy and linkability of pseudonyms are essential issues in V2X communications. ...
Full-text available
Vehicular ad hoc networks allow vehicles to share their information for the safety and efficiency of traffic purposes. However, information sharing can threaten the driver’s privacy as it includes spatiotemporal information, and the messages are unencrypted and broadcasted periodically. Therefore, they cannot estimate their privacy level because it also depends on their surroundings. This article proposes a centralized adaptive pseudonym change scheme that permits the certificate’s authority to adjust the pseudonyms assignment for each requesting vehicle. This scheme adapts dynamically depending on the density of the traffic environment and the user’s privacy level, and it aims to solve the trade-off problem between wasting pseudonyms and Sybil attack. We employ a Knapsack problem-based algorithm for target tracking and an entropy-based method to measure each vehicle’s privacy. In order to demonstrate the applicability of our framework, we use real-life data captured during the interoperability tests of the European project InterCor. According to the experimental results, the proposed scheme could easily estimate the level of confidentiality and, therefore, may best respond to the adaptation of the pseudonyms.
... However, using bilinear pairings or RSA has high computational cost and high bandwidth overhead. Whyte et al. proposed using the ECQV composite with signature (ECDSA), which is efficient and lightweight, in vehicle-to-vehicle (V2V) application scenarios [57]. However, this solution still has security risks in certain specific scenarios. ...
... As an improvement to stressful computing, renewal, and storage costs of certificate management in conventional public key cryptosystems, Al-Riyami-Paterson proposed a certificateless definition [57,64]. However, their scheme and most other subsequent research are based on bilinear pairing, the computing cost of which is nearly twenty times that of point multiplication in ECC. ...
Full-text available
Significant technological advancements in the Internet of Vehicles (IoV) incentivize the rapid development of various vehicular communication technologies for wireless connectivity among vehicles, roadside devices, and pedestrians. Despite the countless benefits, security issues have received considerable critical attention since breaches have been recurrent in vehicular communication networks and applications, which seriously affects the transportation environment. To resolve the security issues in vehicular communication, we introduce a novel signature scheme based on a standard elliptic curve cryptography (ECC) algorithm in this paper. Compared with existing schemes, the proposed scheme is lightweight and cost-saving in the vehicular environment and can efficiently authenticate and protect the exchange of messages between each entity in the IoV. The security of our scheme is based on the unsolved NP-complete problem: the elliptic curve discrete logarithm problem. Moreover, by using key prefixing, we demonstrate the merits of our scheme through security analysis in terms of avoiding key escrow and replacement attack resistance.
... In most cases, an attacker is a rogue vehicle participating in a CV application like platoon. It poses itself as a legitimate vehicle to the certificate authority (CA), like Security Credentials Management System (SCMS) [6], thus obtaining certificate to be a participant of a platoon. Then, it can misuse the underlying CA and launch various types of attacks that lead to collisions [7]. ...
Recent developments in the smart mobility domain have transformed automobiles into networked transportation agents helping realize new age, large-scale intelligent transportation systems (ITS). The motivation behind such networked transportation is to improve road safety as well as traffic efficiency. In this setup, vehicles can share information about their speed and/or acceleration values among themselves and infrastructures can share traffic signal data with them. This enables the connected vehicles (CVs) to stay informed about their surroundings while moving. However, the inter-vehicle communication channels significantly broaden the attack surface. The inter-vehicle network enables an attacker to remotely launch attacks. An attacker can create collision as well as hamper performance by reducing the traffic efficiency. Thus, security vulnerabilities must be taken into consideration in the early phase of the development cycle of CVs. To the best of our knowledge, there exists no such automated simulation tool using which engineers can verify the performance of CV prototypes in the presence of an attacker. In this work, we present an automated tool flow that facilitates false data injection attack synthesis and simulation on customizable platoon structure and vehicle dynamics. This tool can be used to simulate as well as design and verify control-theoretic light-weight attack detection and mitigation algorithms for CVs.
... Using Location-based Services in ITSs is still a challenge for current research: the provided services must be available in real-time, secure against manipulation, and should be protecting their users' privacy. One widely spread approach to include privacy into the architecture of ITSs has been the use of pseudonyms managed by a Public-Key Infrastructure (PKI) [1]- [4]. This solution enables secure communication between participants and aims to achieve privacy by periodically exchanging pseudonyms to prevent user tracking. ...
Conference Paper
Full-text available
Efficient and intelligent traffic networks rely on the constant exchange of information between participants. For instance, navigation services benefit directly from the availability of real-time traffic information to suggest the most time-optimized and ecologically sustainable routes. This type of information is now commonplace and is formed based on extensive, microscopic movement profiles. This imposes direct constraints on the location privacy of users who implicitly or explicitly share such information. In this paper, we present STRIDE as a component of an ITS to gather real-time traffic information in a privacy-friendly manner, ultimately protecting data sources (i.e., users) against data misuse. Our architecture is designed around the concept of distributed trust, preventing attackers from tracking vehicles across the network, even if they succeed in compromising network components. We also achieve conformity to ETSI standards and conclude that real-world implementation of our architecture would be feasible. Thus, we evaluate STRIDE using SUMO and a real-world data set to analyze STRIDE's potential to provide accurate traffic information. Furthermore, we show that STRIDE ensures k-anonymity even in sparse traffic scenarios, eventually protecting location privacy of each vehicle.
Conference Paper
Cooperative Adaptive Cruise Control, a promising Vehicular Ad-hoc Network application, automates transportation and improves efficiency. Vehicles form a platoon, following a leader, with their controllers automatically adjusting velocity, based on messages by other vehicles, to keep appropriate distances for safety. Towards deploying secure Cooperative Adaptive Cruise Control, several proposals in academia and standardization leave significant questions unanswered. Thwarting adversaries is hard: cryptographic protection ensures access control (authentication and authorization) but falsified kinematic information by faulty insiders (platoon members with credentials, even the platoon leader) can cause platoon instability or vehicle crashes. Filtering out such adversarial data is challenging (computational cost and high false positive rates) but, most important, state-of-the-art misbehavior detection algorithms completely fail during platoon maneuvering. In this paper, we systematically investigate how and to what extent controllers for existing platooning applications are vulnerable, mounting a gamut of attacks, ranging from falsification attacks to jamming and collusion; including two novel attacks during maneuvering. We show how the existing middle-join and leave processes are vulnerable to falsification or 'privilege escalation' attacks. We mitigate such vulnerabilities and enable vehicles joining and exiting from any position (middle-join and middle-exit). We propose a misbehavior detection system that achieves an F1 score of 87% on identifying attacks throughout the lifetime of the platoon formation, including maneuvers. Our cyberphysical simulation framework can be extended to assess any other driving automation functionality in the presence of attackers.
Dynamic group signatures (DGS) enable a user to generate a signature on behalf of a group of users, allowing a prospective user to join via an appropriate join protocol. A natural security requirement in the dynamic setting is to permit an adversary to concurrently perform join protocol executions. To date, most of DGS schemes do not provide the efficient concurrent join protocols in their security analysis, because of the need to use knowledge extractors. Also, DGS schemes have to provide efficient batch verifications for practical applications such as Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communication, where a large number of group signatures should be verified in a very short time. In this paper, we propose a new practical DGS scheme that supports not only efficient concurrent joins but also batch verifications. The concurrent security is proven by showing that our join protocols are simulated without any knowledge extractor in security analysis. To do this, we introduce a modified Pointcheval–Sanders (PS) problem that can guarantee efficiently checking equality of discrete logarithms. In terms of efficiency, when considering a type-3 pairing, our DGS scheme has the advantages that the signature generation and verification are faster and especially our batch verification is at least 7 times faster in case of verifying 100 signatures, compared to other comparable pairing-based DGS schemes in the literature.
Conference Paper
Full-text available
We design, implement, and evaluate a technique to identify the source network interface card (NIC) of an IEEE 802.11 frame through passive radio-frequency analysis. This tech- nique, called PARADIS, leverages minute imperfections of transmitter hardware that are acquired at manufacture and are present even in otherwise identical NICs. These imper- fections are transmitter-specic and manifest themselves as artifacts of the emitted signals. In PARADIS, we measure dierentiating artifacts of individual wireless frames in the modulation domain, apply suitable machine-learning classi- cation tools to achieve signicantly higher degrees of NIC identication accuracy than prior best known schemes. We experimentally demonstrate eectiveness of PARADIS in dierentiating between more than 130 identical 802.11 NICs with accuracy in excess of 99%. Our results also show that the accuracy of PARADIS is resilient against ambient noise and uctuations of the wireless channel. Although our implementation deals exclusively with IEEE 802.11, the approach itself is general and will work with any digital modulation scheme.
Conference Paper
Large-scale peer-to-peer systems face security threats from faulty or hostile remote computing elements. To resist these threats, many such systems employ redundancy. However, if a single faulty entity can present multiple identities, it can control a substantial fraction of the system, thereby undermining this redundancy. One approach to preventing these “Sybil attacks” is to have a trusted agency certify identities. This paper shows that, without a logically centralized authority, Sybil attacks are always possible except under extreme and unrealistic assumptions of resource parity and coordination among entities.
Defensive publication
  • Anonymous
Anonymous. Defensive publication. [Online]. Available:
Hardware security module Available: en. wikipedia.orglwikilHardware-security -module
  • Wikipedia
Security Architecture and Mechanisms for V2VIY2I. [Online] Available: www.sevecom.orglDeliverables/Sevecom-Deliverable- D2
  • Secure Vehicle Communication
A generic public key infrastructure for securing Car-to-X communication
  • N Bißmeyer
  • H Stübing
  • E Schoch
  • S Götz
  • J P Stolz
  • B Lonc
N. Bißmeyer, H. Stübing, E. Schoch, S. Götz, J. P. Stolz, and B. Lonc, "A generic public key infrastructure for securing Car-to-X communication," in 18th World Congress on Intelligent Transport Systems, 2011.
Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), SEC Std
SEC, Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV), SEC Std. 4, 2011.
Stage 3 mapping for IEEE
  • Security
Security; Stage 3 mapping for IEEE 1609.2.
July) Recommended elliptic curves for federal government use Available:
National Institute of Standards and Technology. (1999, July) Recommended elliptic curves for federal government use. [Online]. Available:
Available: security module
  • Wikipedia
Wikipedia. Hardware security module. [Online]. Available: security module