Secure protocols for data propagation and group communication in vehicular networks

Abstract

Vehicular networks are organized with high-mobility vehicles, which are a challenge to key agreement and secured communication among vehicles; hence, efficient cryptography schemes for lightweight ciphers are essential. Many security schemes for vehicular networks particularly take the secure propagation of traffic-related information into account. Group communication is desirable in vehicular networks, while groups of friends drive the vehicles to travel together. In this study, it is applied an asymmetric key mechanism and a group-based Elliptic Curve cryptograph to authenticate data propagation as also to individually secure group communication. The data propagation includes a flooding delay mechanism, where each vehicle participant in the propagation calculates an individual delay for propagation. As groups of vehicles move on the roadway toward same destinations, two alternative schemes of group key agreement in vehicle-to-vehicle and vehicle-to-infrastructure modes are proposed to secure group communication among the vehicles. Security analysis results present that the proposed schemes can effectively prevent malicious vehicle from participating in vehicular communications. Evaluation results show that the propagation delay mechanism can effectively reduce broadcast collision, and the delay results of the group key agreement schemes are acceptable.

1. Introduction

Secure data transmission in vehicle ad hoc networks (VANETs) has been an important issue. The disclosure environments with wireless connection are vulnerable to eavesdrop and spoofing; hence, a number of security researches in VANETs have been presented. Most of them have the same goal and vision to protect the vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications. Public key cryptography is always addressed as a foundation for VANET security requirements, since vehicles have enough capabilities, and be able to connect to the Internet through fixed stations. The propagation of traffic-related data such as traffic conditions, road safety, danger warnings, and vehicle's emergency braking is essential in order to keep safety for all vehicles moving on the roadway. In the real world, groups of friends could drive vehicles to travel together, so group communications are possible in VANETs. For the above reasons, the study focuses on the secure protocols for the traffic-related data propagation and group-based communication. The security issue for the propagation should be authentication replacing encryption cryptography in order to achieve fast broadcasting. Confidential communications are necessary, since the vehicles in a group always intent to share data solely among themselves. This study authenticates the propagation of traffic-related information in the V2V mode, while other vehicles can authenticate a disclosed propagation from a vehicle source using the asymmetric signature scheme. Structures of secure group communication are implemented in the V2V and V2I modes in order to overcome the high-frequency change in the vehicular topology. Vehicle groups apply the elliptic curve cryptography [1] to the group key agreement protocols.

Basically, a VANET is organized with heterogeneous connections, supporting inter-vehicle, vehicle-to-station, and inter-station communications. Inter-vehicle as V2V communication is unstable due to high-mobility vehicles on the roadway. Road-side stations (RSUs) are deployed on the roadside to assist vehicles in Internet connection and obtaining key-related materials. Most key materials for VANETs are mainly to safeguard the propagation information. A reliable propagation of traffic-related information is essential, so that vehicles can travel safely and keep the traffic flowing freely over the roadway. It is a challenge that a vehicle authenticates the incoming traffic notifications of vehicles next to each other using ad hoc key cryptography. Multi-hop routing in V2I mode is hard to achieve directly and timely significant traffic propagation between any two neighboring vehicles. In addition, the deployment of RSUs on each roadside to cover all moving vehicles is impossible. Real-time safety applications always achieve the purpose of accident avoidance and cooperative driving in VANETs. The data propagation in the V2V mode without a propagation schedule will induce the problems of communication collision and broadcast storms.

Public-key infrastructure (PKI) can protect vehicular communication using the public key cryptography. Vehicles have to apply for a valid key pair, certificated by trusted third party such as Certificate Authority (CA). In the V2I mode, vehicles connect to the PKI services through roadside RSUs, since RSUs always support wireless and wired techniques. Basically, one participant represented as a mobile vehicle or a fixed RSU should have an individual public/private key pair with the certificate for authentication, communication confidentiality, and integrity in VANETs. The asymmetric cryptography is not suitable to secure group communication, while one vehicle wants to transmit confidentially huge amount of data such as digital map-based information and multimedia to other vehicles in a group. Additionally, unstable V2V links cannot endure long periods of group communication. With the aid of RSUs in the V2I mode, the scattered vehicles can keep connections during a group communication session. Using a symmetric key to secured group communication improves the performance of delivering confidential data by comparing the data protected by all individual asymmetric-based keys of all participants.

Although vehicular computer has enough storage and computational capabilities without power-supply problems, light-weight, and strict security schemes are still essential to timely process data transmission in fast changes of VANET's topology. It is applied in this research the Elliptic Curve Diffie-Hellman (ECDH) to establish group keys to achieve secure group communication. ECDH belonging to the elliptic curve cryptography is a variant of the Diffie-Hellman (DH) key agreement scheme, allowing that two parties create a common secret key over an insecure channel. ECDH with 160-bit key lengths provides the same security level as the DH secret sharing protocol [2]. The original DH protocol with exponential operations needs a key of at least 1, 024 bits to achieve adequate security, and therefore includes additional computational overhead. For instance, vehicles A and B try to construct a shared key, and the public parameters (a prime and base point P as a well-known generator in DH, coefficients a and b, elliptic curve y² = x³ + ax + b) must be set first. A or B must have an appropriate key pair for elliptic curve cryptography, comprising an ECC private key, k (a randomly selected integer) and public key Z (Z = kP). Both A and B have a key pair each. Then, A and B exchange their public keys, so that A and B calculate particularly a secret key, GK₁(= k _A Z_B = k _A k _B P) and GK₂(= K _B Z_A = k _B k _A P).

The remaining of this paper is organized as follows. A number of security issues in VANETs are described in Section 2, while Section 3 defines the communication scenarios and security requirements in a general vehicle architecture, where a propagation delay mechanism is also discussed. Section 4 details the key agreement schemes for group communication, followed by security and delay analyses in Section 5. Section 6 evaluates the performance of the proposed schemes in term of communication delay, and message loss ratio, and finally conclusions remarks and future work are presented in Section 7.

2. Related works

Vehicular communication has specific characteristics different from ad hoc communication, which characteristics may affect the security decisions that developers have to take. The features exhibited in the V2V and V2I modes contain the geographically constrained topology, directional movement, predictable mobility, sufficient power consumption, and route-based driving cooperation. Most of security issues in ad hoc networks are not entirely employed nor considered in vehicular communication.

Key pre-distribution schemes [3] relies on a probability of a large number of common keys among nodes that are not suitable for vehicles with open environments. Group-based security methods [4–9] usually outperform other methods in secure one-to-many transmission in terms of performance, scalability, and communication overhead. Lin et al. [4] addressed a security protocol, named Group Signature and Identity-based Signature (GSIS), to provide not only the requirements of security and privacy preserving, but also a group-based signature scheme to verify data transmission using a group's public key. The GSIS solves the mutual authentication problem for inter-vehicle group communication applications. A receiver accepting a group message can only confirm whether the sender is a member in the group, though not identifying the sender. A larger computational overhead is generated in GSIS for maintaining a revocation list. The efficient traceability can be achieved without the storage overhead of managing a number of certificates at membership and tracing manger. A group key agreement method, called GDH [5], generalizes upon the well-known DH key exchange. A sender generates and delivers a list of partial keys replacing the whole shared key to a receiver over the public network, so the receiver uses its partial key to compute the group secret. In addition, the particular member of the group is charged with the task of building and distributing this list. For this reason, this study adopts the ECDH-based key agreement protocol to establish group keys for secured group communication among vehicles.

The position-based routing protocol [10] is suitable for vehicular communication, since the GSP system is always one of the basic equipments inside vehicles. Broustis et al. collected some routing schemes to vehicular communication, such as MDDV [11] and GSR [12]. Most of ad hoc routing schemes are inappropriate, since vehicle mobility and data forwarding are required with a direction. One vehicle in MDDV knows the road topology through a digital map, and its position can be found in the road network via a GPS device, as also the existence of their neighbors. MDDV is performed in two phases, namely forwarding and propagation phases, to exchange data between two vehicles and to address the questions about which vehicle can transmit, when to transmit, and when to store/drop messages. In the GSR protocol, a vehicle source predicts the position of a vehicle destination for communication. The source discovers the destination with a request once, and the destination responds its position and velocity back to the source. Based on the map information, the source transfers data to the destination after predicting its position. Consequently, GSR combines the position-based routing with the topological information. In this research, one head tries to deliver a key product to the next neighboring head in a global group using the above-mentioned routing protocol.

Zarki et al. [13] proposed a potential simple security infrastructure for vehicular communication on the highway, called DAHNI. The infrastructure turns vehicles to have the capabilities of location awareness, ad hoc routing, accessing to fixed base stations. The DAHNI provides the security issues including, at least, digital signature, time-stamping and sequencing, and a certification infrastructure. Data in DAHNI environment can be addressed with three types, namely, fixed spatial data, spatio-temporal data, and mobile data. Unfortunately, the DAHNI still presents problems to enable secure collection and dissemination of data timely. Cryptographic mechanisms of the identity-based encryption [14] and the proxy signature [15] are often adapted in V2I communication scenarios. Choi et al. [16] developed security mechanisms to protect vehicular communication. In the initial phase, vehicles and RSUs need to register their identities with the trust authority (TA) to capture their temporary key-related materials and private/public key pair of elliptic curve cryptography. One vehicle gains a pseudo-ID and essential parameters for implementing a temporal signature after authentication. BSU also receives confidentially a private key and proxy signature's parameters from the TA, after authentication. In any of V2I communication scenarios, vehicle and RSU have a mutual authentication in order to share a session key. The vehicle accepts a temporal anonymous certificate from the RSU, and the data transmission is protected by the session key. In V2V communication scenarios, each vehicle has a key pair and a certificate by the Elliptic Curve Digital Signature Architecture (ECDSA) [17]. Broadcasting traffic-related information signed by one vehicle with its private key can be authenticated by others with its disclosure valid certificate. This study applies the temporary asymmetric cryptography and signature to the proposed delay propagation and travel-based group communication scenarios. Each participant needs to hold a key pair based on the elliptic curve cryptography in advance. The procedures of authenticating the delay propagation and securing the agreement of group-based key are the main contributions in the study.

3. System model

A vehicle network under highways and rural roads as presented in this section not only complies with the security requirements, but also has some assumptions: (1) each vehicle is equipped with a wireless omni-directional antenna, GPS device, and digital map, (2) RSUs connect to the Internet through wired or wireless technologies, where two neighboring RSUs can communicate easily and quickly each other, (3) any two vehicles equipped with the dedicated short range communications (DSRC) protocol as IEEE 802.11p [18] has the same transmission range for inter-vehicle communication, (4) vehicles have event-based sensors to sense traffic and road statuses, and share a digital map such as Google Map, (5) each vehicle periodically sends a hello beacon to its neighborhood, and a beacon only contains the identity of the sender, and (6) RSUs on the roadway are managed by the servers on the Internet, and the servers connect to the trusted third party in the PKI services, as shown in Table 1.

Table 1 Notations in this study

Vehicles and RSUs are authenticated by trusted third party through the authentication procedure [16] at the initialization of a VANET. After identity authentication, each of them has a valid key pair and warranty/certificate.

3.1. Vehicular network architecture and communication scenarios

Two types of communication modes, V2V and V2I, in the vehicle network are depicted in Figure 1. The position of one vehicle can be tracked by the neighboring vehicles in a short period through the announced GPS and velocity information [19]. The GPS data of vehicles should not be disclosed in VANETs at will, since adversaries easily track vehicles according to their GPS and speed data. Vehicle applications require that vehicles share their position to each other to achieve the computation or routing purposes. In this study, vehicles need to announce their GPS data to participate the delay propagation of traffic-related information and becoming a head for the V2V group communication. The VANET performs the real-time propagation of the emergency information in the V2V mode, when a traffic-related event is happening. The vehicles in movement on a roadway with the reverse direction, different on where the event happened will not participate in the propagation, even if received the information; moreover, the vehicles moving from the front of the event location on the roadway will also not propagate the information. For example, Car 2 has a traffic event in Figure 1, while Cars 1 and 10 will not participate in the propagation of the traffic event in the network.

Figure 1

The V2V and V2I communication modes in VANETs.

Group communication is desirable in vehicle networks, while groups of friends drive vehicles to travel together. They can establish a group to share data such as multimedia and map information, even if their vehicles are moving close or apart from each other on the same roadway. Their group communication scenarios are implemented through the V2V or V2I mode in this study. A physical group with the subset of the vehicles moving closely each other in the V2V mode must have a mobile head, and the head always moves at a steady velocity up or down a slight degree incline. The head has one-hop neighboring vehicles as its members in the physical group. All of the physical groups only organized by the scattered vehicles form a hierarchical group, denoted as a global group. In Figure 1, Cars 7-9 know about each other and could organize a physical group, and Car 8 is the head. The other alternative of group communication is to establish a virtual group in the V2I mode. The vehicles organize multiple localized groups with the RSUs on the roadside of the travel path. One of the RSUs organizes a localized group with the subset of the vehicles; hence, all of the localized groups form a virtual group. The RSUs participating in the virtual group are denoted as head avatars to service for all of the vehicles. Still in the Figure 1, cars 6, 10, and 11 on the same roadway organize a virtual group with RSU1 and RSU2. The set of RSUs on the roadside is managed by the trusted server on the Internet; hence, the server must connect the trusted party to maintain the security requirements of the RSUs. If a vehicle tries to apply for a virtual group, then the server will select the appropriate RSUs for it. Consequently, V2V-based global and V2I-based virtual groups are addressed, with different ways of selecting their heads. A global group is appropriate to the vehicles without connection gaps, and a virtual group is appropriate to them with high-frequency broken connections.

3.2. Propagation delay mechanism

A self-determined delay scheme is combined with the data propagation in order to avoid broadcast storms and propagation collision. A vehicle, denoted as r, receives a fresh traffic-related warning message from one of its front vehicles, denoted as s, and must delay a little time before propagation, denoted as Δt, given by the following equation:

\text{Δ}{t}_p=\alpha \times \frac{\left(1-\left(\mathsf{\text{(Spee}}{\mathsf{\text{d}}}_s-\mathsf{\text{Spee}}{\mathsf{\text{d}}}_r\mathsf{\text{)}}∕v\mathsf{\text{limit}}\right)\right)}{\mathsf{\text{(}}\text{Δ}dp{j}_{s\to r}∕R_{\mathsf{\text{T}}}\mathsf{\text{)}}}

(1)

where, v limit is the maximum speed limit in the area where the vehicle moves, Speed _s and Speed _r are the velocities of s and r, individually, smaller than v limit, R_T is the transmission range of vehicles, Δdpj is the projection distance from s to r over the vector from the preceding sender of s to s, and α is a value proportional to the number of the rear neighboring nodes of r. For example, v _{i +1} , v _{i +2} , and v _i are represented as s, r, and the preceding sender of s in Figure 2. Vehicle v _{i +2} must wait a self-determined delay time as calculated in Equation (1), once v _{i +2} receives the traffic-related information from v _{i +1} . Vehicle v _{i +2} will continue to propagate if receives no same message from its rear neighboring vehicles, after waiting the delay time. To calculate the projection distance, v _{i +2} needs to gain the GPS positions and the velocities of v _i and v _{i +1} . The sensitive data of v _i and v _{i +1} are attached to the propagation from v _i to v _{i +2} , and furthermore v _{i +2} has to verify the data. Section 4.1 details the procedure of propagating a warning message within an authentication format.

Figure 2

Example of the delay propagation of the traffic-related information.

3.3. Security requirements

A traffic-related message always involves safety-critical information. Attackers could try to endanger road-traffic or node-vehicle safety by broadcasting incorrect or tamping messages. For the reason, the propagation generated from a source must achieve data integrity and identity authentication. The propagation of a traffic-related message is attached with GPS data of vehicles for calculating their individual delay time; hence, the propagation procedure involves the verification of the sensitive data.

A session group key for a global or virtual group should be established quickly among participating vehicles, due to fast topology changes in VANETs. The vehicles use the valid group key to achieve secure communication in terms of data authentication, data confidentiality, and data integrity. Group communication in this study is designed with the purpose that groups of friends drive vehicles traveling together; hence, the vehicles always know about each other. To apply for a virtual group, one of them has to connect to the server on the Internet through one of its neighboring RSUs. The mutual authentication between Vehicle and BSU is necessary to prevent against adversaries masquerade as legal participants. An attacker could apply for a virtual group using a travel route of the digital map, where the vehicles are traveling at present; hence, it is important that how to prevent those applications from the attacker. Head avatars in a virtual group need to hold essential key materials for the vehicles, and thus, the vehicles on a travel route will share securely data through the head avatars in the virtual group. Two groups with different members cannot produce the same group key, even if they travel on the same route toward same destinations. Groups without any RSU need a global key to communicate securely among the vehicles.

4. Proposed security mechanisms

This section introduces the procedures of the delay propagation of a traffic-related message and secure group communication.

4.1. Authentication of the delay propagation

If detecting a traffic-related event, one vehicle will broadcast a new warning message to the neighborhood, and as any of the neighboring vehicles receive the message will ignore the propagation if received other warnings recording the same event in advance. Basically, traffic-related events happen to close or same to the locations of the vehicle sources, and the neighboring vehicle can detect whether the propagations are same or not by comparing to the event type, the position of the event happenings, and timestamps provided by the sources.

Suppose a propagation path containing the participating vehicles (v _i , i ∈ 0 ~ i + 2) is denoted as v₀ → v₁ →⋯→ v _i → v _{i +1} → v _{i +2} , and v₀ is the vehicle source, first broadcasting a fresh traffic-related warning message. The message, denoted as Warn#0, includes the sensitive data (i.e., identity, GPS, and speed) of v₀, an event type (Event _k ), and the timestamp. Vehicle v₀ has to sign the Warn#0, so that other vehicles can verify the message in the future. Vehicle v₁ modifies the Warn#0 by adding its sensitive data and timestamp, once received and verified it. Vehicle v₂ performs same tasks as Vehicle v₁, after receiving the Warn#1 from v₁. Accordingly, the other vehicles in the propagation path can follow a format to make their warning messages. The warning format only retains the identities, GPS data, and velocities of two closest previous participants for computing the individual delay time. The certificates in the format will verify whether the participants and their attached data are valid in VANETs. Consequently, a warning message propagating in a lengthy path can efficiently be authenticated in each hop, while the packet size of the message is constant. The authentication procedure of the delay propagation in the path is given as follows:

• 1. v ₀ detects a traffic event, and propagates immediately a warning message:

  • Warn#0(v₀, GPS _{v 0}, Speed _{v 0}, Event _k , Tstamp#0), Sign(Warn#0, SK _{v 0}), Cert _{v 0}.

• 2. v ₁ verifies the source, and calculates the delay time. The direct distance from v ₀ to v ₁ replaces the projection distance of the delay time, since v ₁ has the preceding sender of v ₀. After waiting the delay time, v ₁ propagates the modified warning message:

  • Warn#1(v₀, v₁, GPS _{v 0}, GPS _{v 1}, Speed _{v 0}, Speed _{v 1} , Event _k , Tstamp#0, Tstamp#1, Speed#1), Sign(Warn#0, SK _{v 0}), Sign(Warn#1, SK _{v 1}), Cert _{v 0}, Cert _{v 1}.

• 3. v ₂ verifies the source, and calculates the delay time, the two preceding senders, v ₀ and v ₁. After waiting the delay time, v ₂ propagates the Warn#2 as follows:

  • Warn#2(v₀, v₁, v₂, GPS _{v 0}, GPS _{v 1}, GPS _{v 2}, Speed _{v 0}, Speed _{v 1}, Speed _{v 2}, Event _k , Tstamp#0, Tstamp#1, Tstamp#2), Sign(Warn#0, SK _{v 0}), Sign(Warn#1, SK _{v 1}), Sign(Warn#2, SK _{v 2}), Cert _{v 0}, Cert _{v 1}, Cert _{v 2}.

• 4. v ₃ performs the same tasks as v ₃, but removes the data of v ₁ in the modified warning message, since the data are useless to v ₄, in calculating the delay time. After waiting the delay time, v ₃ propagates the Warn#3 as follows:

  • Warn#3(v₀, v₂, v₃, GPS _{v 0}, GPS _{v 2}, GPS _{v 3}, Speed _{v 0}, Speed _{v 2}, Speed _{v 3}, Event _k , Tstamp#0, Tstamp#2, Tstamp#3), Sign(Warn#0, SK _{v 0}), Sign(Warn#2, SK _{v 2}), Sign(Warn#3, SK _{v 3}), Cert _{v 0}, Cert _{v 2}, Cert _{v 3}.

• 5. The propagation continues by following on the remainder path: v ₃ → v ₄ ⋯ → v _{i -1} → v _i → v _{i +1} . The warning format of v _{i +1} 's propagation is denoted as:

  • Warn#i(v₀, v _i , v _{i +1} , GPS _{v 0}, GPS _vi , GPS _{vi +1}, Speed _{v 0}, Speed _vi , Speed _{vi +1}, Event _k , Tstamp#0, Tstamp#i, Tstamp#i+1), Sign(Warn#0, SK _{v 0}), Sign(Warn#v _i , SK _vi ), Sign(Warn#v _{i +1} , SK _{vi +1}), Cert _{v 0}, Cert _vi , Cert _{vi +1}.

4.2. Secure communication in a global group without RSUs

When areas have no RSU such as rural roads, the vehicles traveling together organize a number of one-hop physical groups. Each of them can know its neighboring vehicles by broadcasting periodically a hello beacon. Each physical group needs a head, called TH, moving with a steady velocity in order to coordinate the establishment of a group key. Any of vehicles keeping a steady velocity for a tiny period of time will automatically become a TH and announce the role with a two-hop broadcast strategy, while having no neighboring THs. The two-hop broadcast strategy means that an announcement can be forwarded to two-hop neighboring nodes. To avoid communication collisions during the announcement period of THs, each TH announces its role after waiting the individual delay time, as determined by Equation (2):

\text{Δ}{t}_A=\beta \times \frac{\text{Δ}{d}_{\text{TH}j\to \text{Dest}}^{tp}}{\text{Max}(\{\text{Δ}{d}_{\text{TH}j\to \text{Dest}}^{tp}\text{})}}\times \text{NumofTHs},j\in 0~n,

(2)

where the NumberOfTHs is the predictive number of THs, larger than or equal to the number of the practical THs (n), \text{Δ}{d}_{\mathsf{\text{TH}}j\to \mathsf{\text{Dest}}}^{tp} is the approximate distance between the locations of TH _j and the traveling destination, Dest on the route of the digital map, the \text{Max}(\{\text{Δ}{d}_{\text{TH}j\to \text{Dest}}^{tp}\text{})} as a function will return the maximum value of the set, \{\text{Δ}{d}_{\text{TH}j\to \text{Dest}}^{tp}\text{}}, and β is a value proportional to the average propagation delay of one hop. In Equation (2), vehicular computers using the map-based service APIs such as GoogleMap [20] can easily calculate the approximate distance between two locations on a route in the digital map. The announcement information contains the GPS position of the TH.

Each of the one-hop neighboring vehicles that receive the announcement will respond as it becomes a member of the TH. Each member selects only one TH as its head in the physical group.

Suppose one TH, TH _x , has as one-hop neighboring members, denoted {M _i }. TH _x broadcasts a request to {M _i } for establishing a group key, after appending its identity, velocity, GPS, and the list of {M _i } within a particular sequence, denoted as NList _x to the request. The vehicles in {M _i } moving on the front locations of the travel roadway have a high priority on the front of the arrangement of NList _x . The request is defined as follows:

TH _x → {M _i }: Req@(v _x , Speed _x , GPS _x , NList _x ), Sign(Req@, SK_THx), Cert _x .

Suppose that the vehicles {M₁, M₂, ..., M_(x-1)} in the NList _x are neighbors to TH _x , and {M _i } exchange the ECDH-based public keys each other. Each of M _i generates a private and public key pair, K₁ and K₁P, while P is a well-known generator. In addition, TH _x also has its key pair, K _x and K _x P. At the beginning of the key agreement protocol, M₁ as the first vehicle broadcasts its neighborhood immediately. M₂ cannot broadcast its K₂P until it receives the K₁P from M₁. Just like M₂, the others broadcast their public keys according to the order in NList _x . TH _x can help one of {M _i } forwarding its public key to the next member. After exchanging completely public keys, each M _i has to unicast the result (K₁K₂...K_(i-1)K_{(i+ 1)}...K_{(x- 1)}P) without the K _i P to TH _x . TH _x returns individually a response by multiplying its private key for M _i , such as (K₁K₂...K_(i-1)K_(i+1)...K_(x-1)K _x P). Finally, M _i multiplies the response with its private key to have granted the group key, g{k}_x\left(={\prod }_{i=1}^x{K}_{i}P\right). Consequently, the group key is shared among the TH _x and its {M _i } in order to secure communication in the physical group.

Any TH knows its two-hop neighboring THs, after completing the announcement procedure. All of the THs in the physical groups establish a global group key for all of the vehicles based on the position-based routing. To avoid the key disclosure, each TH multiplies a pseudo private and public key pair, gk' and gk'P. The TH moving at the top of the traveling path must become the root to start the key agreement process, while the other THs are always moving behind itself. Supposing that there are multiple THs, denoted as (TH₁, TH₂, ..., TH _{n -1}, TH _n ), and TH _j always moves behind TH _{j -1}. The procedure started by TH₁ using the on-demand routing in the V2V mode for establishing a global group key is detailed as follows:

• 1. TH₁ forwards its < gk ₁ 'P > to its neighboring TH₂ using one of ad hoc routing schemes such as the position routing [10]. Once the data is stored, TH₂ generates and sends a product < gk ₂'gk ₁'P > to TH₃. Just like the previous TH, TH₃ generates and sends a product < gk ₃'gk ₂'gk ₁'P > to TH₄.

• 2. The process of forwarding the product continues by following the remainder path: TH₄ → TH₅ → ⋯ → TH _{n -1}. TH _{n -1} delivers the {\displaystyle {\prod }_{i=1}^{n-1}g{k}_i^{\text{'}}P} to TH _n , after storing the product {\prod }_{i=1}^{n-2}g{k{}_i}^{\prime }P from TH _{n -2} .

• 3. TH _n generates the global group key, {\prod }_{i=1}^{n}g{k{}_i}^{\prime }P, by multiplying the product of TH _{n -1} with its pseudo private key, gk _n '. However, TH _n must return its public key, gk _n 'P, back to TH _{n -1} using the previous routing path.

• 4. TH _{n -1} can generate the global group key, after multiplying {\prod }_{i=1}^{n-2}g{k{}_i}^{\prime }P by (gk _{n -1}'gk _n 'P), and returns the gk _{n -1}'gk _n 'P to TH _{n -2} .

• 5. Just like TH _{n -1}, TH _{n -2} generates the key, and returns the product gk _{n -2} 'gk _{n -1}'gk _n 'P to TH _{n -3} .

• 6. Returning the product continues by following on the remainder path: TH _{n -3} → TH _{n -4} → ⋯ → TH _j ⋯ → TH₁. TH _j returns the product to its previous TH _{j -1}, {\prod }_{i=1}^{n}g{k{}_i}^{\prime }P after generating the group key.

• 7. TH₁ receives the product, {\prod }_{i=2}^{n}g{k{}_i}^{\prime }P from TH₂. The key agreement process is done, and the group key, {\prod }_{i=1}^{n}g{k{}_i}^{\prime }P has shared among the THs.

• 8. Finally, each TH distributes the global group key to its member by encrypted with the physical group key, gk _x . The message is defined as follows:

If the last step is excluded, there are the extra encryption/decryption overheads. The secure group communication from M _i to the others is then detailed as follows:

M _i → TH _i :

Stream#(M _i , Multimedia, Tstamp), MAC(Stream#, gk _i ), or

E(Stream#(v₁, Multimedia, Tstamp), gk _i ), MAC(E(...), gk _i )

TH _i → {TH _j | j ∈ 1 - n, j! = i}:

Stream#, MAC(Stream#, GGK), or E(Stream#, GGK), MAC(E(...), GGK)

TH _j → {M _j }:

Stream#, MAC(Stream#, gk _j ), or E(Stream#, vgk _j ), MAC(E(...), gk _j ), where {M_j} are the members of TH _j .

4.3. Secure communication in a virtual group with multiple RSUs

According to the vehicle architecture in Section 3.1, legal RSUs on the roadside are managed by a number of servers on Internet. The servers are assumed to be able to connect to the trusted third parties. The scattered vehicles moving in the trip can organize a virtual group with the RSUs. Figure 3 illustrates that v₁ asks for a virtual group to establish group communication, while the vehicles (v₁-v _n ) travel on the route toward the common destination. The others (v₂-v _n ) could also apply for the group through their neighboring RSUs during traveling. Suppose that the v₁ sends a request with the travel-related information to a valid RSU, RSU _i . The RSU _i checks whether v₁ and the request are valid, by examining the certificate and the attached timestamp. If the request is not yet expired, RSU _i checks its local storage whether the RSU set exists or not, in order to serve the same vehicles on the route within the same trip period. RSU _i responds immediately to v₁, if the set is always available in the storage; otherwise, if the set is not existent or has been expired, RSU _i will forward the request to its server on the Internet, denoted as Root. The procedure is that v₁ applies for a set of the RSUs using the information of a travel route which is detailed as follows:

Figure 3

Illustration of the architecture of a virtual group, and the five phases of the key agreement to establish a VGK, shared among the vehicles ( v ₁ - v _n ). Assume that the vehicles travel on the route toward the common destination.

Phase 1. Vehicle v₁ sends Req# to RSU _i , and attaching with the identities of the vehicles, the required trip period (ΔT), the current timestamp (Tstamp), and the travel route in a digital map (TP_map). The request is signed with its private key.

v₁ → RSU _i : Req# (v₁, ΔT, Tstamp, TP_map, {v _i |i ∈ 1-n}), Sign(Req#, SK _{v 1}), Cert _{v 1}

Phase 2. Suppose that the set of RSUs is not existent for the request. RSU _i forwards the request to the Root with an attached MAC code, while sharing a common key with the Root. If RSU _i and Root have no common key, the signature of RSU _i will replace the MAC code.

RSU _i → Root:

Req# (v₁, ΔT, Tstamp, TP_map, {v _i }), Sign(Req#, SK_v1), Cert _{v 1}, MAC(Req#||Sign, K_{Root, RSUi}), or

Req# (v₁, ΔT, Tstamp, TP_map, {v _i }), Sign(Req#, SK_v1), Sign(Req#, SK_RSUi), Cert _{v 1}, Cert_RSUi

Phase 3. Root authenticates the Req# using the v₁'s PK_v1, and RSU _i is verified through the MAC code or its signature. If the authentication is successful, Root determines the subset of RSUs located on the route, TP_map, and sends an encrypted Resp# back to RSU _i . The Resp# is attached with the identities of the selected RSU _j , the TP_map, and an expiration time (ETime), a VGK, and a key pair for {R _j }, (GK_set, GK_setP) (i.e., set = hash(tp||ΔT||{R _j }||{v _i }||Tstamp)). The response is encrypted by the key shared between RSU _i and Root, or the public key of RSU _i to prevent eavesdropping and modification from attackers on the Internet.

Root→RSU _i :

E#(Resp#'_tp, Sign#_Root, E(Resp#_tp, Sign#_Root, PK _{v 1}), K_{Root, RSUi}), MAC(E#, K_{Root, RSUi}), or

E#(Resp#'_tp, Sign#'_Root, E(Resp#_tp, Sign#_Root, PK _{v 1}), PK_RSUi), where Resp#_tp is generated for the vehicles (i.e., Resp#_tp = Resp#({R _j }, TP_map, ETime)), Resp#'_tp is generated for the chosen RSUs (i.e., Resp#'_tp = Resp#(VGK, GK_set, GK_setP, {R _j }, {v _i }, TP_map, ETime, ΔT)), and Sign#_Root (or Sign'#_Root) represents that the Resp#_tp (or Resp#'_tp) is signed by SK_Root.

Phase 4. RSU _i forwards the Resp#'_tp to the other RSUs in the {R _j }. Any two RSUs connecting to the Internet can easily establish a shared secret key, K_{RSUi, RSUj}. In addition, RSU _i has to forward the encrypted Resp#_tp to v 1.

RSU _i → {RSU _j |j ∈ 1-n, j! = i}:

E(Resp#'_tp, Sign#'_Root, K_{RSUi, RSUj}), MAC(E(...), K_{RSUi, RSUj})

RSU _i → v₁: E(Resp#_tp, Sign#_Root, PK _{v 1})

Phase 5. Each of {RSU _j } stores the tuple, (GK_set, GK_setP, {R _j }, {v _i }, TP_map, ETime, ΔT), in the storage until the ETime is expired. {RSU _j } sends a notification to {v _i }, if the vehicles is moving in their transmission ranges.

Each RSU _i → a subset of {v _i }:

Notify# (the RSU set is ready for your trip), Sign(Notify#, SK_RSUi), Cert_RSUi

{RSU _j } as head avatars assist the scattered vehicles in aggregating a VGK within their transmission ranges. Suppose that one of {RSU _j }, R _x , has a few of the vehicles {v _y |y ∈ 1-j, n > j} within its transmission range, exactly as a cluster. The members in {v _y } are arranged in a sequence, when v _j always moves behind v _{j -1}. Figure 4 depicts a localized key agreement process among R _x and {v _y }, with the following steps:

Figure 4

Illustration of establishing a group key in a localized group.

• 1. R _x replies a message, Resp& to {v _y } as a subset of the vehicles, when v _i in {v _y } sends Req# to R _x .

  R _x → broadcast: Resp&({v _y }, ETime, GK_setP), Sign(Resp&, SK _Rx ), Cert _x .

• 2. One member (v ₁) generates a key pair, k _{v 1} and k _{v 1} P, and then broadcasts k _{v 1} P to other members. When another member (v ₂) receives the key, then multiplies it with its private key, denoted as k _{v 2} k _{v 1} P. To avoid a broadcast storm, v ₁ as the most front of members in the road broadcasts first, and other members delay a little time to broadcast. Eventually, each member performs the same product, K _{v 1} K _{v 2}...K _vy P.

• 3. Each member filters out its private key from the product, and unicasts the extracted result to R _x , for example, v ₁ sends the K _{v 2}...K _vy P to R _x . Members can unicast confidentially the result to R _x , using the public key, GK _set P.

• 4. R _x receives a product from one member, and then generates a response by multiplying with the key, GK _set in the storage. For example, R _x constructs the product, GK _set K _{v 2}, ..., K _vy P, for v ₁, then unicasts it to v ₁. Consequently, R _x and {v _y } share a group key, denoted as vgk _x (=G{K}_{\mathsf{\text{set}}}{\prod }_{i=1}^x{K}_{i}P), in the localized group.

• 5. This step is optional. {R _x } can determine whether to share the VGK to the {v _i} in the localized groups. R _x sends confidentially the VGK to its members by encrypting with the vgk _x .

The vehicles will share a VGK, if completing all steps of the five phases. Each of the vehicles shares securely data with the others, when the data are encrypted by the VGK. If the last step of the fifth phase is excluded, head avatars will have the extra encryption/decryption overheads. The secure group communication without the last step from v_i to the others is detailed as follows:

v _i → R _i :

Stream#(v₁, Multimedia, Tstamp), MAC(Stream#, vgk _i ), or

E(Stream#(v₁, Multimedia, Tstamp), vgk _i ), MAC(E(...), vgk _i )

R _i → {R _j |j ∈ 1-n, j! = i}:

Stream#, MAC(Stream#, VGK), or E(Stream#, VGK), MAC(E(...), VGK)

R _j → {v _j }:

Stream#, MAC(Stream#, vgk _j ), or E(Stream#, vgk _j ), MAC(E(...), vgk _j ), where each vehicle in {v _j } is moving within the transmission range of R _j .

5. Security and delay analyses

Attackers could generate incorrect propagation of information based on fake traffic events to influence traffic conditions, even paralyze the vehicle network. In addition, group communication including sensitive data in the private group will provoke adversary's interest. This section analyzes the security issues for the delay propagation and group communication.

5.1. Security of the propagation of traffic-related information

A Warn# message with the signature and warrant/certificate of a vehicle source can achieve the identity and data authentication, after verifying using the public key. Each of the vehicles in the propagation procedure can trust the sensitive data of the two preceding senders as their GPS positions and speeds, after verifying successfully their signatures.

In the only V2V mode, attackers without the valid key pair issued by the trusted third party cannot create or forward an incorrect warning message. A compromised vehicle could go through a wrong warning propagation and try to modify a warning propagation. If a compromised vehicle fixed in a location creates a wrong propagation to attack the network, it is most probably without success. The detection range of event-based sensors is smaller than the transmission range of 802.11p in vehicles, and therefore the neighboring vehicles can easily find no event happening in its neighborhood. Already compromised vehicle does not modify easily the propagation, since the propagation is signed by its two preceding senders and the vehicle source is found in the propagation path. The compromised vehicle could conspire with them to fabricate an incorrect warning; however, the adversaries could be found with a high probability by their valid neighbor vehicles.

As the network supports the V2I mode, the trusted RSUs service as guards may accuse a compromised vehicle that creates or forwards incorrect Warn# message. If the number of accusations against a suspected vehicle achieves a threshold, the certificate of the vehicle will be expired and added in the certificate revocation list (CRL) by the trusted party. If a trusted vehicle accuses a suspect vehicle, the accusation will be verified by a number of its neighboring RSUs. If the accusation is correct, then the RSUs will report the result to the trusted third party through its management servers.

A replay attack could be generated, while the two neighboring vehicles in a propagation path collude to propagate repetitively a warning message. The vehicle receiving the replay message can check whether the warning is expired or not according to the timestamp given by the vehicle source. Three timestamps are attached in a Warn# message: one is attached by the source, and the others are attached by collusive vehicles. The difference in time between the two previous timestamps of the Warn# is represented as the actual elapsed time of the event happening. The vehicle can determine whether the event happening is expired or not, when each event type has a stable reparation period announced by the government responsible for the traffic event. Consequently, the propagation of a traffic-related message reaches the security degrees consisting of source non-repudiation, data integrity, the prevention of replication attacks, and delay effect.

5.2. Propagation delay

We illustrate two cases for the propagation delay scheme using the architecture presented in Figure 2. The IEEE 802.11p operates under 5.9 GHz and supports speed up to 190 km/h with a normal transmission range of 300 m. The vehicles move on the highway (HH) and rural roads (RR), individually corresponding to two examples. Table 2 shows the delay time of propagations for the examples. Suppose that R_T is 300 m in Equation (1), the other values of v _{i +1} , v _{i +2}, and v _{i +3} are given in the table. The GPS _i , GPS _{i +1}, GPS _{i +2}, and GPS _{i +2} are set to (24.164477, 120.670084), (24.164492, 120.671157), (24.164676, 120.671841), and (24.164935, 120.672254).

Table 2 Illustration of the delay propagation with v_i, v_i+1, v_i+2, and v_i+3 in Figure 2

The derived unit of GPS is latitude and longitude, (x, y), and the derived unit of Speed (Sp) is Kilometer per hour (Km/h), same as that of v limit. To calculate the projection distance, v _{i +2} and v _{i +3} first gain their projection positions over the vector from v _i to v _{i +1} . Second, each of them calculates the straight distance from Sp _{i +1} to itself. For example, v _{i +2} calculates the distance using Equation (3) as follows:

\text{Δ}dpj\mathsf{\text{ = 2}}\times arcsin\left(\sqrt{{sin}^2\left(a^{\prime }\right)+cos\left(x_{i+1}\right)\times cos\left(x_{i+2}\right)\times {sin}^2\left(\mathsf{\text{b’}}\right)}\right)\times \mathsf{\text{EarthRadius,}}

(3)

where a' is set to (x _{i +1} - x _{i +2})/2, b' is set to (y _{i +1} - y _{i +2})/2, and EarthRadius is set to 63, 78, 137 m.

Vehicle v _{i +2} and v _{i +3} moving within the transmission range of v _{i +1} have the projection distance, 64.15 (m) and 103.03 (m) over the vector from v _i to v _{i +1} . In the HH, v _{i +2} moves more faster than v _{i +1} , and v _{i +3} moves slower than v _{i +1} . Vehicle v _{i +3} must propagate the traffic-related information faster than the propagation of v _{i +2} . Basically, v _{i +2} will listen and gain the propagation from v _{i +3} , then be able to stop its propagation to avoid broadcast storms. In the RR, v _{i +2} moves slowly and v _{i +3} moves fast toward v _{i +1} . Vehicle v _{i +2} must propagate the traffic-related information faster than the propagation of v _{i +3} . The vehicle v _{i +3} will decide not to propagate for collision avoidance, after waiting a period as the delay time of v _{i +2}.

5.3. Security of V2I group communication

Vehicles and RSU can authenticate each other through the asymmetric cryptography. RSUs are maintained by the servers on the Internet, and the servers are supported with the trusted third party. If an invalid RSU was recorded in the CRL, then servers will eliminate it from the establishment procedure of virtual groups. An attacker without the servers' support masquerades difficultly itself as a valid RSU to attend the head avatars of any virtual group.

Group communication is designed for the groups of friends driving vehicles to travel together; hence, any of vehicles always holds their total identities. It is impossible that an outside attacker joins easily and successfully their trip in the V2I mode. During the period of applying for a new virtual group, to deliver the Req# from a vehicle to the Root through a RSU can achieve data integrity, source authentication, and non-repudiation of transmission. If the RSU uses a secret key shared with the Root to encrypt their operations with a MAC code, then delivering Req# or Resp# between them will achieve data confidentiality and integrity. In addition, any two BSUs communicate securely each other using a secret key or their public keys. In this case, the communication achieves data confidentiality and integrity.

A compromised vehicle cannot apply for the same virtual group by sending the same set of the vehicles' identities and the travel path to a valid RSU, unless it belongs to one of them. In other words, any two sets of the VGK and the key materials (GK_set, GK_setP) determined by the Root (i.e., a server with the trusted third party) cannot be same, only if the values of the parameters, tp, ΔT, {R _j }, {v _i }, and Tstamp are the same in two different applications.

To perform the key agreement protocol for a localized group, the members exchange their ECDH-based public keys and send particular products to the BSU, individually. The delivery of the products is secure using the GK_setP to prevent the middle attack. Group communication in a localized group can achieve data confidentiality and integrity, when the members adopt the localized group key to encrypt their communication.

5.4. Security of V2V group communication

The V2V group communication can be implemented, following the conditions: no connection gap among the traveling vehicles, and enough THs moving at steady speeds. The vehicles are divided into different one-hop physical groups. The delivery of a Req@ from one TH to its neighboring members achieves data integrity, source authentication, and non-repudiation, since the TH's signature was appended to the request. Each TH cooperates with its one-hop members in key agreement to gain a common key gk _x . Since THs move on the roadway in an order, they can cooperate to get a common key, GGK, after an exchange of ECDH products to make a round trip from the head TH to the tail TH and back again. Both of the key agreements are safe unless attackers solve the elliptic curve discrete logarithm problem. The confidentiality and integrity of data sharing among the vehicle in a physical or global group can be reached.

An attacker without a valid certificate cannot become a TH. Any compromised vehicle with a valid certificate cannot easily join a traveling group, since the vehicles know each other. A compromised vehicle could disguise itself as one of the vehicles by broadcasting a beacon with the compromised identity, and therefore, the two vehicles with the same identity move together at the beginning. The adversary can successfully perform the key agreement in its physical group, before the key agreement process of GGK. To avoid the expansion of damage into other physical groups, THs must append their identities to the products during the agreement period of GGK, as detailed in Section 4.2. For example, TH _k forwards its product to the next TH, and the product is defined as follows:

The compromised vehicle can easily be detected, while each TH knows which vehicles are moving within which of physical groups.

6. Performance evaluation

In this study, each vehicle conserves a key pair to encryption/decrypt data at the VANET initialization. In addition, various public key cryptographies were applied to the initialization process. Some participants establish a session key using their public key cryptography, and therefore hash and session key operations are adopted to consume few overheads and to improve the encryption/decryption performance. Vehicle exploits a hash function such as HMAC-160 or RIPEMD-160 to verify the integrity of data communication in our evaluation. Each vehicular computer in our experimental environment is implemented using a Linux platform PC with a 2.4 GHz CPU, 1 GB of memory as hardware and supporting the GNU C/C++ library, which will have enough capability to implement Elliptic Curve and RSA cryptographies. This study evaluated the eclipsed time of propagating traffic-related packets, the key synchronization time in the global and virtual groups, and the delay results of comparing our schemes with GDH [5], and GSIS [16].

The delay propagation scheme, denoted as DelayProp, compared with a natural propagation, denoted as NatureProp. Vehicles always flood immediately while receiving a propagation message in the NatureProp. Figure 5 shows the propagation with a message loss ratio in the DelayProp smaller than that in the NatureProp. We also compared the experimental results, while DeplayProp is designed with various average numbers of neighboring nodes of each vehicle. All DelayProps with Equation (1) reached a small ratio in the packet loss estimation, even if the network size was increasing, such a ratio of approximately 1%. The value of α as the number of neighbors of a vehicle increases, the delay time increases. Since the width of a road is limited with few lanes, the average number of neighboring vehicles was set to 6, 12, 18, or 24 in the evaluation. Consequently, the network size had a little impact for the proposed scheme. The "DelayProp with 18" and "DelayProp with 24" have a high value of neighbor-based vehicle density, and therefore only few vehicles participate the propagation process, and most of them always listen the propagation from its rear neighboring nodes after waiting an individual time. Figure 6 depicts the propagation delay time of the four DelayProp with various numbers of neighboring nodes. The environment area of the VANET in "DelayProp with 6" is max in the four propagations; hence, it has more delay than the others. The percentage of the area, that any of the four propagations are covered with, is always larger than 93%.

Figure 5

Impact of traffic load on message loss ratio for the propagation of traffic-related information.

Figure 6

Comparison of the propagation delay of DelayProp with various the average number of neighboring nodes.

The proposed key agreement scheme is compared with the group-based GDH and GSIS schemes. The GDH and GSIS established a group-based secret key and a group-based public key individually. Both of them adopted DH with exponential operations. We evaluated the proposed scheme with a 160-bit group key for gk, vgk, GGK, and VGK, and the others were implemented with a 1024-bit key. The group communication adopted the seven or eight members in each physical or localized group, and the total number of vehicles in a VANET is 65 nodes. Figure 7 depicts the comparison of the average delay time of the three key agreement schemes without GSIS, since the procedure of its group-based signature was initialized in the offline phase. The key agreement in a virtual group obtained the aid of the valid RSUs, thus the delay time was very low. A global group without RSUs in VANETs had a large delay, when the traffic load was increasing. The global group had a small delay before the traffic load was 65, while vehicle heads always helped exchanging ECDH-based products.

Figure 7

Comparison of the average delay of three key agreement schemes.

Figure 8 depicts the comparison among four schemes for secure group communication. After finishing the key agreement protocols, members in a group shared a secret key. The network using GSIS to data transmission performed the verification of the group-based signature replacing the encryption and decryption operations. The communication architectures of Virtual Group-160 and GSIS supported the aid of fixed RSUs. For this reason, their average delay was inclining to a stable status. However, the consumption overhead of verifying a signature was larger than encryption or decryption operations. The average transmission delays of GSIS and Virtual Group-160 were tending to 60 and 25 ms, individually. The others built secure communication in the only V2V mode, so that the delays of data transmission were serious, as the traffic load increases.

Figure 8

Comparison of the average delay of the four schemes for secure transmission from one source to all members in a group.

7. Conclusions

This research paper discusses the security issues for two communication scenarios in vehicle network, the propagation of traffic-related messages, and the group-based communication scenarios. The security issues of the delay propagation achieved authentication and non-replication. The propagation delay mechanism avoids problems of communication collision and broadcast storms, but increases the propagation delay. Our simulation results indicated that the scheme improved the performance of the data flooding. The delay time (seconds) is acceptable, since to deal with traffic-related events such as a car accident needs a lot of time (minutes or hours).

Secure group communication scenarios can be implemented in the V2I and V2V modes. In the V2I mode, BSUs strengthen the security of group communication. The key agreement process in a localized group is easily accomplished with the head avatars in the virtual group. In addition, the vehicles distributed in different localized groups can perform secure group communication by the aid of their localized group keys and a VGK, issued by the third party. The establishment of group key for secure V2V group communication can easily be accomplished because of the security features of the ECDH-based key agreement protocol. The elliptic curve group key with a small size still has the same security strength with RSA and DH. The V2V group communication with the aid of the position-based routing consumes less time in the establishment of a secret key among THs in a global group.

In general, key management for secure group communication is a challenge in ad hoc networks. The group key management in the proposed schemes is easily to be solved. According to the scenario of group communication, groups of friends traveling together can easily gain identities of all vehicles. For this reason, it is impossible that a new vehicle can join to the group during the period of traveling. However, a member could leave the traveling group in the real world. In order to reduce the complexity of rebuilding group keys, heads in the V2I or V2V group cannot distribute the virtual or global group key (VGK or GGK) to their members. If one member leaves from a physical or localized group, then the head should re-build the gk or vgk key. In case that one of head avatars was not available, then the vehicles will need to re-apply for a virtual group to avoid attacks. Alternatively, if one of THs leaves, then the members belonging to the TH must re-organized physical groups, and the GGK will be re-builded. The vehicles in the other physical groups not belonging to the TH still keep the original status.