A mechanism to enforce privacy in vehicle-to-infrastructure communication

Available online at www.sciencedirect.com

Computer Communications 31 (2008) 2790–2802 www.elsevier.com/locate/comcom

A mechanism to enforce privacy in vehicle-to-infrastructure communication Paolo Cencioni a, Roberto Di Pietro b,* b

a Dipartimento di Informatica, Universita` di Roma ‘‘Sapienza’’, Via Salaria 113, 00198 Roma, Italy Dipartimento di Matematica, Universita` di Roma Tre, L.go S. Leonardo Murialdo 1, 00146 Roma, Italy

Available online 23 December 2007

Abstract Privacy-related issues are crucial for the wide diffusion of Vehicular Communications (VC). In particular, traffic analysis is one of the subtler threats to privacy in VC. In this paper we first briefly review current work in literature addressing privacy issues and survey vehicular mobility models. Then we present VIPER: a Vehicle-to-Infrastructure communication Privacy Enforcement pRotocol. VIPER is inspired to solutions provided for the Internet—mix—and cryptography—universal re-encryption. The protocol is shown to be resilient to traffic analysis attacks and analytical results suggest that it also performs well with respect to key performance indicators: queue occupancy, message path length and message delivery time; simulation results support our analytical findings. Finally, a comprehensive analysis has been performed to assess the overhead introduced by our mechanism. Simulation results show that the overhead introduced by VIPER in terms of extra bits required, computations, time delay, and message overhead is feasible even for increasing requirements on the security of the underlying cryptographic mechanisms. Ó 2007 Elsevier B.V. All rights reserved. Keywords: Vehicular communications; Anonymity; Privacy; Traffic analysis; Vehicular mobility models

1. Introduction Both academia and car manufacturers are progressively paying more and more attention to Vehicular Communications (VC), that allow vehicles to connect to each other and with the roadside infrastructure to form a Vehicular Adhoc Network (VANET). The nodes of a VANET are commonly divided in two categories: On-Board Units (OBU), that are radio devices installed on vehicles, and Road Side Units (RSU), that constitute the network infrastructure. RSUs are placed along the roadside and are controlled by a network operator. VC will enable the development of systems to support several services, for instance road safety, traffic information diffusion, automatic tolling and entertainment [11]. An example of protocol suitable for VC is IEEE 802.11p, a protocol belonging to the IEEE *

Corresponding author. Tel.: +39 3293758764. E-mail addresses: [email protected] (P. Cencioni), [email protected] (R. Di Pietro). 0140-3664/$ - see front matter Ó 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2007.12.009

802.11 family. The expected development of VANETs will involve millions of vehicles worldwide, making that network the most extended form of mobile ad-hoc networks [21]. However, the nature of the wireless communications makes eavesdropping particularly easy. All an adversary needs to do is to deploy its devices across the area of the network that it wishes to monitor. To a smaller scale, or in case pre-deployment of the eavesdropping infrastructure is not feasible, a mobile adversary could easily follow a target vehicle while being outside the line of sight, simply following the messages sent by the target. At the same time, safety messages provide even richer information on their sender; this essentially allows automatic tracking of the vehicle that eventually reveals private information regarding the activities of the driver. The wide availability of VC-compatible radios (802.11-based) makes such a threat even more credible. Furthermore, VANETs introduce a number of challenges to the research community like high node mobility,

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802

nodes heterogeneity, and several security issues. For instance, note that exchanged messages can take part in road safety applications [19]; therefore, it is fundamental to take security into account when designing protocols and mechanisms for VANETs. In particular, security requirements include authentication, data consistency and integrity, availability, non-repudiation and privacy [17]. Among these requirements, privacy is key to the VANET, because a lack of privacy could rise concern about the adoption of this new technology, delaying its widespread diffusion. The contributions of this paper are the following. We summarize current solutions to enforce anonymity for VANETs and we provide a brief survey of the most diffused mobility models for VANETs as well. However, the core of contribution of this paper is VIPER: A Vehicleto-Infrastructure Privacy Enforcement pRotocol. In particular, we focus on not time-constrained communications that are usually involved in applications like automatic tolling, traffic information diffusion, and entertainment. We show that VIPER is resilient to traffic analysis attacks and analyse its performances with respect to key indicators: queue occupancy, message path length and message delivery time. Further, we analyse the overhead introduced by VIPER in terms of extra bits required, computations, time delay and number of dummy messages sent. Analytical and simulation results show that VIPER introduces negligible overhead and moreover it scales well with the dimension of the network as well as with increasing requirements on the security of the underlying mechanisms. The sequel of the paper is organized as follows: Section 2 reports related work on both anonymity and mobility models; Section 3 details the proposed solution, while in Section 4 the results of the theoretical analysis and the simulations are shown. Finally, Section 5 reports some concluding remarks and outlines some future work. 2. Related work 2.1. Anonymity Anonymity issues have been extensively studied for the Internet and interesting solutions have been developed. Some of them are summarized in the following. The first approach to anonymity on the Internet is represented by Chaum’s Mixes [7], that were originally designed to provide e-mail anonymity. A Mix is a node that acts as a proxy between a sender and a receiver. In fact, it collects messages from several sender and forwards them to the receivers in such a way that a receiver cannot infer the identity of the sender. Moreover, a Mix provides sender and receiver unlinkability against a global eavesdropper. This goal is achieved by collecting messages of equal length from different nodes and forwarding these messages to their respective recipients in a different order (not predictable from the order of the inputs), making difficult for an eavesdropper to correlate an input message with the corre-

2791

sponding output message. A sequence of Mixes can be used to tolerate an attack by colluding Mixes, because just a single correctly-behaving Mix in the sequence prevents message correlation. The Mix approach has been applied not only in asynchronous communications systems (like e-mail) but also in symmetric ones, like web browsing. In [12] the Onion Routing (OR) scheme is presented, in which a number of CORs (Core Onion Routers) act as real-time Mixes to anonymize web traffic. While Chaum’s Mixes can wait for an indefinite amount of time to receive a fixed number of messages from several sender, CORs are designed to forward messages in real-time. This introduces a limit in the anonymity provided by the scheme, for instance when the traffic level is low. To increase the level of traffic it is possible to let the CORs exchange some dummy traffic (i.e. messages that do not carry any meaningful information). In OR, a connection between a sender and a receiver is set up by the former, that chooses some CORs and consequently creates a path to the destination, whose routers are the CORs chosen. The sender then creates a message called onion, that is a recursively layered data structure consisting of as many layers as the number of CORs in the path. Each layer of the onion is encrypted with the public key of the corresponding COR and contains the identity of the next COR in the path, the embedded onion, and some encrypted information that will be used during the web traffic exchange phase. Once the connection between the sender and the receiver is established, data can be sent in both directions. Subsequent messages are broken into fixed-size cells, that are encrypted using the symmetric-based encryption keys specified in the set-up phase. The OR project brought to the development of a second generation of the scheme, called Tor [9]. Another web traffic anonymization system is Crowds [22]. A crowd is a collection of users registered within a server, called blender, that is responsible for crowd membership management. Once a user is registered, all the other crowd members are notified about the identity of the newcomer. The blender is also responsible for key distribution. Crowds uses symmetric pair-wise keys to encrypt and decrypt http requests and responses exchanged through a path. A path is formed in the following way: the initiator of the request randomly selects a user of the crowd (possibly itself), that randomly decides either to stop the path (and then to send the subsequent http requests to the web server) or to continue the path (and then to randomly select another user), and so on. Therefore, the length of the path is not decided by the initiator as in OR, but depends on the local decision taken by each router on the path. Paths are static, that is, once a path between an initiator and a responder is created, all the traffic exchanged by these two nodes follows that path. Replies from the web server follow the same path, in reverse order. Traffic analysis is a category of attacks against anonymity of communications [5]. Techniques to prevent traffic analysis attacks on the Internet have been an active area

2792

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802

of research as well. In [5], techniques to prevent message coding attack, timing attack, message volume attack, flooding attack, intersection attack and collusion attack are exposed. However, anonymity and privacy research in VANETs is still in its infancy, where only few solutions have been provided so far; some of them are reported in the following. In [18] an overview on the challenges and open issues in privacy and identity management is given. The work in [21] considers attacks against privacy and a solution relying on the pre-loading of a set of anonymous public/private key pairs is proposed; this solution is complemented with a key-changing algorithm that changes the current key with a frequency that depends on the vehicle speed. In [24] a solution for privacy protection for non-safety communications between vehicle and infrastructure is proposed. In that solution vehicles are clustered in groups, and for each group a particular vehicle (the group leader) acts as a proxy on behalf of the vehicles in its group. Random silent periods are also used to protect anonymity of vehicles when they do not have to communicate with the infrastructure. In [19] an anonymization service that provides vehicles with a temporary identity is proposed. Vehicles can periodically renew their identity by showing a valid certificate to reanonymizers arranged along the roadside. Finally, in [20] a secure mechanism to form group of vehicles is proposed. This approach do not rely on a RSU infrastructure, and uses special vehicles (group leaders) that periodically broadcast their position, obtained through a GPS. The other vehicles choose the group to join based on positions broadcasted from leaders. 2.2. Mobility models In VANET simulations it is fundamental to use a realistic and complete mobility model, to obtain valid simulation results. In this section the most important mobility models currently available are detailed. Random Waypoint (RW) [23] is a simplified mobility model, in which the movement of a vehicle is represented by fixing a starting point and a timestep length. From its current point, a vehicle stops for a timestep and then randomly selects a new point; it then selects a random speed within a given interval, and moves towards the new point with the selected speed. The main limitation of RW is that vehicles move independently of each other, so the model cannot represent car-following. Further, it does not represent neither multi-lane roads nor traffic control mechanisms. RW model is applied in [23] together with maps of real US streets, that are used to constrain the – otherwise random – vehicle movement. Street Random Waypoint (StRaW) [8] is an improvement of RW: the mobility model is similar, but it represents car-following and traffic control. Like RW, it uses maps to constrain vehicle mobility. However, there is still no support for multi-lane roads and different road type definition – like urban and extra-urban roads, highways, etc. This

makes impossible to represent car overtaking and vehicle speed differentiation based on the current road type. VISSIM [4] is a complete and realistic mobility model, that represents car-following, multi-lane roads and car overtaking. The interaction between vehicles is obtained through a driver behaviour model, made up by four states. State transitions depend on the distance between two vehicles and their speeds. Lane-changing is allowed in multi-lane roads: a vehicle moves to its left lane if it is not in free driving mode and if the lane change let the vehicle move to a higher state. A vehicle moves to its right lane if it is not in braking mode and if the lane change let the vehicle remain in the same state. Using the VISSIM model, a VANET simulation tool has been implemented [14]. SUMO [1] is a complete vehicular mobility model that captures many features of a realistic vehicular traffic, like car-following, traffic control mechanisms, road and vehicle type definition, multi-lane roads, overtaking, etc. All these factors contribute to determine vehicle speed, that is also affected by the shape of the road. Further, SUMO deals with priorities at crossings: they are determined by traffic lights and by the types of the crossing roads. Moreover, SUMO allows to import scenarios from other simulators, like VISSIM, or to generate scenarios via an included highly customizable tool. Using the SUMO mobility model and the ns-2 network simulator, the TraNS tool [3] has been recently developed. TraNS is a VANET simulation environment that integrates the two different simulators (SUMO for the vehicular traffic part and ns-2 for the wireless network part). TraNS converts a SUMO simulation into a ns-2-compliant mobility trace file, that can be included in the ns-2 simulation to describe the mobility of the nodes. TraNS has been used in this paper to simulate the VIPER protocol. 3. The VIPER protocol This section details the VIPER protocol; the intuition behind this protocol is to have vehicles not to send their messages directly to the RSU, but to have vehicles acting as mixes [7]; further, messages are encrypted via a publickey crypto-system that allows re-encryption of messages. The mix is limited to nodes belonging to the same group, where a group is defined as the set of vehicles registered within a Road Side Unit (for details about vehicle registration see Section 3.4). We show that combining these techniques in an original way, the protocol is resilient against some traffic analysis attacks while preserving its scalability. 3.1. Routing When a vehicle needs to send a message to the RSU, it flips a biased coin, where faces are named, respectively, forward (with associated probability pf > 1=2) and send (with associated probability 1  pf ). If the result of the flip is for-

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802

ward, then VIPER randomly selects another vehicle (hereafter called relay) from the same group it belongs to, and this vehicle becomes the intended recipient of the message. Note that a vehicle could also select itself as a relay. If the result of the coin flip is send, the RSU is the recipient. When a relay node receives a message, it performs the same operations; that is it can set as next hop another randomly chosen vehicle with probability pf , or the RSU with probability 1  pf (see Fig. 1). The operations performed by a vehicle at the receipt of a message are summarized in Algorithm 1. When a message is received the next hop is locally decided as above described, and the message is encrypted (according to the operations described in Section 3.2) and queued. Every vehicle is required to send a batch of n messages at the end of every time slot. Note that message size, batch size, and time slot length are fixed. The vehicles act as mix nodes: that is, at the end of the time slot a subset of the messages in the queue is selected for sending (according to a specific policy – e.g. random selection –), and batch messages Algorithm 1. Operations performed at the end of a time slot

2793

for instance, it could be possible to adopt an ageing policy, to avoid having a message that remains in queue for an undefined amount of time. To prevent a particular kind of traffic analysis (that is, the message volume attack), the batch size must be fixed (see Section 4.1). To meet this requirement, if the number of queued messages is smaller than the batch size, VIPER adds some dummy messages to the queue. However, note that it is also possible that the number of messages to be sent could exceed the size of the queue. In this case, we assume that messages are lost; however, note that to reduce the number of discarded messages due to the total queue occupancy, one straightforward solution could be to increase the maximum queue size. As technology advances, reducing the constraints on on-board resources, this possibility will became more viable. Nevertheless, to show that our protocol efficiently leverages even a small sized queue, an analysis of message loss is provided in Section 4.3. The results show that with the proposed queue dimension (i.e. a queue of only n = 4 slots) the impact is tolerable (less than 1 65% of the messages are lost) and that with a queue of just 16 slots (that is just four times the size of the batch of n messages to send at the end of every time slot), the number of lost messages is negligible. The operations performed by a vehicle at the end of every time slot are summarized in Algorithm 2. Algorithm 2. Operations performed at the end of a time slot

are sent to their recipients in random order. Sent messages are dequeued. Note that batch messages selected for sending could be chosen according to different policies as well;

3.2. Message encryption

send forward

forward

Fig. 1. Example of routing in VIPER.

A message sent in VIPER has the structure depicted in Fig. 2. To prevent an eavesdropper to learn the identity of the sender from the sender field of the message, every message is encrypted. VIPER uses universal re-encryption

2794

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802 0

ID of the recipient RSU ID of the relay vehicle ID of the sender vehicle

Encrypted Message

Signature

with the public key of the RSU

Certificate

Fig. 2. Structure of a message.

[13], a public-key crypto-system based on ElGamal that allows re-encryption, that is a ciphertext can be encrypted again without first being decrypted, while requiring a single decryption on the recipient side. The scheme is applied in VIPER in the following way: the sender encrypts the message using the public key of the RSU and a secret encryption factor (locally chosen). Every relay re-encrypts the message using its own encryption factor, while the RSU (and only the RSU) decrypts the message using its private key. The universal re-encryption crypto-system works in the following way. Suppose that the triplet ðp; g; AÞ is the ElGamal public key of Alice, where p is a large prime, g is a generator of the multiplicative group Z p ; A ¼ ga ðmod pÞ and a is a secret value known only to Alice (i.e. her private key). In order to encrypt a message m with the public key ðp; g; AÞ, one has to generate a random encryption factor r and compute R ¼ gr ðmod pÞ and C ¼ m  Ar ðmod pÞ. The ciphertext is the pair ðC; RÞ. In order to re-encrypt the ciphertext, one has to generate a 0 random encryption factor r0 and compute R0 ¼ Rr ðmod pÞ 0 r0 and C ¼ C ðmod pÞ. In this case, the ciphertext is the pair ðC 0 ; R0 Þ. Alice can decrypt a ciphertext (regardless of how many re-encryptions have been done on it) computing m ¼ C 0 =R0a ðmod pÞ. Re-encryption, if performed as above exposed, can be a computationally expensive operation, because it requires a relay node to compute a modular exponentiation 0 C r ðmod pÞ, where the value p is represented over at least 512 bits. Note that this computationally expensive operation also requires a non-negligible time to be carried out. If the required time exceeds a given threshold, the protocol could not be adopted, regardless of its features. For instance, nowadays 450 ms are considered a suitable time elapse for non-time-constrained applications [21]. To reduce the number of operations required when the need for a message to be encrypted or re-encrypted arises, we resort to pre-computation, so that only a modular multiplication is required at run-time. In particular, we assume 0 that vehicles pre-compute k values < gr1 ðmod pÞ; r01 r0k r0k A ðmod pÞ >; . . . ; < g ðmod pÞ; A ðmod pÞ >. Hence, once a relay needs to re-encrypt a message, it can simply com-

0

pute R0j ¼ R  grj ðmod pÞ and C 0j ¼ C  Arj ðmod pÞ. Decryption is still possible thanks to the properties of the ElGamal public-key crypto-system. At the receipt of ðC; RÞ the relay node is just required to perform two modular multiplications to compute ðC 0 ; R0 Þ. Note that the same optimization can be used also for encryption. However, we cannot use this optimization for decryption because the a value R0 cannot be pre-computed, since the value R0 is available only at the receipt of an encrypted message. Finally, note that decryption is carried out by the RSU, that we can assume have enough computational power to manage decryption efficiently – within the required time constraints. Observe that the ciphertext size and the computational costs for all algorithms are exactly twice those of the basic ElGamal crypto-system. As for the random encryption factor r required by the algorithm, one possibility could be to have a true source of randomness on board of the vehicles; however, this cannot be always the case, hence a more feasible approach could be to rely on a good source of pseudo-randomness, like the Mersenne twister pseudo-random number generator [16]. One further issue to address is originated by the possible vulnerabilities that could arise since we are using k pre-computed values. To tackle this issue, please note that the properties of standard semantic security and also universal semantic security under re-encryption may be shown straightforwardly to be reducible to the Decision Diffie– Hellman (DDH) assumption [6], in much the same way as the semantic security of ElGamal [25]. Hence, resorting to pre-computations to speed-up the operations required by both the encryption and the re-encryption does not weaken the security of the protocol. The operations required for encryption, re-encryption and decryption with modular multiplication are summarized in Algorithms 3–5, respectively. Algorithm 3. Encryption of a message by a vehicle Input: Plaintext m, public key of the RSU (p, g, A), random encryption factor r Output: Ciphertext (C, R) C m  Ar ðmod pÞ; R gr ðmod pÞ;

Algorithm 4. Re-encryption of a message by a relay vehicle Input: Ciphertext (C, R), public key of the RSU (p, g, A), random encryption factor r0 Output: Ciphertext ðC 0 ; R0 Þ 0 C0 C  Ar ðmod pÞ; 0 R0 R  gr ðmod pÞ; The use of a crypto-system with re-encryption features has an important role regarding the VIPER resilience with respect to the message coding attack

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802

Algorithm 5. Decryption of a message by a RSU Input: Ciphertext ðC 0 ; R0 Þ, public key of the RSU (p, g, A), private key of the RSU a Output: Plaintext m m C 0 =R0a ðmod pÞ; (see Section 4.1) as well as efficiency: the RSU is required to perform a single decryption, even if each relay node has added a layer of encryption. Further, pre-computation allows each vehicle to encrypt/re-encrypt a message with just two modular multiplications. 3.3. Group membership notification As in VANETs node mobility is high, group membership can change frequently. In order to preserve the routing mechanism described in Section 3.1, group members have to be notified about group changes. In VIPER this task is accomplished by the RSU, through the periodic dispatch of group notification messages (GNMs). That is, the RSU periodically broadcasts a message containing the identities of the vehicles currently belonging to the group (the vehicles currently registered within that RSU). GNMs are signed by the RSU to let members verify its identity. At the receipt of a GNM, every node belonging to the corresponding group updates the group member identities locally stored. The updated identities are used in subsequent message transmissions, according to the routing scheme previously described. To prevent an adversary from learning the identities of all vehicles by eavesdropping on a GNM, that message could be encrypted using a group encryption algorithm like LKH [26]. This requires group members to be provided with the needed group keys, i.e. it is necessary to send a rekey message together with every GNM. Therefore, a GNM is made up by two parts, one for the update of the group keys needed for the decryption (according to LKH), and one for the update of the identities of the group members (Fig. 3).

2795

To prevent an insider adversary (an adversary that is registered within the RSU and can then decrypt a GNM) to learn the identities of the other group members, real identities have to be replaced with pseudonyms. That is, when a vehicle registers within a RSU (see Section 3.4), the latter assigns a new pseudonym to the former and communicates that pseudonym to the vehicle over a secure channel, such that only the vehicle and the RSU can link the pseudonym to the real identity of the vehicle. To prevent the Sybil attack [10], past pseudonyms cannot be used. That is, in every transmission the vehicle can use only the pseudonym assigned by its current RSU. 3.4. Registration Because of the high mobility of the vehicles, sometimes a vehicle (say, V) can leave from the area served by a RSU U and get into an area served by a different RSU U 0 . In this case, V has to register within U 0 and, as a consequence, to change group. To deal with this case, every RSU periodically broadcasts its public key. When V senses the signal of U 0 , in accordance to a specific policy it can decide to switch to U 0 (for instance, if the signal power of U 0 is greater than the signal power of U). When a switch is decided, node V stores the public key of U 0 and sends to U 0 a registration request, together with its ID, public key, certificate and a random number. This request is encrypted with the public key of U 0 , to prevent an adversary to track V through eavesdropping on its registration requests. The RSU U 0 then registers V and adds it to the new group. It then chooses a pseudonym for V and sends it together with the group keys needed by V for the decryption of the next GNM (see Section 3.3). Also this latter reply from U 0 is requested to be sent over a secure channel – for instance, encrypted with the public key of V. The removal of V from the old group managed by U can be achieved through an explicit communication by the new RSU U 0 . However, note that different policies could be adopted as well. 3.5. RSU replies

ID of the RSU Signature Pseudonym member 1

Encrypted ... Pseudonym member n

Rekey message

with the new LKH group keys Encrypted with the old LKH group keys

Fig. 3. Structure of a GNM.

Some messages (mostly Location-Based Service requests [21]) require a reply from the RSU. For example, the request of a route to a particular destination sent by a vehicle V to the RSU through a LBS request, needs a reply message containing the route itself. In these cases, the anonymity of V has to be protected not only in the request sending phase, but also in the reply transmission. On one hand, the RSU is not allowed to broadcast the reply message using a destination field in clear text, because an adversary could track V through eavesdropping on the replies from the RSU to V. On the other hand, it is unfeasible to broadcast the message encrypted with the public key of V, because every vehicle would have to try to decrypt this message to discern whether it is the intended recipient

2796

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802

or not. Note that this could introduce an excessive overhead since public key decryption is a computationally expensive operation. Our solution to this problem is to use HMAC to allow a vehicle to discriminate if it is the recipient of the message without requiring message decryption. Both the RSU and V share the secret value S V (they can exchange it secretly during the registration phase). Every reply from the RSU to V is then encrypted with the public key of V and broadcasted together with a random value r and the HMAC computed over the random value r and the secret value S V – that is, HMACðS V ; rÞ. When a vehicle receives the triplet: random value, HMAC, and encrypted message (< r; hmac; enc message >) it computes the value hmac0 ¼ HMACðr; S V Þ. If hmac0 ¼ hmac, then it is the intended recipient of the encrypted message, and can proceed to decrypt the message, otherwise it will not undertake this computationally expensive operation, since it is not the intended recipient. 4. Analysis and discussion In this section an analytical evaluation of VIPER is proposed, together with the discussion of the simulation results. Note that simulation results, that have been obtained using the VANET simulation environment TraNS [3], confirm our analytical findings, that is the performance of VIPER with regards to key indicators: queue occupancy, message path length and message delivery time, scales with the number of vehicles. Further, simulations show that the computational overhead introduced by our proposed encryption/re-encryption mechanism by far and large allows to respect the constraint posed by the requested response time. We also show a similar evaluation with respect to the number of dummy messages sent by vehicles. 4.1. Traffic analysis resilience In the following the resilience of the proposed protocol to traffic analysis [5] is discussed. Three attacks have been considered: message coding attack, message volume attack and timing attack. VIPER is resilient to the message coding attack thanks to the re-encryption operated by relay vehicles. Indeed, assume that an adversary could locally eavesdrop on the messages incoming to and outgoing from a relay vehicle. Since the relay vehicle re-encrypts every relayed message using a secret encryption factor, the message coding changes at every relay, making the tracking of the message impossible for the adversary. VIPER is resilient to the message volume attack because both the message and the batch size are fixed, while it is resilient to the timing attack thanks to the mix function carried out by the relay vehicles. By forcing vehicles to transmit and receive messages at fixed data rate, it is also impossible for a local eavesdropper to

track a message using different transmission and receiving intervals. 4.2. Performance analysis In this section the performance of the VIPER protocol is evaluated, with respect to key performance indicators, such as: the queue occupancy, the message path length and the message delivery time. We chose to evaluate these factors because of their relevance in vehicle-toinfrastructure applications. Indeed, it is desirable that queues contain just few messages, and that message paths are short enough to reduce the average message delivery time. The queue occupancy has been modelled using a time-discrete Markov process, where the random variable to analyse is the number of messages contained in a vehicle queue at the end of a time slot. The probability that a vehicle receives exactly k messages in a time slot is:   pf nGk nG pf k  Pk ¼ 1 ð1Þ G G k That is, k is a binomial random variable. Using the above probability, a Markovian analysis has been conducted. The parameters n (the batch size) and pf (the probability of forwarding a message to a relay vehicle), have been fixed to 4 and 0.6, respectively, while the queue size has been limited to eight messages, that is twice the batch size. The following six states have been identified for this Markov chain: (i) at the end of a time slot the queue of the vehicle contains a number of messages between 0 and 3; (ii) at the end of a time slot the queue of the vehicle contains four messages; (iii) at the end of a time slot the queue of the vehicle contains five messages; (iv) at the end of a time slot the queue of the vehicle contains six messages; (v) at the end of a time slot the queue of the vehicle contains seven messages; (vi) at the end of a time slot the queue of the vehicle contains eight messages; The first state represents the situation in which a vehicle can empty its queue at the end of the current time slot. This happens if the queue of the vehicle contains a number of messages between 0 and 3, because we set that in every time slot a vehicle sends a batch of four messages ðn ¼ 4Þ and one of them is a new message composed by the vehicle during the time slot. As we said before, the queue size has been limited to a maximum of eight messages. Using the probability distribution P k , the stochastic 1step transition matrix ½P  has been calculated:

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802

2

3

sum0;3

P4

P5

P6

P7

1  sum0;7

6 sum0;2 6 6 6 sum0;1 ½P  ¼ 6 6 P 0 6 6 4 0

P3 P2

P4 P3

P5 P4

P6 P5

P1

P2

P3

P4

P0 0

P1 P0

P2 P1

P3 P2

1  sum0;6 7 7 7 1  sum0;5 7 7 1  sum0;4 7 7 7 1  sum0;3 5

0

2797

Pk

ð2Þ

1  sum0;2

P where sum0;i ¼ ik¼0 P k . From the above ½P  matrix we calculated the limiting distribution vector, that expresses the probability that after an arbitrary number of time slots a vehicle is in one of the six states previously defined. Since this Markov chain is ergodic, the limiting distribution corresponds to the stationary distribution p, that is the stochastic vector such that p  ½P  ¼ p. To calculate such p we resolved the linear system:  T ðP  IÞ ¼ 0 ð3Þ uT p ¼ 1 where P is the 1-step transition matrix, I is the 6  6 identity matrix and u is the six-dimension unitary vector. Therefore, we resolved a system of seven first-degree equations with six variables, that allowed us to obtain the limiting distribution, plotted in Fig. 4. Note that the probability for a vehicle to empty its queue at the end of a time slot is around 0.6. The group size ðGÞ does not noticeably affect the queue occupancy. In Fig. 5 three diagrams for P k are represented, for three different values of G. Since the three plots follow the same trend, we argue that VIPER enjoys good scalability with respect to the queue occupancy. The expected value of the message path length, E½l, can be easily calculated because in the VIPER routing scheme every vehicle either forwards a message to a relay (with probability pf ) or sends it to the Road Side Unit (RSU, with probability 1  pf ). This means that l (the path length) is a geometrically distributed random variable, with parameter 1  pf . Using the above considerations, the expected value of the message path length can be calculated as

0.3 0.25 0.2 0.15 0.1 0.05 0 1000 0

1

2

3 k

100 4

5

6

7

G

8 10

Fig. 5. Probability of receiving k messages in a time slot.

E½l ¼

1 : 1  pf

ð4Þ

Using E½l, the expected value of the message delivery time can be calculated as well. In the VIPER routing scheme, the sender sends a batch of messages at the end of a time slot and every relay vehicle waits for a time slot and then forwards the messages, either to another relay or to the RSU. Then, the expected value of the message delivery time can be calculated as ! tts  pf 1 E½t ¼ tts  ðE½l  1Þ ¼ tts  1 ¼ ð5Þ 1  pf 1  pf where tts is the time slot length. E½l and E½t as functions of pf are plotted in Figs. 6 and 7, respectively, using the reference value of 300 ms as tts [21]. As in VANETs is important to reduce the message delivery time, the value 0.6 has been chosen for pf , that determines an expected message path length of 2.5 hops and an expected message delivery time of 450 ms. That amount of time is suitable for non-timeconstrained applications [21]. 4.3. Simulation and discussion To confirm the above results, the VIPER protocol has been simulated using the VANET simulation environ-

0.6

4

0.5

3.5

E[l]

probability

0.4

0.3

3

0.2

2.5 0.1

0 0-3

4

5 6 messages in queue

7

8

Fig. 4. Limiting distribution of having k messages in queue.

2 0.5

0.55

0.6

0.65

0.7

pf

Fig. 6. Expected value of the message path length.

0.75

2798

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802 0.9 1.8

% discarded messages

0.8

E[T] (s)

0.7 0.6 0.5 0.4

1.7

1.6

1.5

0.3 1.4

0.2 0.5

0.55

0.6

0.65

0.7

0.75

20

p

40

60

80

G

f

Fig. 7. Expected value of the message delivery time.

Fig. 9. Percentage of discarded messages.

ment TraNS [3], that integrates the vehicular traffic simulator SUMO [1] and the network simulator ns-2 [2]. The choice of the simulation tool is the result of a survey of the most popular vehicular mobility models, summarized in Section 2. VIPER has been simulated over an urban-like scenario, made up of a square area entirely covered by one RSU (all the vehicles in the simulation belong to the same group). The simulations have been repeated for different values of three parameters: G (the group size), n (the message batch size) and pf (the probability of forwarding). During the simulations, traces have been collected in order to measure the queue occupancy, the percentage of discarded messages (due to the total queue occupancy), the average message path length and the average message delivery time. In Fig. 8 the distribution of vehicles with respect to the queue occupancy is plotted, for four different values of G ranging from 20 to 80. The trend of the plots reflects the curve of Fig. 4. Note that the group size does not noticeably affect the queue occupancy, as argued in the performance analysis. For the same reason, the percentage of discarded messages depending on G (plotted in Fig. 9) is roughly constant. Therefore, these simulation results confirm the good scalability property of VIPER with respect to the queue occupancy.

To further evaluate the number of discarded messages due to the limitation on the number of slots devoted to implement the queue, we performed the simulations again, increasing the maximum queue size q. Since in the first set of simulations q was set equal to 2n (with n = 4 being the number of messages sent by each vehicle in a time slot), we repeated the simulations setting q equal to 3n and 4n, respectively. The results obtained are shown in Fig. 10. Note that for q ¼ 3n (i.e. a queue of just 12 messages) the percentage of discarded messages at the end of the simulation decreases noticeably (from 1.5% to 0.3%), while for q ¼ 4n (i.e. a queue of just 16 messages), the number of lost messages becomes negligible. That is, a small increase as for the amount of memory devoted to implement the queue – as can be foreseeable based on the considerations exposed in Section 3.1 – and the number of lost messages would drop to zero. In Figs. 11 and 12 the average message path length and delivery time as functions of pf – the probability of forwarding a message to a relay vehicle – are plotted. The trend of both the above mentioned plots is similar to the curves depicted in Figs. 6 and 7, respectively. Simulation results confirm that the choice of pf ¼ 0:6 corresponds to an average message path length of 2.5 hops and an average message delivery time of 450 ms.

70

0.4

G=20 G=40 G=60 G=80

% discarded messages

60

% vehicles

50 40 30 20

q=3n q=4n

0.3

0.2

0.1

10 0 0-3

0 4

5

6

messages in queue

Fig. 8. Queue occupancy.

7

8

20

40

60

80

G

Fig. 10. Percentage of discarded messages with bigger queue sizes.

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802

message path length

4

3.5

3

2.5

2 0.55

0.6

0.65 pf

0.7

0.75

Fig. 11. Message path length. 0.9

delivery time (s)

0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.55

0.6

0.65

0.7

0.75

pf

Fig. 12. Message delivery time.

4.4. Overhead analysis In this section we analyse the overhead introduced by VIPER in term of number of extra bits required, computations requested, time delay introduced and dummy messages sent. Indeed, ElGamal encryptions and reencryptions, operating with a fixed modulo p, can increase the message size; every relay vehicle has to perform cryptographic operations (i.e. re-encryption) on received messages before forwarding them; the routing mechanism adopted, that forces a message to possibly pass through a number of relays before being sent to the RSU, could introduce a delay in message delivery. Furthermore, as explained is Section 3.2, the RSUs have to decrypt messages, that in the ElGamal crypto-system is a computationally expensive operation (i.e. it is required to calculate a modular exponentiation). Finally, in VIPER vehicles can also send dummy messages, that have an impact on the bandwidth overhead. Analysis and simulations will show that the introduced overhead is perfectly sustainable for all of the parameters taken into consideration: extra bits required per message, computational overhead, introduced delay and number of dummy messages. VIPER uses ElGamal for encryption, re-encryption and decryption of messages; note that operations

2799

performed within the ElGamal crypto-system are modulo p. So, the size of a ciphertext can be expressed as sizec ¼ p  dsizep =pe bits, where sizep is the size of the plaintext in bits. This holds because operations modulo p force the length of ciphertext to be equal to p if sizep 6 p. Otherwise, it is necessary to split the plaintext in blocks of size p and compute the encryption on each block. Hence, the maximum number of extra bits introduced is p  1. In particular, a value commonly used for p is 512 bits, hence the maximum overhead introduced by ElGamal encryptions is 511 bits per block. As for the computational overhead introduced by the message splitting, note that since the typical plaintext size in vehicular communications is between 800 and 1600 bits [21], every encryption requires from 2 to 4 exponentiations. Similarly, every re-encryption requires from 2 to 4 multiplications. Note also that re-encryption is operated on messages already encrypted, whose size is then a multiple of p. This implies that no message size overhead is introduced by re-encryption. To measure the time overhead due to the cryptographic operations performed, during the VIPER simulations (described in Section 4.3) traces are collected every time a node generates, forwards and receives a message. These three operations correspond to an encryption, a re-encryption and a decryption, respectively. Both encryption and re-encryption are operated by vehicles and involve multiplications modulo p, so they introduce the same time overhead. As noted in Section 3.2, decryption (operated by RSUs) is a more computationally expensive operation because it requires to calculate a modular exponentiation. Note that the more expensive operation (i.e. the modular exponentiation) is done only by the RSU, whose computing power is greater than the vehicle computing power, while vehicles have only to perform two modular multiplications. This is due to the fact (see Section 3.2) that vehicles can leverage pre-computations, hence requiring just two modular multiplications when encryption/re-encryption is needed. In our simulations, every vehicle generates one message every 300 ms (according to [21]), and vehicles send messages for 78 s, that is the total simulation time. Under these conditions, the average number of modular multiplications done by a vehicle is 12.1 per second. As described in Section 4.3, during the simulations we let G (the group size) vary from 20 to 80. This allowed us to evaluate the relationship between the average number of cryptographic operations done by vehicles and G. As in the queue occupancy discussion, also in this case the variation of G does not noticeably affect the performances. In Fig. 13, the plot represents the average number of modular multiplications per second performed by a vehicle as a function of the group size. Note that the plot is roughly flat. This gives VIPER a good scalability property also with respect to the time overhead introduced by the cryptographic techniques used. To evaluate the time overhead introduced by the cryptographic operations also from the point of view of the RSU,

2800

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802 20

mean value variance

16

multiplications / sec

18 14

16 14

12

12 10

10 8 20

8 30

40

50 G

60

70

80

Fig. 13. Average number of modular multiplications per second per vehicle.

the mean value, the variance and the minimum and maximum values have been calculated for the number of exponentiations done by the RSU, together with the number of multiplications done by the whole group per second. To calculate these values, the number of vehicles in the group (G) has been fixed equal to 60. During the total simulation time (78 s), the number of cryptographic operations performed has been traced. The results are presented in Table 1. Note that the variance of both indicators is affected by the length of the sending interval. Indeed, since vehicles send encrypted messages every 300 ms [21], the number of cryptographic operations performed during a 1-s time-interval changes noticeably. This increases the variance as for the number of operations performed per second. Further, we evaluated the time overhead experienced by each vehicle within the group as well. During the simulations we traced the number of modular multiplications done by each vehicle for each second, and then calculated both the corresponding mean value and the variance – for each vehicle. The results are plotted in Fig. 14. Note that the mean value is similar for all vehicles. A similar analysis has been performed to evaluate the overhead of VIPER in terms of number of dummy messages sent by vehicles per second. Therefore, during simulations traces have been collected for each dummy message sent. The average number of dummy messages measured in the simulations is 1.99 messages per vehicle per second. This value (as in the evaluation of the queue occupancy, the message delivery time and the computational overhead) is not noticeably affected by G (the group size) as shown in Fig. 15.

Table 1 Variance, minimum and maximum values of the number of operations done in the whole group ðG ¼ 60Þ per second

Mean value Variance Minimum Maximum

Exponentiations (RSU)

Multiplications (vehicles)

327 561 294 456

806 675 745 931

6

0

10

20

30 vehicle ID

40

50

60

Fig. 14. Mean value and variance of the number of modular multiplications per second for each vehicle.

4

3

2

1

0 20

30

40

50 G

60

70

80

Fig. 15. Average number of dummy messages sent per second per vehicle.

The same metric has been evaluated with respect to the whole group of 60 vehicles. The mean value of the number of dummy messages sent per second by the whole group, together with the variance, minimum, and maximum values are presented in Table 2. As in the evaluation of the number of cryptographic operations done per second, also in this case the variance is affected by the length of the sending interval (300 ms). We evaluated also the overhead in terms of dummy messages sent by each vehicle of the group. The mean value of the number of dummy messages sent by each vehicle, together with the variance, are plotted in Fig. 16. Note that the mean value is similar for all vehicles.

Table 2 Variance, minimum and maximum values of the number of dummy messages sent by the whole group ðG ¼ 60Þ per second Dummy messages Mean value Variance Minimum Maximum

119.9 102 97 142

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802 10 9.5 9 8.5 8 7.5 7 6.5 6 5.5 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0

mean value variance

10

20

30 vehicle ID

40

50

60

Fig. 16. Mean value and variance of the number of dummy messages sent per second for each vehicle.

Finally, to complete the overhead analysis, the computation time needed to calculate a multiplication and an exponentiation modulo p has been measured. The hardware architecture used to this purpose is a GNU/Linux (i686) platform, with gcc-4.0.1 and OpenSSL 0.9.7e library for cryptographic primitives (without any external graphic acceleration). To measure the execution time for a given computational process we tracked the CPU cycles consumed during an execution of the process. The experiment were carried out on an Intel 2,16 GHz machine, that complies IA32 architecture (which provides cycle counter; a 64bit, unsigned number). We chose this architecture because its computational power can be comparable to the computational power of the CPU of a vehicle. The IA32 counter is accessed with the rdtsc (read time stamp counter) instruction, that takes no arguments and sets register %edx to the high-order 32 bits of the counter and register %eax to the low-order 32 bits. Based on this methodology, a pair of functions are integrated within our code to measure the total number of cycles that elapse between any two time points: #include"clock.h" void start_counter();/* Starts the counter */ double get_counter(); /* Returns: Number of cycles since last call to start_counter */ To verify the precision of this approach we invoked the counter just before and just after the function call sleep(sleeptime); (where sleeptime equals to 1 s). We obtained 2,161,354,923 as result value (i.e. 2161.4 MHz). We ran the two functions of interest (modular exponentiation and multiplication) for 1001 times each, and discarded the first execution time for cache warming purposes. Furthermore, results were gathered in run-level 1 to minimize interference from other system processes. The results for both operations were obtained through

2801

the average of 1000 measurements and for three different sizes of p. Results are summarized in Table 3. These values show that the average time needed by vehicles for message encryption and re-encryption with a key size of 512 bits is around 0.2 ms per second only (12.1  16.9 ls = 0.2 ms). Since the number of re-encryptions per second measured in the simulations are around 8, if we were not using precomputations this would require eight exponentiations, hence a vehicle would spend 44.8 ms (8  5.6 ms = 44.8 ms) each second on re-encryption, that is still an acceptable value. However, 512 bits is commonly considered as a weak key size [15], so a bigger key size can be needed. Using bigger key sizes (i.e. 928 and 1312 bits) the time spent each second by vehicles for exponentiations and multiplications increases, and is summarized in Table 4. Hence, for key sizes equal to 928 and 1312 bits, the use of modular exponentiation for message re-encryption is no more possible, because a consistent fraction of the second would be spent by vehicles in computing cryptographic operations. With stronger key sizes (i.e. 928 and 1312 bits) the cryptographic techniques used by our anonymity protocol are still feasible using pre-computations. Finally, note that while the time needed for a modular exponentiation increases noticeably with the key sizes, the growth of the time needed for a multiplication is lower. Indeed, with a 1312 bits key size, the exponentiation time is around 13 times bigger than with a 512 bits key size. Instead, the growth in multiplication time with the same key sizes is only around five times. This is in compliance with the observation [15] that for a key size of k bits, the overhead for exponentiation is Oðk 3 Þ while multiplication requires Oðk 2 Þ. 5. Conclusion and future work In this paper we have introduced VIPER: a Vehicle-toInfrastructure communication Privacy Enforcement pRotocol. VIPER re-interprets and combines in an original way two existing solutions: mix and universal re-encryption. The former is well known in the Internet context while the latter is a recent proposal in cryptography. The protoTable 3 Execution times for a modular computation Key size (bits)

Exponentiation (ms)

Multiplication (ls)

512 928 1312

5.6 26.71 71.7

16.9 47.9 89.1

Table 4 Time spent each second by vehicles for modular exponentiations and multiplications Key size (bits)

Exponentiation (ms)

Multiplication (ms)

512 928 1312

44.8 213.6 573.6

0.2 0.6 1.1

2802

P. Cencioni, R. Di Pietro / Computer Communications 31 (2008) 2790–2802

col is shown to be resilient to three major traffic analysis attacks: message coding attack, message volume attack and timing attack. Further, analytical results suggest that VIPER also performs well with respect to key performance indicators: queue occupancy, message path length and message delivery time, that is the performances of VIPER are only marginally affected by an increase in the number of vehicles. Simulation results support these analytical findings. Finally, a comprehensive analysis has been performed to assess the overhead introduced by our mechanism. Simulation results show that the overhead introduced by VIPER in terms of extra bits required, computations, time delay and number of dummy messages sent, are feasible even for increasing requirements on the security of the underlying cryptographic mechanisms. Future work includes the adaptation of VIPER to enforce security and privacy in Inter-Vehicle Communications (IVC). Acknowledgements This work has been supported by the EU FP6 projects: ‘‘European Satellite Communications Network of Excellence” (SatNEx II, IST-27393); PERSONA (Contract No. 045459); INTERMEDIA (Contract No. 38419). The authors would like to thank the anonymous reviewers – their comments have been very useful to improve the quality of this paper. References [1] SUMO, Simulation of Urban MObility. Available from: . [2] The VINT Project, ns-2, The network simulator. Available from: . [3] TraNS homepage. Available from: . [4] VISSIM homepage. Available from: . [5] O. Berthold, H. Federrath, M. Ko¨hntopp, Project anonymity and unobservability in the internet, CFP’00: Proceedings of the tenth conference on Computers, freedom and privacy, ACM Press, 2000. [6] D. Boneh, The decision Diffie–Hellman problem, in: ANTS-III: Proceedings of the Third International Symposium on Algorithmic Number Theory, Springer-Verlag, London, UK, 1998. [7] D.L. Chaum, Untraceable electronic mail, return addresses, and digital pseudonyms, Communications of the ACM 24 (2) (1981) 84– 90. [8] D.R. Choffnes, F.E. Bustamante, An integrated mobility and traffic model for vehicular wireless networks, in: VANET’05: Proceedings of the 2nd ACM international workshop on Vehicular ad hoc networks, ACM Press, 2005.

[9] R. Dingledine, N. Mathewson, P. Syverson, Tor: The SecondGeneration Onion Router, in: Proceedings of the 13th USENIX Security Symposium, USENIX, 2004. [10] J.R. Douceur, The sybil attack, in: Proceedings of the 1st International Workshop on Peer-to-Peer Systems (IPTPS’01), Springer, 2002. [11] M. Gerlach, VaneSe – an approach to VANET security, in: Proceedings of First International Workshop on Vehicle-to-Vehicle Communications (V2VCOM), IEEE Computer Society, 2005. [12] D. Goldschlag, M. Reed, P. Syverson, Hiding routing information, Information Hiding LNCS (1174) (1996) 137–150. [13] P. Golle, M. Jakobsson, A. Juels, P. Syverson, Universal reencryption for mixnets, in: Topics in Cryptology, CT-RSA 2004, Springer-Verlag, Inc., New York, 2002. [14] C. Gorgorin, V. Gradinescu, R. Diaconescu, V. Cristea, L. Iftode, An Integrated Vehicular and Network Simulator for Vehicular Ad-Hoc Networks, in: Proceedings of the 20th European Simulation and Modelling Conference, 2006. [15] A.K. Lenstra, E.R. Verheul, Selecting cryptographic key sizes, Journal of Cryptology 14 (4) (2001) 255–293. [16] M. Matsumoto, T. Nishimura, Mersenne twister: a 623-dimensionally equidistributed uniform pseudo-random number generator, ACM Transactions on Modeling and Computer Simulation 8 (1) (1998) 3–30. [17] P. Papadimitratos, V. Gligor, J.-P. Hubaux, Securing vehicular communications: assumptions, requirements, and principles, in: Workshop on Embedded Security in Cars (ESCAR), 2006. [18] P. Papadimitratos, A. Kung, J.-P. Hubaux, F. Kargl, Privacy and identity management for vehicular communication systems: a position paper, in: Workshop on Standards for Privacy in UserCentric Identity Management, 2006. [19] B. Parno, A. Perrig, Challenges in securing vehicular networks, in: Proceedings of Workshop on Hot Topics in Networks (HotNets-IV), 2005. [20] M. Raya, A. Aziz, J.-P. Hubaux, Efficient secure aggregation in VANETs, in: VANET’06: Proceedings of the 3rd International Workshop on Vehicular Ad hoc Networks, ACM Press, Los Angeles, CA, USA, 2006. [21] M. Raya, J.-P. Hubaux, Securing Vehicular Ad Hoc Networks, Journal of Computer Security, Special Issue on Security of Ad-Hoc and Sensor Networks 15 (1) (2007) 39–68. [22] M.K. Reiter, A.D. Rubin, Crowds: anonymity for web transactions, ACM Transactions on Information and System Security 1 (1) (1998) 66–92. [23] A.K. Saha, D.B. Johnson, Modeling mobility for vehicular ad hoc networks, in: VANET’04: Proceedings of the 1st ACM International Workshop on Vehicular Ad hoc Networks, ACM Press, 2004. [24] K. Sampigethaya, L. Huang, M. Li, R. Poovendran, K. Matsuura, K. Sezaki, CARAVAN: providing location privacy for VANET, in: Proceedings of the Embedded Security in Cars (ESCAR) Workshop, 2005. [25] Y. Tsiounis, M. Yung, On the security of elgamal based encryption, in: PKC’98: Proceedings of the First International Workshop on Practice and Theory in Public Key Cryptography, Springer-Verlag, London, UK, 1998. [26] C.K. Wong, M. Gouda, S.S. Lam, Secure group communications using key graphs, IEEE/ACM Transaction on Networking 8 (1) (2000) 16–30.