4.3. Detection Scheme
Messages transmitted in VANETs are described in
Table 1 and fall into three categories: beacon messages, alert messages, and entertainment messages. Alert messages are broadcast in an emergency and are critical to safe driving. Therefore, in this paper, we focus on how to detect forged alert messages based on the blockchain technology in VANETs. Alert messages normally report emergency situations described in
Table 2, where
and
denote life cycle and the longest transmission range of the event reported in an alert message, respectively. As shown in
Table 2, alert messages are divided into four categories and have different life cycles.
As illustrated in
Figure 4, the security scheme is comprised of four components: identification of the legitimacy of a vehicle; an incentive consensus mechanism; identification of forged messages and malicious vehicle nodes; and the public–private key mechanism and RSA encryption algorithm are adopted in the scheme to protect the security and privacy of vehicles. The ledgers of BCIR and BCCA in this scheme are illustrated in
Figure 5.
- (1)
Verify a vehicle’s legal identification
When receives an alert message from , it sends the received message to a nearby RSU and requests it to identify the legitimacy of the message. The RSU checks if has a legal identification before evaluating the trustworthiness of the message. Algorithm 1 illustrates the steps to verify the identification of . For secure communication, the RSA method is adopted in Algorithm 1.
Step 1: Vehicle sends a request to a RSU within its communication range to verify the message received from vehicle . The request includes the received message, the pseudo-ID , and , which is the public key of .
Step 2: After receiving the request, the RSU sends a message, which includes
and a random value
L to the closest CA. Note that
L is produced by the method of linear congruence generator (LCG), calculated as:
where
d is a seed value, and its initial value is set to be the current system time;
A is a multiplier;
Z is an increment value; and
M is a modulus. Note that
M and
Z are prime numbers to each other.
Step 3: When the CA receives the message from the RSU, it checks the ledger of BCCA. If
is stored in the ledger, then
is a legitimate vehicle; otherwise, it is an illegitimate one. Then, a session key
is created by the random value
L encrypted with the private key of the CA.
is created by encrypting
with the public key of the RSU
and
is created by encrypting the checking report with
. Finally,
and
are encrypted with
and sent to the RSU. The encryption is performed as
where
E is a function of encryption and
C represents the plaintext.
Step 4: When the RSU receives the encrypted result from the CA, it decrypts the result with its own
to obtain
and
. Then, the RSU decrypts
with its
to obtain
. Finally, the report is created by decrypting
with
. This decryption process is described as
where
D is a function of decryption.
Algorithm 1 Verify a vehicle’s legal identification |
- Input:
, , and ; - Output
verification result; - 1:
sends a request to BCIR; - 2:
LCG is used to produce L; - 3:
L and are sent to BCCA; - 4:
CA checks the ledger on BCCA; - 5:
if is stored in the ledger then - 6:
is a legal vehicle; - 7:
else - 8:
is an illegal vehicle; - 9:
end if - 10:
Encrypt L with as ; - 11:
Encrypt the verification result with as ; - 12:
Encrypt and with ; - 13:
Send to the RSU; - 14:
The RSU decrypts ; - 15:
Output the verification result.
|
- (2)
POS consensus with an incentive mechanism
If is verified as a legitimate vehicle by the BCCA blockchain, the BCIR blockchain then identifies whether or not the message sent by was forged.
To stimulate the RSUs to take active behaviors, a consensus appropriate for VANETs should be constructed. Consensus in a blockchain is a process where all peers of the network reach a common agreement on the present state of the distributed ledger. At present, the most common consensus algorithms include POW, POS, and PBFT. From the advent of Bitcoin to today, there over 30 consensus algorithms have emerged [
37], most of which are based on the above three consensus algorithms.
Unlike other traditional consensus, nodes in BCIR are designed to utilize computing power for forged message validation rather than merely solving the difficult hash problem. Therefore, we designed a novel consensus POS based on an incentive mechanism (POS-I) for BCIR in VANETs. According to the POS consensus with an incentive mechanism, when an RSU enacts active behavior, it receives energy benefit. POS-I is described in Algorithm 2.
Algorithm 2 Consensus mechanism POS-I |
- Input:
, k, , , a, J, ; - Output
committer peer; - 1:
RSU sends a request to CA; - 2:
BCCA initializes an election for selecting committer peer; - 3:
for all RSU participating in the election do - 4:
submits as deposit; - 5:
Calculate ; - 6:
if then - 7:
cannot participate in the election; - 8:
else - 9:
is regarded as a candidate; - 10:
end if - 11:
Calculate ; - 12:
end for - 13:
Selecting the node whose has as the committer peer ; - 14:
Calculate ; - 15:
Calculate ; - 16:
Output committer peer.
|
Step 1: BCCA initializes an election to select a committer peer. The RSUs, which would like to participate in the election, submit deposits in order to become candidates. The energy value of every candidate
is reduced as a deposit. The process of calculating deposit is described as:
where
denotes the submitted deposit,
denotes the current energy value of
,
k denotes the total number of participation elections of
, and the initial value
k is set to zero.
RSUs have various types of behaviors in VANETs, such as broadcasting messages, participating election of selecting a committer peer, and identifying the trustworthiness of a message. Normally, the energy of a RSU changes with different behaviors. For example, when it broadcasts messages in VNAETs, its energy is consumed. Meanwhile, in order to encourage its active behaviors, it is also rewarded a certain energy. The reward is larger than the consumed energy.
After submitting the deposit, the energy of
is updated as:
Step 2: If the energy of is lower than , which is a threshold, is deleted from the candidate group; otherwise, it remains in the candidates group.
Step 3: The total number of elections initialized by BCCA is counted as
J. After every election for a committer, the energy of every RSU on BCIR is updated. Stakes refer to the assets (or energy) owned by a node. The idea is that the more active behaviors an RSU has, the more stakes it owns. The stake of each RSU candidate is calculated as
where
denotes the stake of
, and
denotes the energy value of
after the
x-th election. The RSU, which has the highest stake value among the candidate group, is selected as the committer peer.
Step 4: When the committer peer is selected according to the above process, BCCA refunds a certain percent of deposit to each candidate RSU. Now, BCCA updates all RSUs. The updating process is described as
where
denotes the energy of a RSU after the
election initialized by BCCA,
denotes the energy of a RSU after the
election, and
denotes a certain percent of deposit refunded. Especially, we set
to be an attenuation coefficient. Meanwhile, BCCA offers a reward
to the committer peer, calculated as
As mentioned above, if is selected as a committer peer on BCIR, it gains the reward energy and be refunded at a certain percentage.
- (3)
Verify the integrity of messages
The RSU, which is elected as a committer peer, verifies the message integrity sent from
. Algorithm 3 describes the verification process for message integrity.
Algorithm 3 Verify message integrity |
- Input:
, , , ; - Output
Message integrity result; - 1:
Calculate the hash code of m; - 2:
Encrypt with the as the committer digital signature; - 3:
Add the digital signature in the message m to get ; - 4:
Use LCG to get a random number G; - 5:
Encrypt G with the as ; - 6:
Encrypt with as ; - 7:
Encrypt with as ; - 8:
Send and to BCCA; - 9:
CA decrypts with to get ; - 10:
Decrypt with to get digital signature; - 11:
Decrypt digital signature with to get ; - 12:
CA on the message m hashes to get ; - 13:
ifthen - 14:
the m is verified as integrity; - 15:
else - 16:
the m is tampered; - 17:
end if - 18:
Output the message integrity result.
|
Step 1: The committer RSU on a message m hashes to get the synopsis of m, which is denoted as . Then, is encrypted with the committer RSU’s private key . The result of encryption is considered as the committer RSU’s digital signature and is added in the message m to get .
Step 2: The committer RSU employs the LCG method to obtain a random number G, and a session key is created by encrypting G with the committer RSU’s public key .
Step 3: , which is created by encrypting with , and are sent to the CA, which is the closest to the RSU.
Step 4: The CA decrypts with its private key to get , and is decrypted with to get m and the committer RSU’s digital signature.
Step 5: The committer RSU’s digital signature is decrypted with to get . The CA that is the closest to the RSU on the message m hashes to get . If is equal to , m is verified as integrity.
- (4)
Verify the legitimacy of messages.
In our scheme, BCIR acts as a distributed public ledger, which stores the reputation values of every vehicle in the blockchain. BCIR first checks the sender vehicle ’s reputation and then verifies the trustworthiness of the message. If the reputation of is smaller than the reputation threshold , the message from this node is labeled as forged information. Otherwise, BCIR checks the message based on the evidence with respect to , , , time effectiveness, and distance effectiveness.
As mentioned above, the committer RSU follows the message verification policies to determine the message’s trustworthiness as follows:
Check the sender’s reputation from the vehicle reputation table on BCIR.
Check , , and .
Check time effectiveness and distance effectiveness.
If the sender’s reputation is larger than , , , and of the received message are checked in the historical event table on BCIR in order to evaluate if an event reported in the message has been stored in the historical event table.
If
of a message in the historical event table is the same as
, the message is placed in
, defined as
, where
z denotes the total number of messages in
. For
, the distance between
and
m is calculated as:
where
, where
and
denote the longitude and latitude of
m, respectively; and
is defined as
, which denote the longitude and latitude of
, respectively. The similarity of
and
m is calculated as
If is larger than , m is considered to be the same as , and it checks time effectiveness and distance effectiveness. Otherwise, m is treated as a new one.
If
is over
, the distance effectiveness is checked; otherwise, it is dropped because it expires:
If
is over
, the message is dropped; otherwise, it is considered to be a reliable message:
The process for identifying the trustworthiness of a message is illustrated in Algorithm 4.
Algorithm 4 Verify the legitimacy of messages |
- Input:
, , , ; - Output
the legitimacy of messages; - 1:
For a message m; - 2:
ifthen - 3:
m is verified as a forged message; - 4:
end if - 5:
for all events recorded in historical event table on BCIR do - 6:
Compare of the event with ; - 7:
if of the event is the same as then - 8:
Place the event in ; - 9:
for all events in do - 10:
Calculate , ; - 11:
if then - 12:
The event in m is the same as ; - 13:
end if - 14:
end for - 15:
else - 16:
Calculate ; - 17:
if then - 18:
m is outdated and discarded; - 19:
else - 20:
Calculate ; - 21:
if then - 22:
m is a legitimate message; - 23:
end if - 24:
end if - 25:
end if - 26:
end for
|
If the received message is valid and trustworthy based on the aforementioned policy, it is stored in the historical event table on BCIR and the sender vehicle’s reputation is increased. Otherwise, the sender vehicle’s reputation is decreased. When a vehicle’s reputation value is below the threshold
, it is considered to be a malicious node. The reputation of
is calculated as
where
represents the reputation value of
in the time period
T,
denotes
’s reputation in the time period
, and
and
represent the total numbers of messages and forged messages sent from
in the time period
T, respectively.