Identity authentication method of alliance chain under identity-based strong permission control mode

Abstract

The application discloses an identity authentication mode of a consortium chain in a strong permission control mode based on identification, calculates a user public key from a user identification and a set of public mathematical parameters by using an elliptic curve bilinear pair theory, the user public key comprises a user identification and a version number of the user on the consortium chain, wherein the user identification is used for identity authentication, and the version number is used for key update; and a user private key corresponding to the user public key is calculated from the user identification, the set of public mathematical parameters and a secret value in a domain range, and is uniformly generated by a key generation center and downloaded to the user. The application adopts the above identity authentication mode, does not need the participation of a trusted third party, effectively resists attacks of intermediaries, does not need to bind identity information and a public key by using a digital certificate, reduces the bandwidth occupied by the transmission of a certificate in an identity authentication process, improves identity authentication efficiency, and solves the problem of IBC key update.

Description

Technical Field

[0001] This invention relates to the field of identity authentication technology, and in particular to a consortium blockchain identity authentication method under a strong permission control model based on identifiers. Background Technology

[0002] Consortium blockchains are a relatively new way to apply blockchain technology to enterprises. In scenarios with strong access control, consortium blockchains primarily belong to banks, insurance companies, securities firms, business associations, large corporations, and their upstream and downstream partners. These enterprises are generally already IT- and internet-based, and blockchain can greatly help improve the efficiency of notarization, settlement and clearing operations, and value exchange networks within these industry chains.

[0003] A consortium blockchain is a type of blockchain that requires identity authentication. Only authenticated nodes or organizations can participate in transactions within the consortium blockchain network. Existing identity authentication typically employs the traditional Public Key Infrastructure (PKI) authentication mechanism, introducing a trusted third-party Certificate Authority (CA) responsible for managing the digital certificates of all users under the PKI structure. By storing each user's identity and their corresponding public key information, the user's public key and identity information are bound together. However, the use of digital certificates increases the complexity for users and incurs significant resource overhead.

[0004] In scenarios involving massive numbers of terminal devices requiring authentication and trust, PKI authentication mechanisms are unsuitable. If the network receives more terminal requests than its resource processing capacity can exceed its capabilities, network service issues can easily arise. In such cases, maintaining user public keys and identity relationships becomes extremely difficult for third-party services. Frequent public key searches can degrade the capabilities of trusted third-party services and even expose them to Denial-of-Service (DoS) attacks. Furthermore, trusted third parties themselves require exceptional computing and network communication capabilities to handle such a large volume of user service requests.

[0005] Shamir first proposed Identity-Based Cryptograph (IBC), in which each entity has a meaningful and unique identifier as a public key. This eliminates the need for digital certificates to bind identity information to the public key, avoiding the complex certificate management challenges of PKI. It offers several significant advantages: certificate-free, identity-based cryptography, and ease of key use and management. It ensures strong signature security while meeting the more flexible security needs of various applications. However, the maintenance process between the public key and identity in IBC cryptography is complex, and the large bandwidth consumed during certificate transmission during authentication leads to slow authentication efficiency. Furthermore, the IBC key update problem remains unresolved. Summary of the Invention

[0006] The purpose of this invention is to provide a consortium blockchain identity authentication method under a strong permission control mode based on identifiers, which does not require the participation of a trusted third party and effectively resists man-in-the-middle attacks; it does not require digital certificates to bind identity information and public keys, reducing the bandwidth occupied by certificate transmission during identity authentication and improving identity authentication efficiency; it also solves the problem of IBC key updates.

[0007] To achieve the above objectives, this invention provides a consortium blockchain identity authentication method under a strong permission control mode based on identifiers. Utilizing elliptic curve bilinear pairing theory, a user public key is calculated from a user identifier and a set of publicly available mathematical parameters. The user public key includes the user's identifier and version number on the consortium blockchain, where the user identifier is used for identity authentication and the version number is used for key updates. The user private key, corresponding to the user public key, is calculated from the user identifier, a set of publicly available mathematical parameters, and a secret value within a domain range, and is uniformly generated by a key generation center and downloaded to the user.

[0008] Preferably, the secret value within the domain range is a random number used to generate the user's private key.

[0009] Preferably, the key generation steps are as follows:

[0010] a. Initialize the key generation center;

[0011] b. Receive key registration request;

[0012] c. Parse the request parameters;

[0013] d. User identity verification;

[0014] e. Generation of user public and private keys;

[0015] f. Encapsulate the master public key into the user public key;

[0016] g. Returns the user's public and private keys.

[0017] Preferably, the key update includes the following steps:

[0018] (1) When a user actively requests a key update due to key leakage, the key update only updates the version number. The updated version number is the original version number +1. The specific steps are as follows: After receiving the key update request from the node, the key generation center verifies the identity of the requester and checks whether it exists in the revocation map. If it does not exist, the user identifier is stored in the revocation map and the value is set to 1. If it exists, the value corresponding to the user identifier is incremented by 1, and the key corresponding to the newly generated user identifier is sent to the user.

[0019] (2) When a node communicates, the sender initiates a query request to the key generation center to find the recipient's user identifier. The key generation center queries whether the recipient's user identifier is in the revocation map. If it exists, the key generation center returns the latest version number to the sender. The sender concatenates the latest version number with the recipient's user identifier to obtain the recipient's latest public key. If it does not exist, the initial version number 1 is returned.

[0020] Preferably, the identity authentication includes the following steps:

[0021] S1. Generate Chain Configuration File: The configuration file defines the names of resources on the chain and the permissions required to access those resources;

[0022] S2. Key generation center initialization: Generate master key pair and write the master public key into the chain configuration file;

[0023] S3. User Registration: The user initiates a registration request to the key generation center, and the key generation center returns the user's key pair;

[0024] S4. Chain service initialization: The master public key and resource permissions are parsed through the configuration file and the chain service is initialized.

[0025] S5. Transaction Generation: The sender initiates a query request to the key generation center to find the recipient's user identifier. The key generation center checks whether the recipient's user identifier is in the revocation map. If it exists, the key generation center returns the latest version number to the sender. The sender concatenates the latest version number with the recipient's user identifier to obtain the recipient's latest public key. The sender uses the recipient's public key to encrypt the message and uses its own signing private key to sign it to generate a transaction, which is then sent to the consortium blockchain.

[0026] S6. Verify the user's public key: The consensus node of the consortium blockchain retrieves the user's public key from the transaction and verifies whether the main public key encapsulated in the user's public key is consistent with the main public key on the chain. If they are inconsistent, it proves that the user's public key is not trusted and the transaction is rejected. If they are consistent, signature verification is performed.

[0027] S7. Signature Verification: The consortium blockchain consensus node uses the user's signature public key to verify whether the signature is correct. If it is incorrect, the transaction is rejected.

[0028] S8. Permission Location: The consensus node of the consortium blockchain retrieves the name of the resource accessed in the transaction and looks up the corresponding permission definition on the chain;

[0029] S9. Permission Verification: The consortium blockchain consensus node retrieves the user's identity and permissions based on the user identifier in the transaction and determines whether the user's permissions are consistent with the permissions corresponding to the accessed resources.

[0030] S10. Consensus: Consensus nodes reach a consensus on transactions according to the corresponding consensus algorithm. If a consensus is reached, the transaction will be recorded on the blockchain.

[0031] The advantages and positive effects of the identity authentication method for consortium blockchains under the identifier-based strong access control mode described in this invention are:

[0032] 1. In this invention, the public key is uniquely determined by the identity identifier, eliminating the need for a trusted third party (CA) to bind the user's identity and public key. This simplifies the process of maintaining the relationship between the public key and the identity. Furthermore, since the user's identity information on the blockchain is the public key, if an attacker replaces the public key received by the target victim, the victim can directly observe whether the received public key has been replaced, thus avoiding message leakage caused by man-in-the-middle attacks.

[0033] 2. In this invention, there is no need to bind identity information to the public key with a digital certificate. During the identity authentication process, only the public key can be transmitted, and the identity information required by the user can be extracted from the public key. This reduces the bandwidth occupied by transmitting the certificate during the identity authentication process and improves the efficiency of identity authentication.

[0034] 3. In this invention, a trusted third party, the key generation center, is used to distribute and manage private keys. A version number is appended to the user identifier, and a revocation map is maintained in the key generation center. The key value is the user identifier, and the value is the version number. When nodes communicate, the user identifier of the receiver is checked to see if it is in the revocation map. If it exists, the key has been updated, and the updated version number is returned to the message sender. The sender can use the returned version number to construct the receiver's new public key, thus solving the IBC key update problem.

[0035] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0036] Figure 1 This is an overall structural diagram of an embodiment of the consortium blockchain identity authentication method under the identifier-based strong permission control mode of the present invention;

[0037] Figure 2 This is a flowchart illustrating the user key generation process of an embodiment of the consortium blockchain identity authentication method under a strong permission control mode based on the identifier of the present invention.

[0038] Figure 3 This is a flowchart illustrating the key update process of a consortium blockchain identity authentication method under a strong permission control mode based on the identifier, as described in this invention. Detailed Implementation

[0039] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0040] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0041] Example

[0042] The identifier-based strong-access control model for consortium blockchain authentication is a public-key cryptography technique based on IBC cryptography. Utilizing elliptic curve bilinear pairing theory, a user public key is calculated from a user identifier and a set of publicly available mathematical parameters. The user public key includes the user's identifier and version number on the consortium blockchain, where the user identifier is used for authentication and the version number is used for key updates. The corresponding user private key is calculated from the user identifier, a set of publicly available mathematical parameters, and a secret value within a specific domain. This private key is uniformly generated by a key generation center and downloaded to users. The secret value within a specific domain includes parameters such as the system private key. The overall structural diagram of this invention is shown below. Figure 1 As shown.

[0043] The flowchart for user key generation is as follows: Figure 2 As shown, the specific steps for generating the user key are as follows:

[0044] a. Initialize the key generation center;

[0045] b. Receive key registration request;

[0046] c. Parse the request parameters;

[0047] d. User identity verification;

[0048] e. Generation of user public and private keys;

[0049] f. Encapsulate the master public key into the user public key;

[0050] g. Returns the user's public and private keys.

[0051] The user key update flowchart is as follows: Figure 3 As shown, the key update specifically includes the following steps:

[0052] (1) When a user actively requests a key update due to key leakage, the key update only updates the version number. The updated version number is the original version number +1. The specific steps are as follows: After receiving the key update request from the node, the key generation center verifies the identity of the requester and checks whether it exists in the revocation map. If it does not exist, the user identifier is stored in the revocation map and the value is set to 1. If it exists, the value corresponding to the user identifier is incremented by 1, and the key corresponding to the newly generated user identifier is sent to the user.

[0053] (2) When a node communicates, the sender initiates a query request to the key generation center to find the recipient's user identifier. The key generation center queries whether the recipient's user identifier is in the revocation map. If it exists, the key generation center returns the latest version number to the sender. The sender concatenates the latest version number with the recipient's user identifier to obtain the recipient's latest public key. If it does not exist, the initial version number 1 is returned.

[0054] Identity verification includes the following steps:

[0055] S1. Generate Chain Configuration File: The configuration file defines the names of resources on the chain and the permissions required to access those resources;

[0056] S2. Key generation center initialization: Generate master key pair and write the master public key into the chain configuration file;

[0057] S3. User Registration: The user initiates a registration request to the key generation center, and the key generation center returns the user's key pair;

[0058] S4. Chain service initialization: The master public key and resource permissions are parsed through the configuration file and the chain service is initialized.

[0059] S5. Transaction Generation: The sender initiates a query request to the key generation center to find the recipient's user identifier. The key generation center checks whether the recipient's user identifier is in the revocation map. If it exists, the key generation center returns the latest version number to the sender. The sender concatenates the latest version number with the recipient's user identifier to obtain the recipient's latest public key. The sender uses the recipient's public key to encrypt the message and uses its own signing private key to sign it to generate a transaction, which is then sent to the consortium blockchain.

[0060] S6. Verify the user's public key: The consensus node of the consortium blockchain retrieves the user's public key from the transaction and verifies whether the main public key encapsulated in the user's public key is consistent with the main public key on the chain. If they are inconsistent, it proves that the user's public key is not trusted and the transaction is rejected. If they are consistent, signature verification is performed.

[0061] S7. Signature Verification: The consortium blockchain consensus node uses the user's signature public key to verify whether the signature is correct. If it is incorrect, the transaction is rejected.

[0062] S8. Permission Location: The consensus node of the consortium blockchain retrieves the name of the resource accessed in the transaction and looks up the corresponding permission definition on the chain;

[0063] S9. Permission Verification: The consortium blockchain consensus node retrieves the user's identity and permissions based on the user identifier in the transaction and determines whether the user's permissions are consistent with the permissions corresponding to the accessed resources.

[0064] S10. Consensus: Consensus nodes reach a consensus on transactions according to the corresponding consensus algorithm. If a consensus is reached, the transaction will be recorded on the blockchain.

[0065] Therefore, this invention adopts the aforementioned consortium blockchain identity authentication method under the identifier-based strong permission control mode. It does not require the participation of a trusted third party. During a transaction, the consortium blockchain consensus node retrieves the user's public key from the transaction and verifies whether the master public key encapsulated in the user's public key matches the on-chain master public key. If they do not match, it proves that the user's public key is not trusted and the transaction is rejected. If they match, signature verification is performed. The consortium blockchain consensus node uses the user's signing public key to verify whether the signature is correct. If it is incorrect, the transaction is rejected. Thus, the recipient can verify the source and correctness of the message, effectively resisting man-in-the-middle attacks. It eliminates the need for digital certificates to bind identity information and public keys, reducing the bandwidth occupied by certificate transmission during identity authentication and improving authentication efficiency. It also solves the problem of IBC key updates.

[0066] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A consortium blockchain identity authentication method based on identifier-based strong access control, characterized by: Using the theory of bilinear pairing of elliptic curves, the user's public key is calculated from the user identifier and mathematical parameters. The user's public key includes the user's identifier and version number on the consortium blockchain. The user identifier is used for identity authentication, and the version number is used for key updates. The user's private key, which corresponds to the user's public key, is calculated from the user identifier, mathematical parameters, and secret value. It is generated and downloaded to the user by the key generation center. The key update includes the following steps: 1) When a user actively requests a key update, the key update only updates the version number. The updated version number is the original version number + 1. The specific steps are as follows: After the key generation center receives the key update request from the node, it verifies the identity of the requester and checks whether it exists in the revocation map. If it does not exist, the user identifier is stored in the revocation map and the value is set to 1. If it exists, increment the value corresponding to the user identifier by 1, and send the key corresponding to the newly generated user identifier to the user; 2) When nodes communicate, the sender initiates a query request to the key generation center to find the recipient's user identifier. The key generation center checks whether the recipient's user identifier is in the revocation map. If it exists, the key generation center returns the latest version number to the sender. The sender concatenates the latest version number with the recipient's user identifier to obtain the recipient's latest public key. If it does not exist, the initial version number 1 is returned. The identity authentication includes the following steps: S1. Generate Chain Configuration File: The configuration file defines the names of resources on the chain and the permissions required to access those resources; S2. Key generation center initialization: Generate master key pair and write the master public key into the chain configuration file; S3. User Registration: The user initiates a registration request to the key generation center, and the key generation center returns the user's key pair; S4. Chain service initialization: The master public key and resource permissions are parsed through the configuration file and the chain service is initialized. S5. Transaction Generation: The sender initiates a query request to the key generation center to find the recipient's user identifier. The key generation center checks whether the recipient's user identifier is in the revocation map. If it exists, the key generation center returns the latest version number to the sender. The sender concatenates the latest version number with the recipient's user identifier to obtain the recipient's latest public key. The sender uses the recipient's public key to encrypt the message and uses its own signing private key to sign it to generate a transaction, which is then sent to the consortium blockchain. S6. Verify the user's public key: The consensus node of the consortium blockchain retrieves the user's public key from the transaction and verifies whether the main public key encapsulated in the user's public key is consistent with the main public key on the chain. If they are inconsistent, it proves that the user's public key is not trusted and the transaction is rejected. If they are consistent, signature verification is performed. S7. Signature Verification: The consortium blockchain consensus node uses the user's signature public key to verify whether the signature is correct. If it is incorrect, the transaction is rejected. S8. Permission Location: The consensus node of the consortium blockchain retrieves the name of the resource accessed in the transaction and looks up the corresponding permission definition on the chain; S9. Permission Verification: The consortium blockchain consensus node retrieves the user's identity and permissions based on the user identifier in the transaction and determines whether the user's permissions are consistent with the permissions corresponding to the accessed resources. S10. Consensus: Consensus nodes reach a consensus on transactions according to the corresponding consensus algorithm. If a consensus is reached, the transaction will be recorded on the blockchain. The key generation center is used to distribute and manage private keys. A version number is appended to the user identifier. The key generation center maintains a revocation map, where the key is the user identifier and the value is the version number. When nodes communicate, they verify whether the recipient's user identifier is in the revocation map. If it exists, the key has been updated, and the updated version number is returned to the message sender. The sender can then use the returned version number to construct the recipient's new public key.

2. The consortium blockchain identity authentication method under the identifier-based strong access control mode according to claim 1, characterized in that: The secret value is a random number used to generate the user's private key.

3. The consortium blockchain identity authentication method under the identifier-based strong access control mode according to claim 1, characterized in that, The key generation steps are as follows: a. Initialize the key generation center; b. Receive key registration request; c. Parse the request parameters; d. User identity verification; e. Generation of user public and private keys; f. Encapsulate the master public key into the user public key; g. Returns the user's public and private keys.

Images