Certificateless aggregate signature authentication method based on sm2

Abstract

The application discloses a certificateless aggregation signature authentication method based on SM2 and relates to the technical field of Internet of Vehicles.The method comprises the following steps: initialization, roadside facility activation, vehicle registration, key distribution, single signature and verification, and aggregation signature and verification.In the method, the certificateless signature mechanism realizes the authentication of vehicles, an aggregation signature strategy based on SM2 is designed, in the aggregation signature process, the unpredictability of the aggregation signature generation process is increased, the implementation difficulty of collusion attack is improved, it is difficult for an attacker to deduce a valid aggregation signature combination through pre-computation, the security and reliability of the authentication scheme are further improved, and more stable security guarantee is provided for vehicle communication in an open Internet of Vehicles environment.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, and in particular to a certificateless aggregate signature authentication method based on SM2. Background Technology

[0002] In the context of the Internet of Vehicles (IoV), vehicles and infrastructure interact wirelessly. This open network topology faces numerous security risks, making the design of efficient and secure authentication schemes a crucial research direction in IoV technology development. Traditional public key infrastructure (PKI)-based authentication schemes typically rely on certificates for identity verification, requiring each vehicle to possess a valid digital certificate for verification with a certification authority. Frequent communication among numerous vehicles increases the overhead of certificate management, distribution, and revocation. Furthermore, in most schemes, vehicle keys are generated and distributed by a centralized key distribution organization, posing potential single points of failure and key leakage risks. In an IoV environment, if the key distribution organization experiences security issues, the keys of all vehicles within the domain may be leaked, threatening the security and stability of the entire IoV system. Authentication schemes also need to provide a certain degree of anonymity, ensuring vehicles do not expose their true identities during communication to prevent malicious attackers from tracking specific vehicles by observing communication content or interaction patterns. Simultaneously, to ensure the security of the authentication scheme, various potential security attacks must be considered, such as public key substitution attacks, replay attacks, and collusion attacks. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a certificateless aggregate signature authentication method that can improve the security and reliability of authentication schemes and provide more robust security for vehicle communication in an open Internet of Vehicles environment.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a certificateless aggregate signature authentication method based on SM2, comprising the following steps:

[0005] Initialization: A trusted institution generates public security parameters, stores these parameters secretly, and synchronizes them to the blockchain;

[0006] Roadside facility activation: The roadside facility sends registration information to a trusted agency, which verifies the registration information and completes the activation upon successful verification.

[0007] Vehicle Registration and Key Distribution: Intelligent connected vehicles send registration requests to trusted institutions. The trusted institution verifies the timestamp in the request and checks for duplicate vehicle identities. It generates long-term and short-term anonymous identities for the vehicle, stores the encrypted vehicle identity index information on the blockchain, calculates and generates a partial private key for the vehicle, and sends a registration success notification along with relevant identity and partial private key information to the intelligent connected vehicle. The intelligent connected vehicle verifies the partial private key sent by the trusted institution and calculates the complete private key for subsequent signing and authentication.

[0008] Single signature and verification: The intelligent connected vehicle calculates the signature message and sends it to the roadside facility; the roadside facility first checks the message timestamp to prevent replay attacks and verifies the validity of the signature. After successful verification, it returns a successful authentication result to the intelligent connected vehicle.

[0009] Aggregated signature and verification phase: The roadside facility first verifies the timestamps of the received multiple messages, performs weighted aggregate signature calculation on the signature information of multiple vehicles, and outputs the aggregate result. The generated aggregate signature is then verified. After successful verification, the intelligent connected vehicle returns a successful aggregate authentication result, completing the batch identity authentication.

[0010] The beneficial effects of adopting the above technical solution are as follows: The certificateless signature mechanism in the method described in this application realizes vehicle authentication, and an aggregate signature strategy based on SM2 is designed. In the process of aggregate signature, by increasing the unpredictability of the aggregate signature generation process, the difficulty of collusion attacks is increased, making it difficult for attackers to deduce effective aggregate signature combinations through pre-calculation, thereby further improving the security and reliability of the authentication scheme and providing a more robust security guarantee for vehicle communication in the open Internet of Vehicles environment. Attached Figure Description

[0011] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0012] Figure 1 This is the main flowchart of the method described in the embodiments of the present invention;

[0013] Figure 2 This is a schematic diagram of the structure of the corresponding model in the method described in this invention;

[0014] Figure 3 This is a detailed flowchart of the method described in the embodiments of the present invention;

[0015] Figure 4 This is a comparison chart of the computational overhead of a single signature and single signature verification in an embodiment of the present invention;

[0016] Figure 5 This is a comparison chart of the computational overhead of aggregate signatures in embodiments of the present invention;

[0017] Figure 6 This is a comparison chart of communication overhead in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0020] Overall, such as Figure 1 As shown in the figure, this invention discloses a certificateless aggregate signature authentication based on SM2. The method includes: initialization, roadside facility activation, vehicle registration, key distribution, single signature and verification, and aggregate signature and verification.

[0021] The certificateless aggregate signature authentication method based on SM2 involves models such as Figure 2 As shown. The model involves the following entities, and the specific functions of each entity are as follows.

[0022] Trusted Authority (TA): As a trusted third-party institution, the TA possesses sufficient credibility and adequate computing, storage, and communication capabilities. It is responsible for vehicle registration within the current area, the generation of some keys, and the maintenance of the blockchain network. It also manages the legitimate RSU roadside infrastructure table and has the authority to trace vehicle identities.

[0023] Roadside Unit (RSU): As infrastructure deployed on the roadside, the RSU has a certain computing power and communicates wirelessly with vehicles through the dedicated communication protocol DSRC. It is mainly responsible for authenticating vehicles and providing them with more service information.

[0024] Intelligent connected vehicles: Each vehicle is equipped with an intelligent sensing device, an on-board unit (OBU), which communicates with roadside infrastructure via wireless communication technology to collect information such as the vehicle's location and speed, and can initiate authentication with the roadside infrastructure.

[0025] Blockchain: Maintained by a trusted entity (TA), responsible for filing roadside facility information and storing vehicle registration information.

[0026] Furthermore, such as Figure 3 As shown, the method specifically includes the following steps:

[0027] Initialization phase:

[0028] Trusted institutions generate public safety parameters, which serve as the foundation for secure communication within the system. These parameters are then secretly stored and synchronized to the blockchain to ensure their immutability.

[0029] Roadside facility activation phase:

[0030] The roadside facility sends registration information to a trusted organization, which verifies the registration information and activates the facility once the verification is successful.

[0031] Vehicle registration and key distribution phase:

[0032] Intelligent connected vehicles send registration requests to trusted institutions to apply for system access. The trusted institution verifies the timestamp in the request and checks for duplicate vehicle identities to prevent malicious registration. The trusted institution generates long-term and short-term anonymous identities for the vehicle; the long-term identity is used for stable identification, and the short-term identity is used for temporary communication to protect privacy. The trusted institution stores the encrypted vehicle identity index information on the blockchain to ensure the identity information is tamper-proof. The trusted institution randomly selects system security parameters and calculates a partial private key for the vehicle. The trusted institution sends a registration success notification, along with relevant identity and partial private key information, to the intelligent connected vehicle. The intelligent connected vehicle verifies the partial private key sent by the trusted institution and calculates the complete private key based on its own parameters for subsequent signing and authentication.

[0033] Single Signature and Verification Phase:

[0034] Intelligent connected vehicles use their private keys to generate signed messages and send these messages to roadside facilities. The roadside facilities first check the message timestamp to prevent replay attacks, then verify the validity of the signature, confirming the message's origin and integrity. Upon successful verification, the roadside facilities return a successful authentication result to the intelligent connected vehicle.

[0035] Aggregated signature and verification phase:

[0036] The roadside facilities first verify the timestamps of the received multiple messages, perform weighted aggregation signature calculation on the signature information of multiple vehicles, and output the aggregation result. The generated aggregate signature is then verified. After successful verification, the intelligent connected vehicle returns a successful aggregation authentication result, thus completing the batch identity authentication.

[0037] The above steps will be explained in detail below using more specific methods:

[0038] Table 1: Parameters and Definitions Involved

[0039]

[0040] Initialization phase:

[0041] TA executes the system initialization module and sets security parameters. Calculate TA master private key Calculate the TA master public key Output the public parameters required by subsequent modules. ,in The parameters are kept securely by TA, while the parameters are publicly released and transmitted to the blockchain network. The system parameters are jointly maintained and updated regularly by TA and the blockchain network.

[0042] ①TA selects a random number As the system's master private key The master public key of the computing system .

[0043] ②TA will Keep it a secret.

[0044] ③TA selects a hash function .

[0045] ④ Public system parameters .

[0046] Roadside facilities activated:

[0047] The RSU and TA jointly execute the RSU activation module to activate and register information. The RSU provides its real identity information to the TA to apply for activation. The TA assigns an identity identifier to the RSU and stores the real identity information in the blockchain to prevent malicious RSUs from impersonating genuine RSUs and communicating with vehicles, thereby improving the trustworthiness of roadside infrastructure. The RSU calculates its private key. Calculate the public key Provide the TA with their true identity information (RID) and public key through a secure channel. After receiving the message, the TA generates an ARID identifier for the RSU and sets the index pair. Send it to the blockchain, and send the ARID to the RSU via a secure channel.

[0048] ①RSU selects random numbers As the RSU private key, i.e. Calculate the RSU public key. Register information The sender, TA.

[0049] ②TA calculation Upon successful verification, the RSU generates an identity identifier. ,Will Sending the ARID to the blockchain indicates that the RSU has been activated, and simultaneously sending the ARID to the RSU via a secure channel.

[0050] Vehicle registration:

[0051] By vehicle And the TA completes the vehicle registration module to complete vehicle registration.

[0052] ① Vehicles Prepare registration information This includes the vehicle's license plate information, the owner's personal identification information, and the vehicle's unique physical identifier.

[0053] ② Vehicles Select random number Calculate partially anonymous identity information Calculate part of the public key Calculate the hash function. , The vehicle sent a message. To TA.

[0054] ③When the TA receives the vehicle registration application, it first verifies whether the timestamp is within the specified range. If the verification is successful, it calculates... , ,judge Are they equal? ​​If they are equal, then proceed to the blockchain network to query the vehicle. If an identity exists, the registration request is rejected; otherwise, an anonymous identity is applied for for the vehicle.

[0055] ④TA selects random numbers Calculate long-term anonymity TA generates a temporary pseudo-identity for the vehicle. Send long-term anonymous identity, partially short-term anonymous identity, and domain identifier. Give it to the vehicle. (The encrypted version will be sent to the vehicle.) Send to the blockchain system. When law enforcement requests information about a certain vehicle... Applications for traceability can be submitted by searching the blockchain. .

[0056] ⑤ Vehicles Received And it is stored in an anti-tamper device. The vehicle's long-term anonymous identity is... Short-term anonymous identity

[0057] Key distribution:

[0058] By vehicle And the key distribution center in TA completes the key distribution module.

[0059] ①TA randomly selects ,calculate , Calculate part of the private key ,Will Send to vehicle .

[0060] ② Vehicles Receive messages and calculate Calculate and verify whether the equation holds true. If the condition is met, then part of the private key is valid; otherwise, the message is discarded and a new request is made, ultimately obtaining the vehicle's private key. Public key .

[0061] Individual signature:

[0062] By vehicle Complete the signature module. (Vehicle) Send a signed message anonymously.

[0063] ① Vehicles Randomly select random numbers Where n is the order of G, calculate the summary. .

[0064] ②Calculation

[0065] ③Calculation ,like or Then select again calculate.

[0066] ④ Calculation ,if Then select again Calculation. The final output message signature value. The vehicle sends a message to the RSU. .

[0067] Individual signature verification:

[0068] The signature verification module is completed by the roadside unit (RSU).

[0069] ①RSU received the vehicle The sent signed message first checks whether the timestamp in the message is within the specified range, and then checks the signature value. If the message is not within the range, then reject it.

[0070] ②RSU calculation ,like The signature is invalid.

[0071] ③RSU calculation .

[0072] ④RSU calculation

[0073] ⑤RSU calculation ,judge If the condition is met, the authentication is successful.

[0074] Aggregate signature:

[0075] The aggregation signature module is completed by the roadside unit (RSU).

[0076] ① The RSU receives a certain number of message sets. Verify whether the timestamp is within the specified time range; if it does not meet the requirements, discard the corresponding signature.

[0077] ②Calculation .

[0078] ③RSU generates a random list ,calculate , , .

[0079] ④ Calculation .

[0080] ⑤ Calculate weighted aggregation .

[0081] ⑥ Calculation , .

[0082] ⑦ The RSU output aggregate signature is

[0083] Aggregate verification:

[0084] ① First, check if the timestamp is within the specified range. If the timestamp is invalid, discard the signature.

[0085] ②Calculation Check if it is true; if not, the verification fails.

[0086] ③Calculation .

[0087] ④ Calculation

[0088] ⑤ Calculation Determine the equation If the condition is met, the aggregate signature verification is successful.

[0089] Proof of correctness:

[0090] Verify the correctness of a portion of the private key using the following formula:

[0091]

[0092] Verify the correctness of the signature verification using the following formula:

[0093]

[0094] Verify the correctness of the aggregate signature verification using the following formula:

[0095]

[0096] Security Proof and Analysis

[0097] 1) Formal security proof

[0098] (1) Security Model

[0099] Two types of adversaries are defined, each simulating different attack capabilities. The adversary's objective is to successfully forge a valid signature. Type 1 adversary... Simulating an external attacker, it is possible to replace the public key of a legitimate vehicle. However, it is impossible to obtain TA's private key. The second type of adversary Simulating an insider attacker, it is possible to obtain the TA's private key. However, it cannot replace the vehicle's public key. Based on the aforementioned opponent types, the following two games are defined.

[0100] Game 1, Challenger With the enemy The game between them is as follows:

[0101] Challenger Execute the system initialization module and input security parameters. Generate system public parameters params and send the public parameters params to .adversary Perform the following queries: hash query, vehicle partial key query, vehicle private key query, vehicle public key query, vehicle public key substitution query, and signature query. Adversary. Output When the output satisfies This is a condition for a valid signature; no vehicle partial key query or vehicle private key query was performed during the signature query. When not being queried, the opponent Victory.

[0102] Game 2, Challenger With the enemy The game between them is as follows:

[0103] Challenger Execute the system initialization module and input security parameters. Generate system public parameters params, and match the public parameters params with the public and private key pair of TA. , Send to .adversary Perform the following queries: hash query, vehicle partial key query, vehicle private key query, signature query. Adversary. Output When under a fake anonymous identity, the output satisfies This is a valid signature condition; no query was performed for the vehicle's partial key or private key, and the signature query was performed during the signature query process. When not being queried, the opponent victory.

[0104] (2) Safety certificate

[0105] The security of the scheme is proven using a formal proof method as follows:

[0106] Theorem 1: In stochastic oracle models, if the Elliptic Curve Discrete Logarithm Problem (ECDLP) assumption holds, then the method described above can withstand first-type adversaries. Malicious attacks.

[0107] Proof: Assume the challenger The ECDLP problem can be solved with a non-negligible probability, given a challenging instance of a difficult problem. If the opponent If a legitimate signature is successfully forged, then By using Interact to obtain information and thus solve The value of .

[0108] Initialization: Challenger Execute the initialization module and randomly select ,calculate , Simultaneously generate publicly available system parameters. Send it to .

[0109] Inquiry: Challenger maintenance list When the challenger receive of During the questioning, the challenger Query list Does it exist? If the list contains this data, then respond to it. If not, then the challenger. Random selection Response to , data Add to list middle.

[0110] Inquiry: Challenger maintenance list When challenger C received A's When asked, Challenger C consulted the list. Does it exist? If the list contains this data, then respond to it. If not, then the challenger. Random selection Response to , data Add to list middle.

[0111] Vehicle Partial Key Query: Challenger C Maintenance List When the challenger receive When the challenger requests a partial private key for the vehicle, Query list Does it exist? If the list contains this data, then Response to If not, the challenger will select randomly. Response to .calculate , data Add to list middle.

[0112] Vehicle private key query: Challenger Maintenance List When the challenger receive When requesting the vehicle's public key, the challenger Query list Does it exist? If the list contains this data, then Response to Otherwise, perform a partial private key query and then calculate. and update and .

[0113] Vehicle public key query: Challenger Maintenance List When the challenger receive When requesting the vehicle's public key, the challenger Query list Does it exist? If the list contains this data, then Response to Otherwise, after executing the vehicle private key query, the calculation will... Response to and update .

[0114] Vehicle public key replacement query: Attacker A submits a vehicle public key replacement query. Random selection , Challenger C Query List ,replace .

[0115] Signature Inquiry: Challenger receive Request Signature During the questioning, the challenger Random selection ,calculate , , , and thus The final challenger Will Response to .

[0116] Forgery Phase: Last Attacker Output vehicles Forged signature information .if The game stopped the challenger Terminate the operation. Otherwise, challenger... Check if the signature can be verified.

[0117] In polynomial time t, a valid signature is obtained by using the bifurcation lemma. The challenger calculates s from the above equation as a valid solution to the challenging instance of the difficult problem, but this contradicts the intractability of ECDLP, thus proving Theorem 1.

[0118] Theorem 2: Under the assumptions of the stochastic oracle model and ECDLP, the method described can resist... Malicious attacks.

[0119] Proof: Assume an attacker exists. It is possible to forge legitimate signatures and select false identities. Construct a challenger Through with Interactively generate an ECDLP problem instance. , Challenger C seeks to find For the goal.

[0120] Initialization: Challenger Execute the initialization module and randomly select ,calculate , Simultaneously generate publicly available system parameters Connect the common parameter params with Send to .

[0121] Inquiry: Challenger maintenance list When the challenger receive of During the questioning, the challenger Query list Does it exist? If the list contains this data, then respond to it. If not, then the challenger. Random selection Response to , data Add to list middle.

[0122] Inquiry: Challenger maintenance list When the challenger receive of During the questioning, the challenger Query list Does it exist? If the list contains this data, then respond to it. If not, then the challenger. Random selection Response to , data Add to list middle.

[0123] Vehicle Partial Key Interrogation: Challenger Maintenance List When the challenger receive When requesting a query for the vehicle's private key, if The game ends when the challenger... Query list Does it exist? If the list contains this data, then Response to If not, the challenger will select randomly. Response to .calculate , data Add to list middle.

[0124] Vehicle private key query: Challenger Maintenance List When the challenger receive When requesting the vehicle's public key, if If the challenger fails, the game ends. Query list Does it exist? If the list contains this data, then Response to Otherwise, perform a partial private key query and then calculate. and update and .

[0125] Vehicle public key query: Challenger Maintenance List When the challenger receive When requesting the vehicle's public key, the challenger Query list Does it exist? If the list contains this data, then Response to Otherwise, after executing the vehicle private key query, it will... Response to and update .

[0126] Signature Inquiry: Challenger receive Request Signature During the inquiry, randomly select ,calculate ,calculate ,calculate . Therefore, The final challenger Will Response to .

[0127] Forgery Phase: Last Attacker Output vehicles Forged signature information .if The game ends when the challenger... Terminate the operation. Otherwise, challenger... Check if the signature can be verified.

[0128] According to the bifurcation lemma, another valid signature can be obtained in polynomial time t. The challenger calculated from the above equation... As an efficient solution to a challenging instance of a difficult problem, but this contradicts the intractability of ECDLP, thus proving Theorem 2.

[0129] 2) Informal security attribute analysis

[0130] The security attributes of the method are analyzed using informal analysis as follows:

[0131] (1) Authentication: In the method, before a vehicle sends a message to the nearby roadside facility (RSU), it must generate a specific signature. After the roadside facilities receive the RSU, they will determine... The method verifies the legitimacy of the source of the authentication message and confirms that the message has not been tampered with during transmission, thus the method is authentication-enabled.

[0132] (2) Anonymity: In the method, the vehicle uses a pseudo-identity. The authentication communication process is then initiated. , , Since attackers cannot deduce the vehicle's true identity from the false identity through computation, the method is anonymous.

[0133] (3) Unlinkability: In the method, the vehicle periodically changes its short-term anonymous identity. Each anonymous identity is only valid within a set validity period. Signatures exceeding the validity period are considered invalid, ensuring that attackers cannot use expired signatures for identity association or location tracking. The scheme utilizes short-term anonymous identities to maintain the change of anonymous identities during vehicle communication, effectively preventing attackers from associating multiple communication events through long-term observation or data analysis to deduce the vehicle's true identity. Therefore, the method possesses unlinkability.

[0134] (4) Traceability: In the method described above, a balance between anonymity and traceability of vehicles is achieved through the collaborative work of blockchain and a trusted agency (TA). When law enforcement agencies need to trace the true identity information of a specific vehicle, they need to submit a legitimate application to the TA. The TA then retrieves the vehicle's registration information from the blockchain to trace it and obtain the vehicle's true identity information. This provides compliant traceability support for regulatory agencies without compromising anonymity. Therefore, the method is traceable.

[0135] (5) Replay attack: In the method described above, the vehicle signature is ,in The timestamp is the first thing RSU checks when performing certificateless signature authentication. Whether the message is within a specified range to ensure its freshness can effectively identify and reject replay attacks of old messages. Therefore, the method described can resist replay attacks.

[0136] (6) Collusion attack: During the aggregation signature generation calculation process, by calculating By binding messages to vehicle identities and leveraging the collision resistance of hash functions, message forgery is prevented. Simultaneously, RSU introduces a non-linear factor through a random list to calculate weighted aggregation, making it difficult for attackers to predict or control the aggregate signature weights, thus preventing the forgery of aggregate signatures. This significantly increases the difficulty for malicious attackers to conduct collusive attacks, and colluders must solve the ECDLP problem to forge a signature structure that satisfies this requirement. of Therefore, the method described above can effectively resist collusion attacks.

[0137] Attribute comparison analysis:

[0138] Table 2 compares the proposed solution with other literature, focusing on requirements such as message authentication, anonymity, batch authentication, resistance to collusion attacks, decentralization, and the use of domestically developed algorithms. In the table, "√" indicates that the solution possesses this function, "×" indicates that this function is not implemented, and "-" indicates that the solution does not consider this requirement.

[0139] Table 2: Comparison of Scheme Attributes

[0140]

[0141] As can be seen from Table 2, literature

[28] (Mei Q, Xiong H, Chen J, et al. Efficientcertificateless aggregate signature with conditional privacy preservation inIoV[J]. "IEEE Transactions on Systems, Man, and Cybernetics: Systems, 2021,15(1): 245-256), literature

[36] (Xiong H., Chen JH, Mei Q, et al. Conditionalprivacy-preserving authentication protocol with dynamic membership updating for VANETs[J]. IEEE Transactions on Dependable and Secure Computing, 2022, 19(3): 2089-2104.), Document

[37] (Zhou X, Lou M, Vijayakumar P, et al. Efficientcertificateless conditional privacy-preserving authentication for VANETs[J]. IEEE Transactions on Vehicular Technology, 2022, 71(7): While solutions 7863-7875 meet certain authentication requirements, they lack corresponding defense mechanisms against collusion attacks, and the scheme relies on a trusted third-party institution to store vehicle registration information. Comparative analysis shows that the certificateless aggregate signature scheme based on SM2, while meeting basic security requirements, considers more security needs. An SM2-based aggregate signature is designed, which calculates a weighted aggregate signature using a random list during signature generation. This prevents attackers from forging legitimate aggregate signatures through joint analysis even if they obtain communication data from multiple vehicles, thus improving the security of the authentication scheme. Utilizing blockchain for distributed storage of vehicle registration information provides decentralized vehicle registration information management. In conclusion, the proposed method meets more security requirements.

[0142] Performance Comparison Analysis

[0143] 1) Calculation cost:

[0144] To facilitate scheme comparison, the analysis of computational overhead primarily considers the computationally expensive cryptographic operations involved in the signature algorithm process. The following definitions are made: The time required for one elliptic curve dot product operation is... Add computation time to the points on an elliptic curve. The time required for one bilinear pairing operation. For the scalar multiplication operation time associated with bilinear mapping, The addition operation time associated with bilinear mapping, The time for one hash operation, The time for one inversion operation is given. The operations were run on an Ubuntu 20.04 operating system using PBC and the OPENSSL library in C. The total operation time was obtained after performing 1000 different password operations, and the average time per operation was calculated. The results are shown in Table 3.

[0145] Table 3: Execution Time of Cryptographic Operations

[0146]

[0147] The method described above is compared with the signature process in references

[28] ,

[36] , and

[37] , and the results are shown in Table 4. In reference

[28] , a single signature requires two map-to-point hash function operations, four elliptic curve multiplication operations, and one elliptic curve addition operation to finally generate the signature. When performing a single signature verification, the calculation is... The calculation of its parameters involves four bilinear pairing operations and two elliptic curve dot products. When verifying k signatures through aggregated signatures, the calculation... Four bilinear pairing operations and 2k elliptic curve dot product operations were used. Reference

[36] used one elliptic curve dot product operation and three hash operations for a single signature, with a computational cost of The verification of a single signature uses five elliptic curve dot multiplication operations, four elliptic curve dot addition operations, and one hash operation, with a computational cost of [missing information]. Reference

[37] uses one elliptic curve dot product and two hash operations for a single signature, with a computational cost of The method employs four elliptic curve dot product operations, three elliptic curve dot addition operations, and three hash operations when verifying a single signature. Specifically, it uses one elliptic curve dot product operation, one hash function operation, and one inversion operation to ultimately calculate the signature for a single signature. Calculated during single signature verification. ,verify The equality check uses two elliptic curve dot product operations and one hash function.

[0148] Table 4: Comparison of computational costs

[0149]

[0150] The computational costs of individual signatures and individual signature verification for each scheme are compared, and the comparison results are as follows: Figure 4 As shown. Reference

[28] uses a map-to-point hash function with higher computational cost than ordinary hash functions for single signature, and uses four bilinear pairing operations with higher computational cost for single signature verification, resulting in high computational cost for single signature and verification stages. Compared with References

[36] and

[37] , the method uses fewer single ordinary hash function operations in the single signature stage. Although it uses more inversion operations, in the single signature verification stage, the method uses two elliptic curve dot product operations, which is three fewer than Reference

[36] and two fewer than Reference

[37] . The method uses one elliptic curve dot addition operation, which is three fewer than Reference

[36] and two fewer than Reference

[37] . The number of ordinary hash function operations used is also less than that in References

[36] and

[37] . Therefore, the method has the advantage of lower computational cost in the single signature and verification stages of related schemes.

[0151] The method described above is compared with the aggregate signature computation overhead in references

[28] ,

[36] , and

[37] , and the results are as follows: Figure 5 As shown. From the perspective of computational overhead, in the aggregate signature verification stage, reference

[28] uses bilinear operations with high computational complexity, resulting in a large computational overhead during aggregate signature verification. Compared with references

[36] and

[37] , which also do not use bilinear pairing operations, in the aggregate signature verification stage, the method described above uses 3k fewer elliptic curve dot product operations and 3k-1 fewer elliptic curve dot addition operations than reference

[36] , and uses k+1 fewer elliptic curve dot product operations and 2k fewer elliptic curve dot addition operations than reference

[37] . Therefore, the computational overhead of the method described above is lower.

[0152] Communication overhead:

[0153] This section analyzes and calculates the specific content of the messages transmitted by each scheme, and the results are shown in Table 4-5. The message transmitted by the method in a single signature stage is... , Size of space occupied , The space occupied is , The space occupied is , The space occupied is the size of the timestamp T. The messages transmitted during the single signature stage in references

[28] ,

[36] , and

[37] are analyzed respectively.

[0154] Table 5: Single Signature Communication Transmission Message

[0155]

[0156] A comparison of the communication overhead of each scheme during message transmission for signing, such as... Figure 6 As shown. Analysis shows that the communication overhead of the proposed method is better than that of reference

[28] , better than that of reference

[37] , and lower than that of reference

[36] . This is mainly because the proposed method adopts a step-by-step key distribution method, in which the key distribution center and the vehicle each generate a part of the key and jointly complete the key generation process. At the same time, the vehicle's anonymity identity is also generated in a step-by-step manner. This method increases the communication overhead to a certain extent, but improves the security of the key and anonymity generation process, avoids the key custody problem of relying entirely on a trusted key distribution center, reduces the risk of key exposure, and improves the overall security of the authentication scheme.

[0157] In summary, this application proposes a certificateless aggregate signature method based on SM2. The method first analyzes the problems and requirements of current traditional authentication schemes, proposes a specific model for the solution, and then provides a detailed description of the processes for system initialization, roadside facility activation, vehicle registration, key distribution, signing, and verification. Security proofs and analysis demonstrate that the proposed method possesses multiple security attributes. Performance analysis and comparison show that the proposed method reduces computational and communication overhead to a certain extent.

Claims

1. A certificateless aggregate signature authentication method based on SM2, characterized in that... Includes the following steps: Initialization: A trusted institution generates public security parameters, stores these parameters secretly, and synchronizes them to the blockchain; Roadside facility activation: The roadside facility sends registration information to a trusted agency, which verifies the registration information and completes the activation upon successful verification. Vehicle Registration and Key Distribution: Intelligent connected vehicles send registration requests to trusted institutions. The trusted institution verifies the timestamp in the request and checks for duplicate vehicle identities. It generates long-term and short-term anonymous identities for the vehicle, stores the encrypted vehicle identity index information on the blockchain, calculates and generates a partial private key for the vehicle, and sends a registration success notification along with relevant identity and partial private key information to the intelligent connected vehicle. The intelligent connected vehicle verifies the partial private key sent by the trusted institution and calculates the complete private key for subsequent signing and authentication. Single signature and verification: The intelligent connected vehicle calculates the signature message and sends it to the roadside facility; the roadside facility first checks the message timestamp to prevent replay attacks and verifies the validity of the signature. After successful verification, it returns a successful authentication result to the intelligent connected vehicle. Aggregated signature and verification phase: The roadside facility first verifies the timestamps of the received multiple messages, performs weighted aggregate signature calculation on the signature information of multiple vehicles, outputs the aggregate result, verifies the generated aggregate signature, and returns the aggregate authentication success result to the intelligent connected vehicle after successful verification, thus completing the batch identity authentication.

2. The certificateless aggregate signature authentication method based on SM2 as described in claim 1, characterized in that, The initialization specifically includes: Trusted organization (TA) performs system initialization and sets security parameters. Calculate the master private key of the trusted institution TA. Calculate the master public key of the trusted authority TA. Output the public parameters required by subsequent modules. ,in The parameters are securely stored by the Trusted Entity (TA), publicly released and transmitted to the blockchain network, and jointly maintained and regularly updated by the TA and the blockchain network. G is an additive cyclic group generated based on elliptic curves, q is a large prime number, and P is the generator of the additive cyclic group G. This is a hash function.

3. The certificateless aggregate signature authentication method based on SM2 as described in claim 2, characterized in that, The initialization specifically includes: Trusted institution TA selects a random number As the system's master private key The master public key of the computing system ; Trusted institution TA will Keep it secret; Trusted Institution (TA) selects hash function ; Public System Public Parameters .

4. The certificateless aggregate signature authentication method based on SM2 as described in claim 2, characterized in that, Activation of roadside facilities includes the following steps: Roadside Facilities (RSUs) apply for activation by providing their real identity information to a Trusted Authority (TA). The TA then assigns an identity identifier to the RSU, stores the real identity information in the blockchain, and the RSU calculates its private key. Calculate the public key Provide the real identity information (RID) and public key to a trusted institution (TA) through a secure channel. After receiving the message, the Trusted Authority (TA) generates an identity identifier (ARID) for the Roadside Unit (RSU) and sets the index pair. Send it to the blockchain, and send the ARID to the RSU via a secure channel.

5. The certificateless aggregate signature authentication method based on SM2 as described in claim 4, characterized in that, Activation of roadside facilities includes the following steps: Roadside facilities RSU selection random number As the RSU private key, i.e. Calculate the RSU public key. ; Registration information Send to a trusted organization (TA); Trusted Institution TA Calculation Upon successful verification, the roadside facility (RSU) generates an identification identifier. ,Will Sending the ARID to the blockchain indicates that the RSU has been activated, and simultaneously sending the ARID to the roadside facility RSU via a secure channel.

6. The certificateless aggregate signature authentication method based on SM2 as described in claim 4, characterized in that, The vehicle registration process includes the following steps: vehicle Prepare registration information This includes the vehicle's license plate information, the owner's personal identification information, and the vehicle's unique physical identifier. vehicle Select random number Calculate partially anonymous identity information Calculate part of the public key ; Calculate the hash function , Vehicle sends messages Trusted Institution TA; When a trusted agency (TA) receives a vehicle registration application, it first verifies whether the timestamp is within the specified range. If the verification is successful, it calculates... , ,judge If they are equal, then the vehicle will be queried on the blockchain network. If an identity exists, the registration request is rejected; otherwise, an anonymous identity is applied for the vehicle. Trusted Institution (TA) selects random numbers Calculate long-term anonymity Trusted agency TA generates short-term pseudo-identities for vehicles. Send long-term anonymous identity, partially short-term anonymous identity, and domain identifier. Give it to the vehicle; encrypt the [data / method / etc.]. Send to the blockchain system; when law enforcement requests information about a vehicle Applications for traceability can be submitted by searching the blockchain. ; vehicle Received And store it in an anti-tamper device; the vehicle's long-term anonymous identity is Short-term anonymous identity .

7. The certificateless aggregate signature authentication method based on SM2 as described in claim 6, characterized in that: By vehicle And the key distribution is completed by the key distribution center in the Trusted Authority (TA): Trusted Institutions (TAs) randomly select ,calculate , Calculate part of the private key ,Will Send to vehicle ; vehicle Receive messages and calculate Calculate and verify whether the equation holds true. If the condition is met, then part of the private key is valid; otherwise, the message is discarded and a new request is made, ultimately obtaining the vehicle's private key. Public key .

8. The certificateless aggregate signature authentication method based on SM2 as described in claim 7, characterized in that, By vehicle Complete the signature, vehicle Send a signed message anonymously: vehicle Randomly select random numbers Where n is the order of G, calculate the summary. ; calculate ; calculate ,like or Then select again calculate; calculate ,if Then select again Calculate; finally output message signature value The vehicle sends a message to the RSU. ; Signature verification is completed via the roadside unit (RSU): Roadside Unit (RSU) receives vehicle The sent signed message first checks whether the timestamp in the message is within the specified range, and then checks the signature value. If the message is not within the range, then reject it. Roadside Unit (RSU) Calculation ,like The signature is then invalid; Roadside Unit (RSU) Calculation ; Roadside Unit (RSU) Calculation ; Roadside Unit (RSU) Calculation ,judge If the condition is met, the authentication is successful.

9. The certificateless aggregate signature authentication method based on SM2 as described in claim 8, characterized in that, Aggregation signature is completed via Roadside Unit (RSU): The roadside unit (RSU) received a certain number of message sets. Verify whether the timestamp is within the specified time range; if it does not meet the requirements, discard the corresponding signature. calculate ; Roadside Unit (RSU) Random List Generation ,calculate , , ; calculate ; Calculate weighted aggregation ; calculate , ; The RSU output aggregate signature is .

10. The certificateless aggregate signature authentication method based on SM2 as described in claim 9, characterized in that, Aggregated signature and verification includes the following steps: First, check if the timestamp is within the specified range; if the timestamp is invalid, discard the signature. calculate Check if it is true; if not, the verification fails. calculate ; calculate ; calculate Determine the equation If the condition is met, the aggregate signature verification is successful.

Images