Self-Recusation Protocol for Blockage of Misbehaving Applications in Vehicular Networks

Cristina Gil, Leticia González, Neftis Atallah, Ruben M. Lorenzo

CEDETEL (Centre for the Development of Telecommunications in Castilla y León)

Valladolid, Spain cgil; lgonzalez; tneftis; ruben.lorenzo@cedetel.es

Juan Antonio Abánades, Nicolas Jean Leconte, Jairo Montero

GMV Valladolid, Spain

jabanades; njleconte; jmontero@gmv.com

Abstract— Security is a fundamental issue in the deployment of any kind of network, in particular those networks that affect people integrity. It is therefore important to detect the existence of any failure and to try to avoid its propagation as much as possible. In order to take maximum advantage of ad-hoc networks, protocols should be adapted to these new technologies by proposing new alternatives to centralized systems. Along this paper, a proposal is being discussed to allow blockage of applications that show malfunctioning, through a collaborative system based on weighted accusations. This method is more effective than the complete revocation of the keys since it allows the use of critical applications.

Keywords: accusation; VANET; security; application blockage; weight

I. INTRODUCTION Over the last few years, there has been a growing

interest in the potential applications of vehicular networks and the benefits they could bring to users of road networks, both in terms of comfort and safety for drivers and pedestrians. This last issue is particularly relevant since one of the main objectives of the policies of the European Union, in terms of transportation, is to dramatically reduce road accidents, as defined by the European Road Safety Charter [1]. To this end, specific applications (which can be grouped under the term “safety”) are being developed, e.g., the “e-call” system [2]. Other applications could be associated to a second group (“non-safety”) that simply aim to ease the driving experience and the use of infrastructures, such as automatic toll payment, mobile office, infotainment (information + entertainment) services, fleet management, collision avoidance systems, etc.

In any case, these services deployment requires the implementation of certain security measures to ensure their proper working and to avoid abusing or “sniffing” of private information traveling through the network. It is hence important to ensure the existence of mutual trust relationship between VANET (Vehicular Ad-Hoc Network) nodes, and a fast response against those presenting a suspicious behavior. However, nodes revocation presents a major challenge for vehicular networks, as usual mechanisms often rely on the distribution of CRLs

(Certificate Revocation List) [3], by means of a centralized Certificate Authority (CA). This usually forces the maintenance of a continuous connectivity with the fixed infrastructure, instead of using a pure ad-hoc approach.

In this paper, a system is proposed that allows to carry out these revocations, not only locally (without any centralized external entity), but also in a selective way, i.e., affecting only those applications that present misbehavior. This method is based primarily on individual nodes doing network monitoring on their own, and accusing their neighbors as soon as they detect any malfunction. The protocol integrates an access control mechanism (that will be referred as “firewall” from now on, due to its similarities with this security device) that will only block messages from the particular application which is presenting the wrong behavior. A total revocation of user keys will thereby be avoided, so that, in case of possible errors, the nodes will not be deprived of all their applications.

Additionally, the protocol uses a reputation system [4], in such a way that votes issued by nodes will be weighted by a coefficient, assigning their accusations a higher or lower weight depending on the reliability level the nodes have in the network. This level will be calculated based on multiple data, like the number of blocked applications of the transmitting node or the result of accusations against other nodes carried out by this node.

This paper is structured in the following way. In Section II, previous works related to security in VANET networks are made reference to, including other accusation protocols and wrong behavior detection. In Section III, a scheme and performance of the proposal, with a special attention to reliability coefficient calculation, is deeply described. Finally, in a concluding section, open investigation lines and future actions are quoted.

II. RELATED WORK Integrating efficient and effective security mechanisms

in vehicular networks is a very important issue and has promoted multiple studies and even full projects [5]. Thus, several aspects such as possible attacks, security requirements and architecture models to face some of these problems, are already well documented [6][7].

2010 Sixth International Conference on Wireless and Mobile Communications

978-0-7695-4182-2/10 $26.00 © 2010 IEEE

DOI 10.1109/ICWMC.2010.82

430

2010 Sixth International Conference on Wireless and Mobile Communications

978-0-7695-4182-2/10 $26.00 © 2010 IEEE

DOI 10.1109/ICWMC.2010.82

431

2010 Sixth International Conference on Wireless and Mobile Communications

978-0-7695-4182-2/10 $26.00 © 2010 IEEE

DOI 10.1109/ICWMC.2010.82

431

Regarding the topic of this paper, several protocols for nodes revocation in ad-hoc networks can be found in the existing literature [8]. In [9], nodes detecting misbehavior in the network are responsible of warning their neighbors to ignore that vehicle until they can get connectivity to a CA that proceeds to the keys revocation. It can also be noticed that other articles propose the assignment of relative coefficients to issued accusations [10][11] and even suicide mechanisms [12], consisting in a sacrifice of accuser keys to revoke other node considered as malicious.

In this paper, a system is proposed that can be named as “self-recusation” protocol. Its main feature is that the misbehaving node is the one who receives the accusation messages that other nodes send against it, counts them and recuses itself once the threshold conditions are reached. The vehicle will then proceed to block just the application that is not functioning as expected, instead of revoking all its keys and certificates, in order to allow the use of the remaining applications (specially applications as critical as those related to safety), as the blocking of the application could have been caused by a software mistake or a failure in the embedded systems and sensors.

Obviously, for this system to be effective it must use an appropriate mechanism to detect malfunctions in the network, i.e., to find out those applications that deviate from normal behavior pattern. Although this issue falls out of the scope of this paper, there are already several studies [13][14] that have investigated various systems to detect different kinds of misbehavior.

It also should be noted that the approach of self-revocation, can only be accepted if the independence of the application level and the security mechanism hereby proposed is ensured. Otherwise, a failure to operate at the application level could affect the self-revocation system itself. In any case, the self-revocation failure would affect one node only at any given time, which justifies the use of weighting the accusations received from different nodes to minimize the impact of such situations.

III. PROTOCOL OVERVIEW The main objective of this protocol is to ensure that

malicious nodes are detected and neutralized while legitimate nodes are protected from attacks caused by false accusations coming from malicious nodes. In order to achieve this, when a node detects an unexpected behavior, it immediately sends a message signed with its private key, to the involved node. By verifying the signature of the afore-mentioned key, non-repudiation of origin (unambiguous verification of the identity of the sender) can be guaranteed. Accusation messages that cannot be adequately verified will therefore not be taken into account. Additionally, accuser identities will be stored, to later inform them in case of success of the whole process.

For a correct protocol implementation, it is assumed that hardware systems deployed in the nodes are inscrutable and “tamper-proof”, and that potential attackers will therefore

not be able to prevent or manipulate the self-recusation process. On the other hand, it is also assumed that, a separation exists between the application-level and the communication-level hardware. This separation permits the inclusion of new applications by the user, while maintaining the implementation of the self-recusation protocol safe at the lower, communications-level hardware. That is, potential attackers could include mal-functioning applications, but not manipulate the communications-level hardware or software. In addition, it is also assumed that nodes in the network present, mostly, good behavior and cannot “forge” their keys, since these must have been formerly supplied by a trusted CA.

A. Weight Computation As mentioned above, accusations must be accompanied

by a certain coefficient (named weight), the value of which will be calculated depending on the reliability level of the issuer node, since an accusation coming from a trusted node will not have the same validity as the one from a node with blocked applications.

Due to the fact that the node itself will be responsible for calculating the weight of its own accusations, it is required to store certain information regarding the accusations related to that node (data about accusations exchanged among other nodes is not required). For that purpose, it will maintain tables of accusations which will collect both the accusations it generates, and the accusations sent against it by other nodes, along with all related data. In the first case, i.e., for the transmitting accusations, it must also store a special revocation flag (REV) which indicates if the accusation was finally supported enough, that is, if it was successful. A node, whose accusations are not fruitful in majority, will see its reliability level reduced. Accordingly, the factors to be taken into account to calculate accusations weight are:

• Number of blocked applications for the accusing node. It is logical to think that if a node has several revoked applications, it is probably trying to carry out some kind of attack, so its reliability level must be decreased.

• Past accusations performed against other nodes, especially their success or not. If a node sends a lot of accusations but these are never (or hardly ever) successful, that is, they do not achieve the blocking of an application, it could mean that the sending node is “malicious”. This will reduce its reliability level and thus, its weight must have a lower value. However, if a node accuses other nodes, and most of these accusations lead to the blockage of the involved applications, this would contribute to increase the weight of its future accusations as it appears to be trusted node.

With all this information available, each node calculates the weight of the accusations it will send to other nodes, and attaches this value to the accusation message. Thus, when a node accuses another of wrong behavior, it sends to the

431432432

involved node a signed message that should include: the misbehaving application identifier, the accusation weight and a timestamp of the time at which the accusation was generated (this information is required to verify blocking conditions, as described later). Therefore, the accusation message format will have a similar structure to the one shown in Figure 1.

Accusing_ID Accused_ID App Weight Time Signature

Figure 1. Accusation message format.

The specific equation for the weight calculation is currently under study, mainly in an effort to determine algorithm best performance. Nevertheless, it is currently being performed as follows:

w = Wi – (Fu * U) + (Fs * S) – (Fb * B) (1)

where: • w is the weight of the accusation to be sent • Wi is the initial (and maximum) weight, a default

value set for all nodes in the VANET, • U is the number of unsuccessful accusations • S is the number of successful accusations • B is the number of blocked applications • Fu, Fs and Fb are multiplying factors for each of the

above variables. An important consideration is that: Fb > Fs > Fu, that

is, if a node has blocked applications, its behavior is more probably malicious, while the event of an unsuccessful accusation might appear, in a vehicular network, if the accusing node does not receive a confirmation of the success of the accusation, while it was, indeed, successful.

B. Double Threshold Verification When a node is accused, it proceeds to store the

accusation message and to activate the accounting process. This process consists in checking, at any moment, if the sum of the weights of all received accusations (conveniently verified through their signature), relating to a specific application and coming from different nodes, exceeds a pre-established threshold. Nevertheless, before blocking the accused application, a second condition must be fulfilled: all accusations must have been received within a specified temporal interval. That is, the time difference between the oldest stored accusation and the last one received must be lower than a predetermined “T” value. To verify this condition, the timestamps stored in the corresponding table of accusations will be used. If both conditions are fulfilled, the node will establish that its application presents misbehavior, and it will “block” it. To do so, the node will report to its firewall module, which will refuse any outgoing messages from the involved application.

Upon activation of the neutralization process, accusing nodes must be reported if their accusation messages have been supported enough, and hence if the involved application has been blocked. In order to achieve that, the accused node will send a success message to each accusing node. This message will include the node’s identity and the blocked application identifier, according to the format shown in Figure 2. With this information, nodes will update their accusation tables (particularly, flag REV) for the future computation of new weights.

Success Accused_ID Accusing_ID Revoked App Signature

Figure 2. Success message format.

C. Messages Exchange Finally, an example of the messages exchange that

would take place between two vehicles (accuser and accused) can be observed in Figure 3, when the former detects a suspicious behavior in any of the second vehicle applications. The process has been divided into individual functions described next:

• COMPUTE_weight: This function will be responsible for weight computation of each accusation, according to the parameters previously defined (number of successful accusations, number of blocked applications, etc.).

• SEND_acc: Once the weight is known, this function completes the remaining fields, including the timestamp of the generation of the accusation, and sends the packet to the involved node.

• UPDATE_trtable: With this function, the accusing node updates its table of transmitted accusations, in order to be able to calculate future weights.

• RECEIVE_acc: When the accused node receives a new accusation, this function is invoked to verify the message signature. If it is not correct, the accusation will be discarded, as the sender identity could not be verified.

• UPDATE_rcvtable: If the signature is correct, this function extracts the relevant fields of the message and stores them in the table of received accusations, checking previously that the accusation is not a duplicated (there is no longer any accusation for the same application and coming from the some node). Additionally, it will also verify if the thresholds conditions, for that application, have been reached.

• ACTIVATE: In case of having reached or exceeded the pre-established thresholds, this function will be responsible of activating the firewall to block the misbehaving application. It will be mandatory to store accusation messages as evidence, if necessary.

• SEND_success: Once the application blockage is confirmed, this function will report to the accusing nodes that their accusations have been successful.

432433433

Figure 3. Example of Accusation/Success messages exchange (V1

accused node/ V2 accusing node).

IV. CONCLUSION AND FUTURE WORK In this paper, a proposal for the blockage of

misbehaving applications in vehicular networks has been described, consisting essentially in the transmission of accusation messages in response to the detection of a wrong behavior. This method is more effective than the complete revocation of the keys, especially if the misbehavior is caused by a mechanical error, since it allows the involved node to continue with the use of the remaining applications. Another of its main advantages is that the revocation can be performed locally, without the need of an external entity.

However, the possibility of implementing an additional mechanism to report the blockage of applications to the CA, attaching the list of signed accusations as evidence, is under study. If deemed appropriate, a system by which the CA would create and send periodically to the network a list of blocked applications on each node (similar to CRL distribution) could also be deployed. This would provide an additional security level, since the nodes themselves may reject messages coming from those applications in the event of a failure in the applications blocking process. Moreover, if the CA detects a node with a high number of blocked applications, it could decide to revoke its certificate completely by considering that it is a corrupt node.

Finally, there is a need to check the protocol performance using specific tools to simulate its behavior. A scheme of this proposal is under implementation using “ns-2” [15] to verify the system features in different vehicular environments. These simulations will allow to further determine optimal values for the threshold conditions, based on the results obtained with different mobility traces and parameters.

ACKNOWLEDGMENT Part of this work is being funded by the MARTA project

(Mobility & Automotion through Advanced Transport Networks), one of 16 projects approved by CDTI (Spanish Government Center for Development and Technology for Industry) as part of the CENIT program (National Strategic Consortiums for Technical Investigation) to foster Research and Development in Spain.

REFERENCES [1] European Road Safety Charter - http://www.erscharter.eu/ [2] eCall Whitepaper v1.5, QUALCOMM Incorporated, March 2009. [3] P, Papadimitratos, G. Mezzour and J.-P. Hubaux, “Certificate

revocation list distribution in vehicular communication Systems”. VANET’08, EPFL, 2008, ACM 978-1-60558-191-0/08/09.

[4] S. Buchegger and J.-Y. Le Boudec, “Self-policing mobile ad hoc networks by reputation systems”. Communications Magazine, IEEE, 43(7):101–107, 2005.

[5] SEVECOM (Secure Vehicular Communication) – http://www.sevecom.org

[6] M. Raya and J.-P. Hubaux, �Securing vehicular ad hoc networks”, Journal of Computer Security, Special Issue on Security of Ad Hoc and Sensor Networks, Vol. 15, Nr. 1, pp. 39-68, Oct. 2007.

[7] M. Raya, P. Papadimitratos and J.-P. Hubaux, “Securing vehicular communications�, IEEE Wireless Communications Magazine, Special Issue on Inter-Vehicular Communications, Vol. 13, Nr. 5, pp. 8-15, Oct. 2006

[8] T. Moore, J. Clulow, S. Nagaraja, and R. Anderson, “New strategies for revocation in ad-hoc networks”. In Proceedings of ESAS�07, LNCS 4572, pp. 232�246, 2007.

[9] M. Raya, P. Papadimitratos, I. Aad, D. Jungels and J.-P. Hubaux, “Eviction of misbehaving and faulty nodes in vehicular networks”, IEEE Journal on Selected Areas in Communications, Special Issue on Vehicular Networks, Vol. 25, Nr. 8, pp. 1557-1568, 2007.

[10] D. Jungels, M. Raya, I. Aad and J.-P. Hubaux, “Certificate revocation in vehicular ad hoc networks”, Technical Report LCA-REPORT-2006-006, EPFL, 2006.

[11] C. Crépeau and C.R. Davis, “A certificate revocation scheme for wireless ad hoc networks”. In Proceedings of SASN’03.

[12] J. Clulowand and T. Moore, “Suicide for the common good: a new strategy for credential revocation in self-organizing systems”. ACM SIGOPS OSR 40(3), 18–21 (2006)

[13] A. Mishra, K. Nadkarni, and A. Patcha, “Intrusion detection in wireless ad hoc networks”. IEEE Wireless Communications, 11(1):48�60, Feb. 2004.

[14] Y. Zhang and W. Lee, “Intrusion detection in wireless ad hoc networks”. In Proceedings of MobiCom’2000.

[15] The Network Simulator: ns-2 – http://www.isi.edu/nsnam/ns/

433434434