A dynamic key management and secure data transfer based on m-tree structure with multi-level security framework for Internet of vehicles

Abstract

Nowadays, broadband wireless networks and 5G have improvements in the quality and dependability of network services for high-speed mobile vehicles. Within an open communication environment on the Internet of vehicles named IoV, personal details will be revealed on the Wi-Fi network. Considering information security and privacy, this research concentrates on how to protect secure information transmission in real time through IoV, and also wants to avoid illegal vehicles, passers-by or drivers from joining connection and planting or altering significant data. This research provides a multilevel security infrastructure with M-tree based elliptic curve digital signature algorithm (ECDSA) for securing data transmission in both IoV and cloud environments. While transmitting, this study provides several flexible and scalable schemes to manage security issues, which dynamically adjust the framework depending on the rapidly changing IoV topology and speed up the time to synchronise the reconstruction of the system key, and decrease the quantity of phases to resynchronise the system key. Moreover, most research of key management without secure data transmission, we integrate the M-tree key management with secure data transmission to achieve the secure IoV. Simultaneously, the provided key management for the multi-level security is quite appropriate to adaptable and expandable IoV.

KEYWORDS:

• 5G
• Internet of vehicle
• IoV
• M-tree
• ECDSA

1. Introduction

As the Internet of vehicles becomes popular and intelligent, vehicles can establish a connection with more open devices, and thereby the security issues are created. Nowadays, IoV attracts great attention to researchers. Because the IoV may communicate with vehicles, roadside equipment and even cloud services mutually. For the foreseeable future, IoV is going to carry out a big data application and analysis on cloud computing. Simultaneously, the V2X technologies will be employed to strengthen driving safety. Those are vehicles to infrastructure named V2I, vehicles to roadside equipment named V2R, vehicles to vehicles named V2V, vehicles to pedestrians named V2P, vehicles to transportation named V2T, and vehicles to groups named V2G and vehicles to networks named V2N. In particular, V2V is gradually becoming more and more popular. Currently, IEEE would like to propose the security and communication framework named IEEE1609/802.11P.

Nowadays, many countries are continually investing in autopilot and driverless vehicle research. The 5G is going to encourage us to evolve into the leading driving technology for autopilot and driverless vehicles. IoV is a mass-connected network, which integrates the necessary information like vehicle speed, route and location. The vehicle can supplement the collection of its own information about the status and environmental information through sensors, GPS, radars, cameras and image processing devices. Thanks to cloud computing technology, diverse IoV information transmissions are combined with each computer in a vehicle to measure, analyze and process a vast quantity of data. Afterwards, the vehicles find the best path or the possible path, and report the status of the road condition to the control centre immediately. The monitoring system may programme the traffic signal cycle, depending on the real-time traffic conditions to reduce the traffic bottleneck.

The premature phase of vehicle to everything (V2X) counts on typical wireless transmission and adopts a similar technique with Wi-Fi networks, yet its dependability is weak and undefended to intrusion and interference offences. So far, with the progressive popularity of 5G being developed, lots of countries are working towards the development of 5G technology. Thus, the original IoV concept is gradually being changed to the IoV application. In the foreseeable future, 5G is going to definitely offer reliable and efficient V2X services. Meanwhile, except for communicating with one another, the vehicle may also deliver messages via roadside devices and adopt IoV to identify unusual car accidents. In the event of an accident, short-range communication may be initiated. It stores information about accidents or scene information and delivers the videos or accident details to the platform of cloud services. Afterwards, V2X may assist in the completion of accident summary for the vehicle and in restoring the location of the traffic accident at which the accident occurred, such as the precise GPS particulars of the vehicle, the position of the roadside devices, and travel routes and journey information of the vehicle with pictures to examine the behaviour of drivers before car accidents.

Nevertheless, since the IoV open communication surroundings, within an open Internet of vehicle communication environment, personal details are going to be revealed on the Wi-Fi network. Taking into account information security, privacy, the security of information as well as the protection of personal data, the purpose of this study is to safeguard transmitted information in real time and to avoid unauthorised vehicles, drivers or passers-by from being involved in the communication and implementation or modification of critical transmitted information. This study develops a virtual machine on the cloud service platform that comprises services such as key management, identity verification, security certification, the public key infrastructure PKI and the certification authority (CA) server. At the border entrance, the cloud service category manager (CSCM) takes charge of transmitting the type of service required from the vehicles to the end of the cloud service platform, and thoroughly analyzing and dealing with a variety of messages coming from vehicles and RSU.

Moreover, this research must examine how to guarantee security between the vehicle with vehicle (V2V), the vehicle with roadside equipment (V2R), the vehicle with group (V2G) and the vehicle messages with the cloud service platform, as the vehicle moves and communicates with the RSU using the sensor of the onboard OBU. In short, IoV requires a secure data communication framework to guarantee the information security delivered among OBU, RSU and the cloud service platform. This research also takes into consideration that the IoV infrastructure and topology are changing so rapidly, when the vehicle is involved or deviating from the secure transmission of the IoV. Besides, the connected route can change, and vehicles can be connected to various base stations. As a result, this study needs to offer a secure key management mechanism that can address dynamic change in topology. Moreover, the proposed scheme involves multiple paths and can be made quickly and effectively to process the secure transmission of data in IoV, when there is a proactive change in the IoV topology. As a result, based on dynamic M-tree structures, this research provides a multi-level security key management protocol for IoV with secure data transmission to address IoV weaknesses in key management and security problems. This will improve the information security of IoV.

The rest of this paper is structured as follows. Section 2 introduces the related work. Section 3 presents the process of ECDSA digital signature of IoV. Section 4 introduces the framework of multi-level security. Section 5 describes the security key management agreement based on M-tree and secure data transmission modes. Section 6 is the analysis of security and performance. Eventually, conclusions and further work are derived from Section 7.

2. Related work

Over the past few years, lightweight security mechanisms, including PUF-based authentication (Zhang et al., 2021) and elliptic curve Diffie–Hellman protocol, have been adopted to various application domains, such as medical information systems (Xiao et al., 2021), wireless sensor networks (Hua, 2021; Lin et al., 2016) and smart environments (Xia et al., 2021).

Due to the unique characteristics of vehicular networks, restricted computing resources and unstable communication, security issues in IoV applications tend to be performed by lightweight cryptographic schemes. Not only authentication, but also key operations possibly related to key agreement (Xu et al., 2021), key management (Hua et al., 2021; Zhang et al., 2021) and key distribution (Vijayakumar et al., 2017) protocols are concerned in these issues. Further, wireless high-frequency transmission by 5G (Hu et al., 2021) or 6G technology (Pandi et al., 2022) will support higher capacity and much lower latency for data transmission of IoV and VoX applications.

IoV is considered a mission-critical infrastructure. Vehicles aggregate real-time data with other vehicles, RSU and cloud servers, and transmit aggregated data to OBU. IoV data can be analyzed either locally or on a cloud server, and actions are taken depending on the request type. Because IoV has wide-scale interconnecting networks with a large number of vehicles. Obviously, there exists a great risk of privacy and security issues. Through the encryption mechanism and digital signature cryptographic protocols can address those concerns. Additionally, the simultaneous need for the encryption mechanism and the digital signature, these mechanisms are amalgamated named signcryption. In order to eliminate the issue of key escrow related to the signcryption, a certificateless approach is generally considered.

In 2007, Xiaodong et al. exploited a group signature to inspect multiple signatures (Xiaodong et al., 2007; Yong et al., 2013), and thus improved the efficiency of authentication. The proposed scheme is based on bilinear paring. However, this mechanism exists a serious defect that the paring operations at least need two members to complete and cannot be extended, and therefore this proposed mechanism is not scalable for IoV. Additionally, this mechanism exploits lots of exponential operations that consume computing power and increase the complexity of operation.

In 2007, Raya et al. proposed the LAB scheme (Maxim & Jean, 2007). Initially, this mechanism places every OBU in abundance of private keys and their correlative anonymous certifications within a pool with 43,800 certificates. Then, a vehicle arbitrarily chooses one of its anonymous certifications and adopts its corresponding private key to sign the transmitted data. The receiver adopts the public key of the sender with the anonymous certificate to verify the source data. Those anonymous certificates are used to replace the identity of the vehicles. Every certificate only exists for a short period of time to match the privacy requirement of the vehicle. Although, the proposed LAB scheme achieves the purpose of the supposed privacy requirement, this mechanism needs to maintain quite a huge number of certificates and the identities of authority for all vehicles, and therefore becomes inefficient and not scalable for a large number of IoVs.

In 2013, Hu et al. provided a privacy-preserving scheme for vehicle Ad Hoc networks using group signature protocol (2013). In this study, each vehicle keeps secret keys and public keys to avoid disclosing its identity. Nevertheless, as the increasing quantity of vehicles in the revocation list increases, the consuming time of completing group signature also increases linearly. In other words, this proposed scheme consumes lots of extra time.

In 2018, Nisha et al. provided a scheme to ensure the security of vehicles using the blockchain mechanism (Ali et al., 2019; Kulathunge & Dayarathna, 2019; Nisha et al., 2018). At the same time, Ali et al. exploited a certificateless signature to prove the integrity of transmitted data in IoV, and used a blockchain to store the identity of authorised vehicles and also adopted other blockchain to store unauthorised or revoked vehicles.

In 2015, Xiaodong et al. proposed a security protocol named GSIS for VANETs, which combines group signature with identity-based signature to achieve privacy-preserving (Hong et al., 2016; Xiaodong & Rongxing, 2015). This study exploits group signature to protect the communication between multiple OBUs, where the transmitted data are anonymously signed by the sender, meanwhile, the authorities can recover the identities of senders. Additionally, RSUs adopt identity-based cryptography to sign the transmitted data from RSUs, and make sure the authenticity of RSUs. Since the identity is implied in RSUs, and therefore can reduce the great overhead of signatures.

2020 Joon et al. proposed a secure key and authentication agreement to conquer the security issue in IoV (2020). This study only exploits XOR operations and hash functions to achieve this agreement. In this study, vehicles and RSUs register at the TA (Trusted Authentication) server and perform the secure key protocol instead of a tamper-proof device TPD. Afterwards, vehicles use the session key to encode and decode the transmitted data to RSUs. After receiving the transmitted data, RSUs inspect the received data and forward them to the cloud platform.

In 2021, Insaf et al. proposed an anonymous certificate encryption scheme for IoV on the basis of the Hyper elliptic Curve (HEC) (2021). This given system ensures an official analysis of security as part of the Random Oracle Model (ROM) for confidence, affordability, and anonymous receiver. Additionally, the proposed certificateless cryptography mechanism avoids the issue of key escrow problem and guarantees the anonymity of the receiver in open wireless channels. However, this scheme without the capability to allocate partial private key on an open channel, and thus needs a secure channel to share partial private key with vehicles in IoV environments.

In 2021, Mu et al. proposed an efficient secure attribute-based encryption system for IoV using association rules (2021). This study adopts the features of frequency between vehicle nodes through the max-miner association rules algorithm, and aims to construct frequent item sets and carry out secure communication in vehicle nodes belonging to the same classification set. In this scheme, only ECUs that meet the ciphertext requirements can decipher the data, ensuring data confidentiality while reducing the risk of attacks on the in-vehicle network. However, the access frequency features cannot report the real situation, if an outsider vehicle joins this network and would like to communicate with the group will be turned down.

The IoV system is susceptible to various security and privacy hazards. Although the above methods provide signcryption, authentication or encryption of data for IoVs networks, all of the aforementioned methodologies are based on complex cryptographic mechanisms and bilinear pairing, and all of them have high calculation and communication costs and are incompatible with IoV environments. In other words, they also suffer from the problems of complicated operations, scalability and consume lots of computing time. Therefore, a light security system is needed to ensure protection from a variety of known and unknown threats. This study would like to propose a high efficiency, flexible and scalable mechanism to deal with the security transmissions in IoV.

3. The process of ECDSA digital signature of IoV

As the IoV computer has limited computing resources, this research surveys numerous conventional signature algorithms. We find that the elliptic curve signature (ECDSA) possesses the benefits of rapid rate, strong and small signature. Besides, the ECDSA usage has become increasingly widespread. The functionality of the ECDSA resembles many algorithms of signature (Yasin & Erkan, 2021). It exploits a private key to sign the message and using a public key to inspect the signature. Moreover, the ECDSA operation mode is similar to the other cryptographic schemes, but the key of ECDSA is retained in CNG (cryptography API: next generation). Through CNG, this study is able to securely maintain key pairs, public keys and refer to them utilising simple string names.

Moreover, compared ECDSA to RSA (Ron Rivest, Shamir, Adleman), this study observes that ECDSA utilises a smaller key length to reach a similar level of RSA security, even though ECDSA requires complex implementing methods. The theoretical foundation for ECDSA is to resolve the problem of discrete logarithm of the elliptic curve named ECDLP (Shoma et al., 2015). Nevertheless, the benefits of RSA are convenient to implement and also can be used for encrypting and deciphering simultaneously. Moreover, RSA is slower and the length of the signature is significantly longer, and the theoretical foundation for RSA is to handle the factoring of very large integers. A comparison between ECDSA and RSA can be found in Table 1 (Dhanashree et al., 2018; Nils et al., 2004).

Table 1. Comparing ECDSA to RSA.

Cryptosystem	ECDSA Algorithm (Elliptic Curve Digital Signature Algorithm)			RSA Algorithm (Rivest, Shamir and Adleman)
Secure degree	2^128	2^192	2^256	2^128	2^192	2^256
Signature key Length	64	96	132	384	960	1920
Merits	Rapid speed, short signature length.			Use concise, encrypted and deciphered at the same time.
Defects	Complicated implementation technology.			With lower speed and longer signature length.
Security theoretical basis	ECDLP: Elliptic Curve Discrete Logarithm Problem.			The factorisation of extremely large integers.

Taking into account the current phase, the sensing device took along by the vehicle’s OBU generally has no strong computer power. This research primarily concentrates on the IoV surroundings and presents a cryptographic signature protocol using an elliptic curve and a mechanism for transmitting information security. Therefore, we adopt the ECDH (elliptic curve Diffie-Hellman) key exchange protocol to carry out our key management mechanism and secure data transmission among V2V, V2R and V2G. As ECDH replaces exponential with multiplication and addition (Ram & Manoj, 2013), it uses less necessary memory to the OBU sensors, minimises intricate encrypting and deciphering calculations for the CPU, and ensures a rapid and effective transmission of information security. In addition, the study suggests that vehicles must also communicate with at the end of cloud service platforms, and as a result, this study utilises ECDSA to guarantee the secure data transmission of IoV to cloud platforms, and thus obtain the fully secure IoV architecture.

Furthermore, in practical environments, this study should combine the elliptic curve cryptographic system with the OBU sensors and RSU roadside equipment. Taking into account the need for deployment, we first choose a GF(p) finite field, and estimate the quantity of OBUs and the roadside device. Therefore, this study selects a proper elliptic curve y² = x³ + ax + b mod p, where a = 1, b = 1, p = 307 in F₃₀₇, for instance, the following elliptic curve y ² = x³ + x + 1 mod 307, where p is a prime and G is the elliptic curve Ep (a, b) generator point. The selected elliptic curve conforms to the next qualifications (Daisy et al., 2015): (1) n is a prime and the G order; (2) y_G² = x_G³ + ax_G + b mod p; (3) nG = 0 and n < p. Thanks to this elliptical curve, this survey generates a total of 307 points, as illustrated by Figure 1. Moreover, taking into consideration the quantity of vehicle OBUs and roadside devices, this study allows the elliptic curve and coefficients to be flexibly adjusted and expanded to generate the deployed points required to fit the needs of vehicles and roadside devices.

Figure 1. The elliptic curve point generated by y² = 1x ³ + 1x + 1 mod 307.

ECDSA is comprised of ECC (Amit et al., 2016; Zhe et al., 2017) and DSA. The whole process of signing, as shown in Table 2 and Figure 2, is comparable to DSA. However, the obvious distinction during the signing is the algorithm, which utilises ECC to perform the signature. Afterwards, this study obtains the final result of the signature being divided into (r, s). The process for signing is the following.

Figure 2. The whole ECDSA signature process.

Table 2. Sender and receiver perform ECDSA signature process.

Vehicles/OBU/LCA	Signature	Vehicles/OBU/LCA
1. Select an elliptic curve EGF(p) (d, e), and a generator G. Elliptic curve order = n = | EGF(p) (d, e)| + 1, and n is the number of points on the curve that include infinitely far points.
2. Select a point G = (xG, yG) and k private key, where k∈[1, n−1] and the G order is n, and then the usage of the generator G calculates PK = k x G = k x (xG, yG) public key and it is denoted as (d, e, p, n, G, Pk).
	3. Select a random integer i ∈ [1, n−1], and calculate the point R = (xR, yR) = i x G = i x (xG, yG).
	4.Use the coordinate values (x, y) and the original message M from point R as parameters, and then take SHA1 as the hash function for computing e = HASH(M).
	5. r = xR mod n;
	6. s = (k x r + e) x i^−1 (mod n).
	7. The signature result is (M, r, s). When r or s is 0, go back to duplicate step 3 to regenerate a random integer r until finished from step1 to step7.
		8. The recipient accepts the M message along with the value of the signature (M, r, s).
		9. Calculate e = HASH(M), w = s^−1 mod n, u1 = e x w mode n, u2 = r x w mode n. C = (xc, yc)= u1 x G + u2 x Pk.
		10. Verification of the equation r = xc.
		11. In case the mentioned equation r = xc is accurate, and then takes the signature, else turns down the signature.

4. The framework of a multi-level security

As IoV needs to integrate vehicles, roadside devices and cloud service servers. As a result, each security level is considered similar to the hierarchical authorisation of companies, and each security level has individual duties and is responsible for its own security task. The main purpose of this study is to propose a mechanism of the key management of the multi-level security for IoV via an M-tree framework. Because each vehicle is deployed at the lowest level of the key management scheme, then this study maps the leaf node to a vehicle on layer 4 on the security level. Additionally, RSUs are in charge of gathering the data delivered from the OBUs of the vehicle. This study places the RSUs in layer 3 of the security level, and the LCA (local certificate authority CA) in layer 2. The GCA (global CA) and cloud server correspond to the top level on layer 1 of the security level.

This research also takes into account detection devices of OBU that the vehicles carried at this stage generally have no sufficient computing resources. Here, many vehicles are split into multiple groups, and a group is considered a key management unit. Consequently, we can effectively lower the time complexity of updating and synchronising keys of the entire system, and exploit the ECDH (Elliptic Curve Diffie-Hellman) key interchange protocol to exchange keys, manage and en/decipher data to guarantee the secure data transmission between V2V, V2R and V2G. Besides, because the topology of the IoV is changing quite fast, we must also take into account the management of updating and synchronising keys for IoV.

Consequently, the main purpose of this study is to provide a key management agreement based on a multi-level security framework to combine the elliptic curve cryptosystem with IoV and cloud service platforms (Sathishkumar & Rajakumar, 2017). As V2V or V2R equipment executes secure data transmission, this study employs the ECDH session key to perform the secure data transmission for point-to-point. While the communication is between a vehicle and the group vehicle V2G, this research employs the group key management mechanism to compute a common group key for protecting the security of transmitted data. Additionally, this study deploys a VM virtual machine server at the end of the cloud to serve as the root base station GCA, which is an administrator of the entire system and is responsible for the key management agreement.

Moreover, this study deploys a secure LCA in the V2G communication environment to server as the local group leader. LCA is responsible for the key exchange protocol of ECDH, and updating and synchronising the group key. In other words, LCA is the leader of local RSUs, and takes charge of the local group key management and synchronisation.

Figure 3 depicts the authority framework. Initially, a deployed trusted and secure GCA server is located in this entire system. GCA takes in charge of the issuance of key pairs and the digital certificate. If a vehicle wants to take part in this system, the aforementioned information needs to be applied to GCA. Additionally, OBU, RSU or related devices have to be embedded in the ECC cryptosystem.

Figure 3. The multi-level security system framework.

Afterwards, this study proposes a M-tree framework, as illustrated by Figures 4 and 5, to map IoV equipment to the related security level. The lowest level represents the vehicle. Because the vehicle serves as the role of sender and receiver during the secure data transmission. Additionally, the roadside device RSU serves as a mediator role, and RSUs are located on level 3 of M-tree, since the vehicle transmits data through the RSU to other vehicles or to the cloud service control manager CSCM and GCA, which gathers all delivered data from vehicles, and this study arranges the CSCM and GCA on level 1. Eventually, we employ an M-tree with multiple degrees to correlate the whole system of the key management of the multi-level security, and thus our presented scheme can efficiently address the dynamic key management.

Figure 4. The proposed multi-level security infrastructure maps to corresponding devices.

Figure 5. The proposed M-tree structure correlates to the mapped multi-level security authority.

In this presented research, this study divides M-tree into several groups as the group key management unit. Then, we compute the session key of every leaf node located at the lowest layer, and upward deliver the session key along the route of its ancestor node. Afterwards, the computation of the ancestor node RSU, we can gain the partial group key of level 3 and subsequently forwards it to upper LCA. Eventually, all LCAs perform a similar process and upload the partial group key result to GCA. Consequently, GCA gathers all coming from partial group keys, and eventually calculates the whole IoV system key. In the same way, when an RSU located in level 3 departs, only the replaced RSU passes upwards along its ancestor node to recompute the newer partial group key, subsequently transmits it to LCA and LCA can instantly figure out the newer partial group key, and then forward the newer result to GCA located on the top level. Finally, the whole system comes back to regularity and gains the new system key. Therefore, the proposed scheme indeed accelerates the performance of key resynchronisation. When GCA at the top level collapses, the substituted GCA just needs to gather each LCA’s key to quickly restore the whole system key. Figure 5 depicts the M-tree framework of LCA. The entire system consists of the following elements.

1. Certificate Authority: CA has constant power and plenty of computing and storage resources. It is the secure trusted centre of IoV and is responsible for issuing digital certificates for RSUs, OBUs and vehicles. In this study, we divide CA into GCA (Global CA) and LCA (Local CA). GCA is in charge of the secure trusted centre of the entire IoV, and LCA is in charge of the secure trusted centre of the local area. They serve registration and revocation of certification, and also key management in IoV. Additionally, LCAs also issue the public and private key pairs of OBUs and RSUs, and maintain the identity of OBUs and RSUs.

2. Road Side Unit: RSU is an equipment located along the roadside, and serves as the middle device to forward information from OBUs to LCA. Therefore, while transmitting information to RSU, we should consider the security issue. The main tasks of RSUs are to (1) forward an encrypted message form OBUs, and (2) assist LCA to efficiently verify the real identity of OBU. Additionally, RSUs need the authorisation of LCA and GCA. Besides, RSUs will not reveal any transmitted messages. Here, this study assumes that RSU is strongly secure and cannot be compromised. At the same time, RSU cannot sign delivered messages in the name of either OBU or LCA. Unlike vehicles, this study assumes that RSUs have no computational, energy and capacity constraints. Therefore, RSUs are able to serve as mediators to transfer messages from OBUs.

3. On-Board Unit: OBU is a device installed on vehicles, which has to be registered to GCA with certificates, key pairs and public system parameters before joining IoV. Additionally, OBU can communicate with RSUs via wireless communications and generates the necessity for a tamper-proof device in each vehicle. OBU can perform signature, encryption, decryption, and security operations. When the OBUs of vehicles are on the road, they steadily broadcast information periodically, including position, current time, traffic, speed, direction, accident events, etc. The above information will be processed, aggregated and delivered to the drivers and cloud platform via RSUs.

5. The M-tree based key management with multi-modes secure data transmission

This section utterly discusses the main purpose of our presented the key management agreement of the multi-level security. First of all, GLA uses the elliptic curve cryptosystem to produce several key pair sets. Subsequently, this study embeds the key pair into the OBU of the joining vehicle, and divides vehicles into several groups. Moreover, this study employs the ECDH key agreement to produce session keys between the vehicles depending on the M-tree degree. Afterwards, vehicles deliver the produced session key to its own upper RSU located at level 3. Similarly, the RSU produces the session key between RSUs utilising the ECDH key agreement depending on the M-tree degree, and then delivers the produced session key to its upper LCA. The following describes the process in detail.

In the beginning, the whole system had a prime generator known as the base point P of the Diffie–Hellman agreement. Additionally, each vehicle randomly chooses its individual private key V_x utilising the ECC cryptosystem to produce a correlated public key P_x, and P_x = V_xP. Consequently, we combine the private key V_x with the public key P_x as a pair (V_x, P_x) for vehicle X. In the same way, (V_y, P_y) represents the key pair of the vehicle Y. Within the proposed multilevel security scheme, the leaf node is the same as the vehicle owning a key pair. In the presented system, this research supposes the neighbouring vehicle V₁ and the vehicle V₂ are located at level 4 with key pairs (V₁, P₁) and (V₂, P₂), respectively. Then V₁ and V₂ employ ECDH to compute the common session key S = V₁V₂P for both vehicles, and P is the ECDH generator. Afterwards, both vehicles upward send S to their same ancestor node RSU located at level 3. For briefness, this study illustrates a binary tree. V₁ and V₂ are located at the lowest level as leaf nodes, and both vehicles can infer the same session key V₁V₂P for V₁ and V₂. Similarly, V₃ and V₄ gain the same session key V₃V₄P. Subsequently, V₁ and V₂ upward send V₁V₂P upward to their common ancestor node RSU₁. Afterwards, V₃ and V₄ upward send the session key V₃V₄P to their common ancestor nodes RSU ₂. Since RSU ₁, RSU ₂, RSU ₃  …  RSU_z are all located at level 3, after similar processes referred to above, then RSU₁ and RSU₂ together compute the common session key RSU₁RSU₂P = V₁V₂V₃V₄P. Subsequently, RSU₁ and RSU₂ respectively upward deliver their common session key to their ancestor node LCA. After receiving it, LCA obtains V₁V₂V₃V₄P. In the same way, if there exist other LCAs, they perform the above process and upward to their parent node GCA. Consequently, GCA figures out the system key V₁V₂V₃V_4 …VzP, and Z indicates the final vehicle. Because this scheme just utilises addition and multiplication instead of exponential operations, therefore this mechanism saves a significant amount of computing resources.

Moreover, this study takes into account when the vehicle or RSU takes apart from IoV. We have to recalculate the whole system key. However, this study provides a very efficient way to deal with the reorganisation of the system key. This system only needs to recalculate from the level of the departing node along the upward route to the GCA node. At last, the IoV network gains the newer system key. Besides, the necessity of the whole process takes just Log_mN stages, where m stands for the M-tree degree and Log_mN stands for the M-tree height. Generally, since this study employs ECDH, the benefit is that we almost ignore the M-tree degree, the vehicle just transmits the V_iP value to its ancestor RSU depending on the route from its parent node LCA to GCA, and this mechanism rapidly and efficiently gains the system key. Additionally, our multi-level security mechanism may also offer various managements of various levels and protect devices using different security levels. For instance, before deployment, RSUs need more verification and security. However, we cannot request to equip with ECC key pairs in each vehicle’s OBUs, and therefore give more loose restrictions on vehicles. In addition, LCA, GCA, CSCM and cloud servers must pass multiple strict authentication to take part in IoV. Consequently, the presented system is exactly like the hierarchical concept in an enterprise or in an army, and there are various levels with various security permissions.

Moreover, taking into account the rapid changing of topology and the quantity of vehicles in IoV, the proposed mechanism quickly transforms the multi-level security framework into a dynamic framework of M-tree. These include an RSU that can be connected to at most M-1 vehicles. It is known as an M-tree with M order, and 2 ≤ the degree of nodes ≤M. The M-tree possesses the below features.

1. The degree of the root node is at least 2 degrees.

2. The M-tree conforms to an M-way search tree.

3. The bottom level places the leaf node.

4. The M-tree satisfies ⌈M/2⌉ ≤ the degree of other nodes ≤M, with the exception of root and leaf nodes.

Consequently, the following is that we infer the quantity of members for an M-tree. The full M-tree has the maximum members M⁰+ M ¹+ M ²+ … M ^h−1, and the M-tree height is h. (1) $M^0+M^1+M^2+\dots \dots M^{h-1}=\frac{M^h-1}{M-1}$(1) The binary tree named B-tree with degree two is the M-tree’s special case, which has the minimum members 1 + 2(r⁰+ r¹+ r²+ … r^h−2), and r equals ⌈M/2⌉, and the B-tree height is h.

1 + 2(r⁰+ r¹+ r²+ … r^h−2) $=1+2\left(\frac{r\left(r^{h-2}\right)-r^0}{r-1}\right)$ (2) $=1+2\left(\frac{\left(r^{h-1}\right)-1}{r-1}\right)$(2)

According to the aforementioned inference, we can immediately change the M-tree degree dynamically, depending on the quantity of vehicles to meet the scalability of the practical vehicle environment. Because this research employs the more flexible, scalable and expandable ECC cryptosystem (Jia et al., 2019; Kuljeet et al., 2019), which is also more efficient. The study describes the steps of the proposed multi-level security as follows.

Step1. The identity of every vehicle is V_i with a key pair represented (V_i, P_i). Subsequently, V_i figures out V_iP as its public key, where P is a generator of ECC.

Step2. Depending on the algorithm of M-tree, we suppose that the M-tree degree is 3. Figure 6 and Table 3 describe the M-tree structure and notation, respectively. Here, this research illustrates a 3-way tree to present V_xy1, V_xy2 and V_xy3 cooperatively computing the common session key V_xy1V_xy2V_xy3P. For simplicity, this study denotes V_xy1V_xy2V_xy3P as V_xy1-3P, and subsequently delivers RSU_y with the computed session key. Similarly, the following result indicates that this study repeats the alike procedure and infers the session key. (3) $RS{U_y}_{+1}\text{ obtains }{V_x}_{\left[y+1\right]1}{V_x}_{\left[y+1\right]2}{V_x}_{\left[y+1\right]3}P={V_x}_{\left[y+1\right]1-3}P$(3) (4) $RS{U_y}_{+2}\text{ obtains }{V_x}_{\left[y+2\right]1}{V_x}_{\left[y+2\right]2}{V_x}_{\left[y+2\right]3}P={V_x}_{\left[y+2\right]1-3}P$(4) (5) $RS{U_y}_{+3}\text{ obtains }{V_x}_{\left[y+3\right]1}{V_x}_{\left[y+3\right]2}{V_x}_{\left[y+3\right]3}P={V_x}_{\left[y+3\right]1-3}P$(5) (6) $RS{U}_{y+i}\text{ obtains }{V_x}_{\left[y+i\right]1}{V_x}_{\left[y+i\right]1}{V_x}_{\left[y+i\right]1}P={V_x}_{\left[y+i\right]1-3}P$(6)

Figure 6. Construct the system key through the mapped M-tree structure.

Table 3. The usage of notations in secure data transmission.

Name	Description
GCA	The global certificate authorisation server
LCAx	The local certificate authorisation server, x denotes the LCA number
RSUy	The road side unit, y indicates the RSU number
Vxyj	A vehicle, x indicates the belonging of GCA, and y indicates the belonging of RSU.
ECDSA	Elliptic curve digital signature algorithm.
HMAC	Hash function code
TS	Time stamp
ToS	Type of service
DVxyj	Delivered data of Vxyj
HMAC(DVxyj)	Hash function code of data DVxyj
IDVxyj	Identity of Vxyj
||	Data merge
&	And operation
EKGK_RSUy	Encipher/Encipher data using the group key of RSUy

Then, RSU_y, RSU_y+1, … , RSU_y+j independently and securely communicate their session key to the parent node called LCA_x, LCA_x+1, LCA_x+w, respectively. Upon receipt of the transferred session key, from LCA_x to LCA_x+w duplicate the same process and securely transmit individual session keys to the GCA located at the cloud service platform.

Step3. Finally, on the cloud service platform, GCA is going to gain all the session keys coming from LCA_x, LCA_x+1, … , LCA_x+w. Subsequently, GCA computes the whole system key = V_xy1V_xy2V_xy3 … V_x[y+i]jP through ECDH operations, according to the equations (1)∼(6).

Following these steps above, then every vehicle, RSU, LCA and GCA can utilise the same system key to encipher and decipher the transmitteVSPd data, and thus complete the secure data transmission of IoV.

5.1. The algorithm of secure data transmission

Initial phase:

Each RSU computes the local group key according to the M-tree structure of ECCDH.

Execution phase:

At the beginning, the source vehicle V_xyi determines whether the destination vehicle V_wzj belongs to the same LCA_x group.

Perform x & w operations.

If x = w, then the source vehicle V_xyi and the destination vehicle V_wzj belong to the same LCA_x authority, and then perform y & z operation.

  {If y = z, then the source vehicle V_xyi and the destination vehicle V_wzj belong to the same RSU_y authority. Subsequently, V_xyi and V_wzj perform secure data transmission using the group key of RSU_x to ensure security.

   Else V_xyi and V_wzj belong to the same LCA_x but belong to the different RSU. Then RSU_y and RSU_z exploit LCA_x to perform the group exchange agreement via ECDH to achieve the same group key of LCA_x for the future secure data transmission of V_xyi and V_wzj.

  }

  Else the source vehicle V_xyi and the destination vehicle V_wzj belong to the different LCA_x authority and RSU authority, then RSU_y and RSU_z exploit ECDSA signature agreement to perform the secure data transmission.

5.2. Secure data transmission modes

For increasing the efficiency of secure data transmission, this study proposes the group key mode and the ECDSA mode to deal with different scenarios. The group key mode accelerates the speed of secure communication once the members obtain the same group key. Only the vehicle owns the same group key that can take part in the communication. Others cannot take part in secure communication without the group key. Nevertheless, the ECDSA mode gives an optional way to achieve secure data transmission. When the members of IoV are abundant and huge, the time complexity of obtaining the system key takes longer time. The member can exploit the ECDSA mode to deal with secure data transmission, since the member has already owned the certificate, and thus the vehicle can sign the transmitted data to protect the transmitted data. The detailed presentation is as follows.

1. The secure data transmission of IoV belongs to the same RSU authority: the group key agreement via RSU

When the source vehicle V_xy1 and destination V_xyi are located in the same RSU_y, as shown in the red dot line of Figure 7, and therefore they adopt the group key of RSU_y for the secure communication of all members. Initially, both vehicles perform ECDH cryptography agreement. For simplicity, here illustrates a B-tree structure. V_xy1 and V_xy2 execute the ECDH agreement and obtain the common session key V_xy1V_xy2*P, V_xy3 and V_xy4 obtain the common session key V_xy3V_xy4*P, the remaining vehicle V_xyi execute the same operation and forwards its key to RSU_y, and then RSU_y calculates the common group key for GK_RSUy= V_xy1V_xy2V_xy3V_xy4 … V_xyj*P. Subsequently, if V_xy1 would like to deliver the data to V_xyj, the detailed secure procedure is as follows. $\begin{array}{rl}& \mathbf{\#}{{\mathit{V}}_{\mathit{x}\mathit{y}}}_{\mathbf{1}}\to \mathit{R}\mathit{S}{\mathit{U}}_{\mathit{y}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{G}\mathit{K}\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|\mathbf{|}\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\left({{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\right)\right]\end{array}$Initially, V_xy1 adopts the hash function to calculate HMAC(D_Vxy1), and then enciphers the aggregations of ToS, TS, the routing path, original data and HMAC(D_Vxy1) via the group key RSU_y. Subsequently, V_xy1 sends the enciphered result to RSU_y. $\begin{array}{rl}& \mathbf{\#}\mathit{R}\mathit{S}{\mathit{U}}_{\mathit{y}}\to {{\mathit{V}}_{\mathit{x}\mathit{y}}}_{\mathit{i}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{G}\mathit{K}\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\right)|\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\right)\mathbf{|}|\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\mathbf{\left)}\mathbf{\right]}\end{array}$Once the enciphered data are received, RSU_y deciphers the received data utilising the group key RSU_y. Subsequently, RSU_y performs the hash function on the original data D_Vxy1, and verifies if it equals to the received HMAC(D_Vxy1). If there is a difference, it means during the transmission, the data are tampered with other vehicles. Otherwise, RSU_y puts its ID into the routing path (ID_Vxy1ID_RSUy), and then enciphers the merged data of ToS, TS, the rouging path, the original data (D_Vxy1|D_RSUy) and its HMAC(D_Vxy1|D_RSUy) via the group key of RSU_y. Eventually, RSU_y sends the enciphered result to V_xyj.

Figure 7. Construct the system key through the mapped M-tree structure.

After receiving the enciphered data, V_xyj deciphers them using the group key of RSU_y, and verifies the integrity of HMAC(D_Vxy1|D_RSUy). If the HMAC is correct, then the secure data transmission is complete.

1. The secure data transmission of IoV belongs to the same LCA and different RSU: the group key agreement via LCA

When the source vehicle V_xy1 and destination V_x(y+1)j are located in the different RSU, but in the same LCA_x, as shown in the blue dot line of Figure 7. In this situation, this study has to perform the group key exchange operation to achieve the new group key for LCA. In the beginning, RSU_y obtains its group key GK_RSUy = V_xy1V_xy2 … V_xyj*P using the ECDH agreement, and RSU_y+1 obtains its group key GK_RSUy+1 = V_x(y+1)1V_x(y+1)2 … V_x(y+1)j*P. Subsequently, RSU_y and RSU_y+1 individually forward their group key to LCA_x. After receiving, LCA_x performs the group key exchange operations and obtains the newer group key GK_LCAx = GK_RSUy * GK_RSUy+1= V_xy1V_xy2 … V_xyjV_x(y+1)1V_x(y+1)2 … V_x(y+1)j*P. Additionally, this study employs the common group key GK_LCAx to execute the secure data transmission from V_xy1 to V_x(y+1)j as follows. $\begin{array}{rl}& \mathbf{\#}{{\mathit{V}}_{\mathit{x}\mathit{y}}}_{\mathbf{1}}\to \mathit{R}\mathit{S}{\mathit{U}}_{\mathit{y}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{G}\mathit{K}\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|\mathbf{|}\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\left({{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\right)\right]\end{array}$At the beginning, V_xy1 adopts the hash function to calculate HMAC(D_Vxy1), and then enciphers the merged data of ToS, TS, the rouging path, the original data and HMAC via the group key GK_LCAx. Subsequently, V_xy1 sends the enciphered result to RSU_y. $\begin{array}{rl}& \mathbf{\#}\mathit{R}\mathit{S}{\mathit{U}}_{\mathit{y}}\to \mathit{L}\mathit{C}{\mathit{A}}_{\mathit{x}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{G}\mathit{K}\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\mathbf{|}\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\right)|\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\right)\mathbf{|}|\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\mathbf{\left)}\mathbf{\right]}\end{array}$Once the enciphered data are received, RSU_y deciphers the received data with the group key GK_LCAx. Subsequently, RSU_y performs the hash function on the original data D_Vxy1, and verifies if it equals to the received HMAC(D_Vxy1). If there is a difference, it means during the transmission, the data are tampered with other vehicles. Otherwise, RSU_y put its ID into the routing path (ID_Vxy1ID_RSUy), and then enciphers the merged data of ToS, TS, the rouging path, the original data (D_Vxy1|D_RSUy) and its HMAC(D_Vxy1|D_RSUy) via the group key GK_LCAx. Eventually, RSU_y forwards the enciphered result to LCA_x.

$\begin{array}{rl}& \mathbf{\#}\mathit{L}\mathit{C}{\mathit{A}}_{\mathit{x}}\to \mathit{R}\mathit{S}{{\mathit{U}}_{\mathit{y}}}_{\mathbf{+}\mathbf{1}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{G}\mathit{K}\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|\mathit{I}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\right)|\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\mathbf{)}||\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\mathbf{|}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\right)\mathbf{]}\end{array}$Once the enciphered data are received, LCA_x deciphers the received data with the group key GK_LCAx. Subsequently, LCA_x performs the hash function on the original data (D_Vxy1|D_RSUy), and verifies if it equals to the received HMAC(D_Vxy1|D_RSUy). If there is a difference, it means during the transmission, the data are tampered with other vehicles. Otherwise, LCA_x puts its ID into the routing path (ID_Vxy1|ID_RSUy|ID_LCAx), and then enciphers the merged data of ToS, TS, the rouging path, the original data (D_Vxy1|D_RSUy|D_LCAx) and its HMAC(D_Vxy1|D_RSUy|D_LCAx) via the group key GK_LCAx. Eventually, LCA_x forwards the enciphered result to RSU_y+1. $\begin{array}{rl}& \mathbf{\#}\mathit{R}\mathit{S}{{\mathit{U}}_{\mathit{y}}}_{\mathbf{+}\mathbf{1}}\to {{\mathit{V}}_{\mathit{x}}}_{\left(\mathit{y}\mathbf{+}\mathbf{1}\right)\mathit{j}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{G}\mathit{K}\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|\mathit{I}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}|\mathit{I}{{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{Y}}}_{\mathbf{+}\mathbf{1}}\right)|\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}|{{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{Y}}}_{\mathbf{+}\mathbf{1}}\right)|\\ & |\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\mathbf{|}{{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{Y}}}_{\mathbf{+}\mathbf{1}}\text{)}\mathbf{]}\end{array}$Similar to the above procedure, RSU_y+1 deciphers the enciphered data and verifies the integrity of the received data. Afterwards, RSU_y+1 puts the related data into the corresponding column of the combination. Finally, RSU_y+1 forwards the enciphered result to V_x(y+1)j.

After receiving the enciphered data, V_x(y+1)j performs the above similar procedure, and verifies the integrity of HMAC(D_Vxy1|D_RSUy|D_LCAx|D_RSUY+1), and completes the secure data transmission from V_xy1 to V_x(y+1)j.

1. The secure data transmission of IoV belongs to the different LCA: the ECDSA mechanism

When the source vehicle V_xy1 and destination V_x(y+i)j are located in the different LCAs, as shown in the green dot line of Figure 7. For reducing the computing time of the group key exchange, this study adopts ECDSA mechanism to secure data transmission. The detailed procedure is as follows. $\begin{array}{rl}& \mathbf{\#}{{\mathit{V}}_{\mathit{x}\mathit{y}}}_{\mathbf{1}}\to \mathit{R}\mathit{S}{\mathit{U}}_{\mathit{y}}\\ & \mathbf{\#}\mathbf{E}{{\mathbf{K}}_{\mathit{S}\mathit{i}\mathit{g}\mathit{n}\mathbf{\_}\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|\mathbf{|}\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\left({{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\right)\right]\end{array}$First, V_xy1 signs the transmitted data [ToS|TS|ID_Vxy1|D_Vxy1||HMAC(D_Vxy1)] with its own private key using ECDSA, and then forwards the signature result to RSU_y. $\begin{array}{rl}& \mathbf{\#}\mathit{R}\mathit{S}{\mathit{U}}_{\mathit{y}}\to \mathit{L}\mathit{C}{\mathit{A}}_{\mathit{x}}\\ & \mathbf{\#}\mathbf{E}{{\mathbf{K}}_{\mathit{S}\mathit{i}\mathit{g}\mathit{n}}}_{\mathbf{\_}\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\right)|\text{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\right)\mathbf{|}|\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\mathbf{\left)}\mathbf{\right]}\end{array}$Upon receipt of the transmitted data, RSU_y deciphers the signature result utilising the public key of V_xy1, and verifies the original data [ToS|TS|ID_Vxy1|D_Vxy1||HMAC(D_Vxy1)] whether they are correct. If the transmitted data are tampered with, then discard this data, otherwise RSU_y adds its ID_RSUy into the routing path and computes HMAC(D_Vxy1|D_RSUy) using the hash function. Then, RSU_y signs the entire data using its private key, and delivers the signature result to LCA_x.

$\begin{array}{rl}& \mathbf{\#}\mathit{L}\mathit{C}{\mathit{A}}_{\mathit{x}}\to \mathit{G}\mathit{C}\mathit{A}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{S}\mathit{i}\mathit{g}\mathit{n}\mathbf{\_}\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\mathit{I}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\right)|\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\mathbf{)}||\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\right)\mathbf{]}\end{array}$After receiving, LCA_x adopts the RSU_y’s public key to decipher the enciphered data, and then verifies the original data of [ToS|TS|(ID_Vxy1ID_RSUy)|(D_Vxy1|D_RSUy)||HMAC(D_Vxy1|D_RSUy)] whether it is correct. Subsequently, LCA_x adds its identity ID_LCAx into the routing path and computes HMC(D_Vxy1|D_RSUy|D_LCAx). Consequently, LCA_x signs the entire data using its private key, and then sends the signature result to GCA. $\begin{array}{rl}& \mathbf{\#}\mathit{G}\mathit{C}\mathit{A}\to \mathit{L}\mathit{C}{\mathit{A}}_{\mathit{x}\mathbf{+}\mathit{w}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{S}\mathit{i}\mathit{g}\mathit{n}\mathbf{\_}\mathit{G}\mathit{L}\mathit{C}\mathit{A}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\mathit{I}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\mathit{I}{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}}\right)|\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}|{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}}\right)|\\ & |\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\mathbf{|}{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}}\mathbf{\left)}\mathbf{\right]}\end{array}$When GCA obtains the transmitted data, it performs the above similar procedure and delivers the signature result to LCA_x+w. $\begin{array}{rl}& \mathbf{\#}\mathit{L}\mathit{C}{\mathit{A}}_{\mathit{x}\mathbf{+}\mathit{w}}\to \mathit{R}\mathit{S}{\mathit{U}}_{\mathit{y}\mathbf{+}\mathit{i}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{S}\mathit{i}\mathit{g}\mathit{n}\mathbf{\_}\mathit{L}\mathit{C}\mathit{A}\mathit{y}}[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\mathit{I}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\mathit{I}{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}}\mathit{I}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}\mathbf{+}\mathit{w}}\right)|\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}|{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}}\\ & |{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}\mathbf{+}\mathit{w}}\mathbf{)}||\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}|{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\mathbf{|}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}\mathbf{+}\mathit{w}})\mathbf{]}\end{array}$After receiving, LCA_y utilises the public of GCA to decipher the enciphered data, and then verifies the original data of [ToS|TS|(ID_Vxy1ID_RSUyID_LCAxID_GLCA)|(D_Vxy1|D_RSUy|D_LCAx|D_GLCA)||HMAC(D_Vxy1|D_RSUy|D_LCAx|D_GLCA)] whether they are tamped with, and repeats the similar procedures, adds its identity ID_LCAx+w into the routing path and computes HMAC(D_Vxy1|D_RSUy|D_LCAx|D_GLCA|D_LCAx+w). Eventually, LCA_x+w signs the entire data using its private key, and then sends the signature result to RSU_y+i. $\begin{array}{rl}& \mathbf{\#}\mathit{R}\mathit{S}{\mathit{U}}_{\mathit{y}\mathbf{+}\mathit{i}}\to {{\mathit{V}}_{\mathit{x}}}_{\left(\mathit{y}\mathbf{+}\mathit{j}\right)\mathit{j}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{S}\mathit{i}\mathit{g}\mathit{n}\mathbf{\_}\mathit{R}\mathit{S}\mathit{U}\mathit{y}\mathbf{+}\mathit{i}}[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\left(\mathit{I}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}\mathit{I}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}\mathit{I}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\mathit{I}{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}}\mathit{I}{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}\mathbf{+}\mathit{w}}\mathit{I}{{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}}_{\mathbf{+}\mathit{i}}\right)|\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}\\ & |{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}\mathbf{+}\mathit{w}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}\mathbf{+}\mathit{i}})||\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}{{\mathit{D}}_{\mathit{V}\mathit{x}\mathit{y}}}_{\mathbf{1}}|{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}}|{\mathit{D}}_{\mathit{G}\mathit{L}\mathit{C}\mathit{A}}|{\mathit{D}}_{\mathit{L}\mathit{C}\mathit{A}\mathit{x}\mathbf{+}\mathit{w}}\mathbf{|}{\mathit{D}}_{\mathit{R}\mathit{S}\mathit{U}\mathit{y}\mathbf{+}\mathit{i}}\mathbf{\left)}\mathbf{\right]}\end{array}$When RSU_y+i receives the transmitted data, it adopts the public key of LCA_y to decipher the enciphered data, after that verifies the original data whether they are tamped with. Subsequently, RSU_y+i adds its identity ID_RSUy+i into the routing path and computes HMAC(D_Vxy1|D_RSUy|D_LCAx|D_GLCA|D_LCAx+w|D_RSUy+i). Consequently, RSU_y+i signs the entire data using its private key, and then sends the signature result to V_x(y+j)j.

Finally, when V_x(y+j)j receives the data coming from RSU_y+i, it utilises the public key of RSU_y+i to decipher the enciphered data, and performs the hash function on the source data (D_Vxy1|D_RSUy|D_LCAx|D_GLCAx|D_LCAx+w|D_RSUy+i), and verifies if they equal to the received HMAC(D_Vxy1|D_RSUy|D_LCAx|D_GLCA|D_LCAx+w|D_RSUy+i). If they are different, it means during the transmission, the data are tampered with other vehicles. Otherwise, the original data from each vehicle are correct. According to the proposed mechanism, this study achieves the secure data transmission of IoV belonging to the different LCAs.

In an actual IoV environment, because V2V, V2I, V2P and V2G usually strongly demand rapidity, in addition to the topological architecture of the IoV is changing quickly. This research employs the proposed dynamic M-tree key management agreement and takes advantage of the ECDH and ECDSA to solve the problems of insufficient computing resources on the vehicle, RSUs and the cryptographic system issues between the vehicles.

1. The secure data transmission framework for IoV and the cloud server platform

When data goes through RSU and Internet to arrive at the cloud service platform, the submitted data must be protected against modification. This research uses a PKI infrastructure to securely transmit data and perform identity authentication. Furthermore, we exploit ECDSA to finish the secure transmission of data between vehicles, RSUs and cloud services on the cloud platform.

Because PKI utilises the digital signature of EDCSA to verify the participator identity, this scheme is highly appropriate to authenticate the identity of infrastructure devices, roadside devices, intelligent lights, signage and cloud platform servers. In this way, this research exploits digital signatures to guarantee the authenticity of the information source and to prevent impersonation, man-in-the-middle, and information replay attacks. This allows us to improve the reliability of the securely transmitted data from IoV infrastructure to a cloud services platform.

At the deployment stage, each vehicle member initially requests a certificate via the GCA of the cloud platform. The GCA server is in charge of the issuance of certificates to vehicles, RSU devices, vehicle service provider (VSP) and users. At the same time, the GCA server also is responsible for renewing certificates, revoking certificates and maintaining CRL (certificate revocation list).

When vehicles are required to demand a cloud service, this research utilises RSU to reach the cloud platform to perform secure data transmission. Because RSU and VSP are stationary installations and seldom altered, the identity of participants, such as RSU and VSP, may be confirmed by digital signatures. In the meantime, RSU also may help perform secure data transmission. This lowers the calculation load on OBU of vehicle. The framework of the GCA server is shown on the top left corner in Figure 8.

Figure 8. The whole framework of the secure data transmission between IoV and the cloud service platform.

Firstly, at the early stage of this study, a secure virtual machine is chosen as a GCA server from the cloud platform.

Stage 1. The RSU of the road equipment, the vehicles and the VSP first apply to GCA for a certificate.

Stage 2. If a vehicle requires a VSP service, initially, the vehicle delivers the source data, the type of service ToS demand, itself identity ID, and the time stamp TS. This computation uses a hash function to generate the HMAC code of the above data as HMAC(ToS|TS|ID|source data). Subsequently, this study merges the plaintext data with the HMAC outcome, and employs ECDSA to sign and encipher the entire data via a private key, then after that delivers the signature result to the cloud platform.

Stage 3. The result of the signature is delivered to the boundary CSCM (cloud service category manager) via Internet routers.

Stage 4. Afterwards, CSCM utilises the vehicle’s public key for deciphering enciphered data, then computes the newer HMAC″ code of the received source data, and then verifies if HMAC″ equals to the received HMAC. When HMAC″ equals to HMAC, that indicates the source data are accurate and have not changed as the transmission process progresses.

Stage 5. Depending on the ToS from vehicles, CSCM will send the request to the respective application service on the cloud platform.

This research assumes when the M_A vehicle transmits the data and request to CSCM along V2N, RSU₁ and Internet routers. Once the delivered data has been received, subsequently CSCM delivers this request to the relevant cloud service, depending on the request of ToS coming from the vehicle. Figure 8 shows the path of the blue colour. The following steps describe in detail the secure transmitting of data from the vehicle to the cloud service platform.

If the vehicle M_A would like to deliver the M(DV_A) message to the cloud services platform, M_A initially delivers M(DV_A) to the connected base station RSU₁ by V2N, as indicated by the path M_A ↔ V2N ↔ RSU₁ ↔ R₁ ↔ R₂ ↔ R₄ ↔ CSCM ↔ cloud service platform in Figure 8. Firstly, the vehicle M_A places the required ToS, the time stamp, itself ID and the transmitted data M(DV_A) in the respective column, subsequently enters the aforementioned data as the hash function input, and produces the HMAC(ToS|TS|ID_MA|M(DV_A)). This research then uses M_A’s private key to sign and encipher HMAC(ToS|TS|ID_MA|M(DV_A)) utilising ECDSA and merges the original data with the signature result. Finally, M_A sends all data to RSU₁. $\begin{array}{rl}& \mathbf{\#}{\mathit{M}}_{\mathit{A}}\to \mathit{R}\mathit{S}{\mathit{U}}_{\mathbf{1}}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{S}\mathit{i}\mathit{g}\mathit{M}\mathit{A}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\mathit{I}{\mathit{D}}_{\mathit{M}\mathit{A}}|\mathit{M}\left(\mathit{D}{\mathit{V}}_{\mathit{A}}\right)||\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\mathit{I}{\mathit{D}}_{\mathit{M}\mathit{A}}|\mathit{M}\left(\mathit{D}{\mathit{V}}_{\mathit{A}}\right)\right)\mathbf{]}\end{array}$Once the enciphered data are received, RSU₁ instantly deciphers the enciphered data utilising the M_A’s public key, after that utilises the hash function to figure out the obtained source (ToS|TS|ID_MA|M(DV_A)) to gain a newer HMAC″. Afterwards, we check HMAC″ with the obtained source HMAC, and validate if HMAC″ equals to the source HMAC. When HMAC″ does not match HMAC, this represents that the source data are altered while transmitting, else the received data are valid, and then RSU₁ delivers EK_SigMA[ToS|TS|ID_MA|M(DV_A)||HMAC(ToS|TS|ID_MA|M(DV_A))] to the R₁ cloud router. $\begin{array}{rl}& \mathbf{\#}\mathit{R}\mathit{S}{\mathit{U}}_{\mathbf{1}}\to {\mathit{R}}_{\mathbf{1}}\to {\mathit{R}}_{\mathbf{2}}\to {\mathit{R}}_{\mathbf{4}}\to \mathit{C}\mathit{S}\mathit{C}\mathit{M}\\ & \mathbf{\#}\mathbf{E}{\mathbf{K}}_{\mathit{S}\mathit{i}\mathit{g}\mathit{M}\mathit{A}}\left[\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\mathit{I}{\mathit{D}}_{\mathit{M}\mathit{A}}|\mathit{M}\left(\mathit{D}{\mathit{V}}_{\mathit{A}}\right)||\mathbf{H}\mathbf{M}\mathbf{A}\mathbf{C}\mathbf{(}\mathit{T}\mathit{o}\mathit{S}|\mathit{T}\mathit{S}|\mathit{I}{\mathit{D}}_{\mathit{M}\mathit{A}}|\mathit{M}\left(\mathit{D}{\mathit{V}}_{\mathit{A}}\right)\right)\mathbf{]}\end{array}$Once the enciphered data are received, router R₁ forwards it to R₄ passing through routers R₂ and R₃ depending on the routing table. During this phase, the router can utilise its security protocol to protect the network packet.

Once R₄ obtains the enciphered data, R₄ forwards it to the border CSCM server. Meanwhile, CSCM uses the M_A’s public key to decipher the enciphered data, and subsequently computes the newer HMAC″ code of the received source data [ToS|TS|ID_MA|M(DV_A)] utilising the hash function. Afterwards, this research verifies HMAC″ with the received source HMAC, and subsequently determines if HMAC″ = HMAC. When it makes any difference, this represents that the source data are altered during the transmitting path of RSU₁→R₁→R₂→R₄→CSCM. If not, CSCM sends the request to the relevant cloud application service, depending on the requested ToS from M_A.

Generally, the proposed framework using the ECDSA signature protocol can securely transmit data between V2V, V2I, V2P, and V2G in IoV, and also secure the transmitting of data between the OBU of the vehicle and the cloud server platform as well. Finally, this research prevents harmful vehicles or malicious network devices from joining the transmission of data.

1. The architecture of secure data transmission for the cloud server platform: secure Map Reduce operations

When the CSCM sends the data to the related cloud service server (CSS) to perform Map/Reduce operation according to ToS, in order to confirm the identity and security of Mapper and Reducer for participants deployed in the cloud, this study uses VM Ware to simulate and construct several virtual servers to jointly execute Hadoop and Map/Reduce operations. Because there are so many servers in the cloud, the system must verify the identity of the participants before it cooperatively performs security operations. This study uses Kerberos to authenticate the participating servers before performing secure Map/Reduce operations to keep the data secure (Mukti et al., 2018; Subodh & Rajesh, 2020), as shown in Figure 9.

Figure 9. The Kerberos authentication protocol for the Mappers and Reducers of the cloud service platform.

At the beginning of this system, we selected a secure GCA (as the key distribution centre), Mappers and Reducers from the cloud servers with mutual trust. The account database of GCA DB stores the account secrets of virtual servers such as CSS, Mappers, Reducers and other cloud service servers as follow-up identification operations. When the CSS requests the Map/Reduce operation, at the initial registration stage: CSS, Mappers and Reducers generate a group of personal passwords through the random number generator and store them into the account database of the GCA server.

Step1. Apply for a session key Initially, CSS requests a session key SK from the GCA VM server.

Step2. The master key and the enciphered session key: When GCA (a key distribution centre) receives the request, and then calculates a session key SK. In order to ensure that only CSS and Mappers/Reducers know SK, GCA respectively extracts the password of CSS and the Mappers/Reducers which take part in this operation, from the account DB. Subsequently, GCA performs a hash operation and respectively obtains the master key of CSS and the Mappers and Reducers, such as MK_{CSS(/Map/Red)}= HASH(Password_{CSS(/Map/Red)}). After that, CSS uses itself master key MK_CSS to encipher the SK via a symmetric encryption scheme and obtains EK(SK)_MK-of-CSS, and then uses MK_Map and MK_red to perform symmetric encryption operations on SK, ID_CSS, IP_CSS, its Domain and TS to respectively obtain EK[SK|ID_CSS|IP_CSS|Domain|TS]_MK-of-Map and EK[SK|ID_CSS|IP_CSS|Domain|TS]_MK-of-Red. For simplicity, we present it as EK[SK|ID_CSS|IP_CSS|Domain|TS]_{MK-of-Map(/Red)} also named the session ticket. So far, GCA has a session ticket that consists of SK, CSS and Mappers/Reducers encrypted by MK. Eventually, GCA delivers EK(SK)_MK-of-CCS and the session ticket EK[SK|ID_CSS|IP_CSS|Domain|TS]_{MK-of-Map(/Red)} to CSS.

Step3. When CSS receives the above message, then forwards EK(SK)_MK-of-CSS and the session ticket EK[SK|ID_CSS|IP_CSS|Domain|TS]_{MK-of-Map(/Red)} to the Mappers/Reducers, which take part in this operation.

Step4. In order to provide more effective identity authentication, after receiving the encrypted session key SK, CSS uses its own MK_CSS to decipher the received EK(SK)_MK-of-CSS from GCA and obtain SK. Then the authenticator is generated, and contains the ID_CSS, IP_CSS, Domain and TS to be the duration of the subsequent confirmation request. Subsequently, this study enciphers the authenticator using SK and obtains EK[ID_CSS|IP_CSS|Domain|TS]_SK. After that, CSS delivers the authenticator EK[ID_CSS|IP_CSS|Domain|TS]_SK to the Mappers/Reducers, which take part in this operation.

Step5. When the Mappers/Reducers receive the above message, then decipher EK[SK| ID_CSS|IP_CSS|Domain|TS]_{MK-of-Map(/Red)} using itself MK_Map(/Red) to obtain SK, and then can decipher the received authenticator EK[ID_CCS|IP_CCS|Domain|TS]_SK using SK to compare the [ID_CSS|IP_CSS|Domain|TS] of the session ticket and the deciphered result [ID_CSS|IP_CSS|Domain|TS] of the authenticator whether they are the same to ensure the identity of CSS. After CSS and Mappers/Reducers verify each other’s identities, and this study can perform the secure Map/Reduce operations.

The above secure data transmission modes provide a flexible and scalable option to protect data. The proposed mechanisms finish the secure data transmission from vehicles to cloud, and also integrate cloud platform with IoV. When a source vehicle wants to deliver data to a destination vehicle, under the same RSU or LCA, this study adopts a group key mechanism to secure data. Nevertheless, a huge IoV can exploit ECDSA to improve the efficiency of secure data transmission between vehicles. Additionally, this study also considers the secure transmission of data between vehicles and the cloud service platform. We provide a complete secure architecture to achieve this target, and make sure the identity of VM members joining the secure map/reduce operations.

6. The analysis of security and performance

In this section, we analyze and estimate our presented secure data transmission scheme. While transmitting data, the system must guarantee data integrity and avoid modification. Furthermore, we must make sure of the identity of participants in order to avoid impersonation from taking part in the process of data transmission. The following describes the detailed analysis of security.

1. Signature verification proof

According to the ECDSA algorithm, the receiver has to verify the identity of the sender. This study infers the following operations and ensures the signature of sender. $\begin{array}{rl}C& =(x_c,y_c)=u_1\times G+u_2\times P_k\\ & =u_1\times G+u_2\times k\times G=\left(u_1+u_2\times k\right)\times G\\ & =\left(e\times s^{-1}+r\times s^{-1}\times k\right)\times G=(e+r\times k)\times s^{-1}\times G\\ & =(e+r\times k)\times \left[\right(k\times r+e)\times i^{-1}{]}^{-1}\times G\\ & =(e+r\times k)\times (k\times r+e{)}^{-1}\times (i^{-1}{)}^{-1}\times G\\ & =i\times G=\left(x_R,y_R\right)=\left(r,y_R\right)\end{array}$From the above inference, this study can prove that indeed r = x_c, and thus this study can ensure the signature is correct.

1. Identity verification

In this study, although there is no authentication process when GCA made a request to CSS. However, if CSS_A pretends or claims to be CSS_B, then CSS_A will obtain the session key SK of CSS_B and Mapper/Reducers. However, the subsequent GCA uses CSS_B’s password to calculate the master key of CSS_B and uses the master key of CSS_B to encrypt SK.

However, only those who really know the CSS_B’s password can decipher and obtain the session key SK. Therefore, CSS_A cannot decipher and obtain the session key SK without CSS_B’s password, so it can confirm the identity of participants.

1. Confidentiality of Vehicle-to-Vehicle

Once malicious vehicles are interested in communicating with each other, through the route of transmission, only the two connected vehicles own the same session key via the ECDH key exchange protocol, after that utilise the session key for enciphering and deciphering transmitted data. Just the vehicle or RSU owns the common session key that can encipher or decipher the transmitted data (Zhang et al., 2021). The vehicle with no session key which cannot be included in the process of secure transmission, in spite of the harmful vehicle impersonates others, and thus this study can guarantee confidentiality of information transmission for Vehicle-to-Vehicle.

1. Confidentiality of Vehicle-to-Group

Just vehicles that have the same group key are allowed to participate in the group to communicate (Dan et al., 2004; Zhang et al., 2011), while vehicles with no group key are not allowed to join the communication. Even though an outside vehicle is listening or receiving a transmission, it is unable to decipher the encrypted message by the group vehicle as it has no group key. This method prevents messages from leaking or altering and ensures the confidentiality of messages between vehicles and groups.

1. System scalability

In this study, we utilise a dynamic M-tree structure to achieve the group key management. The benefit of M-tree is flexibility and scalability. As this research expands the quantity of vehicles, the whole system constantly retains the O(log_M N) time complicity, where M stands for the M-tree degree and N stands for the quantity of vehicles, to figure out the group key. Moreover, even a great number of vehicles join the communication, the system just needs log_MN stages to deal with the resynchronisation of the group key and obtain the common group key, as shown in Table 4. This mechanism is very well adapted to the wide range of vehicles in the IoV environment. Figure 10 shows the dashed green square as the new connecting vehicles, and the investigation result indicates that the system still needs the same quantity of phases for handling key interchange and computing the group key. Besides, when a vehicle leaves, the whole system only has to compute the subtree of the leaving vehicle, then can reconstruct the newer group key of the vehicles. Therefore, this mechanism has flexibility and scalability.

1. Efficiency of the key management

Figure 10. The resynchronisation phase of the group key when vehicles joining or leaving IoV.

Table 4. Resynchronisation cost of the system key for IoV.

Cost	Vehicle/RSU	Employ ECDH to perform M-tree key agreement	Employ ECDH to perform B-tree key agreement	Employ DH to perform none-tree key agreement
Operational costs	Vehicle join	2 unicasts and 1 multiplication	2 unicasts and 1 multiplication	${\text{C}}_2^N$
	Vehicle leave	2 unicasts and 1 multiplication	2 unicasts and 1 multiplication	${\text{C}}_2^N$
	RSU join	2 unicasts and 1 multiplication	2 unicasts and 1 multiplication	${\text{C}}_2^N$
	RSU leave	2 unicasts and 1 multiplication	2 unicasts and 1 multiplication	${\text{C}}_2^N$
Resynchronising phases	Vehicle join	LogM(N)	Log2(N)	${\text{C}}_2^N$
	Vehicle leave	LogM(N)	Log2(N)	${\text{C}}_2^N$
	RSU join	LogM(N−1)	Log2(N−1)	${\text{C}}_2^{{\log }_{2}N}$
	RSU leave	LogM(N−1)	Log2(N−1)	${\text{C}}_2^{{\log }_{2}N}$

In this study, we compare the proposed key management of M-tree with None-tree and B-tree schemes on re-synchronising the system key. From Table 4, if vehicles participate in or take apart from IoV, the entire system needs to resynchronise the system key. As a result, the ECDH with M-tree and B-tree schemes outperform the None-tree scheme on communication and operational costs, since the M-tree scheme just takes two unicast phases and one multiplication phase. However, the None-tree scheme takes ${\text{C}}_2^N$ phases utilising DH.

1. Synchronisation time of a vehicle joining or leaving

Initially, this system needs to construct the system key. Figure 11 depicts the construction time of the system key on different schemes. As a result, the M-tree based scheme outperforms GDH and DH under the same secure levels. Since the M-tree structure only needs to update the keys along the parent nodes, GDH and DH have to exchange the share key for each other that needs ${\text{C}}_2^N$ phases, and then obtain the system key. Additionally, a vehicle or an RSU joins/leaves the IoV, the entire system needs to reconstruct the entire system key. Figure 12 demonstrates that a vehicle joins IoV. The M-tree based scheme takes less resynchronisation time to reconstruct the system key then GDH and DH, since M-tree only needs to recalculate the joining node and the parent node. Similarly, when a vehicle leaves, the M-tree based scheme also outperforms GDH and DH, as shown in Figure 13.

Figure 11. The comparison of constructing the system key on M-tree, GDH and DH schemes.

Figure 12. The comparison of reconstructing the system key when a vehicle joins IoV.

Figure 13. The comparison of reconstructing the system key when a vehicle leaves IoV.

7. Conclusions

Thanks to the development of 5G, automated driving without a driver will be right around the corner. Because IoV has an open communication environment, personal information is disclosed to the wireless network. Therefore, the problem of information security for IoV is going to be a significant theme. The proposed agreement of the multi-level security key management for IoV relies on the structure of an M-tree with the capacity to dynamically adjust the framework depending on the rapidly changing IoV topology. Additionally, this mechanism speeds up the time to synchronise the reconstruction of the system key, and decreases the quantity of phases to resynchronise the system key. Moreover, the provided key management for the multi-level security is quite appropriate to adaptable and expandable IoV environments. As well, the system effectively lowers operation and communication costs. In comparison to a B-tree, this study employs an M-tree that is more effective than the conventional key management. Moreover, the use of addition and multiplication operations can take the place of complex exponential operations and decrease the computing loading of OBU and RSU, and is better suited for IoV without plenty of calculating resources. Consequently, this study utilises a smaller key length of ECDSA to reach Diffee-Hellman or RSA security level, and secure the transmitted data among IoV devices and cloud service platforms. Thus this study can ensure information security and achieve secure IoV.

Data availability statement

The data that support the findings of this study are available on request.

Disclosure statement

No potential conflict of interest was reported by the author(s).