Efficient electronic voucher verification method based on homomorphic aggregation in internet of vehicles cloud environment

Abstract

The application provides a kind of high-efficiency electronic voucher verification method based on homomorphic aggregation under the cloud environment of Internet of Vehicles, belongs to the technical field of Internet of Vehicles security.Its technical scheme is: including the following steps: S10 system initialization;S20 entity registration;S30, vehicle key generation;S40, vehicle pseudonym generation;S50, single vehicle signature generation;S60, vehicle homomorphic aggregation signature;S70, homomorphic aggregation signature verification.The beneficial effects of the application are: the application reduces the calculation overhead of electronic voucher message verification process, and relieves the computing pressure of the cloud;Through the certificateless homomorphic aggregation signature message verification protocol and dynamic pseudonym technology, anonymous privacy protection is realized, the reliability of user identity is guaranteed;At the same time, the electronic voucher signature message sent by the vehicle is also guaranteed to be unforgeable, and the integrity, authentication and non-repudiation of the message are realized, and the anonymity and unlinkability of the vehicle identity are realized.

Description

Technical Field

[0001] This invention relates to the field of vehicle network security technology, and in particular to an efficient electronic credential verification method based on homomorphic aggregation in a vehicle network cloud environment. Background Technology

[0002] Traffic accident determination refers to the traffic management department's inspection and investigation of the accident scene, determination of the cause of the accident, and determination of liability based on the degree of fault of the parties involved. Accident determination relies on on-site evidence. With the development of vehicle-to-everything (V2X) intelligent technology, the integration of people and vehicles is becoming increasingly close, making the need for vehicle-related evidence collection in accidents more urgent. Vehicle evidence collection focuses on electronic data (hereinafter referred to as electronic evidence) generated by in-vehicle systems such as event data recorders (EDR), dashcams, and driving recorders. According to the definitions in the Civil Procedure Law, Criminal Procedure Law, and Administrative Procedure Law, electronic evidence generated by in-vehicle systems is one of the eight major categories of evidence in judicial definitions. However, the technology for collecting electronic evidence has progressed slowly, mainly for the following reasons:

[0003] 1. Due to the involvement of manufacturers' trade secrets and users' personal privacy, there is currently no suitable solution to balance the large amount of data in vehicle systems.

[0004] 2. Vehicle-mounted systems have vulnerabilities when collecting evidence. For example, they are highly exposed to the outside world. As long as someone studies how the system works internally, they can connect to it through external devices, tamper with the data it generates, and forge evidence to evade responsibility.

[0005] 3. In addition, in some accidents, vehicles are severely damaged by burning, burying, etc., making it impossible to obtain electronic voucher data from the vehicle system, thus making it impossible to determine liability.

[0006] With the development of IoT sensing and communication technologies, vehicles use onboard sensing units, roadside data acquisition modules, and vehicle-to-infrastructure (V2X) communication to collect real-time vehicle operation data. This integrates V2X communication (vehicle-to-X, connecting people, vehicles, and roads) to build a data platform for monitoring large-scale real-time vehicle operation information, leading to the concept of the Internet of Vehicles (IoV). The IoV is an open, heterogeneous network composed of a Vehicular Ad-Hoc Network (VANET) and the mobile internet. It achieves intelligent transportation and provides services such as traffic safety and infotainment through real-time interconnection and sensing between vehicles, roads, and management platforms. Because of its interconnectivity between vehicles, roads, and processing platforms, the IoV can be applied to intelligent transportation, autonomous driving, vehicle dynamic management, and real-time data services.

[0007] Meanwhile, with the emergence of cloud computing technology, cloud storage has gradually become the mainstream storage method and development trend for vehicle-to-everything (V2X) data. The "vehicle-cloud" network architecture can play a significant role in the aggregation, scheduling, management, and application of massive amounts of vehicle data. Compared with traditional storage systems, cloud storage systems have the following advantages:

[0008] 1) Cloud storage can integrate numerous inexpensive storage media into a storage resource pool. Users can rent resources from the pool from cloud service providers according to their actual storage needs, effectively solving problems such as limited local storage resources.

[0009] 2) The cloud storage system provides users with a dedicated access interface for accessing data, and security is maintained by a professional provider, enabling users to conveniently access the cloud anytime, anywhere.

[0010] 3) Cloud storage service providers have their own set of security protection mechanisms, which can provide better redundant backup and disaster recovery for user data, and maximize the protection of user data.

[0011] In the context of the Internet of Vehicles (IoV), the massive amounts of electronic credential data generated by intelligent vehicles can be stored and processed remotely in the cloud, which can reduce vehicle-related evidence collection issues. Domestic and international scholars have already conducted relevant research in this area. For example, international scholars Whaiduzzaman M et al. proposed different models and methods for cloud data processing in the IoV in their papers "A survey on vehicular cloud computing," Olariu S et al. in "A survey of vehicular cloud research: Trends, applications and challenges," and Mekki T et al. in "Vehicular cloud networks: Challenges, architectures, and future directions." Domestic scholars Liu Xuehua et al. provided a specific implementation method for cloud forensics in "A Cloud Forensics Method Based on Software-Defined Security and Cloud Forensics Trend Analysis," and Chen Weiwei et al. proposed a blockchain-based electronic forensics scheme under the IoV communication architecture, focusing on privacy protection and efficient storage of vehicle electronic credential data. However, both of these domestic scholars focused on secure forensics, not evidence storage. There are currently many problems with cloud-based storage of vehicle electronic certificate data, such as centralized storage, low message verification efficiency, and high latency, specifically:

[0012] Vehicles upload electronic credential data to a third-party cloud storage platform. Specific users with sharing permissions can directly download target data from the cloud, greatly improving the convenience of data sharing. However, a single autonomous vehicle generates over 4TB of data daily. If all this data is stored and processed in the cloud without filtering, the cloud's requirements for ultra-low latency and ultra-high reliability in data processing will be difficult to meet. Simultaneously, vehicle nodes in the vehicle network communicate wirelessly with roadside units, transferring data to the cloud. Security issues arising from wireless communication follow. During communication between vehicles and roadside units, malicious attackers may intercept, tamper with, or delete relevant electronic credentials, leading to the leakage of user privacy and the alteration of specific vehicle driving status data. Therefore, in the cloud, electronic credential messages uploaded by vehicles must be verified before storage to ensure data integrity and traceability. However, due to the high speed of vehicle-to-everything (V2X) communication, the high real-time requirements of messages, and the massive volume of driving status data generated, the traditional one-time verification method becomes a bottleneck for remote cloud processing of electronic credentials in a centralized cloud environment. In a high-density traffic scenario, there might be 180 vehicles within the communication range of a single Restricted Unit (RSU), with each vehicle sending a security message every 300 milliseconds. This means the RSU must verify at least 600 messages per second. Extending to the cloud, the number of RSUs to process becomes enormous. Undoubtedly, this poses a significant challenge to any existing verification scheme. Therefore, academia has proposed an aggregated signature technique to address these issues. The concept of aggregated signatures was first proposed by Boneh et al. in 2003. Aggregated signatures are digital signatures that support aggregation. Through aggregation algorithms, multiple signatures from n different messages from different users can be combined into a single short signature. Therefore, aggregated signatures can effectively reduce the signature size, thereby lowering verification costs. These characteristics make them suitable for vehicular network environments with limited bandwidth and storage.

[0013] The problems mentioned above mainly include the following aspects:

[0014] 1. Vehicle-to-Everything (V2X) architecture

[0015] The Internet of Vehicles (IOV), sometimes called Vehicular Ad-hoc Networks (VANETs), is a new type of multi-hop mobile wireless communication network. It typically consists of a Trusted Authority Center (TA), vehicles with On-Board Units (OBUs), and Roadside Units (RSUs). The TA is responsible for the registration and management of OBUs and RSUs. Users communicate with other vehicles via their OBUs (V2V) and with RSUs via V2I (V2I). Vehicles transmit the information they perceive to RSUs via V2V or V2I wireless communication, and the RSUs then transmit this information to the corresponding servers via wired transmission. Vehicles can then access various application services through the RSUs.

[0016] The specific details of the vehicle-to-everything (V2X) architecture are as follows:

[0017] 1) Onboard Unit (OBU): The vehicle's onboard unit has certain computing and storage capabilities. As a mobile communication entity, it senses underlying data through various deployed smart sensors and communicates with other OBUs and RSUs using wireless communication devices.

[0018] 2) Roadside unit (RSU): Roadside units are usually fixed on both sides of the road and at intersections. Compared with vehicle-mounted units, they have stronger computing and storage capabilities and provide services for vehicle-mounted units to access the network.

[0019] 3) Trusted Authority Center (TA): A Trusted Authority Center is an authoritative organization, usually the local traffic management bureau. Its key distribution agency is mainly used to publish system security parameters and provide registration and authentication services for each node in the system.

[0020] 2. Bilinear mapping

[0021] Let G1 and G2 be the additive cyclic group and the multiplicative cyclic group of order q, respectively (where q is a large prime number). The bilinear pair e: G1 × G1 → G2 satisfies the following property:

[0022] 1) Bilinear, i.e. and ( It is a finite field that does not contain zero elements, satisfying e(aP1,bP2)=e(P1,P2).ab .

[0023] 2) Non-degenerative, i.e. Make e(P1, P2) ≠ 1.

[0024] 3) Computability, i.e. There exists an efficient algorithm to compute e(P1,P2).

[0025] 4) Symmetry, i.e. The expression e(P1, P2) = e(P2, P1) is satisfied.

[0026] 3. Homomorphic signatures

[0027] The concept of homomorphic signatures was proposed by Johnson et al. in 2002. It refers to the ability of any entity to perform homomorphic operations on authenticated data to generate new data and obtain a valid signature of the new data without the need for a signature private key.

[0028] Suppose that the binary operations on the message space M and the signature space σ of the digital signature are ⊙ and ⊙, respectively. If there are two pairs of message signature pairs Where σ1 and σ2 are respectively messages The signature. Let the signature algorithm f be (M, ⊙) to... Homomorphic mapping, i.e. It can be seen that in the same dataset, the signatures of each message vector can be derived from the signatures of other known message vectors without the need for complex signature algorithms.

[0029] The security of homomorphic signature schemes includes unforgeability and privacy. Generally, the strongest security requirements achievable by a homomorphic signature scheme are unforgeability under Adaptive Chosen Message Attack (EUF-CMA) and complete context hiding. Homomorphic signature schemes can be classified according to their homomorphic operation functions into linear homomorphic signatures, polynomial function homomorphic signatures, and fully homomorphic signatures. Linear homomorphic signatures are an efficient, fast, and lightweight signature scheme, the most widely used. They allow any entity to linearly combine signed data to generate new data without a signing private key, and can generate a valid signature for the new data. For example, Boneh et al. designed an efficient network coding signature scheme using linear homomorphic signatures; Lin et al. studied a lattice-based linear homomorphic signature scheme with a shorter public key.

[0030] 4. Homomorphic aggregation signature

[0031] The concept of aggregated signatures, proposed by Boneh et al. in 2003, combines n signatures from n different signers for n different messages into a single short signature, simplifying the verification of these n signatures into a single verification. It is a "batch processing" and "compression technique" in the field of digital signatures, reducing storage space and network bandwidth requirements while improving verification efficiency. In the context of verifying the legality of massive electronic credential message signatures in a connected vehicle cloud storage environment, without aggregated signature technology, each signature would need to be verified individually, which is cumbersome and computationally and storage-intensive. Using aggregated signatures, digital signatures from different users can be compressed into a single signature, and verifying the aggregated signature is equivalent to verifying all individual user signatures before aggregation. Using aggregated signatures not only ensures the integrity of data in cloud storage but also enables public batch verification for data auditing in the cloud, improving verification efficiency.

[0032] Scholars such as Wu Jingwen designed an efficient vehicle network message authentication scheme that protects user privacy using certificateless aggregate signature; scholars such as Yang Xiaodong proposed three types of attacks against certificateless aggregate signature schemes in the vehicle network and provided solutions. The papers "An efficient certificateless aggregate signature with conditional privacy-preserving for vehicular sensor networks," "Efficient certificateless aggregate signature with conditional privacy preservation in IoV," and "Efficient certificateless aggregate signature scheme for performing secure routing in VANETs" all propose solutions to reduce authentication overhead using aggregate signature technology, but they cannot resist the collusion attack of multiple malicious users proposed in the paper "Certificateless aggregate signature scheme secure against fully chosen-keyattacks." The solution proposed in the paper "Research on Identity Privacy Protection Scheme of Vehicle Networking in Edge Computing Scenarios" can resist the collusion attack of malicious users, but still has some unverifiable details. The paper "Research on Security Mechanisms for Information Security Issues of Vehicle Networking" proposes a trusted center to pre-store a user tracking list to track malicious users, but it brings significant storage and management overhead. The solution proposed in the paper "An efficient authentication scheme based on semi-trusted authority in VANETs" includes the generation of vehicle pseudonyms in the message, but it does not design a reliable verification and authentication mechanism by an authoritative institution, allowing malicious vehicles to forge pseudonyms to evade tracking. The paper "Efficient conditional anonymity with message integrity" In the proposed scheme of "and authentication in a vehicular ad hoc network", the roadside unit needs to rely on a trusted center to verify the legitimacy of the vehicle's identity, resulting in low system operating efficiency.

[0033] 5. Certificate-free public-key cryptography

[0034] Certificate-free public-key cryptography, proposed by SSAI-Riyami et al. in 2003, involves a key generation center that generates only a portion of the user's private key. The user's private key consists of a randomly selected secret value and a portion of the private key. Compared to traditional public-key infrastructures and identity-based cryptography, certificate-free public-key cryptography simplifies public key certificate management and solves key escrow issues. In the context of vehicle-to-everything (V2X) architecture, the key generation center cannot escape responsibility even if it intentionally or unintentionally infringes on user privacy. For example, Wang Daxing et al. used a certificate-free aggregate signature scheme to achieve efficient and secure authentication in V2X, ensuring message authentication and non-forgeability. Kumezusa et al. proposed a more suitable scheme for the V2X environment to address the signature forgery problem in the certificate-free aggregate signature scheme proposed by Thumbur et al.

[0035] Based on the above background technology analysis, it can be seen that scholars at home and abroad have tried to use aggregated signature technology to reduce authentication overhead in the Internet of Vehicles, but all of them have various problems and have not considered the authentication efficiency problem in the electronic certificate storage scenario in the Internet of Vehicles cloud environment. Summary of the Invention

[0036] The purpose of this invention is to provide an efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment. This method can ensure the security, immutability, and traceability of vehicle identity privacy data, while also overcoming the shortcomings caused by the huge computational load of V2X electronic credential data verification in the cloud environment. It can efficiently authenticate vehicle electronic credentials under the conditions of user anonymity and data confidentiality.

[0037] The inventive concept of this invention is as follows: Considering the need for both ultra-low latency and high reliability in the rapid movement of vehicles in the Internet of Vehicles (IoV), this invention deploys some computing at the network edge closer to the mobile side, constructing a mobile edge computing system. Simultaneously, addressing the limited computing power of nodes in the IoV, and acknowledging the need for rapid verification of large amounts of traffic status information, a fast verification protocol for anonymous and privacy-preserving certificateless homomorphic aggregation signature messages is designed. The protocol, combining the characteristics of information transmission in the IoV, employs a certificateless public-key cryptography (CL-PKC) system to achieve reliable identity authentication and protect vehicle privacy. The edge cloud uses an auxiliary signature aggregation method to accelerate message verification. Elliptic curve cryptography (ECC) is used to ensure data transmission security. The central cloud uses a homomorphic aggregation verification algorithm to achieve rapid batch verification of messages from multiple vehicles and multiple electronic credentials, and uses pseudonym technology to ensure the privacy of vehicle users is not compromised, enabling traceability of malicious or violating vehicle identities. When verifying massive amounts of electronic credentials, collaborative cloud computing between vehicles, the edge, and the central cloud is adopted, providing services from the nearest location, thus realizing the decentralization of cloud computing resources and improving verification efficiency.

[0038] This invention is achieved through the following measures: a highly efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment, comprising the following steps:

[0039] S1. System Initialization: System initialization is divided into two parts: central cloud initialization and edge cloud initialization. Central cloud initialization refers to the Trusted Authentication Center (TA) in the central cloud layer generating a series of system parameters, including the TA's public key, system hash function, and other common system parameters, by setting the system master key and selecting an elliptic curve. The TA then pre-sets these system parameters into the vehicle's On-Board Unit's (OBU) unmodifiable storage unit and broadcasts them to all entities in the system. Edge cloud initialization, on the other hand, refers to the local authentication center in the edge cloud layer generating its public and private keys and publishing the public key within the local domain system.

[0040] S2, Entity registration, Vehicle V entering the network i and RSU j All entities need to initialize registration. Entities submit their true identity information to the TA. This is to ensure vehicle V i For privacy and to resolve key escrow and certificate management issues, TA provides vehicle V i Calculate the false identity and generate a partial key for it; the remaining key is given by vehicle V. i Generation. Additionally, to ensure the message's unforgeability, RSU... j It is necessary to set its public and private keys, and the TA must publish the relevant parameters to the LC. The LC determines the RSU. j After the region is assigned, RSU will be assigned. j The relevant parameters are stored in the edge cloud server. Finally, the vehicle pre-installs the pseudo-identity and part of the key in the OBU's tamper-proof storage device, RSU. j The private key is stored in its internal, tamper-proof storage device;

[0041] S3. Vehicle key generation: To verify the authenticity of the RSU identity, when vehicle V... i Upon entering a new edge cloud LC region, the RSU public key and deployment location relationship table for that region are downloaded via a secure channel. Subsequently, when vehicle V... i When entering a new RSU area, the secret value of the signature and the vehicle's public key are set, and the private key is pre-set in the OBU. The public key is broadcast to all entities in the system.

[0042] S4. Vehicle pseudonym generation, in order to solve the vehicle V i To prevent privacy breaches during communication and avoid associated attacks, the solution generates a pseudonym as the vehicle's V. i Work status;

[0043] S5. Individual vehicle signature generation: To ensure the integrity and verifiability of the electronic credential message, vehicle V... i Digital signatures are required when uploading electronic certificate messages. (Vehicle V) i First, the validity period of the temporary pseudonym is verified. Then, the electronic certificate and related parameters are initialized, and the electronic certificate is used as the vector space to be signed. Subsequently, vehicle V... i The system uses its generated private key to sign the electronic certificate, pseudonym, public key, and signature-related parameters. Simultaneously, it encrypts the electronic certificate using the public key of the local certification authority (LC), and then transmits the signature and the encrypted electronic certificate through the RSU. j Forwarded to LC;

[0044] S6. Vehicle Homomorphic Aggregate Signature: Since aggregate signatures combine signatures from multiple vehicles into a short signature using a homomorphic signature derivation algorithm, they can improve signature verification efficiency and reduce the computational and storage overhead of edge cloud servers. After generating the homomorphic aggregate signature, the aggregate signature generator in LC sends the aggregate signature, electronic certificate, and corresponding related parameters to the Trusted Authentication Center (TA).

[0045] S7. Homomorphic Aggregate Signature Verification: Since the OBU and LC have already completed the computational tasks of signing and signature aggregation for the central cloud, the central cloud only needs to verify the aggregated signature. If the verification passes, the relevant electronic certificate is valid and is stored as evidence on the central cloud server. When the evidence collection center needs to collect evidence, it can apply to the central cloud for access; otherwise, this set of electronic certificate messages is discarded.

[0046] Further, step S1 includes:

[0047] S11, Central Cloud Initialization

[0048] 1) TA selects a non-singular elliptic curve E p (a,b): y 2 =x 3 +ax+b mod p, where p is a large prime number, and a,b∈F p Meanwhile, in E p Choose a point P on (a,b) as the generator of group G. Let the order of G be q, and let G contain the point Q at infinity.

[0049] 2) TA is randomly selected As the system's master key, calculate the system's public key P. pub =sP;

[0050] 3) TA selects 5 collision-resistant one-way hash functions: H0: H1: H2: H3: H4:

[0051] 4) TA publishing system parameter Params = {E p (a,b),p,q,G,P,P pub ,H0,H1,H2,H3,H4}, retain the master key s.

[0052] S12, Edge Cloud Initialization

[0053] LC i Random selection Use it as its private key, and calculate its public key. LC i Publish public key

[0054] Furthermore, step S2 specifically includes the following steps:

[0055] S21. Vehicle registration is completed at the Trusted Authentication Center (TA). The vehicle submits basic information (license plate number, owner's identity information, etc.) to the TA to complete the registration.

[0056] S22, TA is to ensure vehicle V i Real identity information ID i To protect privacy, a pseudo-identity is generated for it, the process being: through a secure hash function H0: Calculate vehicle V i The process of creating a false identity is as follows: Among them TS i For vehicle registration time. TA will use the vehicle's fake identity Q. i Send to vehicle V i and vehicle V i The vehicle's real identity, hash value, and pseudo identity are stored in the vehicle identity table. When a vehicle is involved in a traffic accident, illegal driving, or other incident requiring legal action, the pseudo identity Q is used. i Submit to TA, TA will Q i The corresponding tuple is retrieved from the vehicle identity table and processed by the following operations: This allows the vehicle's true identity to be obtained, making the identity traceable and retrospective, which facilitates the handling of traffic accidents.

[0057] S23, TA randomly selects a private value. Calculate Y i =α i P, h 1i =H1(Q i ||Y i ||P pub ), y i =α i +sh1i mod q, and put part of the key {Y i ,y i} Stored in vehicle V i In the tamper-proof OBU device, vehicle V i Obtain partial key {Y i ,y i After that, calculate h. 1i =H1(Q i ||Y i ||P pub Verify whether the following equation holds true;

[0058] y i P = Y i +P pub h 1i

[0059] The calculation process is as follows: y i =α i +sh 1i mod q, y i P = α i P+sPh 1i mod q, y i P = Y i +P pub h 1i .

[0060] If true, it means that part of the key comes from a trusted authentication center (TA) and has not been tampered with, so this part of the key should be used; otherwise, vehicle V... i Re-register and apply for a new partial key;

[0061] S24. Before deploying RSUs on the roadside, the vehicle management office shall purchase and initialize RSU equipment. j Select random number As its secret value, RSU j P can be calculated from the public key. kj =β j P;

[0062] S25, RSU j Public key P kj It is sent to the Trusted Certification Authority (TA) via a secure channel. After the TA verifies and confirms, it will issue a valid RSU. j public key information P kj Coordinates of the deployment location Send to the authentication centers of each edge cloud LC;

[0063] S26, LC certification center determines RSU j Check if the message is in its designated region. If not, ignore the message; otherwise, perform an RSU.j The public key information and deployment location coordinates are stored on the edge cloud server in the format shown in the table.

[0064] Further, step S3 is as follows:

[0065] S31, Vehicle V i When entering a new edge cloud LC region, download the public key and deployment location relationship table from the LC edge cloud server and store the public key and deployment location relationship table in the OBU tamper-proof device;

[0066] S32, Vehicle V i Obtain its current location using GPS devices. And calculate The distance between the RSUs locations in the deployment location relationship table is used to retrieve the mapping between the public keys of the RSUs within the shortest effective distance range and their deployment locations, and then put them into the cache area of ​​the OBU.

[0067] S33, Vehicle V i Random selection And obtain the timestamp TS i Calculate R i =r i P, λ = H1(PID) i ,TS i ,R i ), μ=λY i +r i and send the message through RSU j public key P kj encryption: Send to RSU j ;

[0068] S34, RSU j After receiving the message, use the private key β j Decrypt. Verify λ = H1(PID) i ,TS i ,μP-λY i If the verification passes (P), proceed to step S36; otherwise, proceed to RSU. j Using R i encryption: And send to vehicle V i ;

[0069] S35, Vehicle V i receive Then, first use r i Decrypt and verify the validity of the timestamp. If invalid, discard it; otherwise, proceed to step S36.

[0070] S36, RSU j Broadcast its public key information and location coordinates. Vehicle V i This broadcast message is used to retrieve information from the cache area. If a match is found, it indicates that vehicle V... i Drive into RSU j Jurisdiction area; otherwise, discard this RSU broadcast message;

[0071] S37, Vehicle V i with RSU j After successful authentication, a secret value is randomly selected for storage. Calculate X i =x i P;

[0072] S38, Vehicle V i Set the public key to VPK. i ={X i ,Y i The private key is VSK. i ={x i ,y i}, until V i Enter the new RSU area and repeat S32.

[0073] Furthermore, step S4 specifically includes the following steps:

[0074] S41, Vehicle V i After completing the public and private key setup, use RSU. j public key P kj Q i Encryption with timestamps: Then send the encrypted information to RSU. j ;

[0075] S42, RSU j Using private key β j Decryption Get Timestamp TS j Verify TS i The validity of the result is checked; if invalid, the request is rejected; otherwise, the result is calculated. Let F i ={ID' i ,TS j As vehicle V i Temporary pseudonym, TS j It is the start time when the pseudonym becomes effective;

[0076] S43, RSU j F i ={ID' i ,TS j}Sent to vehicle Vi Vehicle V i The temporary pseudonym is stored in the OBU's immutable device. This continues until vehicle V... i If the temporary pseudonym is invalid, S41 is re-executed.

[0077] Furthermore, step S5 specifically includes the following steps:

[0078] S51, Vehicle V i Calculate the current timestamp ts i With the alias F i ={ID' i ,TS j Time in} j If the difference Δt is greater than the effective time difference, the temporary pseudonym becomes invalid and a new temporary pseudonym needs to be applied for following the pseudonym generation steps above; otherwise, F i ={ID' i ,TS j As vehicle V i Given a temporary pseudonym, continue with the following steps;

[0079] S52, Vehicle V i Random selection Calculate U i =u i P, will send a set of electronic credentials messages to be submitted. As a vector space to be signed.

[0080] S53, Vehicle V i The calculation is performed using the following steps:

[0081] T ik =H3(F i ||X i ||Y i ||U i ||m ik )

[0082] T' ik =H4(F i ||X i ||Y i ||U i ||m ik )

[0083]

[0084] Obtain the electronic certificate Signature σ i =(U i V i ,ts i ).

[0085] S54, Vehicle V i Using LC's public key Encrypt electronic credentials and pseudonyms: And and signature σ i =(U i V i ,ts i ) via RSU j Forwarded to Edge Cloud. Edge Cloud received. After signing, first verify the validity of the signature; if invalid, reject the request; otherwise, use the LC private key γ. i Decryption Then, the electronic voucher Signature σ i =(U i V i ,ts i ), kana F i Stored on a temporary table on the edge cloud server.

[0086] Furthermore, step S6 specifically includes the following steps:

[0087] S61. The Local Certification Center (LC) selects l signature groups from the electronic credential relationship mapping table: σ1=(U1,V1,ts1), σ2=(U2,V2,ts2)...σ l =(U l V l ,ts l ).

[0088] S62. The aggregate signature generator calculates the aggregate signature of l groups of signatures: δ=(V,U1,U2,...U l );

[0089] S63, the local certification center sends the electronic credential mapping table and δ to the central cloud via a secure channel.

[0090] Furthermore, step S7 specifically includes the following steps:

[0091] S71. After receiving δ and the electronic voucher mapping table, the central cloud performs the following calculation: T ik =H3(F i ||X i ||Y i ||U i ||m ik ), T' ik =H4(F i ||X i ||Y i ||U i||m ik ), h 1i =H1(Q i ||Y i ||P pub );

[0092] S72: Verify whether the following equation is true.

[0093]

[0094] The derivation process is verified as follows:

[0095]

[0096]

[0097]

[0098] If true, then the electronic voucher {m1,m2,...m} will be... l Stored on a central cloud server. Otherwise, discarded.

[0099] The schematic diagram of the vehicle networking architecture of this invention is attached. Figure 2 As shown in the attached diagram, the architecture of the present invention is illustrated. Figure 3 As shown.

[0100] The meanings of the symbols in this invention are shown in Table 1:

[0101]

[0102] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0103] (1) This invention achieves anonymous privacy protection of vehicle user identity by combining a certificateless homomorphic aggregated signature message verification protocol and dynamic pseudonym technology, thus ensuring reliability.

[0104] (2) This invention uses the homomorphic aggregation signature algorithm for rapid verification of electronic credentials in the Internet of Vehicles cloud storage environment. The characteristics of homomorphic aggregation signature in data processing ensure the privacy and robustness of the data.

[0105] (3) In order to improve the storage efficiency of vehicle electronic certificate messages in the cloud environment, this invention also alleviates the computing pressure in the cloud, improves the computing power and operating efficiency on the mobile side, and innovatively combines the homomorphic aggregation signature algorithm with the vehicle network architecture, deploying some verification services at the network edge close to the vehicle mobile side to build a mobile edge computing system.

[0106] (4) This invention introduces a certificateless public-key cryptography system, where the signature is generated by vehicle V. iThe signature key is generated using a combination of a partial private key and a secret value. Only electronic credentials sent by legitimate vehicles can be effectively verified, ensuring message integrity and authentication.

[0107] (5) The dynamic pseudonym technology designed in this invention can use temporary pseudonyms to communicate with other entities in the vehicle network system in different regions, which can ensure the anonymity of vehicle identity and the untraceability of location.

[0108] (6) This invention addresses the specific evidence collection needs of the Internet of Vehicles by designing conditional anonymity for vehicles. Electronic credentials generated during vehicle operation can, under certain special circumstances (traffic accidents, hit-and-run incidents, traffic violations, etc.), allow the TA to trace the true identity of such vehicles for judicial investigation and evidence collection. The TA can reveal the true identity of a vehicle by using an XOR operation based on its false identity.

[0109] (7) This invention proposes an efficient electronic certificate message homomorphic aggregation verification scheme in a cloud storage environment for electronic evidence storage in the Internet of Vehicles. The purpose of the scheme is to alleviate the computational pressure and bottleneck of verifying massive electronic certificate messages of vehicles in the cloud. Attached Figure Description

[0110] Figure 1 This is an overall flowchart of the efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) environment, as described in this embodiment of the invention.

[0111] Figure 2 This is a schematic diagram of the vehicle network architecture in an example of the present invention.

[0112] Figure 3 This is a schematic diagram of the scheme architecture in an example of the present invention.

[0113] Figure 4 This is a flowchart of the entity registration process in an example of the present invention.

[0114] Figure 5 This is a flowchart of the vehicle key generation process in an example of the present invention.

[0115] Figure 6 This is a flowchart illustrating the process of generating vehicle pseudonyms in an example of the present invention.

[0116] Figure 7 This is a flowchart illustrating the process of generating a single vehicle signature in an example of the present invention.

[0117] Figure 8 This is a comparison chart of the computational overhead of aggregation verification in an example of the present invention. Detailed Implementation

[0118] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. Of course, the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0119] Example 1

[0120] In this embodiment, to improve the storage efficiency of vehicle electronic certificate messages in a cloud environment, while alleviating the computational pressure on the cloud and enhancing the computing power and operating efficiency of the mobile side, a high-efficiency electronic certificate verification method based on platform aggregation in a vehicle-to-everything (V2X) environment is designed. The process is as follows: Figure 1 As shown, this method deploys some verification services at the network edge close to the vehicle's movement side, constructing a mobile edge computing system. However, edge computing deployment near network infrastructure is vulnerable to attacks such as impersonation, privacy theft, and fake news from edge vehicles and network infrastructure. Furthermore, unauthorized insiders may also access and steal sensitive information stored in edge data centers. Therefore, a homomorphic aggregation verification algorithm is used in edge computing deployment to protect the privacy of users and messages during the verification process.

[0121] The vehicle network architecture in this embodiment is shown in the appendix. Figure 2 As shown in the attached diagram, the solution architecture is as follows. Figure 3 As shown, it consists of four parts: central cloud (trusted authentication center, cloud server), edge cloud (local authentication center, edge server), RSU, and vehicles.

[0122] 1) The central cloud consists of a trusted authentication center and cloud servers. The trusted authentication center is the highest authority in the entire system, built and managed by a trusted national transportation management department. It is responsible for all entities in the system, such as RSUs and vehicle registration and identity revocation, and manages all edge clouds. The trusted authentication center generates pseudo-identities and partial private keys for vehicles, while the cloud servers provide sufficient computing and storage resources for the trusted authentication center, responsible for verifying and storing correct electronic credentials.

[0123] 2) The edge cloud consists of a local certification center, edge servers, and connected RSUs. The local certification center (LC) is managed by the local traffic management department and is responsible for receiving vehicle signatures of electronic credential messages collected by the local RSUs. It uses a homomorphic signature derivation algorithm to aggregate multiple electronic credential message signatures into a single signature, completing part of the signature calculation. The edge servers provide computing and storage resources for the local certification center.

[0124] 3) The RSU is fixed to the side of the road and communicates with vehicles within its jurisdiction via wireless communication protocols such as DSRC or 5G, and accesses the edge cloud via a wired channel. In this scheme, the RSU needs to generate temporary pseudonyms for vehicles entering its area, forward the area's electronic credential message and a single signature to the edge cloud.

[0125] 4) Each vehicle is equipped with an On-Board Unit (OBU) module, which has certain computing, storage, and communication functions. In this scheme, the vehicle uses the OBU to generate a public key and calculate the signature of a single electronic credential message.

[0126] During the driving process of each vehicle connected to the Internet of Vehicles, a large number of electronic certificate messages are generated, the contents of which are as follows:

[0127] Vehicles cannot send electronic credential messages directly to cloud storage. They must first calculate and generate a signature for the electronic credential message and send it to the local RSU along with the electronic credential message. The local RSU then forwards it to the edge cloud. For security reasons, the edge cloud uses a homomorphic encryption aggregation algorithm to aggregate homomorphic signatures for multiple message groups from multiple vehicles and forwards them to the central cloud. The central cloud performs efficient aggregation and signature verification on the batch of electronic credential messages. Once the signature verification is successful, the relevant electronic credential messages are stored in the database as trusted data and serve as on-site evidence in vehicle traffic accidents.

[0128] This embodiment provides an efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment, which specifically includes the following steps:

[0129] S1, System Initialization

[0130] System initialization is divided into two parts: central cloud initialization and edge cloud initialization. Central cloud initialization refers to the Trusted Authentication Center (TA) in the central cloud layer generating a series of system parameters, including the TA's public key, system hash function, and other common system parameters, by setting the system master key and selecting an elliptic curve. Ultimately, the TA pre-sets these system parameters into the vehicle's On-Board Unit's (OBU) unmodifiable storage unit and broadcasts them to all entities in the system. Edge cloud initialization, on the other hand, refers to the local authentication center in the edge cloud layer generating its public and private keys and publishing the public key within the local domain system.

[0131] S2, Entity Registration

[0132] Vehicles registered in the network V i and RSU j All entities need to initialize registration. Entities submit their true identity information to the TA. This is to ensure vehicle V i For privacy and to resolve key escrow and certificate management issues, TA provides vehicle V i Calculate the false identity and generate a partial key for it; the remaining key is given by vehicle V. iGeneration. Additionally, to ensure the message's unforgeability, RSU... j It is necessary to set its public and private keys, and the TA must publish the relevant parameters to the LC. The LC determines the RSU. j After the region is assigned, RSU will be j The relevant parameters are stored in the edge cloud server. Finally, the vehicle pre-installs the pseudo-identity and part of the key in the OBU's tamper-proof storage device, RSU. j The private key is stored in its internal, tamper-proof storage device;

[0133] S3, Vehicle Key Generation

[0134] To verify the authenticity of the RSU identity, when vehicle V i Upon entering a new edge cloud LC region, the RSU public key and deployment location relationship table for that region are downloaded via a secure channel. Subsequently, when vehicle V... i When entering a new RSU area, the secret value of the signature and the vehicle's public key are set, and the private key is pre-set in the OBU. The public key is broadcast to all entities in the system.

[0135] S4. Vehicle pseudonym generation

[0136] To solve vehicle V i To prevent privacy breaches during communication and avoid associated attacks, the solution generates a pseudonym as the vehicle's V. i Work status;

[0137] S5, Single Vehicle Signature Generation

[0138] To ensure the integrity and verifiability of electronic voucher messages, vehicle V i Digital signatures are required when uploading electronic certificate messages. (Vehicle V) i First, the validity period of the temporary pseudonym is verified. Then, the electronic certificate and related parameters are initialized, and the electronic certificate is used as the vector space to be signed. Subsequently, vehicle V... i The system uses its generated private key to sign the electronic certificate, pseudonym, public key, and signature-related parameters. Simultaneously, it encrypts the electronic certificate using the public key of the local certification authority (LC), and then transmits the signature and the encrypted electronic certificate through the RSU. j Forwarded to LC;

[0139] S6, Vehicle Homomorphic Aggregation Signature

[0140] Since aggregated signatures combine signatures from multiple vehicles into a short signature using a homomorphic signature derivation algorithm, they can improve signature verification efficiency and reduce computational and storage overhead on edge cloud servers. After generating the homomorphic aggregated signature, the aggregated signature generator in LC sends the aggregated signature, electronic certificate, and corresponding parameters to the Trusted Certification Center (TA).

[0141] S7, Homomorphic Aggregate Signature Verification

[0142] Since the OBU and LC have already completed the computational tasks of signing and signature aggregation for the central cloud, the central cloud only needs to verify the aggregated signature. If the verification passes, the relevant electronic certificate is valid and is stored as evidence on the central cloud server. When the evidence collection center needs to collect evidence, it can apply to the central cloud for access; otherwise, the electronic certificate message is discarded.

[0143] Step S1 includes:

[0144] S11, Central Cloud Initialization

[0145] 1) TA selects a non-singular elliptic curve E p (a,b): y 2 =x 3 +ax+b mod p, where p is a large prime number, and a,b∈F p Meanwhile, in E p Choose a point P on (a,b) as the generator of group G. Let the order of G be q, and let G contain the point Q at infinity.

[0146] 2) TA is randomly selected As the system's master key, calculate the system's public key P. pub =sP;

[0147] 3) TA selects 5 collision-resistant one-way hash functions: H0: H1: H2: H3: H4:

[0148] 4) TA publishing system parameter Params = {E p (a,b),p,q,G,P,P pub ,H0,H1,H2,H3,H4}, retain the master key s.

[0149] S12, Edge Cloud Initialization

[0150] LC i Random selection Use it as its private key, and calculate its public key. LC i Publish public key

[0151] like Figure 4 As shown, step S2 specifically includes the following steps:

[0152] S21. Vehicle registration is completed at the Trusted Authentication Center (TA). The vehicle submits basic information (license plate number, owner's identity information, etc.) to the TA to complete the registration.

[0153] S22, TA is to ensure vehicle V i Real identity information ID i To protect privacy, a pseudo-identity is generated for it, the process being: through a secure hash function H0: Calculate vehicle V i The process of creating a false identity is as follows: Among them TS i For vehicle registration time. TA will use the vehicle's fake identity Q. i Send to vehicle V i and vehicle V i The vehicle's real identity, hash value, and pseudo identity are stored in the vehicle identity table. When a vehicle is involved in a traffic accident, illegal driving, or other incident requiring legal action, the pseudo identity Q is used. i Submit to TA, TA will Q i The corresponding tuple is retrieved from the vehicle identity table and processed by the following operations: This allows the vehicle's true identity to be obtained, making the identity traceable and retrospective, which facilitates the handling of traffic accidents.

[0154] S23, TA randomly selects a private value. Calculate Y i =α i P, h 1i =H1(Q i ||Y i ||P pub ), y i =α i +sh 1i mod q, and put part of the key {Y i ,y i} Stored in vehicle V i In the OBU (On-Board Unit) tamper-proof device. Vehicle V i Obtain partial key {Y i ,y i After that, calculate h. 1i =H1(Q i ||Y i ||P pub Verify whether the following equation holds true.

[0155] y i P = Y i +P pub h 1i

[0156] The calculation process is as follows: y i =αi +sh 1i mod q, y i P = α i P+sPh 1i mod q, y i P = Y i +P pub h 1i .

[0157] If true, it means that part of the key comes from a trusted authentication center (TA) and has not been tampered with, so this part of the key should be used; otherwise, vehicle V... i Re-register and apply for a new partial key;

[0158] Table 2 Vehicle Identification Table

[0159]

[0160] S24. Before deploying RSUs on the roadside, the vehicle management office shall purchase and initialize RSU equipment. j Select random number As its secret value, RSU j P can be calculated from the public key. kj =β j P;

[0161] S25, RSU j Public key P kj It is sent to the Trusted Certification Authority (TA) via a secure channel. After the TA verifies and confirms, it will issue a valid RSU. j public key information P kj Coordinates of the deployment location Send to the authentication centers of each edge cloud LC;

[0162] S26, LC certification center determines RSU j Check if the message is in its designated region. If not, ignore the message; otherwise, perform an RSU. j The public key information and deployment location coordinates are stored on the edge cloud server in the format shown in the table.

[0163] Table 3 Relationship between RSU public key and deployment location

[0164]

[0165]

[0166] like Figure 5 As shown, step S3 specifically includes the following steps:

[0167] S31, Vehicle V iWhen entering a new edge cloud LC region, download the public key and deployment location relationship table from the LC edge cloud server and store the public key and deployment location relationship table in the OBU tamper-proof device;

[0168] S32, Vehicle V i Obtain its current location using GPS devices. And calculate The distance between the RSUs locations in the deployment location relationship table is used to retrieve the mapping between the public keys of the RSUs within the shortest effective distance range and their deployment locations, and then put them into the cache area of ​​the OBU.

[0169] S33, Vehicle V i Random selection And obtain the timestamp TS i Calculate R i =r i P, λ = H1(PID) i ,TS i ,R i ), μ=λY i +r i and send the message through RSU j public key P kj encryption: Send to RSU j ;

[0170] S34, RSU j After receiving the message, use the private key β j Decrypt. Verify λ = H1(PID) i ,TS i ,μP-λY i If the verification passes (P), proceed to step S36; otherwise, proceed to RSU. j Using R i encryption: And send to vehicle V i ;

[0171] S35, Vehicle V i receive Then, first use r i Decrypt and verify the validity of the timestamp. If invalid, discard it; otherwise, proceed to step S36.

[0172] S36, RSU j Broadcast its public key information and location coordinates. Vehicle V i This broadcast message is used to retrieve information from the cache area. If a match is found, it indicates that vehicle V... i Drive into RSU j Jurisdiction area; otherwise, discard this RSU broadcast message;

[0173] S37, Vehicle V i with RSU j After successful authentication, a secret value is randomly selected for storage. Calculate X i =x i P;

[0174] S38, Vehicle V i Set the public key to VPK. i ={X i ,Y i The private key is VSK. i ={x i ,y i}, until V i Enter the new RSU area and repeat S32.

[0175] like Figure 6 As shown, step S4 specifically includes the following steps:

[0176] S41, Vehicle V i After completing the public and private key setup, use RSU. j public key P kj Q i Encryption with timestamps: Then send the encrypted information to RSU. j ;

[0177] S42, RSU j Using private key β j Decryption Get Timestamp TS j Verify TS i The validity of the result is checked; if invalid, the request is rejected; otherwise, the result is calculated. Let F i ={ID' i ,TS j As vehicle V i Temporary pseudonym, TS j It is the start time when the pseudonym becomes effective;

[0178] S43, RSU j F i ={ID' i ,TS j}Sent to vehicle V i Vehicle V i The temporary pseudonym is stored in the OBU's immutable device. This continues until vehicle V... i If the temporary pseudonym is invalid, repeat step S41.

[0179] like Figure 7As shown, step S5 specifically includes the following steps:

[0180] S51, Vehicle V i Calculate the current timestamp ts i With the alias F i ={ID' i ,TS j Time in} j If the difference Δt is greater than the effective time difference, the temporary pseudonym becomes invalid and a new temporary pseudonym needs to be applied for following the pseudonym generation steps above; otherwise, F i ={ID' i ,TS j As vehicle V i Given a temporary pseudonym, continue with the following steps;

[0181] S52, Vehicle V i Random selection Calculate U i =u i P, will send a set of electronic credentials messages to be submitted. As a vector space to be signed.

[0182] S53, Vehicle V i The calculation is performed using the following steps:

[0183] T ik =H3(F i ||X i ||Y i ||U i ||m ik )

[0184] T' ik =H4(F i ||X i ||Y i ||U i ||m ik )

[0185]

[0186] Obtain the electronic certificate Signature σ i =(U i V i ,ts i ).

[0187] S54, Vehicle V i Using LC's public key Encrypt electronic credentials and pseudonyms: And and signature σ i =(Ui V i ,ts i ) via RSU j Forwarded to Edge Cloud. Edge Cloud received. After signing, first verify the validity of the signature; if invalid, reject the request; otherwise, use the LC private key γ. i Decryption Then, the electronic voucher Signature σ i =(U i V i ,ts i ), kana F i It is stored in a temporary table on the edge cloud server, as shown in Table 4 below.

[0188] Table 4 Electronic Voucher Relationship Mapping

[0189]

[0190]

[0191] Step S6 specifically includes the following steps:

[0192] S61. The Local Certification Center (LC) selects l signature groups from the electronic credential relationship mapping table: σ1=(U1,V1,ts1), σ2=(U2,V2,ts2)...σ l =(U l V l ,ts l ).

[0193] S62. The aggregate signature generator calculates the aggregate signature of l groups of signatures: δ=(V,U1,U2,...U l );

[0194] S63, the local certification center sends the electronic credential mapping table and δ to the central cloud via a secure channel.

[0195] Step S7 specifically includes the following steps:

[0196] S71. After receiving δ and the electronic voucher mapping table, the central cloud performs the following calculation: T ik =H3(F i ||X i ||Y i ||U i ||m ik ), T' ik =H4(F i ||X i ||Y i ||U i||m ik ), h 1i =H1(Q i ||Y i ||P pub );

[0197] S72: Verify whether the following equation is true.

[0198]

[0199] The derivation process is verified as follows:

[0200]

[0201]

[0202]

[0203] If true, then the electronic voucher {m1,m2,...m} will be... l Stored on a central cloud server. Otherwise, discarded.

[0204] To verify the feasibility of this embodiment, the correctness and method feasibility of this embodiment are analyzed.

[0205] 1. Security certification

[0206] Based on the security model defined in the paper "A New Provable Secure Certificateless Aggregate Signature Scheme", the scheme in this paper only has an attacker A1: A1 represents a malicious vehicle in the system, which cannot obtain the system master key s, but can obtain or replace the public key of any user.

[0207] The proposed solution provides an existence-unforgeable proof under adaptive choice message attacks, simulated by a game between challenger C and attacker A1.

[0208] Theorem states that in the stochastic oracle model, if a malicious vehicle A1 can successfully forge a signature with a non-negligible advantage ε in probabilistic multinomial time, then there exists a challenger C who can solve the ECDLP problem with an advantage ε' in probabilistic multinomial time.

[0209] in, q d q represents the number of queries to a portion of the private key. s ε represents the number of signature queries, n represents the number of signers in the aggregate signature, e represents the natural constant, and ε represents the advantage of A1 in successfully forging a signature.

[0210] Prove that C is a challenger capable of solving the ECDLH(P,Q=s·P) problem, and computes s by interacting with A1. A1, through interaction with C, forges the target user ID. i The valid signature. The detailed interaction process between challenger C and attacker A1 is as follows:

[0211] Initialization Phase: Challenger C executes the system initialization algorithm, setting the system parameters Params = {E} p (a,b),p,q,G,P,P pub The values ​​H0, H1, H2, H3, H4 are sent to attacker A1.

[0212] Challenger C establishes and maintains five initially empty lists, used to track attacker A1's queries to oracles H1, H2, H3, and H4, as well as public key substitution queries. The five lists include the L1 list. L2 List L u List (F,X,Y,x,y), L sk List (F, y, Y), L s List

[0213] in:

[0214] Oracle Inquiry Phase: In this phase, attacker A1 and challenger C conduct oracle inquiries within the polynomial order of magnitude.

[0215] 1) H1 Oracle Query: When C receives A1's H1(Q) query... i ||Y i ||P pub When querying, if list L1 contains Then C returns Give A1; otherwise, C chooses randomly. Will Add to list L1 and return Give it to A1.

[0216] 2) H2 Oracle query: When A1 queries Q i Query C; if the corresponding tuple already exists in L2, return [the value]. Give A1; otherwise, A1 first performs a vehicle secret value oracle query, then randomly selects... and return Give it to A1.

[0217] 3) H3 Oracle Query: When A1 queries H3(F i ||X i ||Y i ||Ui ||m ik When querying C, if list L s Includes Then C returns Give A1; otherwise, C selects randomly. Will Add to list L s and return Give it to A1.

[0218] 4) H4 Oracle Queries: When A1 queries H4(F)... i ||X i ||Y i ||U i ||m ik When querying C, if list L s Includes Then C returns Give A1; otherwise, C selects randomly. Will Add to list L s and return Give it to A1.

[0219] 5) Partial Private Key Query: When C receives a partial private key query from A1, if list L sk If the given information contains the corresponding tuple, then C returns (d). i ,Y i (A) Give A1; otherwise, C performs the following operation:

[0220] ①If F i =F i If '', then C terminates the operation.

[0221] ②If F i ≠F i ', then C randomly selects Let y i =a i H1(Q) i ||Y i ||P pub ) = h 1i Calculate Y i =x i Ph 1i P pub ,Will (F i ,y i ,Y i Add them to lists L1 and L2 respectively. sk and return (d i ,Y i Give A1.

[0222] 6) Create User Query: When C receives the Create User query from A1, if list L u If the given information contains the corresponding tuple, then C returns (X). i ,Y i If A is selected, then C performs the following steps:

[0223] ①If F i =F i ', then C randomly selects Let H1(Q) i ||Y i ||P pub ) = h 1i Calculate Y i =b i P, X i =x i P, y i =b i +sh 1i mod q, will (F i ,X i ,Y i ,⊥,y i Add them to lists L1 and L2 respectively. u , return (X i ,Y i Give A1.

[0224] ②If F i ≠F i ', then C is from list L sk Get (F) i ,y i ,Y i ), randomly selected Calculate X i =x i P, will (F) i ,X i ,Y i ,x i ,y i Add to list L u , return (X i ,Y i Give A1.

[0225] 7) Secret value query: When C receives a secret value query from A1, C performs the following operation:

[0226] ①If F i =F i If '' is entered, the operation will terminate.

[0227] ②If F i ≠F i ', then C is from list Lu Get (F) i ,X i ,Y i ,x i ,y i and return x i Given A1. If list L u (F is not included) i ,X i ,Y i ,x i ,y i C first submits information about F. i Create user query and (x) i ,X i Add to list L u Finally, C returns x. i Give it to A1.

[0228] 8) Replace public key query: If A1 wants to use the newly selected (X') public key... i ,Y i Replace F i The original (X) i ,Y i C from list L u Get (F) i ,X i ,Y i ,x i ,y i ), update the list (F) i ,X i ,Y i ,x i ,y i ) is (F i ,X' i ,Y i ',⊥,⊥).

[0229] 9) Signature Inquiry: When A1 submits a signature request to C regarding... When signing, C performs the following operations:

[0230] ①If F i =F i ', then C is from list L1, L u Get from (F i ,X i ,Y i ,⊥,⊥), C is randomly selected And get the current timestamp ts i , making V i =d i T ik =H3(F i ||Xi ||Y i ||U i ||m ik ), T' ik =H4(F i ||X i ||Y i ||U i ||m ik ),calculate C returns the signature σ i =(U i V i ,ts i Give A1, and Add to list L s .

[0231] ②If F i ≠F i ', then C is from list L1, L u Get from (F i ,X i ,Y i ,x i ,y i C is randomly selected. And get the current timestamp ts i Calculate U i =u i P, C returns the signature σ i =(U i V i ,ts i Give A1, and Add to list L s .

[0232] Forgery stage: A1 stops the above inquiry and outputs information about the vehicle (F) i ,m i A forged signature σ' i =(U' i V i ',ts' i ) and the corresponding public key (X' i ,Y i At the same time, C performs the following operations:

[0233] ②If F i ≠F i If '', then C terminates the operation.

[0234] ②If F i =F i ', then δ satisfies the following equation (1)

[0235]

[0236] Because of U' i =u' i P,Y i '=α' i P,X' i =x' i P, therefore u' i ,r' i ,α,x' i Since C is unknown, according to the bifurcation lemma, A1 can be obtained in polynomial time with different V values. i T ik and T' ik Reconstruct message Another valid signature And it satisfies equation (2)

[0237]

[0238] Based on equations (1) and (2), C can be calculated.

[0239]

[0240] According to equation (3), In other words, C solved the ECDLH problem.

[0241] C can solve the ECDLH problem in probabilistic polynomial time with an advantage of ε' if the following three conditions are met:

[0242] Condition 1 (E1): The query for A1 to submit part of the private key and signature will not be terminated.

[0243] Condition 2 (E2): A1 can successfully forge a signature.

[0244] Condition 3 (E3): A1 can successfully forge a signature and C will not terminate the game.

[0245] The advantage of C in solving the ECDLH problem in probabilistic polynomial time is:

[0246] ε'=Pr[E1∧E2∧E3]=Pr[E1]Pr[E2|E1]Pr[E3|E1∧E2].

[0247] During the inquiry phase, if F i =F i ', C will terminate the operation. Let Pr[F i =F i If '] = η, then the probability that C will not terminate the operation is (1-η). Therefore, A1 submits q. d Second part private key query, qs The probability of a signature query not being terminated is Right now

[0248] The advantage of A1 in successfully forging a signature is ε, so Pr[E2|E1]≥ε.

[0249] When both E1 and E2 are satisfied, when F i =F i '(i=1), F i ≠F i '(i∈(1,l]∧i∈Z * If C does not terminate the operation, then Pr[E3|E1∧E2]=η(1-η) l-1 Therefore, we get:

[0250] ε'=Pr[E1∧E2∧E3]=Pr[E1]Pr[E2|E1]Pr[E3|E1∧E2]

[0251]

[0252] Clearly, if adversary A1 has an advantage ε in successfully forging a signature, then A1 can solve the ECDLH problem, which contradicts the fact that the ECDLH problem is a difficult problem under the random oracle model. This means that adversary A1's advantage ε does not exist, and the proposed solution can resist forgery attacks by adversary A1.

[0253] 2. Message integrity and authentication analysis

[0254] In the security proof, we have proven that messages are unforgeable under the ECDLH hard problem assumption of the stochastic oracle model. In a single vehicle pair of electronic credentials... In the signature, the signature is from vehicle V i The signature key is generated using a combination of a portion of the private key and a secret value. Since the secret value is held by the vehicle, and a portion of the private key is held by both the vehicle and the TA, and based on the unforgeability proof in the security proof, the attacker can use the public key (X) to... i ,Y i ) Calculate the signature key (x) i ,y i The probability of this happening is negligible. Attackers cannot pass verification by forging signatures; only electronic credentials sent by legitimate vehicles can be validly verified. If the signature message is tampered with, it cannot be verified as a valid signature.

[0255] In summary, this solution can guarantee message integrity and message authentication.

[0256] 3. Analysis of vehicle anonymity and non-linkability

[0257] Using a temporary pseudonym to communicate with other entities in the vehicle-to-everything (V2X) system while the vehicle is in motion ensures the anonymity of the vehicle's identity and the untraceability of its location. In the proposed solution, the TA (Transporter) can reconstruct the vehicle's true identity using a vehicle identity table, while other entities can only communicate with the vehicle using a temporary pseudonym. Vehicle V i The false identities are as follows: Only TA holds the vehicle ID generated during registration. i Based on the collision-resistant properties of secure hash functions, attackers cannot reconstruct the real identity from the fake identity. (Vehicle V) i The temporary kana are as follows: F i ={ID' i ,TS j},in Due to β j For RSU j The private value. Based on the ECDLH problem, besides vehicle V... i With the RSU that is currently communicating j In addition, other entities cannot calculate β. j .

[0258] When vehicle V i Send σ to a certain RSU i =(U i V i ,ts i When ), due to σ i middle u i The randomness of the vehicle and the fact that the vehicle enters the areas of different RSUs will randomly generate new temporary pseudonyms, so attackers cannot confirm the vehicle's driving path based on different messages sent by the same vehicle.

[0259] In summary, the proposed solution satisfies the anonymity and non-linkability of vehicles.

[0260] 4. Analysis of the non-repudiation of messages

[0261] Electronic credentials generated during vehicle operation should, under certain special circumstances (traffic accidents, hit-and-run incidents, traffic violations, etc.), allow for the tracing of the vehicle's true identity for judicial investigation and evidence collection. The tracing agent can reveal the vehicle's true identity through an XOR operation, based on any false identity. Therefore, the anonymity of this scheme is conditional anonymity. The specific process is as follows:

[0262] ①If vehicle V i If no accident was caused and the perpetrator fled the scene, the judicial authorities will investigate the vehicle (V). i The fake identity stored in the tamper-proof device is sent to TA. TA retrieves the fake identity Q. i Corresponding tuple (Q)i ID i H0(ID) i ||TS i After that, the vehicle V is restored by equation (4). i Real identity ID i An investigation will be launched, and the results will be handed over to the judicial authorities.

[0263]

[0264] ②If vehicle V i If the perpetrator flees the scene of an accident, the judicial authorities will pursue charges against the vehicle owner. i The RSU that last requested service requested a false identity for the vehicle and sent the false identity to the TA. The TA retrieved the false identity Q. i Corresponding tuple (Q) i ID i H0(ID) i ||TS i After that, the vehicle V is restored by equation (4). i Real identity ID i An investigation will be launched, and the results will be handed over to the judicial authorities.

[0265] In summary, this solution satisfies the non-repudiation of messages.

[0266] 5. Performance Analysis

[0267] Since this solution aims to improve the efficiency of vehicle network message authentication by aggregating electronic credential messages from multiple vehicles, the computational overhead of message authentication in this solution is analyzed as follows:

[0268] This embodiment (Algorithm 1) is compared with the following algorithms to evaluate its performance: Wang Daxing et al.'s (Algorithm 2) certifiable secure certificateless aggregate signature algorithm for vehicular ad hoc networks; ZHONG Hong et al.'s (Algorithm 3) Privacy-preserving authentication scheme with full aggregation in VANETs; ALI et al.'s (Algorithm 4) An efficient conditional privacy-preserving authentication scheme for vehicle-to-infrastructure communication in VANETs; CUI J et al.'s (Algorithm 5) An efficient certificateless aggregate signature without pairings for vehicular ad hoc networks; and C.Li et al.'s (Algorithm 6) An enhanced secure identity based certificateless public key authentication scheme for vehicular sensor networks. Regarding computational overhead, the average execution time of various cryptographic operations is shown in Table 5, based on experimental results running on a computer with an Intel Core i7-4770 CPU@3.40GHz processor and 4GB of memory.

[0269] Table 5. Execution time unit for various operations: ms

[0270]

[0271] 5.1 Computational Cost Analysis

[0272] Regarding computational overhead, since the time cost of performing a general hash operation is relatively small compared to other time costs, the main statistics are the signing time of a single signature, the verification time of a single signature, and the verification time of an aggregated signature. The computational overhead of algorithms [2-6] and this embodiment is shown in Table 6. Assuming the number of aggregated signature messages is l = 100, the percentage reduction in computational cost of the proposed scheme compared to algorithms [2-6] is as follows:

[0273] The percentage reduction compared to Algorithm 2 in this embodiment:

[0274] The percentage reduction compared to Algorithm 3 in this embodiment:

[0275] The percentage reduction compared to Algorithm 4 in this embodiment:

[0276] The percentage reduction compared to Algorithm 5 in this embodiment:

[0277] The percentage reduction compared to Algorithm 6 in this embodiment:

[0278] Because algorithms [2-4] require complex bilinear pairing operations and hash operations mapped to points, their computational overhead is relatively high. Both Algorithm 5 and the scheme presented in this paper achieve aggregation verification without bilinear pairing operations. Based on the comparison results, Algorithm 1 in this embodiment has a greater advantage. Although the aggregation verification computational overhead of Algorithm 5 is slightly lower than that of this embodiment, a single signature in this embodiment is an electronic certificate composed of k messages, meaning the number of messages verified in this embodiment is far greater than l. Furthermore, this embodiment offers stronger privacy protection compared to Algorithm 6.

[0279] Table 6 Comparison of Calculation Costs for Each Scheme

[0280]

[0281] Figure 8 The computational cost analysis is performed for the aggregation verification of each scheme derived from Table 6.

[0282] Depend on Figure 8 It can be seen that, when verifying electronic credentials, this embodiment has a significant advantage in terms of time overhead compared to aggregated signature schemes with bilinear mapping. It also has certain advantages compared to aggregated signature schemes without bilinear mapping. In summary, this embodiment is more suitable for rapidly verifying a large number of electronic credentials in the Internet of Vehicles (IoV) electronic forensics model.

[0283] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A highly efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment, characterized in that, Includes the following steps: S1, System Initialization System initialization is divided into two parts: central cloud initialization and edge cloud initialization. Central cloud initialization refers to the Trusted Authentication Center (TA) of the central cloud layer generating a series of system parameters by setting the system master key and selecting an elliptic curve, including the TA's public key and the system hash function. Finally, the TA pre-sets the system parameters into the storage unit of the vehicle's OBU that cannot be modified, and broadcasts them to all entities in the system. Edge cloud initialization refers to the local authentication center of the edge cloud layer generating its public and private keys and publishing the public key in the local domain system. S2, Entity Registration Vehicles registered in the network V i and RSU j Entity initial registration involves the entity submitting its true identity information to the TA to ensure vehicle V i For privacy and to resolve key escrow and certificate management issues, TA provides vehicle V i Calculate the false identity and generate a partial key for it; the remaining key is given by vehicle V. i To ensure the message's unforgeability, RSU is generated. j The TA sets its public and private keys, and publishes the relevant parameters to the local certification authority (LC). The LC then determines the RSU. j After the region is assigned, RSU will be j The relevant parameters are stored in the edge cloud server. The vehicle pre-installs a false identity and some keys in the OBU's tamper-proof storage device. j The private key is stored in its internal, tamper-proof storage device; S3, Vehicle Key Generation To verify the authenticity of the RSU identity, when vehicle V i When a vehicle enters the new Local Certification Center (LC) area, it downloads the RSU public key and deployment location table for that area via a secure channel. i When entering a new RSU area, the secret value of the signature and the vehicle's public key are set, and the private key is pre-set in the OBU. The public key is broadcast to all entities in the system. S4. Vehicle pseudonym generation To solve vehicle V i Privacy leaks during communication, preventing association attacks, and generating aliases as vehicle registration numbers. i Work status; S5, Single Vehicle Signature Generation To ensure the integrity and verifiability of electronic voucher messages, vehicle V i When uploading electronic certificate messages, they must be digitally signed. (Vehicle V) i First, verify the validity of the temporary pseudonym. Then, initialize the electronic certificate and related parameters, using the electronic certificate as the vector space to be signed. Vehicle V i The generated signing private key is used to sign the electronic certificate, pseudonym, signing public key, and signature-related parameters. The electronic certificate is then encrypted using the public key of the local certification authority (LC). The signed result and the encrypted electronic certificate are then transmitted via RSU. j Forwarded to the local certification authority (LC); S6, Vehicle Homomorphic Aggregation Signature Since aggregated signatures are generated by combining signatures from multiple vehicles into a short signature using a homomorphic signature derivation algorithm, the aggregated signature generator in the local certification center (LC) generates the homomorphic aggregated signature and then sends the aggregated signature, electronic certificate, and corresponding related parameters to the trusted certification center (TA). Step S6 includes the following steps: S61. The local certification authority (LC) selects l signature groups from the electronic credential relationship mapping table: σ1 = (U1, V1, ts1). σ2=(U2,V2,ts2)...σ l =(U l V l ts l ); S62. The aggregate signature generator calculates the aggregate signature of l groups of signatures: δ=(V,U1,U2,...U l ); S63. The local certification center sends the electronic credential mapping table and δ to the central cloud via a secure channel; S7, Homomorphic Aggregate Signature Verification Since the OBU and the local certification center LC have completed the computational tasks of signing and signature aggregation for the central cloud, the central cloud needs to verify the aggregated signature. If the verification is successful, it means that the relevant electronic certificate is valid and it is stored as evidence in the central cloud server. When the evidence collection center needs to collect evidence, it applies to the central cloud for access; otherwise, the electronic certificate message is discarded.

2. The efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment according to claim 1, characterized in that, Step S1 includes the following steps: S11, Central Cloud Initialization 1) TA selects a non-singular elliptic curve E p (a,b): y 2 =x 3 +ax+b mod p, where p is a large prime number, and a,b∈F p , In E p Choose a point P on (a,b) as the generator of group G. Let the order of G be q, and let G contain the point Q at infinity. 2) TA is randomly selected As the system's master key, calculate the system's public key P. pub =sP; 3) TA selects 5 collision-resistant one-way hash functions: H0: H1: H2: H3: H4: 4) TA publishing system parameter Params = {E p (a,b),p,q,G,P,P pub H0, H1, H2, H3, H4}, retain the master key s; S12, Edge Cloud Initialization LC i Random selection Use it as its private key, and calculate its public key. LC i Publish public key 3. The efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment according to claim 1, characterized in that, Step S2 includes the following steps: S21. Vehicle registration is completed at the Trusted Certification Center (TA). The vehicle submits basic information to the TA to complete the registration. S22, TA is to ensure vehicle V i Real identity information ID i To protect privacy, a pseudo-identity is generated for it, the process being: through a secure hash function H0: Calculate vehicle V i The process of creating a false identity is as follows: Among them, TS i For the vehicle registration time, TA will use the vehicle's fake identity Q i Send to vehicle V i and vehicle V i The vehicle's real identity, hash value, and pseudo identity are stored in the vehicle identity table. When a vehicle is involved in a traffic accident or violates traffic regulations and needs to be held legally responsible, the pseudo identity Q will be used. i Submit to TA, TA will Q i The corresponding tuple is retrieved from the vehicle identity table and processed by the following operations: To obtain the vehicle's true identity, enabling traceability and retrospection, which can be used for handling traffic accidents; S23, TA randomly selects a private value. Calculate Y i =α i P, h 1i =H1(Q i ||Y i ||P pub ), y i =α i +sh 1i mod q, and put part of the key {Y i ,y i } Stored in vehicle V i In the tamper-proof OBU device, vehicle V i Obtain partial key {Y i ,y i After that, calculate h. 1i =H1(Q i ||Y i ||P pub Verify whether the following equation holds true; y i P=Y i +P pub h 1i The calculation process is as follows: y i =α i +sh 1i mod q, y i P = α i P+sPh 1i mod q, y i P = Y i +P pub h 1i If true, it means that part of the key comes from a trusted authentication center (TA) and has not been tampered with, so this part of the key should be used; otherwise, vehicle V... i Re-register and apply for a new partial key; S24. Before deploying RSUs on the roadside, the vehicle management office shall purchase and initialize RSU equipment. j Select random number As its secret value, through P kj =β j P calculates P kj As P kj =β j P's public key; S25, RSU j Public key P kj It is sent to the Trusted Certification Authority (TA) via a secure channel. After the TA verifies and confirms, it will issue a valid RSU. j public key information P kj Coordinates of the deployment location Send to each local certification authority (LC); S26, Local Certification Center (LC) determines RSU j Check if the message is in its designated region. If not, ignore the message; otherwise, perform an RSU. j The public key information and deployment location coordinates are stored on the edge cloud server.

4. The efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment according to claim 1, characterized in that, Step S3 includes the following steps: S31, Vehicle V i When entering a new Local Certification Center (LC) area, download the public key-deployment location relationship table from the LC server and store the public key-deployment location relationship table in the OBU tamper-proof device; S32, Vehicle V i Obtain its current location using GPS devices. And calculate The distance between the RSUs locations in the deployment location relationship table is used to retrieve the mapping between the public keys of the RSUs located within the shortest effective distance range and their deployment locations, and then put them into the cache area of ​​the OBU's high-speed cache memory. S33, Vehicle V i Random selection And obtain the timestamp TS i Calculate R i =r i P, λ = H1(PID) i ,TS i ,R i ), μ=λY i +r i and send the message through RSU j public key P kj encryption: Send to RSU j ; S34, RSU j After receiving the message, use the private key β j Decrypt and verify λ = H1(PID) i ,TS i ,μP-λY i If the verification passes (P), proceed to step S36; otherwise, proceed to RSU. j Using R i encryption: And send to vehicle V i ; S35, Vehicle V i receive Then, first use r i Decrypt and verify the validity of the timestamp. If invalid, discard it; otherwise, proceed to step S36. S36, RSU j Broadcast its public key information and location coordinates; Vehicle V i Based on this broadcast message, information is retrieved from the cache area of ​​the high-speed buffer. If a match is found, it indicates that vehicle V... i Drive into RSU j Jurisdiction area; otherwise, discard this RSU broadcast message; S37, Vehicle V i with RSU j After successful authentication, a secret value is randomly selected for storage. Calculate X i =x i P; S38, Vehicle V i Set the public key to VPK. i ={X i ,Y i The private key is VSK. i ={x i ,y i }, until V i Enter the new RSU area and repeat S32.

5. The efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment according to claim 1, characterized in that, Step S4 includes the following steps: S41, Vehicle V i After completing the public and private key setup, use RSU. j public key P kj Q i Encryption with timestamps: Then send the encrypted information to RSU. j ; S42, RSU j Using private key β j Decryption Get Timestamp TS j Verify TS i The validity of the result is checked; if invalid, the request is rejected; otherwise, the result is calculated. Let F i ={ID i ',TS j As vehicle V i Temporary pseudonym, TS j It is the start time when the pseudonym becomes effective; S43, RSU j F i ={ID i ',TS j }Sent to vehicle V i Vehicle V i The temporary pseudonym is stored in the OBU's immutable device until vehicle V. i If the temporary pseudonym is invalid, repeat step S41.

6. The efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment according to claim 1, characterized in that, Step S5 includes the following steps: S51, Vehicle V i Calculate the current timestamp ts i With the alias F i ={ID i ',TS j Time in} j If the difference Δt is greater than the effective time difference, the temporary pseudonym becomes invalid, and a new temporary pseudonym is applied for according to the pseudonym generation steps; otherwise, F... i ={ID i ',TS j As vehicle V i Given a temporary pseudonym, continue with the following steps; S52, Vehicle V i Random selection Calculate U i =u i P, will send a set of electronic credentials messages to be submitted. As a vector space to be signed; S53, Vehicle V i The calculation is performed using the following steps: T ik =H3(F i ||X i ||Y i ||U i ||m ik ) T′ ik =H4(F i ||X i ||Y i ||U i ||m ik ) Obtain the electronic certificate Signature σ i =(U i V i ,ts i ); S54, Vehicle V i Using the public key of the local certification authority (LC) Encrypt electronic credentials and pseudonyms: And and signature σ i =(U i V i ,ts i ) via RSU j Forwarded to Edge Cloud, Edge Cloud received After signing, the validity of the signature is first verified. If it is invalid, the application is rejected; otherwise, the private key γ of the local certification authority (LC) is used. i Decryption Then, the electronic voucher Signature σ i =(U i V i ,ts i ), kana F i Stored on a temporary table on the edge cloud server.

7. The efficient electronic credential verification method based on homomorphic aggregation in a vehicle-to-everything (V2X) cloud environment according to claim 1, characterized in that, Step S7 includes the following steps: S71. After receiving δ and the electronic voucher mapping table, the central cloud performs the following calculation: T ik =H3(F i ||X i ||Y i ||U i ||m ik ), T′ ik =H4(F i ||X i ||Y i ||U i ||m ik ), h 1i =H1(Q i ||Y i ||P pub ); S72: Verify whether the following equation is true. The derivation process is verified as follows: If true, then the electronic voucher {m1,m2,...m} will be... l Stored on a central cloud server; otherwise, discarded.

Images