Identity registration method, storage medium and program product

Abstract

The invention relates to the technical field of computers, and provides an identity registration method, a storage medium and a program product. And the target registration server receives a registration request from the terminal equipment, wherein the registration request is used for requesting identity registration of the target user. And the target registration server performs identity registration on the target user under the condition that the target user is in a non-registration state under each registration server, generates a user credential and sends the user credential to the terminal equipment. According to the identity registration method provided by the invention, the global uniqueness constraint of the user identity can be realized.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an identity registration method, storage medium, and program product. Background Technology

[0002] With the widespread adoption of internet services, cross-domain identity authentication and management has become a core component of cybersecurity infrastructure. Its core objective is to achieve efficient identity verification and access control between different services while ensuring user privacy and data security.

[0003] In the traditional federated identity management (FIM) model, the same natural person can register independent accounts with multiple identity providers (IdPs). The system cannot identify and associate these accounts with the same entity, resulting in the problem of "multiple identities" and making it difficult to meet the regulatory requirements for real-name uniqueness in different scenarios. Summary of the Invention

[0004] This application provides an identity registration method to solve the technical problem of multiple identities caused by the same natural person being able to register independent accounts at multiple IdPs.

[0005] Firstly, embodiments of this application provide an identity registration method applied to a target registration server. Specifically, the target registration server receives a registration request from a terminal device, which requests identity registration for a target user. When the target user is in an unregistered state under each registration server, the target registration server registers the target user's identity, generates user credentials, and sends the user credentials to the terminal device.

[0006] In one embodiment, the registration request may include the target user's user identifier. If the target user is unregistered on each registration server, before registering the target user's identity, the target registration server may also determine the target user's registration status on each registration server based on the target user's user identifier using a blockchain.

[0007] In one embodiment, if the target user's identity registration information does not exist in the blockchain, or if the target user's identity registration information in the blockchain has been revoked, it indicates that the target user is in an unregistered state under each registration server.

[0008] In one embodiment, the blockchain may store the target user's identity registration information under the target registration server. The target registration server may also receive registration revocation requests from terminal devices, which request the revocation of the target user's identity registration information under the target registration server. The target registration server may generate a revocation instruction, which includes the target user's user identifier and the target registration server's server identifier. The target registration server may send the revocation instruction to the nodes of the blockchain, causing the nodes to revoke the target user's identity registration information under the target registration server in the blockchain.

[0009] Secondly, embodiments of this application provide an identity registration method applied to a terminal device. Specifically, the terminal device sends a registration request to a target registration server. The registration request requests the registration of a target user's identity, enabling the target registration server to register the target user's identity and generate user credentials even when the target user is unregistered under each registration server. The terminal device receives and stores the user credentials.

[0010] In one embodiment, the terminal device may also encrypt the user credentials before storing them.

[0011] In one embodiment, encrypting the user credentials may specifically include: generating a high-entropy random number, obtaining a user password, generating an encryption key based on the high-entropy random number and the user password, and encrypting the user credentials using the encryption key.

[0012] In one embodiment, the terminal device can also send a target service access request to the verification server and receive an authentication request from the verification server. The terminal device can verify the identity of the target user through the target registration server and generate an authentication token based on the verification result. The authentication token is used to authenticate the target user. Then, the terminal device can send the authentication token to the verification server, so that the verification server, after successfully authenticating the target user based on the authentication token, provides the target service to the terminal device.

[0013] In one embodiment, the above-mentioned verification of the target user's identity through the target registration server may specifically include: randomizing and blinding the user credentials, sending an authentication request to the target registration server, the authentication request containing the blinded user credentials, so that the target registration server can verify the target user's identity based on the blinded user credentials.

[0014] In one embodiment, before generating an authentication token based on the verification result, the terminal device can also verify the authenticity of the verification result.

[0015] Thirdly, embodiments of this application provide an identity registration device located on a target registration server, the device comprising: The receiving module is used to receive registration requests from terminal devices. The registration request is used to request the target user to register their identity.

[0016] The registration module registers the target user's identity and generates user credentials when the target user is in an unregistered state under each registration server.

[0017] The sending module is used to send user credentials to the terminal device.

[0018] Fourthly, embodiments of this application provide an identity registration device located in a terminal device, the device comprising: The sending module is used to send a registration request to the target registration server. The registration request is used to request the target user to register their identity, so that the target registration server can register the target user's identity and generate user credentials even if the target user is in an unregistered state under each registration server.

[0019] The receiving module is used to receive and store user credentials.

[0020] Fifthly, embodiments of this application provide a registration server, including a memory, a transceiver, and a processor; A memory for storing computer programs; a transceiver for sending and receiving data under the control of the processor; and a processor for reading the computer programs from the memory and performing the following operations: The system receives a registration request from a terminal device, which requests the registration of the target user. If the target user is unregistered under each registration server, the system registers the target user, generates user credentials, and sends the user credentials to the terminal device.

[0021] Sixthly, embodiments of this application provide a terminal device, including a memory, a transceiver, and a processor; A memory for storing computer programs; a transceiver for sending and receiving data under the control of the processor; and a processor for reading the computer programs from the memory and performing the following operations: A registration request is sent to the target registration server. This request is used to request the target user to register their identity, so that the target registration server can register the target user even if the target user is in an unregistered state under each registration server, and generate user credentials. The user credentials are then received and stored.

[0022] In a seventh aspect, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the identity registration method described in the first or second aspect.

[0023] Eighthly, embodiments of this application provide a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the identity registration method described in the first or second aspect.

[0024] In a ninth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the identity registration method described in the first or second aspect.

[0025] The identity registration method provided in this application verifies that the target user is in an unregistered state under all registration servers before registration, thereby preventing the same user from registering repeatedly with multiple identity providers from the source and achieving a global uniqueness constraint on user identity. This not only solves the pain point of "multiple identities" caused by the fragmentation of multiple IdP data in the traditional FIM mode, but also allows users to achieve convenient access and unified management with globally unique user credentials, reducing the cost of user identity management. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a system architecture diagram of an identity registration system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the interaction flow of an identity registration method provided in an embodiment of this application; Figure 3 This is a schematic diagram of an interaction process for accessing a target service provided in an embodiment of this application; Figure 4 This is a schematic diagram of an interactive process for revoking identity registration information provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an identity registration device provided in an embodiment of this application; Figure 6 This is a schematic diagram of another identity registration device provided in an embodiment of this application; Figure 7This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0029] In the description of this invention, it should be understood that the terms "center," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," and "third" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0030] With the widespread adoption of internet services, cross-domain identity authentication and management has become a core component of cybersecurity infrastructure. Its core objective is to achieve efficient identity verification and access control between different services while ensuring user privacy and data security. Currently, mainstream identity authentication technologies can be divided into two main categories: traditional FIM (Fixed Identity Authentication) and emerging decentralized identifiers (DIDs).

[0031] In traditional FIM (Firmware Integrity Management) systems, typical solutions include implementations based on the Security Assertion Markup Language (SAML) protocol and the Open ID Connect (OIDC) protocol. The core logic is as follows: users register and store their identity credentials at a trusted IdP (Intelligence Depositor). When a user accesses a third-party service (SP), the SP redirects the user's request to the corresponding IdP for authentication. Upon successful authentication, the IdP issues an identity token containing user attributes and a digital signature to the SP, which then uses this token to verify the user's identity. This model, through a single sign-on (SSO) mechanism, enables users to conveniently access multiple application services with a single set of credentials, and is widely used in enterprise applications and internet services.

[0032] To address the risks of single point of failure, data monopoly, and user privacy breaches inherent in the centralized IdP model of traditional FIM (Fixed Integrity Management) systems, self-sovereign identity (SSI) schemes based on blockchain and distributed ledger technologies have gradually become a research hotspot. Under the SSI architecture, users achieve self-management of their identity by generating decentralized identifiers and asymmetric key pairs. Identity attributes are issued by the IdP in the form of verifiable credentials (VCs) and stored autonomously by users through digital wallets and other terminals. The blockchain, as the trusted underlying layer, only stores DID documents and VC revocation status; verifiers do not need to rely on a specific centralized server to verify the authenticity and validity of a user's identity through on-chain data. Some schemes further introduce a consortium blockchain architecture, where multiple institutions act as consensus nodes to jointly maintain the identity ledger, thereby improving the efficiency of cross-domain trust transfer.

[0033] Currently, significant shortcomings still exist in complex scenarios where multiple identity providers coexist and strict guarantees of identity uniqueness and data transfer security are required. These shortcomings are as follows: The lack of effective constraints on cross-IdP identity uniqueness: In the traditional FIM model, the data systems of different IdPs are fragmented, allowing the same individual to register independent accounts at multiple IdPs. The system cannot identify and associate these accounts with the same entity, leading to the problem of "multiple identities" and failing to meet the regulatory requirements for real-name uniqueness in different scenarios. While standard SSI or DID models encourage users to generate multiple DIDs to ensure anonymity and privacy, they lack an inherent mechanism for enforcing identity uniqueness and are similarly unsuitable for business scenarios requiring explicit identity constraints.

[0034] Therefore, how to achieve global uniqueness constraints on user identity in an environment where multiple identity providers coexist is an urgent problem to be solved.

[0035] To address the aforementioned technical issues, this application provides an identity registration method. A terminal device can send a registration request to a target registration server, requesting the registration of a target user. Upon receiving the registration request, the target registration server can register the target user and generate user credentials even if the target user is unregistered on each registration server. Subsequently, the target registration server can send the user credentials to the terminal device, which can then receive and store them.

[0036] The identity registration method in this application verifies that the target user is in an unregistered state under all registration servers before registration, thereby preventing the same user from registering repeatedly with multiple identity providers from the source. This achieves a global uniqueness constraint on user identity, which not only solves the pain points of "multiple identities" caused by the fragmentation of multiple IdP data in the traditional FIM mode and the lack of a mandatory identity uniqueness mechanism in the standard SSI / DID mode, but also allows users to achieve convenient access and unified management with globally unique user credentials, reducing the cost of user identity management.

[0037] The following is combined Figures 1-7 The identity registration method provided in the embodiments of this application will be described in detail.

[0038] Figure 1 A system architecture diagram of an identity registration system provided in this application embodiment is shown below. Figure 1 As shown, the identity registration system may include a terminal device 101, a registration server 102, a verification server 103, and a blockchain (or blockchain network) 104.

[0039] This application embodiment does not specify the number of terminal devices 101, registration servers 102, and verification servers 103. Figure 1 The example shown is based on the number of three terminal devices 101, registration server 102, and verification server 103.

[0040] In this embodiment, terminal device 101 can send a registration request to a registration server 102 (hereinafter referred to as the target registration server). The target registration server can register the target user's identity and generate user credentials even when the target user is in an unregistered state under each registration server. The target registration server can send the user credentials to terminal device 101, and terminal device 101 can store the user credentials.

[0041] In some embodiments, a user's identity registration information under the registration server 102 may be stored in the blockchain 104.

[0042] In some embodiments, when a user intends to access a service, they can send a service access request to the authentication server 103 through their terminal device 101.

[0043] The terminal device 101 involved in this application embodiment may be a device that provides voice and / or data connectivity to a user, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. The name of the terminal device may differ in different systems; for example, in a 5G system, the terminal device may be called User Equipment (UE).

[0044] Registration server 102 and verification server 103 can be cloud servers, also known as cloud computing servers or cloud hosts, which are host products in the cloud computing service system. Servers can also be servers in a distributed system or servers integrated with blockchain. Server 101 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or it can provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, etc.

[0045] Figure 2 This is a schematic diagram illustrating the interaction flow of an identity registration method provided in an embodiment of this application. The method is implemented through interaction between a terminal device and a target registration server. (Refer to...) Figure 2 As shown, the method includes the following steps S201-S204.

[0046] S201, the terminal device sends a registration request to the target registration server.

[0047] Correspondingly, the target registration server can receive registration requests from terminal devices.

[0048] A registration request is used to request the registration of the target user's identity.

[0049] The terminal device is the electronic device (such as a smartphone, tablet, or laptop) owned by the target user. The target registration server is a server with user identity registration capabilities, used to register user identities; therefore, the target registration server can also be called the target IdP. The target IdP can be an IdP selected by the target user based on factors such as service provider and geographic preference, or it can be the IdP closest to the location of the terminal device, or it can be an IdP corresponding to information such as the terminal device's operator and model.

[0050] Specifically, when a target user intends to register their identity on a network (such as the Internet, a local area network, or a dedicated communication network), they can trigger a registration operation through a terminal device (such as clicking a registration button or entering registration instructions). In response to the user's registration operation, the terminal device can generate a registration request based on the target user's user identifier (UID) and send this request to the target registration server. Thus, the target registration server can receive the registration request sent by the terminal device, which carries the target user's user identifier.

[0051] S202, The target registration server registers the target user's identity and generates user credentials when the target user is in an unregistered state under each registration server.

[0052] The user's identity registration information under the registration server can be stored in the blockchain. Correspondingly, if the target user is in an unregistered state under each registration server, the aforementioned target registration server can also determine the target user's registration status under each registration server based on the target user's user identifier through the blockchain before registering the target user's identity.

[0053] Specifically, if the target registration server determines that the target user is unregistered on each registration server, either because the target user's identity registration information does not exist in the blockchain, or because the target user's identity registration information in the blockchain has been revoked. In this case, the target registration server can register the target user's identity and generate user credentials.

[0054] In one example, the blockchain may include a registration list and a revocation list. The registration list records the correspondence between user identifiers and server identifiers. Each correspondence indicates that the user identifier indicates that the user has registered their identity under the target registration server indicated by the server identifier. The revocation list records the correspondence between user identifiers and server identifiers. Each correspondence indicates that the user identifier indicates that the user's identity registration information under the target registration server indicated by the server identifier has been revoked.

[0055] Accordingly, the target registration server can query the target user's user identifier in the blockchain's registration list. If the target user's user identifier is not found in the registration list, it indicates that the target user has not registered, meaning the target user is in an unregistered state under each registration server. The target registration server can then register the target user and generate user credentials.

[0056] If the registration list contains the target user's user identifier, the target registration server can obtain the server identifier (hereinafter referred to as server identifier 1) corresponding to the target user's user identifier in the registration list. Then, the target registration server can determine whether the blockchain's revocation list contains a correspondence between the target user's user identifier and server identifier 1. If the revocation list contains a correspondence between the target user's user identifier and server identifier 1, it indicates that the target user's identity registration information under the registration server indicated by server identifier 1 has been revoked, and the target registration server can register the target user's identity and generate user credentials. If the revocation list does not contain a correspondence between the target user's user identifier and server identifier 1, it indicates that the target user's identity registration information under the registration server indicated by server identifier 1 has not been revoked, that is, the target user is in a registered state under the registration server indicated by server identifier 1. The target registration server cannot register the target user's identity.

[0057] The above technical solution uses blockchain as a real-time database to store user identity registration information, and the server (such as the registration server) can directly look up the user's identity registration information in the blockchain.

[0058] The process of generating user credentials by the target registration server will be described below.

[0059] The target registration server can store its own private key. The target registration server can use its own private key and the target user's user identifier to generate user credentials.

[0060] In one example, the private key of the target registration server is used. Taking the target user's user identifier as UID as an example, the target registration server can generate user credentials using the following formula: .

[0061] (Formula 1) in, It is a random number selected by the target registration server. . These are common parameters.

[0062] S203, The target registration server sends user credentials to the terminal device.

[0063] S204, The terminal device receives and stores the user credentials.

[0064] After the target registration server generates the target user's user credentials in the above manner, it can send the target user's user credentials to the terminal device. The terminal device can store the user credentials and correspondingly store the target user's user identifier and the target registration server's server identifier.

[0065] To ensure that the user credentials of the target user are not leaked, the target registration server can use a secure channel to send the user credentials to the terminal device.

[0066] As can be seen from the above technical solution, this application combines the Keyed-Verification Credential (KVC) mechanism in cryptography with the distributed ledger characteristics of blockchain to propose a cross-domain identity authentication scheme that can guarantee global uniqueness and support privacy protection. Specifically, before registering a user's identity, the target registration server can verify that the target user is in an unregistered state under all registration servers, thereby preventing the same user from registering repeatedly with multiple identity providers from the source. This achieves a global uniqueness constraint on user identity, solving the pain points of "multiple identities" caused by the fragmentation of multiple IdP data in the traditional FIM mode and the lack of a mandatory identity uniqueness mechanism in the standard SSI / DID mode. It also allows users to achieve convenient access and unified management with globally unique user credentials, reducing the cost of user identity management.

[0067] As described above, a blockchain can include a registration list. Therefore, after the target registration server registers the identity of the target user, it can send a registration record, including the user's identifier and the server identifier of the target registration server, to the nodes of the blockchain.

[0068] In one example, the registration record may include not only the user identifier of the target user and the server identifier of the target registration server, but also the record type, such as... ,in, The record type used to identify this record is a registration record. For user identification, This serves as the server identifier. Thus, after a blockchain node receives the registration record, it can store the target user's identifier and the target registration server's identifier in the registration list.

[0069] In one alternative implementation, the target registration server may generate its own private key and public key before generating user credentials using its own private key. Continuing with the private key... For example, the target registration server can generate its own public key using the following formula (Formula 2). .

[0070] (Formula 2) To prevent the leakage of user credentials stored within them, in one optional implementation, the terminal device may encrypt the user credentials before storing them. The terminal device can then store the encrypted user credentials to prevent leakage and ensure their security.

[0071] This application does not specifically limit the method by which the terminal device encrypts user credentials.

[0072] In one example, the terminal device can generate a high-entropy random number and obtain the user's password. Then, based on the high-entropy random number and the user's password, the terminal device can generate an encryption key and use this key to encrypt the user's credentials.

[0073] User password refers to the string (or password) entered by the user.

[0074] Terminal devices can generate high-entropy random numbers using either a cryptographically secure pseudo-random number generator (CSSPRNG) or a hardware random number generator (HRNG), without any specific limitation.

[0075] Specifically, let's take the example of a terminal device generating a high-entropy random number using CSSPRNG. After obtaining the user's password, the terminal device can generate an encryption key using a preset key derivation algorithm. The terminal device can then use this encryption key and a preset encryption algorithm to encrypt the user's credentials, obtaining the encrypted user credentials.

[0076] Key derivation algorithms may include, but are not limited to, the PBKDF algorithm, the Argon2 algorithm, etc. Encryption algorithms may include, but are not limited to, symmetric encryption algorithms, asymmetric encryption algorithms, etc. This application does not specifically limit the key derivation algorithm and encryption algorithm.

[0077] For example, the key derivation algorithm is PBKDF, the encryption algorithm is a symmetric encryption algorithm, the high-entropy random number generated by the terminal device through CSSPRNG is X, the user password is pwd, and the user credentials are... For example, after the terminal device generates a high-entropy random number X and obtains the user's password pwd, it can use the PBKDF algorithm to generate an encryption key K. The generated encryption key K can be referred to as Formula 3 below. Then, the terminal device can use the encryption key K and a symmetric encryption algorithm to encrypt the user credential, obtaining the encrypted user credential [cre]. The encrypted user credential [cre] can be referred to as Formula 4 below.

[0078] (Formula 3) (Formula 4) in, Used to characterize symmetric encryption algorithms.

[0079] To prevent the leakage of high-entropy random numbers and consequently, the disclosure of user credentials, one optional implementation allows the terminal device to protect the privacy of these high-entropy random numbers. In one example, if the terminal device is running Linux, it can utilize the SystemdCredentials interface provided by Linux to store the high-entropy random numbers. In another example, if the terminal device is configured with a trusted platform module (TPM), it can store the high-entropy random numbers within the TPM.

[0080] The above technical solution not only avoids the static storage of encryption keys in plaintext or weak encryption form in the terminal device, but also utilizes operating system kernel-level access control policies to prevent the leakage of high-entropy random numbers, thus protecting them. Furthermore, the above process can be automated using specific software, significantly improving the security and feasibility of user-side key and high-entropy random number management.

[0081] When a user intends to access a certain service, they can send a service access request to the server providing the service (hereinafter referred to as the verification server) through their terminal device. The following describes the process of the verification server providing the target service to the target user, taking the target user's intention to access the target service as an example.

[0082] Figure 3 This is a schematic diagram of an interaction process for accessing a target service provided in an embodiment of this application. The method is implemented through the interaction of a terminal device, a verification server, and a target registration server. Figure 3 As shown, the method includes S301-S307.

[0083] S301, the terminal device sends a target service access request to the verification server.

[0084] As described above, an authentication server can provide services to users; therefore, an authentication server can also be a service provider (SP).

[0085] The target service access request is used to request access to the target service.

[0086] Specifically, when a target user intends to access a target service, they can trigger an access operation for the target service through a terminal device. In response to the user's access operation, the terminal device can generate a target service access request and send it to the verification server. Thus, the verification server can receive the target service access request sent by the terminal device.

[0087] S302, the verification server sends an authentication request to the terminal device.

[0088] In this way, the terminal device can receive the authentication request sent by the verification server.

[0089] After receiving a target service access request from a terminal device, the verification server generates an authentication request to ensure the legitimacy of the target user's identity, prevent malicious users from forging identities and illegally accessing the target service, and guarantee the security of service access. This request is then sent to the terminal device to authenticate the target user's identity. Thus, the terminal device can receive the authentication request from the verification server.

[0090] S303, the terminal device verifies the identity of the target user through the target registration server and obtains the verification result.

[0091] As described above, the terminal device can store user credentials encrypted using a symmetric encryption algorithm. Since the encryption and decryption keys of the symmetric encryption algorithm are the same, the terminal device can obtain the encrypted user credentials and decrypt them using the decryption key to obtain the decrypted user credentials. The terminal device can then send an authentication request to the target registration server, and this authentication request can include the user credentials. The target registration server can then verify the identity of the target user based on the user credentials.

[0092] To prevent the leakage of user credentials, in one optional implementation, the terminal device may randomize and blind the user credentials before sending an authentication request to the target registration server, resulting in blinded user credentials. Accordingly, the authentication request sent by the terminal device to the target registration server may include the blinded user credentials. The target registration server can then verify the identity of the target user based on the blinded user credentials.

[0093] In one example, continuing with the PBKDF key derivation algorithm, a symmetric encryption algorithm, a high-entropy random number X, a user password pwd, a user credential cre, and the encrypted user credential [cre], the terminal device can obtain the encrypted user credential [cre], the high-entropy random number X, and the user password pwd. The terminal device can then generate a decryption key K based on the high-entropy random number and the user password. The generated decryption key K can be referenced in Formula 3 above. Afterwards, the terminal device can use the decryption key K to decrypt the encrypted user credential [cre] using Formula 5 below, obtaining the user credential cre.

[0094] (Formula 5) Terminal devices can generate random parameters and use these random parameters to randomize and blind the user credential cre.

[0095] It is understood that user credentials can consist of multiple fields (or parameters). The randomization and blinding processing of user credentials by the terminal device can refer to blinding any field contained in the user credentials using random parameters, or it can refer to blinding multiple fields contained in the user credentials using random parameters. There is no specific limitation on this.

[0096] The random parameters generated by the terminal device can be two, three, more, or fewer parameters. Furthermore, the random parameters generated by the terminal device can include, but are not limited to, finite fields. Random numbers, random group elements, etc. This application does not specifically limit the number and type of random parameters in its embodiments.

[0097] The terminal device performs blinding processing on any field contained in the user credential using random parameters. The terminal device generates two random parameters, one of which is a random number in a finite field. random numbers on ( Another random number is the random group element R (R ← For example, the terminal device can perform structured parsing on the user credential cre to obtain the fields that make up the user credential cre. That is, the fields that make up the user credential include S w S z S x and S y Terminal equipment Take randomization and blinding as an example.

[0098] Terminal device generates random numbers After the random group element R, it can be based on the random number r' and the field The randomized field is determined using the following formula six. Then, the terminal device can use the target user's user identifier (uid) and the randomized field... The random group element R and the preset cryptographic hash function H are used to determine the parameter U using the following formula (Formula 7). The terminal device can then process the randomized field... And parameter U is encapsulated as parameter And parameters Terminal devices can be based on parameters Generate an authentication request and send it to the target registration server.

[0099] (Formula 6) (Formula 7) The target registration server receives the authentication request, can parse the authentication request, and obtain the parameters. The target registry server can be based on parameters. Verify the identity of the target user.

[0100] This application does not specifically limit the method by which the target registration server verifies the identity of the target user. For example, the target registration server can verify the identity of the target user through zero-knowledge proof, or it can verify the identity of the target user based on biometric information comparison or two-way authentication using symmetric encryption keys. The following description will focus on the method by which the target registration server verifies the identity of the target user through zero-knowledge proof.

[0101] The target registration server can store its own private key. Taking the target registration server's private key sk=(z, x0, x1, y0, y1) as an example, the target registration server can use the private key sk=(z, x0, x1, y0, y1) and parameters... The following formula generates three intermediate parameters T1, T2 and T3.

[0102] (Formula 8) Then, the target registration server can construct a linear relationship Y=M⋅w. Wherein, It is a vector, and M is a The group element matrix can be divided into two parts: the upper part is a matrix with publicly available parameters. A matrix whose diagonal elements are all 0, i.e., a group. The unit element, the blocks below are . It is a vector, and It can be understood that Y and M are public information, while w is a vector related to the private key, which belongs to private information.

[0103] The target registration server can perform zero-knowledge proof on the constructed linear relationship to obtain a proof result. This proof result verifies that the linear relationship between Y, M, and w holds true without revealing the vector w associated with the private key. The target registration server then uses the proof result and the three intermediate parameters mentioned above as the verification result and sends the verification result to the terminal device. (The proof result is used as...) For example, the target registration server is based on the proof result. The verification results obtained using the three intermediate parameters T1, T2, and T3 mentioned above can be: The target registration server can send verification results to the terminal device. .

[0104] The following section will perform a zero-knowledge proof on the target registration server regarding the linear relationship constructed above, and obtain the proof result. The process is described.

[0105] In one example, the target registry server can be selected from a limited domain. Five independent random numbers are randomly selected from the given data to construct a 5-dimensional random vector k. The target registration server can calculate the first commitment value based on the matrix M and the random vector k described above using the following formula (nine). Afterwards, the target registration server can perform a PK based on its own public key, and the randomized fields... The parameters are: U, three intermediate parameters T1, T2, and T3, and the first commitment value. The first challenge value is calculated using the cryptographic hash function H. .

[0106] (Formula Nine) The target registration server can calculate the response value s based on the random vector k, the first challenge value c, and the vector w using the following formula. The target registration server can then obtain the proof result based on the response value s and the first challenge value c. .

[0107] (Formula 10) S304, The terminal device generates an authentication token based on the verification result.

[0108] In one alternative implementation, the terminal device may also verify the authenticity of the verification result before generating an authentication token based on the verification result.

[0109] Specifically, the terminal device receives the proof result returned by the server. After obtaining the three intermediate parameters T1, T2, and T3, the random numbers stored locally can be used as a basis. The authenticity of the verification results is verified using random group elements R and the user identifier of the target user.

[0110] In one example, the terminal device can inversely deduce the randomized field through calculations using intermediate parameter T2, random group element R, and public parameter X1. ,and The terminal device can also reverse-engineer the randomized field by calculating the intermediate parameter T3, the random group element R, and the public parameter Y1. ,and Obtain the randomized field. and randomized fields Then, the terminal device can be based on random numbers Determine the randomized fields and randomized fields The accuracy. Specifically, if ,and If successful, the terminal device can confirm that the verification has passed. ,and If the verification fails, the terminal device can determine that the verification has failed. At this point, the terminal device can re-execute the S303 process until the verification passes.

[0111] Once the verification is successful, the terminal device can generate an authentication token that can be checked by the verification server. .

[0112] S305, the terminal device sends an authentication token to the authentication server.

[0113] The terminal device generates the authentication token in the above manner. Then, an authentication token can be sent to the verification server. .

[0114] S306, The verification server authenticates the target user based on the authentication token.

[0115] S307: After successful authentication, the verification server provides the target service to the terminal device.

[0116] In one example, where the target registration server verifies the identity of the target user using zero-knowledge proof, the verification server receives the authentication token sent by the terminal device. Then, it can be based on the authentication token. User ID in , The publicly available parameter H of the target registration server is used to reconstruct parameter U using Formula 7 above. The reconstruction process is consistent with how the terminal device determines parameter U. Furthermore, the verification server can also determine matrix M and vector Y by referring to the method used by the target registration server to determine matrix M and vector Y. Afterward, the verification server can verify the proof results in the following manner. The legitimacy of it.

[0117] The verification server can be based on matrix M and the proof results. The second commitment value is determined using the response value s, the first challenge value c, and the vector Y, with reference to Formula 11 below. The second challenge value is determined by referring to Formula Twelve below. .

[0118] (Formula Eleven) (Formula 12) The verification server can be used at the first challenge value c and the second challenge value. Equal, that is In the case where authentication of the target user is successful, i.e., the authentication token of the target user is deemed valid, the verification server can then provide the target service to the terminal device. This is based on the first challenge value c and the second challenge value. Not equal, that is In this case, the authentication server determines that the target user's authentication has failed, meaning the target user's authentication token is invalid. At this point, the authentication server will not provide the target service to the terminal device.

[0119] Through the above technical solution, users present a randomized, one-time authentication token to the verification server, rather than user credentials. Furthermore, when requesting authentication from the registration server, users do not need to disclose the service they wish to access or their user identifier. This method prevents attackers in the network channel from stealing user credentials by eavesdropping on network channel data. Simultaneously, the registration server only participates in the user authentication process but cannot know which verification server the user specifically authenticated with, thus avoiding the privacy risks of complete monitoring of user movements by the issuing party in traditional centralized IdP models.

[0120] The aforementioned verification server requires the public key of the target registration server. Determine the second challenge value In this embodiment of the application, the verification server obtains the public key of the target registration server. The process is not specifically limited. In one example, the verification server can obtain the public key of the target registry server from the target registry server. In another example, the verification server can obtain the public key of the target registration server from the blockchain. .

[0121] The verification server obtains the public key of the target registration server from the blockchain. In this case, the blockchain can include a server registration list, which stores the server identifiers and public keys of the registered servers. The correspondence between them is established. Accordingly, after generating its own public and private keys using the above method, the target registration server can send its server identifier and public key to the blockchain nodes. The blockchain nodes can then store the target registration server's server identifier and public key in their server registration lists. In this way, the verification server can retrieve the target registration server's public key from the blockchain based on its server identifier. .

[0122] In an optional implementation, before authenticating the target user based on the authentication token, the verification server may further determine whether the target user has registered their identity with the target registration server. If the target user has registered their identity with the target registration server, the verification server may execute steps S306-S307. If the target user has not registered their identity with the target registration server, the verification server suspends verification.

[0123] The following describes the process by which the verification server determines whether a target user has registered their identity on the target registration server.

[0124] The terminal device can send an authentication token and the server identifier of the target registration server to the verification server. The verification server can then obtain the target user's registration information under the target registration server based on the user identifier and the server identifier contained in the authentication token. If the registration information indicates that the target user is already registered, the verification server can determine that the target user has registered with the target registration server. If the verification server cannot obtain the target user's registration information, or if the target user's registration information has been revoked, the verification server can determine that the target user has not registered with the target registration server.

[0125] In one optional implementation, the user's registration information under the registration server can be stored in a blockchain. Correspondingly, the verification server can retrieve the target user's registration information under the target registration server from the blockchain. If the target user's registration information does not exist in the blockchain, or if the target user's registration information in the blockchain has been revoked, the verification server can determine that the target user has not registered on the target registration server. If the target user's registration information exists in the blockchain, the verification server can determine that the target user has registered on the target registration server.

[0126] If a user intends to withdraw their registration information under a specific registration server, they can send a registration withdrawal request to that registration server via their terminal device to request the withdrawal of the user's registration information under that server. The following describes the process of withdrawing a user's registration information under a target registration server, using the example of a user intending to withdraw their registration information.

[0127] Figure 4 This is a schematic diagram of an interactive process for revoking identity registration information provided in an embodiment of this application. The method is implemented through interaction between a terminal device, a target registration server, and blockchain nodes. Figure 4 As shown, the method includes S401-S404.

[0128] S401, the terminal device sends a registration cancellation request to the target registration server.

[0129] In this way, the target registration server can receive registration cancellation requests from the terminal device.

[0130] A registration cancellation request is used to request the cancellation of the target user's identity registration information under the target registration server.

[0131] Specifically, the target users through the above Figure 2 The method shown describes how, after registering one's identity information with the target registration server, if the target user subsequently intends to withdraw their registration information, they can trigger the withdrawal operation via a terminal device. In response to the user's withdrawal operation, the terminal device generates a registration withdrawal request based on the target user's user identifier and sends it to the target registration server. Thus, the target registration server can receive the registration withdrawal request sent by the terminal device.

[0132] S402, the target registration server generates a revocation command.

[0133] The revocation command includes the target user's user identifier and the target registration server's server identifier.

[0134] After receiving a registration cancellation request from a terminal device, the target registration server can parse the request to obtain the target user's identifier. Then, based on the target user's identifier and its own server identifier, the target registration server can generate a cancellation command.

[0135] To ensure that the entity revoking the registration information of a target user registered on the target registration server is the target user themselves, in one optional implementation, the target registration server can obtain the user's credentials through a terminal device. If the obtained credentials match the target user's credentials, the target registration server can determine that the entity revoking the registration information is indeed the target user. If the obtained credentials do not match the target user's credentials, the target registration server can determine that the entity revoking the registration information is not the target user themselves.

[0136] To ensure that the user credentials of the target user are not leaked, the terminal device can use a secure channel to send the user credentials to the target registration server.

[0137] S403, the target registration server sends a revocation command to the nodes of the blockchain.

[0138] When a user's registration information under the registration server is stored on the blockchain, the target registration server can send a revocation command to the blockchain nodes, including the target user's user identifier and its own server identifier.

[0139] In one example, the revocation command can include not only the target user's user identifier and its own server identifier, but also the command type, such as... ,in, The instruction type used to identify this instruction is an undo instruction. For user identification, This serves as the server identifier. Thus, upon receiving the revocation command, a blockchain node can quickly revoke the target user's registration information on the target registration server based on the command type, user identifier, and server identifier carried in the revocation command.

[0140] S404, a node in the blockchain revoks the target user's identity registration information under the target registration server.

[0141] Specifically, a blockchain can include a revocation list, which records the correspondence between user identifiers and server identifiers. Each correspondence indicates that the user identifier's registration information under the target registration server indicated by that server identifier has been revoked. Correspondingly, after receiving a revocation command, a blockchain node can parse it to obtain the target user's identifier and the target registration server's identifier carried in the command. The blockchain node can then store the target user's identifier and the target registration server's identifier in the revocation list, indicating that the target user's registration information under the target registration server has been revoked.

[0142] To prevent the information contained in the revocation instruction from being maliciously modified during transmission, in one optional implementation, after the target registration server generates the revocation instruction, it can also sign the revocation instruction. Correspondingly, after receiving the revocation instruction, the blockchain node can verify the signature on the revocation instruction. After the verification is successful, the blockchain node can revoke the target user's identity registration information under the target registration server in the blockchain in the manner described above.

[0143] It is understandable that after the target user's identity registration information under the target registration server is revoked, the target user can register on a registration server other than the target registration server. The specific registration process can be referred to the above. Figure 2 The method of identity registration under the target registration server will not be elaborated here.

[0144] With the above technical solution, when a user needs to migrate from one registration server to another, they must first revoke their identity information registered on the original registration server. This mechanism ensures the atomicity of user identity status transfer, that is, the premise of "the new identity taking effect" is to strictly guarantee the "expiration of the old identity".

[0145] The identity registration device provided in the embodiments of this application is described below. The identity registration device described below can be referred to in correspondence with the identity registration method described above.

[0146] Figure 5 This example illustrates the structure of an identity registration device located on a target registration server. The device includes: The receiving module 501 is used to receive a registration request from the terminal device. The registration request is used to request the target user to register their identity.

[0147] Registration module 502 registers the target user's identity and generates user credentials when the target user is in an unregistered state under each registration server.

[0148] The sending module 503 is used to send user credentials to the terminal device.

[0149] Figure 6 A schematic diagram of another identity registration device is shown, located in a terminal device, and the device includes: The sending module 601 is used to send a registration request to the target registration server. The registration request is used to request the target user to register their identity, so that the target registration server can register the target user's identity and generate user credentials when the target user is in an unregistered state under each registration server.

[0150] The receiving module 602 is used to receive and store user credentials.

[0151] Figure 7 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 7 As shown, the electronic device may include: a processor 710, a communication interface 720, a memory 730, and a communication bus 740, wherein the processor 710, the communication interface 720, and the memory 730 communicate with each other via the communication bus 740. The processor 710 can call a computer program in the memory 730 to execute steps of the identity registration method, such as: Receive a registration request from a terminal device, requesting registration of the target user. If the target user is unregistered under each registration server, register the target user, generate user credentials, and send the user credentials to the terminal device; or... A registration request is sent to the target registration server. This request is used to request the target user to register their identity, so that the target registration server can register the target user even if the target user is in an unregistered state under each registration server, and generate user credentials. The user credentials are received and stored.

[0152] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0153] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the identity registration method provided in the above embodiments, such as including: Receive a registration request from a terminal device, requesting registration of the target user. If the target user is unregistered under each registration server, register the target user, generate user credentials, and send the user credentials to the terminal device; or... A registration request is sent to the target registration server. This request is used to request the target user to register their identity, so that the target registration server can register the target user even if the target user is in an unregistered state under each registration server, and generate user credentials. The user credentials are received and stored.

[0154] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing a processor to execute the steps of the identity registration method provided in the above embodiments, such as including: Receive a registration request from a terminal device, requesting registration of the target user. If the target user is unregistered under each registration server, register the target user, generate user credentials, and send the user credentials to the terminal device; or... A registration request is sent to the target registration server. This request is used to request the target user to register their identity, so that the target registration server can register the target user even if the target user is in an unregistered state under each registration server, and generate user credentials. The user credentials are received and stored.

[0155] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0156] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0157] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0158] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An identity registration method, characterized in that, Applied to the target registry server, including: Receive a registration request from a terminal device, the registration request being used to request the identity registration of the target user; If the target user is in an unregistered state under each registration server, the target user is registered and a user credential is generated. Send the user credentials to the terminal device.

2. The identity registration method according to claim 1, characterized in that, The registration request includes the user identifier of the target user; Before registering the identity of the target user when the target user is in an unregistered state under each registration server, the method further includes: Based on the user identifier of the target user, the registration status of the target user under each registration server is determined through blockchain.

3. The identity registration method according to claim 2, characterized in that, If the target user's identity registration information does not exist in the blockchain, or if the target user's identity registration information in the blockchain has been revoked, it indicates that the target user is in an unregistered state under each registration server.

4. The identity registration method according to claim 2 or 3, characterized in that, The blockchain stores the identity registration information of the target user under the target registration server, and the method further includes: Receive a registration cancellation request from the terminal device, the registration cancellation request being used to request the cancellation of the target user's identity registration information under the target registration server; Generate a revocation command, wherein the revocation command includes the user identifier of the target user and the server identifier of the target registration server; The revocation instruction is sent to the nodes of the blockchain so that the nodes of the blockchain revoke the identity registration information of the target user under the target registration server in the blockchain.

5. An identity registration method, characterized in that, Applied to terminal devices, including: Send a registration request to the target registration server. The registration request is used to request the target user to register their identity, so that the target registration server can register the target user's identity and generate user credentials when the target user is in an unregistered state under each registration server. Receive and store the user credentials.

6. The identity registration method according to claim 5, characterized in that, Before storing the user credentials, the method further includes: The user credentials are encrypted.

7. The identity registration method according to claim 6, characterized in that, The encryption of the user credentials includes: Generate high-entropy random numbers; Obtain user password; An encryption key is generated based on the high-entropy random number and the user password; The user credentials are encrypted using the encryption key.

8. The identity registration method according to any one of claims 5-7, characterized in that, The method further includes: Send a target service access request to the verification server; Receive the authentication request sent by the verification server; The identity of the target user is verified through the target registration server; Based on the verification result, an authentication token is generated, which is used to authenticate the target user; The authentication token is sent to the verification server so that the verification server can authenticate the target user based on the authentication token and then provide the target service to the terminal device.

9. The identity registration method according to claim 8, characterized in that, The step of verifying the identity of the target user through the target registration server includes: The user credentials are randomized and blinded. An authentication request is sent to the target registration server, the authentication request containing the user credentials after being blinded, so that the target registration server can verify the identity of the target user based on the user credentials after being blinded.

10. The identity registration method according to claim 8, characterized in that, Before generating the authentication token based on the verification result, the method further includes: The authenticity of the verification results is verified.

11. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the identity registration method as described in any one of claims 1 to 4 or 5 to 10.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the identity registration method as described in any one of claims 1 to 4 or 5 to 10.

Images