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 v0 → v1 →⋯→ v
i
→ v
i
+1 → v
i
+2 , and v0 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 v0, an event type (Event
k
), and the timestamp. Vehicle v0 has to sign the Warn#0, so that other vehicles can verify the message in the future. Vehicle v1 modifies the Warn#0 by adding its sensitive data and timestamp, once received and verified it. Vehicle v2 performs same tasks as Vehicle v1, after receiving the Warn#1 from v1. 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 0 detects a traffic event, and propagates immediately a warning message:
-
Warn#0(v0, GPS
v
0, Speed
v
0, Event
k
, Tstamp#0), Sign(Warn#0, SK
v
0), Cert
v
0.
-
2.
v 1 verifies the source, and calculates the delay time. The direct distance from v 0 to v 1 replaces the projection distance of the delay time, since v 1 has the preceding sender of v 0. After waiting the delay time, v 1 propagates the modified warning message:
-
Warn#1(v0, v1, 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 2 verifies the source, and calculates the delay time, the two preceding senders, v 0 and v 1. After waiting the delay time, v 2 propagates the Warn#2 as follows:
-
Warn#2(v0, v1, v2, 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 3 performs the same tasks as v 3, but removes the data of v 1 in the modified warning message, since the data are useless to v 4, in calculating the delay time. After waiting the delay time, v 3 propagates the Warn#3 as follows:
-
Warn#3(v0, v2, v3, 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 3 → v 4 ⋯ → v
i
-1 → v
i
→ v
i
+1 . The warning format of v
i
+1 's propagation is denoted as:
-
Warn#i(v0, 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):
(2)
where the NumberOfTHs is the predictive number of THs, larger than or equal to the number of the practical THs (n), is the approximate distance between the locations of TH
j
and the traveling destination, Dest on the route of the digital map, the as a function will return the maximum value of the set, , 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@, SKTHx), Cert
x
.
Suppose that the vehicles {M1, M2, ..., 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, K1 and K1P, 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, M1 as the first vehicle broadcasts its neighborhood immediately. M2 cannot broadcast its K2P until it receives the K1P from M1. Just like M2, 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 (K1K2...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 (K1K2...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, . 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 (TH1, TH2, ..., TH
n
-1, TH
n
), and TH
j
always moves behind TH
j
-1. The procedure started by TH1 using the on-demand routing in the V2V mode for establishing a global group key is detailed as follows:
-
1.
TH1 forwards its < gk
1
'P > to its neighboring TH2 using one of ad hoc routing schemes such as the position routing [10]. Once the data is stored, TH2 generates and sends a product < gk 2'gk 1'P > to TH3. Just like the previous TH, TH3 generates and sends a product < gk 3'gk 2'gk 1'P > to TH4.
-
2.
The process of forwarding the product continues by following the remainder path: TH4 → TH5 → ⋯ → TH
n
-1. TH
n
-1 delivers the to TH
n
, after storing the product from TH
n
-2 .
-
3.
TH
n
generates the global group key, , 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 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
⋯ → TH1. TH
j
returns the product to its previous TH
j
-1, after generating the group key.
-
7.
TH1 receives the product, from TH2. The key agreement process is done, and the group key, 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#(v1, 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 {Mj} 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 v1 asks for a virtual group to establish group communication, while the vehicles (v1-v
n
) travel on the route toward the common destination. The others (v2-v
n
) could also apply for the group through their neighboring RSUs during traveling. Suppose that the v1 sends a request with the travel-related information to a valid RSU, RSU
i
. The RSU
i
checks whether v1 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 v1, 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 v1 applies for a set of the RSUs using the information of a travel route which is detailed as follows:
Phase 1. Vehicle v1 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 (TPmap). The request is signed with its private key.
v1 → RSU
i
: Req# (v1, ΔT, Tstamp, TPmap, {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# (v1, ΔT, Tstamp, TPmap, {v
i
}), Sign(Req#, SKv1), Cert
v
1, MAC(Req#||Sign, KRoot, RSUi), or
Req# (v1, ΔT, Tstamp, TPmap, {v
i
}), Sign(Req#, SKv1), Sign(Req#, SKRSUi), Cert
v
1, CertRSUi
Phase 3. Root authenticates the Req# using the v1's PKv1, 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, TPmap, and sends an encrypted Resp# back to RSU
i
. The Resp# is attached with the identities of the selected RSU
j
, the TPmap, and an expiration time (ETime), a VGK, and a key pair for {R
j
}, (GKset, GKsetP) (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), KRoot, RSUi), MAC(E#, KRoot, RSUi), or
E#(Resp#'tp, Sign#'Root, E(Resp#tp, Sign#Root, PK
v
1), PKRSUi), where Resp#tp is generated for the vehicles (i.e., Resp#tp = Resp#({R
j
}, TPmap, ETime)), Resp#'tp is generated for the chosen RSUs (i.e., Resp#'tp = Resp#(VGK, GKset, GKsetP, {R
j
}, {v
i
}, TPmap, ETime, ΔT)), and Sign#Root (or Sign'#Root) represents that the Resp#tp (or Resp#'tp) is signed by SKRoot.
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, KRSUi, 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, KRSUi, RSUj), MAC(E(...), KRSUi, RSUj)
RSU
i
→ v1: E(Resp#tp, Sign#Root, PK
v
1)
Phase 5. Each of {RSU
j
} stores the tuple, (GKset, GKsetP, {R
j
}, {v
i
}, TPmap, 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#, SKRSUi), CertRSUi
{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:
-
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, GKsetP), Sign(Resp&, SK
Rx
), Cert
x
.
-
2.
One member (v 1) 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 2) 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 1 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 1 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 1, then unicasts it to v 1. Consequently, R
x
and {v
y
} share a group key, denoted as vgk
x
(), 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 vi to the others is detailed as follows:
v
i
→ R
i
:
Stream#(v1, Multimedia, Tstamp), MAC(Stream#, vgk
i
), or
E(Stream#(v1, 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
.