Trust, Security and Privacy in VANETs – A Multilayered ... - CiteSeerX

Trust, Security and Privacy in VANETs – A Multilayered Security Architecture for C2C-Communication ? Frederic Stumpf, Lars Fischer and Claudia Eckert Research Group IT-Security, Department of Computer Science, Technische Universit¨ at Darmstadt, Germany. {stumpf,fischer,eckert}@sec.informatik.tu-darmstadt.de

¨ Abstract. Dieser Beitrag stellt ein mehrschichtiges Protokoll zur Ubermittlung von Sicherheitsmeldungen in Fahrzeugnetzen vor. Es gew¨ ahrleistet dabei die Anonymit¨ at der Fahrzeughalter und verhindert dadurch, dass unerlaubt Bewegungsprofile eines Fahrzeuges erstellt werden k¨ onnen. Gleichzeitig implementiert das Protokoll einen Mechanismus, der erlaubt die Anonymit¨ at aufzuheben, was es erm¨ oglicht ein Fahrzeug aus dem Fahrzeugnetz zu isolieren. Aufgrund der Tatsache, dass Verkehrsnachrichten a ¨ußerst sensible und kritische Informationen enthalten, ist es von entscheidender Bedeutung, dass die vom Fahrzeug verwendete Software nicht unzul¨ assig manipuliert wurde. Dies w¨ urde es ansonsten erm¨ oglichen, dass manipulierte Sicherheitsmeldungen eingespielt werden. Um dies zu verhindern, bedient sich das in diesem Beitrag vorgestellte Protokoll eines zweiten Mechanismus, der sicherstellt, dass nur die Fahrzeuge in der Lage sind, Nachrichten zu verschicken, deren Software nicht manipuliert wurde.

1

Introduction

As we move into an era of networked systems, vehicles are also being equipped with wireless communication technologies. Based on these abilities, different vehicles are able to exchange information related to traffic safety and thus increase traffic safety and efficiency. A particular vehicle could for example be warned about danger situations that have been detected by sensors of another vehicle. In this context, we consider multi-hop messages, e.g., Vehicle based Road Condition Warning [1] and single hop messages, e.g., Emergency Electronic Brake Lights [2]. However, the introduction of safety message raises severe security challenges. Since these messages influence the behaviour of critical components, a misuse of safety messages can result in serious accidents. These safety messages require trusted software components to ensure that a particular safety message is based on real events and not injected from a malicious vehicle. Additionally, it is also necessary to have a mechanism that can ?

Appeared in 23. VDI/VW-Gemeinschaftstagung: Automotive Security, pp. 55-70, Wolfsburg, Germany, VDI-Verlag, 2007

2

Stumpf et al.

isolate misbehaving vehicles from the network. Compounding this problem is that a vehicle owner could transfer identification data to other vehicles, which undermines the possibility to clearly identify and isolate misbehaving vehicles. As a result, key challenges in architectures that support safety messages arise, such as ”trustworthiness of the vehicles system components” and ”liability identification” [3]. Additionally, problems of ”privacy and anonymity” arise from possible misuse of personal movement data [3]. Examples for such risks are, wrong brakesignals maliciously inserted into the system movement logs of vehicle movements in the hands of a single traffic authority representative.

In this paper, we present a multi-layered security protocol that enables a vehicle to take part in Inter-vehicle communication for safety information, while satisfying the above mentioned requirements. Our solution is based on two main schemes: Attestation of virtualized system components and secure revocable anonymous authenticated communication. Virtualization isolates system components, which prevents different system components from influencing each other. It therefore allows encapsulating security-sensitive systems, such as the brake assist system and isolating these systems from others. To ensure that sensitive software components are untampered, they are measured by a hardware-based, tamper-resistant measuring engine (TPM) and the obtained results are stored in a protected storage. These measurements are then reported to remote entities (remote attestation) [4], e.g., during the anonymity protected certificate issuance of a communication protocol to prove that the measured soft- and hardware components are in a trusted state.

An Inter-vehicle communication protocol should use methods to increase unlinkability of distinct messages. Our certification protocol utilises revocable blinded signatures and shared secrets to provide an adjustable tradeoff between authenticity and privacy. Tracing requests by the traffic authorities are fulfilled by mapping certificates to identities of vehicle owners by shared secret interpolation. This process enforces the many-eye principle to protect the user’s privacy while ensuring that the traffic authorities are able to trace and exclude rogue vehicles.

This paper is structured as follows. In section 2 we provide an overview on trusted computing and a communication scenario. We provide a brief overview of trusted computing and explain the scenario in Section 2. In Section 3 we describe our already proposed protocol for obtaining a certificate to transmit safety messages and perform a threat analysis. This section is followed by Section 4 which extends the presented protocol with additional mechanisms to ensure that the vehicle’s software is trusted. Section 5 discusses some open issues and the mechanisms of our introduced protocol. Section 6 reviews related work and Section 7 provides concluding remarks.

Trust, Security and Privacy in VANETs

2

3

Basics and Scenario

In this section we first give a broad overview of Trusted Computing, which is necessary to understand our approach. In the second part, we explain the setting and assumptions for our work.

2.1

Trusted Computing

The core component of trusted computing is the Trusted Platform Module (TPM) [5]. The TPM can be viewed as functionally equivalent to a high-end smart card, and is soldered to the motherboard of a platform. The TPM serves as a root of trust within the platform and provides the following functionality: registers for recording platform state; a means of reporting platform state to remote entities; secure volatile and non-volatile memory; random number generation; a SHA-1 hashing engine; and asymmetric key generation, encryption and digital signature capabilities. Tampering with the TPM is generally difficult, since it is implemented in tamper resistant hardware. The registers responsible for recording platform state, a.k.a. Platform Configuration Registers (PCRs), are of particular interest to us. These registers are initialized on startup and used to store software integrity values. Before execution, a software component’s execution is recorded by the stored measurement log (SML) and measured by the TPM. The measurement made by the TPM is written to a specific PCR by combining a hash of the software component with the previous value of the PCR. The following function is used to calculate the value for PCR register N, where SHA1 refers to the cryptographic hash function used by the TPM and || denotes a concatenation: Extend(P CRN , value) = SHA1(P CRN ||value)

(1)

In order to establish trust in a computer system, a trusted computing enhanced system will measure and store the boot sequence of a platform. When turning on a computer, the Core Root of Trust Measurement (CRTM), which resides in the BIOS, is the first component to be executed. The CRTM then measures itself and the BIOS, and hands over control to the next software component in the boot chain. This process continues for every component involved in the boot sequence of a platform. Through the process of remote attestation a subset of the values stored in the PCRs, combined with the SML, can be used to demonstrate to a remote entity that a platform is currently in a particular state. In order to guarantee the authenticity of this attestation, PCRs are signed with a nonmigratable TPM signing key, called an Attestation Identity Key (AIK). An AIK is generated on a TPM and certified by a trusted third party, typically called a Privacy-CA, or signed via a Direct Anonymous Attestation protocol [6]. With the obtained (proof) certificate, a remote platform can compare the signed values with reference values, to check whether the platform is in a trusted state or not.

4

2.2

Stumpf et al.

Scenario

The topic of this paper is secured and anonymous vehicular event message communication. We assume that all vehicles are equipped with means to send and receive messages on a shared broadcast medium. Vehicles recognise events, for example emergency brakes or hazardous road conditions through on-board sensors. The Information about those events is broadcasted in event messages to the vehicular network. Depending on the nature of the event, an event message may be relayed by other vehicles. Rogue vehicles emit faulty event messages because their soft- or hardware is broken or has been (maliciously) been tampered with. Event messages contain positional information and therefore could betray the vehicle’s itinerary. The objectives of the protocol proposed herein are directly adapted to this scenario. Due to severe consequences of false event messages, authorization and nonrepudiability of these messages must be ensured. In order to protect the driver’s privacy, tracking of vehicles through these messages has to be prevented. Messages have to be as small as possible to reduce the transmission time, for example in case of two approaching vehicles. The traffic authorities grant authorization and isolate vehicles that produce faulty event messages. They have to be able to map event messages to vehicle identities and to trace a vehicles itinerary in case of detection of malicious behaviour. Rogue vehicles have to be isolated within a previously chosen maximum isolation time interval. Certificate Revocation Lists (CRLs) are avoided, since this method does not scale well for large networks and tight time constraints. Every vehicle is equipped with an On-Board Unit (OBU) and a Trusted Platform Module (TPM). We assume that the TPM behaves as expected. All vehicles run a virtualized environment that makes use of the TPM. This allows reporting the state of one isolated environment to a remote entity. Examples for such systems are the microkernel-based Turaya kernel [7,8] or Xen-based approaches [9,10]. Both approaches could be used in vehicles, since they are capable of running on embedded controllers such as ARM. The software stack that is responsible for generating safety messages is situated in the OBU. The OBU is produced by a car manufacturer and is equipped with an OBU Certificate for authentication. To reduce the complexity and the number of involved certificates, the OBU can also inherit keys that are protected by the Trusted Platform Module. Additional certificates for authenticating a particular OBU can thus be omitted. We assume that a second method of communication can be used to contact traffic authorities. This second communication medium is used relatively infrequent and has less strict constraints on time and bandwidth, for example WLAN inside a garage. The privacy within this scenario consists of two sub-problems. The Unlinkability as defined in [11], is one of the main topics in our work. The Untraceability describes in this context the unlinkability of event messages and is out of scope of this paper. Nevertheless one purpose of this work is to enable frequent pseudonym changes. Example for such concepts are frequent key changes

Trust, Security and Privacy in VANETs

5

as proposed in [12] and the introduction of random silence periods as proposed in [13]. Both concepts can be used independently.

3

Protocol Overview

This section gives a short overview of our protocol for secure and privacy protected Inter-vehicle communication. The concept is called Secure Revocable Anonymous Authenticated Inter-Vehicle Communication (SRAAC) and has been introduced in [14]. It is based on the distributed magic-ink signatures introduced by Jakobsson and Yung [15]. Unlike other blinded signature schemes, the scheme presented by Jakobsson and Yung offers the possibility to unblind a signed message by the signer, thus allowing a quorum of servers to produce a signature and a possibly different quorum to unblind a signature. After we have introduced the main concepts of this protocol, we will perform a threat analysis and will show which challenges exist that are solved by our contribution. 3.1

SRAAC

SRAAC requires an infrastructure consisting of three main entities, Authentication Authority (AA), On-Board-Units (OBU) which are part of the vehicles and the Inter-Vehicle Communication Certificate Servers (ICS). The AA issues a unique certificate to every OBU and is able to identify and authenticate the holder of a certificate. Inter-Vehicle Communication Certificate Servers (ICS) are responsible for blindly signing and issuing Inter-Vehicle Communication Certificates (IVC), which are used as credentials to authorise an OBU to emit InterVehicle Event Messages. The IVC are signed blindly using the magic ink scheme. The steps for obtaining an IVC are depicted in Figure 1. All ICS, which are denoted as Si , have previously generated an asymmetric key pair (x, y) where x is a shared secret between the servers and y the corresponding public key. The protocol will generate a DSS signature [16] (r, s) on a message k , where k is the issued IVC certificate consisting of validity time and public key. This signed IVC is then used by the OBU for Inter-vehicle communication. x mod y is denoted [x]y in the following calculations. Please refer to [14],[15] for further details. Described below is a protocol to distributedly calculate an IVC certificate for an OBU through a quorum Q of n servers Si . Under normal conditions all available ICS are part of the quorum. The OBU has been authenticated in advance by the AA and has established confidential and secure communications with each server ((1) and (2) in Figure 1). Data on the values of n, t, g, p, q had been agreed upon by the servers and communicated to the OBU. t ≤ n is the number of servers required to recover the anonymity revocation key xt . The variables g, p, q are public parts in DSS [17] where p is prime and has length l, where l is a multiple of 64 and 512 ≤ l ≤ 1024. q is a prime divisor of p − 1 and g is an element of order q in Zq . step 1 In advance all Si randomly pick two random secrets k, and a from two (tn , n) secret sharing schemes in Zq [18]. The resulting shares held by Si

6

Stumpf et al.

AA Ticket, blinded IVC shares (3)

Authorization Request (1)

Ticket (2)

ICS ICS ...

Blinded, signed IVC (4)

ICS

Inter vehicle event message (5)

Fig. 1. Protocol steps in SRAAC are denoted k i and ai . The Si generate a zero-sharing (2t, n) where each Si has knowledge of share bi and a (3tn , n) zero-sharing where each Si has knowledge of share ci . Each server Si then computes and broadcasts vi := [(ki ai + bi )]q and Ai := [g ai ]p to the quorum. step 2 The servers calculate v and A by shared secret interpolation from the −1 received values vi and Ai and send r := [Av ]p to the OBU. step 3 The OBU wants a public key k ∈ Zq to be signed blindly by the servers. It generates two random blinding factors α, β ∈ Zq . Then it computes r := [[r−β ]p ]q , µ := [kα]q and ρ := [rα]q . Afterwards, it computes a (t, n) secret sharing (µ1 , . . . , µn ) of µ, with public information g µi and another (t, n) secret sharing (ρ1 , . . . , ρn ) of ρ with public information hρi . The share (µi ,ρi ) is then send to each Si . See [19] for further reference on verifiable secret sharings. step 4 The quorum interpolates and stores tag := [(g µ , hρ )]q without revealing the individual shares. The blinded signature σ is generated by interpolation of σ := [k(µ + xρ)]q and send to the OBU. step 5 The OBU unblinds the signature by calculating s := [σα−1 β −1 ]q and verifies the triple (k, r, s) is a valid signature. The OBU is now in possession of an IVC certificate signed by the authorities shared DSS-key x. The ICS quorum knows tag and the ticket, which can in collusion with the AA be linked to a specific OBU. Thus a signed certificate (k, r, s) can be traced based on the verification of an undeniable signature. Again, refer to [15] for details. 3.2

Security Threats in SRAAC

In this section, we evaluate possible attacks on SRAAC as well as possible attacks on safety messages. The following attacks are possible if an attacker is able to manipulate the program code of the vehicle’s software.

Trust, Security and Privacy in VANETs

7

Arbitrary Validity Time Since the validity time of the Inter-Vehicle Communication Certificates (IVC) is chosen by the OBU, a manipulated OBU is able to insert arbitrary validity times. A manipulated vehicle can therefore specify a very long validity time, leaving the traffic authorities with no way to isolate a maliciously misbehaving OBU. This flaw has already been discussed in [14]. OBU Collusion Attack The second problem of SRAAC is a collusion attack wherein a group of manipulated OBUs communicate and generate equal IVC input parameters. The OBUs are manipulated in a way that they do not use randomised input for calculation of the keying-material for the IVC but external input, e.g., keying-material distributed by an adversary to the set of colluding OBUs. In effect this creates a set of vehicles that cannot be distinguished in case of a privacy revocation leaving the legal prosecution or the isolation of vehicle useless. Injecting False Safety Messages The SRAAC protocol offers a secure way to isolate misbehaving vehicles. Unfortunately, this process is only a reactive service and can not directly prevent that a vehicle injects malicious safety messages. An attacker might therefore manipulate his own soft- and hardware components and inject messages that are based on false or non-existing events.

4

Trusted Secure Revocable Anonymous Authenticated Inter-Vehicle Communication (T-SRAAC)

To prevent attacks that are based on tampering with the software running on the vehicles, we integrate so called Trusted Inter-Vehicle Communication Certificates (T-IVC). The underlying concept is a ticket-based remote attestation [10], which allows to ensure that a platform has received attestation and is able to proof this attribute. For this purpose, the AA verifies the trustworthiness of the vehicle’s software and issues a ticket that vouches for the trustworthiness of the vehicle’s software. This ticket is then used to obtain a T-IVC. Both issued credentials (AA ticket and T-IVC) are cryptographically bound to the attested vehicle. A vehicle is therefore only able to transfer safety messages, if his current platform configuration still matches the platform configuration from the time, as when the ticket was issued. If an adversary tampers with the software configuration of the vehicle, he is not able to transmit safety messages, since he is not able to access the keys linked to his T-IVC. 4.1

T-SRAAC Protocol

All vehicles are equipped with a Trusted Platform Module (TPM) and run a virtualization-based environment. Inside the virtualization-based environment, a measurement engine measures every compartment before execution and stores

8

Stumpf et al.

the resulting values inside the TPM. To achieve strong isolation between different software components and to isolate security-sensitive applications from non-security sensitive, every security sensitive application runs in its own compartment. For safety applications it is only required to ensure the trustworthiness of compartments that are able to alter safety related event messages. Processes of this type are the software for controlling the sensors as well as the OBU that implements the communication protocol for safety messages and is responsible for transferring safety messages. The TPM therefore only measures compartments whose processes take part in the issuance of an IVC or are involved in the creation of event messages. The TPM is embedded in our enhanced protocol for secure and privacy protected Inter-vehicle communication as shown in Figure 2. For the sake of simplicity not all steps of the SRAAC protocol of Section 3.1 are integrated in this Figure. To obtain an IVC, the vehicle must prove that his platform configuration is in a trusted system state. For this purpose, the TPM creates an asymmetric key-pair that is directly bound to its platform configuration by specifying the PCRs that include the measured compartments that are involved in Inter-vehicle communication (step 1). The TPM then generates an asymmetric key pair using the physical random number generator of the TPM, encrypts this key with the Storage Root Key (SRK), and transfers the encrypted package (i.e., public key (PK) and encrypted secret key (SK’)) to the OBU (steps 2-4). The public part of the generated key is then signed with an attestation identity key (AIK) of the TPM. This proves that the corresponding key-pair is held in the protected storage of a valid TPM and that the generated key is bound to a set of PCRs (steps 5-7). The OBU then transfers the stored measurement log (SML), the AIK-Credential (CertIK ), the certificate of the generated key (CertP K ) and authentication data to the AA. After the OBU has been authenticated, the AA verifies whether the platform configuration the CertP K is bound to is trusted, based on the received SML and the received credentials. If the platform configuration is trusted, i.e. the involved isolated compartments are untampered, the AA issues a ticket which is signed by the private key of the AA and contains the PK and a timestamp (steps 9-11). The ticket is then transferred to the vehicle and encrypted with the PK (step 12). The OBU of the vehicle transfers the encrypted package to the TPM for encryption (step 13). The TPM is able to decrypt this package if the current platform configuration still matches the platform configuration when the key was first generated (steps 14-17). The TPM then generates and cryptographically binds a second key pair which is later used as public key for the certificate. Please note, that the PK can not be used for that purpose, since this key won’t allow a privacy protected and pseudonymous communication with vehicles. The generated key is encrypted with the SRK and transferred to the OBU (steps 19-21). The generated public key (IVC-PK ) is then blinded using blinding factors α and β ∈ Zq (r := [[r−β ]p ]q , µ := [kα]q and ρ := [rα]q ) and transferred together with the decrypted ticket to the ICS (step 22, Compare step 3 of Section 3.1). The different ICS then execute the quorum based blinded signature phase

Trust, Security and Privacy in VANETs

9

as introduced in Section 3.1 on this ticket and transfer the created and still blinded T-IVC back to the vehicle (steps 24-25). Note that this blinded T-IVC is encrypted with the certified PK of the vehicle. It can therefore only be decrypted if the vehicle still matches the initial platform configuration (steps 25-39). The vehicle can now unblind the blinded T-IVC and is now in possession of a T-IVC credential.

Vehicle ICSn

OBU

AA

TPM

Create Binding Key (PCRs[0.23]) (1)

PK and SK’ (4)

Generate SK and PK (2) SK’ =encryptSRK[SK] (3)

Certify Key (PK) (5) CertPK=SignIK [PK] (6) Validate CertIK , CertPK (9) Verify Platform Configuration (10) Create Ticket: T= signAA[Timestamp, PK] (11)

CertIK and CertPK ,SML (8)

CertPK (7)

{T}PK (12)

Decrypt[{T}PK, SK’] (13)

T (17)

Verify Platform Configuration (14) SK=Decrypt[SK’, SRK] (15) Decrypt(Encrypt[T, SK’], SK) (16)

Create Binding Key (PCRs[0.23]) (18)

T, blinded(IVC-PK) (22) Validate T Create T-IVC (23): T-IVC = signICS[blinded(IVC-PK)]

{T-IVC}PK (24)

IVC-PK and IVC-SK’ (21)

Generate IVC-SK and IVC-PK (19) IVC-SK’ =encryptSRK[IVC-SK] (20)

Decrypt[{T-IVC}PK, SK’] (25)

blinded(T-IVC) (29)

Verify Platform Configuration (26) SK=Decrypt[SK’, SRK] (27) Decrypt({T-IVC}PK, SK) (28)

Fig. 2. Trusted SRAAC

All event messages are signed with the secret key (IVC-SK ) that corresponds to a T-IVC. Since this secret key is protected by the TPM and bound to a specific platform configuration, a vehicle can only create event messages if its configuration is still in the same state as when the configuration was first verified. The signed event messages are then verified by another vehicle using the transferred T-IVC. Every OBU has to know the public key of the ICS and is thus able to verify the signature of a received IVC. 4.2

T-IVC Certificate

The T-IVC is a credential that proves that the OBU is authorised by the traffic authorities to emit event messages. The corresponding RSA secret key is used to sign every safety message. Since any verification must be self-contained and autonomous, no communication to any other third instance is possible. This leads

10

Stumpf et al.

to the fact, that neither the Online Certification Status Protocol nor Certificate Revocation Lists can be used. The link between a T-IVC and the certification process where the T-IVC was obtained can only be established by a quorum of t ICS. The certification process can than be linked to a vehicle identity by the AA. A T-IVC comprises of the following data. – – – –

5

The generated TPM RSA public key IV C − P K A validity time, validity A DSS signature (r, s) on the hash-value of the complete certificate The public keys of the DSS signature (y, g, p, q)

Discussion

T-SRAAC enables privacy protected vehicular communication with the ability to revoke privacy. This revocation is protected against misuse by the enforcement of the many-eye-principle through a secret sharing scheme. The authorities are able to isolate an OBU and deny the authorization for further message emission through privacy revocation. Isolation is enforced by the Authentication Authority by refusing to provide new tickets. We will now provide an analysis of the threats that exists in inter-vehicle communication and will show how these threats are prevented by our protocol. This analysis is based on a classification of attackers and resulting attacks in Inter-vehicle communication as introduced in [20]. For this purpose, attackers are classified in four groups. Group 1 has a programmable radio transmitter/receiver. Group 2 has access to an un-modified OBU and can manipulate certain inputs, e.g., sensors. Group 3 controls a modified OBU and can obtain some keying material. Group 4 attackers have access to “records and equipment“ of the infrastructure operators. T-SRAAC directly hinders attackers of group 3 and 4. Group 4 attackers need to control at least t of n ICS to revoke the privacy of given certificates. T-SRAAC thus allows a controlled risk against group 4 by choosing appropriate t and n. Attackers of class 3 are not able to access keying material, since the TPM prevents a modified OBU from using protected keys. Attackers of group 1 are countered by authorization of event messages. A particular vehicle is only able to transfer safety messages, if the validity time of the issued T-IVC is still valid and if the vehicle’s software is still in the same system state as when the ticket was first issued. This mechanism prevents that a vehicle owner is able to transfer safety messages after he has tampered with his vehicle’s software. The verification of the trustworthiness of the vehicle’s software ensures that the OBU uses the physical random number generator of the TPM for key generation and that the OBU does insert arbitrary validity times of the T-IVC. To circumvent this mechanism, an adversary might try to compromise his OBU after he has received a ticket that vouches for his trustworthiness. However, this attack is not successful since the adversary must reboot his OBU for this purpose, which on the other hand results in the fact that the knowledge

Trust, Security and Privacy in VANETs

11

of the ticket will be lost. An attacker is also not able to relay the obtained T-IVC to other vehicles, since this certificate is directly bound to a specific TPM and therefore only useable by a particular vehicle. Finally, if an attacker of class 2 manipulates input to a vehicle’s sensors, an attack that cannot be prevented within a communication protocol, the vehicle can be isolated within appropriate time. The maximum isolation time interval is a parameter controlled by the traffic authorities through the validity time of a T-IVC.

6

Related Work

This paper shares most of the security objectives defined by the Vehicle Safety Communications Project in [21]. The main differences are, that we avoid the use of CRLs, we introduce scalable protection against misuse by single, compromised authorities as well as strong protection against OBU manipulation. The majority of related papers agree on the tight constraints on time and bandwidth during Inter-Vehicle safety Communication. Other works not only focus on car-to-car communication, but T-SRAAC can be extended to car-toinfrastructure safety communication as well. Privacy is, among secured and robust communication, a main problem in many papers [22]. Untraceability in vehicular ad hoc networks is topic of various works. In [23] the effectiveness of pseudonym changes is analysed as success rate of an attacker. The size of the set of possible itineraries under different context information is calculated in [24]. In [13] the anonymity set of a certain vehicle at a certain time is used as measure for unlinkability. Virtualization has already been identified to increase the safety of independent software systems running on a vehicle [25]. This property allows to increase the availability and decreases the vulnerability of systems to errors. Scheibel et al. present an architecture for vehicular software protection in [8]. This architecture is based on the L4 microkernel and also makes use of the TPM to ensure that data that is transferred to a vehicle is bound to a particular software configuration. Similar to our approach, this work uses a key that is bound to a certain platform configuration. However, Scheibel et al. does not focus on safety messages and does not show how the TPM could be used for this purpose. Besides hardware-based attestation methods, a number of software-based approaches have been presented [26,27,28] which rely on optimal program code and exact time measurements. These approaches enable software-based attestation by introducing an optimal program verification process that verifies the memory of a platform by calculating hash values of randomly selected memory regions. However, adapting these techniques in Inter-vehicle communication would become very challenging, since these techniques do not allow to bind a cryptographic key to a certain platform configuration.

12

Stumpf et al.

7

Conclusion

We have presented a multi-layered security protocol that allows a vehicle to receive certificates which are used for transferring traffic safety messages. For this purpose, we have combined a protocol that provides privacy and authorization with concepts that allow to ensure that the software of a particular is in a trusted state. Based on these both concepts, we can ensure that (i) the vehicle’s identity and the personal privacy of vehicle owners is protected even against single malicious certification server and (ii) that transferring safety messages is only possible if the vehicle’s software has not been tampered with. Both properties are of high security concern, since it must be prevented that malicious safety messages are injected into the network and that a vehicle and its owner can be tracked. Our protocol combines different types of signature schemes. While the TPM is only able to generate RSA signatures, our SRAAC protocol uses the Digital Signature Standard (DSS) [16]. However, although that both signatures can be combined, it might not be very practical to use two different cryptographic approaches to create and verify a signature. Another aggravating factor is that the creation of one 1024 bit signature on a representative TPM takes about 62ms [29], which might be not fast and small enough to be practical. Introduction of faster and smaller cryptographic schemes to the TPM are probably needed to use it in the vehicular context. In the future, we are going to work on these issues and try to analyse the overhead and gain introduced through both concepts.

8

Acknowledgments

This work was funded in part by the German Research Foundation (DFG) under grant EC 163/4-1, project TrustCaps.

References 1. Kargl, F., Ma, Z., Schoch, E.: Security engineering for vanets. In: 4th Workshop on Embedded Security in Cars (ESCAR 2006). (2006) 2. consisting of BMW, T.C.V.S.C.C., DaimlerChrysler, Ford, GM, Nissan, Toyota, VW: Vehicle safety communications project task 3 final report identify intelligent vehicle safety applications enabled by dsrc. Technical report, National Highway Traffic Safety Administration, U.S. Department of Transportation (2005) 3. Papadimitratos, P., Gligor, V., Hubaux, J.P.: Securing vehicular communications - assumptions, requirements, and principles. In: 4th Workshop on Embedded Security in Cars (ESCAR 2006). (2006) 4. Stumpf, F., Tafreschi, O., R¨ oder, P., Eckert, C.: A Robust Integrity Reporting Protocol for Remote Attestation. In: Second Workshop on Advances in Trusted Computing (WATC’06 Fall). (2006) 5. Trusted Computing Group: Trusted Platform Module (TPM) specifications. Technical report, https://www.trustedcomputinggroup.org/specs/TPM (2006)

Trust, Security and Privacy in VANETs

13

6. Brickell, E., Camenisch, J., Chen, L.: Direct Anonymous Attestation. In: CCS ’04: Proceedings of the 11th ACM Conference on Computer and Communications Security, New York, NY, USA, ACM Press (2004) 132–145 7. Linnemann, M., Pohlmann, N.: Die vertrauensw¨ urdige sicherheitsplattform turaya. In: DACH Security 2006, Patrick Horster, syssec Verlag (2006) 8. Scheibel, M., St¨ uble, C., Wolf, M.: Design and implementation of an architecture for vehicular software protection. In: Embedded Security in Cars Workshop (ESCAR ’06). (2006) 9. Berger, S., C´ aceres, R., Goldman, K.A., Perez, R., Sailer, R., van Doorn, L.: vtpm: virtualizing the trusted platform module. In: USENIX-SS’06: Proceedings of the 15th conference on USENIX Security Symposium, Berkeley, CA, USA, USENIX Association (2006) 21–21 10. Stumpf, F., Benz, M., Hermanowski, M., Eckert, C.: An Approach to a Trustworthy System Architecture using Virtualization. In: Proceedings of the 4th International Conference on Autonomic and Trusted Computing (ATC-2007). Volume 4158 of Lecture Notes in Computer Science., Hong Kong, China, Springer-Verlag (2007) pp. 191–202 11. Pfitzmann, A., Hansen, M.: Anonymity, unlinkability, unobservability, pseudonymity, and identity managment - a consolidated proposal for terminology. Technical Report v0.27, TU-Dresden (2006) 12. Raya, M., Hubaux, J.P.: The security of vehicular ad hoc networks. In: SASN ’05: Proceedings of the 3rd ACM workshop on Security of ad hoc and sensor networks, New York, NY, USA, ACM Press (2005) 11–21 13. Sampigethaya, K., Huang, L., Li, M., Poovendran, R., Sezaki , K.M.K.: Caravan: Providing location privacy for vanet. In: 3rd Workshop on Embedded Security in Cars (ESCAR 2005). (2005) 14. Fischer, L., Aijaz, A., Eckert, C., Vogt, D.: Secure revocable anonymous authenticated inter-vehicle communication (sraac). In: ESCAR 2006 - Embedded Security in Cars. (2006) 15. Jakobsson, M., Yung, M.: Distributed “magic ink” signatures. In: Advances in Cryptology - Proceedings of Eurocrypt ’97. Volume 1233. (1997) 450–?? 16. of Standards, U.D.O.C.I., Technology: Digital signature standard (dss). Technical report (2000) 17. National Institute of Standards and Technology (NIST): DIGITAL SIGNATURE STANDARD (DSS). (2000) 18. Shamir, A.: How to share a secret. Commun. ACM 22 (1979) 612–613 19. Choc, B., Goldwasser, S., Micali, S., Awerbuch, B.: Verifiable secret sharing and achieving simultaneity in the presence of faults. In: Proceedings of the Annual Symposium on Foundations of Computer Science. (1985) 383–395 20. Aijaz, A., Bochow, B., D¨ otzer, F., Festag, A., Gerlach, M., Kroh, R., Leinm¨ uller, T.: Attacks on intervehicle communication systems - an analysis. In: Proceedings of the 3nd International Workshop on Intelligent Transportation, Hamburg, Germany (2006) 21. US Department of Transportation, National Highway Traffic Safety Administration (NHTSA): Vehicle Safety Communications Project: Final Report, Appendix H: WAVE/DSRC Security. (2005) 22. Doetzer, F.: Privacy issues in vehicular ad hoc networks. In: Workshop on Privacy Enhancing Technologies, Cavtat, Croatia (2005) 23. Butty´ an, L., Holczer, T., Vajda, I.: On the effectiveness of changing pseudonyms to provide location privacy in vanets. In: Proceedings of the Fourth European

14

24. 25. 26.

27.

28.

29.

Stumpf et al. Workshop on Security and Privacy in Ad hoc and Sensor Networks (ESAS2007), Springer (2007) Franz, M., Meyer, B., Pashalidis, A.: Attacking unlinkability: The importance of context. In: Proceedings of the Privacy Enhancing Technologies 2007. (2007) Elphinstone, K., Heiser, G., Huuck, R., Petters, S.M., Ruocco, S.: L4cars. In: Embedded Security in Cars (ESCAR 2005) Workshop. (2005) Seshadri, A., Perrig, A., van Doorn, L., Khosla, P.: SWATT: Software-based attestation for embedded devices. In: IEEE Symposium on Security and Privacy. (2004) Seshadri, A., Luk, M., Shi, E., Perrig, A., van Doorn, L., Khosla, P.: Pioneer: Verifying Code Integrity and Enforcing Untampered Code Execution on Legacy Systems. In: SOSP ’05: Proceedings of the twentieth ACM symposium on Operating systems principles, New York, NY, USA, ACM Press (2005) 1–16 Seshadri, A., Luk, M., Perrig, A., van Doorn, L., Khosla, P.: SCUBA: Secure Code Update By Attestation in sensor networks. In: WiSe ’06: Proceedings of the 5th ACM workshop on Wireless security, New York, NY, USA, ACM Press (2006) 85–94 STMicroelectronics: St19wp18-tpm-c trusted platform module (tpm). Technical report (2004)