A Privacy Aware and Efﬁcient Security Infrastructure

for Vehicular Ad Hoc Networks

Klaus Pl

oßl and Hannes Federrath

University of Regensburg, 93040 Regensburg, Germany

Abstract. VANETs have the potential to dramatically increase road safety by

giving drivers more time to react adequately to dangerous situations. To prevent

abuse of VANETs, a security infrastructure is needed that ensures security re-

quirements like message integrity, conﬁdentiality, and availability. After giving

more details on the requirements we propose a security infrastructure that uses

asymmetric as well as symmetric cryptography and tamper resistant hardware.

While fulﬁlling the requirements, our proposal is especially designed to protect

privacy of the VANET users and proves to be very efﬁcient in terms of computa-

tional needs and bandwidth overhead.

1 Introduction

The term vehicular ad hoc network (VANET) is used for a subgroup of mobile ad hoc

networks (MANETs, deﬁned in [1]). The distinguishing property of the VANET is that

it is formed mainly by vehicles. This implies that node movement is restricted by factors

like road course, encompassing trafﬁc and trafﬁc regulations. Because of the restricted

node movement it is a feasible assumption that the VANET will be supported by some

ﬁxed infrastructure that assists with some services and can provide access to station-

ary networks [2]. The ﬁxed infrastructure will be deployed at critical locations like

slip roads, service stations, dangerous intersections or places well-known for hazardous

weather conditions.

Nodes are expected to communicate by means of North American DSRC standard

[3] that employs the IEEE 802.11p standard for wireless communication. To allow com-

munication with participants out of radio range, messages have to be forwarded by other

nodes (multi-hop communication). Vehicles are not subject to the strict energy, space

and computing capabilities restrictions normally adopted for MANETs [4]. More chal-

lenging is the potentially very high speed of the nodes (up to 250 km/h) and the large

dimensions of the VANET.

The primary VANET’s goal is to increase road safety. To achieve this, the vehicles

act as sensors and exchange warnings or – more generally – telematics information

(like current speed, location or ESP activity) that enables the drivers to react early to

abnormal and potentially dangerous situations like accidents, trafﬁc jams or glaze. In

addition, authorized entities like police or ﬁreﬁghters should be able to send alarm sig-

nals and instructions e.g. to clear their way or stop other road users. Besides that, the

VANET should increase comfort by means of value-added services like location based

services or Internet on the road [5].

Plößl K. and Federrath H. (2007).

A Privacy Aware and Efﬁcient Security Infrastructure for Vehicular Ad Hoc Networks.

In Proceedings of the 5th International Workshop on Security in Information Systems, pages 145-154

DOI: 10.5220/0002419901450154

 SciTePress

These three application categories (“warnings and telematics information” (W),

“alarm signals and instructions” (A), and “value-added services” (V)) imply different

security and privacy requirements with respect to the protection goals integrity, conﬁ-

dentiality and availability. Nevertheless, there is a common need for a security infras-

tructure establishing mutual trust and enabling cryptography. The security infrastructure

therefore includes all technical and organizational measures and facilities needed. After

deﬁning the requirements for any such security infrastructure (section 2) we present a

new proposal (section 3) that particularly aims to protect privacy of the participants and

is designed to be very efﬁcient in terms of computing capabilities and communication

bandwidth. Our system is evaluated in section 4. Section 5 outlines our conclusion and

future work.

2 Security Requirements

In this section we explain the requirements for a VANET security infrastructure. If nec-

essary, we distinguish between the three application categories W, A, and V as deﬁned

in section 1. The requirements are summarized in table 1.

2.1 Integrity

The security infrastructure has to provide mechanisms that prevent or at least detect

message modiﬁcation (I1). This hinders malicious nodes from modifying forwarded

messages and protects message integrity for all application categories.

Alarm signals and instructions sent from authorized nodes like police cars, ﬁre en-

gines or ambulances have to be obeyed by the addressees. Therefore, the authenticity

and integrity of the message as well as the authorization of the sender must be prov-

able instantly without further information (I2a). In contrast, for warnings and telematics

messages plausibility checks can be conducted by means of in car sensors or messages

received from other VANET nodes. Hence no unchangeable and unique identity would

be necessary in this case. Moreover, to hamper movement proﬁle creation it would be

preferable to cloak sender identity especially in periodically sent messages (P1). Never-

theless, ex post accountability and non-repudiation is necessary to be able to prosecute

misuse of the VANET like injection of bogus information (I2b). Therefore anonymous

participation should not be allowed, pseudonymous participation is desirable.

This ex post identiﬁcation must only be allowed in severe cases like accidents with

death results or sending bogus warnings. Automated trafﬁc surveillance or automated

prosecution – e.g. based on the sent telematics data – must not be allowed with regard to

multilateral security (P2). Multilateral security means taking the interests of all parties

involved into account. In this case, interests of law enforcement (to prosecute each vio-

lation of law with as few effort as possible) have to be balanced with interests of citizens

(not to be monitored regardless of whether a suspicion exists). It is an interesting ques-

tion how to deﬁne what such severe cases of VANET abuse are. Nevertheless, it will not

be answered here because we focus on the technical details of the security infrastruc-

ture. We assume that in-car sensor data is correct. Additionally, we expect integration of

146

Table 1. Requirements.

I1 Data integrity

I2a Immediate sender authentication

I2b Ex post accountability

C1 Different levels of conﬁdentiality

C2 Protection of the security infrastructure

P1 Protection against proﬁle generation

P2 Protection against surveillance

A1 Computational and bandwidth efﬁciency

correct time and position information in all messages to protect against replay and po-

sition spooﬁng attacks. This information is available from an infrastructure like Galileo

[6].

2.2 Conﬁdentiality

Conﬁdentiality requirements vary heavily between the three application categories. While

conﬁdentiality of alarm signals is negligible in most cases, it can e.g. be crucial for ser-

vices subject to costs. The security infrastructure therefore has to provide mechanisms

that support different levels of conﬁdentiality (C1). For example these levels could be

no conﬁdentiality, conﬁdentiality against outsiders and conﬁdentiality against all except

direct communication partners.

Besides application data administrative messages like routing protocol information

or messages containing cryptographic material have to be protected against eavesdrop-

ping. Also, the cryptographic information held by participants or centralized instances

has to be protected against unauthorized access. More generally, the security infrastruc-

ture has to be protected against attacks (C2).

2.3 Availability

Because most VANET messages are related to driving conditions and road safety, real-

time processing of these messages is crucial. To be able to fulﬁll the above integrity and

conﬁdentiality requirements VANET nodes have to carry out additional cryptographic

operations that extend message processing. Mechanisms to protect message integrity

increase the message length. To satisfy the given real-time constraints the mechanisms

of the security infrastructure must be as efﬁcient as possible in terms of computational

and bandwidth needs (A1). Despite the fact that there is no feasible protection against

jamming attacks [7] actions must be taken that complicate denial-of-service attacks and

therefore increase availability.

3 Proposal

In this section we present our proposal for a VANET security infrastructure that is de-

signed to be very efﬁcient in terms of computing capabilities and communication band-

147

width while fulﬁlling all security and privacy requirements. After a once-only initial-

ization it employs asymmetric cryptography within a public key infrastructure (PKI) for

messages inﬂuencing road safety. All other messages (especially the periodically sent

telematics messages) are protected by a system employing symmetric cryptography that

is much faster and protects privacy of the participants better than the asymmetric part.

After outlining our proposal in section 3.1 we give some more details on the once-only

initialization (3.2) and the symmetric system part (3.3). Figure 1 shows a VANET with

the different message types.

Internet

B:Beacon

SI:Stopinstruction

AW:Accidentwarning

LBS:Locationbasedservice

fwd:forwardedmessage

Symmetriccryptography

Asymmetriccryptography

Legend

LBS

AW (fwd)

(

)

(

)

:Supportinginfrastructure

Police

Accident

Fig.1. VANET with different message types.

3.1 Outline and Asymmetric Part

In the asymmetric part of the VANET we employ a PKI with vehicle-related identities

(VRI) in form of a private key and a corresponding certiﬁcate. The certiﬁcates are is-

sued by a certiﬁcation authority (CA) in each country that should be operated by the

governmental transportation authority (GTA). We suggest a VRI issued by the GTA

because of the following reasons:

– A VRI is the digital equivalent of the current situation: The license plate is a ﬁxed

pseudonym for the owner of the vehicle and only GTA can link the pseudonym

with the real world identity of the owner. The driver is not known for sure but this

is consistent with current legislation in most countries.

– The GTA is already known and somewhat trusted by the citizens.

– Employing GTA as CA would – at least in the EU – be cost efﬁcient because the

digital tachograph system demands that each member country has a CA issuing cer-

tiﬁcates used in the digital tachograph hardware [8]. In other words most European

GTAs already operate a CA.

148

Each vehicle stores its VRI and at least the root certiﬁcate of the country CA in

tamper resistant hardware (TRH). For warnings integrity and authenticity is ensured

(req. I1, I2a/b) by adding a digital signature and the sending node’s certiﬁcate (see ﬁg.

2). The recipient can check the signature and the identity of the sender included in the

certiﬁcate

. Because warnings are sent very seldom and only distributed to a small geo-

graphical region they can not be used to generate movement proﬁles. Therefore digitally

signing warnings does not harm privacy of the driver in an unacceptable manner.

Data with address information Digital Signature CERT

Fig.2. Message with asymmetric protection.

People with special privileges like police ofﬁcers additionally get individual-related

identities (IRI), in form of a private key and a corresponding certiﬁcate stored on a

smart card. To be able to use their special privileges the certiﬁcate of the sending vehi-

cle and the certiﬁcate of the driver have to be submitted to the CA. After checking the

two certiﬁcates, the CA issues a certiﬁcate (and corresponding key pair) that includes

attributes that grant authorization to send a deﬁned set of alarm signals and/or instruc-

tions. This certiﬁcate is valid e.g. for eight hours (one shift) and used to add a digital

signature to alarm signals and instructions. Recipients can check message integrity and

authorization of the sender instantly and do not have to check revocation information

due to the short validity of the certiﬁcate (req. I1, I2a).

Taking into account performance (req. A1) and privacy requirements (req. P1, P2)

it is not desirable to digitally sign all messages

with the vehicles certiﬁcate. Therefore

geographically distributed trusted third parties (GTTPs) are employed which enable

pseudonymous participation in the VANET as well as message encryption and authenti-

cation within their assigned geographical regions by means of symmetric cryptography.

The participation in the symmetric protected part of the VANET requires communica-

tion with a GTTP from time to time. If a VANET node is not able to contact his GTTP

he has to use asymmetric cryptography and cannot decrypt or verify messages protected

with symmetric cryptography. We want to point out that any VANET participant is able

to participate in the asymmetric part of the VANET after the once-only initialization.

This means he can understand and send safety critical VANET messages even if he is

never able to communicate with a GTTP. We give more details on the symmetric part

after explaining the once-only initialization phase.

If the sending vehicle’s certiﬁcate was issued by another country CA, cross-certiﬁcates are

needed.

Especially the periodically sent telematics information including current position and speed

could easily be abused to create movement proﬁles. In addition, these so-called beacons are

sent very often (approximately every 10 to 300 ms [9, 2]) what results in a lot of computational

and bandwidth overhead.

149

3.2 Initialization

At production time each vehicle is equipped with TRH that cannot be removed without

being destroyed. Then the car manufacturer installs the root certiﬁcate (CERT

Root

) of

the GTA the vehicle is sold to – e.g. CERT

Root

for Germany – and a symmetric key.

The symmetric key is also saved on a smart card. This pre-shared key is used to encrypt

communication between TRH and the smart card (req. C2).

Vehicle manufacturer:

- Installation of TRH

- Store CERTRoot

in TRH

- Store pre-shared key in TRH

and smart card

Owner of vehicle A:

- Generation of SKTRH

and PKTRH

- Physical deactivation of SKTRH

and

PKTRH

generation function

- Generation of SKSC

and PKSC

and transfer

to smart card

- Check and probably installation of CERTRoot

After registration:

- Installation of CERTTRH

Local admission office:

- Read PKTRH

- Check owner identity

- Verify physical deactivation of key pair generation

- Register data with GTA

GTA:

- Issue CERTTRH

Fig.3. Once-only initialization process.

After receiving his new vehicle (and the smart card) the customer connects the smart

card to the TRH and starts the initialization process. TRH checks connection to the

smart card and generates two asymmetric key pairs. One is used as VRI and is saved in

TRH (e.g. PK

T RH

and SK

T RH

for vehicle A). TRH ensures that only one key pair

can be saved and the secret key (SK

T RH

) never leaves TRH (req. C2). The second

key pair is digitally signed with the ﬁrst one and saved on the smart card. This key pair

(P K

and SK

) is used to authenticate the owner. Conﬁguration changes like

saving new or deleting old root certiﬁcates in TRH are allowed only after authentication

with the smart card. This ensures that only the owner is authorized to change the TRH

conﬁguration. If the vehicle is sold the new owner can generate a new key pair and

delete the old one.

If there are no errors in the initialization process the possibility to generate a TRH

key pair (P K

T RH

and SK

T RH

) has to be physically destroyed (e.g. by melting a

fuse after key-pair generation). This ensures that VRI cannot be changed any more (at

least until TRH is removed; partly req. I2a/b). Demanding that the owner generates the

key pair ensures that vehicle manufacturers do not know VRIs of their vehicles (partly

req. P1).

150

The VRI then is registered with the GTA in the normal registration process of a new

vehicle at the local admission ofﬁce. This means the local admission ofﬁce has to read

P K

T RH

and must check that key pair generation is deactivated. Then it saves VRI

within the existing GTA registers and therefore is able to link VRI to owner identity.

Then GTA issues a certiﬁcate (CERT

T RH

) that is saved in vehicle’s TRH. TRH can

check validity by means of the stored root certiﬁcate (CERT

Root

). Communication

between the local admission ofﬁce and GTA has to be protected by the usual means of

network security like ﬁrewalls, VPNs, etc. (req. C2) and shall not be discussed here.

The fact that the owner can check and store root certiﬁcates in TRH ensures that ve-

hicle manufacturers or maintenance personal is not able to operate their own certiﬁcate

hierarchy by installing own root certiﬁcates in TRH (req. C2). On the other hand, the

owner has to be made responsible for correct conﬁguration of root certiﬁcates. Fig. 3

shows the initialization process.

3.3 Symmetric Part

As already mentioned, beacons and messages of the value-added services are protected

by means of symmetric cryptography. To be able to participate, node A uses a challenge

response protocol and CERT

T RH

to authenticate to the local GTTP. To increase avail-

ability, GTTP should be reachable via the VANET as well as via other communication

infrastructures like GSM. GTTP has to be independent from law enforcement and GTA

(see later). After authenticating itself GTTP issues a pseudonym P A and an associated

symmetric key k

M AC

P A

that is unique to the VRI for a certain period of time and stores

the relation between VRI and P A. It also issues the symmetric keys k

M AC

ALL

and k

These are the same for all VANET users in a certain geographic region and a certain

time period. TRH ensures that the symmetric keys are kept secret (req. C2). The ex-

change of the symmetric keys has to be encrypted. The necessary encryption keys can

for example be generated by a Difﬁe-Hellman key exchange after mutual authentica-

tion. Varying levels of conﬁdentiality can easily be achieved by additionally encrypting

the sent data with keys based on VRI or other service speciﬁc certiﬁcates (req. C1).

Messages are assembled inside the TRH. First P A is added after the data to be sent.

Then a message authentication code (M AC

) computed with k

M AC

P A

is added, fol-

lowed by M AC

computed with k

M AC

ALL

. The whole message is encrypted with k

(see ﬁg. 4). Outsiders not participating in the VANET are not able to see any identity

or data, because messages are encrypted. Proﬁle generation and eavesdropping from

outsiders therefore is prevented (req. C1, P1). To hinder proﬁle generation by VANET

participants GTTPs can assign a number of pseudonyms to a vehicle that are changed

frequently. Additionally, the pseudonyms are just valid for a short time interval. Af-

ter that time interval a given pseudonym could belong to another vehicle what makes

linking of pseudonyms to generate a movement or service usage proﬁle pretty hard.

VANET participants (or more precisely their TRH) are able to decipher messages

with the help of k

and check integrity using M AC

computed with k

M AC

ALL

(req.

I1). Ex post accountability (req. I2b) is ensured by employing MAC

computed with

M AC

P A

. Only TRH of the sending vehicle and GTTP know k

M AC

P A

. Therefore,

(only) GTTP can conﬁrm if a given message is really from the claimed sender by check-

ing M AC

. This only works if all computations are carried out in TRH and nobody is

151

Data with address information PA MAC with k MAC with k

ciphered with k

Fig.4. Message with symmetric protection.

able to get to know the symmetric keys or inﬂuence message construction. Therefore it

is crucial to design TRH with a self-destruction mechanism that is activated if anybody

is trying to manipulate the TRH (req. C2).

Req. P2 (protection against surveillance) is accomplished by employing indepen-

dent GTTPs that have to follow strict procedures before revealing the VRI associated

with a given pseudonym at a certain time. Only with this VRI law enforcement is able to

ﬁnd the owner of the vehicle by using the GTA register. We want to point out that while

achieving non-repudiation privacy is protected. Trust is distributed between GTTPs and

GTA: GTTPs do not know the real identities of the vehicle owners, GTA does not know

the relationship between VRI and pseudonym.

4 Evaluation and Related Work

Our proposal ensures message integrity (I1) by means of digital signatures and MAC

Immediate sender authentication for alarm signals and instructions (I2a) is ensured by

using short time certiﬁcates that can be linked to a speciﬁc driver and vehicle. For all

other messages ex post accountability (I2b) is achieved by adding a digital signature

based on VRI or M AC

respectively. Protection against proﬁle generation (P1) is en-

sured by employing changing pseudonyms for frequently sent messages and messages

of value-added services. The independent GTTPs ensure that automated surveillance

is not possible (P2). Law enforcement and GTA know the VRI and the identity of the

owner but cannot link this information to a pseudonym. Only in severe cases like acci-

dents with death results GTTP has to reveal the connection between a given pseudonym

and VRI. In addition, GTTP does not know the real identity corresponding to a given

VRI. Different levels of conﬁdentiality (C1) can be used by encrypting message data

with VRI certiﬁcates, symmetric keys or other service speciﬁc key material. The secu-

rity infrastructure is protected (C2) by means of encrypting all key management mes-

sages and employing TRH that ensures that nobody can inﬂuence message generation

or get to know symmetric or private keys.

We now want to show the computational and bandwidth efﬁciency (A1) of our so-

lution. We assume a message length of 300 byte what is feasible for alarm signals,

warnings and beacons. For the asymmetric part we further assume the usage of RSA

with SHA-256 (key length 2048 bit). The symmetric part employs HMAC SHA-256

(key length 192 bit) and AES (key length 192 bit). According to [10] this ensures ade-

quate security till at least 2020. Pseudonyms are 48 bit in length.

If we assume the smallest possible (non standard) certiﬁcate consisting only of a

public key and a digital signature we get 2048bit + 2048bit = 4096bit. The digital sig-

nature is additional 2048bit. Summing this up (768byte) and adding the message length

we get 1068byte what translates in 768byte/1068byte = 72% security overhead. For

152

the symmetric part we get the following: P A + 2 ∗ HMAC = 48bit + 2 ∗ 256bit =

70byte. In total this is 370byte and a security overhead of just 70byte/370byte = 19%.

Key management messages are negligible because they are sent very seldom (e.g. once

a day). Revocation lists are not needed because of employing short time certiﬁcates for

alarm signals and instructions as well as the possibility to check plausibility of warnings

by means of in-car sensor data and messages received by other VANET participants. Re-

call that far the most messages exchanged are beacons (approximately every 10 to 300

ms). These are protected by symmetric cryptography that is very efﬁcient in terms of

additional security overhead compared to messages protected by asymmetric cryptog-

raphy. Using a middle class PC-system we found that the symmetric part is faster than

the asymmetric part by a factor of approximately 600.

There are only few proposals for VANET security infrastructures so far. Most re-

searchers ([2, 11, 12]) propose a PKI solution, with anonymous or pseudonymous cer-

tiﬁcates issued by the CA. This solutions add digital signatures to each message and

do not provide encryption of messages. The main drawbacks in comparison to our so-

lution are that VANET participants have to ultimately trust the CA and computational

needs and bandwidth overhead are enormous (remember the numbers above). In addi-

tion, up to date revocation information is necessary. Due to the fact that messages are

not encrypted even outsiders can eavesdrop and possibly create movement proﬁles. [13]

suggest a system based on symmetric cryptography. The main problem of this proposal

is that the vehicles have to contact a base station to decrypt and verify messages what is

not feasible taking into account the real-time demands and the very high mobility in the

VANET. Some other authors ([14–16]) outline security and privacy issues in VANETs

but do not present a security infrastructure.

5 Conclusion and Further Aspects

After motivating why some kind of security infrastructure is needed in a VANET, we

discussed requirements like message integrity and non-repudiation for such infrastruc-

tures. In section 3 we made a proposal how a security infrastructure could be constructed

that uses asymmetric as well as symmetric cryptography and tamper resistant hardware

to fulﬁll the requirements. While fulﬁlling all requirements our proposal is especially

designed to protect privacy of the VANET users and proved to be very efﬁcient in terms

of computational needs and bandwidth overhead (see sec. 4).

In our future work we will reﬁne the proposal and discuss issues like the best sched-

ule for changing the symmetric keys and pseudonyms. In addition, the best size of the

geographic regions for the GTTPs will be determined by employing simulations.

References

1. Munoz, J., Syracuse, N.: Proc. of the 53. internet engineering task force (2002)

2. Raya, M., Hubaux, J.P.: The security of vehicular ad hoc networks. In: Proceedings of SASN

2005, ACM (2005)

3. IEEE: (Dedicated Short Range Communication Standard (DSRC))

http://grouper.ieee.org/groups/scc32/dsrc/namerica/.

153

4. Tian, J., Coletti, L.: Routing approach in cartalk 2000 project. In: Proceedings of the IST

Mobile & Wireless Communications Summit 2003. Volume 2. (2003)

5. Pl

oßl, K., Nowey, T., Mletzko, C.: Towards a security architecture for vehicular ad hoc

networks. In: Proceedings of ARES 2006, IEEE Computer Society (2006)

6. EU: The Galilei Project - GALILEO Design Consolidation (2003)

7. Xu, W., Trappe, W., Zhang, Y., Wood, T.: The feasibility of launching and detecting jamming

attacks in wireless networks. In: MobiHoc 05: Proc. of the 6th ACM internat. symposium

on Mobile ad hoc networking and computing, ACM (2005)

8. Council of the EU: Council Regulation (EC) No 2135/98 (1998)

9. Tian, J., Maihoefer, C., Nelisse, M., Provera, M., Dagli, I., Tepfenhart, M., Brenzel, C.:

Routing protocol implementation (2003)

10. Lenstra, A.K., Verheul, E.R.: Selecting cryptographic key sizes. Journal of Cryptology 14

(2001)

11. Parno, B., Perrig, A.: Challenges in securing vehicular networks. In: Proceedings of Work-

shop on Hot Topics in Networks (HotNets-IV), ACM (2005)

12. Raya, M., Papadimitratos, P., Hubaux, J.P.: Securing vehicular communications. IEEE Wire-

less Communications, Special Issue on Inter-Vehicular Communications (2006)

13. Choi, J.Y., Jakobsson, M., Wetzel, S.: Balancing auditability and privacy in vehicular net-

works. In: Q2SWinet 2005: Proc. of the 1st ACM international workshop on quality of

service and security in wireless and mobile networks, ACM (2005)

14. D

otzer, F.: Privacy issues in vehicular ad hoc networks (2005)

15. Zarki, M.E., Mehrotra, S., Tsudik, G., Venkatasubramanian, N.: Security issues in a future

vehicular network. In: Proc. of European Wireless 2002 Conference, Florence, Italy, Febru-

ary 2002. (2002)

16. Yang, H., Luo, H., Ye, F., Lu, S., Zhang, L.: Security in mobile ad hoc networks: Challenges

and solutions. IEEE Wireless Communications 11 (2004)

154