A GENERIC PUBLIC KEY INFRASTRUCTURE FOR

SECURING CAR-TO-X COMMUNICATION

Norbert Bimeyer1, Hagen Stbing2, Elmar Schoch3, Stefan Gtz4, Jan Peter Stotz1,
Brigitte Lonc5
1

Fraunhofer SIT, Secure Mobile Systems, 64295 Darmstadt, Germany,

[norbert.bissmeyer, jan-peter.stotz]@sit.fraunhofer.de
2

Adam Opel AG, Active Safety, 65423 Rsselsheim, Germany,

hagen.stuebing@de.opel.com

Volkswagen AG, Security and Connectivity, 38436 Wolfsburg, Germany,

elmar.schoch@volkswagen.de

Continental Teves AG & Co. oHG, Connected Systems, 60488 Frankfurt / Main, Germany,
stefan.goetz@continental-corporation.com
5

RENAULT S.A.S., Electronic Systems Engineering Department, 1 Avenue du Golf,

78288 Guyancourt Cedex, France, brigitte.lonc@renault.com

ABSTRACT
Security and privacy in Car-to-X (C2X) communication is a major aspect that affects all
applications used in the network. Due to the wireless communication and the decentralized
character of the ad-hoc network attacks are inevitable and are hardly detectable by central
entities. Especially, safety critical applications which trigger their actions based on data
received from other network entities are relying on the trustworthiness of the exchanged
messages. To achieve this trust in messages, the worldwide commonly followed approach is
to introduce a Public Key Infrastructure (PKI). The PKI issues certificates to C2X enabled
units and therefore assures their validity. Yet, C2X has several special requirements on the
design of a suitable PKI, like minimum overhead and privacy preservation.
This paper presents a PKI organisation and structure, which was created in the context of the
Car 2 Car Communication Consortium (C2C-CC), the European industry forum on C2X
communication technologies. In the design of our proposed PKI, great importance is
attached laid on interoperability with other PKIs (e.g. in the U.S.) and extensibility for future
additional implementations. Processes are defined for message verification, certificate updates
and entity revocation. Likewise, flexible privacy protection measures and anonymity aspects
in the ad-hoc communication as well as in the PKI backend are also a major topic.

I. INTRODUCTION
Within the vehicular ad-hoc domain messages are exchanged spontaneously between different
nodes. The ad-hoc communication channels are allocated at 5.9 GHz frequency (G5A) [1].
-1-

ETSI [2] defines a basic set of messages. The so-called Cooperative Awareness Messages
(CAM) are broadcasted periodically and contain mobility information of the sender such as
position, heading, speed and further status information such as vehicle dimensions.
Decentralized Environmental Notification Messages (DENM) are event driven messages
which are sent either via single-hop broadcast or geocast. ITS Vehicle Stations (IVS)
communicate with other IVS or with ITS Roadside Stations (IRS) that may be connected to
the backend via ITS Central Stations (ICS). The term Car-to-X (C2X) reflects the different
communication links, between IVS among themselves as well as between IVS and IRS.
In order to prevent message injection, falsification and eavesdropping, authentication of the
sender as well as message integrity has to be assured by security mechanisms. By using
asymmetric cryptography a sender is able to sign outgoing messages with a private key that is
securely stored and not available to other entities. The appropriate public key which is part of
the digital certificate is appended to every message. Every receiver is therefore able to verify
the message integrity and authenticity by verifying its signature. Additionally, the sender
authentication can be verified by checking the signature of the certificate.
The primary objectives of a Public Key Infrastructure (PKI) are:
1) Issuing and provisioning of valid certificates to respective ITS stations.
2) Limiting digital credentials misuse (i.e. private key, public key, and certificate) by
controlling their validity.
3) Excluding compromised ITS stations or PKI entities from the network activities by
revoking their credentials.
In a classical PKI hierarchy a Root Certificate Authority (RCA) issues additional Certificate
Authorities (CAs) that in turn issue certificates for end users (e.g. persons or computer
systems) when they register at a Registration Authority (RA). A PKI that is used as trust
anchor for securing C2X communication has different requirements compared to classical
PKIs. As no person authentication is necessary within C2X communication, all processes can
be highly automated. In this machine-to-machine communication ITS stations do not only
have to authenticate themselves against each other but also against the CA when requesting
new certificates. Furthermore, privacy protection of vehicle drivers has to be considered by
changing regularly all identities in the communication which also includes the change of
certificates used for message signing.
The remainder of the paper is structured as follows: In section II general assumptions of the
vehicular ad-hoc network are described, followed by the proposal of the PKI structure in
section III. In section IV main processes of the PKI are discussed. Revocation of certificates
and therefore the possibility to withdraw a once gained authorization to actively participate in
the C2X communication is also discussed in this section. Finally, in section V a conclusion
and future work is presented.
-2-

II. ASSUMPTIONS AND SYSTEM REQUIREMENTS

CAs play a key role within a PKI as they are responsible for providing and withdrawing of
communication rights for every ITS station. For both interactions at least a temporary
communication link has to be available between the ITS station and the PKI backend.
Different communication technologies (e.g. IEEE 802.11p/a/b/g/n, Cellular link, On Board
Diagnosis, Removable media, etc.) are considered for updating the certificate store or getting
revocation information. This may lead to the positive effect of higher connection frequency
between the mobile ITS station and central PKI.
Data protection is essential for the connection to the CAs and has to be addressed in all
processes by encryption. Furthermore, the communication with the PKI has to be fault
tolerant due to possibly short connection duration and likely interruptions in the
communication. In order to prevent possible misuse, we anticipate storing critical data such as
private keys, in a secure storage on ITS station side that prevents extraction. Depending on
the type of ITS station, different hardware protection levels are envisioned. For instance,
embedded systems of vehicles may need lower hardware protection mechanisms because
cryptographic data can be bound more easily to the vehicular system. Yet, ITS stations with
more authoritative functions such as emergency vehicles or traffic light must be more robust
against key extraction.
Privacy protection mechanisms are essential for successfully establishing Car-to-X
communication in the market. In order to prevent tracking by external attackers a concept of
pseudonymization is designated where vehicles change identifiers in a frequently and
unexpected manner. All identifiers inside a message such a MAC address, network layer
identifier and the certificate are referred as pseudonym. The pseudonym change strategy and
frequency is out of scope of this work, since we consider it as a feature specific to
manufacturers. For security and effectiveness reasons, we only advocate to standardize
boundaries of maximum and minimum frequency.

III. PUBLIC KEY INFRASTRUCTURE

The proposed PKI, as displayed in Figure 1, presents a structure that takes into account
potential different policies in different countries as well as flexibility for various operational
models. The solution may also be deployed worldwide, depending on harmonization.
The role of the Root CA (RCA) is to define common policies among all subordinate
certificate issuers. The RCA only issues certificates for Long-Term CAs (LTCAs) and
Pseudonym CAs (PCAs), which are valid over long time periods. If there are multiple RCAs,
trust between them can be established by using cross certification this allows more flexible
relationships on the top layer of the PKI. No other cross certification between CAs is allowed,
beyond those defined between Root CAs. Based on enrolment processes at the Root CA,
-3-

different institutions such as vehicle manufacturers (often called OEMs), suppliers,

governmental authorities or other companies may potentially operate Long-Term CAs and
Pseudonym CAs.

Figure 1: General PKI structure

Every LTCA has a certificate that is signed with the private key of the Root CA. With a
similar process the Root CA issues Pseudonym CAs which in turn provide subsequently a
valid Pseudonym CA certificate. Finally, the LTCA is able to issue for each responsible ITS
station one Long-Term Certificates (LTC), that is valid for a longer period of time. Each LTC
created by a LTCA is dedicated to identify and authenticate the respective ITS station within
the PKI and potentially other services, but it is never exposed to the G5A communication for
privacy reasons. In contrast, Pseudonym Certificates (PCs) issued by PCAs are used for the
G5A broadcast communication.

Benefits of the architecture

a) Root CA: The introduction of a Root CA as a central trust anchor simplifies registration of
new Long-Term CAs and Pseudonym CAs in several ways. First, a central RCA is more cost
efficient than a decentralized solution without such a central trust anchor. Assuming
worldwide several dozens or even hundreds of Long-Term CAs are present without a Root
CA. Then a new Pseudonym CA operator would have to make contractual relationships with
all Long-Term CAs in order to be admitted to a large portion of the vehicles. In such a
scenario the number of contracts (and costs) is raising in a quadratic manor whereas a Root
CA leads to simple linear effort. Furthermore the distribution of updates to the vehicles
containing the new list of Pseudonym CAs would be challenging if we assume vehicles may
not be reachable for a longer time.
b) Flexibility for operational models: As discussed in the previous section, different entities
are able to operate Pseudonym CAs with or without a correspondent Long-Term CA. For
privacy reasons, it is also reasonable that an organization such as an OEM is operating a
Long-Term CA under the European Root CA and another organization (e.g. the Car2Car
-4-

Communication Consortium or a European institution) provides a common PCA for multiple

OEMs. The flexibility of the concept also implicitly considers the application of special
public safety and roadside station certificates. The Pseudonym CA of a country may have,
cryptographically fixed in the LTCA certificate, special rights to issue Pseudonym Certificates
for ITS roadside stations, ITS central stations or emergency vehicles. Additionally, due to
Long-Term Certificates are not used for message signing in the G5A communication there is
no need to use special vehicular certificates which has been optimized for minimal size such
as WAVE certificates, defined by IEEE 1609.2 [3]. Well-established certificate formats such
as X.509 with RSA keys may be used as well.
In order to keep the overhead of transmitting certificates over G5A minimal, it is important to
attach only one single certificate to a message. If all PCA certificates are preloaded in a
vehicle, messages can be verified instantly. Even if a PCA certificate is not available it may be
requested on demand from the sender, and the receiver will be able to verify the PCA
certificate using the preinstalled Root CA.

Certificate Types and Formats

The PKI architecture involves a number of different types of keys and certificates. This
section roughly describes all involved key types. Note that the definition of a specific
certificate format is out of scope of this work. Therefore, we mainly refer to generic contents
in the following. A candidate for G5A certificates format may be IEEE 1609.2, for example.

Figure 2: Credentials of ITS and PKI entities

In general, all certificates have a link to the signer (except the Root CA certificate) which is
represented as digest of the respective certificate, called Cert-ID. In order to save valuable
-5-

resources, only the Cert-ID of the direct issuer (Signer-ID) is part of the certificate in contrast
to a complete certificate chain. Figure 2 presents an overview of the credentials available to
the ITS stations and PKI entities. Every entity (i.e. CA, IVS, IRS, ICS) is equipped with a
digital certificate, the respective Signer-ID and a key pair consisting of private and public key.
To give a rough idea about the sizes of certificates and signatures, the following numbers
adopt the sizes defined in IEEE 1609.2. The size of a CA certificate is about 126 bytes
consisting of the Signer-ID (8 bytes), public key (35 bytes) and certificate specific data (19
bytes) that provides information about certificate type, application information, regional
restrictions, start and expiry of validity.
All C2X messages sent by an ITS station have to be signed with a pseudonym. Therefore the
message size is at least increased by a constant security overhead of approximately 186 bytes,
with the attached pseudonym certificate including additional security parameters requiring
130 bytes and the signature 56 bytes in case of using ECDSA NIST 224 for pseudonym
keys.

Key Management on ITS Stations

As presented in Figure 2 all ITS Stations (i.e. vehicles and roadside stations) have to manage
different credentials on their local system. In order to get an impression about the quantities of
credentials, Table 1 lists these various credentials and gives some rough figures on expected
number, required storage capacity, storage type and potential lifetimes for Long-Term usage.
Note that, for an initial deployment, much less credentials have to be stored, such as 5 RCA
certificates, 20 LTCA certificates and 20 PCA certificates. This results in a storage capacity of
about 234 KB. The maximum number of own pseudonym certificates stored on the ITS
station may vary depending on the pseudonym refill strategy discussed in section IV. We
assume in Table 1 a mean pseudonym consumption of 4 certificates per day and a preload
time of one year.
Table 1: Estimation of stored certificates on the ITS stations
Certificate Type

Stored certificates

Certificate size

Total size

Root CA
certificate

20 (plus 380 cross

certificates)

~ 126 Byte

2,5 KB
49 KB

LTCA certificate

up to 1000

~ 126 Byte

PCA certificate

up to 2000

LTC

Storage type

Lifetime

secured

10 - 15 years

123 KB

unsecured

10 - 15 years

~ 126 Byte

246 KB

unsecured

5 years

~ 125 Byte

0,1 KB

unsecured

10 years

LT private key

32 Byte

< 0,1 KB

secured

10 years

PC

~ 1500 for one year

~ 124 Byte

182 KB

unsecured

1 year

Pseudonym
private key

~ 1500 for one year

32 Byte

46 KB

secured

1 year

~ 650 KB (95 KB secured)

-6-

IV. PKI OPERATIONAL PROCESSES

In the following main processes of the secure C2X communication are described. After
introducing the general concept of sender authentication and message integrity verification
processes for changing pseudonym certificates on ITS stations is proposed as well as a
process for requesting new PCs. Finally, the exclusion of compromised ITS stations is
discussed.

Message Signing and Verification

The sender of C2X messages has to sign all outgoing messages with the private key of a valid
pseudonym. Afterwards, the message with appended signature and pseudonym certificate is
broadcasted. On receiver side, the senders authentication has to be verified and the message
integrity has to be verified by decrypting the signature with the public key from the appended
PC. Further mechanisms ensure the message freshness and validity of all certificates.
The senders authenticity will only be accepted if verification of the respective pseudonym
certificate up to a Root CA is possible. If a PCA certificate in the local certificate store on an
ITS station is not available for pseudonym verification, a decentralized mechanism is
approached to retrieve it. In order to do this, the receiver creates a new message with the
Cert-ID of the missing certificate and sends it via unicast to the sender. Then, the receiver of
this request creates a response and returns the respective PCA certificate.

Roaming between Pseudonym CAs

We assume that special units such as emergency vehicles will use a specific PCA, and we can
expect that legislation in different markets will require a separate PCA with different policies.
As a result, vehicles may need to detect that their own pseudonyms as well as received
certificates are not valid in the current region. For the purpose of support of regional policies,
we propose to use region IDs in certificates, if required. Region IDs could be resolved by a
preloaded list of regions including their geographic shape, such as displayed in Figure 3.
Based on this check, the
region of received PCs can
be validated and own certificates can be checked
before they are used to sign
messages. Vehicles without
valid certificates must
request new pseudonyms as
soon as a communication
link is available.

Figure 3: Using country shapes for regional validity of PCs

-7-

Pseudonym Change
In order to protect the privacy of vehicle drivers, all identifiers in the C2X communication (i.e.
pseudonym certificate, network layer node ID and IP address) have to be changed regularly.
However, we argue that there is no need to standardize the pseudonym change frequency. The
vehicle manufacturer or even the driver should be able to modify its own change frequency
dynamically. Nevertheless, using a high pseudonym change frequency requires more
pseudonyms to be available on the vehicle. This directly affects the required size of the local
key storage on the vehicles as displayed in Table 1 and the pseudonym refill interval
described in the following section.
If the vehicle has no unused Pseudonym Certificate in its local database then previously used
pseudonym certificates may be re-used in a pseudo-Round-Robin-like fashion. Alternatively,
the vehicle signs the messages with an expired pseudonym certificate and based on the policy
at the receiver the messages are discarded or used with low trustworthiness.

Refill of Pseudonym Certificates

In this paper we assume that ITS stations create asymmetric key pairs locally and send the
public key to the PCA in order to retrieve corresponding pseudonym certificates.
Due to different communication types as mentioned
in section II, we do not
assume a continuous link to
a Pseudonym CA. In the
deployment phase of C2X
communication, IRS will
only cover a very small
percentage of the road
system in Europe and not
Figure 4: Pseudonym Request Parameters
all vehicles will be
equipped with cellular communication technology. Therefore, we assume that a
communication between vehicles and a CA may happen extremely seldom.
The required frequency of updates, the delivered level of privacy and security can be
expressed basically by three determining parameters (cf. Figure 4):
x

Number of parallel Pseudonyms, issued to be valid in the same time interval. It can be
defined that the requester can use several pseudonyms with the same start and expiry date.

Lifetime of Pseudonyms is defined by the time between start and expiry timestamps of the
PC. If the lifetime is too long, attackers may misuse PCs, since we advocate to avoid
revocation for PCs for scalability reasons.

-8-

Pseudonym preloading interval denotes the maximum expiry timestamp of PCs issued in
a reloading process. This parameter also relates to the security of the system and the
frequency of updates.

As displayed in Figure 5 the ITS station sends a request to a predefined Pseudonym CA (e.g.
Home PCA). This request includes the Signer-ID of the Long-Term Certificate, the list of
public keys, the current position and an identifier or address of the Long-Term CA.
If a Pseudonym CA receives the request it checks if it is allowed to issue Pseudonyms for the
requested region. If another Pseudonym CA is responsible for the region then the request is
forwarded to the appropriate Pseudonym CA such as displayed in Figure 5.
For privacy reasons the Signer-ID of the sender may be encrypted with the public key of the
Long-Term CA. In this case, the Pseudonym CA is not able to create a link between the
pseudonyms and the long term ID of the vehicle. Also the Long-Term CA is not able to create
such a link because the Pseudonym CA is not forwarding the public keys or PCs.

Figure 5: Pseudonym Request Process

If required through on legislation, the Signer-ID may also be transmitted unencrypted so that
the PCA is theoretically able to operate a database that links between the Long-Term CA
and the Pseudonym Certificates. With this process we propose a flexible way to protect the
requesters privacy and omit more complex protocols such as described in [4].
The appropriate PCA sends a request with the (encrypted) Signer-ID of the requester, a
calculated preloading time and the region ID to the Long-Term CA for verification. The LTCA
maintains a database that stores the timestamp until a vehicle has valid pseudonyms for a
distinct region. Only if the Signer-ID of LTC can be found at the Long-Term CA, the
-9-

certificate is not deactivated and no pseudonyms are issued for the given region ID until the
given preloading time then the Pseudonym CA gets a positive response from the LTCA.
Subsequently, the Long-Term CA responds to the Pseudonym CA a start timestamp for new
pseudonyms. Enabled by this procedure the PKI can circumvent that vehicles request
pseudonyms for the same time interval from different or the same Pseudonym CA.
Additionally, the Long-Term CA creates a symmetric decryption key based on the start and
expiry time, and region ID that can be used by the Pseudonym CA to encrypt pseudonym. If
the requested pseudonyms are designed for usage in near future time, then the set of
Pseudonyms is sent to the ITS station without encryption. Otherwise, if the pseudonyms are
designed for a farther future time interval then the set is encrypted with the symmetric key
received from the LTCA in order to prevent misuse. This key is stored in a database at the
Long-Term CA and in case of a decryption key request it is sent to the requesting ITS station.
For such encrypted Pseudonym certificates, short connectivity over G5A for pseudonym
requests can be considered because only one short key has to be transmitted in order to use
preloaded pseudonym certificates. Furthermore, the concept enables the endowment of
pseudonyms for farther future time intervals by restricting the number of pseudonym that can
be used in the near future. In order to decrypt a pseudonym set on the ITS station it can
request the symmetric key by sending the validity time and region ID of the pseudonym. The
responsible LTCA answers with the decryption key if it is available and the start time of
validity of requested Pseudonym certificates is reached.

Revocation of ITS Stations

A fast revocation of pseudonym certificates in the C2X communication is difficult due to
communication restrictions between vehicles and Pseudonym CAs. Therefore, especially in
the first deployment phase the distribution of CRLs may be problematically. As result, the
proposed PKI does not consider distribution of CRLs containing pseudonyms within the
vehicular network in contrast to related PKI proposals [5] [6].

Figure 6: Revocation of ITS stations

-10-

A revocation of vehicles can only be done by rejecting the request for new pseudonym
certificates as illustrated in Figure 5 and Figure 6. In this concept the Long-Term CA links the
revocation information of the vehicle to its Long-Term Certificate. If an ITS station requests
new pseudonym certificates then the Pseudonym CA forwards the request to the respective
Long-Term CA which checks the authorization of the requester.
Furthermore, external registration authorities may automatically inform the LTCA over a
secure communication channel about reversible (de-)registration of ITS stations. The affected
LTC is then marked as active or inactive in the database. In case of permanent deactivation
(e.g. when vehicles or roadside stations will be junked) the LTC entry is deleted from the
database in order to prevent subsequent misuse of these communication systems.

Revocation of CA Certificates
For the revocation of Pseudonym CAs, Long-Term CAs and Root CAs a distribution of CRLs
is proposed. Based on CRLs all revoked CAs have to be distributed actively in the V2X
system. CA certificates that are compromised or not trustworthy due to other reasons are
revoked manually by the PKI administration. Afterwards, the Cert-ID of the affected CA is
added to the CRL and signed by the Root CA. Finally, the CRL is distributed inside the PKI
backend as well as to all ITS stations over available communication links as described in
section II. However, we expect that the case of compromise of a CA should happen extremely
rarely.

Misbehaviour Detection and Reporting

Misbehaviour detection and reporting is considered in the PKI concept but not specified in
more detail. On the one hand well defined misbehaviour algorithms are not yet available and
on the other hand a communication link between the ITS station and a CA is necessary for the
reporting of misbehaviour. Nevertheless, different misbehaviour detection strategies and
voting schemes [7] are proposed that may be used to report suspicious ITS stations to the
responsible Long-Term CA. At first, checks of physical implausibility of mobility data in
messages such as position, heading, and velocity are proposed [8] as well as the verification
of mobility behaviour applying tracking algorithms [9]. Furthermore, random packets can be
passed to the CA in order to detect whether the same certificate is used at completely different
locations at the same time. These algorithms can be improved continuously without disturbing
already deployed ITS stations.

V. CONCLUSION AND FUTURE WORK

In this paper we present a PKI solution that is the result of standardization efforts by the
C2C-Communication Consortium (C2C-CC). Main aspects such as certificate generation,
issuing, distribution and revocation are described by considering important issues such as
privacy and practicability. Furthermore, flexibility and interoperability with other proposed
-11-

PKI concepts, e.g. [6] and [5], are regarded. Extensibility of the proposed mechanisms for
additional future requirements is also considered.
In order to show the practicability of the proposed concept an initial prototype
implementation of the PKI developed in the field operational test project simTD [10] will be
extended by the processes described here in order to evaluate the scalability and availability
requirements. Other projects aiming at field-testing cooperative systems, such as Score@F
French FOT or PRESERVE project will also develop PKI entities and assess the flexibility
and adaptability of the overall PKI system. Furthermore, the C2C-CC considers European
wide deployment as well as ramp up scenarios for the initial integration of C2X
communication.

VI. REFERENCES
[1] ETSI ES 202 663, "European Profile Standard for the Physical and Medium Access Control
Layer of Intelligent Transport Systems Operating in the 5 GHz Frequency Band," in European
Telecommunications Standards Institute, Sophia Antipolis, France, 2010.
[2] ETSI TS 102 637, "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Part 2: Specification of Cooperative Awareness Basic Service V1.1.1," ETSI
Technical Specification ETSI TS 102 637-2, April 2010.
[3] Intelligent Transportation Systems Committee, "IEEE Trial-Use Standard for Wireless Access in
Vehicular Environments - Security Services for Applications and Management Messages," IEEE
Vehicular Technology Society Standard 1609.2 - 2006, 2006.
[4] L. Fischer, A. Amer, C. Eckert, and D. Vogt, "Secure Revocable Anonymous Authenticated
Inter-Vehicle Communication (SRAAC)," in Embedded Security in Cars (escar), Berlin,
Germany, 2006.
[5] G. Di Crescenzo and T. Zhang, "Efficient CRL Search in Vehicular Network PKIs," in DIM`10,
Chicago, Illinois, USA, 2010.
[6] S. Pietrowicz, T. Zhang, and H. Shim, "Short-Lived, Unlinked Certificates for Privacy-Preserving
Secure Vehicular Communications," in 17th ITS World Congress, Busan, Korea, 2010.
[7] B. Ostermaier, F. Dtzer, and M. Strassberger, "Enhancing the Security of Local Danger Warnings
in VANETs - A Simulative Analysis of Voting Schemes," in Seconds International Conference on
Availability, Reliabiliy and Security, Vienna, Autria, 2007.
[8] R. K. Schmidt, T. Leinmller, E. Schoch, A. Held, and G. Schfer, "Vehicle Behavior Analysis to
Enhance Security in VANETs," in Workshop on Vehicle to Vehicle Communications (V2VCOM),
Eindhoven, the Netherlands, 2008.
[9] H. Stbing, A. Jaeger, N. Bimeyer, C. Schmidt, and S. A. Huss, "Verifying Mobility Data under
Privacy Considerations in V2X Communication," in 17th ITS Wolrd Congress, Busan, Korea,
2010.
[10] N. Bimeyer, et al., "simTD Security Architecture," in Embedded Security in Cars Conference
(escar), Dsseldorf, Germany, 2009.

-12-