A terminal group key lightweight aggregation negotiation and verification method and system

Abstract

The present invention relates to a terminal group key lightweight aggregation negotiation and verification method and system. Based on elliptic curve cryptography, a two-layer key structure of individual key (IDK) and group key (GPK) is established, and a lightweight key aggregation negotiation and verification mechanism is designed. A cross-domain authentication terminal is randomly selected as a centralized controller, and other terminals are used as group members to dynamically negotiate keys, thereby improving the flexibility of terminal dynamic management on the basis of reducing single point failures and performance bottlenecks.

Description

Technical Field

[0001] The present invention relates to the field of terminal interaction, and in particular to a terminal group key lightweight aggregation negotiation and verification method and system. Background Art

[0002] With the growing demand for coordinated control of distributed energy sources such as photovoltaics, wind power, and energy storage, and controllable loads such as electric vehicles and smart home appliances, adaptive group dispatching and group control within the security threshold has become a trend. After terminal identity authentication and trust assessment, a cross-regional and cross-domain interaction group is established. Before the secure interaction of business data, there are problems with efficient key negotiation and verification. The group key negotiation mechanism, especially when the number of interactive terminals is large enough, has considerable advantages in terms of low overhead, high efficiency, dynamicity, and consistency. However, resource-constrained terminals still find it difficult to bear its communication and computing overhead, which has become a key issue affecting the practicality of key negotiation. In addition, due to the dynamic nature of terminal group interaction, it is also an urgent problem to be solved in the key negotiation and verification protocol to safely and efficiently revoke the distributed keys or dynamically update the group keys, improve the adaptability of the keys, enhance the credibility of the keys, and enhance the various attack defense capabilities of the key protocol. Summary of the invention

[0003] In order to solve the above problems, the purpose of the present invention is to provide a terminal group key lightweight aggregation negotiation and verification method to achieve lightweight management of key revocation and update, and effectively reduce terminal computing and communication overhead.

[0004] To achieve the above object, the present invention adopts the following technical solutions:

[0005] A terminal group key lightweight aggregation negotiation and verification method, comprising:

[0006] When the terminal in the access domain completes the target cross-domain verification, it exchanges the public key with the terminal in the target domain and randomly selects As Temporary manager of a terminal;

[0007] The terminal of the visited domain and the terminal of the target domain complete the group key negotiation in the terminal group key negotiation group in the TGKAN protocol. The terminal group key negotiation group is a group formed by the terminal of the visited domain and the terminal of the target domain when the terminal of the visited domain completes the target cross-domain verification, and is recorded as the terminal group key negotiation group. ,in express Cross-domain authentication terminal in a domain;

[0008] When the group authentication key negotiation is completed, the terminal in the visited domain negotiates the session key with the terminal in the target domain, and the terminal group key negotiation group Perform an aggregation check.

[0009] Furthermore, the initialization is specifically as follows:

[0010] (1) Call the SRAM PUF module to generate security parameters , Generators of Generating Groups ; Call SRAM PUF to obtain the master key , calculate the public key , choose a hash function and ,in, is a cyclic group; finally Output ;

[0011] (2) Terminal Call the SRAM PUF module to generate random numbers ,in ,calculate and temporary identifier , then Through the rest Send to ;

[0012] (3) Through the rest receive Sent After that, calculate , and Save in Temporary identification index database; generate As a temporary session validity period, when At expiration You need to apply for session negotiation again. ; Random Selection ,calculate , , , through the rest send arrive ;

[0013] (4) Calculate partial private key , ,verify Is it true? If not, recalculate some private keys; Call SRAM PUF module random selection ,calculate ,but The public key is , private key .

[0014] Furthermore, the aggregate verification is as follows:

[0015] (1) Terminal Select random number ,calculate , and generate request information ,in Represents timestamp, calculation , ,get , the last broadcast ; The terminal that receives the broadcast verify Is it true? If so, Add to and save it in the conversation list , then each terminal Finally, we get a list of sessions. , and sends the session request information to ;

[0016] (2) According to the interaction requirements of terminal groups, build Ring Structure Set , and Logically, they are Left and right terminals, order , and create for all legitimate terminals End-to-end group session and generate a session identifier , broadcast ;

[0017] (3) Terminal After receiving the broadcast, generate a message and randomly select the response value , call the SRAM PUF module to calculate and , , ;terminal generate , then to and Send Message ,in yes The timestamp of generation;

[0018] (4) Terminal receive and After sending the message, verify , , If they are consistent, verify and Is it within the specified range? If it passes, verify it. and ,Right now , ; After verification, the terminal calculate , and to Other terminal broadcasts in ;

[0019] (5) Terminal Verify when receiving broadcast requests from other terminals and If they are consistent, verify Is it within the specified range? If yes, wait. Then collect the remaining broadcast messages. If the number of collected messages is less than , or the identifier is not in the generated terminal group, these terminals will be withdrawn from negotiation; Aggregate all received information ,in , ; Then verify If it is not true, verify each message separately to collect the correct signature, otherwise abandon the signature; after verification, Calculate the session key ;

[0020] Generate the same key for each terminal group , calculate , then generates the message Send to ;

[0021] (6) verify Is it within the validity period? If yes, wait Receive the rest of the message and verify the received hash If the hash values ​​are equal, it means that the terminal group has established a usable session key, and A confirmation message is sent to the group of terminals; when the group of terminals confirm the message, communication begins.

[0022] Furthermore, since there is a need for terminals in the group to dynamically join or leave, in order to ensure the security of terminal sessions, the group session key must be updated whenever the group terminals change. Based on the terminal group dynamic management mechanism, key negotiation and update are performed for terminals that dynamically join and leave.

[0023] Furthermore, the dynamic terminal joining is as follows:

[0024] Set up terminal group To join a terminal group that has completed key negotiation The steps are as follows:

[0025] (1) From Select two terminals and Join a new group; now grouped as and ;

[0026] (2) and Reselect the response value and , calculate according to the steps in 5.2.2 , , , , , , signature value and ; Due to the original terminal group Key Negotiation has been completed, so no verification is required when negotiating again; the newly joined terminal group Perform the above authentication process and finally get the key ;

[0027] (3) and Use the original key Encryption Key , and send it to the original terminal group other members of and Use new key Encrypt the original key , and sent to other members who have newly joined the terminal group;

[0028] (4) Merge the above two terminal groups , calculate the new group key as .

[0029] Further, the dynamic terminal leaves as follows:

[0030] Set up terminal group is the current group, and is the exit terminal set, where , then the remaining terminal set is ;

[0031] When the terminal When checking The left adjacent terminal or right adjacent terminal Have you left? or ,So You need to reselect random numbers and calculate and , and send it to the remaining terminals ;

[0032] if When the left and right adjacent terminals do not change, then Only the originally calculated and Send to remaining terminals ;

[0033] when Receive all values and After that, each terminal Verify the aggregation result. After successful verification, the relevant parties continue to calculate the new session key.

[0034] A terminal group key lightweight aggregation negotiation and verification system includes several domains composed of terminal groups; when a terminal in one domain needs to access a terminal in another domain, it is divided into an access domain and a target domain. Specifically: when the terminal in the access domain completes the target cross-domain verification, it exchanges public keys with the terminal in the target domain and randomly selects As Temporary manager of a terminal;

[0035] The terminal of the visited domain and the terminal of the target domain complete the group key negotiation in the terminal group key negotiation group in the TGKAN protocol. The terminal group key negotiation group is a group formed by the terminal of the visited domain and the terminal of the target domain when the terminal of the visited domain completes the target cross-domain verification, and is recorded as the terminal group key negotiation group. ,in express Cross-domain authentication terminal in a domain;

[0036] When the group authentication key negotiation is completed, the terminal in the visited domain negotiates the session key with the terminal in the target domain, and the terminal group key negotiation group Perform an aggregation check.

[0037] Further, initialization is as follows:

[0038] (1) Call the SRAM PUF module to generate security parameters , Generators of Generating Groups ; Call SRAM PUF to obtain the master key , calculate the public key , choose a hash function and ,in, is a cyclic group; finally Output ;

[0039] (2) Terminal Call the SRAM PUF module to generate random numbers ,in ,calculate and temporary identifier , then Through the rest Send to ;

[0040] (3) Through the rest receive Sent After that, calculate , and Save in Temporary identification index database; generate As a temporary session validity period, when At expiration You need to apply for session negotiation again. ; Random Selection ,calculate , , , through the rest send arrive ;

[0041] (4) Calculate partial private key , ,verify Is it true? If not, recalculate some private keys; Call SRAM PUF module random selection ,calculate ,but The public key is , private key .

[0042] Furthermore, the aggregate verification is as follows:

[0043] (1) Terminal Select random number ,calculate , and generate request information ,in Represents timestamp, calculation , ,get , the last broadcast ; The terminal that receives the broadcast verify Is it true? If so, Add to and save it in the conversation list , then each terminal Finally, we get a list of sessions. , and sends the session request information to ;

[0044] (2) According to the interaction requirements of terminal groups, build Ring Structure Set , and Logically, they are Left and right terminals, order , and create for all legitimate terminals End-to-end group session and generate a session identifier , broadcast ;

[0045] (3) Terminal After receiving the broadcast, generate a message and randomly select the response value , call the SRAMPUF module to calculate and , , ;terminal generate , then to and Send Message ,in yes The timestamp of generation;

[0046] (4) Terminal receive and After sending the message, verify , , If they are consistent, verify and Is it within the specified range? If it passes, verify it. and ,Right now , ; After verification, the terminal calculate , and to Other terminal broadcasts in ;

[0047] (5) Terminal Verify when receiving broadcast requests from other terminals and If they are consistent, verify Is it within the specified range? If yes, wait. Then collect the remaining broadcast messages. If the number of collected messages is less than , or the identifier is not in the generated terminal group, these terminals will be withdrawn from negotiation; Aggregate all received information ,in , ; Then verify If it is not true, verify each message separately to collect the correct signature, otherwise abandon the signature; after verification, Calculate the session key ;

[0048] Generate the same key for each terminal group , calculate , then generates the message Send to ;

[0049] (6) verify Is it within the validity period? If yes, wait Receive the rest of the message and verify the received hash If the hash values ​​are equal, it means that the terminal group has established a usable session key, and A confirmation message is sent to the group of terminals; when the group of terminals confirm the message, communication begins.

[0050] Furthermore, since there is a need for terminals in the group to dynamically join or leave, in order to ensure the security of terminal sessions, the group session key must be updated whenever the group terminals change. Based on the terminal group dynamic management mechanism, key negotiation and update are performed for terminals that dynamically join and leave.

[0051] Furthermore, the dynamic terminal joining is as follows:

[0052] Set up terminal group To join a terminal group that has completed key negotiation The steps are as follows:

[0053] (1) From Select two terminals and Join a new group; now grouped as and ;

[0054] (2) and Reselect the response value and , calculate according to the steps in 5.2.2 , , , , , , signature value and ; Due to the original terminal group Key Negotiation has been completed, so no verification is required when negotiating again; the newly joined terminal group Perform the above authentication process and finally get the key ;

[0055] (3) and Use the original key Encryption Key , and send it to the original terminal group other members of and Use new key Encrypt the original key , and sent to other members who have newly joined the terminal group;

[0056] (4) Merge the above two terminal groups , calculate the new group key as .

[0057] Further, the dynamic terminal leaves as follows:

[0058] Set up terminal group is the current group, and is the exit terminal set, where , then the remaining terminal set is ;

[0059] When the terminal When checking The left adjacent terminal or right adjacent terminal Have you left? or ,So You need to reselect random numbers and calculate and , and send it to the remaining terminals ;

[0060] if When the left and right adjacent terminals do not change, then Only the originally calculated and Send to remaining terminals ;

[0061] when Receive all values and After that, each terminal Verify the aggregation result. After successful verification, the relevant parties continue to calculate the new session key.

[0062] The present invention has the following beneficial effects:

[0063] 1. Based on elliptic curve cryptography (ECC), the present invention establishes a two-layer key structure of individual key (IDK) and group key (GPK), designs a lightweight key aggregation negotiation verification mechanism, randomly selects cross-domain authentication terminals as centralized controllers, and other terminals dynamically negotiate keys as group members, thereby improving the flexibility of terminal dynamic management on the basis of reducing single point failures and performance bottlenecks;

[0064] 2. The present invention establishes an anonymous protection mechanism with an optional time scale. The cross-domain authentication terminal uses the master key and the terminal identity to derive an anonymous identity as a temporary identifier for the terminal to negotiate keys and communicate. This allows a high-security-level terminal to negotiate keys with an external terminal, decoupling the real identity from the terminal information. Even if an attacker intercepts the communication data, it is difficult to associate it with a specific terminal.

[0065] 3. The present invention adopts aggregate authentication to improve the efficiency of group key verification, realize lightweight management of key revocation and update, and effectively reduce terminal computing and communication overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Figure 1 This is the initialization phase of the terminal group key negotiation in one embodiment of the present invention;

[0067] Figure 2 This is the terminal group key negotiation aggregation verification stage in one embodiment of the present invention. DETAILED DESCRIPTION

[0068] The present invention is further described in detail below with reference to the accompanying drawings and specific embodiments:

[0069] In this embodiment, a terminal group key lightweight aggregation negotiation and verification method is provided, which is characterized by comprising the following steps:

[0070] After the terminal of the access domain completes the verification of the cross-domain authentication terminal of the target domain, the group formed by the terminal of the access domain and the terminal of the target domain is recorded as the terminal group key negotiation group ,in express Cross-domain authentication terminal in a domain;

[0071] First, the terminal in the target domain and the terminal in the access domain exchange their public keys and randomly select As The temporary manager of the terminal, through initialization, the terminal of the target domain and the terminal of the access domain Complete group key negotiation in the TGKAN protocol;

[0072] After completing the initialization and group authentication key negotiation, the access domain and target domain terminals begin to negotiate the session key, and the terminal group key negotiation group Perform an aggregation check.

[0073] In this embodiment, reference Figure 1 , the terminal group key negotiation initialization phase, specifically:

[0074] (1) : Call the SRAM PUF module to generate security parameters , generate ; Call SRAM PUF to obtain the master key , calculate the public key , choose a hash function and ,at last Output ;

[0075] (2) :terminal Call the SRAM PUF module to generate random numbers ,in ,calculate and temporary identifier , then Through the rest Send to ;

[0076] (3) : Through the rest receive Sent After that, calculate , and Save in Temporary identification index database; generate As a temporary session validity period, when At expiration You need to apply for session negotiation again. ; Random Selection ,calculate , , , through the rest send arrive ;

[0077] (4) : Calculate partial private key , ,verify Is it true? If not, recalculate some private keys; Call SRAM PUF module random selection ,calculate ,but The public key is , private key .

[0078] refer to Figure 2 In this embodiment, the aggregation verification steps are as follows:

[0079] (1) :terminal Select random number ,calculate , and generate request information ,in Represents timestamp, calculation , ,get , the last broadcast ; The terminal that receives the broadcast verify Is it true? If so, Add to and save it in the conversation list , then each terminal Finally, we get a list of sessions. , and sends the session request information to ;

[0080] (2) : According to the interaction requirements of terminal groups, build Ring Structure Set , and Logically, they are Left and right terminals, order , and create for all legitimate terminals End-to-end group session and generate a session identifier , broadcast ;

[0081] (3) :terminal After receiving the broadcast, generate a message and randomly select the response value , call the SRAM PUF module to calculate and , , ;terminal generate , then to and Send Message ,in yes The timestamp of generation;

[0082] (4) :terminal receive and After sending the message, verify , , If they are consistent, verify and Is it within the specified range? If it passes, verify it. and ,Right now , ; After verification, the terminal calculate , and to Other terminal broadcasts in ;

[0083] (5) :terminal Verify when receiving broadcast requests from other terminals and If they are consistent, verify Is it within the specified range? If yes, wait. Then collect the remaining broadcast messages. If the number of collected messages is less than , or the identifier is not in the generated terminal group, these terminals will be withdrawn from negotiation; Aggregate all received information ,in , ; Then verify If it is not true, verify each message separately to collect the correct signature, otherwise abandon the signature; after verification, Calculate the session key ;

[0084] Generate the same key for each terminal group , calculate , then generates the message Send to ;

[0085] (6) : verify Is it within the validity period? If yes, wait Receive the rest of the message and verify the received hash If the hash values ​​are equal, it means that the terminal group has established a usable session key, and A confirmation message is sent to the group of terminals; when the group of terminals confirm the message, communication begins.

[0086] Preferably, in this embodiment, since there is a need for terminals in the group to dynamically join or leave, in order to ensure the security of the terminal session, the group session key must be updated whenever the group terminal changes, and key negotiation and update are performed for the terminals that dynamically join and leave based on the terminal group dynamic management mechanism.

[0087] Dynamic terminal addition, as follows:

[0088] Set up terminal group To join a terminal group that has completed key negotiation The steps are as follows:

[0089] (1) From Select two terminals and Join a new group; now grouped as and ;

[0090] (2) and Reselect the response value and , calculate according to the steps in 5.2.2 , , , , , , signature value and ; Due to the original terminal group Key Negotiation has been completed, so no verification is required when negotiating again; the newly joined terminal group Perform the above authentication process and finally get the key ;

[0091] (3) and Use the original key Encryption Key , and send it to the original terminal group other members of and Use new key Encrypt the original key , and sent to other members who have newly joined the terminal group;

[0092] (4) Merge the above two terminal groups , calculate the new group key as .

[0093] Dynamic terminal departure, as follows:

[0094] Set up terminal group is the current group, and is the exit terminal set, where , then the remaining terminal set is ;

[0095] When the terminal When checking The left adjacent terminal or right adjacent terminal Have you left? or ,So You need to reselect random numbers and calculate and , and send it to the remaining terminals ;

[0096] if When the left and right adjacent terminals do not change, then Only the originally calculated and Send to remaining terminals ;

[0097] when Receive all values and After that, each terminal Verify the aggregation result. After successful verification, the relevant parties continue to calculate the new session key. Embodiment 1:

[0098] In this embodiment, in order to prove the unforgeability of the scheme, we first construct two types of adversaries: and Among them, the opponent A malicious ordinary terminal that cannot master the master key but has the ability to replace the public and private key pair of any terminal; For a malicious cross-domain authentication terminal, it can master the master key but cannot replace the public key of any terminal. Then define 5 adversaries and The random oracles that can be adaptively accessed are as follows:

[0099] Public key: When an adversary accesses the terminal When the challenger receives the public key, the challenger returns the corresponding public key;

[0100] Secret value: When an adversary accesses the terminal When the challenger returns the corresponding secret value,

[0101] Partial private key: When the adversary accesses the terminal When the challenger receives a partial private key, the challenger returns the corresponding partial private key;

[0102] Public key replacement: When the adversary replaces the terminal When the terminal's public key is a partial public key, the terminal's public key-private key pair consists of Replace with ;

[0103] (5) Verification value: terminal Input Message The signature oracle selects one of the following three situations as the return verification value: 1) If the terminal inquiring If it exists and its public key-private key pair is not replaced, then a valid verification value is returned; 2) If the terminal being queried If it does not exist, return the terminator; 3) If the terminal being queried Exists, and its public-private key pair is found to be replaced , the oracle returns .

[0104] Theorem 1: Assuming that the CDH problem is difficult, if the scheme can resist the adversary and and , prove that the scheme is unforgeable under adaptive chosen message attack.

[0105] Lemma 1: In the random oracle model, if the adversary To attack this scheme with a non-negligible advantage, there exists an algorithm Can exceed The advantage of solving CDH problems.

[0106] Proof: Assumption Able to solve CDH problems , then the opponent Can be calculated , the specific steps are as follows:

[0107] (1) Initialization

[0108] run Algorithm, set ,adversary Get public parameters .

[0109] (2) ask

[0110] Maintain the initial empty List. When the adversary ask When the query value is in middle, Returns the corresponding value; otherwise, Random Selection , then Send to adversary and put it into list.

[0111] (3) Public key query

[0112] Maintain the initial empty List. When the adversary Inquiry terminal If There are corresponding values ​​in ,So Returns the corresponding public key ;otherwise, Random Selection and ,calculate and and send it to the adversary .if , Random Selection ,calculate Send to adversary and add it to the list If , Random Selection , ,calculate Send to adversary and add it to middle.

[0113] (4) Secret value query

[0114] Maintain the initial empty List. When the adversary Inquiry terminal When the secret value is , stop otherwise, Random Selection Send to adversary and add it to middle.

[0115] (5) Partial private key query

[0116] Maintain the initial empty List. When the adversary Inquiry terminal If There are corresponding values ​​in ,So Return the corresponding .if , stop If , Random Selection and send it to the adversary .

[0117] (6) Public key replacement

[0118] adversary Randomly select terminal Get its public key and replace it with .

[0119] (7) Verification value query

[0120] When the enemy Inquiry terminal right When verifying the value of , Stop answering. Otherwise, Randomly select a response , then calculate , , , , and finally output the verification value .

[0121] (8) Aggregate verification query

[0122] When the enemy Inquiry terminal right If the verification value of the terminal Both ,So For each Randomly select a response , then calculate , , , For each calculate , , and aggregate the validation value Send to adversary .otherwise, stop Inquiry.

[0123] (9) Forgery process

[0124] adversary Forged aggregate verification value , where at least one terminal ,adversary No part of the private key is asked for. If all Both ,So stop As long as there is , Find in each list The values ​​of all tuples in . verify If true, then Output The specific calculation process is as follows:

[0125]

[0126]

[0127]

[0128]

[0129] therefore, The CDH problem was successfully solved, but this contradicts the assumption of the CDH problem.

[0130] Lemma 2: Under the random prediction model, if the adversary To attack this scheme with a non-negligible advantage, there exists an algorithm Can exceed The advantage of solving CDH problems.

[0131] Proof: Assumption Able to solve CDH problems , then the opponent Can be calculated , the specific steps are as follows:

[0132] (1) Initialization

[0133] run Algorithm, set , and Send to adversary , where the adversary Master Key . , public key, partial private key, secret value, verification value and aggregate verification are the same as Lemma 1.

[0134] (2) Public key query

[0135] Maintain the initial empty List. When the adversary Inquiry terminal The public key of Check if There are corresponding values ​​in , Return the corresponding and send it to the adversary .if , Random Selection ,calculate , and send it to the adversary , and add this tuple to ;if , Random Selection , calculate and add it to middle.

[0136] (3) Forgery

[0137] adversary Forged an aggregate signature, where at least one terminal ,adversary No part of the private key is asked for. If all Both ,So stop As long as there is , Find in each list The values ​​of all tuples in . verify If this equation holds, then Output The specific calculation process is as follows:

[0138]

[0139]

[0140] The CDH puzzle is successfully solved, but this contradicts the assumption of the CDH puzzle. From the proof of Lemma 1 and Lemma 2, it can be seen that Theorem 1 is valid.

[0141] In this embodiment, the solution not only realizes the security of non-forgeability, but also has the security defense capabilities of identity anonymity protection, resistance to counterfeit attacks, resistance to DoS attacks, etc., as follows:

[0142] (1) Identity anonymity: Temporary identities and validity periods are introduced during the registration phase, so that even if an attacker obtains a temporary identity, they cannot be tracked continuously. The continuous updating of temporary identities can improve terminal identity security.

[0143] (2) Resistance to selected aggregate message attacks: The attacker can access a random oracle, adaptively select a subset of messages from the terminal group for the challenger to sign, and then try to forge an aggregate signature for a new subset of messages. The probability of the attacker successfully forging in polynomial time is negligible.

[0144] (3) Anti-forgery attack: Even if an attacker can access the oracle and obtain valid signatures of some messages, he cannot forge a valid signature for a new message.

[0145] (4) Anti-replay attack: Each session is assigned a timestamp to ensure that the attacker cannot resend the same session request.

[0146] (5) Resistance to DoS attacks: Before verifying the correctness of the message, the cross-domain authentication terminal and other terminals wait for a certain time to receive the message. If all messages are not received within a certain period of time or the received message is inconsistent with the expected one, the protocol will terminate.

[0147] (6) Full forward / backward security: The cross-domain authentication terminals are divided into session groups according to the session requirements, and terminals are randomly selected in each session group to start key negotiation. Even if an attacker obtains one or more terminal private keys, the group key cannot be calculated. At the same time, due to the randomness of the group key generation, the subsequent group session key is computationally infeasible. In addition, the group key is recalculated every time a new terminal joins or an old terminal leaves, so the new terminal does not know the old group session key and the old terminal cannot calculate the new group session key.

[0148] Furthermore, the security features of this solution are compared with other similar solutions. From the table below, it can be seen that the above analysis shows that the solution has good security. Our solution has better security performance than other solutions.

[0149]

[0150] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0151] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0152] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0153] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0154] The above is only a preferred embodiment of the present invention, and does not limit the present invention in other forms. Any technician familiar with the profession may use the above disclosed technical content to change or modify it into an equivalent embodiment with equivalent changes. However, any simple modification, equivalent change and modification made to the above embodiment according to the technical essence of the present invention without departing from the technical solution of the present invention still belongs to the protection scope of the technical solution of the present invention.

Claims

1. A terminal group key lightweight aggregation negotiation and verification method, characterized in that: include: When the terminal in the access domain completes the target cross-domain verification, it exchanges public keys with the terminal in the target domain; The terminal of the visited domain and the terminal of the target domain complete the group key negotiation in the terminal group key negotiation group in the TGKAN protocol, wherein the terminal group key negotiation group is a group formed by the terminal of the visited domain and the terminal of the target domain when the terminal of the visited domain completes the target cross-domain verification, and is recorded as the terminal group key negotiation group ,in express Cross-domain authentication terminal in a domain; When the group authentication key negotiation is completed, the terminal of the visited domain negotiates the session key with the terminal of the target domain, wherein the terminal group key negotiation group to which the terminal of the visited domain belongs is Perform aggregate validation; The terminal of the visited domain and the terminal of the target domain complete the group key negotiation in the terminal group key negotiation group in the TGKAN protocol, including: (1) The terminal in the access domain exchanges public keys with the terminal in the target domain and randomly selects As Temporary manager of a terminal; Generate security parameters , Generators of Generating Groups ; Call SRAM PUF to obtain the master key , calculate the public key , choose a hash function and ,in, is a cyclic group; finally Output ; (2) Terminal accessing the domain Call SR to generate random numbers ,in ,calculate and temporary identifier , then Through the rest Send to ; (3) Temporary Manager Through the rest receive Sent After that, calculate , and Save in Temporary identification index database; generate As a temporary session validity period, when At expiration You need to apply for session negotiation again. ; Random Selection ,calculate , , , through the rest send arrive ; (4) Terminals accessing the domain Calculate partial private key , ,verify Is it true? If not, recalculate some private keys; Call SRAM PUF module random selection ,calculate ,but The public key is , private key .

2. According to claim 1, a terminal group key lightweight aggregation negotiation and verification method is characterized in that: The aggregation verification is specifically as follows: (1) Terminal accessing the domain Select random number ,calculate , and generate request information ,in Represents timestamp, calculation , ,get , the last broadcast ; The terminal that receives the broadcast verify Is it true? If so, Add to and save it in the conversation list , then each terminal Finally, we get a list of sessions. , and sends the session request information to ; (2) Temporary Manager According to the interaction requirements of terminal groups, build Ring Structure Set , and Logically, they are Left and right terminals, order , and create for all legitimate terminals End-to-end group session and generate a session identifier , broadcast ; (3) Terminals accessing the domain After receiving the broadcast, generate a message and randomly select the response value ,calculate and , , ;terminal generate , then to and Send Message ,in yes The timestamp of generation; (4) Terminals accessing the domain receive and After sending the message, verify , , If they are consistent, verify and Is it within the specified range? If it passes, verify it. and ,Right now , ; After verification, the terminal calculate , and to Other terminal broadcasts in ; (5) Accessing Domain Terminal Verify when receiving broadcast requests from other terminals and If they are consistent, verify Is it within the specified range? If yes, wait. Then collect the remaining broadcast messages. If the number of collected messages is less than , or the identifier is not in the generated terminal group, these terminals will be withdrawn from negotiation; Aggregate all received information ,in , ; Then verify If it is not true, verify each message separately to collect the correct signature, otherwise abandon the signature; after verification, Calculate the session key ; Generate the same key for each terminal group , calculate , then generates the message Send to temporary manager ; (6) Temporary Manager verify Is it within the validity period? If yes, wait Receive the rest of the message and verify the received hash If the hash values ​​are equal, it means that the terminal group has established a usable session key, and A confirmation message is sent to the group of terminals; when the group of terminals confirm the message, communication begins.

3. According to claim 1, a terminal group key lightweight aggregation negotiation and verification method is characterized in that: When the group terminals change, key negotiation and update are performed for the terminals joining and leaving the dynamic terminals based on the terminal group dynamic management mechanism.

4. A terminal group key lightweight aggregation negotiation and verification method according to claim 3, characterized in that: The dynamic terminal joining is as follows: Set up terminal group To join a terminal group that has completed key negotiation The steps are as follows: (1) From Select two terminals and Join a new group; now grouped as and ; (2) and Reselect the response value and , calculate according to the steps in 5.2.2 , , , , , , signature value and ; Due to the original terminal group Key Negotiation has been completed, so no verification is required when negotiating again; the newly joined terminal group Perform the above authentication process and finally get the key ; (3) and Use the original key Encryption Key , and send it to the original terminal group other members of and Use new key Encrypt the original key , and sent to other members who have newly joined the terminal group; (4) Merge the above two terminal groups , calculate the new group key as .

5. A terminal group key lightweight aggregation negotiation and verification method according to claim 3, characterized in that: The dynamic terminal leaves as follows: Set up terminal group is the current group, and is the exit terminal set, where , then the remaining terminal set is ; When the terminal When checking The left adjacent terminal or right adjacent terminal Have you left? or ,So You need to reselect random numbers and calculate and , and send it to the remaining terminals ; if When the left and right adjacent terminals do not change, then Only the originally calculated and Send to remaining terminals ; when Receive all values and After that, each terminal Verify the aggregation result. After successful verification, the relevant parties continue to calculate the new session key.

6. A terminal group key lightweight aggregation negotiation and verification system, characterized in that: It includes several domains composed of terminal groups. When a terminal in one domain needs to access a terminal in another domain, it is divided into an access domain and a target domain. Specifically, when the terminal in the access domain completes the target cross-domain verification, it exchanges the public key with the terminal in the target domain and randomly selects As Temporary manager of a terminal; The terminal of the visited domain and the terminal of the target domain complete the group key negotiation in the terminal group key negotiation group in the TGKAN protocol. The terminal group key negotiation group is a group formed by the terminal of the visited domain and the terminal of the target domain when the terminal of the visited domain completes the target cross-domain verification, and is recorded as the terminal group key negotiation group. ,in express Cross-domain authentication terminal in a domain; When the group authentication key negotiation is completed, the terminal in the visited domain negotiates the session key with the terminal in the target domain, and the terminal group key negotiation group Perform aggregate validation; The terminal of the visited domain and the terminal of the target domain complete the group key negotiation in the terminal group key negotiation group in the TGKAN protocol, specifically: (1) Call the SRAM PUF module to generate security parameters , Generators of Generating Groups ; Call SRAM PUF to obtain the master key , calculate the public key , choose a hash function and ,in, is a cyclic group; finally Output ; (2) Terminal Call the SRAM PUF module to generate random numbers ,in ,calculate and temporary identifier , then Through the rest Send to ; (3) Through the rest receive Sent After that, calculate , and Save in Temporary identification index database; generate As a temporary session validity period, when At expiration You need to apply for session negotiation again. ; Random Selection ,calculate , , , through the rest send arrive ; (4) Calculate partial private key , ,verify Is it true? If not, recalculate some private keys; Call SRAM PUF module random selection ,calculate ,but The public key is , private key .

7. According to claim 6, a terminal group key lightweight aggregation negotiation and verification system is characterized in that: The aggregation verification is specifically as follows: (1) Terminal Select random number ,calculate , and generate request information ,in Represents timestamp, calculation , ,get , the last broadcast ; The terminal that receives the broadcast verify Is it true? If so, Add to and save it in the conversation list , then each terminal Finally, we get a list of sessions. , and sends the session request information to ; (2) According to the interaction requirements of terminal groups, build Ring Structure Set , and Logically, they are Left and right terminals, order , and create for all legitimate terminals End-to-end group session and generate a session identifier , broadcast ; (3) Terminal After receiving the broadcast, generate a message and randomly select the response value , call the SRAM PUF module to calculate and , , ;terminal generate , then to and Send Message ,in yes The timestamp of generation; (4) Terminal receive and After sending the message, verify , , If they are consistent, verify and Is it within the specified range? If it passes, verify it. and ,Right now , ; After verification, the terminal calculate , and to Other terminals broadcast ; (5) Terminal Verify when receiving broadcast requests from other terminals and If they are consistent, verify Is it within the specified range? If yes, wait. Then collect the remaining broadcast messages. If the number of collected messages is less than , or the identifier is not in the generated terminal group, these terminals will be withdrawn from negotiation; Aggregate all received information ,in , ; Then verify If it is not true, verify each message separately to collect the correct signature, otherwise abandon the signature; after verification, Calculate the session key ; Generate the same key for each terminal group , calculate , then generates the message Send to ; (6) verify Is it within the validity period? If yes, wait Receive the rest of the message and verify the received hash If the hash values ​​are equal, it means that the terminal group has established a usable session key, and A confirmation message is sent to the group of terminals; when the group of terminals confirm the message, communication begins.

8. A terminal group key lightweight aggregation negotiation and verification system according to claim 6, characterized in that: Since terminals in a group may dynamically join or leave, in order to ensure the security of terminal sessions, the group session key must be updated whenever a terminal in the group changes. Based on the dynamic management mechanism of the terminal group, key negotiation and update are performed for terminals that dynamically join or leave.

9. A terminal group key lightweight aggregation negotiation and verification system according to claim 8, characterized in that: The dynamic terminal joining is as follows: Set up terminal group To join a terminal group that has completed key negotiation The steps are as follows: (1) From Select two terminals and Join a new group; now grouped as and ; (2) and Reselect the response value and , calculate according to the steps in 5.2.2 , , , , , , signature value and ; Due to the original terminal group Key Negotiation has been completed, so no verification is required when negotiating again; the newly joined terminal group Perform the above authentication process and finally get the key ; (3) and Use the original key Encryption Key , and send it to the original terminal group other members of and Use new key Encrypt the original key , and sent to other members who have newly joined the terminal group; (4) Merge the above two terminal groups , calculate the new group key as .

10. A terminal group key lightweight aggregation negotiation and verification system according to claim 8, characterized in that: Dynamic terminal departure, as follows: Set up terminal group is the current group, and is the exit terminal set, where , then the remaining terminal set is ; When the terminal When checking The left adjacent terminal or right adjacent terminal Have you left? or ,So You need to reselect random numbers and calculate and , and send it to the remaining terminals ; if When the left and right adjacent terminals do not change, then Only the originally calculated and Send to remaining terminals ; when Receive all values and After that, each terminal Verify the aggregation result. After successful verification, the relevant parties continue to calculate the new session key.

Images