Certificate Revocation Management in VANET

8/13/2019 Certificate Revocation Management in VANET

1/7

International Journal of Cyber-Security and Digital Forensics (IJCSDF) 1(2): 115-121

The Society of Digital Information and Wireless Communications, 2012 (ISSN: 2305-0012)

Certificate Revocation Management in VANET

Ghassan SamaraDepartment of Computer Science, Faculty of Science and Information Technology, Zarqa University

Zarqa, [email protected]

ABSTRACT

Vehicular Ad hoc Network security is one ofthe hottest topics of research in the field ofnetwork security. One of the ultimate goals inthe design of such networking is to resistvarious malicious abuses and security attacks.In this research new security mechanism is

proposed to reduce the channel load resultedfrom frequent warning broadcasting happenedin the adversary discovery process Accusation Report (AR) - which produces aheavy channel load from all the vehicles in theroad to report about any new adversarydisovery. Furthermore, this mechanism willreplace the Certificate Revocation List (CRL),which cause long delay and high load on thechannel with Local Revocation List (LRL)which will make it fast and easy in theadversary discovery process.

KEYWORDS

Secure Certificate Revocation; LocalCertificate Revocation; VANET; CertificateManagement; VANET Security.

1. INTRODUCTION

Traffic congestion is the most annoyingthing that any driver in the world dreamingof avoiding it, a lot of traveling vehiclesmay cause problems, or facing problemsthat must be reported to other vehicles toavoid traffic overcrowding, furthermore,there are a lot of vehicles may sendincorrect information, or a bogus data, andthis could make the situation even worse.

Recent research initiatives supported bygovernments and car manufacturers seekto enhance the safety and efficiency oftransportation systems. And one of themajor topics to search is "CertificateRevocation".

Certificate revocation is a method torevoke some or all the certificates that the

problematic vehicle has, this will enableother vehicles to avoid any informationfrom those vehicles, which cause

problems.Current studies suggest that the Road SideUnit (RSU) is responsible for tracking themisbehavior of vehicles and for certificaterevocation by broadcasting CertificateRevocation List (CRL). RSU also

responsible for the certificatemanagement, communication withCertificate Authority (CA), warningmessages broadcasting, communicatingwith other RSUs. RSU is a small unit will

be hanged on the street columns, every 1KM [2] according to DSRC 5.9 GHZrange.In vehicular ad hoc networks most of roadvehicles will receive messages or

broadcast sequence of messages, and they

dont need to consider all of theseMessages, because not all vehicles have agood intention and some of them have anEvil-minded.Current technology suffers from highoverhead on RSU, as RSU tackingresponsibility for the whole Vehicular

Network (VN) Communication.

115
mailto:[email protected]:[email protected]:[email protected]


2/7



Furthermore, distributing CRL causescontrol channel consumption, as CRLneed to be transmitted every 0.3 second[3]. Search in CRL for each messagereceived causes a processing overhead forfinding a single Certificate, where VNcommunication involves a kind of periodicmessage being sent and received 10 times

per second.This research proposes mechanisms thatexamine the certificates for the receivedmessages, the certificate indicates toaccept the information from the currentvehicle or ignore it; furthermore, thisresearch will implement a mechanism forrevoking certificates and assigning ones,these mechanisms will lead better andfaster adversary vehicle recognition.

2. RESEARCH BACKGROUND

In the previous published work [1],security mechanisms were proposed toachieve secure certificate revocation, andto overcome the problems that CRLcauses.

Existing works on vehicular networksecurity [4], [5], [6], and [7] propose theusage of a PKI and digital signatures butdo not provide any mechanisms forcertificate revocation, even though it is arequired component of any PKI-basedsolution.

In [8] Raya presented the problem ofcertificate revocation and its importance,the research discussed the current methodsof revocation and its weaknesses, and

proposed a new protocols for certificaterevocation including : CertificateRevocation List (CRL), Revocation usingCompressed Certificate Revocation Lists(RC 2RL), Revocation of the Tamper ProofDevice (RTPD) and DistributedRevocation Protocol (DRP) stating thedifferences among them. Authors made asimulation on the DRP protocol concluding

that the DRP protocol is the mostconvenient one which used the Bloomfilter, the simulation tested a variety ofenvironment like: Freeway, City andMixing Freeway with City.

In [9] Samara divided the network to smalladjacent clusters and replaced the CRLwith local CRL exchanged interactivelyamong vehicles, RSUs and CAs. The sizeof local CRL is small as it contains thecertificates for the vehicles inside thecluster only.

In [10] Laberteaux proposed to distributethe CRL initiated by CA frequently. CRLcontains only the IDs of misbehaving

vehicles to reduce its size. The distributionof the received CRL from CA is madefrom RSU to all vehicles in its region, the

problem of this method is that, not all thevehicles will receive the CRL (Ex: avehicle in the Rural areas), to solve this

problem the use of Car to Car (C2C) isintroduced, using small number of RSUs ,transmitting the CRL to the vehicles.

In [3] the eviction of problematic vehiclesis introduced, furthermore, somerevocation protocols like: Revocation ofTrusted Component (RTC) and LeaveProtocol are proposed.

In [11] some certificate revocation protocols were introduced in the traditionalPKI architecture. It is concluded that themost commonly adopted certificaterevocation scheme is through CRL, usingcentral repositories prepared in CAs. Basedon such centralized architecture, alternativesolutions to CRL could be used forcertificate revocation system likecertificate revocation tree (CRT), theOnline Certificate Status Protocol (OCSP),and other methods where the commonrequirement for these schemes is highavailability of the centralized CAs, asfrequent data transmission with On BoardUnit (OBUs) to obtain timely revocation

116


3/7



information may cause significantoverhead.

3. PROPOSED SOLUTION

In the previous published work in [1] the proposed protocols for message checkingand certificate revocation were thefollowing:

Message Checking:

In this approach any vehicle receives amessage from any other vehicle takes themessage and checks for the sendercertificate validity, if the sender has aValid Certificate (VC), the receiver willconsider the message, in contrary, if thesender has an Invalid Certificate (IC) thereceiver will ignore the message,furthermore, if the s ender doesnt have acertificate at all, the receiver will report tothe RSU about the sender and check themessage if it is correct or not, if theinformation received was correct RSU willgive a VC for the sender, else RSU willgive IC for it, and register the v ehiclesidentity into the CRL. See figure 1 formessage checking process.

Figure 1. Message checking procedure

Certificate Revocation:

Certificate revocation is done when anymisbehaving vehicle having VC isdiscovered, where RSU replaces the old

VC with new IC, to indicate that thisvehicle has to be avoided and this happenswhen more than one vehicle reporting toRSU that a certain vehicle has a VC and

broadcasting wrong data. See figure 2, thisreport must be given to RSU each time thatany receiver receives information fromsender and finds that this information iswrong.

Figure 2. Certificate revocation procedure

The revocation will be as follows, a sendersen sends a message to receiver rec; thismessage may be from untrusted vehicle, soreceiver sends Message to RSU to acquireSession Key (SKA), RSU replay messageContaining SK Reply (SKR), this messagecontains the SK assigned to the currentconnection, this key is used to preventattackers from fabrication of messages

between the two vehicles.

Receiver sends a message to checkvalidity, this m essage called ValidityMessage, the message job is to indicate ifthe sender vehicle has a VC or not.Afterwards, RSU reports to the rec that the

117


4/7



sender has a VC, so receiver can considerthe information from the sender with nofear.

In some situations, receiver receives

several massages, where all massagesagree on a same result and same data, but aspecific sender sends deferent data, thisdata will be considered as wrong data, ifthis data belongs to the same category.

Every message will be classifieddepending on its category:

TABLE I. MESSAGE CLASSIFICATION ANDCODING

Every category has a code, if the messagereceived has the same code of the othermessages, and has a deferent data, then thismessage is considered as a bogus message.In this case rec sends an Abuse Report(AR) for RSU, the Abuse AR (sen id,

Message Code, Time of Receive), thisreport will be forwarded to CA, if RSUreceives the same AR from other vehicleslocated in the same area, the number ofabuse Report messages depends on thevehicles density on the road, see figure 3.

Figure 3. Calculation of the Number of Vehicles inthe Range [12]. If the number of vehicles that

making accusation for a specific vehicle isnear the half of the current vehicles, RSUwill make a Revocation Request (RR) torevoke the VC from the sender vehicle.

Some vehicles dont produce an AR because they didnt receive any data fromthe s ender vehicle (maybe they werent inthe area wile broadcasting), or they have a

problem in their devices, or they have anIC, so RSU will not consider theirmessages.

CA makes a revocation order to RSU afterconfirming the RR and updates the CRLand then RSU revokes the VC from thesender vehicle, and assigns IC for it, toindicate to other vehicles in the future, thatthis vehicle broadcasts wrong data, "donttrust it".

Figure 2 shows certificate revocation steps.

Message 1: sen (sender) sends a messageto the rec (receiver), this message alongwith digital signature of sen, and thismessage is encrypted with the Primary Key(PK) of rec.

Any attacker can make a fabricated

message telling rec that this messageoriginated from sen, to prevent thissignature from being used.

Message 2: rec sends a request to RSUencrypted with the PK of RSU, acquiring aSK for securing connection.

Message 3: replay for Message 2, containsthe SK and the time for sending the replay,the importance of the time is to preventreplay attack, where an attacker can sendthis message more than once, with thesame session key, and same signature, sohe can forge the whole connection.

Message 4: rec sends validity message tocheck if the vehicle has to be avoided ornot, this message encrypted with the sharedSK obtained from RSU.

118


5/7



Message 7: sen sends a message to reccontaining the VC, to report for rec thatthis vehicle must be trusted, and the timeof sending, in here, to avoid reply attack,which happens when an attacker keeps themessage with him, and sends it after a

period, may be at that time, the senderscertificate been revoked by RSU, so thesen must be avoided, but the attacker forcethe rec vehicle to trust it. After receivingthe information, rec checks if the messagehas a deferent or same data for the samecategory of other messages received.

Message 8: if the message is deferent, then,wrong data is received, rec sends an AbuseReport for RSU, contains sen id to knowwhich vehicle made the problem, MessageCode to know the category of the message,Time of Receive to know when themessage received, and the message alsoincludes the Time to avoid replay attackand Signature to avoid fabrication; themessage is encrypted with PK of RSU.

In this situation replay attack will happen,if an attacker copied this message, andsends it frequently to RSU in several timesto make sure that the number of accusation

reached a level, that the certificate must berevoked.

After examining the number of vehiclesthat accused sen for sending an Invalidmessage, if the number is reasonable, RSUsends Message 9.

Message 9: RSU sends RR for CA,containing Serial Number and Time toavoid replay attack and Signature to avoidfabrication, Revocation Reason to statewhat is the reason for revocation, and senid to know which vehicle is the

problematic one and message code toknow what is the message category; themessage is encrypted with PK of CA.

Replay attack in this situation happenswhen an attacker wants to transmit thesame message for CA claiming that thismessage is from RSU, after some time CA

will not have the ability to respond,causing for DoS attack, so RSU must useTime and Serial number for this message,

because CA has a lot of work to do andsending a lot of these kind of messageswill cause a problem.

Message 10: CA makes a RevocationOrder for RSU; this message contains SNto avoid DoS Attack, time to avoid replayattack, signature to avoid fabricationattack, Sender Id, Revocation Reason tostate what is the reason for revocation.

After receiving this request CA will updateCRL, adding the new vehicle that beencaptured to CRL and send it for RSU.

DoS attack can happen, when attacker keepsending the same message to RSU,claiming that the message originated fromCA, CA messages have the highest priorityto be processed by RSU, so RSU willreceive a huge amount of messages fromCA and process it, without having the timeto communicate with other RSUs or othervehicles, to avoid it a serial number andsignature is used.

Message 11: RSU makes the revocation,

revoking VC, assigning IC, also thismessage contains the time to avoid replayattack, Signature to avoid fabricationattack, Revocation Reason to state what isthe reason for revocation.

However, RSU will be responsible forrenewing vehicle certificates, any vehiclehas an expiring certificate willcommunicate with RSU to renew thecertificate, then the RSU will check theCRL to see if this vehicle has an IC or not.

If there is no problem for giving a newcertificate for this vehicle, it will be givenfor a specific life time, when the periodexpires vehicle will issue a request for theCA for renewing the certificate. VC willhave a special design different from thedesign of X.509 certificate [13] as shownin [1].

119


6/7


7/7



2. DSRC Home Page. [cited 2011-11-21;Available from: http://www.leearmstrong.com/DSRC/DSRCHomeset.htm .

3. Raya, M., et al., Eviction of misbehaving andfaulty nodes in vehicular networks. IEEEJournal on Selected Areas in Communications,2007. 25(8): p. 1557-1568.

4. Raya, M. and J.P. Hubaux. The security ofvehicular ad hoc networks. Proceedings of the3rd ACM workshop on Security of ad hoc andsensor networks, 2005, ACM.

5. Parno, B. and A. Perrig. Challenges insecuring vehicular networks. in Proceedings ofthe Fourth Workshop on Hot Topics in

Networks (HotNets-IV). 2005.6. Samara, G., W.A.H. Al-Salihy, and R. Sures.

Security Issues and Challenges of VehicularAd Hoc Networks (VANET). in 4thInternational Conference on New Trends inInformation Science and Service Science(NISS), 2010 . IEEE.

7. Samara, G., W.A.H. Al-Salihy, and R. Sures.Security Analysis of Vehicular Ad Hoc Nerworks (VANET). in Second InternationalConference on Network ApplicationsProtocols and Services (NETAPPS), 2010.IEEE.

8. Raya, M., D. Jungels, and P. Papadimitratos,Certificate revocation in vehicular networks.Laboratory for computer Communications andApplications (LCA) School of Computer andCommunication Sciences, EPFL, Switzerland,2006.

9. Samara, G., S. Ramadas, and W.A.H. Al-Salihy, Design of Simple and EfficientRevocation List Distribution in Urban Areasfor VANET's. International Journal of

Computer Science, 2010. 8.10. Laberteaux, K.P., J.J. Haas, and Y.C. Hu.Security certificate revocation list distributionfor VANET. in Proceedings of the fifth ACMinternational workshop on VehiculAr Inter-

NETworking 2008. ACM.11. Lin, X., et al., Security in vehicular ad hoc

networks. Communications Magazine, IEEE,2008. 46(4): p. 88-95.

12. Raya, M. and J.P. Hubaux, Securing vehicularad hoc networks. Journal of ComputerSecurity, 2007. 15(1): p. 39-68.

13. Stallings, W., Cryptography and networksecurity, principles and practices, 2003.Practice Hall.

121
http://www.leearmstrong.com/DSRC/DSRCHomeset.htmhttp://www.leearmstrong.com/DSRC/DSRCHomeset.htmhttp://www.leearmstrong.com/DSRC/DSRCHomeset.htmhttp://www.leearmstrong.com/DSRC/DSRCHomeset.htmhttp://www.leearmstrong.com/DSRC/DSRCHomeset.htm

Certificate Revocation Management in VANET

Documents

Transcript of Certificate Revocation Management in VANET