infoscience - École polytechnique fédérale de lausanne

INTRODUCTIONInitiatives to create safer and more efficientdriving conditions have recently begun to drawstrong support. Vehicular communications (VC)will play a central role in this effort, enabling avariety of applications for safety, traffic efficiency,driver assistance, and infotainment. For example,warnings for environmental hazards (e.g., ice onthe pavement) or abrupt vehicle kinetic changes(e.g., emergency braking), traffic and road con-ditions (e.g., congestion or construction sites),and tourist information downloads will be pro-vided by these systems.

Vehicular networking protocols will allownodes, that is, vehicles or roadside infrastructureunits, to communicate with each other over sin-gle or multiple hops. In other words, nodes willact both as end points and routers, with vehicu-lar networks emerging as the first commercialinstantiation of the mobile ad hoc networkingtechnology.

The self-organizing operation and the uniquefeatures of VC are a double-edged sword: a richset of tools are offered to drivers and authori-ties, but a formidable set of abuses and attacksbecomes possible. Hence, the security of vehicu-lar networks is indispensable, because otherwisethese systems could make antisocial and criminalbehavior easier, in ways that would actually jeop-ardize the benefits of their deployment. Whatmakes VC security hard to achieve is the tightcoupling between applications, with rigidrequirements, and the networking fabric, as wellas the societal, legal, and economical considera-tions. Solutions to this problem involve industry,governments, and academia, and can have abroad impact.

In this article we are specifically concernedwith the following problem: how to design and

build vehicular communication protocols andsystems that leave as little space as possible formisbehavior and abuse and, at the same time,remain resilient to ongoing attacks. We presentan analysis of the vulnerabilities of vehicular net-works and the salient challenges in securing theiroperation. Then we propose our architecturalview of how VC can be secured, along with abrief (due to space limitations) overview of novelcertificate revocation protocols tailored to theVC environment. Finally, we survey relatedworks and discuss a few open issues in thisemerging area of research.

VULNERABILITIES AND CHALLENGES

VULNERABILITIES

Any wireless-enabled device that runs a rogueversion of the vehicular communication protocolstack poses a threat. We denote such roguedevices deviating from the defined protocols asadversaries or attackers.

The adoption of a variant of the widelydeployed IEEE 802.11 protocol1 by the vehiclemanufacturers makes the attacker’s task easier.And even possession of credentials cannotensure alone the correct operation of the nodes.The effects of differing types of attackers (inter-nal or external, rational or malicious, indepen-dent or colluding, persistent or random) canclearly differ. Here, rather than analyzing specif-ic protocols, we are after a general explorationof VC vulnerabilities.

Jamming — The jammer deliberately generatesinterfering transmissions that prevent communi-cation within their reception range. As the net-work coverage area (e.g., along a highway) canbe well-defined, at least locally, jamming is alow-effort exploit opportunity. As Fig. 1 illus-trates, an attacker can relatively easily, withoutcompromising cryptographic mechanisms andwith limited transmission power, partition thevehicular network.

Forgery — The correctness and timely receipt ofapplication data is a major vulnerability. Figure2 illustrates the rapid “contamination” of largeportions of the vehicular network coverage areawith false information where a single attackerforges and transmits false hazard warnings (e.g.,ice formation on the pavement), which are takenup by all vehicles in both traffic streams.

IEEE Wireless Communications • October 20068 1536-1284/06/$20.00 © 2006 IEEE

A

A

*A enters theparking lot at time

t3*A downloadsfrom server X

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

IN T E RV E H I C U L A R CO M M U N I C AT I O N S

MAXIM RAYA, PANOS PAPADIMITRATOS, AND JEAN-PIERRE HUBAUX, EPFL

ABSTRACTThe road to a successful introduction of

vehicular communications has to pass throughthe analysis of potential security threats and thedesign of a robust security architecture able tocope with these threats. In this article we under-take this challenge. In addition to providing asurvey of related academic and industrial efforts,we also outline several open problems.

SECURING VEHICULAR COMMUNICATIONS

The road to a successful introductionof vehicular communications hasto pass through theanalysis of potentialsecurity threats andthe design of arobust security architecture able tocope with thesethreats. In this articlethe authors undertake this challenge.

RAYA LAYOUT 10/9/06 1:15 PM Page 8

brought to you by COREView metadata, citation and similar papers at core.ac.uk

provided by Infoscience - École polytechnique fédérale de Lausanne

https://core.ac.uk/display/147918225?utm_source=pdf&utm_medium=banner&utm_campaign=pdf-decoration-v1

In-transit Traffic Tampering — Any node acting as arelay can disrupt communications of other nodes:it can drop or corrupt messages, or meaningfullymodify messages. In this way, the reception ofvaluable or even critical traffic notifications orsafety messages can be manipulated. Moreover,attackers can replay messages (e.g., to illegiti-mately obtain services such as traversing a tollcheck point). In fact, tampering with in-transitmessages may be simpler and more powerfulthan forgery attacks.

Impersonation — Message fabrication, alteration, andreplay can also be used towards impersonation.Arguably, the source of messages, identified ateach layer of the stack, may be of secondary impor-tance. Often, it is not the source but the content(e.g., hazard warning) and the attributes of themessage (freshness, locality, relevance to thereceiver) that count the most. However, an imper-sonator can be a threat: consider, for example, anattacker masquerading as an emergency vehicle tomislead other vehicles to slow down and yield; oran adversary impersonating roadside units, spoof-ing service advertisements or safety messages.

Privacy Violation — With vehicular networksdeployed, the collection of vehicle-specific infor-mation from overheard vehicular communica-tions will become particularly easy. Theninferences on the drivers’ personal data could bemade, and thus violate her or his privacy.2 Thevulnerability lies in the periodic and frequentvehicular network traffic: safety and traffic man-agement messages, context-aware data access(e.g., maps, ferryboat schedules), transaction-based communications (e.g., automated pay-ments, car diagnostics), or other controlmessages (e.g., over-the-air registration withlocal highway authorities). In all such occasions,messages will include, by default, information(e.g., time, location, vehicle identifier, technicaldescription, trip details) that could preciselyidentify the originating node (vehicle) as well asthe drivers’ actions and preferences (Fig. 3).

On-board Tampering — Beyond abuse of the com-munication protocols, the attacker may select totinker with data (e.g., velocity, location, status ofvehicle parts) at their source, tampering with theon-board sensing and other hardware. In fact, itmay be simpler to replace or by-pass the real-time clock or the wiring of a sensor, rather thanmodifying the binary code implementation of thedata collection and communication protocols.Any VC security architecture should achieve atrade-off between robustness and cost due totamper-proof hardware.

CHALLENGESThe operational conditions, the constraints, andthe user requirements for VC systems makesecurity a challenging problem, with the mostsignificant challenges specific to the VC dis-cussed here.

Network Volatility — The connectivity amongnodes can often be highly transient and a one-time event. For example, two vehicles (nodes)traveling on a highway may remain within their

IEEE Wireless Communications • October 2006 9

n Figure 1. Spectrum jamming.

Jammer

Roadsidebase station

n Figure 2. Message forgery.

Roadsidebase station

Attacker

“Victims”contaminated

with false alarm

2 Secrecy of personal data, such as those, for example,stored in repositories, and message confidentiality are notspecific to VC only.


transceiver range, or within a few wireless hops,for a limited period of time. In other words,vehicular networks lack the relatively long-livedcontext and, possibly, the personal contact of thedevice users of a connection to a hot spot or therecurrent connection to an on-line service acrossthe Internet. Hence password-based establish-ment of secure channels, gradual developmentof trust by enlarging a circle of trusted acquain-tances, or secure communication only with ahandful of endpoints may be impractical forsecuring VC.

Liability vs. Privacy — To make the problem moredifficult, accountability and, eventually, liabilityof the vehicles and their drivers are required.Vehicular communication is envisioned as anexcellent opportunity to obtain hard-to-refutedata that can assist legal investigations (e.g., inthe case of accidents). This implies that, to beginwith, unambiguous identification of the vehiclesas sources of messages should be possible. More-over, context-specific information, such as coor-dinates, time intervals, and associated vehicles,should be possible to extract or reconstruct. Butsuch requirements raise even stronger privacyconcerns. This is even more so when drivers’biometrics are considered: biometrics, useful forenhancing vehicle access and control methods,

are highly private and unique data that cannotbe reset or reassigned.

Delay-Sensitive Applications — Many of the envi-sioned safety and driver-assistance applicationspose strict deadlines for message delivery or aretime-sensitive. Security mechanisms must takethese constraints into consideration and imposelow processing and messaging overhead. Notonly must protocols be lightweight, but alsorobust to clogging denial-of-service attacks. Oth-erwise, it would suffice for an adversary to gen-erate a high volume of bogus messages andconsume resources so that message delivery isdelayed beyond the application requirementsand thus, in practice, denied.

Network Scale — The scale of the network, withroughly a billion vehicles around the globe, isanother challenge. This, combined with the mul-titude of authorities governing transportationsystems, makes the design of a facility to providecryptographic keys a challenge per se. A techni-cally and perhaps politically convincing solutionis a prerequisite for any security architecture.

Heterogeneity — The heterogeneity in VC tech-nologies and the supported applications areadditional challenges, especially taking intoaccount the gradual deployment. With nodespossibly equipped with cellular transceivers, digi-tal audio and Global Positioning System (GPS)or Galileo receivers, reliance on such externalinfrastructure should not be the weakest link inachieving security. For example, if GPS signalingcan be spoofed, can the correctness of nodecoordinates and time accuracy be assumed? Sec-ond, with a range of applications with differingrequirements, security solutions must retain flexi-bility, yet remain efficient and interoperable.

SECURITY ARCHITECTURE

In this section we present the components need-ed to protect VC against a wide range of threats,some of which are described in the previous sec-tion. We also aim at providing an authentication,authorization, accounting (AAA) framework forVC. Figure 4 depicts the general architecture,the components of which are described next.

SECURITY HARDWAREAmong the vehicle onboard equipment, thereshould be two hardware modules needed forsecurity, namely, the event data recorder (EDR)and the tamper-proof device (TPD). Whereasthe EDR only provides tamper-proof storage,the TPD also possesses cryptographic processingcapabilities.

The EDR will be responsible for recordingthe vehicle’s critical data, such as position,speed, time, and so forth, during emergencyevents, and is similar to an airplane’s black box.These data will help in accident reconstructionand the attribution of liability. EDRs are alreadyinstalled in many road vehicles, especially trucks.These can be extended to also record the safetymessages received during critical events.

The car electronics, especially the data bussystem, are easily accessible by the owner or by

IEEE Wireless Communications • October 200610

n Figure 3. Vehicle tracking.

3

2

A

A

B

1

A

*A enters theparking lot at time

t3*A downloadsfrom server X

*A refuels at timet2 and location

(x2,y2,z2)

*A at (x1,y1,z1)at time t1

*A communicateswith B



a mechanic. Hence the cryptographic keys of avehicle need proper hardware protection,namely, a TPD. The TPD will take care ofstoring all the cryptographic material and per-forming cryptographic operations, especiallysigning and verifying safety messages. By bind-ing a set of cryptographic keys to a given vehi-cle, the TDP guarantees the accountabilityproperty as long as it remains inside the vehi-cle. The TPD has to be as independent as pos-sible from its external environment; hence, itshould include its own clock and have a batterythat is periodically recharged from the vehicle’selectric circuits. Yet, despite all these “fea-tures,” the TPD will still suffer from the factthat it cannot control the correctness of thedata it receives. This may result in the TPDsigning messages with bogus data. The solutionto this problem is briefly described in the“Authentication” subsection.

A major obstacle to the adoption of TPDs istheir high cost. But current products are mainlyintended for computation-hungry financial appli-cations. Hence, there are several factors that canfacilitate the introduction of TPDs in vehicles:• The creation of a “lighter” version of TPDs• The leverage on the building-up expertise for

vehicular EDRs• The economy of scale that will drive costs sig-

nificantly lower

VEHICULAR PUBLIC KEY INFRASTRUCTURE

The huge number of vehicles registered in dif-ferent countries and traveling long distances,well beyond their registration regions, requires arobust and scalable key management scheme.The involvement of authorities in vehicle regis-tration implies the need for a certain level ofcentralization. Communication via base stations(as in cellular networks) is not enough for VC,mainly because vehicles need to authenticatethemselves not only to base stations, but also toeach other (without invoking any server), whichcreates a problem of scalability. In addition,symmetric cryptography does not provide thenonrepudiation property that allows the account-ability of drivers’ actions (e.g., in the case ofaccident reconstruction or finding the originatorsof forgery attacks). Hence, the use of public keycryptography is a more suitable (if not the only)option for deploying VC security.

This implies the need for a Vehicular PublicKey Infrastructure (VPKI) where CertificateAuthorities (CAs) will issue certified public/pri-vate key pairs to vehicles (with many pairs pervehicle for privacy reasons, as is explainedbelow). Similarly to current vehicle registrationauthorities, there will be several CAs, each cor-responding to a given region (e.g., country, state,metropolitan area, etc.). Other candidates for

n Figure 4. Overview of the security architecture.

Data verification

{Position, speed,acceleration, direction,

time, safety events}

{Signer’s digital signature,signer’s public key PK,CA’s certificate of PK}

Safetymessage

Cryptographicmaterial

Authenticatedmessage

Tamperproof device

Event datarecorder

Secure positioning

Secure multihop routing

Certificate authorityService (e.g. tollpayment or

infotainment)

The huge number ofvehicles registered in

different countriesand traveling long

distances, wellbeyond their

registration regions,requires a robust and

scalable key managementscheme. The

involvement ofauthorities in vehicle

registration impliesthe need for a certain level of centralization.



taking the role of CAs are car manufacturers. Inany of the two cases, the different CAs will haveto be cross-certified so that vehicles from differ-ent regions or different manufacturers canauthenticate each other. This will require eachvehicle to store the public keys of all the CAswhose certificates it may need to verify. Alter-nately, in the case where CAs are regionalauthorities, vehicles may request new public/pri-vate key pairs delivered by the foreign region3

they enter.

AUTHENTICATIONThe fundamental security functions in VC willconsist in authenticating the origin of a datapacket. Authentication and the inherent integrityproperty counter the in-transit traffic tamperingand impersonation vulnerabilities. In addition,authentication also helps to control the autho-rization levels of vehicles.

To authenticate each other, vehicles will signeach message with their private key and attachthe corresponding certificate. Thus, when anoth-

er vehicle receives this message, it verifies thekey used to sign the message and, once this isdone correctly, it verifies the message. To reducethe security overhead, the common approach isto use Elliptic Curve Cryptography (ECC) — themost compact public key cryptosystem thus far.But it is possible to reduce this overhead bysigning only critical messages (e.g., with accidentwarnings) or one in every few messages (the fre-quency and redundancy of messages can allowthis). In addition, given the frequency of safetymessage broadcasts (typically, every 300 ms), avehicle can ignore redundant messages.

CERTIFICATE REVOCATIONThe advantages of using a PKI for VC areaccompanied by some challenging problems,notably, certificate revocation. For example, thecertificates of a detected attacker or malfunc-tioning device have to be revoked, that is, itshould not be able to use its keys or, if it stilldoes, vehicles verifying them should be madeaware of their invalidity.

n Figure 5. Revocation protocol of the tamper-proof device (RTPD).

FM radio

ORSend secure message to tamper-

proof device and broadcast compressed CRL locally using (1) a specific BS

OR (2) a paging area

(3) Send secure message to tamper-proof device using low-speed broadcast

Check for location information

Certificate authority(CA)

Location database

Informowner

Base station

Broadcastcompressed

CRL

M

Secure message Secure msg

ACK (always via BS)

Neighbors TPD: erases keys + STOP

3 In this context, “foreign”means a region differentfrom a vehicle’s homeregion.

The fundamentalsecurity functions inVC will consist inauthenticating theorigin of a datapacket. Authenticationand the inherentintegrity propertycounter the in-transittraffic tampering andimpersonation vulnerabilities. In addition, authentication alsohelps to control theauthorization levelsof vehicles.



The most common way to revoke certificatesis the distribution of certificate revocation lists(CRLs) that contain the most recently revokedcertificates; CRLs are provided when infra-structure is available. In addition, using short-lived certificates automatically revokes keys.These are the methods proposed in the IEEEP1609.2 standard [1]. But there are severaldrawbacks to this approach. First, CRLs can bevery long due to the enormous number of vehi-cles and their high mobility (meaning that avehicle can encounter a high number of vehi-cles when traveling, especially over long dis-tances). Second, the short lifetime of certificatesstill creates a vulnerability window. Last but notleast, the availability of an infrastructure willnot be pervasive, especially in the first years ofdeployment.

To avoid the above shortcomings, we havedesigned a specific solution. It includes a set ofrevocation protocols, namely, Revocation Proto-col of the Tamper-Proof Device (RTPD), Revo-cation protocol using Compressed CertificateRevocation Lists (RCCRL), and DistributedRevocation Protocol (DRP). In the following,we present the details of RTPD, as illustrated inFig. 5, and only outline the main features ofRCCRL and DRP (due to space constraints). InRTPD, once the CA has decided to revoke allthe keys of a given vehicle M, it sends to it arevocation message encrypted with the vehicle’spublic key. After the message is received anddecrypted by the TPD of the vehicle, the TPDerases all the keys and stops signing safety mes-sages. Then it sends an ACK to the CA. All thecommunications between the CA and the vehicletake place in this case via base stations. In fact,the CA has to know the vehicle’s location inorder to select the base station through which itwill send the revocation message. If it does notknow the exact location, it retrieves the mostrecent locations of the vehicle from a locationdatabase and defines a paging area with basestations covering these locations. Then it multi-casts the revocation message to all these basestations. In the case when there are no recentlocation entries or the ACK is not received aftera timeout, the CA broadcasts the revocation

message, for example, via the low-speed FMradio on a nationwide scale or via satellite.

The RCCRL protocol is used when the CAwants to revoke only a subset of a vehicle’s keysor when the TPD of the target vehicle isunreachable (e.g., by jamming or by tamperingof the device). Given the expected large size ofCRLs in vehicular ad hoc networks (VANETs),the key idea in RCCRL is to use Bloom filters— a probabilistic data structure used to testwhether an element is a member of a set. Thus,the size of a CCRL will be only a few KB.RCCRL also relies on the availability of infra-structure that broadcasts the CCRLs once every10 min. Compared to RTPD, RCCRL has thespecial feature of warning the neighbors of arevoked vehicle as they also receive the CCRLs.

The DRP protocol is used in the pure ad hocmode whereby vehicles accumulate accusationsagainst misbehaving vehicles, evaluate themusing a reputation system, and, in case misbe-havior is detected, report them to the CA once aconnection is available. Unlike RTPD andRCCRL, the revocation in DRP is triggered bythe neighbors of a vehicle upon the detection ofmisbehavior. Mechanisms for the detection ofmalicious data [2] can be leveraged to spot vehi-cles generating these data (since all messages aresigned).

PRIVACYTo address privacy vulnerability, we proposeusing a set of anonymous keys that change fre-quently (every couple of minutes) according tothe driving speed. Each key expires after itsusage; only one key can be used at a time. Thesekeys are preloaded in the vehicle’s TPD for along duration, e.g., until the next yearly checkup;the TPD takes care of all the operations relatedto key management and usage. Each key is certi-fied by the issuing CA and has a short lifetime(e.g., a specific week of the year). In addition, itcan be tracked back to the real identity of thevehicle — the Electronic License Plate (ELP) —in case law enforcement necessitates this andonly after obtaining a permission from a judge.This conditional anonymity will help determinethe liability of drivers in the case of accidents.

n Table 1. Comparison of different network types with respect to security problems. It should be noted here that there exist several mech-anisms proposed for some network types, but we consider the most widely adopted of these. Thus, for example, we took Pretty GoodPrivacy (PGP) as a representative example of Peer-to-Peer (P2P) security in the Internet.

FeaturesNetwork type

Cellular, WLAN Sensor Networks P2P (PGP) VANET

Key Management symmetric, centralized symmetric, centralized asymmetric, decentralized asymmetric, multiple authorities

Authentication authentication server pairwise symmetric digital signatures, web oftrust

digital signatures, CAcertificates

Revocation directly by the operator distributed voting counter-certificates short-lived certificates; CRLs

Privacy temporary identifiers NA anonymizing services preloaded keys

Positioning triangulation with basestations

triangulation withbeacons NA open problem



The downside of this approach is the necessityfor storage space for all the keys for one year,but these can fit in only a few Mbytes [3].

In the case of infotainment applications inwhich vehicles communicate with the infra-structure, the CARAVAN scheme [4] allowsvehicles to preserve their privacy by forminggroups in which the group leader acts as a proxyon behalf of all group members that access theinfrastructure. When the vehicles do not have toaccess the infrastructure, they remain silent, thuspreventing eavesdroppers from tracking theirpseudonyms.

STATE OF THE ART

ACADEMIC RESEARCH

The research on VC security is just beginning,with a few pioneer papers published thus far. In[5], Blum and Eskandarian describe a securityarchitecture for VC intended mainly to counterthe so-called “intelligent collisions” (meaningthat they are intentionally caused). But this isonly one type of attack, and building the securityarchitecture requires awareness of as manypotential threats as possible. They propose theuse of a PKI and a virtual infrastructure wherecluster-heads are responsible for reliably dissem-inating messages (by a sequential unicast insteadof broadcast) after digitally signing them; thisapproach creates bottlenecks at cluster-heads inaddition to high security overhead. Gerlach [6]describes the security concepts for vehicular net-works. Hubaux et al. [7] take a different perspec-tive of VC security and focus on privacy andsecure positioning issues. They point out theimportance of the trade-off between liability andanonymity and also introduce Electronic LicensePlates (ELPs), unique electronic identities forvehicles. Parno and Perrig [8] discuss the chal-lenges, adversary types, and some attacksencountered in vehicular networks; they alsodescribe several security mechanisms that can beuseful in securing these networks. Raya andHubaux [3] describe a full security and privacyframework for VANETs with primary simulationevaluations of the security overhead. El Zarki etal. [9] describe an infrastructure for VC andbriefly mention some related security issues andpossible solutions.

Table 1 summarizes the mechanisms used toprovide security features in VC and comparesthem with other network types that are broadlyaddressed in the literature. We can see that thedistinctive properties of VANETs, notably scaleand high mobility, justify the need for, as well asthe opportunity of, using novel solutions com-pared to other network types.

INDUSTRIAL PROJECTSThere are many completed and ongoing projectson VC all over the world. Examples include theBerkeley PATH project in the United States andthe German project Fleetnet. Yet none of theseearly projects has considered the security aspectsof VC. To bridge this gap, new projects are allo-cating part of their resources to investigate secu-rity issues. In the following, we provide anoverview of the most relevant ones.

The IEEE P1609.2 standard [1] is part of theDSRC standards for VC supported by the U.S.Vehicle Safety Communication Consortium(VSCC). It proposes using asymmetric cryptog-raphy to sign safety messages with frequentlychanging keys so that anonymity is preserved.There is no mechanism proposed for certificaterevocation. Instead, certificates have short life-times and are periodically requested by vehiclesthrough roadside base stations, implying theneed for a pervasive infrastructure.

In Europe, VC security is partially consideredwithin the projects Network on Wheels (NoW)and Global System for Telematics (GST) as wellas by the Car2Car Communication Consortium(C2C-CC). It is being fully addressed by the newEuropean project SEVECOM (that stands forSecure Vehicular Communications), which focus-es on providing a full definition and implemen-tation of security requirements for VC.

OPEN PROBLEMSIn addition to the main building blocks present-ed earlier, there remains a set of unexploredproblems directly related to VC security. In thissection we outline the most important of theseproblems.

Secure Positioning — In VC, position is one of themost important data for vehicles. Each vehicleneeds to know not only its own position but alsothose of other vehicles in its neighborhood. GPSsignals are weak, can be spoofed, and are proneto jamming. Moreover, vehicles can intentionallylie about their positions. Hence, the need for asecure positioning system that will also supportthe accountability and authorization properties,frequently related to a vehicle’s position.

Data Verification — This helps to prevent the forg-ing attacks illustrated in Fig. 2. This can beachieved by a data correlation mechanism thatcompares all collected data regarding a givenevent. A first example of such a mechanism ispresented in [2], where the vehicle has a modelto which it compares received data before classi-fying it as truthful, malicious, or unintentionallyincorrect.

DoS Resilience — DoS attacks, and especially jam-ming, are relatively simple to mount, yet theireffects can be devastating. Existing solutionssuch as frequency hopping do not completelysolve the problem. The use of multiple radiotransceivers, operating in disjoint frequencybands, can be a feasible approach.

CONCLUSION

In this article we have described the problemsthat characterize the security of vehicular net-works and sketched possible solutions. As wehave seen, some of these solutions can leverageon existing security techniques. However, wealso have stressed that vehicular communicationsexhibit unique security challenges, induced bythe high speed and sporadic connectivity of thevehicles (especially with the infrastructure), thehigh relevance of their geographic location, thetension between liability and privacy, and the

There are many completed and ongoing projects onVC all over theworld. Examplesinclude the BerkeleyPATH project in theUnited States andthe German projectFleetnet. Yet none ofthese early projectshas considered thesecurity aspects of VC.



huge scale and very gradual deployment of thenetwork. Only a coordinated effort of all partiesinvolved (vehicle manufacturers, transportationauthorities, law enforcement agencies, insurancecompanies, and academic researchers) will makeit possible to devise a solution that is compliantwith the demanding requirements of this fasci-nating area.

Interested readers can visit http://ivc.epfl.chfor more information on this topic.

ACKNOWLEDGMENTSWe would like to thank Virgil Gligor, RainerKroh, and Tim Leinmüller for their helpful feed-back on earlier versions of this work.

REFERENCES[1] “IEEE P1609.2 Version 1 — Standard for Wireless

Access in Vehicular Environments: Security Services forApplications and Management Messages,” in develop-ment, 2006.

[2] P. Golle, D. Greene, and J. Staddon, “Detecting andCorrecting Malicious Data in VANETs,” Wksp. Vehic. Adhoc Networks (VANET), 2004.

[3] M. Raya and J.-P. Hubaux, “The Security of Vehicular AdHoc Networks,” Wksp. Security in Ad hoc and SensorNetworks (SASN), 2005.

[4] K. Sampigethaya et al., “CARAVAN: Providing LocationPrivacy for VANET,” Wksp. Embedded Security in Cars(ESCAR), 2005.

[5] J. Blum and A. Eskandarian, “The Threat of IntelligentCollisions,” IT Professional, vol. 6, no. 1, Jan.–Feb.2004, pp. 24–29.

[6] M. Gerlach, “VaneSe: An Approach to VANET Security,”V2VCOM, 2005.

[7] J.-P. Hubaux, S. Capkun, and J. Luo, “The Security andPrivacy of Smart Vehicles,” IEEE Security and PrivacyMag., vol. 2, no. 3, May–June 2004, pp. 49–55.

[8] B. Parno and A. Perrig, “Challenges in Securing Vehicu-lar Networks,” Wksp. Hot Topics in Networks (HotNets-IV), 2005.

[9] M. El Zarki et al., “Security Issues in a Future VehicularNetwork,” Euro. Wireless, 2002.

BIOGRAPHIESMAXIM RAYA ([email protected]) received a B.Eng. degreein computer and communications engineering in 2002from the American University of Beirut, Lebanon. He is cur-rently pursuing his Ph.D. studies at EPFL. His research inter-ests are in the area of security in wireless networks, andespecially vehicular networks. His web site ishttp://people.epfl.ch/maxim.raya.

PANAGIOTIS PAPADIMITRATOS ([email protected])received his Ph.D. degree in electrical and computer engi-neering from Cornell University Ithaca, NY, in 2005. Hejoined the Department of Electrical and Computer Engi-neering at Virginia Tech, Blacksburg, VA, as a researchassociate. He is currently a senior researcher with theSchool of Computer and Communication Sciences at EPFL.His research is concerned with networking protocols, net-work security, ad hoc and sensor networks, and wirelessand mobile systems. His web site is http://people.epfl.ch/panos.papadimitratos.

JEAN-PIERRE HUBAUX ([email protected]) is a fullprofessor at EPFL. His research interests are mobile net-working and computing, notably, the security and cooper-ation in fully self-organized mobile ad hoc networks. He isan Associate Editor of IEEE Transactions on Mobile Com-puting and Foundations and Trends in Networking. He hasheld visiting positions at the IBM T. J. Watson ResearchCenter and at the University of California at Berkeley. HisWeb site is http://people.epfl.ch/jean-pierre.hubaux.


infoscience - École polytechnique fédérale de lausanne

Documents