TY - JOUR
AU1 - Xu, Guishuang
AU2 - Yin, Xinchun
AU3 - Li, Xincheng
AB - 1 Introduction 1.1 Motivation The Internet of Vehicles (IoV) integrates advanced sensors and modern communication technology to optimize driving efficiency and solve traffic problems (e.g., traffic jams and frequent traffic accidents). In IoV, each vehicle is equipped with a wireless communication device called an on-board unit (OBU), which is used to communicate with other vehicles and roadside units (RSU). There are two communication modes in IoV, i.e., vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications [1]. According to cellular vehicle-to-everything (C-V2X) [2], vehicles broadcast real-time traffic information (e.g., location, speed, weather information, etc.) every 100 milliseconds. However, security threats and privacy disclosure are two obstacles hindering the application of IoV [3]. On the one hand, IoV is quite vulnerable to attacks due to open-access wireless channels. As the vehicles usually drive at high speed, if the attacker injects an attack instructions at the device terminal or cloud server (CS), it is likely to endanger the lives of drivers and passengers. On the other hand, the attacker can eavesdrop and sniff the transmitted traffic messages, which leads to serious disclosure of users’ privacy. Group key agreement (GKA) is one of the effective ways to solve the above problems, where vehicles beyond the group cannot send encrypted messages to group members [4]. Besides, it allows multiple group members to fairly negotiate a secret group key in open networks, which enables subsequent secure communications. Nevertheless, there are some shortcomings in existing GKA protocols. First, they cannot guarantee post-compromise security (PCS) due to the lack of an effective revocation mechanism, and the corrupted vehicles can update the group key all the time. Second, vehicles in the same group may collude with each other for more benefits. They would send malicious or fake messages to the group and disclose the group key to attackers, which seriously disturbs the communication security of the group [5]. Finally, vehicles and servers must remain online and conduct several interactions to rotate the group key. Since the rotation may be frequent, the process is extremely inefficient. In recent years, continuous group key agreement (CGKA) [6] has provided a powerful abstraction to reason on the above security requirements. CGKA implements group operations using O(log(n)) computation, communication, and storage with the TreeKEM protocol [7]. The propose-and-commit flow is employed to provide group key rotation for the next epoch. Therefore, the CGKA protocol achieves post-compromise forward security (PCFS) efficiently. It also achieves asynchronous decentralized group key management for large dynamic groups using a CS without disclosing group key information. However, the fundamental CGKA protocol cannot satisfy security and privacy-preserving properties in specific applications (e.g., traceability and privacy-preserving in IoV). Therefore, an efficient and robust continuous group key agreement (ER-CGKA) scheme extending Hashimoto et al.’s work [8] is proposed for IoV to provide asynchronous GKA and PCFS. The proposed ER-CGKA can not only inherit the advantages of CGKA but also satisfy the security and privacy-preserving requirements of the IoV. 1.2 Contribution The main contributions of the work are shown as follows. An efficient and robust continuous group key agreement (ER-CGKA) scheme is proposed to resist collusion attacks. The protocol extends a metadata-hidden CGKA scheme and provides robustness against collusion attacks among group users. Threshold cryptography is leveraged to guarantee that adversaries less than the threshold cannot disturb the group key management and threaten group communications. It is the first time that the CGKA protocol is applied to IoV to provide PCFS. In ER-CGKA, vehicles are distributed in a pool of pseudonyms to achieve privacy-preserving and traceability at the same time. Traffic management center (TMA) can recover the real identity of malicious vehicles through pseudonyms, while other entities cannot identify vehicles. The proposed ER-CGKA scheme is secure and efficient. Security analysis indicates that it satisfies all the fundamental security requirements like conditional privacy-preserving, confidentiality, unlinkability, PCFS, and resistance to collusion attacks. The performance analysis shows that ER-CGKA has low computation costs and communication overhead, which is suitable for resource-constrained IoV scenarios. The architecture of the work is shown as Fig 1. The functions of the work mainly include four parts. Prat one is conditional privacy-preserving and confidentiality, which is achieved by pseudonym technology and elliptic curve cryptography (ECC) assumption. Part two is the PCFS guaranteed by the treeKEM protocol. Part three is unlinkability, which is ensured by a batch of pseudonyms. Part four is the resistance to collusion attacks, based on a (k, n) secret-sharing scheme. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 1. The architecture of the work. https://doi.org/10.1371/journal.pone.0307867.g001 1.3 Organization The rest of the paper is organized as follows. Section 2 surveys the related work. In Section 3, preliminaries are introduced. In Section 4, the ER-CGKA scheme is presented in detail. Section 5 demonstrates the security proof and analysis under the random oracle model (ROM). The performance evaluation is given in Section 6. At last, we conclude the work in Section 7. 1.1 Motivation The Internet of Vehicles (IoV) integrates advanced sensors and modern communication technology to optimize driving efficiency and solve traffic problems (e.g., traffic jams and frequent traffic accidents). In IoV, each vehicle is equipped with a wireless communication device called an on-board unit (OBU), which is used to communicate with other vehicles and roadside units (RSU). There are two communication modes in IoV, i.e., vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications [1]. According to cellular vehicle-to-everything (C-V2X) [2], vehicles broadcast real-time traffic information (e.g., location, speed, weather information, etc.) every 100 milliseconds. However, security threats and privacy disclosure are two obstacles hindering the application of IoV [3]. On the one hand, IoV is quite vulnerable to attacks due to open-access wireless channels. As the vehicles usually drive at high speed, if the attacker injects an attack instructions at the device terminal or cloud server (CS), it is likely to endanger the lives of drivers and passengers. On the other hand, the attacker can eavesdrop and sniff the transmitted traffic messages, which leads to serious disclosure of users’ privacy. Group key agreement (GKA) is one of the effective ways to solve the above problems, where vehicles beyond the group cannot send encrypted messages to group members [4]. Besides, it allows multiple group members to fairly negotiate a secret group key in open networks, which enables subsequent secure communications. Nevertheless, there are some shortcomings in existing GKA protocols. First, they cannot guarantee post-compromise security (PCS) due to the lack of an effective revocation mechanism, and the corrupted vehicles can update the group key all the time. Second, vehicles in the same group may collude with each other for more benefits. They would send malicious or fake messages to the group and disclose the group key to attackers, which seriously disturbs the communication security of the group [5]. Finally, vehicles and servers must remain online and conduct several interactions to rotate the group key. Since the rotation may be frequent, the process is extremely inefficient. In recent years, continuous group key agreement (CGKA) [6] has provided a powerful abstraction to reason on the above security requirements. CGKA implements group operations using O(log(n)) computation, communication, and storage with the TreeKEM protocol [7]. The propose-and-commit flow is employed to provide group key rotation for the next epoch. Therefore, the CGKA protocol achieves post-compromise forward security (PCFS) efficiently. It also achieves asynchronous decentralized group key management for large dynamic groups using a CS without disclosing group key information. However, the fundamental CGKA protocol cannot satisfy security and privacy-preserving properties in specific applications (e.g., traceability and privacy-preserving in IoV). Therefore, an efficient and robust continuous group key agreement (ER-CGKA) scheme extending Hashimoto et al.’s work [8] is proposed for IoV to provide asynchronous GKA and PCFS. The proposed ER-CGKA can not only inherit the advantages of CGKA but also satisfy the security and privacy-preserving requirements of the IoV. 1.2 Contribution The main contributions of the work are shown as follows. An efficient and robust continuous group key agreement (ER-CGKA) scheme is proposed to resist collusion attacks. The protocol extends a metadata-hidden CGKA scheme and provides robustness against collusion attacks among group users. Threshold cryptography is leveraged to guarantee that adversaries less than the threshold cannot disturb the group key management and threaten group communications. It is the first time that the CGKA protocol is applied to IoV to provide PCFS. In ER-CGKA, vehicles are distributed in a pool of pseudonyms to achieve privacy-preserving and traceability at the same time. Traffic management center (TMA) can recover the real identity of malicious vehicles through pseudonyms, while other entities cannot identify vehicles. The proposed ER-CGKA scheme is secure and efficient. Security analysis indicates that it satisfies all the fundamental security requirements like conditional privacy-preserving, confidentiality, unlinkability, PCFS, and resistance to collusion attacks. The performance analysis shows that ER-CGKA has low computation costs and communication overhead, which is suitable for resource-constrained IoV scenarios. The architecture of the work is shown as Fig 1. The functions of the work mainly include four parts. Prat one is conditional privacy-preserving and confidentiality, which is achieved by pseudonym technology and elliptic curve cryptography (ECC) assumption. Part two is the PCFS guaranteed by the treeKEM protocol. Part three is unlinkability, which is ensured by a batch of pseudonyms. Part four is the resistance to collusion attacks, based on a (k, n) secret-sharing scheme. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 1. The architecture of the work. https://doi.org/10.1371/journal.pone.0307867.g001 1.3 Organization The rest of the paper is organized as follows. Section 2 surveys the related work. In Section 3, preliminaries are introduced. In Section 4, the ER-CGKA scheme is presented in detail. Section 5 demonstrates the security proof and analysis under the random oracle model (ROM). The performance evaluation is given in Section 6. At last, we conclude the work in Section 7. 2 Related work 2.1 Synchronous group key agreement Many synchronous GKA protocols for IoV have been proposed to construct secure vehicular communications. Since all vehicles in the group should contribute to the new group key, several rounds of interactions between them are necessary. Though Boneh and Silverberg [9] leveraged the military mapping technique to reduce it to one round, the computation cost is high, and an additional round of communication is required for key authentication. Meanwhile, Hu et al. [10] pointed out that military mapping is insecure, which requires all group members to be online at the same time. However, it is unrealistic due to the time difference that exists among group members. The authenticated key agreement (AKA) schemes are proposed to ensure message transmission security and the privacy of vehicles. Canetti and Krawczyk [11] pointed out that a secure key agreement protocol can be designed with a session key security algorithm, symmetric encryption algorithm, and authentication algorithm. Dua et al. [12] devised a lightweight AKA scheme based on ECC. However, a trusted cluster vehicle is required in their scheme, and the group key updates are not considered. Islam et al. [13] designed an AKA scheme based on a finite field without ECC or bilinear pairing (BP) operation. However, their scheme has some shortcomings. First, TMA needs to be online during group key updates and unicast the new group key to each vehicle, which is inefficient and has poor application. Then, it simply performs the “XOR” operation on the updated key and the old key to complete the encryption operation of the new group key, and the encrypted updated key is exposed in the public channel. Therefore, the vehicle that has been removed from the group can still compute the updated key. Ma et al. [14] devised an AKA scheme based on fog computing and proved its security under the ROM, but the costs of computation and communication are still high. Cui et al. [15] proposed an AKA scheme under the multi-cloud environment based on ECC. Although the computational efficiency has improved since not using BP, single-TMA makes the scheme vulnerable to denial of service (DoS) attacks. Wei et al. [16] raised a lightweight AKA scheme supporting conditional privacy-preserving based on the multi-TMA model, which employed the technologies of Lagrange interpolation theorem, symmetric encryption, hash function, and pseudorandom function (PRF). Their scheme can resist DoS attacks to some extent but relies on trusted TMA to perform group authentication. In 2014, Karuppiah et al. [17] proposed a secure remote user mutual authentication scheme using smart cards, which enables the user to choose his/her password freely and renew the password anytime. Based on Chinese remainder theorem, Vijayakumar et al. [18] designed a centralized dynamic group key management for secure multicast communication. The the computation complexity of the key server is reduced to O(1). In 2015, Vijayakumar et al. [19] proposed a dual AKA technique for secure data transmission in vehicular ad hoc networks (VANET), adding or revoking users in the VANET group can be performed in a computationally efficient manner by updating a small amount of information. For secure authentication in global mobility networks, Karuppiah et al. [20] designed an anonymous authentication scheme for roaming service, providing perfect forward secrecy and detect wrong passwords quickly. In 2016, Karuppiah et al. [21] put forward a lightweight authentication scheme with user anonymity, providing local password verification, and resisting replay attacks. In 2017, Karuppiah et al. [22] proposed a dynamic ID-based generic framework for an anonymous authentication scheme, which offers the user anonymity, password change, updating option, and quick detection of wrong password. In 2023, Tan et al. [23] designed an AKA scheme for UAV-assisted infrastructure-less IoV. They deployed the tethered UAV (TUAV) as the specific mobilized base station so that the active edge IoV infrastructure is not needed. Based on chaotic maps, Zhang et al. [24] proposed a sustainable AKA protocol for industry 5.0, which can achieve secure authentication among consumers, gateway nodes, and Internet of Things-based consumer electronics and generate session keys. To decrease the frequent interaction of vehicles with the TMA, Saleem et al. [25] proposed a secure access control protocol with conditional privacy for VANET, which does not require the TMA’s involvement during authentication between vehicles and RSUs. Soon after, a privacy-preserving AKA protocol for VANET using the hashing technique was proposed [26], which provides an efficient and secure data transmission mechanism over a public communication channel. Mahmood et al. [27] developed a key agreement solution for mobile users to realize mutual authentication in a single round. Their protocol offers user anonymity and prevents physical attacks by physically unclonable functions. This year, Manickam et al. [28] designed a three-factor mutual authentication scheme for telecare medical information system based on ECC, which protects sensitive patient data from getting out during communication and protects against different types of security attacks. Saleem et al. [29] designed a hash-based authentication scheme, which effectively combines identity, password, and bio-metric to enhance resistance against impersonation, denial of service, and privileged insider attacks. Gautam et al. [30] suggested a blockchain-based authentication framework for intra-twin and inter-twin communication in vehicular digital twin networks and the integrated blockchain in the system assures data compactness and verifiability. Since all vehicles in the group should contribute to the new group key, several rounds of interactions between group members are necessary. Therefore, the synchronous group key agreement schemes have rigorous requirements for latency and robustness of IoV. 2.2 Asynchronous continuous group key agreement To improve communication efficiency and achieve PCFS, the CGKA protocols are proposed. In 2019, Weidner et al. [31] raised that updating randomized key information instead of overwriting, cannot achieve forward security (FS) and lacks formal security proof. In 2020, Alwen et al. [6] analyzed the TreeKEM [7] scheme and pointed out that it cannot satisfy PCFS security requirements. Then, they first proposed the concept of CGKA, which achieves key updates that are invisible to CS in different states with a renewable encryption technique. However, neither of their models supports concurrency, nor prevents message injection by malicious attackers. Later, a stronger adversary model was put forward and the concept of real-or-random was first introduced [32]. The definition in [32] gives the attacker the ability to be highly adaptable and fully proactive, corrupting any participant, and even arbitrarily setting the random numbers required for key agreement. Simultaneously, the robustness of CGKA is improved with zero-knowledge proofs (ZKP). In 2021, Klein et al. [33] first proposed a CGKA protocol that can guard against adaptive adversaries. Soon after, the history graph [34] was invoked to describe the syntax of CGKA and first provides a black box structure for secure group message transmission of CGKA. Then, Hashimoto et al. [35] and Alwen et al. [36] optimize the formal definition to achieve a CGKA protocol with CS support. If a user wants to update the group key, they have to generate the corresponding message and broadcast it to all other users with the help of CS. In large groups, the bandwidth requirements and computation costs are huge due to having users update keys sequentially. Weidner et al. [37] proposed a decentralized CGKA protocol with strong security guarantees, which realizes the linear complexity of communication. Recently, Hashimoto et al. [8] provided a simple and generic wrapper protocol that upgrades non-metadata-hiding CGKAs into metadata-hiding CGKAs. They leverage the existence of a unique continuously evolving group secret key shared among the group members, which is used to convince CS anonymously that a user is a legitimate group member. Based on the above research, we applied the CGKA protocol to IoV and proposed the ER-CGKA scheme. It aims to ensure a secure message transmission over public channels, protect the privacy of vehicles, and improve the efficiency of the group key updates. 2.1 Synchronous group key agreement Many synchronous GKA protocols for IoV have been proposed to construct secure vehicular communications. Since all vehicles in the group should contribute to the new group key, several rounds of interactions between them are necessary. Though Boneh and Silverberg [9] leveraged the military mapping technique to reduce it to one round, the computation cost is high, and an additional round of communication is required for key authentication. Meanwhile, Hu et al. [10] pointed out that military mapping is insecure, which requires all group members to be online at the same time. However, it is unrealistic due to the time difference that exists among group members. The authenticated key agreement (AKA) schemes are proposed to ensure message transmission security and the privacy of vehicles. Canetti and Krawczyk [11] pointed out that a secure key agreement protocol can be designed with a session key security algorithm, symmetric encryption algorithm, and authentication algorithm. Dua et al. [12] devised a lightweight AKA scheme based on ECC. However, a trusted cluster vehicle is required in their scheme, and the group key updates are not considered. Islam et al. [13] designed an AKA scheme based on a finite field without ECC or bilinear pairing (BP) operation. However, their scheme has some shortcomings. First, TMA needs to be online during group key updates and unicast the new group key to each vehicle, which is inefficient and has poor application. Then, it simply performs the “XOR” operation on the updated key and the old key to complete the encryption operation of the new group key, and the encrypted updated key is exposed in the public channel. Therefore, the vehicle that has been removed from the group can still compute the updated key. Ma et al. [14] devised an AKA scheme based on fog computing and proved its security under the ROM, but the costs of computation and communication are still high. Cui et al. [15] proposed an AKA scheme under the multi-cloud environment based on ECC. Although the computational efficiency has improved since not using BP, single-TMA makes the scheme vulnerable to denial of service (DoS) attacks. Wei et al. [16] raised a lightweight AKA scheme supporting conditional privacy-preserving based on the multi-TMA model, which employed the technologies of Lagrange interpolation theorem, symmetric encryption, hash function, and pseudorandom function (PRF). Their scheme can resist DoS attacks to some extent but relies on trusted TMA to perform group authentication. In 2014, Karuppiah et al. [17] proposed a secure remote user mutual authentication scheme using smart cards, which enables the user to choose his/her password freely and renew the password anytime. Based on Chinese remainder theorem, Vijayakumar et al. [18] designed a centralized dynamic group key management for secure multicast communication. The the computation complexity of the key server is reduced to O(1). In 2015, Vijayakumar et al. [19] proposed a dual AKA technique for secure data transmission in vehicular ad hoc networks (VANET), adding or revoking users in the VANET group can be performed in a computationally efficient manner by updating a small amount of information. For secure authentication in global mobility networks, Karuppiah et al. [20] designed an anonymous authentication scheme for roaming service, providing perfect forward secrecy and detect wrong passwords quickly. In 2016, Karuppiah et al. [21] put forward a lightweight authentication scheme with user anonymity, providing local password verification, and resisting replay attacks. In 2017, Karuppiah et al. [22] proposed a dynamic ID-based generic framework for an anonymous authentication scheme, which offers the user anonymity, password change, updating option, and quick detection of wrong password. In 2023, Tan et al. [23] designed an AKA scheme for UAV-assisted infrastructure-less IoV. They deployed the tethered UAV (TUAV) as the specific mobilized base station so that the active edge IoV infrastructure is not needed. Based on chaotic maps, Zhang et al. [24] proposed a sustainable AKA protocol for industry 5.0, which can achieve secure authentication among consumers, gateway nodes, and Internet of Things-based consumer electronics and generate session keys. To decrease the frequent interaction of vehicles with the TMA, Saleem et al. [25] proposed a secure access control protocol with conditional privacy for VANET, which does not require the TMA’s involvement during authentication between vehicles and RSUs. Soon after, a privacy-preserving AKA protocol for VANET using the hashing technique was proposed [26], which provides an efficient and secure data transmission mechanism over a public communication channel. Mahmood et al. [27] developed a key agreement solution for mobile users to realize mutual authentication in a single round. Their protocol offers user anonymity and prevents physical attacks by physically unclonable functions. This year, Manickam et al. [28] designed a three-factor mutual authentication scheme for telecare medical information system based on ECC, which protects sensitive patient data from getting out during communication and protects against different types of security attacks. Saleem et al. [29] designed a hash-based authentication scheme, which effectively combines identity, password, and bio-metric to enhance resistance against impersonation, denial of service, and privileged insider attacks. Gautam et al. [30] suggested a blockchain-based authentication framework for intra-twin and inter-twin communication in vehicular digital twin networks and the integrated blockchain in the system assures data compactness and verifiability. Since all vehicles in the group should contribute to the new group key, several rounds of interactions between group members are necessary. Therefore, the synchronous group key agreement schemes have rigorous requirements for latency and robustness of IoV. 2.2 Asynchronous continuous group key agreement To improve communication efficiency and achieve PCFS, the CGKA protocols are proposed. In 2019, Weidner et al. [31] raised that updating randomized key information instead of overwriting, cannot achieve forward security (FS) and lacks formal security proof. In 2020, Alwen et al. [6] analyzed the TreeKEM [7] scheme and pointed out that it cannot satisfy PCFS security requirements. Then, they first proposed the concept of CGKA, which achieves key updates that are invisible to CS in different states with a renewable encryption technique. However, neither of their models supports concurrency, nor prevents message injection by malicious attackers. Later, a stronger adversary model was put forward and the concept of real-or-random was first introduced [32]. The definition in [32] gives the attacker the ability to be highly adaptable and fully proactive, corrupting any participant, and even arbitrarily setting the random numbers required for key agreement. Simultaneously, the robustness of CGKA is improved with zero-knowledge proofs (ZKP). In 2021, Klein et al. [33] first proposed a CGKA protocol that can guard against adaptive adversaries. Soon after, the history graph [34] was invoked to describe the syntax of CGKA and first provides a black box structure for secure group message transmission of CGKA. Then, Hashimoto et al. [35] and Alwen et al. [36] optimize the formal definition to achieve a CGKA protocol with CS support. If a user wants to update the group key, they have to generate the corresponding message and broadcast it to all other users with the help of CS. In large groups, the bandwidth requirements and computation costs are huge due to having users update keys sequentially. Weidner et al. [37] proposed a decentralized CGKA protocol with strong security guarantees, which realizes the linear complexity of communication. Recently, Hashimoto et al. [8] provided a simple and generic wrapper protocol that upgrades non-metadata-hiding CGKAs into metadata-hiding CGKAs. They leverage the existence of a unique continuously evolving group secret key shared among the group members, which is used to convince CS anonymously that a user is a legitimate group member. Based on the above research, we applied the CGKA protocol to IoV and proposed the ER-CGKA scheme. It aims to ensure a secure message transmission over public channels, protect the privacy of vehicles, and improve the efficiency of the group key updates. 3 Preliminary knowledge 3.1 Notations Table 1 shows the main notations and descriptions in the ER-CGKA scheme. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 1. The main notations and descriptions. https://doi.org/10.1371/journal.pone.0307867.t001 3.2 System model The system model of our scheme is shown in Fig 2, which includes four entities. Vehicle. The vehicle is the main participant in performing group key agreements. It is responsible for creating groups, uploading proposals, generating and processing commits, and updating group keys. Vehicles are incredible since they may be comprised or collude with each other. RSU. A semi-trusted RSU is an infrastructure installed along roadsides, which assists vehicles in group key agreements and provides communication transfer services. Although the RSU can perform the protocol honestly, it may record the transmitted data due to curiosity and snoop on the privacy of the vehicle. TMA. TMA is a powerful traffic management center. It is responsible for system initialization, pseudonym generation, and key distribution. TMA can retrieve the real identities of malicious vehicles and publish them. TMA is totally credible because it controls the construction and operation of the system. CS. CS is the semi-trusted third party that stores the group information, proposals, and commits and informs vehicles to update the group key. Although CS performs the protocol frankly, it tries to snoop on the stored data and identities of vehicles. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 2. System model of the ER-CGKA scheme. https://doi.org/10.1371/journal.pone.0307867.g002 3.3 Security requirements Correctness. All group vehicles have the same group key and state at every same epoch. Conditional privacy-preserving. Apart from TMA, the real identities of vehicles are anonymous for other entities. Confidentiality. The group key is secret to any entity other than the group members. Unlinkability. CS cannot link to two or more proposals or commits that are uploaded or downloaded by the same vehicles. PCFS. Although the current group key is disclosed, attackers cannot obtain the previous and subsequent group keys. In other words, the group key at each epoch is incalculable for attackers. Robustness to collusion attacks. Suppose there are n vehicles in the group, the group key updates only when at least k vehicles commit the same proposal. 3.4 PRF & PRP Pseudorandom function (PRF). Define function F: {0, 1}* × {0, 1}* → {0, 1}*, for adversaries in probability polynomial time (PPT), if holds, function F is a PRF. Input key k ∈ K and binary string x ∈ X, PRF performs y = PRF(k, x) and outputs y ∈ Y and y is indistinguishable for adversaries in PPT. Pseudorandom permutation (PRP). Define function P:{0, 1} * × {0, 1} * → {0, 1}*, for adversaries in PPT, if holds, function P is a strong PRP. 3.5 Syntax of metadata-hidden CGKA The syntax of metadata-hidden CGKA is given according to [8], where we assume id is the executing party and omit it from the input. Group Creation (Create): Initialize a new group state and take party id as the only member. Proposals (Propose, act)→p: Input action ‘act’ which can be ‘add’-idt (adding idt), ‘rem’-idt (removing idt) or ‘upd’ (updating the key material of idt), output a proposal p. Commit (commit,): Commit a vector of proposals , output commit . c0 is a member-independent commit, while is a member-dependent commit list, where is equal to the current group size. If contains a ‘add’ proposal, then it outputs a welcome message , where idt is the added member. Process (Process,c0,,): Process commit with the associated proposals , move the id’s group state into next epoch. Join (Join,): The added member id can join group with welcome message and its group state is synced with any member who processes the commit made at the same epoch. Key (Key)→K: Output the current group secret key K. 3.1 Notations Table 1 shows the main notations and descriptions in the ER-CGKA scheme. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 1. The main notations and descriptions. https://doi.org/10.1371/journal.pone.0307867.t001 3.2 System model The system model of our scheme is shown in Fig 2, which includes four entities. Vehicle. The vehicle is the main participant in performing group key agreements. It is responsible for creating groups, uploading proposals, generating and processing commits, and updating group keys. Vehicles are incredible since they may be comprised or collude with each other. RSU. A semi-trusted RSU is an infrastructure installed along roadsides, which assists vehicles in group key agreements and provides communication transfer services. Although the RSU can perform the protocol honestly, it may record the transmitted data due to curiosity and snoop on the privacy of the vehicle. TMA. TMA is a powerful traffic management center. It is responsible for system initialization, pseudonym generation, and key distribution. TMA can retrieve the real identities of malicious vehicles and publish them. TMA is totally credible because it controls the construction and operation of the system. CS. CS is the semi-trusted third party that stores the group information, proposals, and commits and informs vehicles to update the group key. Although CS performs the protocol frankly, it tries to snoop on the stored data and identities of vehicles. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 2. System model of the ER-CGKA scheme. https://doi.org/10.1371/journal.pone.0307867.g002 3.3 Security requirements Correctness. All group vehicles have the same group key and state at every same epoch. Conditional privacy-preserving. Apart from TMA, the real identities of vehicles are anonymous for other entities. Confidentiality. The group key is secret to any entity other than the group members. Unlinkability. CS cannot link to two or more proposals or commits that are uploaded or downloaded by the same vehicles. PCFS. Although the current group key is disclosed, attackers cannot obtain the previous and subsequent group keys. In other words, the group key at each epoch is incalculable for attackers. Robustness to collusion attacks. Suppose there are n vehicles in the group, the group key updates only when at least k vehicles commit the same proposal. 3.4 PRF & PRP Pseudorandom function (PRF). Define function F: {0, 1}* × {0, 1}* → {0, 1}*, for adversaries in probability polynomial time (PPT), if holds, function F is a PRF. Input key k ∈ K and binary string x ∈ X, PRF performs y = PRF(k, x) and outputs y ∈ Y and y is indistinguishable for adversaries in PPT. Pseudorandom permutation (PRP). Define function P:{0, 1} * × {0, 1} * → {0, 1}*, for adversaries in PPT, if holds, function P is a strong PRP. 3.5 Syntax of metadata-hidden CGKA The syntax of metadata-hidden CGKA is given according to [8], where we assume id is the executing party and omit it from the input. Group Creation (Create): Initialize a new group state and take party id as the only member. Proposals (Propose, act)→p: Input action ‘act’ which can be ‘add’-idt (adding idt), ‘rem’-idt (removing idt) or ‘upd’ (updating the key material of idt), output a proposal p. Commit (commit,): Commit a vector of proposals , output commit . c0 is a member-independent commit, while is a member-dependent commit list, where is equal to the current group size. If contains a ‘add’ proposal, then it outputs a welcome message , where idt is the added member. Process (Process,c0,,): Process commit with the associated proposals , move the id’s group state into next epoch. Join (Join,): The added member id can join group with welcome message and its group state is synced with any member who processes the commit made at the same epoch. Key (Key)→K: Output the current group secret key K. 4 The ER-CGKA scheme The main procedure of the ER-CGKA scheme is shown in Fig 3, which contains three parts: System Initialization, Entity Registration and CGKA. Part ① is System Initialization, TMA generates its public-private key pairs, and broadcasts system public parameters to RSUs and vehicles. Part ② is Entity Registration, TMA generates pseudonyms for vehicles and distributes private keys for RSUs. Part ③ is CGKA, which is the core of the ER-CGKA scheme. It includes five stages: group creation, proposals, commit, join, and process & key. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 3. The main procedure of the ER-CGKA scheme. https://doi.org/10.1371/journal.pone.0307867.g003 4.1 System initialization At this stage, TMA generates its private key and system public parameters. The steps are as follows. (1) Input secure parameter λ, choose an additive cyclic group with order q, where P is the generator of . (2) Randomly choose as its private key and keep it in secret, set public key Tpub = aP. (3) Choose one secure one-way hash function: . (4) Publish the system public parameters . 4.2 Entity registration 4.2.1 Vehicle registration. At this stage, vehicle Vi asks TMA for a registration. In the IoV system, a pool of pseudonyms is necessary to protect the identity privacy of the vehicle. The steps are as follows. (1) Vi randomly chooses , computes Xi = xiP, transmits registration request {Xi, RIDi, n} to TMA via secure channels, where n denotes the number of requested pseudonyms. (2) After receiving {Xi, RIDi, n}, for j = 1, 2, …, n, TMA computes h1i = H1(aXi||Ti,j), Qi,j = RIDi ⊕ h1i, PIDi,j = {Qi,j, Ti,j}, sets pseudonyms PID = {PIDi,1, PIDi,2, …, PIDi,n}, and sends PID to Vi through secure channels, where Ti,j is the valid period of PIDi,j. (3) Upon receiving PID, Vi stores them to OBU. 4.2.2 RSU registration. At this stage, TMA generate public-private key pairs for RSUj. The steps are as follows. (1) RSUj transmits its real identity to the TMA through the secure channel. (2) TMA randomly chooses , computes , and sends to RSUj. (3) RSUj keeps in secret and broadcasts to surrounding vehicles. 4.3 Continuous group key agreement In the CGKA protocol, all the vehicles in a group need to store the group identifier gid, the current epoch of the group, the current group key, and information to identify the current members. Additionally, each vehicle stores a public key (called key material) whose corresponding secret key is known only to themselves. A three-part box representing the group state at a given epoch is stored on CS. As is shown in Fig 4, the top box stores the group identifier gid, epoch, and the group statement gvki. The middle box stores the encrypted proposals created during the epoch. The bottom box stores the encrypted commit message that concluded this epoch. Fig 5 shows the process of CGKA in our ER-CGKA scheme. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. The database (DB) stored on CS. https://doi.org/10.1371/journal.pone.0307867.g004 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 5. The process of ER-CGKA. https://doi.org/10.1371/journal.pone.0307867.g005 4.3.1 Group creation. Assume that V1 hopes to create a group containing n members. It first registers a new group that only includes itself to CS. The steps are as follows. (1) Input (Create), initiate a new group identifier gid and group key K0, epoch = 0. (2) Generate group specific authentication key (gvk0, gsk0) with the group key K0 and some authentication information. (3) Send (gvk0, gid) to CS. (4) CS stores (gvk0, gid) into the DB. 4.3.2 Proposals. CS generates a random challenge chi ← {0, 1}λ and transmits it to Vi before it uploads the proposals. The steps are as follows. (1) Vi inputs (Propose, ‘act-PIDi,j’), creates a proposal pi, where ‘act’ ∈ add, rem, upd, represents addition or removal of vehicle PIDi,j, and update of key materials, respectively. (2) Vi generates signature σi with gski, uploads {σi, pi, PID1j} to CS. (3) CS stores {pi, PIDi,j} into DB after checking the validity of σi with gvki. Add group member PIDi,j: , propose to add a new vehicle PIDi,j to the current group. Input group state, the PIDi,j of new vehicle and its public key, output an updated group state and an addition proposal message. Fig 6 shows the key agreement for new vehicles joining. Assume that there are five vehicles in the current group, V1 proposes to add vehicle V6 to the group. Remove group member PIDi,j: , propose to remove a vehicle PIDi,j from current group. Input group state, the PIDi,j of target vehicle, output an updated group state and a removal proposal message. Fig 7 shows the key agreement for old vehicles leaving. Assume that V1 proposes to remove vehicle V3 from the group. Update key material: , propose to update the key materials of vehicles. Input group state, output an updated group state and an update proposal message. Fig 8 shows the group key agreement for the key materials update. Assume that V2 updates its new key as . Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 6. The key agreement for new vehicle joining. https://doi.org/10.1371/journal.pone.0307867.g006 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 7. The key agreement for old vehicle leaving. https://doi.org/10.1371/journal.pone.0307867.g007 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 8. The key agreement for key materials update. https://doi.org/10.1371/journal.pone.0307867.g008 4.3.3 Commit. To update the group state, Vi(i = 1, 2, …, n) download pi to commit. The steps are as follows. Initial commit phase. Vehicle Vj performs the following algorithms. (1) Input (Commit, pi), generate a commit . The welcome message is depended on if there is an additional proposal message in . (2) Generate new group authentication key (gvki, gski). (3) Inform vehicles that it has generated the commit and gvki. (4) Generate PRP key , which defined the permutation on group size. (5) Create a permuted member dependent commit so that is placed at entry PRP(permKey, i) ∈ [1, 2, …, n]. Message construction phase. Vehicles Vi(i = 1, 2, …, n) perform the following algorithms. (1) Execute step (4) in Initial commit phase except Vj. (2) Operate the VOPRF protocol [38], input permKey, output zi. (3) Parse zi into three parts (zi,1, zi,2, zi,3) ∈ {0, 1}λ × {0, 1}λ × {0, 1}λ. (4) Construct a random share si of zi,1 using a (k, n) secret-sharing scheme [39], where zi,2 is used in the share generation process. (5) Derive a temporary symmetry key TKi using a pseudorandom generator, where takes zi,1 as input. (6) Encrypt PIDi,j with TKi to obtain cyphertext CTi. (7) Vj uploads to CS after performing an authentication with gski, while other vehicles uploads {CTi, si, zi,3}. Aggregation phase. CS performs the following algorithms. (1) Group together messages that share the same zi,3 vale into subset Ui. (2) Run the share recovery algorithm on the collections of share values {si}i = 1, …k ∈ Ui to output zi,1. (3) Derive a temporary symmetry key TKi takes zi,1 as input. (4) Decrypt CTi with TKi to obtain PIDi,j. (5) Store into DB and create list Li to store {PID1,j, PID2,j, …, PIDk,j}. 4.3.4 Join. It is worth noting that the added vehicle PIDi,j can join in group using welcome message if ‘act’ = add. (1) After V1 uploading , CS stores into a specific DB, where works similarly to the . (2) Vi(i = 1, 2, …, n) performs authentication protocol to retrieve in the DB of CS. Input (Join, ), the state of PIDi,j is synced with any member who processes the commit made at the same epoch. 4.3.5 Process & Key. Once there are k elements in Li, CS broadcasts to all vehicles. Then, Vi(i = 1, 2, …, n) retrieves and processes commit corresponding to themselves. Steps are as follows. (1) Generate permKey = PRF (Ki−1,′ pi′), compute the permuted index = PRP (permKey, i). (2) Retrieve from with index. (3) Input , move to the next epoch and generate the new group key Ki. 4.1 System initialization At this stage, TMA generates its private key and system public parameters. The steps are as follows. (1) Input secure parameter λ, choose an additive cyclic group with order q, where P is the generator of . (2) Randomly choose as its private key and keep it in secret, set public key Tpub = aP. (3) Choose one secure one-way hash function: . (4) Publish the system public parameters . 4.2 Entity registration 4.2.1 Vehicle registration. At this stage, vehicle Vi asks TMA for a registration. In the IoV system, a pool of pseudonyms is necessary to protect the identity privacy of the vehicle. The steps are as follows. (1) Vi randomly chooses , computes Xi = xiP, transmits registration request {Xi, RIDi, n} to TMA via secure channels, where n denotes the number of requested pseudonyms. (2) After receiving {Xi, RIDi, n}, for j = 1, 2, …, n, TMA computes h1i = H1(aXi||Ti,j), Qi,j = RIDi ⊕ h1i, PIDi,j = {Qi,j, Ti,j}, sets pseudonyms PID = {PIDi,1, PIDi,2, …, PIDi,n}, and sends PID to Vi through secure channels, where Ti,j is the valid period of PIDi,j. (3) Upon receiving PID, Vi stores them to OBU. 4.2.2 RSU registration. At this stage, TMA generate public-private key pairs for RSUj. The steps are as follows. (1) RSUj transmits its real identity to the TMA through the secure channel. (2) TMA randomly chooses , computes , and sends to RSUj. (3) RSUj keeps in secret and broadcasts to surrounding vehicles. 4.2.1 Vehicle registration. At this stage, vehicle Vi asks TMA for a registration. In the IoV system, a pool of pseudonyms is necessary to protect the identity privacy of the vehicle. The steps are as follows. (1) Vi randomly chooses , computes Xi = xiP, transmits registration request {Xi, RIDi, n} to TMA via secure channels, where n denotes the number of requested pseudonyms. (2) After receiving {Xi, RIDi, n}, for j = 1, 2, …, n, TMA computes h1i = H1(aXi||Ti,j), Qi,j = RIDi ⊕ h1i, PIDi,j = {Qi,j, Ti,j}, sets pseudonyms PID = {PIDi,1, PIDi,2, …, PIDi,n}, and sends PID to Vi through secure channels, where Ti,j is the valid period of PIDi,j. (3) Upon receiving PID, Vi stores them to OBU. 4.2.2 RSU registration. At this stage, TMA generate public-private key pairs for RSUj. The steps are as follows. (1) RSUj transmits its real identity to the TMA through the secure channel. (2) TMA randomly chooses , computes , and sends to RSUj. (3) RSUj keeps in secret and broadcasts to surrounding vehicles. 4.3 Continuous group key agreement In the CGKA protocol, all the vehicles in a group need to store the group identifier gid, the current epoch of the group, the current group key, and information to identify the current members. Additionally, each vehicle stores a public key (called key material) whose corresponding secret key is known only to themselves. A three-part box representing the group state at a given epoch is stored on CS. As is shown in Fig 4, the top box stores the group identifier gid, epoch, and the group statement gvki. The middle box stores the encrypted proposals created during the epoch. The bottom box stores the encrypted commit message that concluded this epoch. Fig 5 shows the process of CGKA in our ER-CGKA scheme. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 4. The database (DB) stored on CS. https://doi.org/10.1371/journal.pone.0307867.g004 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 5. The process of ER-CGKA. https://doi.org/10.1371/journal.pone.0307867.g005 4.3.1 Group creation. Assume that V1 hopes to create a group containing n members. It first registers a new group that only includes itself to CS. The steps are as follows. (1) Input (Create), initiate a new group identifier gid and group key K0, epoch = 0. (2) Generate group specific authentication key (gvk0, gsk0) with the group key K0 and some authentication information. (3) Send (gvk0, gid) to CS. (4) CS stores (gvk0, gid) into the DB. 4.3.2 Proposals. CS generates a random challenge chi ← {0, 1}λ and transmits it to Vi before it uploads the proposals. The steps are as follows. (1) Vi inputs (Propose, ‘act-PIDi,j’), creates a proposal pi, where ‘act’ ∈ add, rem, upd, represents addition or removal of vehicle PIDi,j, and update of key materials, respectively. (2) Vi generates signature σi with gski, uploads {σi, pi, PID1j} to CS. (3) CS stores {pi, PIDi,j} into DB after checking the validity of σi with gvki. Add group member PIDi,j: , propose to add a new vehicle PIDi,j to the current group. Input group state, the PIDi,j of new vehicle and its public key, output an updated group state and an addition proposal message. Fig 6 shows the key agreement for new vehicles joining. Assume that there are five vehicles in the current group, V1 proposes to add vehicle V6 to the group. Remove group member PIDi,j: , propose to remove a vehicle PIDi,j from current group. Input group state, the PIDi,j of target vehicle, output an updated group state and a removal proposal message. Fig 7 shows the key agreement for old vehicles leaving. Assume that V1 proposes to remove vehicle V3 from the group. Update key material: , propose to update the key materials of vehicles. Input group state, output an updated group state and an update proposal message. Fig 8 shows the group key agreement for the key materials update. Assume that V2 updates its new key as . Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 6. The key agreement for new vehicle joining. https://doi.org/10.1371/journal.pone.0307867.g006 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 7. The key agreement for old vehicle leaving. https://doi.org/10.1371/journal.pone.0307867.g007 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 8. The key agreement for key materials update. https://doi.org/10.1371/journal.pone.0307867.g008 4.3.3 Commit. To update the group state, Vi(i = 1, 2, …, n) download pi to commit. The steps are as follows. Initial commit phase. Vehicle Vj performs the following algorithms. (1) Input (Commit, pi), generate a commit . The welcome message is depended on if there is an additional proposal message in . (2) Generate new group authentication key (gvki, gski). (3) Inform vehicles that it has generated the commit and gvki. (4) Generate PRP key , which defined the permutation on group size. (5) Create a permuted member dependent commit so that is placed at entry PRP(permKey, i) ∈ [1, 2, …, n]. Message construction phase. Vehicles Vi(i = 1, 2, …, n) perform the following algorithms. (1) Execute step (4) in Initial commit phase except Vj. (2) Operate the VOPRF protocol [38], input permKey, output zi. (3) Parse zi into three parts (zi,1, zi,2, zi,3) ∈ {0, 1}λ × {0, 1}λ × {0, 1}λ. (4) Construct a random share si of zi,1 using a (k, n) secret-sharing scheme [39], where zi,2 is used in the share generation process. (5) Derive a temporary symmetry key TKi using a pseudorandom generator, where takes zi,1 as input. (6) Encrypt PIDi,j with TKi to obtain cyphertext CTi. (7) Vj uploads to CS after performing an authentication with gski, while other vehicles uploads {CTi, si, zi,3}. Aggregation phase. CS performs the following algorithms. (1) Group together messages that share the same zi,3 vale into subset Ui. (2) Run the share recovery algorithm on the collections of share values {si}i = 1, …k ∈ Ui to output zi,1. (3) Derive a temporary symmetry key TKi takes zi,1 as input. (4) Decrypt CTi with TKi to obtain PIDi,j. (5) Store into DB and create list Li to store {PID1,j, PID2,j, …, PIDk,j}. 4.3.4 Join. It is worth noting that the added vehicle PIDi,j can join in group using welcome message if ‘act’ = add. (1) After V1 uploading , CS stores into a specific DB, where works similarly to the . (2) Vi(i = 1, 2, …, n) performs authentication protocol to retrieve in the DB of CS. Input (Join, ), the state of PIDi,j is synced with any member who processes the commit made at the same epoch. 4.3.5 Process & Key. Once there are k elements in Li, CS broadcasts to all vehicles. Then, Vi(i = 1, 2, …, n) retrieves and processes commit corresponding to themselves. Steps are as follows. (1) Generate permKey = PRF (Ki−1,′ pi′), compute the permuted index = PRP (permKey, i). (2) Retrieve from with index. (3) Input , move to the next epoch and generate the new group key Ki. 4.3.1 Group creation. Assume that V1 hopes to create a group containing n members. It first registers a new group that only includes itself to CS. The steps are as follows. (1) Input (Create), initiate a new group identifier gid and group key K0, epoch = 0. (2) Generate group specific authentication key (gvk0, gsk0) with the group key K0 and some authentication information. (3) Send (gvk0, gid) to CS. (4) CS stores (gvk0, gid) into the DB. 4.3.2 Proposals. CS generates a random challenge chi ← {0, 1}λ and transmits it to Vi before it uploads the proposals. The steps are as follows. (1) Vi inputs (Propose, ‘act-PIDi,j’), creates a proposal pi, where ‘act’ ∈ add, rem, upd, represents addition or removal of vehicle PIDi,j, and update of key materials, respectively. (2) Vi generates signature σi with gski, uploads {σi, pi, PID1j} to CS. (3) CS stores {pi, PIDi,j} into DB after checking the validity of σi with gvki. Add group member PIDi,j: , propose to add a new vehicle PIDi,j to the current group. Input group state, the PIDi,j of new vehicle and its public key, output an updated group state and an addition proposal message. Fig 6 shows the key agreement for new vehicles joining. Assume that there are five vehicles in the current group, V1 proposes to add vehicle V6 to the group. Remove group member PIDi,j: , propose to remove a vehicle PIDi,j from current group. Input group state, the PIDi,j of target vehicle, output an updated group state and a removal proposal message. Fig 7 shows the key agreement for old vehicles leaving. Assume that V1 proposes to remove vehicle V3 from the group. Update key material: , propose to update the key materials of vehicles. Input group state, output an updated group state and an update proposal message. Fig 8 shows the group key agreement for the key materials update. Assume that V2 updates its new key as . Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 6. The key agreement for new vehicle joining. https://doi.org/10.1371/journal.pone.0307867.g006 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 7. The key agreement for old vehicle leaving. https://doi.org/10.1371/journal.pone.0307867.g007 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 8. The key agreement for key materials update. https://doi.org/10.1371/journal.pone.0307867.g008 4.3.3 Commit. To update the group state, Vi(i = 1, 2, …, n) download pi to commit. The steps are as follows. Initial commit phase. Vehicle Vj performs the following algorithms. (1) Input (Commit, pi), generate a commit . The welcome message is depended on if there is an additional proposal message in . (2) Generate new group authentication key (gvki, gski). (3) Inform vehicles that it has generated the commit and gvki. (4) Generate PRP key , which defined the permutation on group size. (5) Create a permuted member dependent commit so that is placed at entry PRP(permKey, i) ∈ [1, 2, …, n]. Message construction phase. Vehicles Vi(i = 1, 2, …, n) perform the following algorithms. (1) Execute step (4) in Initial commit phase except Vj. (2) Operate the VOPRF protocol [38], input permKey, output zi. (3) Parse zi into three parts (zi,1, zi,2, zi,3) ∈ {0, 1}λ × {0, 1}λ × {0, 1}λ. (4) Construct a random share si of zi,1 using a (k, n) secret-sharing scheme [39], where zi,2 is used in the share generation process. (5) Derive a temporary symmetry key TKi using a pseudorandom generator, where takes zi,1 as input. (6) Encrypt PIDi,j with TKi to obtain cyphertext CTi. (7) Vj uploads to CS after performing an authentication with gski, while other vehicles uploads {CTi, si, zi,3}. Aggregation phase. CS performs the following algorithms. (1) Group together messages that share the same zi,3 vale into subset Ui. (2) Run the share recovery algorithm on the collections of share values {si}i = 1, …k ∈ Ui to output zi,1. (3) Derive a temporary symmetry key TKi takes zi,1 as input. (4) Decrypt CTi with TKi to obtain PIDi,j. (5) Store into DB and create list Li to store {PID1,j, PID2,j, …, PIDk,j}. 4.3.4 Join. It is worth noting that the added vehicle PIDi,j can join in group using welcome message if ‘act’ = add. (1) After V1 uploading , CS stores into a specific DB, where works similarly to the . (2) Vi(i = 1, 2, …, n) performs authentication protocol to retrieve in the DB of CS. Input (Join, ), the state of PIDi,j is synced with any member who processes the commit made at the same epoch. 4.3.5 Process & Key. Once there are k elements in Li, CS broadcasts to all vehicles. Then, Vi(i = 1, 2, …, n) retrieves and processes commit corresponding to themselves. Steps are as follows. (1) Generate permKey = PRF (Ki−1,′ pi′), compute the permuted index = PRP (permKey, i). (2) Retrieve from with index. (3) Input , move to the next epoch and generate the new group key Ki. 5 Security proof and security analysis 5.1 Security proof The priority of all CGKA schemes is to prevent the adversary from getting the group key. We prove the ER-CGKA scheme is secure according to the CGKA security model in [40]. In the CGKA security game, the attacker is given access to various oracles to drive the execution of a CGKA protocol. However, the attacker will not be allowed to modify or inject any control messages. In addition, the capabilities of the attacker and restrictions on the order in which the attacker may call the oracles are motivated by a CGKA protocol, which would be used at a higher level. The main oracles to drive the execution are the oracles ‘create-group’, ‘add-user’, ‘remove-user’, ‘send-update’, ‘deliver’. The first four oracles allow the adversary to instruct vehicles to initiate new epochs, whereas the deliver oracle makes vehicles proceed to the next epoch. CS connecting the vehicles is trusted to provide vehicles with a consistent view of which operation takes place in each epoch. That is, while multiple parties may initiate a new epoch, the attacker is forced to pick a single operation that defines the new epoch; the corresponding sender is referred to as the leader of the epoch. The game forces the attacker to initially create a group at epoch = 0. Thereafter, any group member may add new vehicles, remove current group members, or perform an update. The attacker may also corrupt any vehicle at any point and challenge the update secret in any epoch where the leader performs an update operation. Furthermore, the adversary can instruct vehicles to stop deleting old secrets. There will be restrictions checked at the end of the execution of the game to ensure that the attacker’s challenge/corruption/no-deletion behavior does not lead to trivial attacks. Then, we prove the ER-CGKA scheme is secure through a game interaction between adversary A and oracles. Definition 1 (Non-adaptive CGKA security) The CGKA protocol is non-adaptively (t, c, n, P, ε)-secure if for all (t, c, n) − adversaries, . In other words, if the adversary A that runs in time at most t, makes at most c challenge queries, and never produces a group with more than n members, then the advantage of A with safety predicate P against a CGKA scheme is ε. Theorem 1 If A can win CGKA security game with the non-negligible probability ε in PPT under the ROM, then A has the advantage of breaking CGKA protocol. Proof 1 Assumed that A tries to obtain group key, the interaction between A and oracles are as follows. Initialization. The init oracle sets up the game and all the variables need to keep track of the execution. The random bit b is used for real-or-random challenges, and the dictionary γ keeps track of all the vehicles’ states. For every epoch, the dictionaries lead, I, and G record the leader, the update secret, and the group members, respectively, and ep records which epoch each vehicle is currently in. The array ctr counts all new operations initiated by a vehicle in its current epoch. Moreover, D keeps track of which parties delete their old values and which do not. Dictionary chall is used to ensure that the adversary A can issue at most a single challenge per (update) epoch. Finally, M records all control messages produced by parties; the adversary A has read access to M (as indicated by the keyword pub). Initiating operations and choosing epoch leaders. As mentioned above, the adversary A must choose a leader in every epoch, i.e., a sender whose control message is ultimately processed by all group members. More precisely, for each vehicle PIDi,j currently in some epoch t, ctr[PIDi,j] can be thought of as a (local) “version number” that counts the various operations initiated by PIDi,j in epoch t. The counter is incremented each time PIDi,j initiates a new operation. The resulting control messages for vehicles PIDi,j are stored in M with key (t + 1, PIDi,j, PIDk,j, ctr[PIDi,j]), representing the number of the next epoch, the sender, the recipient, and the (local) version number of the operation. Similarly, dictionary G stores the new group that would result from the operation with key (t + 1, PIDi,j, ctr[PIDi,j]). For every epoch t, the first control message M[t, PIDi,j, PIDm,j, c] delivered via deliver, for some vehicles PIDi,j, PIDm,j and version number c, determines that PIDi,j is the leader and c is the version that was chosen by CS. Correspondingly, the game records (PIDi,j, c) → lead[t] and sets the group membership to G[t, PIDi,j, c] → G[t]. In general, whenever a vehicle PIDm,j processes any control message, the counter ctr[PIDm,j] is reset to 0 as all operations initiated by PIDm,j in its current epoch are now obsolete (either processed by PIDi,j or rejected by the server in favor of some other operation). Note that the sender of an operation also sends a control message addressed to themselves to the server. The server confirms an operation by returning that message back to the sender. Group creation. The oracle create-group causes PID1,j to create a group with members {PID1,j, PID2,j, …, PIDn,j}. This is only allowed if PID1,j is currently in epoch 0, which is enforced by the req statement. Thereafter, PID1,j calls the group creation algorithm and sends the resulting welcome messages to all vehicles involved (including itself). Adding and removing vehicles and performing updates. For all three oracles add-user, remove-user, and send-update, the req statement checks that the call makes sense (e.g., checking that a vehicle added to the group is not currently a group member). Subsequently, the oracles call the corresponding CGKA algorithms (add, rem, and upd, respectively) and store the resulting control messages in M. Delivering control messages. The oracle deliver is called with the same four arguments [t, PIDi,j, PIDm,j, c] that are used as keys for the M array. The req statement at the beginning checks that (1) either there is no leader for epoch t yet or version c of PIDi,j is the leader already and (2) the recipient PIDk,j is currently either in epoch t − 1 or a newly added group member, which is checked by predicate added defined by added[t, PIDi,j, PIDm,j, c] ≔ PIDm,j ∉ G[t − 1] ∧ PIDm,j ∈ G[t, PIDi,j, c]. If the checks are passed, the appropriate control message is retrieved from M and run through proc on the state of PIDi,j. If there is no leader for epoch t yet, the game sets the leader as explained above and also records the update secret I[t] output by proc. In all future calls to deliver, the values I output by process will be checked against I[t] and, in case of a mismatch, the instruction win reveals the secret bit b to the attacker; this ensures correctness. Finally, the epoch counter for PIDk,j is incremented—or set to -1 if the operation just processed removes PIDk,j from the group. This involves a check via predicate removed defined by removed[t, PIDm,j] ≔ PIDm,j ∉ G[t − 1] ∧ PIDm,j ∈ G[t]. Challenges, corruptions, and deletions. In order to capture that update secrets must look random, the attacker is allowed to issue a challenge for any epoch corresponding to an update operation. When calling chall[t] for some t, the oracle first checks that t indeed corresponds to an update epoch and that a leader already exists. Similarly, using reveal, the attacker can simply learn the update secret of an epoch. It is also ensured that for each epoch, the attacker can make at most one call to either chall or reveal. To formally model forward secrecy and PCS, the attacker is also allowed to learn the current state of any vehicle by calling the oracle corrupt. Finally, the attacker can instruct a vehicle PIDi,j to stop deleting old values by calling no-del (PIDi,j). Subsequently, the game will implicitly store all old states of PIDi,j (instead of overriding them) and leak it to the attacker when he calls corrupt. The game also sets the corresponding flag. Avoiding trivial attacks. In order to ensure that the attacker may not win the CGKA security game with trivial attacks (such as, e.g., challenging an epoch t’s update secret and leaking some vehicle’s state in epoch t), at the end of the game, the predicate safe is run on the queries q1, q2, …, qq in order to determine whether the execution was devoid of such attacks. The predicate tests whether the attacker can trivially compute the update secret in a challenge epoch t* using the state of a vehicle PIDi,j in some t and the control messages observed on the network. This is the case if either (1) PIDi,j has not performed an update or been removed before epoch t* or (2) PIDi,j stopped deleting values at some point up to epoch t* and was corrupted thereafter. It uses the function q2e(q), which returns the epoch corresponding to query q. Specifically, for q ∈ {corrupt(PIDi,j), no-del(PIDi,j)}, if PIDi,j is member of the group when q is made, q2e(q) is the value of ep[PIDi,j], otherwise, q2e(q) returns ⊥. For q ∈ {send-update(PIDi,j), remove-user (PIDi,j, PIDk,j)}, q2e(q) is the epoch for which PIDi,j initiates the operation. If q is not processed by any vehicle we set q2e(q) = ⊥. Observe that the predicate safe can in general be replaced by any other predicate P, potentially weakening the resulting security notion. Advantage. Next, we analyze the probability that A can win CGKA security game. A (t, c, n) − adversary is an adversary A that runs in time at most t, makes at most c challenge queries, and never produces a group with more than n members. For adversary A for which the safety predicate evaluates to true on the queries made by it, A wins the CGKA security game if it correctly guesses the random bit b in the end. The advantage of A with safety predicate P against a CGKA scheme CGKA is defined by . To sum up, the probability that A can win CGKA security game is . 5.2 Security analysis We prove that our scheme satisfies all the security requirements mentioned in Section 3.3. Correctness. All vehicles in the same group will compute a new group key and move to the next epoch after processing the same proposal. In addition, if a vehicle joins the group via a welcome message , its group state is synced with any member who processes the commit made at the same epoch. According to Theorem 1, the ER-CGKA scheme contents correctness. Conditional privacy-preserving. (1) Anonymity. We employ pseudonym technology to protect the identity privacy of vehicles, which makes it impossible for any entity to learn the real identity of vehicles except TMA. (2) Traceability. If vehicles send malicious or fake messages, other vehicles will transmit their pseudonyms (e.g. PIDi,j) to TMA with the help of RSU. Then, TMA retrieves Qi,j and Ti,j in its DB with PIDi,j, computes h1i = H1(aXi||Ti,j) with a, recovers the real identity of malicious vehicle RIDi = Qi,j⊕h1i, removes it from the group and punishes it. Therefore, the ER-CGKA scheme realizes conditional privacy-preserving. Confidentiality. The group key is derived from the previous group key and the update key material. So even if an attacker steals the group key of the previous epoch, there is no way to generate the current group key without update key material. In other words, the group key is kept secret from any entity other than the group members. Therefore, the ER-CGKA scheme ensures group key confidentiality. Unlinkability. At the vehicle registration stage, TMA generates a batch of pseudonyms so that vehicles can choose one unused pseudonym at a time to communicate with others. Thus, any third party (e.g. CS) cannot link to two or more proposals or commits are uploaded or downloaded by the same vehicle. Therefore, the ER-CGKA scheme fulfills unlinkability. PCFS. (1) FS. The FS means that the new vehicle joining the group cannot decrypt the communication content of the previous epoch. In our scheme, the group key is commonly derived from the group key at the previous epoch and the key material. The group state of the new vehicle is synchronized with the members at the current epoch, but it cannot obtain the previous group key to decrypt the former ciphertext. According to Theorem 1, the ER-CGKA scheme satisfies FS. (2) PCS. The PCS means that vehicles that left the group cannot obtain the group key of the next epoch. In our scheme, if a vehicle uploads a ‘rem’ proposal, the group key will be updated once at least k vehicles commit it. Since the left vehicle does not know the key materials, it cannot compute the new group key of subsequent epochs. According to Theorem 1, the ER-CGKA scheme achieves PCS. Resistance to collusion attacks. At the commit stage, vehicles in the group can download proposals to commit and upload the commits to CS. Especially, CS checks if there are at least k commits in a n-size group that are associated with the same proposal. If so, CS informs vehicles to download the commits to process and update the group key. Therefore, the ER-CGKA scheme can resist collusion attacks through the (k, n) secret sharing scheme. Table 2 shows the security comparison result between our scheme and schemes in [8, 13, 14], where “✓” represents satisfying the property, “×” represents not satisfied. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 2. Security comparison. https://doi.org/10.1371/journal.pone.0307867.t002 The scheme in [13] assumed that there is a fully trusted cluster head vehicle, which breaks the secure communication if the cluster head vehicle is compromised. Moreover, the scheme does not enable PCS since the key updates are not considered. The scheme in [14] considers the key update. Nevertheless, the vehicle that has left the group can still compute the updated key by performing the “XOR” operation on the updated key and the old key. Besides, the vehicles in the schemes in [13, 14] use a specific identity for communication, which cannot satisfy the unlinkability. Finally, the schemes in [8, 13, 14] cannot resist collusion attacks, but our ER-CGKA scheme satisfies all the above security requirements. 5.1 Security proof The priority of all CGKA schemes is to prevent the adversary from getting the group key. We prove the ER-CGKA scheme is secure according to the CGKA security model in [40]. In the CGKA security game, the attacker is given access to various oracles to drive the execution of a CGKA protocol. However, the attacker will not be allowed to modify or inject any control messages. In addition, the capabilities of the attacker and restrictions on the order in which the attacker may call the oracles are motivated by a CGKA protocol, which would be used at a higher level. The main oracles to drive the execution are the oracles ‘create-group’, ‘add-user’, ‘remove-user’, ‘send-update’, ‘deliver’. The first four oracles allow the adversary to instruct vehicles to initiate new epochs, whereas the deliver oracle makes vehicles proceed to the next epoch. CS connecting the vehicles is trusted to provide vehicles with a consistent view of which operation takes place in each epoch. That is, while multiple parties may initiate a new epoch, the attacker is forced to pick a single operation that defines the new epoch; the corresponding sender is referred to as the leader of the epoch. The game forces the attacker to initially create a group at epoch = 0. Thereafter, any group member may add new vehicles, remove current group members, or perform an update. The attacker may also corrupt any vehicle at any point and challenge the update secret in any epoch where the leader performs an update operation. Furthermore, the adversary can instruct vehicles to stop deleting old secrets. There will be restrictions checked at the end of the execution of the game to ensure that the attacker’s challenge/corruption/no-deletion behavior does not lead to trivial attacks. Then, we prove the ER-CGKA scheme is secure through a game interaction between adversary A and oracles. Definition 1 (Non-adaptive CGKA security) The CGKA protocol is non-adaptively (t, c, n, P, ε)-secure if for all (t, c, n) − adversaries, . In other words, if the adversary A that runs in time at most t, makes at most c challenge queries, and never produces a group with more than n members, then the advantage of A with safety predicate P against a CGKA scheme is ε. Theorem 1 If A can win CGKA security game with the non-negligible probability ε in PPT under the ROM, then A has the advantage of breaking CGKA protocol. Proof 1 Assumed that A tries to obtain group key, the interaction between A and oracles are as follows. Initialization. The init oracle sets up the game and all the variables need to keep track of the execution. The random bit b is used for real-or-random challenges, and the dictionary γ keeps track of all the vehicles’ states. For every epoch, the dictionaries lead, I, and G record the leader, the update secret, and the group members, respectively, and ep records which epoch each vehicle is currently in. The array ctr counts all new operations initiated by a vehicle in its current epoch. Moreover, D keeps track of which parties delete their old values and which do not. Dictionary chall is used to ensure that the adversary A can issue at most a single challenge per (update) epoch. Finally, M records all control messages produced by parties; the adversary A has read access to M (as indicated by the keyword pub). Initiating operations and choosing epoch leaders. As mentioned above, the adversary A must choose a leader in every epoch, i.e., a sender whose control message is ultimately processed by all group members. More precisely, for each vehicle PIDi,j currently in some epoch t, ctr[PIDi,j] can be thought of as a (local) “version number” that counts the various operations initiated by PIDi,j in epoch t. The counter is incremented each time PIDi,j initiates a new operation. The resulting control messages for vehicles PIDi,j are stored in M with key (t + 1, PIDi,j, PIDk,j, ctr[PIDi,j]), representing the number of the next epoch, the sender, the recipient, and the (local) version number of the operation. Similarly, dictionary G stores the new group that would result from the operation with key (t + 1, PIDi,j, ctr[PIDi,j]). For every epoch t, the first control message M[t, PIDi,j, PIDm,j, c] delivered via deliver, for some vehicles PIDi,j, PIDm,j and version number c, determines that PIDi,j is the leader and c is the version that was chosen by CS. Correspondingly, the game records (PIDi,j, c) → lead[t] and sets the group membership to G[t, PIDi,j, c] → G[t]. In general, whenever a vehicle PIDm,j processes any control message, the counter ctr[PIDm,j] is reset to 0 as all operations initiated by PIDm,j in its current epoch are now obsolete (either processed by PIDi,j or rejected by the server in favor of some other operation). Note that the sender of an operation also sends a control message addressed to themselves to the server. The server confirms an operation by returning that message back to the sender. Group creation. The oracle create-group causes PID1,j to create a group with members {PID1,j, PID2,j, …, PIDn,j}. This is only allowed if PID1,j is currently in epoch 0, which is enforced by the req statement. Thereafter, PID1,j calls the group creation algorithm and sends the resulting welcome messages to all vehicles involved (including itself). Adding and removing vehicles and performing updates. For all three oracles add-user, remove-user, and send-update, the req statement checks that the call makes sense (e.g., checking that a vehicle added to the group is not currently a group member). Subsequently, the oracles call the corresponding CGKA algorithms (add, rem, and upd, respectively) and store the resulting control messages in M. Delivering control messages. The oracle deliver is called with the same four arguments [t, PIDi,j, PIDm,j, c] that are used as keys for the M array. The req statement at the beginning checks that (1) either there is no leader for epoch t yet or version c of PIDi,j is the leader already and (2) the recipient PIDk,j is currently either in epoch t − 1 or a newly added group member, which is checked by predicate added defined by added[t, PIDi,j, PIDm,j, c] ≔ PIDm,j ∉ G[t − 1] ∧ PIDm,j ∈ G[t, PIDi,j, c]. If the checks are passed, the appropriate control message is retrieved from M and run through proc on the state of PIDi,j. If there is no leader for epoch t yet, the game sets the leader as explained above and also records the update secret I[t] output by proc. In all future calls to deliver, the values I output by process will be checked against I[t] and, in case of a mismatch, the instruction win reveals the secret bit b to the attacker; this ensures correctness. Finally, the epoch counter for PIDk,j is incremented—or set to -1 if the operation just processed removes PIDk,j from the group. This involves a check via predicate removed defined by removed[t, PIDm,j] ≔ PIDm,j ∉ G[t − 1] ∧ PIDm,j ∈ G[t]. Challenges, corruptions, and deletions. In order to capture that update secrets must look random, the attacker is allowed to issue a challenge for any epoch corresponding to an update operation. When calling chall[t] for some t, the oracle first checks that t indeed corresponds to an update epoch and that a leader already exists. Similarly, using reveal, the attacker can simply learn the update secret of an epoch. It is also ensured that for each epoch, the attacker can make at most one call to either chall or reveal. To formally model forward secrecy and PCS, the attacker is also allowed to learn the current state of any vehicle by calling the oracle corrupt. Finally, the attacker can instruct a vehicle PIDi,j to stop deleting old values by calling no-del (PIDi,j). Subsequently, the game will implicitly store all old states of PIDi,j (instead of overriding them) and leak it to the attacker when he calls corrupt. The game also sets the corresponding flag. Avoiding trivial attacks. In order to ensure that the attacker may not win the CGKA security game with trivial attacks (such as, e.g., challenging an epoch t’s update secret and leaking some vehicle’s state in epoch t), at the end of the game, the predicate safe is run on the queries q1, q2, …, qq in order to determine whether the execution was devoid of such attacks. The predicate tests whether the attacker can trivially compute the update secret in a challenge epoch t* using the state of a vehicle PIDi,j in some t and the control messages observed on the network. This is the case if either (1) PIDi,j has not performed an update or been removed before epoch t* or (2) PIDi,j stopped deleting values at some point up to epoch t* and was corrupted thereafter. It uses the function q2e(q), which returns the epoch corresponding to query q. Specifically, for q ∈ {corrupt(PIDi,j), no-del(PIDi,j)}, if PIDi,j is member of the group when q is made, q2e(q) is the value of ep[PIDi,j], otherwise, q2e(q) returns ⊥. For q ∈ {send-update(PIDi,j), remove-user (PIDi,j, PIDk,j)}, q2e(q) is the epoch for which PIDi,j initiates the operation. If q is not processed by any vehicle we set q2e(q) = ⊥. Observe that the predicate safe can in general be replaced by any other predicate P, potentially weakening the resulting security notion. Advantage. Next, we analyze the probability that A can win CGKA security game. A (t, c, n) − adversary is an adversary A that runs in time at most t, makes at most c challenge queries, and never produces a group with more than n members. For adversary A for which the safety predicate evaluates to true on the queries made by it, A wins the CGKA security game if it correctly guesses the random bit b in the end. The advantage of A with safety predicate P against a CGKA scheme CGKA is defined by . To sum up, the probability that A can win CGKA security game is . 5.2 Security analysis We prove that our scheme satisfies all the security requirements mentioned in Section 3.3. Correctness. All vehicles in the same group will compute a new group key and move to the next epoch after processing the same proposal. In addition, if a vehicle joins the group via a welcome message , its group state is synced with any member who processes the commit made at the same epoch. According to Theorem 1, the ER-CGKA scheme contents correctness. Conditional privacy-preserving. (1) Anonymity. We employ pseudonym technology to protect the identity privacy of vehicles, which makes it impossible for any entity to learn the real identity of vehicles except TMA. (2) Traceability. If vehicles send malicious or fake messages, other vehicles will transmit their pseudonyms (e.g. PIDi,j) to TMA with the help of RSU. Then, TMA retrieves Qi,j and Ti,j in its DB with PIDi,j, computes h1i = H1(aXi||Ti,j) with a, recovers the real identity of malicious vehicle RIDi = Qi,j⊕h1i, removes it from the group and punishes it. Therefore, the ER-CGKA scheme realizes conditional privacy-preserving. Confidentiality. The group key is derived from the previous group key and the update key material. So even if an attacker steals the group key of the previous epoch, there is no way to generate the current group key without update key material. In other words, the group key is kept secret from any entity other than the group members. Therefore, the ER-CGKA scheme ensures group key confidentiality. Unlinkability. At the vehicle registration stage, TMA generates a batch of pseudonyms so that vehicles can choose one unused pseudonym at a time to communicate with others. Thus, any third party (e.g. CS) cannot link to two or more proposals or commits are uploaded or downloaded by the same vehicle. Therefore, the ER-CGKA scheme fulfills unlinkability. PCFS. (1) FS. The FS means that the new vehicle joining the group cannot decrypt the communication content of the previous epoch. In our scheme, the group key is commonly derived from the group key at the previous epoch and the key material. The group state of the new vehicle is synchronized with the members at the current epoch, but it cannot obtain the previous group key to decrypt the former ciphertext. According to Theorem 1, the ER-CGKA scheme satisfies FS. (2) PCS. The PCS means that vehicles that left the group cannot obtain the group key of the next epoch. In our scheme, if a vehicle uploads a ‘rem’ proposal, the group key will be updated once at least k vehicles commit it. Since the left vehicle does not know the key materials, it cannot compute the new group key of subsequent epochs. According to Theorem 1, the ER-CGKA scheme achieves PCS. Resistance to collusion attacks. At the commit stage, vehicles in the group can download proposals to commit and upload the commits to CS. Especially, CS checks if there are at least k commits in a n-size group that are associated with the same proposal. If so, CS informs vehicles to download the commits to process and update the group key. Therefore, the ER-CGKA scheme can resist collusion attacks through the (k, n) secret sharing scheme. Table 2 shows the security comparison result between our scheme and schemes in [8, 13, 14], where “✓” represents satisfying the property, “×” represents not satisfied. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 2. Security comparison. https://doi.org/10.1371/journal.pone.0307867.t002 The scheme in [13] assumed that there is a fully trusted cluster head vehicle, which breaks the secure communication if the cluster head vehicle is compromised. Moreover, the scheme does not enable PCS since the key updates are not considered. The scheme in [14] considers the key update. Nevertheless, the vehicle that has left the group can still compute the updated key by performing the “XOR” operation on the updated key and the old key. Besides, the vehicles in the schemes in [13, 14] use a specific identity for communication, which cannot satisfy the unlinkability. Finally, the schemes in [8, 13, 14] cannot resist collusion attacks, but our ER-CGKA scheme satisfies all the above security requirements. 6 Performance evaluation We analyze the computation and communication overhead of the ER-CGKA scheme. The cost of the scheme in [8] is written in normal font (X), while ours is written in bold (±X). In addition, we simulate the performance of our ER-CGKA scheme. The CGKA protocol is mainly interacted with vehicles and CS. Therefore, the CS is simulated by Windows 10 laptop 607 with an AMD Ryzen 9 5950 X @4 GHz processor and 32 GB of memory. The vehicle (Client) is simulated by Windows 10 laptop with Intel(R) Core (TM) i5-7200 U CPU @ 2.50 GHz and 12 GB of memory. 6.1 Computation cost For computation cost, we consider that (1) The run time of key generation like signature key Tgk, group key Tk, symmetric key Tder and permKey TPRP. (2) The time of executing algorithms like VOPRF protocol TVOPRF, secret sharing Tss and recovery Trec. (3) The general run time like signature generation Tsig and verification Tver, symmetric encryption Tse and symmetric decryption Tsd. The details are described as Table 3. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 3. The comparison of computation cost. https://doi.org/10.1371/journal.pone.0307867.t003 According to Table 3, the cost of the ER-CGKA scheme is equal to the scheme in [8] during Group Creation and Proposals. In the Commit stage, our scheme takes more time due to resisting collusion attacks. Concretely, the extra time is executing VOPRF protocol once, performing a secret share and recovery scheme, deriving the symmetric key twice, and operating a pair of symmetric encryption and decryption. In the Process & Key stage, CS broadcasts commit messages to vehicles rather than download from CS. Thus, we do not need to perform an authentication protocol. Based on Table 3, we simulated the running time of Client and CS in Figs 9 and 10. Specifically, the signature algorithm is the elliptic curve digital signature algorithm (ECDSA), and the symmetric encryption algorithm is the advanced encryption standard (AES). According to Fig 9, we can see that at the stages of Group Creation (0.417 ms) and Proposals (0.437 ms), the run time of the Client in our proposed ER-CGKA scheme is equal to the scheme in [8]. During the Commit stage, our run time (0.889 ms) is a little higher than the scheme in [8] (0.856 ms) since the secret sharing the algorithm is executed to resist the collusion attacks by the group members. At the Process & Key stage, compared to the the scheme in [8] (0.44 ms), the computation time in proposed ER-CGKA scheme (0.003 ms) has reduced 99.32%. Overall, our the total computation time of the Client has decreased by 18.82%. Similarly, according to Fig 10, compared to the scheme in [8], the run time of CS in our proposed ER-CGKA scheme at the Process & Key stage has reduced 100%, and the total time decreased by 33.18%. Therefore, our ER-CGKA scheme is more efficient. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 9. The run time of client. https://doi.org/10.1371/journal.pone.0307867.g009 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 10. The run time of CS. https://doi.org/10.1371/journal.pone.0307867.g010 6.2 Communication overhead In terms of communication overhead, we consider the bandwidth requirements of pseudonym |PIDi,j|, group key |ek|, commit message |c0|, ||, signature |sig|, and signature authentication key |svk|. U (resp. A, R) stand for the number of ‘upd’ (resp. ‘add’, ‘rem’) proposals published during the last epoch. The details are described as Table 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 4. The comparison of communication overhead. https://doi.org/10.1371/journal.pone.0307867.t004 As is shown in Table 4, the bandwidth overhead is added on uploading the pseudonym of the vehicle in Propose and Commit stage, which is used to trace the real identity of the proposer for TMA and realize resistance to collusion attacks. Besides, the cost is reduced in the Process & Key stage. On the one hand, vehicles do not need to upload signatures to convince CS that it is a legitimate group member. On the other hand, the commit message downloading is not required since CS broadcasts to them directly. We applied ElGamal mPKE and ECDSA algorithms to obtain concrete communication overhead. We assume a group of N = 256 members, k = 2/3N=171 members, and numbers for Commit and Process assume no proposal was made during the last epoch. From Fig 11, the ER-CGKA scheme’s bandwidth requirements are more than compared to the scheme in [8], which increased 14.29% (Propose-‘upd’), 16.67% (Propose-‘add’), 25% (Propose-‘rem’), and 60.04% (Commit stage), respectively. The reason is that we utilize pseudonym technology to achieve conditional privacy-preserving and unlinkability of the group vehicles. But at the Process & Key stage, our communication cost was reduced by 44.44% since the group vehicles don’t need to transmit signatures and commit messages. In a word, although the total communication cost in our ER-CGKA scheme increased by 55.57% than the scheme in [8], our scheme achieves more secure requirements. Thus, the result is acceptable. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 11. The bandwidth requirements. https://doi.org/10.1371/journal.pone.0307867.g011 6.3 Discussion What’s more, to give a better presentation of this work, we compare the computation cost with schemes [41–44]. Without loss of generality, we choose Type A elliptic curve. We utilize the JPBC library to simulate cryptographic operations on a Windows 10 laptop with an AMD Ryzen 9 5950 X @4 GHz processor and 32 GB of memory. The computation time for the accomplishment of a bilinear pairing operation is 2.972 ms, and the point multiplication is 5.265 ms. The comparison results are shown in Table 5. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 5. The comparison of computation cost with schemes [41–44]. https://doi.org/10.1371/journal.pone.0307867.t005 As is shown in Table 5, the total computation time of our ER-CGKA scheme is less than [43, 44] and higher than [41, 42]. Specifically, schemes in [43, 44] utilize the expensive bilinear pairing operation, so their computation cost is higher. In addition, we utilized a secret sharing algorithm, an ECDSA algorithm, and many key generation algorithms to achieve PCFS and resist collusion attacks. So our computation cost is higher than [41, 42]. Overall, we achieve a better trade-off between security and performance. 6.1 Computation cost For computation cost, we consider that (1) The run time of key generation like signature key Tgk, group key Tk, symmetric key Tder and permKey TPRP. (2) The time of executing algorithms like VOPRF protocol TVOPRF, secret sharing Tss and recovery Trec. (3) The general run time like signature generation Tsig and verification Tver, symmetric encryption Tse and symmetric decryption Tsd. The details are described as Table 3. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 3. The comparison of computation cost. https://doi.org/10.1371/journal.pone.0307867.t003 According to Table 3, the cost of the ER-CGKA scheme is equal to the scheme in [8] during Group Creation and Proposals. In the Commit stage, our scheme takes more time due to resisting collusion attacks. Concretely, the extra time is executing VOPRF protocol once, performing a secret share and recovery scheme, deriving the symmetric key twice, and operating a pair of symmetric encryption and decryption. In the Process & Key stage, CS broadcasts commit messages to vehicles rather than download from CS. Thus, we do not need to perform an authentication protocol. Based on Table 3, we simulated the running time of Client and CS in Figs 9 and 10. Specifically, the signature algorithm is the elliptic curve digital signature algorithm (ECDSA), and the symmetric encryption algorithm is the advanced encryption standard (AES). According to Fig 9, we can see that at the stages of Group Creation (0.417 ms) and Proposals (0.437 ms), the run time of the Client in our proposed ER-CGKA scheme is equal to the scheme in [8]. During the Commit stage, our run time (0.889 ms) is a little higher than the scheme in [8] (0.856 ms) since the secret sharing the algorithm is executed to resist the collusion attacks by the group members. At the Process & Key stage, compared to the the scheme in [8] (0.44 ms), the computation time in proposed ER-CGKA scheme (0.003 ms) has reduced 99.32%. Overall, our the total computation time of the Client has decreased by 18.82%. Similarly, according to Fig 10, compared to the scheme in [8], the run time of CS in our proposed ER-CGKA scheme at the Process & Key stage has reduced 100%, and the total time decreased by 33.18%. Therefore, our ER-CGKA scheme is more efficient. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 9. The run time of client. https://doi.org/10.1371/journal.pone.0307867.g009 Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 10. The run time of CS. https://doi.org/10.1371/journal.pone.0307867.g010 6.2 Communication overhead In terms of communication overhead, we consider the bandwidth requirements of pseudonym |PIDi,j|, group key |ek|, commit message |c0|, ||, signature |sig|, and signature authentication key |svk|. U (resp. A, R) stand for the number of ‘upd’ (resp. ‘add’, ‘rem’) proposals published during the last epoch. The details are described as Table 4. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 4. The comparison of communication overhead. https://doi.org/10.1371/journal.pone.0307867.t004 As is shown in Table 4, the bandwidth overhead is added on uploading the pseudonym of the vehicle in Propose and Commit stage, which is used to trace the real identity of the proposer for TMA and realize resistance to collusion attacks. Besides, the cost is reduced in the Process & Key stage. On the one hand, vehicles do not need to upload signatures to convince CS that it is a legitimate group member. On the other hand, the commit message downloading is not required since CS broadcasts to them directly. We applied ElGamal mPKE and ECDSA algorithms to obtain concrete communication overhead. We assume a group of N = 256 members, k = 2/3N=171 members, and numbers for Commit and Process assume no proposal was made during the last epoch. From Fig 11, the ER-CGKA scheme’s bandwidth requirements are more than compared to the scheme in [8], which increased 14.29% (Propose-‘upd’), 16.67% (Propose-‘add’), 25% (Propose-‘rem’), and 60.04% (Commit stage), respectively. The reason is that we utilize pseudonym technology to achieve conditional privacy-preserving and unlinkability of the group vehicles. But at the Process & Key stage, our communication cost was reduced by 44.44% since the group vehicles don’t need to transmit signatures and commit messages. In a word, although the total communication cost in our ER-CGKA scheme increased by 55.57% than the scheme in [8], our scheme achieves more secure requirements. Thus, the result is acceptable. Download: PPT PowerPoint slide PNG larger image TIFF original image Fig 11. The bandwidth requirements. https://doi.org/10.1371/journal.pone.0307867.g011 6.3 Discussion What’s more, to give a better presentation of this work, we compare the computation cost with schemes [41–44]. Without loss of generality, we choose Type A elliptic curve. We utilize the JPBC library to simulate cryptographic operations on a Windows 10 laptop with an AMD Ryzen 9 5950 X @4 GHz processor and 32 GB of memory. The computation time for the accomplishment of a bilinear pairing operation is 2.972 ms, and the point multiplication is 5.265 ms. The comparison results are shown in Table 5. Download: PPT PowerPoint slide PNG larger image TIFF original image Table 5. The comparison of computation cost with schemes [41–44]. https://doi.org/10.1371/journal.pone.0307867.t005 As is shown in Table 5, the total computation time of our ER-CGKA scheme is less than [43, 44] and higher than [41, 42]. Specifically, schemes in [43, 44] utilize the expensive bilinear pairing operation, so their computation cost is higher. In addition, we utilized a secret sharing algorithm, an ECDSA algorithm, and many key generation algorithms to achieve PCFS and resist collusion attacks. So our computation cost is higher than [41, 42]. Overall, we achieve a better trade-off between security and performance. 7 Conclusion First, we propose an ER-CGKA scheme with PCFS for IoV. Then, we prove that it is secure according to CGKA security under the ROM. It satisfies message authentication, integrity, confidentiality, non-repudiation, and unlinkability. Besides, the ER-CGKA scheme achieves conditional privacy-preserving of vehicles’ identity and PCFS of the group key. Moreover, collusion attacks by malicious vehicles can be resisted through threshold cryptography. The performance simulation results indicate that the computation cost and communication overhead are low. In the future, we will make great efforts to construct a more efficient and practical CGKA scheme for IoV and find the trade-off between communication efficiency and privacy-preserving. Supporting information S1 Dataset. https://doi.org/10.1371/journal.pone.0307867.s001 (XLSX) S2 Dataset. https://doi.org/10.1371/journal.pone.0307867.s002 (XLSX)
TI - ER-CGKA: Efficient and robust continuous group key agreement scheme with post-compromise forward security for IoV
JF - PLoS ONE
DO - 10.1371/journal.pone.0307867
DA - 2024-08-29
UR - https://www.deepdyve.com/lp/public-library-of-science-plos-journal/er-cgka-efficient-and-robust-continuous-group-key-agreement-scheme-po3xVov3kj
SP - e0307867
VL - 19
IS - 8
DP - DeepDyve
ER -