A GENERIC PUBLIC KEY INFRASTRUCTURE FOR SECURING CAR-TO-X COMMUNICATION Norbert Bißmeyer1, Hagen Stübing2, Elmar Schoch3, Stefan Götz4, Jan Peter Stotz1, Brigitte Lonc5 1
Fraunhofer SIT, Secure Mobile Systems, 64295 Darmstadt, Germany, [norbert.bissmeyer, jan-peter.stotz]@sit.fraunhofer.de 2
3
4
Adam Opel AG, Active Safety, 65423 Rüsselsheim, Germany,
[email protected]
Volkswagen AG, Security and Connectivity, 38436 Wolfsburg, Germany,
[email protected]
Continental Teves AG & Co. oHG, Connected Systems, 60488 Frankfurt / Main, Germany,
[email protected] 5
RENAULT S.A.S., Electronic Systems Engineering Department, 1 Avenue du Golf, 78288 Guyancourt Cedex, France,
[email protected]
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
1
~ 125 Byte
0,1 KB
unsecured
10 years
LT private key
1
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 sender’s 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 sender’s 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):
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 requester’s 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 -9-
distinct region. Only if the Signer-ID of LTC can be found at the Long-Term CA, the 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. After the creation of pseudonym certificates on the PCA, a digest of the pseudonym set is created and sent to the responsible LTCA. On the LTCA a symmetric key for the pseudonym set is created, stored in the database as well as sent back to the PCA. 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. For such encrypted blocks of PCs, short connectivity over G5A for pseudonym requests can be considered because only one 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 from a PCA by sending the digest of the pseudonym set. The PCA forwards this digest to the responsible LTCA which answers with the key if it is available and the time of validity of the certificates included in the encrypted block 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 6Fehler! Verweisquelle konnte nicht gefunden werden.. 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 -11-
privacy and practicability. Furthermore, flexibility and interoperability with other proposed 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 Wolrd Congress, Busan, Korea, 2010. [7] B. Ostermaier, F. Dötzer, 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. Leinmüller, E. Schoch, A. Held, and G. Schäfer, "Vehicle Behavior Analysis to Enhance Security in VANETs," in Workshop on Vehicle to Vehicle Communications (V2VCOM), Eindhoven, the Netherlands, 2008. [9] H. Stübing, A. Jaeger, N. Bißmeyer, 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. Bißmeyer, et al., "simTD Security Architecture," in Embedded Security in Cars Conference (escar), Düsseldorf, Germany, 2009.
-12-
