Security Infrastructure for VANETs

8/14/2019 Security Infrastructure for VANETs

1/6

Security Infrastructure for VANETs

Ashwin Rao2006ANY7513

Project Supervisor: Dr. Arzad A Kherani

Abstract

The primary objective of vehicular ad hoc networks (VANETs), i.e., secure communicationof the time critical information, is possible only if a robust infrastructure provides this securityat all times. This document explores the dependency of performance of VANETs on themechanism used for providing this security infrastructure

1 Introduction

A mobile ad hoc network (MANET) is a kindof an ad hoc network of mobile nodes con-nected by wireless links. The nodes are free tomove randomly and organise themselves arbi-trarily. A Vehicular ad hoc network (VANET)is a special kind of MANET in which the mo-bile nodes are vehicles. The main differencebetween VANETs and MANETs is that inVANETs the nodes move in a random but pre-dictable manner, but at much higher speedscompared to traditional MANETs. The ad-vantage of VANETs over traditional ad hocnetworks is that nodes (vehicles) possess sub-stantial power resources. VANETs enable ve-hicles to communicate with each other (V2V)and road side infrastructure (V2I) to increasethe awareness of their surroundings thereby in-creasing safety and p ossibly optimising traffic.The applications running over VANETs are bebroadly classified as

Safety related applications - e.g. Early

Warning messages.

Best Effort Applications - e.g. Infotain-ment, traffic optimisation.

Secure Transactions - e.g. Toll collection.

Most of the critical messages in VANETs are

broadcast oriented safety messages that shouldhave a deep penetration and should be deliv-ered in a short time. Additionally these mes-sages must be secure and must not leak per-sonal, identifying, or linkable information tounauthorised parties, as the owners of the ve-hicles involved in the communication have aright to privacy.Thus the important points in VANET securityare

Authentication - There can be mali-cious and genuine sources for messages inVANETs. Authentication is the ability todistinguish between these sources.

Anonymity - The physical identity of theoriginator of a message should not be eas-ily identifiable from the message

Data Integrity - The data received areexactly as sent by the authorized entity

without any modification [3]

Low Overhead - The messages being timecritical, the security overheads should re-tain the usefulness of the message.

1


2/6

2 Abbreviations

The commonly used abbreviations in theVANET literature are [1]

DSRC - is a short to medium range com-munications service that supports bothpublic safety and private operations inroadside to vehicle and vehicle to vehiclecommunication environments.

ACID - An application class identifier isa code(number) that identifies a class ofapplications.

ACM - An application context mark is acode that identifies a specific instance of

an application within a class.

OBU - A WAVE device that can operatewhen in motion and supports informationexchange with roadside units (RSUs) andother OBUs.

RSU - A wireless access in vehicular en-vironments (WAVE) device that operatesonly when stationary and supports in-formation exchange with on board units(OBUs).

WAVE - Wireless Access in VehicularEnvironments (WAVE), a new name forDSRC [2].

3 Current Scenario inVANETs

The IEEE 1609 Family of Standards [1] definean architecture and a complementary, stan-

dardised set of services and interfaces that col-lectively enable secure vehicle-to-vehicle (V2V)and vehicle-to-infrastructure (V2I) wirelesscommunications.

The layers of the protocol stack are as follows

Figure 1: 1609.x Protocol Stack

IEEE P1609.1 - Resource Manager - de-scribes the key components of the WAVEsystem architecture and defines data flowsand resources at all points. It also definescommand message formats and data stor-age formats that must be used by appli-cations to communicate between architec-ture components, and specifies the typesof devices that may be supported by theOBU resident on the vehicle or mobileplatform.

IEEE P1609.2 - Security Services for Ap-plications and Management Messages - de-fines secure message formats and process-

ing. It also defines the circumstances forusing secure message exchanges and howthose messages should be processed basedupon the purpose of the exchange.

IEEE P1609.3 - Networking Services- defines network and transport layerservices in support of secure WAVEdata exchange. It also defines WaveShort Messages(WSM), providing anefficient WAVE-specific alternative toIPv6(Internet Protocol version 6) that canbe directly supported by applications.

IEEE P1609.4 - Multi-Channel Opera-tions - provides enhancements to the IEEE802.11 MAC to support WAVE opera-

2


3/6

tions. It provides mechanisms for priori-tised access to the physical channel.

The IEEE P1609.2 standard defines securemessage formats and the processing of those se-

cure messages within the WAVE system usingthe Public Key Infrastructure(PKI). It coversmethods for securing WAVE management mes-sages and application messages with the excep-tion of vehicle originating safety messages, andalso describes administrative functions neces-sary to support core security functions. Forobtaining anonymity each vehicle is issued aset of certificates, as periodically sent beaconswith position and time information enable ex-ternal eavesdroppers to create movement pro-

files [4].But for the robustness of the security, timelyaccess to revocation information is important.However real time availability and penetrationof the revocation information is a particularlyhard problem in vehicular networks. Some pro-posals for certificate revocation in vehicularnetworks have been made [8], which includetemporary revocation of the attacker till theconnection to the CA is established.Security requirement and time constraints forapplications based on criticality of the informa-tion have been proposed and the security char-acteristics of these applications along with gen-eral characteristics like degree human involve-ment on events have been enumerated in [7].The end to end delays based on the criticalityof the applications are as follows.

Up to 0.5 seconds - message is highly crit-ical, e.g. break down warning.

0.5 seconds to 1 second - time is critical,

e.g. emergency vehicle approaching warn-ing.

1 to 5 seconds - delays up to 5 seconds areacceptable, e.g. glare reduction.

Other delays - time is not critical, e.g. in-telligent traffic flow control.

4 Algorithm to Accept/Drop

MessagesThe trivial algorithm for accepting/dropping amessage relies on a local information that isresiding at the receiving OBU in terms of theCRLs. The mechanism proposes dropping a re-ceived message if the sender happens to be inthe CRLs. However, it is not very clear whatstep should be taken if the sending entity isnot listed in the CRLs available at the receiv-ing OBU. Clearly, absence of the sender in theCRLs available at the receiver does not guar-

antee that the senders certificate has not beenrevoked by the authority (CA) that issued cer-tificate to the sender. Thus, the receiver facesthe dilemma of whether to accept the messageor simply drop it. In order to improve the per-formance of the message flow in V2V commu-nications, an most important point to be ad-dressed is to have an algorithm (criteria) toaccept/drop a message received by an OBU.In short the packet can be accepted/droppedbased on the Confidence On the Security in-

frastructure(CoS). The Security Infrastructurerepresents the Public Key Infrastructure alongwith the mechanism for issue and distributionof certificates and CRLs issued by the CAs.Hence the CoS is the probability of acceptingthe packet when the certificate is not presentin the CRLs available in the OBU and thepacket satisfies all other criteria mentioned inthe standard for accepting the packets.This CoS is dependent on

The freshness of the certificate under con-

sideration. This freshness of the certifi-cate specifies how fresh the current cer-tificate is. The more recent/fresh the lessprobable is its revocation. This freshnesscomplements the honest majority concept

3


4/6

of vehicular networks that assumes mostof the nodes in the V2V are honest, butthe cost of obtaining this freshness needsto be analysed for various Security Infras-tructure designs.

The freshness of the CRLs. The freshnessof CRLs in the OBU is the penetration ca-pacity of the CRLs, which in turn is com-pletely dependent on the mechanism usedfor distributing the CRLs.

The concept of freshness of certificates is notnew but a similar concept was mentioned in [9]and can be obtained if security infrastructureconsiders the following points.

The signer should provide all the evidence(if possible) the acceptor needs, includingthe recency/freshness information. Freshcertificates are the best evidence.

The acceptor of the messages should setthe recency/freshness requirements of thecertificate and not the CA.

Thus if the performance is measured as thefraction of packets dropped due to failure inauthenticating a genuine sender, to the totalnumber of packets transmitted, then the mech-

anism used for implementing the security in-frastructure determines the performance of thesystem.

5 Design Constraints for theSecurity Infrastructure

The high mobility of vehicles and the unavail-ability of connection with the PKI at all timesmakes design of the security infrastructure a

non trivial task. The factors that affect thedesign of the security infrastructure, thus theCoS are

The storage capacity of the OBU. As men-tioned above the security infrastructure

determines the number of certificates andCRLs to be stored, hence the storagecapacity limits the maximum number ofCRLs that can be stored in the OBU.

The number of certificates in thecertificate chain. The number of links/certificates in the certificate chainto the root determines the number of CAswhose certificates and CRLs need to bestored in the OBU.

The expected number of certificates re-voked and its distribution geographically.The expected number of certificates re-voked and the geographical distribution ofthese revocations determines the number

of CRLs required in the OBU.This is related to the density of nodes inthe geographical regions under consider-ation. e.g. If the security infrastructureis designed such that a vehicle requires anew certificate if it relocates from one geo-graphical region to another, then only theCRLs of the current geographical regionare needed on the OBU.

The relocation (migration) model of the

vehicles. The relocation model describeshow the vehicle migrates from one regionto the other.If the certificate is to remain the sameacross geographical domains then the re-location model determines the maximumnumber of regions whose CRLs need to bestored on the OBU.

The Mobility Model of the vehicles. Themobility model describes how the vehiclemoves from one geographical region to

another. This along with the density ofthe nodes determines the number of othernodes(RSUs and OBUs) the given nodecommunicates.

4


5/6

Life time of a certificate. This determinesthe time for which the certificates need tobe stored on the OBU.

The ways of implementing the security in-

frastructure can be broadly classified as1. Only one CA for all vehicles. This has

many issues like monopoly and the factthat no organisation is universally trusted.

2. Manufacturer Based- The manufacturer isthe CA

Each vehicle manufacturer is the CAfor the vehicles it produces

A representative of a group of manu-facturers is the CA for vehicles pro-duces by member manufacturers.

This model poses the following prob-lems [5]

Coordination in installing certifi-cates.

Coordination for distribution of re-vocation lists in vehicles running onroad.

It doesnt optimise on localisation of

information like, probability of com-municating with vehicles registeredin the same region is high in the re-gion of registration.

3. Geographical Region Based- This can beimplemented as vehicle registration au-thorities becoming the CAs.

A certificate is issued by a CA ofone region and is valid across all ge-ographical regions.

The relocation model is such thatwith a given certificate a vehicle cantheoretically relocate to all other ge-ographical regions in the life-time ofthe certificate.

A certificate is issued by a CA in oneregion and it is valid only in the re-gion of issue.On relocation the certificate needto be re-signed or a new certificate

needs to be issued by the CA of thecurrent region.

A certificate is issued by a CA of oneregion and is valid in a set of regionsthat are near1 the region of issue.On relocation new certificates wontbe required in near by regions.

Some critical questions that need to be an-swered by the security infrastructure are

1. Who are the CAs authorised to issue to a

certificate?This is the most important question andits answer provides the core design of thesecurity infrastructure.

2. How will the certificates be distributed?The issuing authority can authorise otherorganisations to distribute the certificatesissued by it. This is analogous to the reg-istration authorities concept mentionedin [6].

3. What is the life-time of the certificate?What is the procedure for renewal of thecertificates? The above 2 questions isaddresses the frequency with which thecertificates need to be renewed, thus canprovide the time limit for the relocationmodel.

4. Is there any support for freshness checksdone by certificate owner i.e the OBU?This can be provided by the amount oftime for which the vehicles can access thePKI.

1The factors that determine whether a region is near

to the region of issue or not depends on the relocation

model and probability with which a vehicle migrates to

the region under question from the region of issue.

5


6/6

5. What is/are the geographical region(s) forwhich the given certificate is valid?

6. How is the relocation of the vehicles han-dled?

7. What are the conditions for revocation?

8. How will the revocation lists be propa-gated?

9. How many CRLs need to stored on theOBU?

6 Future Work

The factors affecting the design of the secu-

rity infrastructure are now very limited, andwork needs to be done in obtaining other fac-tors. Comparisons of the various implementa-tions need to be analysed, in different scenar-ios. The impact of the implementation of theSecurity Infrastructure on the CoS and thuson the performance of the system, needs to beanalysed. Simulations need to be carried outto support the results obtained through theo-retical analysis.

7 ConclusionAlong with strong cryptographic algorithms toprovide security, an equally strong infrastruc-ture is required for effective secure communi-cation between the communicating entities inVANETs.

References

[1] http://ieeexplore.ieee.org/xpl/standards.jsp.

[2] http://standards.ieee.org/board/nes/projects/1609-0.pdf.

[3] Cryptography and Network Security. Pear-son Education International., 2006.

[4] Klaus P., Thomas Nowey, and ChristianMletzko. Towards a security architecturefor vehicular ad hoc networks. First Inter-national Conference on Availability, Relia-bility and Security, 2006.

[5] Bryan Parno and Adrian Perrig. Chal-lenges in securing vehicular networks.

[6] Radia Perlman. An overview of pki trustmodels. IEEE Network, 1999.

[7] A. Kung R. Kroh and F. Kargl. Vanetssecurity requirements version 1.0.

[8] Maxim Raya, Daniel Jungels, Panos Pa-padimitratos, Imad Aad, and Jean-PierreHubaux. Certificate revocation in vehicu-

lar networks. 2006.

[9] Ronald L. Rivest. Can we eliminate cer-tificate revocation lists? Proceedings of Fi-nancial Cryptography, 1998.

6

Security Infrastructure for VANETs

Documents

Transcript of Security Infrastructure for VANETs