A resource authentication method based on one-way two-party key agreement and proof of work

Abstract

The application discloses a resource authentication method based on one-way two-party key negotiation and proof of work, comprising: system setting, derivation of shared symmetric key, group user consensus, generation of two-party session key, and verification of the computing power of out-group users. The application proposes a resource authentication method based on one-pass HMQV two-party key negotiation and proof of work, which is used for solving the problem that out-group users with weak computing power pretend to be out-group users with strong computing power to join a group. The method is used for performing resource authentication by force, performing computing power evaluation on out-group users who hope to join the group, preventing out-group users with weak computing power or without computing power, and ensuring the performance and security of a group communication system.

Description

Technical Field

[0001] This invention belongs to the field of information security and resource authentication technology, specifically relating to a resource authentication method based on one-way two-party key negotiation and proof of work, wherein one-way two-party key negotiation refers to one-pass HMQV two-party key negotiation. Background Technology

[0002] Group communication refers to the process of exchanging and communicating information among a group or multiple participants. Compared to traditional one-to-one communication, group communication supports more diverse communication methods and offers higher efficiency and reliability. With the rapid development of the internet, group communication is widely used in cable television, video calls, voice calls, online education, multi-user group chats, and online games.

[0003] In group communication systems, there is a problem where users with weak computing power impersonate users with strong computing power to join the group. The presence of even one user with weak computing power will delay the system's response time. In extreme cases where most group users have weak or no computing power, the performance of the group communication system will significantly degrade. Therefore, it is necessary to design an efficient and intelligent computing power assessment mechanism to verify users' computing capabilities. Resource authentication is an effective method for assessing computing power and can prevent users with weak or no computing power from joining the group communication system. By enforcing resource authentication, group users can effectively assess the computing power of potential users outside the group, thereby maintaining the performance and security of the group communication system.

[0004] Currently, a combination of proof-of-work and signature technology is used to implement resource authentication. This involves a group of users receiving a random message and requiring users outside the group to generate an n-digit signature starting with zeros within a given timeframe. However, this method forces users outside the group to sign a message, potentially leading to the leakage of their private information. Therefore, a more secure method is needed to prevent the leakage of information from users outside the group. Summary of the Invention

[0005] The purpose of this invention is to address the problem of weak external users posing as strong external users to join a group. A resource authentication method based on one-pass HMQV two-party key negotiation and proof-of-work is proposed. By enforcing resource authentication, group users assess the computing power of external users wishing to join the group, preventing the admission of external users with weak or no computing power, thus ensuring the performance and security of the group communication system.

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

[0007] A resource authentication method based on one-way two-party key negotiation and proof-of-work includes the following entities: a trusted third party (TA), a blockchain, a server, and system users; the server is only responsible for message forwarding; system users are divided into out-of-group users and group users according to their identities, with out-of-group users referring to users who wish to join the group and group users referring to users who have already joined the group, and each system user holding a public-private key pair; the trusted third party (TA) is responsible for generating system parameters and public key certificates for each system user; the blockchain refers to a public blockchain that stores the public information of each group user, including public key PK. i Group Gp consists of n group users U i Composed of a group, where i∈[1,n], where users in the group share a group session key gsk, and a secure communication channel is established through the session key gsk; if a user holds a public-private key pair (pk * ,sk * User U outside the group * I want to join group Gp, where g is a cyclic group of order q. The generator; characterized in that the resource authentication method includes the following steps:

[0008] Step 1: System Settings

[0009] A trusted third party (TA) generates and distributes system parameters (params) for the entire system. These parameters include the difficulty value σ of the proof-of-work algorithm, the message round-trip time threshold ΔT, and the hash function H(*). Key Derivation Function (KDF), i.e. Specifically, it includes:

[0010] 1) During system settings, the difficulty value of the puzzle used in the generation method is specified, i.e., the number of 0 bits required. The amount of work required to solve the puzzle is exponentially related to the difficulty value; the difficulty value is used to control the computation time; a time threshold is used to determine the credibility of the message; a hash function is used to perform the computation; specifically as follows:

[0011] • σ is chosen as the difficulty value for the proof-of-work algorithm;

[0012] • Select △T as the threshold for message round-trip time;

[0013] • Select H(*) As a hash function;

[0014] 2) Trusted Third Party (TA) Key Selection Derivation Function Example KDF:{0,1} * →{0,1} lena , where lena is the output length of the key derivation function; KDF maps an input of arbitrary length to a random string of lena bits;

[0015] 3) Trusted third party TA will Distributed to users outside the group U * and group users {U1,U2,...,U n};

[0016] Step 2: Derivation of shared symmetric key

[0017] Each group user U i For i∈[1,n], a shared symmetric key mk=KDF(gsk) is derived using the group session key gsk. The public parameter K=g is calculated and published to generate the two-party session key. mk ;

[0018] Step 3: Group User Consensus

[0019] All group users elect a group user U using a consensus mechanism that employs Proof-of-Work, Proof-of-Stake, Delegated Proof-of-Stake, Authorization Proof-of-Stake, or Proof-of-Weight. j ∈Gp, responsible for verifying user U outside the group * Computing power;

[0020] Step 4: Generate session keys for both parties

[0021] Group user U j User U from outside the group * The initiator uses one-pass HMQV two-party key negotiation to generate a two-party session key tsk; specifically including:

[0022] 1) Group user U j Random selection in Given a finite field of order p, compute the public parameter X = g used to generate the two-party session key. x Send X to user U outside the group * Save the current local timestamp

[0023] 2) Group user U j Use one-pass HMQV to negotiate and generate a two-party session key tsk; and These represent group user U. j and external users U * identity, Indicates that it includes group user U j and external users U * Messages from the identity of group user U j Calculate hash value Group user U j Use the shared symmetric key mk to access the message. Perform a signature operation to generate a signature. pk * User U from outside the group * The public key; the session key between the two parties. The length of the output of the hash function H is equal to the length of the required key;

[0024] 3) External user U * Upon receiving the public parameter X used to generate the two-party session key, verify whether X ≠ 0; if the verification is successful, the external user U... * Generate two-party session keys using one-pass HMQV two-party key negotiation. in

[0025] Step 5: Verify the computing power of users outside the group

[0026] User U from outside the group * Randomly select a random number r, and repeatedly calculate the hash value proof = H(tsk, r) until the first σ bits of the calculated result proof are all 0. Then, combine the triples (r, proof, cer) * Send to group user U j cer * For users outside the group U * Public key certificate; group user U j Received from external user U within the specified time * The sent triple (r, proof, cer) * ), calculate the hash value proof′←H(tsk,r), and verify whether proof=proof′; specifically including:

[0027] 1) User U from outside the group * Randomly select a random number r, and repeatedly calculate the hash value proof = H(tsk, r) until the first σ bits of the calculated result proof are all 0. Then, combine the triples (r, proof, cer) * Send to group user U j ;

[0028] 2) When group user U j Received from external user U * The sent triple (r, proof, cer) * After that, it will record the current local timestamp. First check if it meets the requirements. If this condition is not met, it indicates that user U is outside the group. *The triple (r, proof, cer) was not sent within the specified time △T. * If the group user U j The subsequent operations will not proceed; next, the session key tsk of both parties and the received random number r are read from local memory, and the group user U... j Calculate the hash value proof′←H(tsk,r). If the returned proof = proof′ within a given time, and the first σ bits of the received hash value proof are all 0, then consider the user U outside the group to be a valid user. * The user's computing power meets the requirements for joining the group; otherwise, the user's request to join is rejected. * Join the group.

[0029] This invention employs one-pass HMQV two-party key negotiation technology and proof-of-work to implement resource authentication. By using one-way two-party key negotiation technology instead of signature technology, it avoids forcing users outside the group to sign a message. Users outside the group only use the two-party session keys to hash random numbers, preventing the leakage of any potential private information about them and thus improving system security. Attached Figure Description

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

[0031] The invention will now be described in detail with reference to the accompanying drawings.

[0032] See Figure 1 A resource authentication method based on one-way two-party key negotiation and proof-of-work includes the following entities: a trusted third party (TA), a blockchain, a server, and system users. The server is only responsible for message forwarding. System users can be divided into out-of-group users and group users according to their identities. Out-of-group users refer to users who wish to join the group, and group users refer to users who have already joined the group. Each system user holds a pair of public and private keys and a certificate associated with the public key. The trusted third party (TA) is responsible for generating system parameters and the public key certificate of each system user. The blockchain refers to a public blockchain that stores the public information of each group user, such as public key PK. i Etc.; group Gp consists of n group users U i Composed of a group, where i∈[1,n], where users in the group share a group session key gsk, and a secure communication channel is established through the session key gsk; if a user holds a public-private key pair (pk * ,sk * User U outside the group * I want to join group Gp, where g is a cyclic group of order q. The generator is generated. Specifically, the following steps are included:

[0033] (1) System Settings

[0034] 1) During system settings, the difficulty value of the puzzle used in the generation method is specified, i.e., the number of 0 bits required. The amount of work required to solve the puzzle is exponentially related to the difficulty value; the difficulty value is used to control the computation time; a time threshold is used to determine the credibility of the message; a hash function is used to perform the computation; specifically as follows:

[0035] • σ is chosen as the difficulty value for the proof-of-work algorithm;

[0036] • Select △T as the threshold for message round-trip time;

[0037] • Select H(*) As a hash function.

[0038] 2) Trusted Third Party (TA) Key Selection Derivation Function Example KDF:{0,1} * →{0,1} lena , where lena is the output length of the key derivation function; KDF maps inputs of arbitrary length to a random string of lena bits.

[0039] 3) Trusted third party TA will Distributed to users outside the group U * and group users {U1,U2,...,U n}

[0040] (2) Derived shared symmetric key

[0041] 1) Each group user U i For i∈[1,n], a shared symmetric key mk=KDF(gsk) is derived using the group session key gsk. The public parameter K=g is calculated and published to generate the two-party session key. mk .

[0042] (3) Group user consensus

[0043] 1) All group users select a group user U using a consensus mechanism that employs Proof-of-Work, Proof-of-Stake, Delegated Proof-of-Stake, Authorization Proof-of-Authorization, or Proof-of-Weight. j ∈Gp, responsible for verifying user U outside the group * The computing power.

[0044] (4) Generate session keys for both parties

[0045] 1) Group user U j Random selection in Given a finite field of order p, compute the public parameter X = g used to generate the two-party session key.x Send X to user U outside the group * Save the current local timestamp

[0046] 2) Group user U j Use one-pass HMQV to negotiate and generate a two-party session key tsk; and These represent group user U. j and external users U * identity, This indicates that the group includes user U. j and users outside the group U * Messages from the identity of group user U j Calculate hash value Group user U j Use the shared symmetric key mk to access the message. Perform a signature operation to generate a signature. pk * User U from outside the group * The public key; the session key between the two parties. The length of the output of the hash function H is equal to the length of the required key.

[0047] 3) External user U * Upon receiving the public parameter X used to generate the two-party session key, verify whether X ≠ 0; if the verification is successful, the external user U... * Generate two-party session keys using one-pass HMQV two-party key negotiation. in

[0048] (5) Verify the computing power of users outside the group

[0049] 1) User U from outside the group * Randomly select a random number r, and repeatedly calculate the hash value proof = H(tsk, r) until the first σ bits of the calculated result proof are all 0. Then, combine the triples (r, proof, cer) * Send to group user U j .

[0050] 2) When group user U j Received from external user U * The sent triple (r, proof, cer) * After that, it will record the current local timestamp. First check if it meets the requirements. If this condition is not met, it indicates that user U is outside the group.* The triple (r, proof, cer) was not sent within the specified time △T. * If the group user U j The subsequent operations will not proceed; next, the session key tsk of both parties and the received random number r are read from local memory, and the group user U... j Calculate the hash value proof′←H(tsk,r). If the returned proof = proof′ within a given time, and the first σ bits of the received hash value proof are all 0, then consider the user U outside the group to be a valid user. * The user's computing power meets the requirements for joining the group; otherwise, the user's request to join is rejected. * Join the group.

Claims

1. A resource authentication method based on one-way two-party key negotiation and proof-of-work, comprising the following entities: a trusted third party (TA), a blockchain, a server, and system users; the server is only responsible for message forwarding; system users can be divided into users outside the group and users within the group according to their identities, users outside the group refer to users who want to join the group, and users within the group refer to users who have already joined the group, and each system user holds a pair of public and private keys; A trusted third party (TA) is responsible for generating system parameters and public key certificates for each system user. Blockchain refers to a public blockchain that stores public information for each group of users, including public key PK (player kill) records. i ; Group Gp consists of n group users U i The group consists of a group session key gsk, where i∈[1,n], and the group users share a group session key gsk to establish a secure communication channel. If someone holds a public-private key pair (pk) * ,sk * User U outside the group * I want to join group Gp, where g is a cyclic group of order q. The generator; characterized in that the resource authentication method includes the following steps: Step 1: System Settings A trusted third party (TA) generates and distributes system parameters (params) for the entire system. These parameters include the difficulty value σ of the proof-of-work algorithm, the message round-trip time threshold ΔT, and the hash function H(*). Key Derivation Function (KDF), i.e. Specifically, it includes: 1) In system settings, the difficulty value is used to control the computation time; a time threshold is used to determine the credibility of a message; and a hash function is used to perform the computation; specifically as follows: • σ is chosen as the difficulty value for the proof-of-work algorithm; • Select ΔT as the threshold for message round-trip time; • Select H(*) As a hash function; 2) Trusted Third Party (TA) Key Selection Derivation Function Example KDF:{0,1} * →{0,1} lena , where lena is the output length of the key derivation function; KDF maps an input of arbitrary length to a random string of lena bits; 3) Trusted third party TA will Distributed to users outside the group U * and group users {U1, U2, ..., U} n }; Step 2: Derivation of shared symmetric key Each group user U i For i∈[1,n], a shared symmetric key mk=KDF(gsk) is derived using the group session key gsk. The public parameter K=g is calculated and published to generate the two-party session key. mk ; Step 3: Group User Consensus All group users elect a group user U using a consensus mechanism that employs Proof-of-Work, Proof-of-Stake, Delegated Proof-of-Stake, Authorization Proof-of-Stake, or Proof-of-Weight. j ∈Gp, responsible for verifying user U outside the group * Computing power; Step 4: Generate session keys for both parties Group user U j User U from outside the group * Generate a two-party session key tsk using one-pass HMQV two-party key negotiation; specifically including: 1) Group user U j Random selection in Given a finite field of order p, compute the public parameter X = g used to generate the two-party session key. x Send X to user U outside the group * Save the current local timestamp 2) Group user U j Use one-pass HMQV to negotiate and generate a two-party session key tsk; and These represent group user U. j and external users U * identity, Indicates that it includes group user U j and external users U * Messages from the identity of group user U j Calculate hash value Group user U j Use the shared symmetric key mk to access the message. Perform a signature operation to generate a signature. pk * User U from outside the group * The public key; the session key between the two parties. The length of the output of the hash function H is equal to the length of the required key; 3) External user U * Upon receiving the public parameter X used to generate the two-party session key, verify whether X ≠ 0; if the verification is successful, the external user U... * Generate two-party session keys using one-pass HMQV two-party key negotiation. in Step 5: Verify the computing power of users outside the group User U from outside the group * Randomly select a random number r, and repeatedly calculate the hash value proof = H(tsk, r) until the first σ bits of the calculated result proof are all 0. Then, combine the triples (r, proof, cer) * Send to group user U j cer * For users outside the group U * Public key certificate; group user U j Received from external user U within the specified time * The sent triple (r, proof, cer) * ), calculate the hash value proof′←H(tsk, r), and verify whether proof = proof′; specifically including: 1) User U from outside the group * Randomly select a random number r, and repeatedly calculate the hash value proof = H(tsk, r) until the first σ bits of the calculated result proof are all 0. Then, combine the triples (r, proof, cer) * Send to group user U j ; 2) When group user U j Received from external user U * The sent triple (r, proof, cer) * After that, it will record the current local timestamp. First check if it meets the requirements. If this condition is not met, it indicates that user U is outside the group. * The triple (r, proof, cer) was not sent within the specified time ΔT. * If the group user U j The subsequent operations will not proceed; next, the session key tsk of both parties and the received random number r are read from local memory, and the group user U... j Calculate the hash value proof′←H(tsk, r). If the returned proof = proof′ within a given time, and the first σ bits of the received hash value proof are all 0, then consider the user U outside the group to be a valid user. * The user's computing power meets the requirements for joining the group; otherwise, the user's request to join is rejected. * Join the group.

Images