pseudonymity in vanets and its implications on the vehicular communication protocol...

Pseudonymity in VANETS and itsimplications on the vehicular

communication protocol stacks

Enhancing user privacy in Vehicular Communication

JIBIN JACOB

Master’s Degree ProjectStockholm, Sweden December 19, 2012

papadim

Typewritten Text

XR-EE-LCN 2012:019

A B S T R A C T

Vehicular Communication (VC) network technology is in the verge of real worlddeployment. The technology is aimed at achieving high levels of traffic effi-ciency security and comfort for the users of the traffic system. The technologyfacilitates exchange of awareness and notification messages among the vehiclesto improve the traffic efficiency and safety of the drivers. However, deploy-ment of this awesome technology faces several security and privacy risks. Thesystem is subjected to security risks like replay attacks, nodes sending falseinformation to the system, denial of service attacks by clogging the networks.System also faces several privacy challenges in which sensitive user data canbe eavesdropped and also tracing out a particular node using the location datasent by the node. In this research we focused on protecting the privacy ofthe users using the VC system. Several European projects have been work-ing on privacy enhancement techniques for VC environments. Privacy policyenforcement approach from Privacy Enabled Capability In Co-Operative Sys-tems and Safety Applications (PRECIOSA), pseudonym approach from SecureVehicular Communication (SeVeCom) and Preparing secure V2X CommunicationSystems (PRESERVE) project which integrates the results from both PRECIOSAand SeVeCom projects are three of those projects considered in this report. Thisresearch is more focused on the pseudonym approach proposed by SeVeCom.We discuss the impact of pseudonym change on the communication stack, whatother lower layer identifiers need to be changed along with the pseudonymchange, and is there any other ways the attacker can still link the messagesfrom a particular node to hamper the nodes privacy. Finally after analyzing theresults from the research, we propose a solution to include a new module in thePRESERVE architecture called Identifier Change Management (IDCM) module toimprove the anonymity of the user participating in the vehicular communication.

Keywords: Privacy,VANETS, pseudonyms, VC protocol stacks

i

A C K N O W L E D G E M E N T S

It would not have been possible for me to write this thesis without the help andsupport from so many good people around me. I would like to thank them allfor inspiring and motivating me through out this research. I would like to takethis opportunity to thank some of them who requires special mention at thistime.

First of all, I would like to thank my supervisor Prof. Panos Papadimitratosfor his kind guidance, support and patience through out the research. His vastknowledge in the research area helped me a lot in formulating and executingthe research. His advice and support has been invaluable on both an academicand personal level, for which I am extremely grateful.

I would like to extend my gratitude to my program director Prof. LouiseYngström for helping me a lot during my masters course. She was so kind togive her advises whenever I faced problems during my studies.I would alsolike to thank my professors, who helped me in understanding the informationsecurity concepts and gave me a good base to start with. I would like to extentmy thanks to each and every one of them.

I would also like to thank the PHd students Marcello Lagana, StylianosGisdakis and Nikolaos Alexiou for the insightful discussions and comments forimprovement during the research. Special thanks to Marcello Lagana for givingthe advice during the implementation part of the research.

Last but not least, I would like to thank my family who continued to supportand motivate me through my studies and this research. Without their supportthis would have remained a dream for me. I would like to extend my gratitudeto all of them.

Med vänliga hälsningar,Jibin Jacob

iii

C O N T E N T S

Acronyms ix

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Outline of the report . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Privacy by design 72.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 PRECIOSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 SEVECOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 PRESERVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 VC Protocol Standards 173.1 Wireless Access in Vehicular Environments . . . . . . . . . . . . . 17

3.1.1 WAVE PHY and MAC layers . . . . . . . . . . . . . . . . . 193.1.2 WAVE networking services . . . . . . . . . . . . . . . . . . 203.1.3 WAVE resource manager . . . . . . . . . . . . . . . . . . . . 22

3.2 ETSI ITS-Station OSI protocol stack . . . . . . . . . . . . . . . . . . 243.2.1 ITSC Access Layer . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 ITSC Networking and Transport Layer . . . . . . . . . . . 273.2.3 ITSC Security Layer . . . . . . . . . . . . . . . . . . . . . . . 33

3.3 Car2X Communication Architecture . . . . . . . . . . . . . . . . . 333.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Network Identifier Management 374.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.4 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.6 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.7 Testing and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.7.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

iv

4.7.2 System Configuration . . . . . . . . . . . . . . . . . . . . . 414.7.3 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.7.4 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.7.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.8 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 454.9 Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Conclusion and Future works 515.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Bibliography 53

v

L I S T O F F I G U R E S

2.1 PeRA Architecture[13] . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Pseudonym Approach SeVeCom [17] . . . . . . . . . . . . . . . . 122.3 V2X Security Architecture[18] . . . . . . . . . . . . . . . . . . . . 14

3.1 WAVE Communication Stack[19] . . . . . . . . . . . . . . . . . . . 183.2 802.11 MAC Frame format [21] . . . . . . . . . . . . . . . . . . . . 193.3 WSM Package format[22] . . . . . . . . . . . . . . . . . . . . . . . 213.4 Components of WAVE RM [23] . . . . . . . . . . . . . . . . . . . . 223.5 Sample Signed Message [24] . . . . . . . . . . . . . . . . . . . . . 233.6 ETSI ITS-C Station reference architecture[25] . . . . . . . . . . . . 253.7 Access Layer Details [25] . . . . . . . . . . . . . . . . . . . . . . . 263.8 ITSC Networking and Transport layer[25] . . . . . . . . . . . . . 273.9 Geo-networking address format [27] . . . . . . . . . . . . . . . . . 283.10 Geo-networking packet structure [27] . . . . . . . . . . . . . . . . 283.11 Geo-networking Header structure [27] . . . . . . . . . . . . . . . 293.12 Common Header Structure [27] . . . . . . . . . . . . . . . . . . . 293.13 GN Long Position Vector [27] . . . . . . . . . . . . . . . . . . . . . 293.14 GN Short Position Vector [27] . . . . . . . . . . . . . . . . . . . . . 303.15 BTP Packet Structure [28] . . . . . . . . . . . . . . . . . . . . . . . 303.16 ASN1 encoded CAM message format[29] . . . . . . . . . . . . . . 323.17 Protocol Architecture of the C2C-CC System[3] . . . . . . . . . . . 35

4.1 Attack Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2 ID Change Management Module . . . . . . . . . . . . . . . . . . . 394.3 ID Change Management Module flowchart . . . . . . . . . . . . . 424.4 Geo-Unicast packet structure.[27] . . . . . . . . . . . . . . . . . . 434.5 Sample output of the receivePacket.c . . . . . . . . . . . . . . . . . 444.6 Sample output of the receivePacket.c with IP and UDP . . . . . . 444.7 Snippet of the log file created at the sender. . . . . . . . . . . . . . 454.8 Distribution of execution time - Sending packets . . . . . . . . . . 464.9 Distribution of execution time - Receiving and Parsing GN packets 474.10 Distribution of execution time - IDC . . . . . . . . . . . . . . . . . 484.11 Distribution of execution time - IDC - Detailed Analysis . . . . . 484.12 Model Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vi

L I S T O F TA B L E S

4.1 Execution time for different modules in milliseconds . . . . . . . 45

vii

A C R O N Y M S

APDU Application Protocol Data Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

API Application Program Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ASIC Application Specific Integrated Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

BTP Basic Transport Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

C2C-CC Car2Car Communication Consortium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

CA Certificate Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

CAM Co-operative awareness messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

CCH Control Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

CRL Certificate Revocation List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

DA Destination Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

DENM Decentralized Environmental Notification Messages . . . . . . . . . . . . . 31

DSRC Dedicated short Range Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ETSI European Telecommunications Standards Institute . . . . . . . . . . . . . . . . 1

EVITA E-safety vehicle intrusion protected applications . . . . . . . . . . . . . . . . . 14

FCS Frame check sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

FOT Field operational test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

HTTP Hyper Text Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

IDCM Identifier Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

IEEE Institute of Electrical and Electronics Engineers . . . . . . . . . . . . . . . . . . . 1

IP Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

IPV6 Internet Protocol Version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ITS Intelligent Transport Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

ITSC Intelligent Transport System Communication Protocols . . . . . . . . . . 26

LAN Local Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

LDM Location Dynamic Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

LLC Logical Link Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

MAC Media access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

MIB Machine Information Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

ix

MPC Mandatory Privacy Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

OBU On Board Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

OSI Open Systems Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

PeRA Privacy Enforceable Runtime Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9

PET Privacy Enhancement Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

PHY Physical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

PKI Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

PMM Pseudonym Manage Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

PP Pseudonym Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

PRECIOSA Privacy Enabled Capability In Co-Operative Systems and SafetyApplications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

PRESERVE Preparing secure V2X Communication Systems . . . . . . . . . . . . . . . . . . . . i

PSID Provider Service ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

PV Position Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

RA Receiving Station Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

RCP Resource Command Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

RM Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

RMA Resource Management Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

RSU Road Side Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

SA Source Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

SCH Service Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

SeVeCom Secure Vehicular Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

TA Transmitting Station Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

TCP Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

UDP User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

V2I Vehicle to Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

V2V Vehicle to Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

VANETS Vehicular Adhoc Networks

VC Vehicular Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

VIN Vehicular Identification Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

VSA V2X Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

VSS V2X Security subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

x

WAVE Wireless Access in Vehicular Environments . . . . . . . . . . . . . . . . . . . . . . . 4

WBSS WAVE Basic Service Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

WME WAVE Management Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

WSA WAVE Service Advertisement messages . . . . . . . . . . . . . . . . . . . . . . . . . . 21

WSM WAVE Short Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

WSMP WAVE Short Message Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

xi

1

1 I N T R O D U C T I O N

A VC network is a promising new technology that enables the vehicles tocommunicate each other among themselves and with the outside networks.The introduction of this new communication technology will help to improvetransportation efficiency and safety[1] . Several standardization bodies (e.g.Institute of Electrical and Electronics Engineers (IEEE), European Telecommunica-tions Standards Institute (ETSI), Car2Car Communication Consortium (C2C-CC))started standardizing the vehicular communication protocols in order to facili-tate seamless communication between the vehicles irrespective of their manu-facturers. The state of the art communication protocols are in the final stagesof approval and soon the market will start to roll out VC devices and softwareapplications. As with any good technology, VC technologies are also proneto misuse and attacks by the adversaries. The attacker can compromise theconfidentiality and integrity of the messages that are being sent over the VCsystem and can cause the system to react dangerously that could even harmthe life of the legitimate user. Apart from the security threats caused by theadversary, the privacy of a legitimate user is a matter of concern while usingthese technologies. An adversary can infringe the location privacy of a user bytracking the vehicle or can even eavesdrop to the sensitive data that are beingsent over the communication network and thereby stealing personal informa-tion. Researchers were working on several privacy enhancement techniquesand many of them like, use of pseudonyms i.e. use of short term keys, and useof mix zones i.e. changing the keys in un-monitored areas are accepted as goodsolutions[2] .

1.1 backgroundThe introduction of the communication network technologies to the vehicularenvironments opened up a variety of applications that can attribute to the safetyof the user. Vehicular communication involves communication between vehicles(Vehicle to Vehicle (V2V)) and between vehicle and a road side unit (Vehicleto Infrastructure (V2I)) which enables the VC technology to provide a widerange of applications to the users. V2V communication can provide cooperativeenvironment hazards awareness warnings like forward collision warning or

2 background 1.1

icy road ahead warning. V2V communication also helps the vehicular systemto build the adhoc networks by making use of the location data that is beingbroadcast by each node. V2I communication enables the vehicle to connect to theoutside networks like internet which opens up to a wide variety of applicationsto the in car infotainment systems that are available on the normal TCP/IPnetworks (e.g., Tourist information, maps, points of interests). Accordingto the manifesto[3] from the C2C-CC on the VC, the applications that can beprovided through the VC communications can be broadly classified into safetyapplications, Traffic efficiency applications and infotainment applications. Safetyapplications include forward collision warnings, pre-crash sensing warningsand warnings about hazardous locations. Traffic efficiency applications mayinclude line merging assistance, de-route warning warnings in case of trafficjams or accidents, advice driver about the optimal driving speeds. Infotainmentapplications other non critical services like internet access inside the cars,notifications about the different points of interests in the route, or even themanufacturers or the service stations can provide remote diagnosis to help thedrivers in case of any problems.

Implementation of such a system opens the possibility a number of abusesand attacks to the system. Utmost priority must be given to the security andprivacy of the user while designing and deploying such systems. Confidentialityand integrity of the messages sent over a Vehicular Communication (VC) systemis important for the proper functioning of a VC system. Any attack on the systemcan jeopardize the entire network and can even threaten the life of the driver.Several European projects have contributed in building the system architectureand communication standards for the Secure Vehicular Communication (VC)systems.

State of the art architecture for secure vehicular communication is presentedin [4] . The report discusses various adversary models that can present poten-tial threats to the VC system. Both the internal and external adversaries aremodeled. The document discusses various security requirements of the VC sys-tem including Message authentication and integrity, Message non repudiation,Entity authentication, Access control, Message confidentiality, Accountabilityand Privacy protection. The architecture proposed in the report presents arobust design capable of meeting most of the security requirements of a VCsystem. The report describes the encryption techniques and message formatsto ensure integrity and authenticity of messages sent by each node in the VCsystem. The design makes use of the Public Key Infrastructure (PKI) to ensurethe authentication of each node participating in the system’s functioning.

The security architecture proposed in [4] tackles most of the security prob-lems involved with the VC systems. However the researches to tackle the privacyconcerns of consumers are in the beginning stages. Any attempt to disclose orinfer sensitive user information from the data that is sent over the VC system is

1.2 problem statement 3

considered as a Privacy infringement. An adversary can track the location ofthe individual user by making use of the identification data that each node sentas beacons[5] across the VC network. For example, and adversary can eavesdropinto the messages and identify the particular user by using the public key of aparticular user. Adversary can use the certificate attached to each message as anidentifier to track the individual node. Another way an adversary can breachan individual’s privacy is through eavesdropping into the data that the nodessent over the network and use that data for targeted advertising. For example arestaurant can send advertisements about special deals to all the cars passingnear it during the lunch time.

When it comes to privacy, private individual nodes are the ones to befocused more when compared to public vehicles and Road Side Units (RSUs)participating in the VC, for the latter does not raise any privacy concerns andmust be readily identifiable. The reports [4] and [2] proposes privacy protectionthrough anonymity, a technique by which makes it impossible for an adversaryto correlate two messages sent by the same vehicle. They describe the use ofpseudonyms, which is using multiple certificates/keys to encrypt the messagessent by one node. The pseudonym will be changed in regular intervals so thatan adversary tracking a node using the certificate keys will fail to continuetracking as the key got changed. However if the adversary correlate the oldand new certificates by some other means then the adversary still can continuetracking an individual node. In paper [4], they proposes the idea of Mix zones,where many nodes change their pseudonyms, leaving the attacker to guesswhich key belongs to which node. The use of mix zones improves the anonymityof the nodes participating in VC.

1.2 problem statementAlthough the motivation behind using the pseudonyms for anonymity is ob-vious, many issues need to be addressed before being deployed to the realworld scenarios. Changing the pseudonyms at the upper layers for providinganonymity can become worthless if an attacker can manage to track and linkthe messages using the network identifiers from lower levels of the commu-nication stack. An attacker monitoring the messages at a packet level or ata data frame level could still figure out and link two messages sent from thesame node even if the cryptographic keys used to encrypt those messages inthe upper layer changes. As these messages can contain sensitive personal dataand geographical locations of the user, adversary could use these messages tobreach the privacy of the user. For providing a satisfactory level of anonymityto the user, this problem should be addressed before the system is implemented

4 outline of the report 1.4

in real world. So it becomes obvious that we must change all the lower layernetwork identifiers of the communication stack in order to provide anonymityto the user.

1.3 purposeAs the apparent need for changing the identifiers at the lower levels of thecommunication stack along with the change in a pseudonym is clear, thepurpose of this research can be defined as three fold.

• Systematically analyze the Vehicular Communication protocols, to findout the different identifiers used by the protocol messages, which can beused by the adversary to pinpoint a particular node in the system. Thestudy extends up to three of those standard protocols. IEEE WAVE, ETSI ITS,and the protocol standards from the C2C-CC.

• Model scenarios by which an adversary can establish a linkage betweenthe messages sent by a node even after changing the identifiers.

• Device a software module that can be integrated to the PRESERVE frame-work to manage the network identifiers change in the Vehicular Commu-nication (VC) stack.

1.4 outline of the reportThis report is organized as follows. Chapter 2 discusses the concept of privacy bydesign and explores the contributions of European projects [PRECIOSA, SeVeCom,and PRESERVE] towards enhancement of privacy in VC environments. This chap-ter also includes the discussion about the security architectures developed bythese projects for providing security and privacy to VC environments. Chapter3 explores the protocol standards developed specifically to be used in the vehic-ular environments. The discussion include IEEE Wireless Access in VehicularEnvironments (WAVE) standard, ETSI Intelligent Transport Systems (ITS) StationOpen Systems Interconnection (OSI) protocol stack and C2C-CC protocol stack.The discussion is focused on analyzing the different layer headers, identifyingpotential data fields that could be used by the adversary to track an individualnode in the network and breach the user privacy. The chapter also discusses theneed for changing these header fields randomly in order to provide anonymityto the node. Chapter 4 models a scenario where the privacy of the node can stillbe breached even after changing potential data fields identified in the previous

1.4 outline of the report 5

chapter. Chapter 4 also proposes an enhancement in the PRESERVE architectureto fix the vulnerabilities identified through this research. Chapter 5 summarizesthe report and also includes discussion on the future works.

7

2 P R I VA C Y B Y D E S I G N

2.1 introductionWhen the vehicular networks are deployed in the real world, a large amount ofdata will be captured from the nodes and transmitted through the network. Thedata may include node identification data (for example, Vehicular IdentificationNumber (VIN), nodes License number) real time values captured from differentsensors in the vehicle (for example, geographical location, speed, heading,gas level) and even the sensitive data like credit card numbers, bank accountnumbers if the driver chooses to use any payment services from the vehicle.In order to get the awesome services and benefits from the VC systems, it isnecessary that the nodes transmit these data to the network. The transmissionof sensitive user data over the network causes privacy risks and if not properlydesigned these systems could make user’s privacy at stake. It is important thatthe systems which handle large amounts of user data must be designed fromthe earlier stages by keeping the privacy principles in mind. The approachis often mentioned as privacy by design [6] . This paper [6] also lists out tenprivacy principles which must be considered while designing systems. Theprinciples include, Purpose of Specification – This principle mandates that thepurpose for which the personal data is collected must be specified, Consent –The purpose should have a consent from the donor of the data, Limited Collection– The personal data collected must be minimum and should be according tothe specifications, Limited use – mandates that the data collected must be usedonly for the purposes for which the data was collected, Limited disclosure – thisprinciple prohibits the usage of the personal data outside the system boundariesfor purposes other than those that has consent from the donor, Limited Retention- Mandates that the personal information collected must not be retained onthe system after the stated purpose is fulfilled, Accuracy – the system muststore accurate and up to date information, Safety – the data collected must beprotected against theft and alterations, Openness – The data must be available tothe donor for verification of accuracy, Compliance – the donor must be allowedto verify whether all the above principles are complied to.

Many countries in the world have legally mandated the compliance to theseprinciples when building systems which collect personal data from the users.For example, these principles are stated as laws in the European Data Protection

8 preciosa 2.2

Directives [7] [8] and also in German data protection law [9] . However lawsare often not enough to guarantee the data privacy protection. Recently manyincidents has been reported where the privacy laws has been breached orbroken. [6] Lists the incidents happened at Deutsche Telekom1 or DeutscheBahn(German Railway2 ) showed the issues in the data protection laws. Theseincidents highlighted the need for technologies built into the system that couldprevent the privacy breach. The privacy protection laws of-course are vital butthey cannot be the only line of defense. Systems that collect and stores sensitiveuser data must have some inherent privacy protection mechanism to prevent theprivacy breaches. These technologies are often called as Privacy EnhancementTechniques (PET).

From the initial stages of its design, the researchers of the VC systems pututmost importance for data privacy of the users of the system. Many Europeanprojects were working on developing privacy enhancement techniques for theVC systems. In this chapter we will discuss three of these projects PRECIOSA3,SeVeCom4 and PRESERVE5 and their contributions to the privacy enhancements inVC systems.

2.2 preciosaThe project PRECIOSA started in 2008 and was one of the pioneers in integratingthe concept of privacy by design into its engineering processes in buildingprivacy aware cooperative systems (e.g. Mobile Ad-hoc networks, VehicularCommunication networks). The project was researched and developed bya consortium of two universities (Humboldt-Universität zu Berlin and UlmUniversity) and three industry partners (Trialog, Oracle, PTV Traffic mobilityLogistics) [10] . The project was initiated by eSafety6 , Information Society andMedia7 and Seventh Framework of European Commission8 .

The primary goal of the PRECIOSA project was to analyze the privacy issuesand challenges involved in the cooperative systems [11] and to demonstrate thatthe cooperative systems can comply with the privacy principles listed by thedata protection authorities. Along with the privacy enhancement techniques,the focus was on developing mechanisms that can evaluate and verify the level

1 http://www.time.com/time/business/article/0,8599,1809679,00.html2 http://www.timesonline.co.uk/tol/news/world/europe/article6004352.ece3 http://www.preciosa-project.org/4 http://www.sevecom.org/5 http://www.preserve-project.eu/6 http://ec.europa.eu/information_society/activities/esafety/index_en.htm7 http://ec.europa.eu/dgs/connect/index_en.htm8 http://ec.europa.eu/research/fp7/index_en.cfm

2.2 preciosa 9

of privacy in cooperative systems. The objective was to 1) Define an approachto evaluate the privacy of cooperative systems – in terms of communicationprivacy and data storage privacy, 2) define an architecture for cooperativesystems which is privacy aware – an architecture which provides functionalitiesto protect, detect infringement and auditing of privacy. 3) Define guidelines ofprivacy aware cooperative systems [12] .

Deliverable 11 of the PRECIOSA project [13] , lists the contributions of thePRECIOSA project towards privacy in cooperative systems. These contributionscan be summarized as

• Privacy Enhancement through Data Minimization- In this approach the userof the system will have the authority to choose the level of privacy (lowmedium and high) and the system will limit the amount of data beingtransmitted from the system based on the user settings. For example,when the user opts for high level of privacy, the data transmitted fromthe vehicle will not contain any personal identifiable data and if the useropts for low privacy level, the system can send data that can identify theparticular vehicle (VIN Numbers, License Number).

• Privacy Enforceable Runtime Architecture (PeRA) – PeRA is an architecturedeveloped for privacy data management in ITS systems. PeRA controlsand manages the vehicular information from different sensors insidethe vehicle, data from other communication nodes, and data from othersources. Each data collected from the vehicle is linked with a privacypolicy, in which it defines the different privacy regulations that needs tobe complied while processing and transmitting each data. PeRA allowsthe system to enforce the evaluation of these privacy policies before eachdata is being processed or transmitted. PeRA architecture is shown infigure 2.1. PeRA consists of a Policy Enforcement Layer, which evaluates andenforces policy compliant processing of data items between distributednodes and an Integration Protection Layer, which ensures that only validPeRA instances can directly access any data from the node.

• Privacy Policy Enforcement Perimeter- PRECIOSA defined the concept ofPrivacy policy Enforcement Perimeter, which defines the boundary ofthe system environment in which the data that needs privacy protectionis associated with policies (Which defines the allowed operations on aparticular data). The policies are enforced by the Privacy EnforcementLayer/Mandatory Privacy Control (MPC) subsystem. Also the integrationprotection layer helps the MPC to prevent unauthorized access of datastored on the node.

In summary, the privacy enhancement in the vehicular environments throughdata minimization is an excellent technique in preventing and controlling the

10 preciosa 2.2

Figure 2.1: PeRA Architecture[13]

personal data being transmitted from the node. The PeRA architecture defined byPRECIOSA definitely will prevent the unauthorized persons from accessing thepersonal data from the node. However in the vehicular environments, certaindata such as the geographical location data of the node must be transmitted fromthe node periodically, in order for the vehicular networks to function properly.The Vehicular Communication uses these location data for neighbor discovery[14] and setting up ad-hoc networks. As these location data is accompaniedby identifiers of the node, an adversary can co-relate the node and the locationand trace the route of that node. This is a breach to a node’s location privacy.This problem was further researched by another project called SeVeCom whichwill be discussed in next section. In summary, the privacy enhancement in thevehicular environments through data minimization is an excellent techniquein preventing and controlling the personal data being transmitted from thenode. The PeRA architecture defined by PRECIOSA definitely will prevent theunauthorized persons from accessing the personal data from the node. Howeverin the vehicular environments, certain data such as the geographical locationdata of the node must be transmitted from the node periodically, in order forthe vehicular networks to function properly. The Vehicular Communication usesthese location data for neighbor discovery [14] and setting up ad-hoc networks.As these location data is accompanied by identifiers of the node, an adversarycan co-relate the node and the location and trace the route of that node. This isa breach to a node’s location privacy. This problem was further researched byanother project called SeVeCom which will be discussed next.

2.3 sevecom 11

2.3 sevecomSecure Vehicular Communication (SeVeCom) project started in 2006 with theobjective of building a state of the art secure architecture for vehicular commu-nication. SeVeCom project was part of the initiatives from eSafety, InformationSociety and Media and the Sixth Framework Programme of the EU commission.The researches were done by Industry partners (Trialog, Robert Bosch GmBH,Daimler, CRF-Fiat Research Center) and universities (Budapest University ofTechnology and Economics, EPFL - Ecole Polytechnique Fédérale de Lausanne,Katholieke Universiteit Leuven, Ulm University)[15] .

The project analyzed various security threats anticipated on future vehicularcommunication networks and provided several solutions for tackling thosethreats [16] . After analyzing various threat scenarios, several security require-ments were laid out for building the secure architecture. These requirementsincluded authentication and integrity of the messages transmitted in the VCnetworks, Authentication of the entities participating in the vehicular commu-nication, access control – which defines the authorizations of each entity inthe VC network, preventing the confidentiality of the messages being transmit-ted, accountability of the actions taking place in the network, and preventingmessage non-repudiation [4] . These requirements formed the basis of thesecure architecture developed by the SeVeCom Project. The architecture proposedincludes identity and credential management system – deals with the registrationof the vehicles and other entities to the system, Key management system – whichincludes Public Key Infrastructure (PKI) for distributing and managing the keysfor encrypting the messages generated by the entity, Hardware Security Module– which stores the private key of the node which can be used for signing themessages [4].

Along with the security of the messages, SeVeCom project put much effort into protecting the privacy of the sensitive personal data that is being sent over theVC network. SeVeCom followed the Privacy by Design approach while designingthe architecture. The identifiers (for example the public key certificate attachedto the signed message) that were sent along with the messages posed greatestchallenge in protecting the privacy of a user of the system. Attackers could usethese identifiers to track individuals by analyzing the different identifiers in themessage. Many researches were conducted for finding new ways of privacyenhancement techniques. These researches resulted in defining a state of theart Privacy Enhancement Techniques, which is anonymity through the use ofpseudonyms [4].

Anonymity through pseudonyms – The public key certificate attached to eachmessage sent by the node could be used by the adversary to correlate differentmessages sent by a node. SeVeCom’s research took one step further in providinganonymity to the node participating in a VC communication network. The

12 sevecom 2.3

Figure 2.2: Pseudonym Approach SeVeCom [17]

approach devised was known as anonymity through pseudonyms [4]. Theidea is to use short term certificates that contain less specific details about thevehicles instead of a long term certificate, and also change the certificates aftera certain period of time, so that the adversary analyzing the messages basedon the keys would not be able to link two messages from the same node, oncethe keys are changed. These short term key pairs (public key and private key)are known as pseudonyms. The generation and usage of the pseudonym canbe better explained with the figure 2.2. In the figure we have three entities,Certificate Authority (CA), Pseudonym Provider, and the vehicle. When avehicle registers to the system, each vehicle receives a certificate from the CA,which contains specific details about the vehicle to identify it. This certificateis known as the long term certificate (LT_ID). The vehicle node then contactsthePseudonym Provider (PP) with the LT_ID, so that the PP can verify thedetails and authenticate the node. Once authenticated, the PP will generatepseudonyms for this node. The provider also stores a mapping between thelong term identifier and the pseudonyms generated. This mapping can beused, if the authorities (for e.g. police) want to check the identity of any nodeparticipating in the network. Once the node is filled with the pseudonyms, thenode can use these for encrypting the messages as shown in the figure 2.2. Thenodes will change the pseudonyms after certain period of time, for examplefrom PNYM_1 to PNYM_2. Once the pseudonym is changed to PNYM_2 allthe messages sent by the node will be encrypted with the new keys. So anadversary tracking the messages based on PNYM_1 will loose the linkage oncethe pseudonym is changes. This will provide anonymity to the node in thenetwork, as the adversary cannot predict which node is using which key at agiven time. The pseudonym approach devised by SeVeCom provided a high levelof protection of the user’s data privacy by making the user anonymous. Theidea is, even if the adversary is able collect the data through eavesdropping, the

2.4 preserve 13

adversary will not be able to link the data to a particular user. So the approachsatisfies the privacy requirement of unlinkability. Also this approach providesgood deal of location privacy since the messages carrying the node’s locationis encrypted with different keys at different times. The adversary can onlytrace the location of the node if he gets hold of all the pseudonyms and theknowledge about the time at which the pseudonyms are changed by the node.However that would be a computational challenge for the adversary to guessthe order and time of a pseudonym change. Thus the approach provides highlevel of data privacy protection.

Though the approach enhances the privacy by making the user anonymousin the network, there are several problems that need to be addressed beforeimplementing these techniques. For example, the approach provides high levelof anonymity from an application level, but there is a chance of the adversarycould still link the messages by looking at the lower layers of the communicationstacks. Consider a scenario where a pseudonym change occurred and all thenew messages from the node will be encrypted with the new keys, and supposethe lower layer network identifiers of the communication stack (e.g. InternetProtocol (IP) address, Media access control (MAC) address) are not changedin parallel with the pseudonym change. Then, an adversary monitoring themessages at a packet level could still link the messages coming from the samenode with the help of the identifiers (IP address) on each packet even though thepseudonym changed at the application layer. This problem is being researchedby another European project called PRESERVE which is discussed in next section.

2.4 preservePreparing secure V2X Communication Systems (PRESERVE) project started in2010 with the objective of building a complete security and privacy protectionsubsystem for vehicular communication systems. PRESERVE integrates the re-sults from the researches done by PRECIOSA, SeVeCom and EVITA projects in thefield of security and privacy in vehicular communication network. The researchis initiated by EU seventh framework programme. The project partners includetwo universities (University of Twente (coordinator), The Netherlands, KungligaTekniska Hoegskolan (KTH), Sweden) and industry partners (Escrypt GmbH(SME), Germany, Fraunhofer SIT, Germany, Renault, France, Trialog (SME),France)

Integrated V2X Security Architecture (VSA): One of the main objectives ofthe PRESERVE project is to design and implement a close to market securitysubsystem which integrates the researches from three other projects mentionedabove. The project also aims at solving any open development and deployment

14 preserve 2.4

Figure 2.3: V2X Security Architecture[18]

issues in the security and privacy researches previously done. Another objectiveis to provide a ready to use security Application Specific Integrated Circuit (ASIC)and support to Field operational tests (FOTs). Figure 2.3 shows the V2X SecurityArchitecture (VSA) proposed by PRESERVE project.

The secure architecture shown in figure 2.3 shows how the modules fromother projects are integrated together in creating the V2X Security Architec-ture (VSA). The architecture contains the PeRA from the PRECIOSA project,the secure communications and pseudonym management modules from theSeVeCom project and other crypto services and platform integrity modules fromE-safety vehicle intrusion protected applications (EVITA) project. The architec-ture also includes a convergence layer which facilitates the communicationbetween the security and privacy modules and the communication stack. Thearchitecture also shows how the data collected from the different onboard sen-sors are subjected to security and privacy policies before being transmitted outof the vehicle.

The PeRA module ensures that all the data transmitted is validated basedon the privacy policy and only data that satisfies the requirements will beallowed to be transmitted to the vehicular communication network. All thesecurity related functionalities like entity authentication, authorization are doneby modules developed as part of EVITA project. The architecture also includes

2.4 preserve 15

HSM (Hardware Security Module) to store the private keys used for encryptingthe messages transmitted from the node. The HSM makes sure that the privatekeys never leave the device and also ensures that all the data will be erasedautomatically if someone tries to tamper the device [18].

The pseudonym manage module implements the anonymity through pseudonymsapproach developed by SeVeCom project which we discussed earlier. The fre-quency and order of pseudonym change is managed by this module. Thepseudonym change makes the node anonymous in the network and preventsany adversary from tracking the data transmitted by any individual nodes.Once the node changes the identifiers, it will be difficult for the adversary tolink two messages coming from the same node, thus providing the anonymity.The pseudonym manage module interacts with the nodes communication stackthrough the convergence layer. The convergence layer provides ApplicationProgram Interfaces (APIs) to access lower layers of the communication stack.

From the privacy point of view, PRESERVE project provides an optimal solu-tion for the user by integrating both the data minimization approach and theanonymity through pseudonym approach. The PeRA lets the user to controlthe level of privacy needed and can limit the amount of sensitive data thatgets transmitted from the node over the network. Privacy Enforcement layer inthe PeRA evaluates each data sent from the node against a predefined privacypolicies which determine the sensitivity of the data and only data that passesthe evaluation gets transmitted from the node. The pseudonym manage modulekeeps the node anonymous in the network by changing the identifiers used bythe node while sending messages. Changing the identifiers will make it difficultfor the adversary to track the messages from an individual node.

However the pseudonym approach integrated into the PRESERVE project stillhas some open issues to be solved before the solution can be implemented. Theissue of implications on the communication stack, because of the pseudonymchange, discussed in the SeVeCom section still remains open. Any adversary,analyzing data at a packet level or any lower level of the communication stackcould find a linkage between the messages even if the pseudonym is changedat the application layer. As a result, the anonymity provided by the pseudonymchange could be nullified and the node can still be individually tracked in thenetwork. In this thesis, we furthered the research on this issue by studying thedifferent communication protocol standards defined specifically for Vehicularcommunication networks. Next chapter will discuss the protocol standards forvehicular communications.

17

3 V C P R OTO C O L S TA N DA R D S

VC systems are being designed with the rationale to achieve high levels ofsecurity and efficiency in the traffic systems. The drivers are alerted aboutthe environment so that they can take the appropriate measures to avoid anyhazards. For the proper functioning of the VC systems, the essential part isthe information being exchanged among the vehicles and road side units. It isessential that the nodes participating in the VC speaks the same language for thenodes to understand each other and interpret the information being exchanged.This brings attention to the need for communication standards in the VehicularCommunication. From the beginning, many standardization bodies like IEEE,ETSI and C2C-CC, has been working on developing a communication protocolthat can be used in the vehicular environments. These protocols defines theformat of the messages being exchanged, mandatory fields that needs to bepresent in the messages, the order in which these messages must be send. Thischapter gives a brief introduction to three of these protocols,

• Wireless Access in Vehicular Environments (WAVE) from IEEE

• GeoNetworking protocols from ETSI

• C2C-CC Networking Protocols from Car2Car Communication Consortium

This report concentrates more on the header formats used at each layer inthe protocol stack and try to find out layer identifiers that can leave traces aboutthe node on the vehicular networks.

3.1 wireless access in vehicular environmentsFrom the initial stages, the researchers in vehicular communication area, werein favor of using wireless communications as a basis for the VC systems. How-ever the existing wireless communication standards 802.11x as such was notsuitable for the dynamic vehicular environments. In 2004 an IEEE task groupstarted working on the amendments to the existing MAC and Physical (PHY)layer standards (802.11x) standards to make it adaptable to the vehicular envi-ronments [19] . The amendments are documented as the new standard 802.11p.Meanwhile another group at IEEE started working on developing specifications

18 wireless access in vehicular environments 3.1

Figure 3.1: WAVE Communication Stack[19]

for the other layers in the protocol suites. These specifications are documentedas 1609.x standards. According to [19] the 1609 standards include IEEE 1609.1,IEEE 1609.2, IEEE 1609.3, IEEE 1609.4. The standards 802.11p and 1609.x arecollectively known as the WAVE standards. The WAVE Communication stack isshown in the figure 3.1.

The WAVE Components

The WAVE components includes RSUs, On Board Units (OBUs), that are designedto communicate with each other using the Dedicated short Range Communica-tion (DSRC) technology. In US, a radio spectrum of 75 MHz in the 5.85-5.925 GHzrange is allocated for ITS communications in 1999 [19] . The available spectrumis divided into one Control Channel (CCH) and six Service Channels (SCHs).The WAVE protocols use the Control Channel to transmit the high priority timesensitive communications and the Service Channel to transmit traditional lessdemanding messages. This setup allows the WAVE devices to receive all emer-gency messages even if the devices are busy transmitting traditional InternetProtocol Version 6 (IPV6) data for example downloading a data files. The devicesswitch between the CCH and SCH at regular intervals in order to listen to anydata being transmitted[19] .

As we can see from the figure 3.1, the WAVE includes two communicationprotocol stacks, WAVE Short Message Protocol (WSMP) stack and traditional IPV6stack. Two separate stacks are needed as the WAVE supports two types of com-munications as mentioned above, high priority time sensitive communicationsand traditional less demanding messages. The WAVE Short Messages (WSMs)are messages used by the protocol for setting up and maintaining the vehicularnetworks. An example of a WSM is the regular beacon messages broadcastedat regular intervals from each vehicle in the network. These messages are

3.1 wireless access in vehicular environments 19

Figure 3.2: 802.11 MAC Frame format [21]

used by the protocol to build the ad-hoc networks by performing the neighbordiscovery. WSMs also include the messages carrying emergency information,for example, messages carrying information about an accident warning, or icyroad warnings. These messages are critical and time sensitive. These WSMsare transmitted over the WSMP stack. Along with the WAVE Short Message ,WAVE devices are designed to support traditional IPV6 communications whichallows the device to connect to the internet. For example these communicationscan include, accessing a web server from the device, paying toll tax from thevehicle, accessing emails and watching movies. These communications aredata intensive and can continue for long period of time. So the WAVE protocolallows these communications to be done on separate stack without hinderingthe WSMs.

3.1.1 WAVE PHY and MAC layers

The lower two layers in the WAVE stack is based on IEEE 802.11p protocolstandard. 802.11p [20] is a variant of the 802.11 wireless Local Area Network(LAN) protocols [21] designed specifically for the use in vehicular environments.The traditional 802.11 a/b/g variant of wireless LAN protocols lacked manycharacteristics required by the vehicular environments. Consider a scenariowhere messages being exchanged between two cars passing over in oppositedirections on a freeway. The devices get only a fraction of the second beforethey can set up a connection, do all the necessary handshakes and transmitthe data to the peer. This type of challenging environment makes it difficult touse the traditional 802.11 standards unsuitable for vehicular environments, andthus emerged the new version 802.11p. The amendments made to the 802.11protocols to make it suitable for the VC environments are documented in [20] .These changes can be summarized as changes for communications in highlymobile environments, changes to switch between control channels and servicechannels, prioritizing the messages. Now we will look into the frame formatused by MAC layer.

Figure 3.2 shows the format of an 802.11 frame. 802.11p protocol also usesthe same frame format. As we can see from the figure 3.2, each frame consists


of a MAC Header, Frame body and Frame check sequence (FCS) field whichinclude the cyclic redundancy check of the MAC header and the Frame Body.

While considering privacy of the node, we are interested in the four addressfields in the MAC header. As we can see from the figure 3.2, each MAC framecontains four address fields, Source Address (SA),Destination Address (DA),Transmitting Station Address (TA), and Receiving Station Address (RA). Allthese address represents the 48 bit MAC address of the corresponding source ordestination. While creating the MAC header, each node populates its 48 bit MACaddress in either SA or TA based on whether the node is the originator of theframe or the forwarder of the frame. This address can leave a trace of the nodein the network. An attacker monitoring the network at a frame level can alwaystrace an individual node with the help of these identifiers. In order to provideanonymity for the node, this address should be randomized.

3.1.2 WAVE networking services

These services provide the functionality of the addressing and data deliveryin the WAVE system. These services are comprised of the layers 3 and 4 in theOSI reference model (From figure 3.1). WAVE networking services allow thehigher level applications (including both safety and non safety applications) tocommunicate with the WAVE communication stack. The specific functionalitiesof the Logical Link Control (LLC), Network and transport layers are documentedas IEEE standard 1609.3 [22] and the services are collectively known as WAVEnetworking services. [22] also defines the message formats that must be usedwhen two WAVE entities communicate with each other.

The services provided can be broadly classified into Data plane servicesand Management plane services. Data plane carries the data traffic in theWAVE system. It includes two communication stacks WSMP for time sensitive,high priority messages and the traditional IPV6 stack for less demanding datamessages over Transmission Control Protocol (TCP)/User Datagram Protocol(UDP). Both of these stacks function on top of a single LLC layer which makesit easier to switch between multiple channels and send high priority WSMPmessages without any delays[19] . The services provided by the ManagementPlane are collectively known as WAVE Management Entity (WME). Theseservices include,

• Application registration – which helps any provider who wants to providea service through the WAVE system to register the application(WAVE BasicService Sets (WBSS)) with WME

• Management – WME manages the setting up and maintenance of thedifferent applications provided by the WAVE system collectively known asWBSS


Figure 3.3: WSM Package format[22]

• Channel Usage monitoring – service which manages efficient selection ofchannels to transmit the data

• Machine Information Base (MIB) monitoring – WME manages the informa-tion about the device in the MIB database attached to each device in thenetwork.

The IEEE standards document [22] chapter 7 defines the message structures usedfor advertising and joining the services provided by the service provider. Theservice provider has to register the service with the WME. Then the WME in theRSUs advertises the available services using WAVE Service Advertisement mes-sages (WSA). WSAs are transmitted via CCH. A vehicle node/user receiving theadvertisement, if interested in the particular service can listen to the particularradio signal based on the information received on the WSAs. User also sendsa service request to the provider where the provider makes an entry to theUserServiceRequestTable so that the user will receive the service data. Upon reg-istration, data like UserAvailableSourceMacAddress, UserAvailableIpv6Address,UserAvailableTxLatitude, UserAvailableTxLongitude, UserAvailableTxEleva-tion, UserAvailableLifetime, will get registered with the provider. The user usesProvider Service ID (PSID) to identify a particular service provided by the ser-vice provider. Once registered, if the service employs IPV6, the subsequent datatransfers will be performed on SCH. The complete list of data being transmittedand stored is listed in [22] annex A. Figure 3.3 shows the generation of a WSMpackage.


Figure 3.4: Components of WAVE RM [23]

In summary, when considering with the privacy of the user node, the MACaddress and IPV6 address of the nodes are the identifiers that can be used by theadversary to track the individual node. In order to provide anonymity, theseidentifiers should be randomized.

3.1.3 WAVE resource manager

WAVE Resource Manager (RM) manages the access to the system resources ofa WAVE device. If any service wants to read or write to a WAVE device, theseservices are managed and facilitated by WAVE RM. The WAVE RM is located onRSUs and OBUs.

Figure 3.4 shows the components in a WAVE RM. It includes ResourceManagement Applications (RMAs) which is located on remote computers, whichwants to interact with applications installed on the OBUs. The RM on the RSU,which acts as a broker helps to send the Application Protocol Data Unit (APDU)from RMA to the on-board device or application. On the OBU, resides a softwarecomponent Resource Command Processor (RCP) which executes the commandsend by the RM on behalf of the RMA. The RCP processes the requests byinteracting with the system resources and sends appropriate responses to theRM which is then forwarded back to the RMA. The different services providedby the RM are documented as IEEE Standard 1609.1 [23] . The IEEE standardsdocument 1609.1 [23] also describes the structure of the APDUs used by the RMto communicate between RMAs and RCPs. It also defines several response codesthat the RCPs can respond based on the command processed.

The APDUs defined by the standard does not include any data that canbe used for identifying/tracking individual user nodes. As far as privacy isconcerned, no field needs to be randomized for anonymity.

WAVE Security Services – As we discussed in chapter 2, the messages trans-mitted and stored in a WAVE system is vulnerable to several security attacks


Figure 3.5: Sample Signed Message [24]

such as spoofing, alteration, eavesdropping and replay. Also, as the WAVEdevice which process and transmits these messages are deployed on personalvehicles which are often driven by same individual. If not protected fromunauthorized access and link-ability an adversary could use these messagesto infringe the privacy of individual users of the system. While designing theWAVE communication stack, the designers gave utmost priority for securing themessages in the WAVE system. As we can see from figure 3.1, WAVE providessecurity services for securing both the application messages and managementmessages. These services are collectively known as WAVE Security Servicesand are documented in IEEE 1609.2 Standard [24] . The standard explainsthe structure of secured message, how to process each secured message uponreceptions, how the certificates are used, how to use Certificate RevocationLists (CRLs).

Figure 3.5 shows the structure of a signed message in WAVE System. Eachmessage has a signature attached with it which is the hash value of the messageencrypted using the private key of the user. This provides authentication,integrity and non repudiation to the message. Thus the receiving node canmake sure that the message originated from an authorized node, the message isnot being tampered on transit and the message is in fact sent by the originatoras the signature is signed using the originators private key.

However when it comes to privacy, an attacker could use these signaturesto link the messages sent by the same node. If the adversary can successfullydecrypt the signature by using the public key of the user, the adversary canmake sure that the message in fact came from the individual user. This couldbe a vulnerability that could cause privacy breach. This vulnerability has beentackled by the use of pseudonym approach proposed by the SeVeCom project

24 etsi its-station osi protocol stack 3.2

discussed in chapter 2. So the pseudonym needs to be changed regularly inorder to provide anonymity.

3.2 etsi its-station osi protocol stackIn 2008, European Telecommunications Standards Institute (ETSI) technical com-mittee Intelligent Transport Systems (ITS) started the works for standardizingthe Vehicular Communication (VC). The researches done by several Europeanprojects like CVIS (Cooperative Vehicle-Infrastructure Systems), Safespot (Coop-erative vehicles and road infrastructure for road safety), Coopers (CooperativeSystems for Intelligent Road Safety), Sister (SatComs in Support of Transport onEuropean Roads), laid the ground work for standardizing the communicationprotocols for vehicular environments.

As we discussed previously, in order for a vehicular network to function,it is necessary that the vehicles in the network communicate each other usingdifferent kinds of messages. It is obvious that, only if the vehicles speakthe same language in order to communicate efficiently. Standardization ispart of developing a language that can be understood by each node in thenetwork which allows products from different vendors to operate seamlesslyand efficiently. ETSI ITS developed such a language and is documented as ETSIITS Station reference architecture. The architecture is based on the OSI referencemodel. In this section we will discuss the protocol architecture proposed byETSI ITS. The standardization efforts started in 2010 and are in the draft stage.

Figure 3.6 shows the ITS station reference architecture defined by ETSI. Thislayered architecture is based on the OSI reference model. The architectureincludes six layers namely, Access Layer, Networking and Transport Layer,Facilities Layer, Application Layer, Management Layer and Security Layer. Theaccess layer is the lowest layer which comprises the functionality of OSI layers 1and 2. Networking and Transport layer sits on top of access layer, and providesthe services of OSI Layers 3 and 4. Facilities layer represents the layers 5,6 and7 of the OSI reference model. Also, the architecture defines three more layersthat do not have a direct counterpart in OSI reference model. The applicationlayer provides the services that enable two ITS-S applications to communicateeach other. The management layer facilitates and manages the communicationsbetween two nodes. The security layer can be considered as a part of themanagement layer and provides the services to secure the messages transmittedby the ITS station. This layer also takes care of authentication and authorizationof nodes and grants access to the MIB database of the nodes. In the next section,we will examine the messages structure being exchanged at each layer of theITS Station Reference Architecture.

3.2 etsi its-station osi protocol stack 25

Figure 3.6: ETSI ITS-C Station reference architecture[25]


Figure 3.7: Access Layer Details [25]

3.2.1 ITSC Access Layer

Intelligent Transport System Communication Protocols (ITSC) access layer pro-vides the services required for the ITSC stations to perform point to point dataexchange. The ITSC Access layer supports several technologies to transmit datafrom one device to another. As we can see from the figure 3.6, some examplesof supported communication mediums are, IR (Infrared), MM, M5, GPS, Blue-tooth, 2G/3G/4G, Ethernet. Figure 3.7 shows the detailed view of ITSC AccessLayer. It includes a physical layer (PHY) which connects the ITS station to thecommunication medium, a data link layer- which supports the functionalityof the MAC and LLC layers, and a management layer which provides differentservices to manages the interactions between the PHY and DLL layers.

In this research we concentrated on the communication over wireless LANtechnology where ITS station communicates with another station using wirelessradio communications. The wireless standards in ITS communication are basedon the IEEE 802.11p standards.

ITS Access layer uses the frame format defined by the IEEE 802.11p standards.Refer to figure 3.2 above for the format of a frame. As we can see from the figure,each frame includes four 48 bit MAC addresses namely Source Address (SA),Destination Address (DA), Transmitting Station Address (TA), and ReceivingStation Address (RA). When considering the privacy of a node in the ITSnetwork, these source address included in the frame can be a source for theattacker to identify an individual node in the network. The attacker could linkthe messages transmitted from the same node and trace the details. In order toprovide privacy to the node, these addresses should be changed frequently andrandomly, preventing the attacker from guessing which MAC address belongto which node.


Figure 3.8: ITSC Networking and Transport layer[25]

3.2.2 ITSC Networking and Transport Layer

This layer provides the services and functionalities that corresponds to the layers3 (Network) and 4 (Transport) in the OSI reference model with amendments toadapt it to vehicular environments. This layer defines the addressing standardswhich allow the higher level applications to communicate to the applicationrunning on another node in the network.

Figure 3.8 shows the detailed view of ITSC networking and Transport layer.As the figure shows, it has got three components Network Layer Protocols,Transport Layer Protocols and Network and Transport Layer Managementprotocols.

ITSC networking layer supports two types of networking protocols namelyGeo-networking protocols and IPV6 Protocols. Geo-networking protocols areused to transmit high priority time sensitive messages where as IPV6 protocolssupport the traditional and less demanding exchanges. Both protocols, providesservices to the upper transport layers to transport the message packets acrossthe network. These protocols also use the services provided by the Access layerto perform the actual transmission.

ITSC transport layer supports several transport layer protocols like TCP, UDPand other ITSC specific transport protocols. Transport layer protocols provideservices to the process running at the facilities layer to communicate to theprocesses running on another node in the network. These protocols run inconjunction with the networking protocols to transmit the data packets to thedestination node.

The management Layer provides the interfaces to coordinate the messagesexchanges between transport and networking services.


Figure 3.9: Geo-networking address format [27]

Figure 3.10: Geo-networking packet structure [27]

Geo-networking protocols

Geo-networking protocol standards are standards defined by ETSI designedspecifically for the dynamic vehicular networks. As we discussed in the previoussections, because of the highly dynamic nature of the vehicular environments(for example, frequently changing network topography, very less amount oftime for handshaking and exchanging messages) makes it difficult to use thenormal TCP/IP protocol suites in the vehicular environments. ETSI networkingwork group came up with a set of protocols that could handle high prioritytime sensitive messages efficiently. These protocols are called Geo-networkingprotocols. Some of the services provided by these protocols include [26] ,addressing the nodes in the network, forwarding the packets through thenetwork, building the ad-hoc network based on the location data sent by eachnode. Now we will discuss the package structure used by the geo-networkingprotocols.

Every geo ad-hoc router [routers used in ITS hosts] enabled for geo-networking,have a unique geo-networking address (GN_ADDR). The format of a geo-networkingaddress is given in figure 3.9

M – Represents whether the address is manually configured or not. ST – ITSstation type, SST – ITS Station subtype, SSC – ITS station country code, MID –ITS station identifier. In the case of 802.11p the MID can be 48 bit MAC address.Figure 3.10 shows the structure of a generic geo-networking packet.

MAC header denotes the header of the MAC protocol of ITS access technology.MAC Header along with the LLC header to define and identify the next hop. Geo-Networking header comprises of two parts as shown in figure 3.11, CommonHeader and Extended Header (structure discussed in next section). The Geo-networking security header includes the fields for securing the packet. Thepayload carries the actual data. As we can see from the figure 3.11, payload isoptional, because some packets like the beacon messages do not require anypayloads.


Figure 3.11: Geo-networking Header structure [27]

Figure 3.12: Common Header Structure [27]

The common header structure shown in figure 3.12 includes several fieldslike; NH- determines the type of header immediately following geo-networkingheader, PL – Length of the header payload, TC – represents the traffic class, HL-Hop limit, SE PV- Sender Position Vector (PV). The standards document [27]describes the purpose and valid values of each fields in detail. For the analysisrelated to privacy, we are interested in the SE-PV field. Position vector includesthe position related details of the node which is transmitting the packet. Thereare two types of Position Vector (PV) used in a Geo-Networking packet, LongPV (Figure 3.13) and Short PV (Figure 3.14).

The Long PV is comprised of GN_ADDR – Geo-Networking address whichwe discussed earlier, TST- Time at which the latitude and longitude is recorded,Lat- Latitude of the router, Long- Longitude of the router, S- Speed of router, H-Heading, Alt – Altitude of the router, TAcc – Accuracy indicator of TST, PosAcc– Accuracy indicator for Lat and Long fields, SAcc- Speed Accuracy, HAcc,Heading accuracy, Alt- Accuracy indicator for Altitude. Figure 3.14 shows theshort PV structure which includes GN_ADDR, TST, Lat and Long fields.

From the analysis of the geo-networking packet structures, it is obviousthat the GN_ADDR present in the long/short PV carries the node specific MACaddress and information like speed, heading, latitude and longitude of thenode. And adversary could use this information to link the messages from an

Figure 3.13: GN Long Position Vector [27]


Figure 3.14: GN Short Position Vector [27]

Figure 3.15: BTP Packet Structure [28]

individual node and there by trace the node in the network. In order to provideanonymity, the MAC address needs to be changed at regular intervals whichmake it difficult for the adversary to co-relate the messages easily.

Basic Transport Protocol(BTP)

Basic Transport Protocol (BTP) is the transport layer protocol defined by the ETSIITS OSI standards. BTP provides end to end connection to the processes runningon ITS hosts in the ITS network. BTP is connection less protocol and does notguarantee the delivery of the packet similar to UDP. The applications runningat the ITS facility layer uses the services provided by the BTP to communicate tothe Geo-Networking protocol. Figure 3.15, shows the structure of a BTP packet.Each packet carries a BTP header. There are two types of BTP headers defined aspart of the standard. BTP-A and BTP-B. BTP-A Header contains two fields

• Destination Port : Identifies the port used by the ITS facility layer at thedestination.

• Source Port: Identifies the port used by the ITS facility layer at the source.

BTP-B Header contains two fields

• Destination Port: Identifies the port used by the ITS facility layer at thedestination

• Destination Info: More information about the destination port, if the portis a well known port.

When considering user privacy, the port number associated with each packetin co-relation with other information can be used by the adversary to relate anode accessing a particular service from ITS service provider. At the time of


pseudonym change, an attacker can use this type of info to figure out whichnode changed from one pseudonym to the other pseudonym. We will lookmore into these kinds of attacks in Chapter 4.

ITS Facilities Layer

ITSC Facilities layer provides the services and functionalities defined by the OSIlayers 5, 6 and 7; which includes the OSI session layer (services for managingsessions between inter-host communications), OSI presentation layer (whichincludes the services like encoding, decoding and encryption of applicationdata) and the OSI application layer.

The services provided by the ITSC facilities layer includes amendmentsfrom the traditional services provided by the layers 5, 6 and 7 to make itsuitable for the vehicular environments. ETSI standards document [25] classifiesthese services into Application Support services, Information support services,Communication Support Services, Session Support services and facilities layermanagement services.

Examples of services classified as Application Support services include,

• Station Positioning and time management support service- Services thatprovide the geographical position and time of the ITS station

• Location Dynamic Maps (LDM) support services – applications that pro-vide digital mapping services with dynamic updates

• Security and Access management services

• Station state monitoring services

• Messages Management services – which manages the data exchangebetween the ITS station applications

There are two types of messages defined by the ETSI ITS standards, Decentral-ized Environmental Notification Messages (DENM) – which are messages triggeredwhen some events are detected in the environment like accidents, emergencybreaking and Co-operative awareness messages (CAM) – messages periodicallybroadcasted aimed at networking requirements and road safety. CAMs are usedfor detecting neighbor nodes and setting up the ad-hoc network [25].

Information support services include services like LDM database support,data presentation, location referencing, station type/capabilities. Communica-tions support services provides the message transmission functionalities likebroadcasting, geo-casting, local unicast and global unicast.

Document[29] defines the ASN1 encoded format of CAM message as shownin figure 3.16.


Figure 3.16: ASN1 encoded CAM message format[29]

3.3 car2x communication architecture 33

The station ID field present in the format is a unique identifier that identifieseach node in the network. Station ID is part of the lower layer headers thatwe discussed in the geo-networking address(Refer 3.2.2) previously. Whenconsidering the privacy of the node, the Station ID present in the CAM messagescould be a potential data that the adversary could use to track messagestransmitted from a node.

ITSC Management Layer

As we can see from the figure 3.6, the Management layer spans across thethree layers access, networking and the facilities layer. Management layer doesnot have a corresponding layer in the OSI reference model. ITSC managementlayer provides five major services namely Application management, StationManagement, cross-layer management, Regulatory management and MachineInformation Base (MIB) management [25]. Application management refers tothe management of ITSC applications including installation, configuration andmaintenance. This may also include services to handle the application errors andsafeguarding from harmful applications. Station management services providethe functionality of identity and access managements. Cross layer managementfacilitates seamless interaction between the different ITSC protocol stack layers.Regulatory Management manages the regulatory information based on the needsfrom the access layer. ITSC Management layer also includes the functionalitiesto maintain the MIB database present in each ITS node.

3.2.3 ITSC Security Layer

ITSC security layer provides the security functionality to the different layersin the ITSC protocol stack. According to the standards document [25] thesefunctionalities include, firewall and intrusion detection, authentication autho-rization and identity management, crypto key and certificate managing servicesand the hardware security module that stores the secret keys and prevents thetampering of the device. Each layer in the ITSC protocol stack has interfaces tothe security layer and can use the services provided by the layer to ensure thesecurity of the messages transmitted from the ITS node.

3.3 car2x communication architectureIn 2006, key players in the vehicle manufacturing industry formed a workgroupnamed as Car2Car Communication Consortium (C2C-CC) aimed at building acommon communication platform, where the vehicles from different manufac-

34 summary 3.4

turers can communicate with each other. The consortium included membersfrom Volkswagen, BMW, Daimler Chrysler, Opel, Fiat, Renault, Honda, Hitachi,EFKON, Fraunhofer Germany [30] . The objectives of the consortium included,creation and establishment of protocol standards for vehicles inter-operability,developing safety applications which electronically widens the divers horizonand enables new safety functions like hazard warnings, traffic information,pre-crash sensing/warning and also developing strategies for deployment andmarket penetration [3].

Figure 3.17 show the protocol architecture developed by the Car2Car Com-munication Consortium (C2C-CC). The protocol stack design is based on the OSIprotocol reference model. According to C2C-CC manifesto [3] the applicationsthat uses the C2C-CC communication stacks are broadly classified into threenamely,

• Active Safety applications

• Traffic efficiency applications

• Infotainment applications

Also, as we can see from the architecture, C2C-CC provides two stacks, onefor transmitting fast and reliable safety messages and one for transmittingtraditional less demand non safety application traffic as in the case of info-tainment. Active safety application and Traffic efficiency application messagesare considered high demand traffic and uses C2C-CC stack and Infotainmentapplication uses the traditional TCP and UDP over IPV6 stack. Safety applicationstraffic has the priority and can transmit messages over both the stacks. Thearchitecture also includes an Information Connector block which facilitates thecommunication between the protocol stack layers.

According to [3], the C2C-CC communication stack uses IEEE 802.11p at thePhysical and MAC/LLC layer and IEEE WAVE 1609.x standards for C2C-CCNetwork and C2C-CC Transport layers. These standards are already discussedin chapter 3.1. Please refer back for the details.

3.4 summaryIn this chapter, we analyzed different communication standards used in thevehicular environments with respect to privacy of a vehicular node on thenetwork. We also analyzed the messages; packets and frame formats used bydifferent layers of the protocols stacks in the three different communicationstandards. These protocols uses two separate stacks, one to handle high prioritytime sensitive messages like beacon messages, emergency signals, accident

3.4 summary 35

Figure 3.17: Protocol Architecture of the C2C-CC System[3]

warning signals and another to handle less demanding traffic such as internettraffic. From the analysis, we could find that many identifiers used by thedifferent layers could be vulnerable to privacy related attacks. An attacker whois analyzing the data packets in the network could use these identifiers to linkmessages transmitted from individual nodes. This can lead to serious privacybreaches. Of the identifiers analyzed, the most vulnerable ones where theMAC address of the node, IPV6 address of the nodes, the cryptographic certificatesattached with the messages for security purposes. It is evident from the studiesthat, in order to provide a good level of anonymity, the pseudonym changesmust be accompanied by a change in these identifiers.

Assuming that the system change these identifiers periodically preventingthe attacker from making a successful linkage between the messages transmittedby an individual node, are there scenarios where the attacker could still makeout a relation between the messages sent. We will explore more into thesescenarios in the next chapter.

37

4 N E T W O R K I D E N T I F I E R M A N A G E -M E N T

4.1 introductionIn the previous chapter, we analyzed different Vehicular Communication proto-col standards and identified potential data fields in the layer headers that couldlead to privacy breach of the individual nodes. It is obvious from the researchthat a change in the pseudonym at the upper level of the communication stackmust be accompanied by the change in the identifiers in the lower layer stacks.However, the question remains whether the problem is solved by changing theidentifiers. Are there exists any scenarios where the adversary could use otherinformation from the node to establish linkage between the messages from thatnode even after the changing the identifiers. This chapter explores the scenariosto analyze the vulnerabilities that could lead to a privacy breach. This chapteralso discusses solutions to fix those vulnerabilities and the solution will beintegrated to the PRESERVE project.

4.2 vulnerability analysisFor analyzing the vulnerability, we considered the scenario given in figure 4.1.A car travels from point A to point B. The car is pre-loaded with k pseudonyms.The car changes the pseudonyms at regular intervals and encrypts all its trans-mitted data with the new pseudonym as shown in different colors in the path.The pseudonym change is accompanied by a change in the lower layer identifiersas well. Now suppose the car was using a non safety application, for example,accessing a web server, and the session spans over multiple pseudonym change.We would assume that the attacker is performing a packet level monitoringon the network and is interested in linking the messages transmitted from anindividual node and tracing the location of the node. We further assume thatthe attacker already knows he identifiers (PNYM_1, IP_1,MAC_1) used by theindividual node during the time t marked in orange color in the figure. Duringtime t the attacker can successfully identify the packets transmitted by the nodeusing the identifiers. After t + ∆t time, the node changes the identifiers to

38 risk analysis 4.3

Figure 4.1: Attack Scenario

(PNYM_2, IP_2,MAC_2) [marked green in the figure] and started encryptingall its messages with the new pseudonyms. It will be difficult for the attackerto guess which node changed to which identifier. This provides anonymity tothe nodes in the network.

4.3 risk analysisIn the above scenario, as we can see from the figure, the node is connected to aweb server (for e.g. watching a video or paying bills through online) and theHyper Text Transfer Protocol (HTTP) session spans over multiple pseudonymchanges. Ideally, once the node changes the pseudonyms to the new one, thenode should be anonymous to any attacker monitoring the packets. However,in this scenario, the HTTP session that is running between the node and theweb server can be used by the attacker to guess which node changed to newpseudonym. As an example, suppose the node was downloading a video fromthe YouTube1 server. The packets sent out from the node will have YouTubeserver IP as the destination IP field and port 80 at the destination port field.For time t [marked in orange in the figure], the node was using identifiers(PNYM_1,IP_1,MAC_1) and after ∆t time the node changes its identifiers to(PNYM_2,IP_2,MAC_2). After the pseudonym change, the attacker is cluelessof which node changed to which pseudonym, however, if the node againtries to connect to the same server for downloading data, the attacker couldguess with more confidence that the particular node changed its identifiersfrom (PNYM_1,IP_1,MAC_1) to (PNYM_2,IP_2,MAC_2). Once the attackerestablishes a linkage between the messages, he could trace the location of the

1 Online video sharing website http://www.youtube.com/

4.4 proposed solution 39

Figure 4.2: ID Change Management Module

node and breach the privacy of the node.

4.4 proposed solutionBased on the analysis performed, it is apparent that the pseudonym changeat the application layer must be accompanied by a change in the lower layernetwork identifiers as well. Also the analysis showed that even with thechange in the network identifiers, there are scenarios where the attacker couldsuccessfully link the messages transmitted from an individual vehicle and canbreach the privacy of the user. These gaps in the design of the secure vehiculararchitecture must be tackled before implementing the devices. Fixing thesevulnerabilities provides a higher level of anonymity to the node in the networkand higher level of privacy.

The proposed solution is to include a new module called Identifier ChangeManagement (IDCM) module in the PRESERVE architecture as shown in thefigure 4.2. As we can see from the figure, the module gets the inputs from thePseudonym Manage Module (PMM) in the PRESERVE architecture and interactsdirectly with the Vehicular Communication (VC) stack.

40 design 4.5

4.5 designBased on the researches done, the primary function of the module is to generatenew identifiers (IP and MAC) and update it to the communication stack. Themodule must be triggered on a pseudonym change event on the PseudonymManage Module. From the assessment done on the scenario discussed in thebeginning of this chapter, it is clear that, there are some situations where theattacker could in effect nullify the privacy obtained through a network IDchange. In such scenarios, the attacker could use other information [like thedestination IP and PORT number] to find out which node changed to whichID and there by trace the individual user. The module must be smart enoughto check whether it is appropriate to change the identifiers at a given time.For example, in the scenario discussed above, it is not advisable to change theidentifiers while an HTTP session is running as this could expose a vulnerabilitythat could lead to privacy breach of the node. However, there are some situationswhere we need maximum privacy. In those situations, the module must be ableto change the identifiers regardless of any sessions running or not. The modulemust be able to log all the changes, so that the log file can be investigated incase of any incidents. The requirements can be summarized as,

1. The module can be invoked from the pseudonym manager in two modes

2. (a) Mode 1: mandatory mode [change the IDs regardless of any runningsessions]

(b) Mode 2: recommended mode [change the IDs only if no sessions arerunning]

3. Check for active sessions currently running on the system. [HTTP, HTTPS,FTP..]

4. Generate new IP address

5. Generate new MAC address

6. If In Mode 1, update new IP address and MAC address to the communica-tion stack

7. Else in Mode 2, update the new IDs if NO active sessions are running.

8. Update the log file with the details for future verification [new IDs, updatetime]

4.6 implementation 41

4.6 implementationFigure 4.4 illustrates the control flow of the ID Change management module.The module is triggered on a pseudonym_change1 event from the pseudonymmanage module(Refer Section 2.4). The module first checks the mode in whichit is invoked. In –m[mandatory] mode, program generates new IP address andnew MAC address, bring down the interfaces down, update the new IP and MACaddress to the stack, then bring up the interface again. On successful update,the log file is written with the details of the new identifiers and the time of thechange. If for some reason update fails, the error message is written to the logfile. In -r [recommended] mode, program will check for any active sessions (forexample, http, https, ftp) running currently on the device. If any sessions arerunning, the programs stops execution and will not generate and update newidentifiers. In case of no active sessions, the control flows through the stepsdescribed in the mandatory mode execution. The module is developed using Cprogramming language and is designed to work on Ubuntu based systems.

4.7 testing and results

4.7.1 Limitations

Because of the restrictions in accessing the PRESERVE implementation server,testing was performed using programs that simulated the vehicular commu-nication stack functionalities.Also due to the limitations with the devices thatsupported IPV6 addressing in the lab environment, we conducted the experi-ments using IPV4 network address on the packets.

4.7.2 System Configuration

1. System - HP Pavilion dm4 Notebook PC

2. Processor - Intel(R) Core(TM) i5 CPU M430 @ 2.27GHz

3. Installed Memory(RAM) - 4.00GB(3.80GB usable)

4. Host OS - Windows 7 Home Premium

5. Virtual machine - VMWare Workstation 8

6. Guest OS - Ubuntu 12.04

1 This event is triggered when the system decides to change the pseudonym for privacy purposes.

42 testing and results 4.7

Figure 4.3: ID Change Management Module flowchart

4.7 testing and results 43

Figure 4.4: Geo-Unicast packet structure.[27]

7. RAM allocated to guest OS - 1 GB

4.7.3 Modules

As part of the thesis we developed two modules, SendPacket.c which can sendGeo-networking packets based on the ETSI geo-networking packet structures,and ReceivePacket.c module to receive and parse the Geo-networking packets.Please refer to the code documentation [Published as separate file] for codedetails.

4.7.4 Simulation

In the simulation setup, the program was designed to send multiple unicastgeo-networking packets in a time interval of 1 sec. The Geo-unicast1 header wasconstructed based structure shown in figure 4.4. The Common Header, SO-PV(Source Position Vector) and DE-PV (Destination Position Vector) structures arediscussed in the previous chapter. SN represents the packet sequence numberand LT represents the lifetime field. At the receiving end, the program willlisten to the packets addressed to particular Mac address. Once the packet isreceived, the program parses it and displays the content inside the packet.

The sendPacket.c program was designed to invoke IDCM module after every5 packets. Once the IDCM module is invoked, the module updates the communi-cation stack with new MAC and IPV4 address. Now the next packet send fromthe program will be constructed using the new identifiers. The IDCM modulelogs the new identifiers and the time of change to a log file for future reference.At the receiving end, we can see the details inside the packet and can see thepackets being received with the new network identifiers once the update ishappened.

1 Packets send from a source to destination.

44 testing and results 4.7

Figure 4.5: Sample output of the receivePacket.c

Figure 4.6: Sample output of the receivePacket.c with IP and UDP

4.8 performance evaluation 45

Figure 4.7: Snippet of the log file created at the sender.

4.7.5 Results

Figure 4.5 and 4.6 above shows the sample outputs from receivePacket.c. Figure4.5 shows the details of the packets received with geo-networking header andFigure 4.6 shows the details of packets with both Geo-networking, IP and UDPheaders. As we can see from the screen-shots, the network identifiers are gettingchanged after every 5th packet. The figure 4.7 shows the snippet of the logfile created at the sender side. The program logs the new network identifiersand the time at which the change happened. This log file can be used for crossreference in the future if authorities want to trace back the origin of the packets.

4.8 performance evaluationTable 4.1 shows the performance of the different modules used for testing. Fromthe experiments conducted, the IDCM module takes 1.3 seconds to execute withstandard deviation of 81 milliseconds. The mean and SD of execution timesof the sending and receiving geo-networking packets are calculated over 100samples. The execution time of IDCM module is calculated over 20 samples (oneinvocation per 5 packets).

Execution time in milliseconds Mean Variance Std DevCreating and sending GN packet 0.1321500 4.0788 0.0638658Invoking ID Change Management module 1338.8 6650600 81.551Receiving and parsing GN packet 0.00685 0.0897045 0.0094712

Table 4.1: Execution time for different modules in milliseconds

46 performance evaluation 4.8

Figure 4.8: Distribution of execution time - Sending packets

Figure 4.8 shows the distribution graph of the execution times of the sendermodule that created and send the geo-networking packet.The module executedwith an average time of 0.132 ms.

Figure 4.9 shows the distribution graph of the execution time of the receivepacket module for receiving and parsing a geo-networking packet.

Figure 4.10 represents the execution times of the IDCM module over 20 invo-cations. On an average the module took 1.3 seconds to finish execution. Wefurther investigated the processes inside the IDCM module that contributes tothe 1.3 seconds, and we noticed that the process of bringing the interfaces downand up is consuming large portion of the execution time. We calculated theexecution times of these processes. Figure 4.11 shows the detailed executiondelay analysis of the IDCM module execution delay. As we can see from thegraph, most portion of the total execution time is spend on bringing down andup the interface to re-configure it with the new network identifiers. We triedupdating the identifiers without bringing down the interfaces, but the devicedoesn’t supported this functionality. The module was failing the IOCTL() callwhile trying to update the new identifiers. Also another factor to take intoconsideration for the delay is the environment(Refer section 4.7.2) that the testis conducted. Suggestions to improve the efficiency include

• Use devices that doesn’t requires interface to be brought down in-order toupdate the network identifiers.

• Running the modules outside the virtual environment for example on the

4.9 reflections 47

Figure 4.9: Distribution of execution time - Receiving and Parsing GN packets

actual VSS box(This test is planned for the future work of this thesis).

4.9 reflectionsThe level of privacy of a user in the vehicular network can be expressed as theability of the adversary to link the messages transmitted from the individualusers. It can be expressed as the probability of the adversary guessing thecorrect packet received from a tracked vehicle. To understand this, we canconsider a simple scenario as shown in figure 4.8.

We have two cars A and B going in the same direction. Car X, which is anadversary, intercepts all the messages M from car A to track the vehicle. Car Xuses the network identifiers inside each packet (MAC address, IP address) forlinking the packets that come from the same car. The adversary doesn’t neces-sarily have to follow the victim physically in order to intercept the messages.This can be done either through deploying malicious programs to the victim’scar that sends the data to adversary or by accessing the messages through theroad side unit infrastructures alongside the roads. But for simplicity sake, wekeep the scenario like this. After time t, a pseudonym change event happenedat car A, which in turn changed the network identifiers of the car A. After thechange, the messages transmitted from car A will carry the new identifiers.

Once the adversary receives a new message M, what is the probability that

48 reflections 4.9

Figure 4.10: Distribution of execution time - IDC

Figure 4.11: Distribution of execution time - IDC - Detailed Analysis

4.9 reflections 49

Figure 4.12: Model Scenario

the new message M belongs to car A or car B. Let E be the event of an adversarycorrectly guessing the origin (using network identifiers) of the packet. Let theprobability of E be P(E). Let us assume that the 48 bit MAC address is the onlynetwork identifier in the packet (like in the case of MID in the Geo-networkingpackets considered in testing section above). P(E) = 1 before the pseudonymchange occurred as the adversary already knows the MAC address of the car

A, and after the pseudonym change, the probability reduces to P(E) =1

224(the first 24 bits of the device MAC address are usually reserved by the devicemanufacturer and only the last 24 bits is changed).One thing to note here isthat the first 24 manufacturer specific bits of the MAC address can be a potentialdata for the adversary to link the messages sent from a car. In the case of IPaddress, P(E) depends on the number of bits that gets changed by the program.

P(E) is calculated as1

2nwhere n represents the number of bits changed to form

the new IP (Assuming the network part of IP address is kept constant). Forexample, our ID change management module was designed to change the hostbits of a class C IPV4 address. In this case, last 8 bit represents the host bit and

then P(E) =1

28.

Following things where observed from the results. The sequence numberfield in the Geo-networking address (field SN in figure 4.4) can be a potentialdata field that could be used by the adversary to establish a linkage betweenthe messages. The sequence number should be re-initialized using a randomsequence after the network identifier change. If the packet contains a TCP ora UDP data-gram, the port number inside the data-gram headers can also bea potential data field which the adversary can look into for establishing thelinkage between the messages. This issue can be solved using random portnumbers after every network ID change and port forwarding filters can be usedto filter the packets to the corresponding port. Another challenge that needs tobe addressed is the conflict resolution of the newly generated MAC address andthe IP address.

As we can see from the results, that the probability of an adversary guessing

50 reflections 4.9

the correct address reduces significantly, when the messages are anonymizedusing new network identifiers, and reduces the ability of the adversary to linkthose messages. The more the messages are un-linkable, the more user privacy.

51

5 C O N C L U S I O N A N D F U T U R E W O R K S

5.1 conclusionIn summary, this research explored the implications of the privacy enhancementtechniques on the vehicular communication protocol stacks. We discussed theprivacy enhancement techniques proposed by different EU projects (PRECIOSA,SeVeCom, and PRESERVE). Then we discussed about the protocol standardsdesigned specifically to be used in vehicular environments (IEEE WAVE, ETSI ITSCStation OSI protocol and C2C-CC Standards). We analyzed the layer headers toidentify data fields that could be used by the adversary to track the individualnodes and there by breaching the user’s privacy. This research underlinedthe importance of changing the identifiers at the lower layers of the stack,when the pseudonym is changed at the application layer for enhancing privacy.Then we modeled scenarios where, even after the change in the identifiers, theadversaries being able to link the messages sent from individual nodes and alsothe privacy risks involved in those scenarios. Finally, we designed and built asoftware module that can be integrated to the PRESERVE architecture that tacklesthe vulnerabilities discovered as part of this research and enhances the userprivacy in vehicular networks

5.2 future worksFor the future work, we will implement the ID change management modulein the V2X Security subsystem (VSS)[31] being built as part of the PRESERVEproject. Testing the module in real vehicular environments will help to get moreaccurate measurement on the efficiency and performance of the module. Basedon the feedback from the tests, the module can be fine tuned. Also, currentlymost of the Vehicular Communication standards are still under developmentstages. The analysis that we did on the VC protocol stacks was based on thestandards document currently available. As the standards are not finalizedand are still evolving, future studies must incorporate any changes that areincluded to the standards. For example, addition of any new data field to thenetwork layer headers which can identify individual users on the network mustbe analyzed and dealt accordingly to preserve user privacy.

B I B L I O G R A P H Y

[1] P. Papadimitratos, G. Calandriello, J. Hubaux, and A. Lioy. “Impact ofvehicular communications security on transportation safety”. In: IEEE.Phoenix, AZ, USA: 28th IEEE Conference on Computer Communications(INFOCOM) Workshop on Mobile Networking for Vehicular Environ-ments (MOVE), Apr. 2008, pp. 1–6 (cit. on p. 1).

[2] G. Calandriello, P. Papadimitratos, J. Hubaux, and A. Lioy. “Efficient androbust pseudonymous authentication in VANET”. In: ACM Press. NewYork, NY, USA: Fourth ACM international workshop on Vehicular Adhoc Networks (VANET 07), 2007, pp. 19–28 (cit. on pp. 1, 3).

[3] C2C-CC Technical-Committee. CAR 2 CAR Communication ConsortiumManifesto. report. 2007 (cit. on pp. 2, 34, 35).

[4] P. Papadimitratos et al. “Secure vehicular communication systems: designand architecture”. In: Communications Magazine, IEEE 46.11 (Nov. 2008),pp. 100–109. issn: 0163-6804. doi: 10.1109/MCOM.2008.4689252 (cit. onpp. 2, 3, 11, 12).

[5] F. Kargl, E. Schoch, B. Wiedersheim, and T. Leinmüller. “Secure and Effi-cient Beaconing for Vehicular Networks”. In: The Fifth ACM InternationalWorkshop on VehiculAr Inter-NETworking (VANET 2008). ACM. 2008 (cit. onp. 3).

[6] F. Kargl, F. Schaub, and S. Dietzel. Mandatory enforcement of privacy policiesusing trusted computing principles. Universität Ulm, Fakultät für Ingenieur-wissenschaften und Informatik, 2010 (cit. on pp. 7, 8).

[7] EU, Directive. “Directive 95/46/EC of the european parliament and of thecouncil of 24 October 1995 on the protection of individuals with regard tothe processing of personal data and on the free movement of such data”.In: Official Journal L 281 281.23/11 (1995), pp. 0031–0050 (cit. on p. 8).

[8] EU, Directive. “Directive 2002/58/EC of the European Parliament and ofthe Council of 12 July 2002 concerning the processing of personal dataand the protection of privacy in the electronic communications sector”.In: Official Journal L201 201.31 (2002), p. 07 (cit. on p. 8).

[9] S. Fischer-Hübner. IT-security and privacy: design and use of privacy-enhancingsecurity mechanisms. Springer-Verlag, 2001 (cit. on p. 8).

[10] PRECIOSA. Consortium Members. 2012. url: http : / / www . preciosa -

project.org/consortium (visited on 26/11/2012) (cit. on p. 8).

53

http://dx.doi.org/10.1109/MCOM.2008.4689252

http://www.preciosa-project.org/consortium

http://www.preciosa-project.org/consortium

54 bibliography

[11] PRECIOSA. Objectives. PRECIOSA, 2012. url: http://www.preciosa-project.org/objectives (visited on 26/11/2012) (cit. on p. 8).

[12] “Research contribution to V2X privacy and roadmaps”. In: PRECIOSAFP7 Project Deliverable D16 (Nov. 2010). url: http://www.preciosa-project.org/deliverables (cit. on p. 9).

[13] “Research contribution to V2X privacy and roadmaps”. In: PRECIOSA FP7Project Deliverable D11 (Nov. 2010), pp. –35. url: http://www.preciosa-project.org/deliverables (cit. on pp. 9, 10).

[14] P. Papadimitratos, M. Fiore, C. Casetti, and C. Chiasserini. “Secure neigh-bor position discovery in vehicular networks”. In: 2011 The 10th IFIPAnnual Mediterranean Ad Hoc Networking Workshop. IEEE. 2011, pp. 71–78(cit. on p. 10).

[15] SeVeCom. SEVECOM Consortium Members. SeVeCom, 2012. url: http://www.sevecom.org/Pages/Members.html (visited on 26/11/2012) (cit. onp. 11).

[16] F. Kargl et al. “Secure vehicular communication systems: implementation,performance, and research challenges”. In: Communications Magazine, IEEE46.11 (Nov. 2008), pp. 110–118. issn: 0163-6804. doi: 10.1109/MCOM.2008.4689253 (cit. on p. 11).

[17] F. Kargl. “Enforceable Privacy with PRECIOSA”. In: ITS World Congress2009 SIS 46: Privacy and Data protection within ITS, Stockholm. 2009 (cit. onp. 12).

[18] P. Papadimitratos et al. “Security Requirements of Vehicle Security Archi-tecture”. In: PRESERVE FP7 Project Deliverable1.1 (June 2011), pp. 1–69.url: http://www.preserve-project.eu/deliverables (cit. on pp. 14,15).

[19] R. Uzcategui and G. Acosta-Marum. “Wave: A tutorial”. In: Communica-tions Magazine, IEEE 47.5 (May 2009), pp. 126–133. issn: 0163-6804. doi:10.1109/MCOM.2009.4939288 (cit. on pp. 17, 18, 20).

[20] R. Stanica, E. Chaput, and A. Beylot. “Enhancements of IEEE 802.11 pProtocol for Access Control on a VANET Control Channel”. In: Commu-nications (ICC), 2011 IEEE International Conference on. IEEE. 2011, pp. 1–5(cit. on p. 19).

[21] IEEE 802.11 Working Group. “Telecommunications and information ex-change between systems-Local and metropolitan area networks-Specificrequirements Part 11: Wireless LAN Medium Access Control (MAC) andPhysical Layer (PHY) Specifications”. In: IEEE Std 802.11-2007 (Revision ofIEEE Std 802.11-1999) (2009), p. C1 (cit. on p. 19).

http://www.preciosa-project.org/objectives

http://www.preciosa-project.org/objectives

http://www.preciosa-project.org/deliverables




http://www.sevecom.org/Pages/Members.html

http://www.sevecom.org/Pages/Members.html



http://www.preserve-project.eu/deliverables


bibliography 55

[22] “IEEE Trial-Use Standard for Wireless Access in Vehicular Environments(WAVE) - Networking Services”. In: IEEE Std 1609.3-2007 (2007), pp. 1–99.doi: 10.1109/IEEESTD.2007.353212 (cit. on pp. 20, 21).

[23] “Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE)- Resource Manager”. In: IEEE Std 1609.1-2006 (2006), pp. 1–71. doi:10.1109/IEEESTD.2006.246485 (cit. on p. 22).

[24] “IEEE Trial-Use Standard for Wireless Access in Vehicular Environments -Security Services for Applications and Management Messages”. In: IEEEStd 1609.2-2006 (2006), pp. 1–105. doi: 10.1109/IEEESTD.2006.243731(cit. on p. 23).

[25] “Intelligent Transport Systems (ITS); Communications Architecture”. In:ETSI EN 302 665 V1.1.1 (Sept. 2010), pp. –2 (cit. on pp. 25–27, 31, 33).

[26] A. Martin. “Towards a pan European architecture for cooperative systems”.In: ed. by A. Martin. ETSI ESP. Presented at 16th ITS World Congress21-25 September 2009, Sept. 2009 (cit. on p. 28).

[27] “Intelligent Transport Systems (ITS); Vehicular Communications; Part 4:Geographical Addressing and Forwarding for Point-to-Point and Point-to-Multipoint Communications; Sub-part 1: Media-Independent Func-tionality”. In: ETSI TS 102 636-4-1 V1.1.1 (), pp. –5 (cit. on pp. 28–30,43).

[28] “Intelligent Transport Systems (ITS); Vehicular Communications; GeoNet-working; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol”.In: ETSI TS 102 636-5-1 V1.1.1 (2011) (cit. on p. 30).

[29] “Intelligent Transport Systems (ITS); Vehicular Communications; BasicSet of Applications; Part 2: Specification of Cooperative Awareness BasicService”. In: ETSI TS 102 637-2 V1.1.1 (2010) (cit. on pp. 31, 32).

[30] W. Christian. Car-2-Car Communication Consortium, Applications WorkingGroup- Current Status. Unpublished Work. Nov. 2006 (cit. on p. 34).

[31] F. Kargl. “PRESERVE Fact Sheet”. In: ed. by D. F. K. |. U. of Twente |The Netherlands. 2012, p. 1. url: http://www.preserve-project.eu/sites/preserve-project.eu/files/PRESERVE-Fact-Sheet.pdf (cit. onp. 51).

http://dx.doi.org/10.1109/IEEESTD.2007.353212



http://www.preserve-project.eu/sites/preserve-project.eu/files/PRESERVE-Fact-Sheet.pdf

http://www.preserve-project.eu/sites/preserve-project.eu/files/PRESERVE-Fact-Sheet.pdf

pseudonymity in vanets and its implications on the vehicular communication protocol...

Documents