An internet of vehicles group key management method

Abstract

The application discloses a kind of Internet of Vehicles group key management methods, the method utilizes physical unclonable function to establish the unique binding of vehicle identity and equipment, and the secure session key between vehicle and cloud server is established by post-quantum authentication key agreement;True random group key is generated by cloud server, and the risk that vehicle end random number is predicted or subverted is reduced;Multi-ciphertext packing aggregation is realized using Chinese remainder theorem, and group key distribution is completed by one broadcast;For vehicle dynamic joining and exiting, cloud-assisted mechanism and hash chain mechanism are used respectively to update group key.The application can resist equipment duplication, key leakage, quantum computing attack and random number prediction attack, meet privacy, integrity, authentication, forward security and backward security requirements, and reduce the calculation and communication overhead of group key management.

Description

Technical Field

[0001] This invention belongs to the field of vehicle-to-everything (V2X) secure communication technology, specifically relating to a V2X group key management method based on physically unclonable functions, post-quantum authentication key negotiation, Chinese Remainder Theorem ciphertext packaging technology, and hash chains. Background Technology

[0002] With the development of intelligent connected vehicle technology, applications such as multi-vehicle cooperative driving, platooning, and in-vehicle cloud computing are gradually becoming important application scenarios for the Internet of Vehicles (IoV). During vehicle platooning communication, multiple vehicles need to share task information, control commands, and status data, thus requiring the establishment of a secure and reliable group communication mechanism. Among these, group key management is a crucial foundation for ensuring the security of IoV group communication. It not only needs to ensure that legitimate vehicles can obtain the shared key but also needs to update the group key promptly when vehicles dynamically join or leave, meeting the requirements of forward and backward security.

[0003] Existing secure communication solutions for connected vehicles typically employ authentication mechanisms based on digital certificates and public-key cryptography. However, as mobile devices operating in open environments for extended periods, vehicles' stored long-term keys are vulnerable to physical attacks, side-channel attacks, or device duplication attacks. Once a vehicle's private key is compromised, attackers could use the stolen identity information to forge a legitimate vehicle identity and participate in group communications. Therefore, traditional authentication methods based on stored keys are insufficient to meet the security requirements of a strong binding between device identity and physical entity in the connected vehicle environment. Furthermore, with the development of quantum computing technology, traditional public-key cryptographic algorithms based on large integer factorization and elliptic curve discrete logarithm problems face potential security threats. Therefore, future secure communication scenarios for connected vehicles require authentication key negotiation mechanisms based on post-quantum cryptography algorithms to ensure vehicle identity authentication while enhancing the group communication system's resistance to quantum computing attacks.

[0004] Physically Unclonable Functions (PUFs) utilize the physical randomness generated during chip manufacturing to provide each hardware device with a unique and uncopyable response characteristic, avoiding the direct storage of long-term keys within the device. Therefore, applying PUFs to vehicle authentication enhances the trustworthiness of vehicle identities and reduces the risk of identity theft due to key leaks. However, existing PUF-based authentication schemes typically focus primarily on point-to-point authentication processes and lack sufficient support for large-scale group key management in dynamic vehicle platooning scenarios.

[0005] Furthermore, in dynamic vehicle-to-everything (V2X) environments, the members of a vehicle platoon may change frequently. When a vehicle joins or leaves the platoon, the platoon key needs to be updated promptly. Some existing solutions generate new platoon keys through direct negotiation between vehicles, such as using multi-party key negotiation protocols for member interaction. However, in vehicle platooning scenarios, communication links between vehicles can be affected by vehicle movement, channel changes, and network topology changes. Frequent vehicle interactions lead to high communication overhead and latency. Simultaneously, as the number of vehicles increases, multiple rounds of negotiation further reduce the efficiency of platoon key updates. Therefore, it is necessary to leverage cloud nodes with strong computing power and stable network connections to assist in platoon key management, reducing the computational and communication burden on vehicle-side devices and improving key update efficiency in dynamic platoon environments. In addition, the quality of random numbers generated during platoon key generation directly affects key security. Existing vehicle terminals typically rely on software pseudo-random number generation mechanisms to produce key materials. Limited by vehicle computing resources, hardware environment, and random entropy source conditions, the randomness and unpredictability of the generated random numbers are difficult to guarantee sufficiently. When random numbers have predictable risks, it may lead to a decrease in platoon key security. Therefore, it is necessary to use cloud nodes with high-quality random sources to generate random parameters related to the group key in order to enhance the randomness and security of the group key.

[0006] On the other hand, in large-scale vehicle platoons, the cloud needs to send the same group key to multiple legitimate vehicles simultaneously when distributing group keys. If a traditional per-vehicle encrypted transmission method is used, the cloud needs to generate and send key ciphertext for each member separately. As the group size increases, the number of communication messages and transmission overhead will increase significantly. Therefore, a method is needed that can aggregate the key protection information corresponding to multiple members, enabling the cloud to complete the key distribution to multiple members in a single broadcast, thereby reducing the communication overhead during the group key update process.

[0007] Based on the above issues, how to leverage hardware uniqueness to enhance vehicle identity authentication security, how to combine cloud-assisted mechanisms to reduce the key negotiation burden in dynamic vehicle platooning, how to ensure the security of group keys, and how to achieve efficient key broadcasting and distribution for large-scale vehicle groups have become urgent problems to be solved in the field of secure communication in the Internet of Vehicles. Summary of the Invention

[0008] The purpose of this invention is to address the problems of insufficient vehicle identity authentication security, frequent changes in group members, difficulty in guaranteeing the security of random parameters during group key generation, and low efficiency of large-scale group key distribution in existing vehicle-to-everything (V2X) dynamic platooning communication processes. This invention provides a V2X group key management method based on physically non-cloning functions and resistance to quantum attacks and random number subversion.

[0009] This invention employs a physically non-cloning function to establish a unique binding relationship between vehicle identity and hardware physical characteristics. A challenge-response mechanism enables trusted vehicle authentication, avoiding identity theft issues caused by key leakage and duplication, common in traditional stored-key-based authentication methods. Simultaneously, a post-quantum authentication key negotiation mechanism is introduced to establish a secure session key between the vehicle and the cloud server, providing security against known quantum algorithm attacks for group key distribution. During group key management, a cloud-assisted key generation and distribution mechanism is introduced. Cloud service nodes are responsible for generating group key materials and updating keys in response to dynamic member changes, thus avoiding the computational and communication burden caused by frequent interactions between vehicles. Furthermore, this invention uses a ciphertext encapsulation method based on the Chinese Remainder Theorem (CRT) to aggregate the group key protection ciphertexts for different vehicles into a single broadcast ciphertext. This allows legitimate vehicles to recover the corresponding key materials from the broadcast ciphertext using their own key information, enabling group key distribution to multiple vehicles in a single broadcast, effectively reducing communication overhead in large-scale fleet scenarios.

[0010] The method specifically includes a system initialization phase, a registration phase, a group creation phase, and a group member update phase. In the system initialization phase, password parameters are generated and the system security foundation is established. In the vehicle registration phase, PUF is used to complete vehicle identity registration and challenge response information binding. In the group creation phase, an initial group key is generated in the cloud, encrypted using a combination of post-quantum authentication key negotiation and symmetric encryption, and securely distributed to platoon vehicles via CRT ciphertext packaging. In the group joining phase, the group owner vehicle determines the set of new members, the cloud completes the authentication of new vehicles and generates updated key materials, which are then synchronized and updated by the group owner vehicle to existing members. In the group leaving phase, the group owner vehicle regenerates the key update parameters and redistributes the updated group key to the remaining members.

[0011] This invention enables secure key management for vehicle platooning group communication in dynamic vehicle networking environments, meeting the requirements for key confidentiality, message integrity, vehicle identity authentication, and forward and backward security in dynamic member change scenarios during group communication. At the same time, it reduces the computation and communication overhead during group key updates, improving the security, efficiency, and practicality of the vehicle platooning communication system. It has good application prospects and promotional value.

[0012] The specific technical solution for achieving the objective of this invention is as follows:

[0013] A method for managing vehicle-to-everything (V2X) group keys employs a combination of Physically Unclonable Function (PUF), post-quantum authentication key negotiation, cloud-based true random number generation, and auxiliary key distribution to achieve secure establishment of vehicle groups, dynamic member management, and group key updates. It utilizes the Chinese Remainder Theorem (CRT) to package and broadcast multiple ciphertext keys, enabling the cloud server to distribute keys to multiple target vehicles with a single broadcast, reducing communication overhead. Furthermore, a hash chain mechanism ensures continuous updates of the group key after a member leaves. The group key management method specifically includes the following four stages:

[0014] 1) System initialization phase

[0015] 1-1: Certification Authority (CA) inputs security parameters ;

[0016] 1-2: Post-selection quantum authentication key negotiation protocol ,in, Initialize the system algorithm and input security parameters. And generate common protocol parameters; This is a key generation algorithm that generates long-term public-private key pairs for entities based on public parameters. The key negotiation initiation algorithm is initiated by the initiator, who generates the initiation message for authentication key negotiation. The key negotiation response algorithm involves the responder processing the initiating message and generating a response message, ensuring that both communicating parties negotiate and obtain the same session key; finally, execution... Generate authentication key negotiation public parameters ;

[0017] 1-3: Choose a symmetric encryption scheme ,in, For encryption algorithms, For decryption algorithms;

[0018] 1-4: Select five cryptographically collision-resistant hash functions and message authentication code ,in, This refers to the length of the symmetric key and the output length of the cryptographically collision-resistant hash function;

[0019] 1-5: Select system parameters ,in, Indicates the size of the CRT analog-to-digital pool. This represents the number of challenge-response pairs pre-registered for each vehicle. Indicates the length of the hash chain. Represents the set of positive integers;

[0020] 1-6: Pre-generating the CRT Module Pool Each modulus satisfies And any two moduli are coprime, i.e. ;

[0021] 1-7: Publish System Parameters ;

[0022] 2) Registration phase

[0023] During this phase, the cloud server and each vehicle first register with the Certificate Authority (CA) through a secure channel, and the CA maintains their public keys and certificates. In addition to registering with the CA, each vehicle also registers individually with the cloud server through a secure channel, as described below:

[0024] Cloud server registration: The cloud server registers with a Certificate Authority (CA) and obtains a long-term public key certificate for subsequent authentication key negotiation. The specific process is as follows:

[0025] 2-1-1: Cloud server generates authentication key and negotiates key pair ,in For public key, Use the private key, and then share your identity and public key through a secure channel. Send to the Certificate Authority (CA);

[0026] 2-1-2: The Certificate Authority (CA) received... Next, the registration request is verified. If the request is valid, the certification center issues a certificate. This is used to bind the cloud server identity and public key, and then... Recorded in the local certificate list and transmitted via a secure channel Send to the cloud server;

[0027] 2-1-3: The cloud server received... Next, the certificate will be verified. Once verification is successful, it will be... Stored locally;

[0028] Vehicle registration: Vehicle registration includes: certificate registration with a Certificate Authority (CA) and PUF registration with a cloud server. The certificate registration process with the CA is as follows: Vehicle Generate authentication key and negotiate key pair and its identity and public key Send it to the Certificate Authority (CA) and follow the same process as registering with the cloud server. Obtain the certificate after verification. This certificate is used to bind the vehicle's identity to its public key;

[0029] The PUF registration process with the cloud server is as follows:

[0030] 2-2-1: Vehicles Will Send to the cloud server;

[0031] 2-2-2: After receiving the certificate, the cloud server verifies it. The validity of the certificate is checked; if the certificate is valid, the cloud server generates a set of challenges. and will Send to vehicle ;

[0032] 2-2-3: Vehicles Received After that, for each , will challenge Input its physically non-clonable function and obtain the response. And calculate the corresponding auxiliary data. ;

[0033] An error correction mechanism was introduced. ,in, To assist the data generation algorithm, during the vehicle registration phase, the PUF response is used. Generate auxiliary data ; In response to the recovery algorithm, during the authentication phase, the PUF response affected by noise is used. and auxiliary data Restore stable response If recovery fails, output This indicates an error flag indicating that the PUF response recovery failed.

[0034] 2-2-4: Vehicles Set a challenge response set and the set of auxiliary information corresponding to the challenge ,Will Send to cloud server to erase and store locally ;

[0035] 2-2-5: The cloud server received... Afterwards, Stored locally;

[0036] 3) Group creation stage

[0037] In this stage, the group owner's vehicle first sends a group creation request to the cloud server. After the cloud server completes the request authentication, it generates an initial group key for the group and broadcasts it to the group members. After each member recovers and verifies the group key, the group creation is completed. The specific process is as follows:

[0038] 3-1: Initiate a group creation request

[0039] When the vehicle When forming a convoy with nearby vehicles for collaborative driving and safe communication, the vehicle acting as the group leader initiates a group creation request to the cloud server. The specific process is as follows:

[0040] 3-1-1: Group owner's vehicle Determine the initial group member set ,in, Indicates vehicle identity, while set Includes the group owner's vehicle And the vehicles selected to join the group, set This indicates the group round. Since we are currently in the group creation phase, we let... Subsequently, the group owner set up the vehicle. And send it to the cloud server. This is the current timestamp;

[0041] 3-1-2: The cloud server received... Later, from the vehicle Select a registered challenge from the registration information. And generate a unique group identifier for the group to be created. ,send Give the group owner a vehicle ;

[0042] 3-1-3: The group owner's vehicle received the message. Then, read the corresponding auxiliary data from the local machine. , will challenge Inputting a physically non-cloning function yields and using auxiliary data Restore the corresponding response Then calculate the request authentication key. ,in, Represented as a splicing symbol;

[0043] 3-1-4: Group Owner Vehicle Calculation and Authentication Tag and send to the cloud server ;

[0044] 3-2: Verify the creation request

[0045] The cloud server received Then, first check the timestamp. Whether it is within the valid time window; then according to the selection in 3-1-2. Read the corresponding response Calculate the authentication key for the request and verify Is it equal to If verification fails, the request is rejected; otherwise, the member set is further verified. Check if the vehicle's identity is legitimate; if the verification is successful, accept the request.

[0046] 3-3: Distribute the group key

[0047] 3-3-1: The cloud server selects a set of moduli from the moduli pool. ,in, ;

[0048] 3-3-2: For each The cloud server selects the corresponding challenge. and obtain the corresponding registration response. Using cloud server key pairs and vehicle public key ,implement Obtain the key and auxiliary messages Generate a set of auxiliary messages and a collection of challenges Then calculate ;

[0049] 3-3-3: The cloud server generates a truly random number and sets it as the initial group key. For each ,calculate Then calculate And for each ,calculate as well as Finally, calculate the packaged ciphertext. ;

[0050] Note: To ensure the correctness of the encrypted data packaging and recovery process in 3-3-3, firstly, the vehicle... Corresponding ciphertext Convert to non-negative integer For vehicles Allocation modulus Should meet The packed ciphertext constructed based on the Chinese Remainder Theorem satisfy Therefore, vehicles Through calculation Losslessly recover the corresponding ciphertext integer, and recover the ciphertext. If the complete ciphertext does not meet the requirements Then it is divided into A ciphertext block Make each ciphertext block satisfy The cloud server performs CRT packaging on the ciphertext blocks with the same sequence number in all vehicles, and encapsulates the resulting multiple CRT aggregate values ​​in the same broadcast message; the vehicles restore each ciphertext block through modulo operation, and then splice and decode them in a preset order to restore the complete ciphertext, avoiding the loss of ciphertext information due to modulo reduction;

[0051] 3-3-4: Generating truly random numbers on a cloud server Calculate ciphertext ;

[0052] 3-3-5: Cloud Server Computing Authentication Label Then broadcast to all group members ;

[0053] 3-4: Vehicle recovery group key

[0054] 3-4-1: Vehicles Upon receiving a broadcast message, first obtain the corresponding challenge value. and auxiliary data and calculate Subsequently, based on auxiliary data Restore registration response ;

[0055] 3-4-2: Vehicles Get the corresponding auxiliary message ,calculate ;

[0056] 3-4-3: The vehicle is based on its corresponding module. Recover the corresponding ciphertext The group key was then obtained through decryption. ;

[0057] 3-4-4: Further verification and certification label for vehicles Is it equal to If verification fails, the broadcast message is rejected; otherwise, the group key is accepted. And update the local group status; for the group owner's vehicle Further calculations ,by As the initial value of the hash chain, and calculate The group owner's vehicle uses random values ​​from the hash chain in reverse order as the group key update parameters when subsequent vehicles leave;

[0058] 4) Group update phase

[0059] In a highly dynamic fleet environment, vehicle members may join or leave the group at any time. It is necessary to synchronize and update the group member status and group key. The group update phase includes the vehicle joining process and the vehicle leaving process.

[0060] 4a: Vehicle addition:

[0061] 4a-1: Initiating a group member join request

[0062] When the group owner's vehicle To the current team group When a new registered vehicle is added to the group, the group owner is responsible for determining the set of vehicles allowed to join the next round of the group. The specific process is as follows:

[0063] 4a-1-1: Group owner's vehicle Confirm joining the vehicle collection ,in, This indicates that the group owner's vehicle selects new members to join the current convoy, and then the group owner's vehicle constructs a join request. And send it to the cloud server, where, This is the current timestamp;

[0064] 4a-1-2: To ensure that join requests are initiated by legitimate group owner vehicles, the cloud server selects and... Corresponding registration challenge value And send the challenge value to the group owner's vehicle. ;

[0065] 4a-1-3: Group owner's vehicle Upon receiving the challenge value, retrieve the corresponding auxiliary data from local storage. Then calculate And based on auxiliary data Restore registration response Further calculate the requested authentication key ;

[0066] 4a-1-4: Group Owner Vehicle Calculation Authentication Tag Send to the cloud server ;

[0067] 4a-2: Cloud server generates and updates group key distribution information

[0068] The cloud server received Then, the request in 4a-1-1 is parsed locally. First, the cloud server checks the timestamp. Is it within a valid time window and Is it a group identifier? If the vehicle belonging to the current legitimate group owner is successfully verified, it will be retrieved from the local storage. Corresponding response and calculate Subsequent verification Is it equal to If verification fails, the request to join is rejected; otherwise, further checks are performed. After verifying that all vehicle identities have been registered and verified, set up... ,in, This indicates the set of vehicles for which the cloud server needs to distribute group keys, including newly joined vehicles and the group owner's vehicle, and then performs the following operations:

[0069] 4a-2-1: For each The cloud server randomly selects the corresponding challenge. and obtain the corresponding registration response. Using cloud server key pairs and vehicle public key ,calculate Obtain the auxiliary message set and a collection of challenges Finally, calculate ;

[0070] 4a-2-2: The cloud server generates a truly random number as the new group key. For each ,calculate Then, the Chinese Remainder Theorem is used to package all the ciphertext. The specific process is as follows: cloud server selects the modulus set. ,calculate For each vehicle ,calculate as well as Constructing Encapsulated Ciphertext mod ;

[0071] 4a-2-3: Cloud Server Computing Then broadcast To all The vehicles;

[0072] 4a-3: Vehicle recovery updated group key

[0073] vehicle Received update message broadcast by cloud server Afterwards, if the conditions are met Then perform the following operations to restore the new group key:

[0074] 4a-3-1: Vehicles From the Challenge Collection Obtain challenge points corresponding to your own identity. Subsequently, the vehicle Retrieve corresponding auxiliary data from local storage. and calculate Using auxiliary data Restore registration response ;

[0075] 4a-3-2: Vehicles From auxiliary message set Extract the corresponding auxiliary message and execute Calculate the corresponding symmetric key ;

[0076] 4a-3-3: Vehicles From the set of moduli Obtain the corresponding modulus And use the Chinese Remainder Theorem to recover its own ciphertext. Subsequently, the vehicle was decrypted to obtain the new group key. ;

[0077] 4a-3-4: The vehicle further verifies the integrity and authenticity of the cloud server broadcast message. Is it equal to If verification fails, the vehicle rejects the update message; otherwise, the vehicle accepts it. This serves as the new group key and updates the local group state.

[0078] 4a-4: The group owner's vehicle distributes the updated group key to existing members.

[0079] Because the cloud server only sends requests to those joining the collection. The vehicle distribution group key is used by existing members. The vehicles in the group need to have their keys updated by the group owner's vehicle. Successfully recovered and verified Then, using the current group key Encrypt the new group key Subsequently, the group owner's vehicle Broadcast to existing members in the current group Existing members Upon receiving the ciphertext, decrypt it using the current group key. After successful decryption, existing members will transfer the local group key from [the original group key]. Updated to The group joining process is now complete; newly joined vehicles, the group owner's vehicle, and existing members have all received new group keys. And can use this key for subsequent secure communication;

[0080] 4b: Vehicle Exit

[0081] When some vehicles in the convoy leave the group, to ensure that the leaving vehicles cannot continue to access subsequent group communications, a new group key is generated and distributed only to the remaining members. Let the current group identifier be . The current group key is The current group owner's vehicle is For simplicity, it is assumed that the exit set does not include the current group owner's vehicle. ,Right now, You cannot leave the group; doing so will be considered as disbanding the group.

[0082] 4b-1: Confirm the exit from the vehicle group

[0083] When the group owner's vehicle When deciding to remove some vehicles from a fleet group, confirm the vehicle exit from the vehicle group. ,in This indicates the set of vehicle identities that will be excluded from the next round of group discussions; additionally, vehicle members proactively send a request to the group owner's vehicle to leave the group. ,in: Indicates an application to withdraw from vehicle registration; This indicates the current timestamp. After the group owner's vehicle receives the leave request, it will... Vehicles joining and leaving the collection And finally determine the final exit set. ;

[0084] 4b-2: Generate Exit Update Materials

[0085] The group owner's vehicle is based on the exit from the group. Check if all vehicles belong to the current group member set. After successful verification, perform the following operations:

[0086] 4b-2-1: Calculate the new member set for the group owner's vehicle. At the same time, a new set of moduli is selected. ,in, ;

[0087] 4b-2-2: The group owner's vehicle selects the next unused random value from the locally maintained hash chain. Then calculate the new group key. ;

[0088] 4b-2-3: For each The group owner obtains the vehicle's public key. and execute Obtain the key and auxiliary message ,calculate Then encrypt the new group key. Obtain the auxiliary message set ;

[0089] 4b-2-4: Group Owner's Vehicle Calculation For each ,calculate as well as Then, the Chinese Remainder Theorem was used to construct the packaged ciphertext. ;

[0090] 4b-2-5: Group Owner Vehicle Calculation Authentication Tag Then to the remaining group members Broadcast exit update message ;

[0091] 4b-3: Vehicle recovery updated group key

[0092] Remaining vehicles Received a message from the group owner's vehicle broadcasting that they had left the group. Then, perform the following steps to restore the new group key;

[0093] 4b-3-1: Vehicles From auxiliary message set Obtain the corresponding auxiliary message Then execute and calculate ;

[0094] 4b-3-2: Vehicles From the new set of moduli Obtain the corresponding modulus Using the Chinese Remainder Theorem to recover its corresponding ciphertext ;

[0095] 4b-3-3: Vehicle decryption using session key ;

[0096] 4b-3-4: Further verification of the vehicle Is it equal to If verification fails, the vehicle rejects the update message; otherwise, it accepts it. Use it as the new group key and update the local group state.

[0097] The reason for adopting the above-mentioned update method in this invention is that the process of adding a vehicle involves the authentication of new members and the generation of key distribution materials, which requires the registration information maintained by the cloud server to complete trusted authentication; while the process of leaving a vehicle only involves the key update between existing group members, which does not require the authentication of new members, and the group owner's vehicle can independently complete the group key update using the locally maintained hash chain. This design, while ensuring system security, reduces the continuous involvement of the cloud server in the group update process, reduces the computing and communication load of the cloud server, avoids it becoming a system performance bottleneck, and improves the real-time performance and scalability of group key management in a dynamic vehicle network environment.

[0098] Compared with the prior art, the present invention has the following beneficial technical effects and significant technical progress:

[0099] 1) This invention utilizes a physically unclonable function to establish a unique binding relationship between vehicle identity and hardware physical characteristics, and combines a post-quantum authentication key negotiation mechanism to achieve trusted authentication and secure key establishment between the vehicle and the cloud server, thereby improving the security of group communication in a dynamic vehicle network environment.

[0100] 2) This invention utilizes a high-quality random source provided by a cloud server to generate group keys and random parameters during the key update process, avoiding the problem of insufficient unpredictability of random numbers caused by vehicle nodes being limited by computing resources and random entropy source conditions, thereby improving the randomness and security of the group key generation process.

[0101] 3) This invention uses the Chinese Remainder Theorem to package ciphertext for different vehicles, enabling the cloud server to distribute key materials for multiple vehicles with a single broadcast message, thereby reducing communication overhead during the group key establishment process.

[0102] 4) This invention supports dynamic joining and leaving of vehicles, and ensures key security during the member change process through a group key update mechanism, while meeting forward security and backward security requirements. Attached Figure Description

[0103] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0104] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the method proposed in this invention will be described in detail below with reference to specific embodiments.

[0105] In this embodiment, the system mainly includes a Trusted Authentication Center (CA), a cloud server, and multiple vehicle nodes. The CA is responsible for system parameter generation, entity registration, and authentication information management; the cloud server is responsible for group key generation and auxiliary distribution; and the vehicle nodes form a fleet group, which is managed through a group leader vehicle. The group key management method of this invention includes a system initialization phase, a registration phase, a group creation phase, and a group update phase.

[0106] In this embodiment, system security parameters Set as and set as That is, the group key, session key, and the output length of the cryptographic collision-resistant hash function are all 10 ... Bit. Assume the number of vehicles in the vehicle platoon is... In this embodiment, we take This is used to simulate large-scale vehicle platooning scenarios. A length of [length missing] is used during group key updates. The system uses a hash chain. It employs a CRT-based ciphertext encapsulation mechanism, with the modulus pool size matching the number of vehicles in the vehicle platoon group. At this point, a modular pool is pre-generated. Each modulus satisfies And any two moduli satisfy The parameters mentioned above represent only one set of experimental parameters and can be used to ensure the correctness of ciphertext packing and aggregation and vehicle group key recovery during the group key distribution process.

[0107] See Figure 1 The overall process of this embodiment is as follows:

[0108] 1) System initialization phase

[0109] CA input security parameters Generate system common parameters CA Selected Quantum Authentication Key Agreement Protocol and execute Obtain authentication key negotiation public parameters At the same time, the CA chose a symmetric encryption scheme. and cryptographic collision-resistant hash functions Message authentication code Then, CA sets system parameters. And generate a CRT analog-to-digital pool. ,in, And any two moduli satisfy Ultimately, the CA released the system parameters. .

[0110] 2) Registration phase

[0111] The registration phase includes cloud server registration and vehicle registration.

[0112] Cloud server registration:

[0113] Cloud servers through Generate authentication key pairs The cloud server submits its identity information and public key information to the CA. The CA verifies the cloud server's identity, and upon successful verification, transfers the cloud server's identity information and public key to the CA. Binding is performed, and the corresponding certificate is issued. After receiving the certificate, the cloud server verifies it and stores the relevant registration information locally for identity authentication during subsequent cloud server participation in group key generation and distribution processes.

[0114] Vehicle registration:

[0115] Vehicle registration includes two processes: vehicle certificate registration and vehicle PUF registration.

[0116] First, the vehicle pass Generate authentication key pairs and submit vehicle identification to CA and public key information The CA verifies the vehicle's identity. Once verification is successful, it issues a corresponding certificate to bind the vehicle's identity and public key information.

[0117] Subsequently, the vehicle A PUF registration request is initiated to the cloud server via a secure channel. After verifying the validity of the vehicle certificate, the cloud server selects multiple random challenge values ​​for the vehicle. Send challenge values ​​to the vehicle After receiving the challenge values, the vehicle inputs each challenge into its own PUF and calculates the corresponding response. And further calculate auxiliary data. Subsequently, the vehicle saves the challenge response set. Set of auxiliary information corresponding to the challenge Send to the cloud server and erase locally ,save After receiving the information returned by the vehicle, the cloud server saves the corresponding challenge-response pair. It is used for vehicle identity authentication in the subsequent group creation and group update stages.

[0118] 3) Group creation stage

[0119] After vehicle registration is completed, when multiple vehicles need to form a dynamic fleet for collaborative driving and safe communication, one of the vehicles will act as the group leader vehicle. The system is responsible for initiating the group creation process. In this embodiment, the group creation phase includes four processes: group creation request, cloud server verification of the creation request, generation of group key distribution materials, and vehicle recovery of the group key.

[0120] 3-1: Group Creation Request

[0121] When the vehicle When a fleet group needs to be established, the initial set of group members is determined based on the vehicle status within the current communication range. .in, This parameter represents the vehicle identifier of the group owner; the other parameters represent the vehicle identifiers participating in group communication. Let the current group round be... Since this process is the group creation phase, therefore settings are required. Subsequently, the group owner requested the creation of a vehicle-based group. ,in, This is the current timestamp. To ensure the legitimacy of the request source, the cloud server selects the corresponding challenge value from the vehicle registration information. And generate group identifiers for the groups to be created. Send to the group owner's vehicle .vehicle Upon receiving the challenge value, read the corresponding auxiliary data from local storage. and calculate The registration response was then restored using an error correction algorithm. The group owner's vehicle further calculates the requested authentication key. And calculate the certification label Finally, the vehicle Will Send to the cloud server.

[0122] 3-2: Cloud Server Verification Request

[0123] After receiving the creation request, the cloud server first checks the timestamp. Does it meet the validity requirements, and obtain it based on the registration information? Then calculate and verify Is it equal to If verification fails, the creation request is rejected; otherwise, further verification is performed. After verifying that all vehicles have completed registration, the cloud server executes the group key generation and distribution process. First, it selects from the CRT modulus pool... Subsequently, for each Choose the corresponding challenge and obtain the registration response. Using cloud server authentication key pairs and vehicle public key ,implement get ,calculate .

[0124] 3-3: Cloud server generates group key distribution materials

[0125] The cloud server generates a truly random number as the initial group key. For each vehicle ,calculate Then, CRT was used to aggregate and package all the ciphertext, resulting in... Meanwhile, the cloud server generates truly random numbers. and calculate Final calculation and broadcast To group members.

[0126] 3-4: Vehicle recovery group key

[0127] vehicle Upon receiving the broadcast message, the corresponding key is recovered based on its own identity. First, the PUF response is recovered. Then, auxiliary messages were used. ,calculate and obtained The vehicle utilizes its own module ,recover Then decryption. Vehicle verification Is it equal to After successful verification, the vehicle accepts the group key. .like Then the group owner's vehicle will be restored. This random value is then used to generate a hash chain for updating the group key when a vehicle subsequently exits. As the initial value for the hash chain, and to generate .in, The default hash chain length is used. The group owner's vehicle uses random values ​​from the hash chain in reverse order as the group key update parameters when a member leaves.

[0128] 4) Group update phase

[0129] In a dynamic vehicle-to-everything (V2X) environment, the members of a vehicle platoon may change due to changes in tasks, communication range, or voluntary departure. Therefore, it is necessary to dynamically update the group member set and group key. In this embodiment, the group update phase includes the vehicle joining process and the vehicle leaving process.

[0130] 4a: Vehicle joining

[0131] When a newly registered vehicle needs to join an existing fleet group, the group owner's vehicle... It is responsible for determining the set of vehicles that can be allowed to join, and for generating materials for new member authentication and key update through the cloud server.

[0132] 4a-1: Initiating a group join request

[0133] Let the current group status be ,in, Indicates the group identifier. Indicates the current group round. When the group owner's vehicle... When a new vehicle needs to be added to the current group, the set of vehicles to be added is determined based on the vehicle task requirements. Subsequently, the group owner requested to add the vehicle configuration. ,in, This represents the current timestamp. To verify the legitimacy of the join request source, the cloud server selects a location similar to the group owner's vehicle. Corresponding registration challenge value And send it to the group owner's vehicle.

[0134] After the group owner's vehicle receives the challenge value, it retrieves the corresponding auxiliary data from local storage. and calculate Then, an error correction algorithm was used to recover the data. Further calculate the requested authentication key. and generate authentication labels. Finally, the group owner's vehicle sent a message to the cloud server. .

[0135] 4a-2: Cloud server generates and adds updated materials

[0136] After receiving the join request, the cloud server first checks the timestamp. Is it within a valid time window? Is this vehicle the legitimate owner of the current group? Challenge value Does it belong to the vehicle registration challenge set? After verification, the cloud server obtains the registration information. And calculate the authentication key. Subsequent verification Is it equal to If verification fails, the request to join is rejected; otherwise, further checks are performed. Check if all vehicles in the list are registered. After successful verification, the cloud server constructs a key distribution set. .in, This includes newly added vehicles and vehicles owned by the group owner.

[0137] Subsequently, the cloud server performs the following operations: For Choose the corresponding challenge and obtain the registration response. Using cloud server key pairs ( and vehicle public key ,implement get and calculate Subsequently, the cloud server generates a new group key. .for ,calculate Cloud servers further utilize CRT for... Encapsulation is performed to obtain Finally, cloud server computing authentication label. And broadcast updates. to Vehicles in the middle.

[0138] 4a-3: New members restore the updated group key

[0139] vehicle Upon receiving an update message, similar to the group creation phase, it first restores its own PUF response. Then, auxiliary messages are used for calculation. The vehicle is restored based on its own module. And decrypt to obtain Vehicle verification Then accept the new group key.

[0140] 4a-4: The group owner's vehicle synchronizes the updated group key with existing members.

[0141] Because cloud servers only provide... When distributing updated materials to vehicles within the group, existing group members cannot directly obtain the new group key. Therefore, the group owner's vehicles... Successfully recovered Then, using the old group key Encrypt new group key Then broadcast To the original group members. The original members used... Decryption Complete the vehicle addition process.

[0142] 4b: Vehicle Exit

[0143] When some vehicles in the convoy leave the group, the group key needs to be regenerated, and it must be ensured that the departing vehicles cannot access subsequent communication. Let the current group state be... The current group key is .

[0144] 4b-1: Vehicle Exit Request and Exit Set Determination

[0145] When the group owner's vehicle If some vehicles need to be removed, confirm exiting the collection. In addition, vehicles can also proactively send a request to the group owner to leave the group. After receiving a leave request, the group owner determines the final leave group based on the current group status. During the vehicle exit update process, the next unused hash chain value is selected sequentially from the end of the current hash chain and recorded as... .

[0146] 4b-2: Generate Exit Update Materials

[0147] Group owner vehicle inspection After successful verification, update the member set. Then, the next unused random value is selected from the locally maintained hash chain. And calculate the new group key. Subsequently, regarding The group owner's vehicle used vehicle authentication information Generate key protection material And using CRT to... Encapsulation Finally, the authentication label is calculated. And broadcast an exit update message to the remaining members.

[0148] 4b-3: Restore the new group key for the remaining vehicles

[0149] After receiving the exit update message, the remaining vehicles recover the corresponding encrypted data based on their own authentication information. Then decryption. Vehicle verification After passing, accept Use it as the new group key and update the local group state.

[0150] Through the above-described vehicle joining and leaving process, the present invention can realize the security key update during the change of group members in a dynamic vehicle network environment, ensuring that newly joined vehicles cannot obtain historical communication keys, and that vehicles leaving cannot obtain subsequent communication keys.

[0151] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements made without departing from the principle of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A method for managing group keys in a vehicle-to-everything (V2X) network, characterized in that, A combination of Physically Unclonable Function (PUF), post-quantum authentication key negotiation, cloud-based true random number generation, and auxiliary key distribution is employed to achieve secure vehicle group establishment, dynamic member management, and group key updates. Multiple key ciphertexts are packaged and broadcast using the Chinese Remainder Theorem (CRT), enabling the cloud server to distribute keys to multiple target vehicles with a single broadcast. A hash chain mechanism is also used to ensure continuous group key updates after a member leaves. The group key management method specifically includes the following stages: 1) System initialization phase 1-1: Certification Authority (CA) inputs security parameters ; 1-2: Selecting the Post-Quantum Authentication Key Negotiation Protocol ,in, Input security parameters to initialize the system algorithm. And generate common protocol parameters; This is a key generation algorithm that generates long-term public-private key pairs for entities based on public parameters. The key negotiation initiation algorithm is initiated by the initiator, who generates the initiation message for authentication key negotiation. The key negotiation response algorithm involves the responder processing the initiating message and generating a response message, ensuring that both communicating parties negotiate and obtain the same session key; finally, execution... Generate authentication key negotiation public parameters ; 1-3: Choose a symmetric encryption scheme ,in, For encryption algorithms, For decryption algorithms; 1-4: Select five cryptographically collision-resistant hash functions and message authentication code ,in, This refers to the length of the symmetric key and the output length of the cryptographically collision-resistant hash function; 1-5: Select system parameters ,in, Indicates the size of the CRT analog-to-digital pool. This represents the number of challenge-response pairs pre-registered for each vehicle. Indicates the length of the hash chain. Represents the set of positive integers; 1-6: Pre-generating the CRT Module Pool Each modulus satisfies And any two moduli are coprime, i.e. ; 1-7: Publish System Parameters ; 2) Registration phase During this phase, the cloud server and each vehicle first register with the Certificate Authority (CA) through a secure channel, and the CA maintains their public keys and certificates. In addition to registering with the CA, each vehicle also registers individually with the cloud server through a secure channel, as described below: Cloud server registration: The cloud server registers with a Certificate Authority (CA) and obtains a long-term public key certificate for subsequent authentication key negotiation. The specific process is as follows: 2-1-1: Cloud server generates authentication key and negotiates key pair ,in For public key, Use the private key, and then share your identity and public key through a secure channel. Send to the Certificate Authority (CA); 2-1-2: The Certificate Authority (CA) received... Next, the registration request is verified. If the request is valid, the certification center issues a certificate. This is used to bind the cloud server identity and public key, and then... Recorded in the local certificate list and transmitted via a secure channel Send to the cloud server; 2-1-3: The cloud server received... Next, the certificate will be verified. Once verification is successful, it will be... Stored locally; Vehicle registration: Vehicle registration includes: certificate registration with a Certificate Authority (CA) and PUF registration with a cloud server. The certificate registration process with the CA is as follows: Vehicle Generate authentication key and negotiate key pair and its identity and public key Send it to the Certificate Authority (CA) and follow the same process as registering with the cloud server. Obtain the certificate after verification. This certificate is used to bind the vehicle's identity to its public key; The PUF registration process with the cloud server is as follows: 2-2-1: Vehicles Will Send to the cloud server; 2-2-2: After receiving the certificate, the cloud server verifies it. The validity of the certificate is checked; if the certificate is valid, the cloud server generates a set of challenges. and will Send to vehicle ; 2-2-3: Vehicles Received After that, for each , will challenge Input its physically non-clonable function and obtain the response. And calculate the corresponding auxiliary data. ; An error correction mechanism was introduced. ,in, To assist the data generation algorithm, during the vehicle registration phase, the PUF response is used. Generate auxiliary data ; In response to the recovery algorithm, during the authentication phase, the PUF response affected by noise is used. and auxiliary data Restore stable response If recovery fails, output This indicates an error flag indicating that the PUF response recovery failed. 2-2-4: Vehicles Set a challenge response set and the set of auxiliary information corresponding to the challenge ,Will Send to cloud server to erase and store locally ; 2-2-5: The cloud server received... Afterwards, Stored locally; 3) Group creation stage In this stage, the group owner's vehicle first sends a group creation request to the cloud server. After the cloud server completes the request authentication, it generates an initial group key for the group and broadcasts it to the group members. After each member recovers and verifies the group key, the group creation is completed. The specific process is as follows: 3-1: Initiate a group creation request When the vehicle When forming a convoy with nearby vehicles for collaborative driving and safe communication, the vehicle acting as the group leader initiates a group creation request to the cloud server. The specific process is as follows: 3-1-1: Group owner's vehicle Determine the initial group member set ,in, Indicates vehicle identity, while set Includes the group owner's vehicle And the vehicles selected to join the group, set This indicates the group round. Since we are currently in the group creation phase, we let... Subsequently, the group owner set up vehicle settings. And send it to the cloud server. This is the current timestamp; 3-1-2: The cloud server received... Later, from the vehicle Select a registered challenge from the registration information. And generate a unique group identifier for the group to be created. ,send Give the group owner a vehicle ; 3-1-3: The group owner's vehicle received the message. Then, read the corresponding auxiliary data from the local machine. , will challenge Inputting a physically non-cloning function yields and using auxiliary data Restore the corresponding response Then calculate the request authentication key. ,in, Represented as a splicing symbol; 3-1-4: Group Owner Vehicle Calculation and Authentication Tag and send to the cloud server ; 3-2: Verify the creation request The cloud server received Then, first check the timestamp. Whether it is within the valid time window; then according to the selection in 3-1-2. Read the corresponding response Calculate the authentication key for the request. and verify Is it equal to If verification fails, the request is rejected; otherwise, the member set is further verified. Check if the vehicle's identity is legitimate; if the verification is successful, accept the request. 3-3: Distribute the group key 3-3-1: The cloud server selects a set of moduli from the moduli pool. ,in, ; 3-3-2: For each The cloud server selects the corresponding challenge. and obtain the corresponding registration response. Using cloud server key pairs and vehicle public key ,implement Obtain the key and auxiliary messages Generate auxiliary message set and a collection of challenges Then calculate ; 3-3-3: The cloud server generates a truly random number and sets it as the initial group key. For each ,calculate Then calculate And for each ,calculate as well as Finally, calculate the packaged ciphertext. ; Note: To ensure the correctness of the encrypted data packaging and recovery process in 3-3-3, firstly, the vehicle... Corresponding ciphertext Convert to non-negative integer For vehicles Allocation modulus Should meet The packed ciphertext constructed based on the Chinese Remainder Theorem satisfy Therefore, vehicles Through calculation Losslessly recover the corresponding ciphertext integer, and recover the ciphertext. If the complete ciphertext does not meet the requirements Then it is divided into A ciphertext block Make each ciphertext block satisfy The cloud server performs CRT packaging on the ciphertext blocks with the same sequence number in all vehicles, and encapsulates the resulting multiple CRT aggregate values ​​in the same broadcast message; the vehicles restore each ciphertext block through modulo operation, and then splice and decode them in a preset order to restore the complete ciphertext, avoiding the loss of ciphertext information due to modulo reduction; 3-3-4: Generating truly random numbers on a cloud server Calculate ciphertext ; 3-3-5: Cloud Server Computing Authentication Label Then broadcast to all group members ; 3-4: Vehicle recovery group key 3-4-1: Vehicles Upon receiving a broadcast message, first obtain the corresponding challenge value. and auxiliary data and calculate Subsequently, based on auxiliary data Restore registration response ; 3-4-2: Vehicles Get the corresponding auxiliary message ,calculate ; 3-4-3: The vehicle is based on its corresponding module. Recover the corresponding ciphertext The group key was then obtained through decryption. ; 3-4-4: Further verification and certification label for vehicles Is it equal to If verification fails, the broadcast message is rejected; otherwise, the group key is accepted. And update the local group status; for the group owner's vehicle Further calculations ,by As the initial value of the hash chain, and calculate The group owner's vehicle uses random values ​​from the hash chain in reverse order as the group key update parameters when subsequent vehicles leave; 4) Group update phase In a highly dynamic fleet environment, vehicle members may join or leave the group at any time. It is necessary to synchronize and update the group member status and group key. The group update phase includes the vehicle joining process and the vehicle leaving process. 4a: Vehicle addition: 4a-1: Initiating a group member join request When the group owner's vehicle To the current team group When a new registered vehicle is added to the group, the group owner is responsible for determining the set of vehicles allowed to join the next round of the group. The specific process is as follows: 4a-1-1: Group owner's vehicle Confirm joining the vehicle collection ,in, This indicates that the group owner's vehicle selects new members to join the current convoy, and then the group owner's vehicle constructs a join request. And send it to the cloud server, where, This is the current timestamp; 4a-1-2: To ensure that join requests are initiated by legitimate group owner vehicles, the cloud server selects and... Corresponding registration challenge value And send the challenge value to the group owner's vehicle. ; 4a-1-3: Group owner's vehicle Upon receiving the challenge value, retrieve the corresponding auxiliary data from local storage. Then calculate And based on auxiliary data Restore registration response Further calculate the requested authentication key ; 4a-1-4: Group Owner Vehicle Calculation Authentication Tag Send to the cloud server ; 4a-2: Cloud server generates and updates group key distribution information The cloud server received Then, the request in 4a-1-1 is parsed locally. First, the cloud server checks the timestamp. Is it within a valid time window and Is it a group identifier? If the vehicle belonging to the current legitimate group owner is successfully verified, it will be retrieved from the local storage. Corresponding response and calculate Subsequent verification Is it equal to If verification fails, the request to join is rejected; otherwise, further checks are performed. After verifying that all vehicle identities have been registered and verified, set up... ,in, This indicates the set of vehicles for which the cloud server needs to distribute group keys, including newly joined vehicles and the group owner's vehicle, and then performs the following operations: 4a-2-1: For each The cloud server randomly selects the corresponding challenge. and obtain the corresponding registration response. Using cloud server key pairs and vehicle public key ,calculate Obtain the auxiliary message set and a collection of challenges Finally, calculate ; 4a-2-2: The cloud server generates a truly random number as the new group key. For each ,calculate Then, the Chinese Remainder Theorem is used to package all the ciphertext. The specific process is as follows: cloud server selects the modulus set. ,calculate For each vehicle ,calculate as well as Constructing Encapsulated Ciphertext mod ; 4a-2-3: Cloud Server Computing Then broadcast To all The vehicles; 4a-3: Vehicle recovery updated group key vehicle Received update message broadcast by cloud server Afterwards, if the conditions are met Then perform the following operations to restore the new group key: 4a-3-1: Vehicles From the Challenge Collection Obtain challenge points corresponding to your own identity. Subsequently, the vehicle Retrieve corresponding auxiliary data from local storage. and calculate Using auxiliary data Restore registration response ; 4a-3-2: Vehicles From auxiliary message set Extract the corresponding auxiliary message and execute Calculate the corresponding symmetric key ; 4a-3-3: Vehicles From the set of moduli Obtain the corresponding modulus And use the Chinese Remainder Theorem to recover its own ciphertext. Subsequently, the vehicle was decrypted to obtain the new group key. ; 4a-3-4: The vehicle further verifies the integrity and authenticity of the cloud server broadcast message. Is it equal to If verification fails, the vehicle rejects the update message; otherwise, the vehicle accepts it. This serves as the new group key and updates the local group state. 4a-4: The group owner's vehicle distributes the updated group key to existing members. Because the cloud server only sends requests to those joining the collection. The vehicle distribution group key is used by existing members. The vehicles in the group need to have their keys updated by the group owner's vehicle. Successfully recovered and verified Then, using the current group key Encrypt the new group key Subsequently, the group owner's vehicle Broadcast to existing members in the current group Existing members Upon receiving the ciphertext, decrypt it using the current group key. After successful decryption, existing members will transfer the local group key from [the original group key]. Updated to The group joining process is now complete; newly joined vehicles, the group owner's vehicle, and existing members have all received new group keys. And can use this key for subsequent secure communication; 4b: Vehicle Exit When some vehicles in the convoy leave the group, to ensure that the leaving vehicles cannot continue to access subsequent group communications, a new group key is generated and distributed only to the remaining members. Let the current group identifier be . The current group key is The current group owner's vehicle is For simplicity, it is assumed that the exit set does not include the current group owner's vehicle. ,Right now, You cannot leave the group; doing so will be considered as disbanding the group. 4b-1: Confirm the exit from the vehicle group When the group owner's vehicle When deciding to remove some vehicles from a fleet group, confirm the vehicle exit from the vehicle group. ,in This indicates the set of vehicle identities that will be excluded from the next round of group discussions; additionally, vehicle members proactively send a request to the group owner's vehicle to leave the group. ,in: Indicates an application to withdraw from vehicle registration; This indicates the current timestamp. After the group owner's vehicle receives the leave request, it will... Vehicles joining and leaving the collection And finally determine the final exit set. ; 4b-2: Generate Exit Update Materials The group owner's vehicle is based on the exit from the group. Check if all vehicles belong to the current group member set. After successful verification, perform the following operations: 4b-2-1: Calculate the new member set for the group owner's vehicle. At the same time, a new set of moduli is selected. ,in, ; 4b-2-2: The group owner's vehicle selects the next unused random value from the locally maintained hash chain. Then calculate the new group key. ; 4b-2-3: For each The group owner obtains the vehicle's public key. and execute Obtain the key and auxiliary message ,calculate Then encrypt the new group key. Obtain the auxiliary message set ; 4b-2-4: Group Owner's Vehicle Calculation For each ,calculate as well as Then, the Chinese Remainder Theorem was used to construct the packaged ciphertext. ; 4b-2-5: Group Owner Vehicle Calculation Authentication Tag Then to the remaining group members Broadcast exit update message ; 4b-3: Vehicle recovery updated group key Remaining vehicles Received a message from the group owner's vehicle broadcasting that they had left the group. Then, perform the following steps to restore the new group key; 4b-3-1: Vehicles From auxiliary message set Obtain the corresponding auxiliary message Then execute and calculate ; 4b-3-2: Vehicles From the new set of moduli Obtain the corresponding modulus Using the Chinese Remainder Theorem to recover its corresponding ciphertext ; 4b-3-3: Vehicle decryption using session key ; 4b-3-4: Further verification of the vehicle Is it equal to If verification fails, the vehicle rejects the update message; otherwise, it accepts it. Use it as the new group key and update the local group state.

Images