1. Introduction
The Internet of Vehicles (IoV) is an essential component of the future Intelligent Transportation System (ITS) [
1]. With the development of artificial intelligence applications represented by automatic driving, the in-vehicle sensors and user applications generate a large amount of multimedia data related to security issues [
2]. The normal form of On-Board Units (OBUs) is in-vehicle gateways with a multihomed access capability, which can typically connect to multiple heterogeneous network resources, such as 4G/LTE, 5G, WiFi, and satellite links. As the core component of integrating heterogeneous network resources between Internet of Vehicles devices and cloud services in the ITS framework, the security of the in-vehicle gateway must be prioritized [
3]. Multihoming and mobility cause frequent changes in the wireless network context of devices. To ensure the security and confidentiality of communication systems, we must create a gateway-to-cloud certified secure channel for mass data transmission [
4]. Data loss caused by gateway devices during communication interruption caused by authentication switching should be prevented to meet the demand for delay-sensitive communication in the IoV. The unstable nature of a channel will lead to the loss of authentication messages, resulting in long-term communication interruption and a large amount of data loss. Therefore, higher requirements are placed on the authentication delay of equipment [
5] to achieve context awareness. In summary, an appropriate authentication mechanism to meet the needs of the IoV scenario should be lightweight, low latency, and support both multihoming and mobility [
6].
This study focuses on the security authentication of a mobile multihoming in-vehicle gateway in the IoV scenario, especially on the data source authentication scheme between the in-vehicle gateway and the cloud. How to realize in-vehicle gateway authentication in the dynamic context of the network and provide security-certified data support for IoV delay-sensitive applications is the purpose of our scheme. There are mainly three mainstream technologies to support mobility and multihoming in the IoV. The first is the network layer method of the Internet Key Exchange Protocol (IKE) and its extension (MOBIKE) [
7]. The second is the Datagram Transport Layer Security (DTLS) [
8] working in the transport layer. The last is the layer 3.5 Host Identity Protocol (HIP) [
9] between the network layer and the transport layer. Its basic design allows mobility and multihoming. However, the core principle of the above research directions to construct the certification of devices remains the creation of Security Associations (SAs). The authentication of the in-vehicle gateway is achieved between two endpoints through the traditional Public Key Infrastructure (PKI) certificate mode. The key information maintained by SAs is realized through the interactive key agreement process with the Diffie–Hellman (DH) algorithm. In addition, IP handoff caused by mobility and multihoming support is realized through the interaction of control messages. In addition, since the original design did not consider the aggregation and utilization of heterogeneous network resources, the traditional security mechanisms could not achieve efficient aggregation of multiple links.
The role of the in-vehicle gateway is to provide data packet aggregation and forwarding. The SA establishes a connection between two communication parties, which violates the design principle of stateless forwarding of the network layer. Therefore, this SA-based security authentication measure is inefficient, expensive, and inflexible in a dynamic heterogeneous network scenario, which is intolerable for delay-sensitive IoV requirements.
The following list outlines the issues with the current mechanism:
Identity authentication is dependent on the intricate PKI infrastructure. The operations related to certificates cause overhead issues in terms of delay and bandwidth.
Control messages must be used to create and maintain the SA, which delays authentication and interferes with the IP layer’s stateless feature. Unavoidably, due to the link state fluctuation of heterogeneous networks, signaling interaction will bring unpredictable delay. At the same time, due to the unstable characteristics of the link, such as high packet loss, the performance of the mechanism is further deteriorated due to the retransmission of signaling.
Existing research support for multihoming is restricted to only providing a list of alternate addresses to use multihoming interfaces as the primary and alternate channels. The bandwidth aggregation efficiency of multipath makes it difficult to reach the ideal value.
Given the above problems, we propose a data-driven noninteractive authentication scheme, a lightweight authentication scheme based on the network state context. It aims to realize data privacy and secure communication for the in-vehicle gateway with heterogeneous network access capability. Our scheme is based on bilinear pairing. The in-vehicle gateway calculates authentication keys from network state contexts, such as preassigned private keys, device IDs, network adapter serial numbers, and source address information. The initiation of device authentication and key agreement depends on the driver of user data rather than establishing a dedicated security state.
The security scenario we focus on is the data source authentication from the in-vehicle device with heterogeneous access capability to the cloud server. To secure the entire system, the in-vehicle device needs to achieve offline authentication and device ID registration in the cloud to establish an identity-based key system. The device ID, as a security credential, is used as an identity-based noninteractive key negotiation parameter in the data communication process. Combined with different access identifier parameters (usually IP addresses) and device context information, the multihomed device can authenticate the source address of multiple IPs during the mobile process. The cloud server can also ensure the consistency of data integrity and the data encryption key according to the device ID, access address, and other inherent information of the payload. The address source authentication and data confidentiality and integrity assurance during the communication process can be achieved through the above steps. The triggering of the security communication mechanism depends entirely on the interaction of the payload and does not need to establish the security state in advance. Compared with the traditional strategy, our scheme is more suitable for the heterogeneous Internet of Vehicles network with fluctuating network states due to its light weight and highly efficient characteristics. The specific authentication scheme is introduced in
Section 3.
This article makes the following contributions.
A data-driven authentication scheme based on noninteractive key agreement is proposed. Compared with the PKI system based on certificate authentication, the proposed scheme has the characteristics of low bandwidth overhead and short interaction delay. This design paradigm meets the needs of the IoV scenario for data secure collection and analysis.
According to the communication state of the in-vehicle gateway, we designed an authentication process and two handover mechanisms so that the proposed scheme inherits the stateless feature of the IP layer protocol. Furthermore, our scheme natively supports multipath.
We proved the advantages of our scheme over the traditional interactive mechanism through a comparative simulation. In terms of the delay, it brings less authentication delay, handover overhead in different states, and calculation processing delay. In terms of multipath support, the proposed scheme has better heterogeneous resource aggregation capability.
The remainder is structured as follows. In
Section 2, we introduce the relevant research. We outline our scheme’s precise design in
Section 3. In
Section 4, we conduct experiments to evaluate the performance of the suggested scheme in terms of the latency of authentication, handover, and data transmission. For the heterogeneous resource characteristics of the IoV, multipath aggregation efficiency is also an indicator that we focus on. Finally, we provide a summary in
Section 5.
3. The Design of Our Scheme
3.1. System Architecture
To realize the collection and transmission of massive sensor device data by intelligent applications, the multipath transmission technology integrating heterogeneous resources is indispensable in the IoV. The system architecture of multipath parallel transmission was based on our existing research [
30]. In this multipath architecture, the in-vehicle gateway and cloud server are used as multipath aggregation agents, respectively, to realize multipath aggregation management by establishing logic tunnels to provide transparent concurrent multipath data transmission for massive sensor device data. The focus of this paper is on lightweight authentication support for mobile multihoming devices to achieve stateless forwarding of IoV data. Therefore, the comparison schemes in the subsequent experimental stages were all implemented under the same architecture. It is worth noting that the schemes proposed in this paper can be integrated at different levels according to specific requirements and can realize IP-in-IP encapsulation at the network layer or UDP encapsulation at the transport layer according to the mode adopted by the architecture. In order to facilitate the comparison with the subsequent experimental comparison scheme in this paper, we integrated the proposed scheme into the network layer through IP-in-IP encapsulation.
Figure 4 shows our system architecture. Different in-vehicle gateways can communicate with cloud servers through heterogeneous networks. We show the registration and communication process of building security domains with different GWs under the same CS.
Table 2 shows the abbreviations in our paper.
3.2. Security Assumptions
For the convenience of illustration, we use the abbreviations GW and CS to represent the in-vehicle Gateway and Cloud Server, respectively. The following security presumptions form the foundation of our security system. The GW is a trusted device and will not be an attacker against system security. When the GW is hijacked by an attacker and becomes no longer trusted, the system will ensure system security through key revocation.
We designed an identity-based noninteractive key agreement to construct the security domain. The theory is shown below.
Pairings and the Bilinear Diffie–Hellman (BDH) problem:
represents an additive group of prime order q in a bilinear group system. represents a multiplicative group of prime order q that we define. Based on the above definitions, stands for a bilinear map. The bilinear map has the properties listed below:
(a) Bilinearity: ∀∈ and ∀∈, we have .
(b) Non-degeneracy: is a generator if P is a generator.
(c) Computability: can be efficiently calculated given P∈ and Q∈.
The BDH problem determines the security of the key negotiation procedure depicted below.
Given the above-mentioned generation algorithm, PairingGeneration, we describe the advantage of a probabilistic polynomial-time method
in addressing the BDH issue as
where
are picked at random in a uniform manner. The BDH assumption holds for (
,
) if
is negligible for all probabilistic polynomial time algorithms
.
3.3. System Establishment
System setup: The CS generates a bilinear group system using a probabilistic polynomial-time algorithm, which includes two-cycle groups and with prime order q, a bilinear map . The CS publishes the hash function , which is collision-resistant according to the security requirements. The devices in the system must be uniquely identified, as in , . The bilinear system created by the current CS is the foundation upon which the security domain is built. The system parameters published by the CS ensure that the operations between devices belonging to the CS are based on the same system. We follow the entities of the bilinear system parameter operations to form the public security domain.
3.4. Establish the Security Domain of GW
Registration phase: Different from the traditional IBC system, in the proposed security scheme, the CS, as the communication participant of the security domain, only provides the public parameters of the security domain and the CS device ID as the communication party. The CS does not generate the private key in the domain. The private key of the GW device does not need to be calculated by the CS. Unlike the system that relies on the PKG, it provides the key certificate to the CS by registering the GW device with the CS. This ensures source address authentication when the GW device’s IP address and other key negotiation parameters are variable.
In the registration process, the GW device generates the private key
by itself and generates the registration key
through the scalar multiplication operation on the elliptic curve according to Equation (
2). We concatenated the
and
strings and mapped them to the points on the elliptic curve through the
function. The result performs scalar multiplication on elliptic curves with
to obtain
. The GW submits the registration key
to the CS. The CS stores the accompanying private key
. In the subsequent key negotiation process, the CS will calculate the real-time shared key based on the security domain registration key and the communication context of both communication parties, so as to make the device’s IP address variable. Address authentication based on the device communication context was implemented.
Figure 5 depicts the relevant process. We might consider the CS and GW to be part of the same security domain. The registration process’s security parameters make up the security domain’s context parameters. Through the registration phase, the CS and a GW share the key negotiation parameters based on the master private key in the public security domain. Because the CS has the registration credential, it can ensure that the key negotiation with different parameter IDs of the GW can be realized. The CS and the registered GW jointly constitute a sub-security domain.
3.5. Authentication and Key Agreement
As was already noted, the creation of the SA is necessary for the current network layer security approach to operate. In wireless heterogeneous settings, there is a large delay introduced because state establishment information exchange is necessary prior to data interaction between communication parties. The foundation of our suggested security system is a context-aware data-driven stateless protocol. It is not necessary for both communication parties to initially establish a stateful connection when both have communication requirements. In this work, the secure authentication of multihoming mobile devices was accomplished via an identity-based noninteractive key. In this arrangement, the security domain includes both the GW and CS. Key negotiation was carried out between the two communicating parties utilizing security domain parameters and network state context parameters. The support for an address change is made possible by this design.
After the registration phase, a security domain database is established on both sides of the GW and CS to manage the network context status parameters under the same security domain for data authentication.
Figure 6 shows the context parameter status when the same GW and different CSs constitute a security domain. The security domain master key
and the CS device’s ID are recorded at the GW end. Each GW ID and its corresponding
are recorded at the CS end. At the same time, the network card serial number and the IP address from the corresponding device, as well as the switching times of the corresponding IP address are recorded. These are used as the network context parameter to generate the authentication key. At the same time, it records the IP switching frequency and packet transmission characteristics of the corresponding network card of the corresponding device. These are used as one of the authentication parameters for a more advanced security access design. The CS side’s context parameter database is shown in the figure. The device ID parameter indicates the parameters in the security domain to which both sides of the communication belong. The IP address is used to calculate the materials of the shared key to realize the source address authentication. The network card serial number and IP handover times are used to characterize the scheduling characteristics and mobile handover characteristics of the mobile multihoming device. Both sides of the communication maintain the switching times. Each time the IP address side from the same network card serial number of the GW triggers the count +1 at the CS end, both sides of the communication have the same switching count.
Figure 7 shows the authentication and data transmission process, and the relevant description is as follows.
3.5.1. GW End
When the GW needs to send data, it dynamically senses the network status, extracts the network adapter information, and obtains the address and network adapter serial number
. The private key
for the network interface
is derived from Equation (
3). We concatenated the
,
, and
strings and mapped them to the points on the elliptic curve through the
function. The result performs scalar multiplication on the elliptic curves with
to obtain the private key
.
After obtaining the private key of the network interface, the shared key material can be determined. The security domain information and destination IP address of the communication party are necessary. The key material
is derived through Equation (
4). In this process,
and
are paired in the bilinear system of the current security domain.
The authentication key is calculated by the Pseudo-Random Function (PRF) with input parameters
and
, as shown in Equation (
5).
The number of IP address switches of the network adapter is expressed as . Each network card’s seed counter is initially set to 1 or a default initial value. As the network adapter’s IP changes, the counter step size also changes. To guarantee the consistency of shared keys, both communication participants must keep the same seed counter. To assess the safety status of the equipment and the safety factor of the equipment operating cycle, this parameter can be utilized as a context-aware parameter input.
The network adapter identifying the number of the local device is a necessary context parameter in the multihoming scenario, which aids in the management of the multihoming address. Additionally, the GW ID needs to be transmitted to the other end, in order to determine the necessary security domain characteristics. In
Figure 8, the packet header is displayed. By performing the HMAC procedure on the IP packet’s immutable portion, the authentication field’s value may be determined. To guarantee data integrity and source authentication, the HMAC key is the agreed-upon shared key.
3.5.2. CS End
When the CS receives a data packet, it parses the packet header information and searches the security domain database for the relevant item. When the corresponding item exists, the peer device is legal. If the packet from the peer network adapter that has not been initialized is received, the relevant shared key material is initialized according to Equation (
6).
In order to verify the integrity of the received packet and realize its source authentication, the shared private key is then retrieved by the PRF. The CS uses the authentication key to perform the same HMAC calculation with the sender to compare the authentication fields of the packets. The entire communication flow is depicted in
Figure 9.
Obviously, just a few fields must be added to the data packet header in order to accommodate the authentication information stated above. Without requiring any further information exchange, the authentication procedure may be started when a user data transmission request occurs on the mobile subnet. It exactly adheres to the IP layer’s design philosophy, whereby only forwarding is implemented, and the reliability of the communication is ensured through the top layer.
From the above process, we can see that there is only normal load data exchange in the whole authentication process, and there is no additional signaling transmission. In the IOV scenario, various devices generate new data all the time. This scheme avoids the loss of data blocking caused by the time loss in the signaling interaction process.
3.6. Mobile Support
When IP address switching occurs, the network adapter of the GW dynamically detects the change of the address context and dynamically updates the new private key of the corresponding network interface as Equation (
7).
The shared key material should be updated as Equation (
8).
When calculating the shared key using the PRF as Equation (
9),
The seed counter is incremented by one with the IP switching, forming a new shared key. Then, it communicates as described above.
The receiver receives the data packet from the new address. The address update can be detected by evaluating the network card serial number in the header, and the shared key material is recalculated as Equation (
10).
In addition, the PRF will increase the seed counter by one when calculating the shared key. If the updated packet fails to pass HMAC authentication, it is a forged attack packet, and thus, the corresponding shared key and seed counter will not be updated.
Since the proposed scheme is triggered by the transmission of user data, there are different authentication switching modes depending on whether there is data transmission between the GW and CS. In the first scenario, switching takes place while both sides are exchanging data. Instead of being provided independently, the IP switching information is delayed until the user data packet is updated and activated. This mode is named the transmission mode. The second case is that there is no data transmission between the GW and CS. The GW will now aggressively transmit alerts of address updates to notify the CS. This mode is named the notification mode. According to the above analysis, no matter in which mode, the switching process only needs a single information interaction at most to achieve address and key renegotiation. Our scheme avoids the data transmission interruption caused by redundant message interaction in traditional stateful protocols.
3.7. Key Revocation
In our design, the device registration process is realized through a secure channel. That is, the device is a secure device that passes the review when it is registered. In addition, each device holds the independent device key in the communication process. Even if a single device is attacked, it cannot affect the security of other devices in the system. Since the CS maintains the GW communication context information in the security domain, when the GW becomes a malicious device, the CS can identify the malicious device and revoke its key according to abnormal changes in the context, such as frequent switching of the address, which causes the changes and the abnormal transmission of data streams. In addition, the design of key revocation can also enhance the robustness of the system against malicious devices’ attacks.
Under our security domain architecture design, the key revocation is straightforward. The CS only needs to publish the revocation list of the GW equipment and broadcast it in the whole domain. For scenarios with high security requirements, the characteristics of the IBE technology can be used to add a time parameter when generating the registration certificate when the GW registers with the CS according to the requirements of the key security period. In this way, the key expiration cancellation can be realized. The above two schemes can be used in combination. Through this design, our system security is guaranteed in terms of the timeliness and security level.
3.8. Source Address Authentication against Man-in-the-Middle Attack
Our scheme implements the authentication of the communication source address based on the device ID and communication context. We explain this through the following description. Suppose an attacker impersonates the identity of a legitimate device with to communicate with the CS. The CS calculates the authentication key according to equation . An attacker who wants to pass the message authentication needs to generate an authentication header through the authentication key. In this way, the CS can conclude that the device with is an attacker, thus denying the address access. Any changes made by an attacker in the communication process will make the other legal party unable to generate the authentication header corresponding to the packet context. Such changes will only lead to invalid data and cannot lead to key disclosure. The data flow that has not been attacked can still generate the corresponding security key through a legitimate process to achieve secure communication. In addition, because of our source address authentication function, attackers cannot perform man-in-the-middle-attacks as devices counterfeiting any communication.
3.9. Computational Overhead
We present the computational cost for all cryptographic operations in our scheme in
Table 3. The configuration of the test equipment was “Ubuntu 20.04, with an Intel (R) Core (TM) CPU i5-7200U,8.1 GB memory, @2.50 GHz”. The source code was implemented in C++.
The overhead of system establishment can be loaded when the device starts running, including at the GW end and at the CS end. In the authentication phase, the total computational cost of our scheme is ms. It should be noted that our scheme can greatly reduce the delay in the interaction process. In the context of the IoV with fluctuating link states, the delay occupies a more important proportion than the computational cost.
4. The Experimental Verification of the Proposed Scheme
In this part, we compare the proposed scheme with the interactive authentication mechanism in four aspects: authentication latency, handover latency, data latency, and multipath aggregation efficiency, so as to evaluate the performance of the proposed scheme:
Authentication latency is the time cost between the GW starting the authentication process and finishing the shared key agreement.
The time cost between the GW reacquiring the address, updating the binding with the CS, and re-negotiating the shared key is defined as handover latency.
Data latency is the time cost caused by the calculation and processing of the scheme
Multipath aggregation efficiency is the effect of the security scheme on bandwidth aggregation in heterogeneous networks.
The authentication and handover latency is an important indicator related to traffic safety for highly delay-sensitive IoV applications. Due to the impact of vehicle mobility and network heterogeneity, the packet loss rate and the delay of the link will greatly affect the authentication and handover process. The latency indicator evaluates the most-important impact of the security scheme in IoV applications. The ideal security mechanism should be able to efficiently complete authentication in the case of poor link status. The data transmission delay reflects the complexity of the security scheme to a certain extent, and the gap between different security schemes is mainly reflected in the calculation and processing delay. With the development of multimedia services in the IoV, the demand for network bandwidth is growing. The bandwidth aggregation efficiency reflects the impact of the security scheme on network transmission efficiency when the network load increases.
According to the related work, we selected the mechanism in [
15] as the representative of the interactive mechanism from the existing research. This work considered the authentication research in the mobile multihomed scenario, which is consistent with our research direction. For the noninteractive mechanism based on bilinear pairs, we selected the relevant latest research [
29] as a comparison. However, it does not involve the research on handover and multihomed support. According to its idea, we integrated it into our simulation environment to compare the authentication delay. The interactive scheme was expressed as INTERAC and the noninteractive scheme was named as SFVEC in [
29].
4.1. Network Topology for Simulation
To simulate mobile heterogeneous network scenarios, we designed a network topology, as shown in
Figure 10. The link parameters of three links were designed to simulate heterogeneous network scenarios, and the mobile switching scenarios were simulated through the GW switching at different access points. We constructed a multipath aggregation channel by building a virtual tunnel between the multi-interface GW and CS. The implementation of multipath transmission was realized through the Netfilter mechanism of the Linux kernel. We implemented packet interception and multipath scheduling by registering HOOK functions. The proposed authentication scheme uses the netlink mechanism to calculate and update the authentication key stored in the kernel. The scheduling policy was set to ECF by default. The Pairing-Based Cryptography (PBC) library was used to implement our security method. The pseudo-code of the scheme proposed is referred to Algorithms 1 and 2.
Figure 10.
Simulation of the mobile heterogeneous networks through the design of link parameters and IP switching.
Figure 10.
Simulation of the mobile heterogeneous networks through the design of link parameters and IP switching.
Algorithm 1 GW end. |
- 1:
functionConfig_Initialization() - 2:
Establishment (, ) - 3:
Global.Pk_CS(, ) - 4:
end function - 5:
functionNetwork_management () - 6:
while do - 7:
if linkupdateflag== then - 8:
Uplink.Sk_GW(, , ) - 9:
Uplink.sharekey(, ) - 10:
end if - 11:
end while - 12:
end function - 13:
functionData_processing () - 14:
while recv(GW_tun) do - 15:
Path_Selection() - 16:
Uplink.auth_header() - 17:
Uplink.data_send() - 18:
end while - 19:
end function
|
Algorithm 2 CS end. |
- 1:
functionConfig_Initialization () - 2:
Establishment (, ) - 3:
end function - 4:
functionData_processing () - 5:
while recv(CS_Uplink) do - 6:
Header_parsing() - 7:
if header.device_ID==LICENSED then - 8:
if header.device_ID==CONFIG then - 9:
if header.Interface_no==CONFIG then - 10:
if header.ADDRESS==ORIGINAL_ADDRESS then - 11:
if Uplink.auth()==1 then - 12:
Date.forward() - 13:
else - 14:
Date.discard() - 15:
end if - 16:
else - 17:
Uplink.sharekey() - 18:
end if - 19:
else - 20:
Uplink.loadserialno(, ) - 21:
end if - 22:
else - 23:
Uplink.loadGW(, , ) - 24:
end if - 25:
else - 26:
Data.discard() - 27:
end if - 28:
end while - 29:
end function
|
In the program loading phase, both the CS and GW run the CONFIG_INITIALIZATION () function to load the parameters required for the construction of the bilinear system, that is to complete the loading of the parameters , so that the security mechanism runs on the bilinear system with the same parameters.
At the GW end, the NETWORK_MANAGEMENT () thread detects the access status of the network adapter through the trigger mechanism, obtains the adapter information, including the serial number of the network adapter and the IP address, and calculates the corresponding private key through the bilinear operation combined with its own private key, SKGW. Thread DATA_PROCESSING processes the user packet to be transmitted. Firstly, the multipath scheduling function Path_Selection () selects the path to send. auth_header () calculates the corresponding key according to the selected network card to generate the authentication header. Finally, data_send () implements the construction and sending of the authentication packets.
At the CS end, the DATA_PROCESSING () thread calls the Header_parsing () function to parse the packet, checks the registration through the device ID, and checks the private key of the corresponding network adapter. If the packet of the corresponding network adapter is received for the first time, the corresponding key is generated according to the packet parsing parameters, through the auth () function, which checks the HMAC result of the packet header. If it passes the authentication, it receives the packet. Otherwise, it discards the packet.
In the process of our experimental setup, we set the parameters according to our team’s long-term research in the heterogeneous Internet of Vehicles. For the test research of the relevant realistic parameters, please refer to [
31]. In the experiment, we selected the range of delay and the packet loss rate under real conditions. The experimental results are of practical significance. In the selection of the authentication and handover delay, our delay range was 0-100ms. The setting of the packet loss rate fully considered the scenario of an extremely bad link environment.
Table 4 shows the range of the heterogeneous parameters under the general conditions of vehicle networks.
4.2. Authentication Latency
In order to fully evaluate the authentication latency of the proposed scheme in the heterogeneous network scenario of mobile multihoming devices, we replicated the high packet loss rate and significant link state variation features of mobile heterogeneous networks by adjusting the connection latency under various packet loss rate scenarios. From the results shown in
Figure 11, we concluded that, under the same loss rate, the authentication delay overhead of our scheme had a smaller slope than the interactive scheme. Under the same link delay, our scheme also had less delay overhead under different packet loss rates, and this advantage became more obvious as the link deteriorated. The delay reduction by the proposed scheme was attributed to two factors. Firstly, for the scenario with the same packet loss rate, compared with the two or more rounds of information interaction required by the interactive authentication mode, the noninteractive authentication feature of the proposed scheme resulted in a minor authentication delay. It increased positively with the increase of the link latency, but the interactive authentication overhead had a higher growth rate than the proposed scheme. Secondly, when considering the fixed delay and the change of the packet loss rate, with the increase of mutual information, the certificate and other schemes adopted in the interactive mode had higher bandwidth overhead, which led to a greater possibility of packet loss and a higher probability of packet loss. In order to establish a stateful security alliance, more timeout retransmission mechanisms will be triggered, resulting in a significant increase in overhead. However, the proposed scheme is a stateless mechanism triggered by packet forwarding. It will not cause the authentication establishment process to block normal data transmission.
4.3. Handover Latency
This study was solely concerned with the IP address swapping caused by mobility. In this part, we compared the MOBIKE extension of IKEV2 with the two switching modes of the proposed scheme in terms of handover delay performance.
Figure 12 shows the results. Since there was no interactive state transfer process, the transmission mode preserved the stateless properties of IP, thus reducing the switching overhead. At the same time, in the notification mode, compared with interactive handover, the proposed scheme uses noninteractive key agreement to reduce the number of interactive rounds, thus reducing the handover delay.
From the results shown in
Figure 12, we can see that, in the transmission mode, the performance of the handover delay of the proposed scheme was similar to that of the authentication delay shown in
Figure 11. This is because the noninteractive characteristics make the heavy key negotiation information required for handover be carried in the normal load communication process. Compared with the interactive mechanism, the amount of information required is greatly reduced, thus reducing the delay overhead, even in the notification mode. Our scheme had fewer interaction times than the interactive security federation state switching, and the delay overhead also had a smaller growth slope.
We provide statistics on the above authentication delay and handover delay data.
Table 4 shows the performance improvement in different scenarios. The numbers in the table represent the average latency reduction percentage brought by each process under different packet loss rate settings, and the entries represent two schemes for comparison.
4.4. Data Latency
In this part, we evaluate the calculation and processing costs of the proposed scheme. The proposed scheme and IKEv2 AH protocol used the SHA256 HMAC algorithm for comparison.
Table 5 displays the multilink state parameters used to simulate the heterogeneous multilink scenario.
We calculated the RTT delay of data by sending ping packets to the opposite CS. We compared three scenarios: using the proposed scheme, establishing the SA for the corresponding link in IKEv2 mode, and no authentication. The results are shown in
Figure 13. We can draw the conclusion that, in the case that the heterogeneous link characteristics of multipath will magnify the impact of computing and processing overhead on data transmission delay, the authentication mechanisms will bring different degrees of data latency, but the proposed scheme has less impact and latency fluctuation. According to the data statistics in
Figure 13, under the link setting as
Table 5, the data latency of the proposed mechanism was reduced by 4.17% compared with the other schemes.
To evaluate the overall delay advantage of the scheme, we conducted experiments in the IoV scenario with 1Hz as the data acquisition frequency according to the environmental settings in
Table 5. The proposed authentication scheme can effectively reduce the authentication delay and handover delay. Under the above environmental settings, the delay was reduced by 20.1% and 11.8%, respectively. More improvement will be brought if the data acquisition frequency increases.
4.5. Throughput
Finally, we evaluated the multipath aggregation efficiency of the proposed scheme. The significance of the multipath parallel transmission system is that it achieves the aggregation of heterogeneous resources and improves the transmission bandwidth. Therefore, the ideal security scheme should try to ensure aggregation efficiency under the premise of security. Bandwidth aggregation efficiency is greatly affected by the link state and scheduling strategy. In order to evaluate the aggregation efficiency of the security mechanism, we set the heterogeneous links to fluctuate between different link characteristics and adopted the theoretically optimal scheduling algorithm ECF. In order to compare the impact of the security mechanism on the system aggregation efficiency, we evaluated the aggregation efficiency under the maximum load. The heterogeneous link parameter settings are shown in
Table 5. We compared the UDP maximum theoretical bandwidth transmission between the GW and CS through iperf. The experimental results are shown in
Figure 14. The experimental results showed that the proposed scheme can bring higher bandwidth aggregation efficiency under the same load and scheduling strategy. According to the data statistics in
Figure 14, the throughput of the proposed scheme increased by 4.34% compared with the other scheme. The reason for this advantage is that the proposed scheme described in
Section 3 has a lower transmission delay. The lower transmission delay can better realize the aggregation of data packets in delay-based scheduling mechanisms such as ECF. In addition, in order to further analyze the reasons for the improvement of bandwidth efficiency, we calculated the phenomenon of packet disorder during transmission. The statistics of out-of-order packets are shown in
Figure 15. The results showed that the proposed scheme had fewer out-of-order packets, which improved the bandwidth aggregation efficiency of the scheduling strategy.