Information management system, method and device

Abstract

The present application provides a system, method and apparatus for information management, wherein a user obtains the user's complete identity information through a first device, and a second device obtains the identity information required for verification of different services through different second public keys, thereby strengthening the privacy protection of the user's identity information. The method includes: the second device initiates a registration request to the server. The server sends the type of information that needs to be verified for the first service and the identifier of the first service to the second device. The second device establishes a binding relationship between the public key of the second device and the identifier of the first service. The first device obtains the type of information that needs to be verified for the first service from the second device, and according to the type of information that needs to be verified for the first service, obtains the information that needs to be verified for the first service from the information locally stored on the first device, and there is a binding relationship between the information that needs to be verified for the first service and the public key of the second device.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence security, and in particular to a method and device for image processing. Background Art

[0002] With the popularization and diversification of online activities, various identities are flooding the cyberspace, and the management of online identities faces many serious problems.

[0003] Improper online identity management leads to frequent identity leaks, online fraud, and theft of online banking funds, posing significant risks to people's lives and property. Furthermore, the digitization of social activities has spread sensitive personal identity data across multiple online applications. As more and more companies take on the role of identity management, the ability to securely and effectively manage identity information and the trustworthiness of identity management services are attracting widespread attention. Summary of the Invention

[0004] The embodiments of the present application provide a system, method, and device for identity information management, which generates different business identities for each business according to the different identity information required for verification, thereby effectively protecting the user's data privacy and security.

[0005] In view of this, the first aspect of the present application provides a system for identity information management, including: a first device, a second device and a server. The second device is used to initiate a registration request to the server. The server is used to send a first message to the second device in response to the registration request, and the first message carries the type of identity information that needs to be verified by the first business and the identifier of the first business. The second device is also used to establish a binding relationship between the public key of the second device and the identifier of the first business. The first device is used to obtain the type of identity information that needs to be verified by the first business from the second device, and according to the type of identity information that needs to be verified by the first business, obtain the identity information that needs to be verified by the first business from the identity information locally stored in the first device, and there is a binding relationship between the identity information that needs to be verified by the first business and the public key of the second device.

[0006] In the embodiment of the present application, the user obtains the user's complete identity information through the first device, and other devices other than the first device cannot obtain the user's complete identity information, thereby strengthening the privacy protection of the user's identity information. In addition, due to the different identity information required for verification of each service, the public keys of different second devices are bound to the identity information required for verification of different services. This is equivalent to setting up multiple subordinate identities for each primary identity, each subordinate identity corresponds to the public key of a second device, and each subordinate identity is used to access a service. Each service can only obtain the identity information it needs to verify, and cannot obtain the user's complete identity information, further strengthening the privacy protection of the user's identity information.

[0007] In a first possible implementation of the first aspect, the system further includes a blockchain node. The first device is further configured to send the encrypted identity information required for verification by the first service to the blockchain node. The blockchain node is configured to establish a binding relationship between the encrypted identity information required for verification by the first service and the public key of the second device. In this implementation, the identity information required for verification by the first service is stored on the blockchain node. Maintaining the identity information required for verification by the first service ensures that it is not tampered with, thereby increasing the stability of the solution.

[0008] In a first possible implementation of the first aspect, the first device is further configured to send the encrypted identity information required for verification of the first service to the second device. The second device is further configured to establish a binding relationship between the encrypted identity information required for verification of the first service and the public key of the second device. In this implementation, storing the identity information required for verification of the first service on the second device conserves storage and communication resources of the blockchain. Since the second device is typically a mobile phone, which offers higher security, storing the encrypted first identity information on the mobile phone can improve the security of the identity information.

[0009] In a first possible implementation of the first aspect, the first device is further configured to, after sending the encrypted identity information requiring verification for the first service, delete the encrypted identity information requiring verification for the first service stored locally on the first device. In this implementation, after registration is completed and the encrypted identity information requiring verification for the first service has been saved on the second device or blockchain, the encrypted first service stored locally on the first device may be deleted to conserve local storage resources of the first device.

[0010] In a first possible implementation of the first aspect, the first device is further configured to obtain a user's biometric characteristics and generate a private key for the first device based on the biometric characteristics. In this implementation, the private key for the first device can be generated based on the user's biometric characteristics, eliminating the need for the first device to locally store the private key and eliminating the risk of losing the private key if the first device is lost.

[0011] In a first possible implementation of the first aspect, the first device is further used to register a decentralized identity DID using the public key of the first device. In this implementation, in an embodiment of the present application, the DID is registered through the first public key, so that the first public key is bound to a unique DID. After the server obtains the DID, it can query the first public key based on the DID and verify the identity based on the first public key, such as verifying that the received digital signature comes from the first device. If different first devices use the same first public key, the DIDs obtained from the multiple different first devices may be the same. In order to enable each first device to have a unique DID, after the first device obtains the DID, the blockchain will also check the obtained DID for duplication. If the same DID has not been stored on the current blockchain, it is considered that the registration is successful, and the first public key is bound to a unique DID.

[0012] In a first possible implementation of the first aspect, the first device is further configured to generate a private key of the second device and a public key of the second device, and send the private key of the second device and the public key of the second device to the second device.

[0013] In a first possible implementation of the first aspect, the first device is further configured to obtain an identifier of the first service from the second device. The first device is specifically configured to generate a private key of the second device based on the identifier of the first service, identity information to be verified by the first service, and the private key of the first device.

[0014] In the second aspect, an embodiment of the present application provides a system for identity information management, including: a first device, a second device and a server. The second device is used to initiate an access request to the server. The server is used to send an identity request IR message to the second device in response to the access request, and the IR message carries the identifier of the first business. The second device is also used to find the public key of the second device bound to the first business identifier based on the identifier of the first business. The second device is also used to generate a digital signature of the second device using the private key of the second device corresponding to the public key of the second device, and send the digital signature of the second device and the public key of the second device to the first device. The first device is used to verify that the digital signature of the second device comes from the second device, and then obtain the identity information that needs to be verified for the first business bound to the public key of the second device. The first device is also used to generate the digital signature of the first device based on the private key of the first device, and the digital signature carries the identity information that needs to be verified for the first business. The server is also used to obtain the digital signature of the first device, and after verifying that the digital signature of the first device comes from the first device, obtain the identity information that needs to be verified for the first business.

[0015] In a first possible implementation of the second aspect, the system further includes a blockchain node. The first device is specifically configured to obtain, from the blockchain node, encrypted identity information requiring verification for the first service that is bound to a public key of the second device, and decrypt the encrypted identity information requiring verification for the first service using a private key of the first device to obtain the identity information requiring verification for the first service.

[0016] In a first possible implementation of the second aspect, the first device is specifically used to obtain the encrypted identity information that needs to be verified for the first service and is bound to the public key of the second device from the second device, and decrypt the encrypted identity information that needs to be verified for the first service according to the private key of the first device to obtain the identity information that needs to be verified for the first service.

[0017] In a first possible implementation of the second aspect, the first device is specifically used to obtain the encrypted identity information that needs to be verified for the first service from the local first device, and decrypt the encrypted identity information that needs to be verified for the first service according to the private key of the first device to obtain the identity information that needs to be verified for the first service.

[0018] In a first possible implementation of the second aspect, the first device is further configured to delete the private key of the first device and the identity information required for verification of the first service after sending the digital signature of the first device.

[0019] In a first possible implementation of the second aspect, the first device is further configured to obtain a biometric feature of the user after verifying that the digital signature of the second device comes from the second device, and to generate a private key of the first device based on the biometric feature.

[0020] On the third aspect, an embodiment of the present application provides a system for identity information management, including: a first device, a second device and a server. The second device is used to initiate a registration request to the server. The server is used to send a first message to the second device in response to the registration request, and the first message carries the type of identity information that needs to be verified by the first business and the identifier of the first business. The first device is used to obtain the type of identity information that needs to be verified by the first business from the second device, and according to the type of identity information that needs to be verified by the first business, obtain the identity information that needs to be verified by the first business from the identity information locally stored in the first device. The identity information that needs to be verified by the first business is bound to the target key, and the target key is generated based on the first key, the second key and the third key. The first key is a key generated based on the biometric characteristics of the user obtained by the first device, the second key is a key generated based on the identifier of the first device, and the third key is a key generated based on the identifier of the first business. The first device is also used to encrypt the identity information that needs to be verified by the first business according to the target key.

[0021] In a first possible implementation of the third aspect, the first device is further configured to delete the first key, the second key, the third key, and the target key.

[0022] In a first possible implementation of the third aspect, the second device is further configured to generate a third key according to the identifier of the first service, and establish a binding relationship between the third key and the identifier of the first service.

[0023] The fourth aspect of the present application provides an identity information management system, including: a first device, a second device and a server. The second device is used to initiate an access request to the server. The server is used to send an identity request IR message to the second device in response to the access request, and the IR message carries the identifier of the first service. The first device is used to obtain the identifier of the first service from the second device. The first device is also used to generate a target key based on a first key, a second key and a third key, the first key is a key generated based on the biometric characteristics of the user obtained by the first device, the second key is a key generated based on the identifier of the first device, and the third key is a key generated based on the identifier of the first service. The first device is also used to decrypt the encrypted identity information that needs to be verified by the first service according to the target key to obtain the identity information that needs to be verified by the first service. The first device also encrypts the identity information that needs to be verified by the first service according to the public key of the server, so that the server obtains the identity information that needs to be verified by the first service after decryption according to the private key of the server.

[0024] In a first possible implementation of the fourth aspect, the first device is further configured to delete the first key, the second key, the third key, and the target key.

[0025] In a first possible implementation of the fourth aspect, the second device is further configured to obtain a third key bound to the identifier of the first service, and send the third key to the first device.

[0026] In the fifth aspect, an embodiment of the present application provides a method for identity information management, which is applied to an identity information management system. The identity information management system includes a first device, a second device and a server. The method includes: the second device initiates a registration request to the server. The second device receives a first message sent by the server in response to the registration request, and the first message carries the type of identity information that needs to be verified for the first business and the identifier of the first business. The second device establishes a binding relationship between the public key of the second device and the identifier of the first business. The second device sends the type of identity information that needs to be verified for the first business to the first device, so that the first device obtains the identity information that needs to be verified for the first business from the identity information locally stored in the first device according to the type of identity information that needs to be verified for the first business. There is a binding relationship between the identity information that needs to be verified for the first business and the public key of the second device.

[0027] In a first possible implementation of the fifth aspect, the method further includes: the second device receiving the encrypted identity information required for verification of the first service sent by the first device, and establishing a binding relationship between the encrypted identity information required for verification of the first service and the public key of the second device.

[0028] In a first possible implementation of the fifth aspect, the method further includes: the second device receiving a private key of the second device and a public key of the second device sent by the first device.

[0029] In a first possible implementation of the fifth aspect, the application is to an identity information management system, the identity information management system includes a first device, a second device and a server, and the method includes: the first device obtains the type of identity information that needs to be verified for the first business from the second device, and according to the type of identity information that needs to be verified for the first business, obtains the identity information that needs to be verified for the first business from the identity information locally stored in the first device, and there is a binding relationship between the identity information that needs to be verified for the first business and the public key of the second device.

[0030] In a first possible implementation of the fifth aspect, the method further includes: the first device establishing a binding relationship between identity information that needs to be verified for the first service and a public key of the second device.

[0031] In a first possible implementation of the fifth aspect, the method further includes: the first device encrypting identity information that needs to be verified for the first service according to a public key of the first device.

[0032] In a first possible implementation of the fifth aspect, the system also includes a blockchain node, and the method also includes: the first device sends the encrypted identity information that needs to be verified for the first business to the blockchain node, so that the blockchain node establishes a binding relationship between the encrypted identity information that needs to be verified for the first business and the public key of the second device.

[0033] In a first possible implementation of the fifth aspect, the method also includes: the first device sends the encrypted identity information that needs to be verified for the first service to the second device, so that the second device establishes a binding relationship between the encrypted identity information that needs to be verified for the first service and the public key of the second device.

[0034] In a first possible implementation of the fifth aspect, the method further includes: after the first device sends the encrypted identity information that needs to be verified for the first service, deleting the encrypted identity information that needs to be verified for the first service that is locally stored on the first device.

[0035] In a first possible implementation of the fifth aspect, the method further includes: the first device acquiring a biometric feature of the user, and generating a private key of the first device based on the biometric feature.

[0036] In a first possible implementation of the fifth aspect, the method further includes: the first device registering a decentralized identity DID using the public key of the first device.

[0037] In a first possible implementation of the fifth aspect, the method further includes: the first device generating a private key of the second device and a public key of the second device, and sending the private key of the second device and the public key of the second device to the second device.

[0038] In a first possible implementation of the fifth aspect, the method further includes: the first device obtaining an identifier of the first service from the second device. The first device generating a private key for the second device includes: the first device generating the private key for the second device based on the identifier of the first service, identity information that needs to be verified for the first service, and the private key of the first device.

[0039] The sixth aspect of the embodiment of the present application provides a method for identity information management, which is applied to an identity information management system. The identity information management system includes a first device, a second device and a server. The method includes: the second device initiates an access request to the server. The second device receives an identity request IR message sent by the server in response to the access request, and the IR message carries the identifier of the first business. The second device searches for the public key of the second device bound to the first business identifier based on the identifier of the first business. The second device uses the private key of the second device corresponding to the public key of the second device to generate a digital signature of the second device, and sends the digital signature of the second device and the public key of the second device to the first device, so that the first device verifies that the digital signature of the second device comes from the second device, and then obtains the identity information that needs to be verified for the first business bound to the public key of the second device.

[0040] In a first possible implementation of the sixth aspect, the method is applied to an identity information management system, the identity information management system including a first device, a second device, and a server. The method includes: after the first device verifies that the digital signature of the second device comes from the second device, obtaining identity information that is bound to the public key of the second device and that needs to be verified by a first service. The first device generates a digital signature of the first device based on the private key of the first device, where the digital signature carries the identity information that needs to be verified by the first service.

[0041] In a first possible implementation of the sixth aspect, the system also includes a blockchain node, and after the first device verifies that the digital signature of the second device comes from the second device, it obtains the identity information that needs to be verified for the first business that is bound to the public key of the second device, including: after the first device verifies that the digital signature of the second device comes from the second device, it obtains the encrypted identity information that needs to be verified for the first business that is bound to the public key of the second device from the blockchain node, and decrypts the encrypted identity information that needs to be verified for the first business according to the private key of the first device to obtain the identity information that needs to be verified for the first business.

[0042] In a first possible implementation of the sixth aspect, after the first device verifies that the digital signature of the second device comes from the second device, it obtains the identity information that needs to be verified for the first service that is bound to the public key of the second device, including: after the first device verifies that the digital signature of the second device comes from the second device, it obtains the encrypted identity information that needs to be verified for the first service that is bound to the public key of the second device from the second device, and decrypts the encrypted identity information that needs to be verified for the first service according to the private key of the first device to obtain the identity information that needs to be verified for the first service.

[0043] In a first possible implementation of the sixth aspect, after the first device verifies that the digital signature of the second device comes from the second device, it obtains the identity information that needs to be verified for the first service that is bound to the public key of the second device, including: after the first device verifies that the digital signature of the second device comes from the second device, it obtains the encrypted identity information that needs to be verified for the first service from the local first device, and decrypts the encrypted identity information that needs to be verified for the first service according to the private key of the first device to obtain the identity information that needs to be verified for the first service.

[0044] In a first possible implementation of the sixth aspect, the method further includes: after the first device sends the digital signature of the first device, deleting the private key of the first device and the identity information that needs to be verified by the first service.

[0045] In a first possible implementation of the sixth aspect, the method further includes the first device verifying that the digital signature of the second device comes from the second device, obtaining the user's biometrics, and generating a private key of the first device based on the biometrics.

[0046] A seventh aspect of an embodiment of the present application provides a method for identity information management, which is applied to an identity information management system, the identity information management system including a first device, a second device, and a server. The method includes: the second device initiating a registration request to the server. The second device receiving a first message from the server, the first message carrying a type of identity information to be verified for a first service and an identifier of the first service.

[0047] An eighth aspect of an embodiment of the present application provides a method for identity information management, which is applied to an identity information management system. The identity information management system includes a first device, a second device, and a server. The method includes: the first device obtains the type of identity information that needs to be verified by the first business from the second device, and obtains the identity information that needs to be verified by the first business from the identity information locally stored on the first device based on the type of identity information that needs to be verified by the first business. The identity information that needs to be verified by the first business is bound to a target key. The target key is generated based on the first key, the second key, and the third key. The first key is a key generated based on the biometric characteristics of the user obtained by the first device, the second key is a key generated based on the identification of the first device, and the third key is a key generated based on the identification of the first business. The first device encrypts the identity information that needs to be verified by the first business based on the target key.

[0048] A ninth aspect of an embodiment of the present application provides a method for identity information management, which is applied to an identity information management system. The identity information management system includes a first device, a second device, and a server. The method includes: the second device initiates an access request to the server. The second device receives an identity request IR message sent by the server, and the IR message carries an identifier of the first service. The second device sends the identifier of the first service to the first device.

[0049] The tenth aspect of the embodiment of the present application provides a method for identity information management, which is applied to an identity information management system, the identity information management system including a first device, a second device and a server, the method including: the first device obtains the identification of the first business from the second device. The first device generates a target key based on the first key, the second key and the third key, the first key is a key generated based on the biometric characteristics of the user obtained by the first device, the second key is a key generated based on the identification of the first device, and the third key is a key generated based on the identification of the first business. The first device decrypts the encrypted identity information that needs to be verified by the first business according to the target key to obtain the identity information that needs to be verified by the first business. The first device encrypts the identity information that needs to be verified by the first business according to the public key of the server, so that the server obtains the identity information that needs to be verified by the first business after decryption according to the private key of the server.

[0050] In an eleventh aspect, embodiments of the present application provide a second device that implements the functions of the second device in the method described in the fifth, seventh, or ninth aspects above. This function can be implemented via hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0051] In a twelfth aspect, an embodiment of the present application provides a first device, wherein the second device has the functions of the first device in the method described in the sixth aspect, the eighth aspect, or the tenth aspect. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0052] In a thirteenth aspect, an embodiment of the present application provides a second device comprising: a processor and a memory, wherein the processor and the memory are interconnected via a circuit, and the processor invokes program code in the memory to execute the processing-related functions of the method described in any of the fifth, seventh, or ninth aspects above. Optionally, the home device may be a chip.

[0053] In a fourteenth aspect, an embodiment of the present application provides a first device comprising: a processor and a memory, wherein the processor and the memory are interconnected via a circuit, and the processor invokes program code in the memory to execute the processing-related functions of the method described in any one of the sixth aspect, the eighth aspect, or the tenth aspect. Optionally, the home device may be a chip.

[0054] In the fifteenth aspect, an embodiment of the present application provides a device, which can also be called a digital processing chip or chip. The chip includes a processing unit and a communication interface. The processing unit obtains program instructions through the communication interface, and the program instructions are executed by the processing unit. The processing unit is used to perform processing-related functions in any optional implementation of the fifth aspect, seventh aspect, or ninth aspect mentioned above.

[0055] In the sixteenth aspect, an embodiment of the present application provides a device, which can also be called a digital processing chip or chip. The chip includes a processing unit and a communication interface. The processing unit obtains program instructions through the communication interface, and the program instructions are executed by the processing unit. The processing unit is used to perform processing-related functions in any optional implementation of the sixth aspect, the eighth aspect, or the tenth aspect mentioned above.

[0056] In the seventeenth aspect, an embodiment of the present application provides a computer-readable storage medium comprising instructions, which, when executed on a computer, enables the computer to execute the method in any optional implementation of the fifth aspect, seventh aspect, or ninth aspect above.

[0057] In the eighteenth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method in any optional implementation of the sixth aspect, the eighth aspect, or the tenth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 A flowchart for generating and verifying digital signatures;

[0059] Figure 2 A schematic diagram of the architecture of an identity management system provided in an embodiment of the present application;

[0060] Figure 3 A schematic diagram of the architecture of another identity management system provided in an embodiment of the present application;

[0061] Figure 4 A schematic diagram of a typical application scenario provided by an embodiment of the present application;

[0062] Figure 5 A flowchart of an information management method provided in an embodiment of the present application;

[0063] Figure 6 A flowchart of another information management method provided in an embodiment of the present application;

[0064] Figure 7 A flowchart of another information management method provided in an embodiment of the present application;

[0065] Figure 8 A flowchart of another information management method provided in an embodiment of the present application;

[0066] Figure 9 A flowchart of another information management method provided in an embodiment of the present application;

[0067] Figure 10 A flowchart of another information management method provided in an embodiment of the present application;

[0068] Figure 11 A flowchart of another information management method provided in an embodiment of the present application;

[0069] Figure 12 A flowchart of another information management method provided in an embodiment of the present application;

[0070] Figure 13 A schematic structural diagram of a second device provided in an embodiment of the present application;

[0071] Figure 14 A schematic structural diagram of a first device provided in an embodiment of the present application;

[0072] Figure 15 A schematic structural diagram of another second device provided in an embodiment of the present application;

[0073] Figure 16 A schematic structural diagram of another first device provided in an embodiment of the present application;

[0074] Figure 17A schematic diagram of the structure of a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0075] The following will describe the technical solutions in the embodiments of this application in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0076] Centralized identity management refers to the issuance and control of user identities by a single organization or server. The specific process is as follows: the user provides some information to the service provider and applies for an identity based on this information. The service provider generates an identity for the user (generally a username and password), stores this information on the server, and then issues the identity to the user. When a user accesses a service, they need to provide identity information (generally a username and password). The service provider's server compares the user's identity information stored in it and, after verification, allows the user to use the service. The most common scenario involves a user registering for a service, obtaining an account and password, logging in with that account and password, and using the service.

[0077] Centralized identity management solutions give organizations or central servers complete control over user identities, including the ability to revoke or change them at any time. This deprives users of control over their identities, including the right to be informed. Furthermore, system vulnerabilities in organizations or central servers can lead to the leakage of a large amount of user identity information, leaving users' identities vulnerable.

[0078] To address the aforementioned issues, the present invention provides an identity management solution that addresses the potential security risks of user privacy leakage associated with centralized identity management solutions. Since the present invention involves extensive knowledge related to public keys, certificates, encryption and decryption, and signature technologies, this information is first introduced to facilitate understanding of the solution provided by the present invention.

[0079] A one-way hash function, also known as a one-way hash function or hash function, is used to transform an input message string of arbitrarily long into an output string of fixed length, making it difficult to derive the input string from the output string. This output string is called the hash value of the message. It is generally used to generate message digests and key encryption. One-way hash functions have the following advantages:

[0080] 1. The length of the encrypted ciphertext is fixed (that is, for three columns of a message of any length, the resulting hash value is fixed length).

[0081] 2. If the plaintext is different, the hashed result will definitely be different.

[0082] 3. If the plaintext is the same, then the encrypted ciphertext must be the same (the encrypted ciphertext is the same if the same data is encrypted).

[0083] 4. It is one-way and cannot be reversed.

[0084] Asymmetric cryptography is a type of cryptographic algorithm that requires a pair of keys: a private key (abbreviated as the private key) and a public key (abbreviated as the public key). These two keys are mathematically related, so information encrypted with a user's private key can only be decrypted with that user's decryption key. Knowledge of one key cannot be used to determine the other. Therefore, disclosing one key (the public key) does not compromise the secrecy of the other (or the private key). If the encryption key is a public key, it is used by clients to upload encrypted data to the owner of the private key. This is called public-key encryption. If the decryption key is a public key, information encrypted with the private key can be decrypted with the public key. This allows clients to verify the integrity and accuracy of data or files published by the holder of the private key. This ensures that the recipient knows the information originated from the owner of the private key. This is called a digital signature, and the public key is presented in the form of a digital certificate. For example, installation programs downloaded from the Internet generally carry a digital signature from the program maker, which can prove that the program was indeed released by the author (company) and not forged by a third party and has not been tampered with (identity authentication / verification).

[0085] The following combination Figure 1 To further explain the digital signature process: The data sender performs a hash calculation on the text to be transmitted, obtaining the result as a digest of the text. The digest of the text to be transmitted is then encrypted using the sender's private key. The resulting ciphertext is called the signature of the transmission. The data receiver receives the transmitted text but needs to verify that it is the correct text and has not been tampered with. Therefore, it decrypts the signature using its public key (data encrypted by one key in a key pair can be decrypted using the other key). This yields the text digest. The digest is then calculated using the same hash algorithm as the sender and compared with the decrypted digest. If the two are identical, the text has not been tampered with. Verifying the exact consistency of the two is considered signature verification.

[0086] During the signing process, the party receiving the data needs to keep the public key safe. However, since each sender has a public key, the party receiving the data needs to store a large number of public keys, which makes management difficult. In addition, the locally stored public key may be tampered with and replaced without being detected. To solve this problem, a unified certificate management agency can manage the public keys of all parties who need to send data, and authenticate and encrypt the public keys. This agency is what we often call a certificate authority (CA). The authenticated and encrypted public key is the certificate, also known as a CA certificate. The certificate contains a lot of information, the most important of which is the applicant's public key. When encrypting the public key, the CA uses a unified key pair, and when encrypting the public key, it uses the private key within it. In this way, after obtaining the certificate, the applicant uses his or her private key to generate a signature when sending data, and sends the signature, certificate, and content to the other party. After the other party receives the certificate, it needs to decrypt the certificate to obtain the public key in the certificate. Decryption requires the public key in the CA organization's "unified key pair", which is what we often call the CA root certificate. We usually need to go to the certificate authority to download and install it on the corresponding client that receives data, such as a browser. This public key only needs to be installed once. With this public key, we can decrypt the certificate, obtain the sender's public key, and then decrypt the signature sent by the sender, obtain the digest, recalculate the digest, and compare it to verify the integrity of the data content.

[0087] The solution provided by the embodiment of the present application can be applied to any scenario that requires identity authentication. The solution provided by the embodiment of the present application can enable users to have autonomous identities, that is, an identity system in which users have autonomy and control. The biggest difference between autonomous identities and centralized identity management is that users have specific autonomy and control over their identities, while service providers do not have control over their identities. In addition, more importantly, the solution provided by the example of the present application can ensure that each service provider can only obtain part of the identity information that the service provider needs to verify, and cannot obtain the user's complete identity information, thereby ensuring the security of the user's identity information. In addition, through the solution provided by the embodiment of the present application, when the user's device is lost, the user's identity information will not be easily leaked, further ensuring the security of the identity information.

[0088] See also Figure 2 , is a schematic diagram of the architecture of an identity management system provided by an embodiment of the present application. The solution provided by the embodiment of the present application involves at least three execution entities, including a primary identity management device, a device using the service, and a server.

[0089] The primary identity management device is used to manage all of a user's identity information. The embodiments of this application provide solutions in which users have autonomy and control over their identity information. All identity information is kept by the user and can be stored on the primary identity management device. In some possible implementations, the primary identity management device can be a device that the user can carry with them, such as a smartwatch, smart glasses, smart ring, or other electronic device such as a mobile phone.

[0090] The device using the service is used to use the service. For example, clients corresponding to different services can be installed on the device using the service, and the user can use different services by operating the client, such as using shopping services, reading services, social services, game services, and so on. No identity information may be saved on the device using the service, and the device using the service may interact with the main identity management device to obtain some identity information from the main identity management device. In the solution provided in the embodiment of the present application, the device using the service and the main identity management device are two different devices, and for the same main identity management device, there may be corresponding multiple devices using the service. In some possible implementations, the device using the service may be a device that is convenient for installing the service, such as a mobile phone, PAD, etc. It may also be other electronic devices such as smart watches, smart glasses, and smart rings.

[0091] A server is used to provide services to devices using the service. In some scenarios, the server allows a device using the service to access the server without requiring the device to provide any identity information. In other scenarios, the server requires the device using the service to provide relevant identity information before allowing the device to access the server. The embodiments of the present application focus on scenarios where the server requires the device using the service to provide relevant identity information.

[0092] It should be noted that although Figure 2 Three servers, four devices using the service, and two primary identity management devices are shown in the figure. This does not mean that the embodiment of the present application limits their number. In actual application scenarios, there are more or fewer servers, devices using the service, and primary identity management devices.

[0093] See also Figure 3 , is a schematic diagram of the architecture of another identity management system provided in an embodiment of the present application. The solution provided in an embodiment of the present application also involves blockchain.

[0094] A blockchain consists of a continuously growing series of records, called blocks. These blocks are linked together using cryptographic techniques, with each block containing the hash value of the previous block, a timestamp, and transaction data. A blockchain is essentially a distributed, multi-backup database, but the key difference is that data storage is achieved through multi-party consensus, and historical data is protected using a hash chain, making the data tamper-proof. Compared to traditional database technology, the immutability of blockchain data makes it easier to gain user trust, thus better supporting multi-party collaboration. Typically, the public key generated by the master identity management device is crucial, and each master identity management device must be unique. Therefore, the public key generated by the master identity management device must be trustworthy. Therefore, this application leverages the immutability of the blockchain to ensure that decentralized identities (DIDs) are registered on the blockchain using public keys, so that each public key corresponds to a unique DID, and the public key generated by each master identity management device is tamper-proof.

[0095] Based on the above Figure 2 and Figure 3 The architecture described, Figure 4 This is a schematic diagram of a typical application scenario provided by the embodiment of the present application. Figure 4As shown, the user's identity information is diverse, such as name, date of birth, address, education level, medical records, income, etc. The main identity management device can obtain this identity information through a variety of different channels, such as obtaining education level from a school and medical records from a hospital. The embodiment of the present application does not limit how the main identity management device obtains the user's identity information. The main identity management device generates a private key of the main identity management device and a public key corresponding to the private key locally. The identity can be digitally signed by the private key so that the device with the public key can verify the digital signature. Different services are installed on the device using the service. This application sometimes refers to services as businesses. When the difference between the two is not specifically emphasized, they mean the same thing. The identity information that needs to be verified for each service may be different. For example, gaming services need to verify the user's age, financial services need to verify the user's income, and so on. Therefore, the embodiment of the present application enables each service to only obtain the identity information that it needs to verify, and cannot obtain all the user's information. Specifically, in the embodiment of the present application, multiple business identities are set for the main identity. The embodiment of the present application enables the device using the service to have multiple public-private key pairs. The public key in each public-private key pair is bound to a business and the identity information required for verification of the business, so that the device using the service can access the business using the identity corresponding to the business. During the verification phase, only the identity information required for verification of the business is provided, and the main identity is not used to access each service, and the full identity information is not provided during the verification phase. In this way, the user has specific autonomy and control over the identity, which can ensure that each service provider can only obtain the part of the identity information required for verification by the service provider, and cannot obtain the user's complete identity information, thereby ensuring the security of the user's identity information.

[0096] The following describes the solutions provided by the embodiments of the present application. The solutions provided by the embodiments of the present application may include an identity registration phase and an identity usage phase. The following describes various solutions provided by the embodiments of the present application from these two aspects.

[0097] 1. Identity Registration Phase — Option 1

[0098] See Figure 5 , which is a flow chart of an information management method provided in an embodiment of the present application, is described as follows.

[0099] 501. A first device generates a first secret key (SK) and a first public key (PK).

[0100] In one possible embodiment, the first device can randomly generate a first private key and a first public key corresponding to the first private key. In this embodiment, the embodiment of the present application does not limit the specific method of generating the first private key. Any method that can generate the first private key and the first public key corresponding to the first private key can be adopted in the embodiment of the present application. In this embodiment, the first private key and the public key related to the first private key can also be generated based on certain information, so that the first private key and the first public key can be generated based on the certain information and a pre-selected key generation algorithm. For example, certain information includes but is not limited to a password set by the user, the user's ID number, and the user's medical insurance account number. In this embodiment, the first device can always save the first private key, such as storing the first private key in a private space of the first device. When the first device needs to use the first private key, it obtains the first private key from the private space. Alternatively, in this embodiment, the first device may not save the first private key. When the first device needs to use the first private key, it generates the first private key based on the above-mentioned certain information provided by the user and the selected key generation algorithm and then uses it.

[0101] In another possible implementation, the first device obtains a user's biometrics and generates a first private key and a first public key corresponding to the first private key based on the user's biometrics. The user's biometrics include, but are not limited to, fingerprint information and iris information. In this implementation, the first device does not need to store the first private key. When the first device needs to use the first private key, it can first obtain the user's biometrics and then generate the first private key based on the user's biometrics. Since the first device does not need to store the first private key, the security of the first private key is enhanced. Even if the first device is lost, no one other than the user can obtain the first device's private key.

[0102] In a preferred embodiment, the first device can be a smartwatch, smart ring, smart glasses, smart bracelet, or other personal smart device. In most scenarios, users carry these personal smart devices with them. In this embodiment, the user's primary identity information is stored in these personal smart devices, allowing the user to better control the primary identity information.

[0103] 502. The first device registers a decentralized identity (DID) using the first public key.

[0104] DID allows individuals or organizations to fully own, manage, and control their digital identities and their data. Compared to traditional PKI-based identity systems, blockchain-based DID digital identity systems offer advantages such as guaranteed data authenticity, user privacy, and portability.

[0105] In some embodiments, a DID can be a unique identifier that indicates a mapping relationship between a real entity and an online entity. The DID may include a URL scheme identifier, an identifier for a DID method, and a DID method-specific identifier. Each DID may point to a corresponding DID document. The DID document may include descriptive text in a preset format (e.g., JSON-LD) about the DID and the owner of the DID. The DID may be used as a uniform resource identifier (URI) for locating a DID document. The DID document may include various attributes, such as context, DID subject, public key, authentication, authorization and delegation, service endpoint, creation, update, proof, extensibility, other suitable attributes, or any combination thereof. The DID document may define or point to a resource that defines multiple operations that can be performed relative to the DID.

[0106] Verifiable Claims (VCs) allow for authorization, endorsement, and confirmation between different entities. In a commercial environment, service or product providers can use their customers’ DIDs and VCs to identify and authenticate customers and provide services or products accordingly.

[0107] In some embodiments, a VC can provide verifiable online information about the qualities, characteristics, relationships, and other relevant information of an entity. The VC can contain descriptive text in a preset format (e.g., JSON-LD) that describes one or more claims about the DID (e.g., the age of the DID owner, the educational background of the DID owner) and the entity's endorsement of the claim. The VC can include various attributes, such as context, identity, type, credential subject, issuer, issue date, proof, expiration date, status, representation, other suitable attributes, or any combination thereof. The VC can specify the type of its claim, which can indicate the structure of the claim. This can prompt VC issuers and VC verifiers to automatically process it.

[0108] DID owners can participate in identity management systems in different roles. For example, an individual may wish to use a service provided by a commercial entity that requires proof that they are over 18 years old. This individual could be the DID owner and request a VC issued by a government agency that provides citizen age verification. The commercial entity can verify the VC to ensure that the individual meets age requirements. In this scenario, the individual can be both the DID owner and the VC holder; the government agency can be the VC issuer, and the commercial entity can be the VC verifier.

[0109] In an embodiment of the present application, the DID is registered through the first public key, so that the first public key is bound to a unique DID. After the server obtains the DID, it can query the first public key according to the DID and verify the identity based on the first public key, such as verifying that the received digital signature comes from the first device.

[0110] If different first devices use the same first public key, the DIDs obtained from these multiple devices may be identical. To ensure that each first device has a unique DID, after the first device obtains the DID, the blockchain will also check for duplicates of the obtained DID. If the same DID is not currently stored on the blockchain, the registration is considered successful and the first public key is bound to the unique DID.

[0111] 503. The second device initiates a registration request to the server.

[0112] Users can access a variety of services through a second device, such as shopping services, social services, gaming services, etc. Typically, these services require user registration before they can be accessed, or the service's server will only save the user's data generated during service use after the user has registered. When the user accesses the service using their registered account, they can obtain this data.

[0113] In the solution provided in the embodiments of this application, after the second device initiates a registration request to the server, it does not need to wait for the server to generate an identity for the user (typically a username and password), nor does it need the server to issue the identity to the user. In the solution provided in the embodiments of this application, the second device initiates a registration request to the server in order to obtain the identity information that the server needs to verify. This will be explained in detail in the following steps.

[0114] 504. The second device receives the first information sent by the server.

[0115] After the second device initiates a registration request to the server, the second device receives a first message sent by the server. In one possible implementation, the first message carries the category of identity information that needs to be verified. For example, for gaming services, after the second device initiates a registration request to the gaming server, the category of identity information that needs to be verified in the first message may include age. For another example, for social services, after the second device initiates a registration request to the social server, the category of identity information that needs to be verified in the first message may include ID number, academic qualifications, etc.

[0116] In a possible implementation, the first message may also carry other information, such as a service ID, where each service ID is used to represent a unique service. In other words, there is a one-to-one correspondence between the service ID and the service.

[0117] 505. The second device sends a second message to the first device.

[0118] After the second device receives the first message sent by the server, it obtains the second message according to the first message, and sends the second message to the first device.

[0119] In one possible implementation, the content carried by the second message is completely consistent with the content carried by the first message. For example, if the first message carries the category of identity information that requires verification, the second device forwards the content carried by the first message to the first device via the second message, i.e., the second message also carries the category of identity information that requires verification carried by the first message. For another example, if the first message carries the category of identity information that requires verification and a service identifier, the second device forwards the content carried by the first message to the first device via the second message, i.e., the second message also carries the category of identity information that requires verification and a service identifier carried by the first message.

[0120] In one possible implementation, the content carried in the second message may be part of the content carried in the first message. For example, if the first message carries the category of identity information requiring verification and a service identifier, the second device may send only part of the content carried in the first message to the first device via the second message, such as only sending the category of identity information requiring verification carried in the first message to the first device via the second message.

[0121] It can be understood that the second message must carry the category of the identity information that needs to be verified carried in the first message. In a preferred embodiment, it can also carry a service identifier. In addition, the second message can also carry other information.

[0122] In one possible implementation, the second device may send the second message to the first device via a secure channel. Any secure channel transmission scheme may be adopted in the embodiments of the present application. For example, a secure connection may be established between the first device and the second device, and the second device may send the second message to the second device via a secure network transmission protocol (Transport Layer Security, TLS).

[0123] 506. The first device obtains identity information that needs to be verified for the service.

[0124] According to the category of the identity information that needs to be verified carried in the second message, the identity information corresponding to each category is searched, and the identity information corresponding to each type found constitutes the first identity information. For example, the first device stores all the user's identity information, including but not limited to name, date of birth, address, education level, medical records, income, etc. When the category indication of the identity information that needs to be verified carried in the second message includes name and date of birth, the first device obtains the information corresponding to the name and date of birth from all the identity information. Assuming that the user's name is Zhang San and the date of birth is January 1, 2000, the first identity information may include Zhang San, January 1, 2000, or the first identity information may include name: Zhang San; date of birth: January 1, 2000. The embodiment of the present application does not limit the specific expression of the first identity information.

[0125] 507. The first device obtains the second public key of the second device.

[0126] In a possible implementation, the first device may obtain a pair of public and private keys from another device as the public and private keys of the second device.

[0127] In one possible implementation, the second device may generate a second private key and a second public key corresponding to the second private key. The present embodiment of the application does not limit the method for generating the private key and the public key corresponding to the private key, and this will not be repeated below. In this implementation, after the second device generates the second private key and the second public key, it may send the public key of the second device to the first device.

[0128] In one possible implementation, the first device may randomly generate a pair of public and private keys as the second private key and the second public key of the second device.

[0129] In one possible implementation, the first device can deduce the second private key based on the relevant information, and further can obtain the second public key based on the second private key. In this implementation, the first device can deduce the second private key based on the information that has been obtained, and thus the second private key does not need to be stored in the first device. For example, in one possible implementation, the first private key can be deduced based on the first identity information, the first public key and the service identifier obtained through the above steps. Specifically, the first identity information, the first public key and the service identifier can be used as parameters of a key derivation function (KDF), respectively, and the second private key can be obtained according to the value of the KDF, and the second public key corresponding to the second private key can be further obtained based on the second private key.

[0130] 508. The first device establishes a correspondence between the second public key and the first identity information.

[0131] After the first device obtains the second public key and the first identity information, it establishes a binding relationship between the second public key and the first identity information, so that one second public key corresponds to unique first identity information.

[0132] In one possible implementation, if the first device obtains the service identifier, for example, in step 505, the first device obtains the service identifier and can also establish a correspondence between the service identifier and the first identity information. When the first device establishes a correspondence between the service identifier and the first identity information, it is not necessary to establish a correspondence between the second public key and the first identity information.

[0133] 509. The first device encrypts the first identity information according to the first public key.

[0134] In order to increase the security of the first identity information and prevent the first identity information stored on the first device from being easily leaked, the first identity information may be encrypted using the first public key.

[0135] In a possible implementation, the first identity information and the service identifier may be encrypted according to the first public key.

[0136] 510. The first device sends the encrypted first identity information and the first identifier to the blockchain.

[0137] The first identifier may be the second public key or a service identifier.

[0138] The first device can send a digital signature to the blockchain, which contains the encrypted first identity information and the first identifier. After the blockchain verifies that the digital signature originates from the first device using the first device's public key, the blockchain stores the encrypted first identity information in the DID document corresponding to the DID registered by the first device. Each DID identifier corresponds to a DID document.

[0139] A binding relationship is established between the first identifier and the encrypted first identity information in the blockchain. For example, a binding relationship is established between the second public key and the encrypted first identity information, or a binding relationship is established between the business identifier and the encrypted first identity information.

[0140] 511. The second device establishes a binding relationship between the second public key and the service identifier.

[0141] In a possible implementation, the second device may generate a second private key and a second public key. After the second device obtains the first message, a binding relationship between the second public key and the service identifier may be established.

[0142] In one possible embodiment, if the first device generates the second private key and the second public key, the second device receives the second public key and the second private key sent by the first device. In one possible embodiment, the first device can send the second private key and the second public key to the second device through a secure channel, wherein the secure channel is understood with reference to the secure channel described in step 505 and will not be repeated here. In this embodiment, after the second device receives the second public key and the second private key sent by the first device, it establishes a binding relationship between the second public key and the business identifier. Since the second public key and the second private key are in a one-to-one correspondence, it is equivalent to querying the unique second private key based on the business identifier.

[0143] After obtaining the second private key and the second public key, the second device stores the second public key and the second private key, as well as the binding relationship between the second public key and the service identifier.

[0144] 512. The second device sends a third message to the first device.

[0145] After the second device establishes the binding relationship between the second public key and the service identifier, it can send a third message to the first device to enable the first device to obtain the status of the second device. In one possible implementation, the third message can be used to indicate successful registration.

[0146] In a possible implementation, after the first device obtains the third message sent by the second device, the first identity information locally stored on the first device or the first identity information may be deleted.

[0147] In a possible implementation, if the first device generates the first private key based on the biometrics of the user, the first device may delete the locally stored first private key after obtaining the third message.

[0148] In a possible implementation, if the first device generates a second private key and a second public key, the first device may delete the locally stored second private key after obtaining the third message.

[0149] It should be noted that in the above Figure 5On the basis of the described embodiments, the embodiments of the present application may include more or fewer steps. For example, in one possible implementation, the step may also be included: the first device prompts that the registration is successful. After the first device obtains the third message sent by the second device, it may prompt the user that the registration is successful. The embodiments of the present application do not limit the prompt method for successful registration. For example, the user may be prompted that the service / business described in the above steps has been successfully registered. For another example, some steps may not be executed. For example, in one possible implementation, step 502 or step 508 may not be executed. In fact, each embodiment described in the examples of the present application may include more or fewer steps, and this will not be repeated below.

[0150] In addition, it should be noted that in the above Figure 5 Based on the described embodiments, the order of the steps described above can be swapped. For example, step 511 can be performed before steps 506 to 510, or can be performed simultaneously with steps 506 to 510. In fact, the order of the steps in each embodiment described in the examples of this application can be swapped or the steps can be performed simultaneously, and this will not be repeated below.

[0151] Depend on Figure 5 As can be seen in the corresponding embodiment, during the registration phase, different identity information (first identity information) is generated for each service, and the different identity information is bound to different second public keys. This is equivalent to setting up multiple subordinate identities for each primary identity in the embodiment of the present application, and each subordinate identity is used to access a service. This allows the user to obtain the user's complete identity information through the first device, and other devices other than the first device cannot obtain the user's complete identity information, thereby strengthening the privacy protection of the user's identity information.

[0152] Next, let's compare the above Figure 5 The corresponding login process of the described registration process is introduced.

[0153] 2. Identity Usage Phase (also referred to as the Login Phase in this application) - Solution 1

[0154] See Figure 6 , which is a flow chart of an information management method provided in an embodiment of the present application, is described as follows.

[0155] 601. The second device initiates an access request to the server.

[0156] After the second device initiates an access request to the server, the server sends an identity request (IR) message to the second device.

[0157] In one possible embodiment, the IR message carries a service identifier. In one possible embodiment, the IR message carries a service identifier and a server certificate. In one possible embodiment, the IR message carries a service identifier, a server certificate, and an anti-replay verification parameter. For example, the anti-replay verification parameter can be a random number (Nonce). The specific method of the anti-replay verification parameter is not limited in the embodiment of the present application. In one possible embodiment, the anti-replay parameter is a timestamp and / or serial number used to characterize the generation time of the access request. For example, assuming that the IR message sent by the server to the second device includes the server's unique identifier 123 and the timestamp 10:00, then after obtaining the IR message, the second device first verifies the validity of the server's unique identifier 123 and the timestamp 10:00 in the IR message: if the second device determines that the unique identifier 123 actually exists by querying the corresponding unique identifier database, and the timestamp 11:30 is before the current time and within the preset time range, then the second device determines that the server's unique identifier 123 and the timestamp 10:00 of the IR message are valid, that is, the second device determines that the IR message is a valid IR message. Then, the second device continues to execute subsequent steps, such as step 602.

[0158] 602. The second device obtains a second private key according to the service identifier.

[0159] As mentioned above, during the registration phase, the second device obtains the second private key and the second public key, and establishes a binding relationship between the second public key and the service identifier. After the second device obtains the service identifier based on the IR message, it can retrieve the second public key uniquely corresponding to the service identifier based on the binding relationship between the service identifier and the second public key stored on the second device. Since each second public key corresponds to a unique second private key, the second private key can be retrieved based on the second public key uniquely corresponding to the service identifier.

[0160] 603. The second device sends the digital signature and the second public key to the first device.

[0161] The second device generates a digital signature according to the second private key obtained in step 602.

[0162] In a possible implementation, the digital signature carries an IR message. In addition, the second device also sends a public key of the second device to the first device.

[0163] In one possible implementation, the digital signature and the second public key may be sent to the first device via the same message. In one possible implementation, the digital signature and the second public key may be sent to the first device via different messages.

[0164] In one possible implementation, the digital signature and the second public key may be sent to the first device through a secure channel.

[0165] 604. The first device verifies the digital signature.

[0166] The first device receives the digital signature and public key sent by the second device. The first device verifies the digital signature sent by the second device based on the received public key of the second device. The process of verifying the digital signature has been described above and will not be repeated here.

[0167] If the verification is successful, the subsequent steps are continued, such as step 605. If the verification is not successful, the subsequent steps are not executed.

[0168] 605. The first device obtains a first private key.

[0169] In a possible implementation, if the first private key is stored locally on the first device during the registration phase, the first private key is obtained locally from the first device after the first device successfully verifies the digital signature of the second device.

[0170] In one possible implementation, if the first private key is generated using the user's biometrics during the registration phase, the first device obtains the user's biometrics after successfully verifying the second device's digital signature. The first device generates the first private key based on the obtained user's biometrics and may also generate a first public key corresponding to the first private key using the same method as used during the registration phase.

[0171] 606. The first device obtains the encrypted first identity information from the blockchain.

[0172] The first device can send a digital signature to the blockchain, and the digital signature carries the first identifier. The first identifier in the login phase is the same as the first identifier in the registration phase. For example, if the first identifier in the registration phase is a business identifier, then in the login phase, the first device sends a digital signature to the blockchain, and the digital signature carries the business identifier. After the blockchain verifies that the digital signature comes from the first device based on the public key of the first device, the encrypted first identity information corresponding to the business identifier is queried based on the business identifier. For another example, if the first identifier in the registration phase is a second public key, then in the login phase, the first device sends a digital signature to the blockchain, and the digital signature carries the second public key. After the blockchain verifies that the digital signature comes from the first device based on the public key of the first device, the encrypted first identity information corresponding to the second public key is queried based on the second public key.

[0173] After the blockchain queries the encrypted first identity information based on the first identifier, the encrypted first identity information is sent to the first device so that the first device obtains the encrypted first identity information.

[0174] 607. The first device uses the first private key to decrypt the first identity information.

[0175] After the first device obtains the encrypted first identity information from the blockchain, since the first identity information was encrypted using the first public key during the registration phase, during the login phase, the first device can use the first private key corresponding to the first public key to decrypt the encrypted first identity information to obtain the first identity information.

[0176] 608. The first device sends the digital signature to the second device.

[0177] The first device generates a digital signature using the first private key, wherein the digital signature carries the first identity information. In one possible implementation, the digital signature may also carry a service identifier. In one possible implementation, the digital signature may also carry an anti-replay parameter.

[0178] The first device sends the digital signature to the second device. In one possible implementation, after the first device sends the digital signature to the second device and sends the first identity information to the second device, the first identity information, the first public key, and the service identifier stored locally on the first device can be deleted.

[0179] 609. The second device forwards the digital signature to the server.

[0180] In a possible implementation, the second device may not verify the digital signature, but only forward the acquired digital signature to the server.

[0181] In one possible implementation, after the second device obtains the digital signature sent by the first device, it can verify the first digital signature using the public key of the first device. After the verification is successful, that is, after confirming that the digital signature comes from the first device, it sends the digital signature to the server.

[0182] 610. The server verifies the digital signature using the first public key.

[0183] The server verifies the received digital signature through the public key of the first device. How to verify the digital signature has been introduced above and will not be repeated here.

[0184] In one possible implementation, the server may query the DID of the first device from the blockchain, and obtain the public key of the first device based on the DID uniquely corresponding to the first device.

[0185] 611. After the server verification is successful, the second device is allowed to access the server.

[0186] After the server successfully verifies and determines that the digital signature is indeed issued by the first device, the second device is allowed to access the server, that is, the second device is allowed to use the corresponding service / business.

[0187] In a possible implementation, the server may further send a notification message of successful identity authentication to the second device or the first device.

[0188] In one possible implementation, if the verification fails, the second device is not allowed to access the server.

[0189] Depend on Figure 6 It can be seen from the corresponding embodiments that, during the identity usage stage, each server can only obtain the identity information that the server needs to verify, but cannot obtain all the identity information of the user, which increases the privacy and security of the user's identity. In addition, the solution provided by the embodiment of the present application can easily revoke the second public key to ensure the security of the user's identity information. For example, after the second device is lost, the first device can set the public key of the second device to be invalid, and the second device can no longer request the first device to send identity information based on the previous public key of the second device. In addition, the first device can regenerate a new second public key and establish a binding relationship with the new second device. In addition, the solution provided by the embodiment of the present application can generate a first private key based on the user's biometrics, and the first private key does not need to be stored in the first device, which further increases the security of the identity information. In addition, the public key of the second device is stored on the second device, which is convenient for authentication and use at any time.

[0190] It should be noted that in the above Figure 6 Based on the described embodiments, more or fewer steps may be included. Figure 6 Based on the described embodiments, the order of the steps described above may be swapped, or they may be executed simultaneously.

[0191] In the above Figure 5 and Figure 6 In the described scheme, the encrypted first identity information is stored in the blockchain. In some other implementations, the encrypted first identity information can also be stored in the first device or the second device. This is introduced below in conjunction with specific implementations.

[0192] 1. Identity Registration Phase - Option 2

[0193] See Figure 7 , which is a flow chart of an information management method provided in an embodiment of the present application, is described as follows.

[0194] 701. A first device generates a first private key and a first public key.

[0195] 702. The first device registers the DID using the first public key.

[0196] 703. The second device initiates a registration request to the server.

[0197] 704. The second device receives the first information sent by the server.

[0198] 705. The second device sends a second message to the first device.

[0199] 706. The first device obtains identity information that needs to be verified for the service.

[0200] 707. The first device obtains the second public key of the second device.

[0201] 708. The first device establishes a correspondence between the second public key and the first identity information.

[0202] 709. The first device encrypts the first identity information according to the first public key.

[0203] Steps 701 to 709 can refer to Figure 5 Steps 501 to 509 in the corresponding embodiment can be understood and will not be repeated here.

[0204] 710. The first device stores the encrypted first identity information.

[0205] Different from Figure 5 In the described embodiment, the encrypted first identity information is stored in the blockchain. Figure 7 In the described implementation, the first device locally stores the encrypted first identity information, saving storage resources and communication resources of the blockchain.

[0206] The first device establishes a binding relationship between the first identifier and the encrypted first identity information. The first identifier can be the second public key or the service identifier. For example, a binding relationship is established between the second public key and the encrypted first identity information, or between the service identifier and the encrypted first identity information.

[0207] 711. The first device registers the DID using the second public key.

[0208] If different second devices use the same second public key, or if the same public key is bound to multiple different services on a second device, the same second public key may be bound to different first identities. This can cause confusion during the login phase, for example, causing the first device to mistakenly send its first identity to the second device, leading to server verification failure. For example, a first device has two corresponding second devices: second device A and second device B. If second device A's public key is second public key A, and second device B's public key is second public key B, the first identity bound to second public key A is first identity A, and the first identity bound to second public key B is first identity B. During the login phase, after the first device verifies the digital signature based on second public key A and it succeeds, it sends the first identity bound to second public key A to second device A. However, if second public key A and second public key B are the same, the first device may send the first identity bound to second public key B to second device A. If the first identity bound to second public key A and second public key B are different, when second device A sends the first identity bound to second public key B to the server, verification may fail. For example, a second device is registered with two different services, Service A and Service B. Assume that the public key corresponding to Service A is Second Public Key A, and the public key corresponding to Service B is Second Public Key B. The first identity information bound to Second Public Key A is First Identity A, and the first identity information bound to Second Public Key B is First Identity B. During the login phase, after the first device verifies the digital signature based on Second Public Key A and successfully completes it, it sends the first identity information bound to Second Public Key A to the second device. However, if Second Public Key A and Second Public Key B are identical, the first device may send the first identity information bound to Second Public Key B to the second device. If the first identity information bound to Second Public Key A and Second Public Key B are different, when Second Device A sends the first identity information bound to Second Public Key B to the server, verification may fail. For example, if Service A is a gaming service, the first identity information bound to Second Public Key A includes age, while Service B is a financial service, the first identity information bound to Second Public Key B includes income information. Sending income information to Service A's server may cause verification to fail.

[0209] To solve the above problem, the first device uses the second public key to register the DID. The blockchain will also check the obtained DID for duplication. If the same DID has not been stored on the current blockchain, the registration is considered successful and the second public key is bound to a unique DID.

[0210] 712. The second device establishes a binding relationship between the second public key and the service identifier.

[0211] 713. The second device sends a third message to the first device.

[0212] Step 712 and step 713 can refer to Figure 5 The steps 511 and 512 in the corresponding embodiments can be understood and will not be repeated here.

[0213] 2. Identity Use Phase (also referred to as the Login Phase in this application) - Solution 2

[0214] See Figure 8 , which is a flow chart of an information management method provided in an embodiment of the present application, is described as follows.

[0215] 801. The second device initiates an access request to the server.

[0216] 802. The second device obtains a second private key according to the service identifier.

[0217] 803. The second device sends the digital signature and the second public key to the first device.

[0218] 804. The first device verifies the digital signature.

[0219] 805. The first device obtains a first private key.

[0220] Steps 801 to 805 can refer to Figure 6 Steps 601 to 605 in the corresponding embodiment can be understood and will not be repeated here.

[0221] 806. The first device obtains the encrypted first identity information locally.

[0222] The first device queries local storage according to the first identifier to obtain the encrypted first identity information.

[0223] The first identifier in the login phase is the same as the first identifier in the registration phase. For example, if the first identifier in the registration phase is a service identifier, then in the login phase, the first device queries the encrypted first identity information corresponding to the service identifier based on the service identifier. For another example, if the first identifier in the registration phase is a second public key, then in the login phase, the first device queries the encrypted first identity information corresponding to the second public key based on the second public key.

[0224] 807. The first device decrypts the first identity information using the first private key.

[0225] 808. The first device sends the digital signature to the second device.

[0226] 809. The second device forwards the digital signature to the server.

[0227] 810. The server verifies the digital signature using the first public key.

[0228] 811. After the server verification is successful, the second device is allowed to access the server.

[0229] Steps 807 to 811 can refer to Figure 6 Steps 607 to 611 in the corresponding embodiment can be understood and will not be repeated here.

[0230] It should be noted that in the above Figure 7 and Figure 8 Based on the described embodiments, more or fewer steps may be included. Figure 7 and Figure 8 Based on the described embodiments, the order of the steps described above may be swapped, or they may be executed simultaneously.

[0231] In the above Figure 7 and Figure 8 The described scheme has, in addition to Figure 5 and Figure 6 In addition to the advantages of the described embodiment, the encrypted first identity information is stored on the first device, saving blockchain storage and communication resources. In some possible implementations, the encrypted first identity information can also be stored on the second device, as described below in conjunction with specific implementations.

[0232] 1. Identity Registration Phase — Option 3

[0233] See Figure 9 , which is a flow chart of an information management method provided in an embodiment of the present application, is described as follows.

[0234] 901. A first device generates a first private key and a first public key.

[0235] 902. The first device registers a DID using the first public key.

[0236] 903. The second device initiates a registration request to the server.

[0237] 904. The second device receives the first information sent by the server.

[0238] 905. The second device sends a second message to the first device.

[0239] 906. The first device obtains identity information that needs to be verified for the service.

[0240] 907. The first device obtains the second public key of the second device.

[0241] 908. The first device establishes a correspondence between the second public key and the first identity information.

[0242] 909. The first device encrypts the first identity information according to the first public key.

[0243] Steps 901 to 909 can refer to Figure 7 Steps 701 to 709 in the corresponding embodiment can be understood and will not be repeated here.

[0244] 910. The first device registers the DID using the second public key.

[0245] Step 910 can refer to Figure 7 The corresponding step 711 in the embodiment can be understood and will not be repeated here.

[0246] 911. The second device obtains the encrypted first identity information and the second public key.

[0247] In one possible implementation, the second device may generate the second private key and the second public key. In one possible implementation, if the first device generates the second private key and the second public key, the second device receives the second public key and the second private key sent by the first device. In one possible implementation, the first device may send the second private key and the second public key to the second device via a secure channel. The secure channel is understood with reference to the secure channel described in step 505 and will not be repeated here.

[0248] The second device obtains the encrypted first identity information from the first device. In one possible implementation, the first device may send the encrypted first identity information to the second device via a secure channel. In one possible implementation, the first device may send the encrypted first identity information, the second private key, and the second public key to the second device via the same message. In another possible implementation, the first device may send the encrypted first identity information, the second private key, and the second public key to the second device via different messages.

[0249] After receiving the encrypted first identity information and the second public key, the second device saves the encrypted first identity information, the second public key, and the second private key.

[0250] 912. The second device establishes a binding relationship between the second public key and the service identifier, and establishes a binding relationship between the second public key and the first identity information.

[0251] After the second device establishes a binding relationship between the second public key and the service identifier, since the second public key and the second private key are in a one-to-one correspondence, it is equivalent to being able to query the unique second private key according to the service identifier.

[0252] The second device obtains the second public key bound to the service identifier, and can then obtain the first identity information bound to the second public key.

[0253] In a possible implementation, a binding relationship between the service identifier and the first identity information may also be established. After the second device obtains the service identifier, it may directly obtain the encrypted first identity information bound to the service identifier.

[0254] exist Figure 9 In the described implementation, the second device locally stores the encrypted first identity information. Since the second device is usually a mobile phone with higher security performance, storing the encrypted first identity information in the mobile phone can improve the security of the identity information.

[0255] 913. The second device sends a third message to the first device.

[0256] Step 913 can refer to Figure 5 The corresponding step 512 in the embodiment can be understood and will not be repeated here.

[0257] 2. Identity Use Phase (also referred to as the Login Phase in this application) — Solution 3

[0258] See Figure 10 , which is a flow chart of an information management method provided in an embodiment of the present application, is described as follows.

[0259] 1001. The second device initiates an access request to the server.

[0260] 1002. The second device obtains a second private key according to the service identifier.

[0261] Steps 1001 to 1002 can refer to Figure 6 The steps 601 and 602 in the corresponding embodiments can be understood and will not be repeated here.

[0262] 1003. The second device sends the digital signature and the second public key to the first device.

[0263] The second device generates a digital signature based on the second private key obtained in step 602. The digital signature carries the IR message and the encrypted first identity information. In addition, the second device also sends the public key of the second device to the first device.

[0264] Specifically, after obtaining the service identifier, the second device can obtain the encrypted first identity information bound to the public key based on the second public key bound to the service identifier. If a binding relationship between the service identifier and the encrypted first identity information was established during the registration phase, then after obtaining the service identifier, the second device can directly obtain the encrypted first identity information bound to the service identifier based on the service identifier.

[0265] In one possible implementation, the digital signature and the second public key may be sent to the first device via the same message. In one possible implementation, the digital signature and the second public key may be sent to the first device via different messages.

[0266] In one possible implementation, the digital signature and the second public key may be sent to the first device through a secure channel.

[0267] 1004. The first device verifies the digital signature.

[0268] 1005. The first device obtains a first private key.

[0269] Step 1004 and step 1005 can refer to Figure 6 The steps 604 and 605 in the corresponding embodiments can be understood and will not be repeated here.

[0270] 1006. The first device decrypts the first identity information using the first private key.

[0271] After obtaining the encrypted first identity information from the second device, the first device decrypts the encrypted first identity information using the first private key to obtain the first identity information.

[0272] 1007. The first device sends a digital signature to the second device.

[0273] 1008. The second device forwards the digital signature to the server.

[0274] 1009. The server verifies the digital signature using the first public key.

[0275] 1010. After the server verification is successful, the second device is allowed to access the server.

[0276] Steps 1007 to 1010 can refer to Figure 6 Steps 608 to 611 in the corresponding embodiment can be understood and will not be repeated here.

[0277] In the above Figure 9 and Figure 10 The described scheme has, in addition to Figure 5 and Figure 6In addition to the advantages described in the described embodiment, the encrypted first identity information is stored in the second device. Since the second device is usually a mobile phone, it has higher security performance. Storing the encrypted first identity information in the mobile phone can improve the security of the identity information.

[0278] above Figures 5 to 10 In the described embodiments, public-private key pairs are utilized during the identity registration and usage phases. For example, a first private key, a first public key corresponding to the first private key, a second private key, and a second public key corresponding to the second private key are introduced. In some embodiments, symmetric encryption can also be used instead of asymmetric encryption. This is described below with reference to specific implementations.

[0279] 1. Identity Registration Phase — Option 4

[0280] See Figure 11 , which is a flow chart of an information management method provided in an embodiment of the present application, is described as follows.

[0281] 1101. A first device generates a first key.

[0282] In one possible implementation, the first device may randomly generate the first private key. In this implementation, the first device may always store the first private key, for example, by storing the first private key in a private space of the first device. When the first device needs to use the first private key, it obtains the first private key from the private space.

[0283] In one possible implementation, the first device obtains the user's biometrics and generates a first key based on them. The user's biometrics include, but are not limited to, fingerprint information and iris information. In this implementation, the first device does not need to store the first key. When the first device needs to use the first key, it can first obtain the user's biometrics and then generate the first key based on them. Because the first device does not need to store the first key, the security of the first private key is enhanced. Even if the first device is lost, no one other than the user can access the private key of the first device.

[0284] 1102. The first device generates a second key according to an identifier of the first device.

[0285] Each device has a unique corresponding identifier. The embodiments of the present application do not limit the specific expression of the identifier of the first device. For example, the International Mobile Equipment Identity (IMEI) and the Media Access Control Address (MAC) address can be used as the identifier of the first device. Another example is the access network identifier.

[0286] A second key is generated according to the unique identifier corresponding to the first device.

[0287] 1103. The second device initiates a registration request to the server.

[0288] 1104. The second device receives the first information sent by the server.

[0289] Step 1103 and step 1104 can refer to Figure 5 The steps 503 and 504 in the corresponding embodiments can be understood and will not be repeated here.

[0290] 1105. The second device generates a third key according to the service identifier.

[0291] If the second device generates the third key according to the service identifier, the second device establishes a binding relationship between the service identifier and the third key.

[0292] 1106. The second device sends a target message to the first device.

[0293] The target message carries the category of identity information requiring verification and the third key. For example, for gaming services, after the second device initiates a registration request to the gaming server, the category of identity information required for verification carried in the first message might include age. For another example, for social services, after the second device initiates a registration request to the social server, the category of identity information required for verification carried in the first message might include ID number, educational background, etc.

[0294] In one possible implementation, the target message carries the category of the identity information to be verified and the service identifier. In this implementation, step 1105 may be omitted, and the first device may generate the third key based on the service identifier. If the first device generates the third key based on the service identifier, the first device establishes a binding relationship between the service identifier and the third key.

[0295] In a possible implementation, the target message may carry the category of identity information to be verified, a service identifier, and a third key.

[0296] 1107. The first device obtains the target key.

[0297] The first device synthesizes the target key according to the first key, the second key and the third key. The embodiment of the present application does not limit the specific method and the target key, but only needs to ensure that the target key is synthesized according to the first key, the second key and the third key.

[0298] 1108. The first device obtains first identity information.

[0299] The first device obtains the identity information required for verification of the service. Step 1108 can refer to Figure 5 The above steps can be understood from step 506 in the corresponding embodiment and will not be repeated here.

[0300] 1109. The first device encrypts the first identity information according to the target key.

[0301] 1110. The first device establishes a binding relationship.

[0302] In a possible implementation, the first device establishes a binding relationship between the third key and the encrypted first identity information.

[0303] In a possible implementation, the first device establishes a binding relationship between the target key and the encrypted first identity information.

[0304] In a possible implementation, the first device establishes a binding relationship between the service identifier and the encrypted first identity information.

[0305] 1111. The first device notifies the second device that the first identity information has been encrypted using the target key.

[0306] 1112. The second device sends feedback information to the first device.

[0307] After obtaining that the first device has encrypted the first identity information using the target key, the second device may send a feedback message to the first device to notify the second device that the message sent by the first device has been received (step 1110).

[0308] In a possible implementation, after the first device obtains the feedback message sent by the second device, it may delete the first key, the second key, the third key, and the target key.

[0309] In one possible implementation, the first device may prompt the user that the registration is successful.

[0310] 2. Identity Usage Phase (also referred to as the Login Phase in this application) — Solution 4

[0311] See Figure 12 , which is a flow chart of an information management method provided in an embodiment of the present application, is described as follows.

[0312] 1201. The second device initiates an access request to the server.

[0313] Step 1201 can refer to Figure 6 The corresponding step 601 in the embodiment can be understood and will not be repeated here.

[0314] 1202. The second device obtains a third key according to the service identifier.

[0315] Figure 11 The corresponding embodiment introduces that, during the registration phase, the second device establishes a binding relationship between the third key and the service identifier, so after the second device obtains the service identifier, it can obtain the third key bound to the service identifier.

[0316] 1203. The second device sends an IR message and a third key to the first device.

[0317] In a possible implementation, if the third key is generated by the first device during the registration phase, the second device may only send an IR message to the first device, and the first device may generate the third key according to the service identifier.

[0318] In a possible implementation, the second device may send an IR message and the third key to the first device through a secure channel.

[0319] 1204. The first device obtains a first key and a second key.

[0320] The first device obtains the user's biometric features and generates a first key based on the user's biometric features. The first device obtains the first device's identifier and obtains the second key based on the first device's identifier. Obviously, the user's biometric features are the same as those used during the registration phase, and the identifier is the same as the identifier used during the registration phase. This embodiment of the application will not be further explained.

[0321] 1205. The first device obtains the target key.

[0322] The first device synthesizes a target key from the first key, the second key, and the third key in the same manner as in the registration phase.

[0323] In one possible implementation, the third key may be obtained by the first device according to the service identifier, or the third key may be generated by the second device according to the service identifier and then sent to the first device.

[0324] 1206. The first device obtains the encrypted first identity information.

[0325] In one possible implementation, if the first device establishes a binding relationship between the third key and the encrypted first identity information during the registration phase, then during the login phase, the first device may search for the encrypted first identity information bound to the third key based on the obtained third key.

[0326] In one possible implementation, if the first device establishes a binding relationship between the target key and the encrypted first identity information during the registration phase, then during the login phase, the first device may search for the encrypted first identity information bound to the target key based on the target key.

[0327] In one possible implementation, if the first device establishes a binding relationship between the service identifier and the encrypted first identity information during the registration phase, then during the login phase, the first device may search for the encrypted first identity information bound to the service identifier based on the service identifier.

[0328] 1207. The first device decrypts the first identity information using the target key.

[0329] 1208. The first device sends the first identity information encrypted by the public key of the server to the second device.

[0330] In a possible implementation, after the first device completes step 1207 or step 1208, it may delete the first key, the second key, the third key, and the target key.

[0331] 1209. The second device sends the first identity information encrypted by the public key of the server to the server.

[0332] 1210. The server decrypts the first identity information encrypted by the server's public key using the server's private key and verifies the information.

[0333] 1211. After the server verification is successful, the second device is allowed to access the server.

[0334] Figures 5 to 10 The described embodiments are all solutions designed based on the public key system. When applied, they may require relatively high computing power of the device and relatively high power consumption. Figure 11 and Figure 12 The described embodiment uses a symmetric key-based solution that requires relatively low computing power on the device and has relatively limited functionality. Figure 11 and Figure 12 The described embodiment uses the first device's own identity as part of the key to synthesize a symmetric key, completing a strong binding between the device and the user's key, and providing better security. At the same time, symmetric keys are simple to implement and the technology is mature.

[0335] The above describes in detail the system and method provided by the present application. The following describes the device provided by the present application.

[0336] See Figure 13 , a structural schematic diagram of a second device provided in this application.

[0337] The second device includes:

[0338] The transceiver module 1301 is used to initiate a registration request to the server.

[0339] The transceiver module 1301 is further configured to receive a first message sent by the server in response to a registration request, where the first message carries the type of information that needs to be verified for the first service and an identifier of the first service.

[0340] The processing module 1303 is configured to establish a binding relationship between the public key of the second device and the identifier of the first service.

[0341] The transceiver module 1301 is also used to send the type of information that needs to be verified for the first business to the first device, so that the first device obtains the information that needs to be verified for the first business from the information locally stored in the first device according to the type of information that needs to be verified for the first business. There is a binding relationship between the information that needs to be verified for the first business and the public key of the second device.

[0342] In one possible implementation, the transceiver module 1301 is further configured to receive the encrypted first service verification information sent by the first device. The processing module 1303 is further configured to establish a binding relationship between the encrypted first service verification information and the public key of the second device.

[0343] In one possible embodiment, the transceiver module 1301 is further used to receive the private key of the second device and the public key of the second device sent by the first device. The transceiver module 1301 is used to initiate an access request to the server. The transceiver module 1301 is further used to receive an identity request IR message sent by the server in response to the access request, and the IR message carries the identifier of the first service. The processing module 1303 is used to search for the public key of the second device bound to the first service identifier based on the identifier of the first service. The processing module 1303 is further used to generate a digital signature of the second device using the private key of the second device corresponding to the public key of the second device. The transceiver module 1301 is further used to send the digital signature of the second device and the public key of the second device to the first device, so that the first device verifies that the digital signature of the second device comes from the second device, and then obtains the information that needs to be verified for the first service bound to the public key of the second device.

[0344] In one possible implementation, transceiver module 1301 is configured to initiate a registration request to a server. Transceiver module 1301 receives a first message from the server, the first message carrying the type of information requiring verification for a first service and an identifier of the first service. Transceiver module 1301 is further configured to send the type of information requiring verification for the first service to a second device.

[0345] In a possible implementation, the processing module 1303 is further configured to generate a third key according to the identifier of the first service, and establish a binding relationship between the third key and the identifier of the first service.

[0346] In a possible implementation, a storage module 1302 is further included, configured to store data acquired by the transceiver module.

[0347] See Figure 14 , a structural schematic diagram of a first device provided in this application.

[0348] The first device includes:

[0349] The transceiver module 1401 is used to obtain the type of information that needs to be verified for the first business from the second device, and according to the type of information that needs to be verified for the first business, obtain the information that needs to be verified for the first business from the storage module 1402 of the first device. There is a binding relationship between the information that needs to be verified for the first business and the public key of the second device.

[0350] In a possible implementation, the device further includes a processing module 1403 configured to establish a binding relationship between the information requiring verification for the first service and the public key of the second device.

[0351] In a possible implementation, the processing module 1403 is further configured to encrypt information that needs to be verified for the first service according to the public key of the first device.

[0352] In one possible implementation, the transceiver module 1401 is further used to send the encrypted information that needs to be verified for the first business to the blockchain node, so that the blockchain node establishes a binding relationship between the encrypted information that needs to be verified for the first business and the public key of the second device.

[0353] In a possible implementation, the transceiver module 1401 is further configured to send the encrypted information requiring verification of the first service to the second device, so that the second device establishes a binding relationship between the encrypted information requiring verification of the first service and the public key of the second device.

[0354] In a possible implementation, the processing module 1403 is further configured to: after the first device sends the encrypted information requiring verification of the first service, delete the encrypted information requiring verification of the first service stored locally on the first device.

[0355] In a possible implementation, the processing module 1403 is further configured to generate a private key of the first device according to the biometric characteristics of the user.

[0356] In a possible implementation, the processing module 1403 is further configured to: register a decentralized identity DID using the public key of the first device.

[0357] In one possible implementation, the processing module 1403 is further configured to generate a private key and a public key of the second device. The transceiver module 1401 is further configured to send the private key and the public key of the second device to the second device.

[0358] In one possible implementation, the transceiver module 1401 is further configured to obtain the identifier of the first service from the second device. The processing module 1403 is specifically configured to generate a private key of the second device based on the identifier of the first service, information to be verified by the first service, and the private key of the first device.

[0359] In one possible implementation, processing module 1403 is further configured to verify that the digital signature of the second device originates from the second device and then obtain information that needs to be verified for the first service, which is bound to the public key of the second device. Processing module 1403 is further configured to generate a digital signature of the first device based on the private key of the first device, where the digital signature carries the information that needs to be verified for the first service.

[0360] In one possible implementation, the processing module 1403 is specifically used to: after verifying that the digital signature of the second device comes from the second device, obtain the encrypted information that needs to be verified for the first business and is bound to the public key of the second device from the blockchain node, and decrypt the encrypted information that needs to be verified for the first business according to the private key of the first device to obtain the information that needs to be verified for the first business.

[0361] In one possible implementation, the processing module 1403 is specifically used to verify that the digital signature of the second device comes from the second device, obtain the encrypted information that needs to be verified for the first business and is bound to the public key of the second device from the second device, and decrypt the encrypted information that needs to be verified for the first business according to the private key of the first device to obtain the information that needs to be verified for the first business.

[0362] In one possible implementation, the processing module 1403 is specifically used to, after the first device verifies that the digital signature of the second device comes from the second device, obtain the encrypted information that needs to be verified for the first business from the local first device, and decrypt the encrypted information that needs to be verified for the first business according to the private key of the first device to obtain the information that needs to be verified for the first business.

[0363] In a possible implementation, the processing module 1403 is further configured to delete the private key of the first device and the information that needs to be verified for the first service after the transceiver module 1401 sends the digital signature of the first device.

[0364] In one possible implementation, the processing module 1403 is further configured to obtain a biometric feature of the user after verifying that the digital signature of the second device comes from the second device, and generate a private key of the first device based on the biometric feature.

[0365] In one possible implementation, transceiver module 1401 is further configured to obtain the type of information required for verification by the first service from the second device, and based on the type of information required for verification by the first service, obtain the information required for verification by the first service from information locally stored on the first device. The information required for verification by the first service is bound to a target key, where the target key is generated based on a first key, a second key, and a third key, where the first key is generated based on a biometric characteristic of the user obtained by the first device, the second key is generated based on an identifier of the first device, and the third key is generated based on an identifier of the first service. Processing module 1403 is further configured to encrypt the information required for verification by the first service based on the target key.

[0366] In a possible implementation, the processing module 1403 is further configured to delete the first key, the second key, the third key, and the target key.

[0367] In a possible implementation, the processing module 1403 is further configured to generate a third key according to the identifier of the first service, and establish a binding relationship between the third key and the identifier of the first service.

[0368] In one possible embodiment, the transceiver module 1401 is further used to obtain the identifier of the first service from the second device. The processing module 1403 is further used to generate a target key based on the first key, the second key and the third key, wherein the first key is a key generated based on the biometric characteristics of the user obtained by the first device, the second key is a key generated based on the identifier of the first device, and the third key is a key generated based on the identifier of the first service. The processing module 1403 is further used to decrypt the encrypted information that needs to be verified for the first service according to the target key, and obtain the information that needs to be verified for the first service. The processing module 1403 is also used to encrypt the information that needs to be verified for the first service according to the public key of the server, so that the server obtains the information that needs to be verified for the first service after decrypting it according to the private key of the server.

[0369] See also Figure 15 , a structural schematic diagram of another second device provided in this application is described as follows.

[0370] The second device may include a processor 1501 and a memory 1502. The processor 1501 and the memory 1502 are interconnected via a line. The memory 1502 stores program instructions and data.

[0371] The memory 1502 stores the aforementioned Figure 5-Figure 12 The program instructions and data corresponding to the steps in .

[0372] Processor 1501 is used to execute the above Figure 5-Figure 12 The method steps are performed by the second device shown in any embodiment.

[0373] The transceiver 1503 is used to receive or send data.

[0374] Optionally, the aforementioned Figure 15 The home device shown in can be a chip.

[0375] See also Figure 16 , a structural schematic diagram of another first device provided in this application is described as follows.

[0376] The first device may include a processor 1601 and a memory 1602. The processor 1601 and the memory 1602 are interconnected via a line. The memory 1602 stores program instructions and data.

[0377] The memory 1602 stores the aforementioned Figure 5-Figure 12 The program instructions and data corresponding to the steps in .

[0378] Processor 1601 is used to execute the above Figure 5-Figure 12 The method steps are performed by the first device shown in any embodiment.

[0379] The transceiver 1603 is used to receive or send data.

[0380] Optionally, the aforementioned Figure 16 The access control node shown in FIG may be a chip.

[0381] See also Figure 17 , the structural diagram of the server provided in this application is as follows.

[0382] The server may include a processor 1701 and a memory 1702. The processor 1701 and the memory 1702 are interconnected via a line. The memory 1702 stores program instructions and data.

[0383] The memory 1702 stores the aforementioned Figure 5-Figure 12 The program instructions and data corresponding to the steps in .

[0384] Processor 1701 is used to execute the above Figure 5-Figure 12 The method steps executed by the server in any embodiment shown in FIG.

[0385] The transceiver 1703 is used to receive or send data.

[0386] Optionally, the aforementioned Figure 17 The access control node shown in FIG may be a chip.

[0387] The present application also provides a computer-readable storage medium in which a program is stored. When the program is run on a computer, the computer executes the above-mentioned Figure 5-Figure 12 The illustrated embodiments describe steps in a method.

[0388] The embodiment of the present application also provides an information management device, which can also be called a digital processing chip or chip. The chip includes a processing unit and a communication interface. The processing unit obtains program instructions through the communication interface. The program instructions are executed by the processing unit. The processing unit is used to execute the aforementioned Figure 5-Figure 12 The method steps shown in any embodiment.

[0389] The embodiment of the present application also provides a digital processing chip. The digital processing chip integrates a circuit and one or more interfaces for implementing the above-mentioned processor or the functions of the processor. When the digital processing chip integrates a memory, the digital processing chip can complete the method steps of any one or more embodiments in the above-mentioned embodiments. When the digital processing chip does not integrate a memory, it can be connected to an external memory through a communication interface. The digital processing chip implements the above-mentioned program code stored in the external memory. Figure 5-Figure 12 The method steps shown in any embodiment.

[0390] The present application also provides a computer program product which, when executed on a computer, causes the computer to execute the aforementioned Figure 5-Figure 12 The illustrated embodiments describe steps in a method.

[0391] The information management device provided in the embodiment of the present application may be a chip, which includes: a processing unit and a communication unit. The processing unit may be, for example, a processor, and the communication unit may be, for example, an input / output interface, a pin, or a circuit. The processing unit may execute the computer execution instructions stored in the storage unit to enable the chip in the server to execute the above Figure 5-Figure 12The method described in the embodiment shown. Optionally, the storage unit is a storage unit within the chip, such as a register, a cache, etc. The storage unit may also be a storage unit located outside the chip within the wireless access device, such as a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM), etc.

[0392] Specifically, the aforementioned processing unit or processor may be a central processing unit (CPU), a neural-network processing unit (NPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0393] It should also be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines.

[0394] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus necessary general-purpose hardware, and of course can also be implemented by dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. In general, all functions performed by computer programs can be easily implemented with corresponding hardware, and the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits, or dedicated circuits. However, for the present application, software program implementation is a better implementation method in most cases. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer's floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., including a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0395] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0396] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, a computer, a server, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website, a computer, a server, or a data center. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0397] The terms "first," "second," "third," "fourth," and the like (if any) in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequential sequence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0398] Finally, it should be noted that the above is only a specific implementation method of the present application, but the protection scope of the present application is not limited to this. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be covered by the protection scope of the present application.

Claims

1. A system for identity information management, characterized in that: include: a first device, a second device, and a server; The second device is configured to initiate a registration request to the server; The server is configured to send a first message to the second device in response to the registration request, where the first message carries a type of identity information that needs to be verified for the first service and an identifier of the first service; The second device is further configured to establish a binding relationship between the public key of the second device and the identifier of the first service; The first device is used to obtain the type of identity information that needs to be verified for the first service from the second device, and obtain the identity information that needs to be verified for the first service from the identity information locally stored in the first device based on the type of identity information that needs to be verified for the first service. There is a binding relationship between the identity information that needs to be verified for the first service and the public key of the second device, and the public key of the second device corresponds to the unique identity information that needs to be verified for the first service.

2. The system according to claim 1, wherein: The first device is further configured to encrypt identity information that needs to be verified for the first service according to the public key of the first device.

3. The system according to claim 2, characterized in that The system also includes a blockchain node, The first device is further configured to send the encrypted identity information that needs to be verified for the first service to the blockchain node; The blockchain node is used to establish a binding relationship between the encrypted identity information that needs to be verified by the first business and the public key of the second device.

4. The system according to claim 2, wherein: The first device is further configured to send the encrypted identity information that needs to be verified for the first service to the second device; The second device is further configured to establish a binding relationship between the encrypted identity information that needs to be verified for the first service and the public key of the second device.

5. The system according to claim 3 or 4, characterized in that The first device is further configured to delete the encrypted identity information that needs to be verified for the first service that is locally stored in the first device after sending the encrypted identity information that needs to be verified for the first service.

6. The system according to any one of claims 1 to 4, characterized in that The first device is further configured to obtain a user's biometric characteristics and generate a private key for the first device based on the biometric characteristics.

7. The system according to any one of claims 1 to 4, characterized in that The first device is further used to register a decentralized identity DID using the public key of the first device.

8. The system according to any one of claims 1 to 4, characterized in that The first device is further configured to generate a private key of the second device and a public key of the second device, and send the private key of the second device and the public key of the second device to the second device.

9. The system according to claim 8, characterized in that The first device is further configured to obtain an identifier of the first service from the second device; The first device is specifically configured to generate a private key of the second device according to an identifier of the first service, identity information that needs to be verified by the first service, and a private key of the first device.

10. A system for identity information management, characterized in that: include: a first device, a second device, and a server; The second device is configured to initiate an access request to the server; The server is configured to send an identity request IR message to the second device in response to the access request, where the IR message carries an identifier of the first service; The second device is further configured to search, according to the identifier of the first service, for a public key of the second device bound to the first service identifier; The second device is further configured to generate a digital signature of the second device using a private key of the second device corresponding to the public key of the second device, and send the digital signature of the second device and the public key of the second device to the first device; The first device is configured to verify that the digital signature of the second device comes from the second device, and then obtain identity information that needs to be verified for the first service and is bound to the public key of the second device; The first device is further configured to generate a digital signature of the first device according to the private key of the first device, where the digital signature carries identity information that needs to be verified by the first service; The server is further configured to obtain the digital signature of the first device, verify that the digital signature of the first device comes from the first device, and then obtain identity information required for verification by the first service.

11. The system according to claim 10, wherein: The system also includes a blockchain node; The first device is specifically used to obtain the encrypted identity information that needs to be verified for the first business and is bound to the public key of the second device from the blockchain node, and decrypt the encrypted identity information that needs to be verified for the first business according to the private key of the first device to obtain the identity information that needs to be verified for the first business.

12. The system according to claim 10, wherein: The first device is specifically used to obtain the encrypted identity information that needs to be verified for the first service and is bound to the public key of the second device from the second device, and decrypt the encrypted identity information that needs to be verified for the first service according to the private key of the first device to obtain the identity information that needs to be verified for the first service.

13. The system according to claim 10, wherein: The first device is specifically used to obtain the encrypted identity information that needs to be verified for the first service locally from the first device, and decrypt the encrypted identity information that needs to be verified for the first service according to the private key of the first device to obtain the identity information that needs to be verified for the first service.

14. The system according to any one of claims 10 to 13, characterized in that The first device is further configured to delete the private key of the first device and the identity information required for verification by the first service after sending the digital signature of the first device.

15. The system according to any one of claims 10 to 13, characterized in that The first device is further configured to obtain a user's biometric feature after verifying that the digital signature of the second device comes from the second device, and generate a private key for the first device based on the biometric feature.

16. A system for identity information management, characterized in that: include: a first device, a second device, and a server; The second device is configured to initiate a registration request to the server; The server is configured to send a first message to the second device in response to the registration request, where the first message carries a type of identity information that needs to be verified for the first service and an identifier of the first service; The first device is configured to obtain, from the second device, a type of identity information that needs to be verified for the first service, and obtain, based on the type of identity information that needs to be verified for the first service, the identity information that needs to be verified for the first service from identity information locally stored on the first device, wherein the identity information that needs to be verified for the first service is bound to a target key, where the target key is generated based on a first key, a second key, and a third key, where the first key is a key generated based on a biometric feature of a user obtained by the first device, the second key is a key generated based on an identifier of the first device, and the third key is a key generated based on the identifier of the first service; The first device is further configured to encrypt the identity information that needs to be verified for the first service according to the target key.

17. The system according to claim 16, wherein: The first device is further configured to delete the first key, the second key, the third key, and the target key.

18. The system according to claim 16 or 17, characterized in that The second device is further configured to generate the third key according to the identifier of the first service, and establish a binding relationship between the third key and the identifier of the first service.

19. A system for identity information management, characterized in that: include: a first device, a second device, and a server; The second device is configured to initiate an access request to the server; The server is configured to send an identity request IR message to the second device in response to the access request, where the IR message carries an identifier of the first service; The first device is configured to obtain an identifier of the first service from the second device; The first device is further configured to generate a target key based on a first key, a second key, and a third key, where the first key is a key generated based on a biometric feature of a user acquired by the first device, the second key is a key generated based on an identifier of the first device, and the third key is a key generated based on an identifier of the first service; The first device is further configured to decrypt the encrypted identity information that needs to be verified for the first service according to the target key to obtain the identity information that needs to be verified for the first service; The first device is further configured to encrypt the identity information required for verification of the first service according to the public key of the server, so that the server obtains the identity information required for verification of the first service after decrypting it according to the private key of the server.

20. The system according to claim 19, wherein: The first device is further configured to delete the first key, the second key, the third key, and the target key.

21. The system according to claim 19 or 20, characterized in that The second device is further configured to obtain the third key bound to the identifier of the first service, and send the third key to the first device.

22. A method for identity information management, characterized in that: Applied to an identity information management system, the identity information management system includes a first device, a second device, and a server, and the method includes: The second device initiates a registration request to the server; The second device receives a first message sent by the server in response to the registration request, where the first message carries a type of identity information that needs to be verified for the first service and an identifier of the first service; The second device establishes a binding relationship between the public key of the second device and the identifier of the first service; The second device sends the type of identity information that needs to be verified for the first service to the first device, so that the first device obtains the identity information that needs to be verified for the first service from the identity information locally stored in the first device according to the type of identity information that needs to be verified for the first service. There is a binding relationship between the identity information that needs to be verified for the first service and the public key of the second device, and the public key of the second device corresponds to the unique identity information that needs to be verified for the first service.

23. The method according to claim 22, characterized in that The method further comprises: The second device receives the encrypted identity information required for verification of the first service sent by the first device; The second device establishes a binding relationship between the encrypted identity information that needs to be verified for the first service and the public key of the second device.

24. The method according to claim 22 or 23, characterized in that The method further comprises: The second device receives the private key of the second device and the public key of the second device sent by the first device.

25. A method for identity information management, characterized in that: Applied to an identity information management system, the identity information management system includes a first device, a second device, and a server, and the method includes: The first device obtains the type of identity information that needs to be verified for the first service from the second device, and obtains the identity information that needs to be verified for the first service from the identity information locally stored on the first device based on the type of identity information that needs to be verified for the first service. There is a binding relationship between the identity information that needs to be verified for the first service and the public key of the second device, and the public key of the second device corresponds to the unique identity information that needs to be verified for the first service.

26. The method according to claim 25, characterized in that The method further comprises: The first device establishes a binding relationship between the identity information that needs to be verified for the first service and the public key of the second device.

27. The method according to claim 25, characterized in that The method further comprises: The first device encrypts identity information that needs to be verified for the first service according to the public key of the first device.

28. The method according to claim 27, characterized in that The system further includes a blockchain node, and the method further includes: The first device sends the encrypted identity information that needs to be verified for the first business to the blockchain node, so that the blockchain node establishes a binding relationship between the encrypted identity information that needs to be verified for the first business and the public key of the second device.

29. The method according to claim 27, characterized in that The method further comprises: The first device sends the encrypted identity information that needs to be verified for the first service to the second device, so that the second device establishes a binding relationship between the encrypted identity information that needs to be verified for the first service and the public key of the second device.

30. The method according to claim 28 or 29, characterized in that The method further comprises: After the first device sends the encrypted identity information that needs to be verified for the first service, the first device deletes the encrypted identity information that needs to be verified for the first service that is locally stored.

31. The method according to any one of claims 25 to 29, characterized in that The method further comprises: The first device obtains a biometric characteristic of a user and generates a private key of the first device according to the biometric characteristic.

32. The method according to any one of claims 25 to 29, characterized in that The method further comprises: The first device registers a decentralized identity DID using the public key of the first device.

33. The method according to any one of claims 25 to 29, characterized in that The method further comprises: The first device generates a private key of the second device and a public key of the second device, and sends the private key of the second device and the public key of the second device to the second device.

34. The method according to any one of claims 25 to 29, characterized in that The method further comprises: The first device obtains the identifier of the first service from the second device; The first device generates a private key of the second device, including: The first device generates a private key of the second device according to the identifier of the first service, identity information that needs to be verified by the first service, and the private key of the first device.

35. A second device, characterized in that: Applied to an identity information management system, the identity information management system includes a first device, a second device, and a server, the second device including: The transceiver module is used to initiate a registration request to the server; The transceiver module is further configured to receive a first message sent by the server in response to the registration request, wherein the first message carries a type of identity information that needs to be verified for the first service and an identifier of the first service; a processing module, configured to establish a binding relationship between the public key of the second device and the identifier of the first service; The transceiver module is also used to send the type of identity information that needs to be verified for the first service to the first device, so that the first device obtains the identity information that needs to be verified for the first service from the identity information locally stored in the first device according to the type of identity information that needs to be verified for the first service. There is a binding relationship between the identity information that needs to be verified for the first service and the public key of the second device, and the public key of the second device corresponds to the unique identity information that needs to be verified for the first service.

36. The second device according to claim 35, characterized in that The transceiver module is further configured to receive the encrypted identity information required for verification of the first service sent by the first device; The processing module is further configured to establish a binding relationship between the encrypted identity information that needs to be verified for the first service and the public key of the second device.

37. The second device according to claim 35 or 36, characterized in that The transceiver module is further configured to receive the private key of the second device and the public key of the second device sent by the first device.

38. A first device, characterized in that Applied to an identity information management system, the identity information management system includes the first device, the second device, and a server, the first device including: The transceiver module is used to obtain the type of identity information that needs to be verified for the first business from the second device, and obtain the identity information that needs to be verified for the first business from the storage module of the first device according to the type of identity information that needs to be verified for the first business. There is a binding relationship between the identity information that needs to be verified for the first business and the public key of the second device, and the public key of the second device corresponds to the unique identity information that needs to be verified for the first business.

39. The first device according to claim 38, characterized in that The device further comprises a processing module, configured to: A binding relationship is established between the identity information that needs to be verified for the first service and the public key of the second device.

40. The first device according to claim 39, characterized in that The processing module is further configured to: The identity information required for verification of the first service is encrypted according to the public key of the first device.

41. The first device according to claim 40, characterized in that The system also includes a blockchain node, and the transceiver module is further used to: Send the encrypted identity information that needs to be verified for the first business to the blockchain node, so that the blockchain node establishes a binding relationship between the encrypted identity information that needs to be verified for the first business and the public key of the second device.

42. The first device according to claim 40, characterized in that The transceiver module is further used for: The first device sends the encrypted identity information that needs to be verified for the first service to the second device, so that the second device establishes a binding relationship between the encrypted identity information that needs to be verified for the first service and the public key of the second device.

43. The first device according to claim 41 or 42, characterized in that The processing module is further configured to: After the first device sends the encrypted identity information that needs to be verified for the first service, the first device deletes the encrypted identity information that needs to be verified for the first service that is locally stored.

44. The first device according to any one of claims 39 to 42, characterized in that The processing module is further configured to: A private key of the first device is generated according to the biometric characteristics of the user.

45. The first device according to any one of claims 39 to 42, characterized in that The processing module is further configured to: Register a decentralized identity DID using the public key of the first device.

46. ​​The first device according to any one of claims 39 to 42, characterized in that The processing module is further configured to: generating a private key of the second device and a public key of the second device; The transceiver module is further configured to send the private key of the second device and the public key of the second device to the second device.

47. The first device according to any one of claims 39 to 42, characterized in that The transceiver module is further used for: Obtaining an identifier of the first service from the second device; The processing module is specifically configured to generate a private key for the second device according to an identifier of the first service, identity information that needs to be verified for the first service, and a private key of the first device.

48. A method for identity information management, characterized in that: Applied to an identity information management system, the identity information management system includes a first device, a second device, and a server, and the method includes: The second device initiates an access request to the server; The second device receives an identity request IR message sent by the server in response to the access request, where the IR message carries an identifier of the first service; The second device searches for a public key of the second device bound to the first service identifier according to the first service identifier; The second device uses the private key of the second device corresponding to the public key of the second device to generate a digital signature of the second device, and sends the digital signature of the second device and the public key of the second device to the first device, so that the first device verifies that the digital signature of the second device comes from the second device, and then obtains the identity information that needs to be verified by the first service bound to the public key of the second device.

49. A method for identity information management, characterized in that: Applied to an identity information management system, the identity information management system includes a first device, a second device, and a server, and the method includes: After verifying that the digital signature of the second device comes from the second device, the first device obtains the identity information required for verification by the first service that is bound to the public key of the second device, where the public key of the second device corresponds to the unique identity information required for verification by the first service; The first device generates a digital signature of the first device according to the private key of the first device, where the digital signature carries identity information that needs to be verified by the first service.

50. The method according to claim 49, wherein The system further includes a blockchain node, wherein after the first device verifies that the digital signature of the second device comes from the second device, obtaining identity information that needs to be verified by the first service and is bound to the public key of the second device includes: After the first device verifies that the digital signature of the second device comes from the second device, it obtains the encrypted identity information that needs to be verified for the first business and is bound to the public key of the second device from the blockchain node, and decrypts the encrypted identity information that needs to be verified for the first business according to the private key of the first device to obtain the identity information that needs to be verified for the first business.

51. The method according to claim 49, wherein After the first device verifies that the digital signature of the second device comes from the second device, obtaining identity information that needs to be verified for the first service and is bound to the public key of the second device includes: After the first device verifies that the digital signature of the second device comes from the second device, it obtains the encrypted identity information that needs to be verified for the first business and is bound to the public key of the second device from the second device, and decrypts the encrypted identity information that needs to be verified for the first business according to the private key of the first device to obtain the identity information that needs to be verified for the first business.

52. The method according to claim 49, wherein After the first device verifies that the digital signature of the second device comes from the second device, obtaining identity information that needs to be verified for the first service and is bound to the public key of the second device includes: After the first device verifies that the digital signature of the second device comes from the second device, it obtains the encrypted identity information that needs to be verified for the first business from the first device locally, and decrypts the encrypted identity information that needs to be verified for the first business according to the private key of the first device to obtain the identity information that needs to be verified for the first business.

53. The method according to any one of claims 49 to 52, characterized in that The method further comprises: After the first device sends the digital signature of the first device, the private key of the first device and the identity information required for verification by the first service are deleted.

54. The method according to any one of claims 49 to 52, characterized in that The method further comprises: After verifying that the digital signature of the second device comes from the second device, the first device obtains the user's biometric features and generates a private key for the first device based on the biometric features.

55. A second device, characterized in that Applied to an identity information management system, the identity information management system includes a first device, a second device, and a server, the second device including: A transceiver module, configured to initiate an access request to the server; The transceiver module is further configured to receive an identity request IR message sent by the server in response to the access request, wherein the IR message carries an identifier of the first service; a processing module, configured to search, according to the identifier of the first service, for a public key of the second device bound to the identifier of the first service; The processing module is further configured to generate a digital signature of the second device using a private key of the second device corresponding to the public key of the second device; The transceiver module is also used to send the digital signature of the second device and the public key of the second device to the first device, so that the first device verifies that the digital signature of the second device comes from the second device, and then obtains the identity information that needs to be verified by the first service bound to the public key of the second device.

56. A first device, characterized in that Applied to an identity information management system, the identity information management system includes a first device, a second device, and a server, the first device including: A processing module, configured to verify that the digital signature of the second device comes from the second device, and then obtain identity information that needs to be verified by the first service and is bound to the public key of the second device, where the public key of the second device corresponds to unique identity information that needs to be verified by the first service; The processing module is further configured to generate a digital signature of the first device according to the private key of the first device, wherein the digital signature carries identity information that needs to be verified by the first service.

57. The first device according to claim 56, characterized in that The system also includes a blockchain node, and the processing module is specifically configured to: After verifying that the digital signature of the second device comes from the second device, the encrypted identity information that needs to be verified for the first business and is bound to the public key of the second device is obtained from the blockchain node, and the encrypted identity information that needs to be verified for the first business is decrypted according to the private key of the first device to obtain the identity information that needs to be verified for the first business.

58. The first device according to claim 56, characterized in that The processing module is specifically used to: After verifying that the digital signature of the second device comes from the second device, obtain the encrypted identity information that needs to be verified for the first business and is bound to the public key of the second device from the second device, and decrypt the encrypted identity information that needs to be verified for the first business according to the private key of the first device to obtain the identity information that needs to be verified for the first business.

59. The first device according to claim 56, characterized in that The processing module is specifically used to: After the first device verifies that the digital signature of the second device comes from the second device, it obtains the encrypted identity information that needs to be verified for the first business from the first device locally, and decrypts the encrypted identity information that needs to be verified for the first business according to the private key of the first device to obtain the identity information that needs to be verified for the first business.

60. The first device according to any one of claims 56 to 59, characterized in that The processing module is further configured to: After sending the digital signature of the first device, the transceiver module deletes the private key of the first device and the identity information that needs to be verified by the first service.

61. The first device according to any one of claims 56 to 59, characterized in that The processing module is further configured to: After verifying that the digital signature of the second device comes from the second device, the user's biometric characteristics are obtained, and a private key of the first device is generated based on the biometric characteristics.

62. A second device, characterized in that The method comprises a processor coupled to a memory, wherein the memory stores a program, and when the program instructions stored in the memory are executed by the processor, the method according to any one of claims 22 to 24 or the method according to claim 48 is implemented.

63. A first device, characterized in that The invention comprises a processor coupled to a memory, wherein the memory stores a program, and when the program instructions stored in the memory are executed by the processor, the method according to any one of claims 25 to 34 or the method according to any one of claims 49 to 54 is implemented.

64. A computer-readable storage medium comprising a program, which, when executed by a processing unit, performs the method according to any one of claims 22 to 24, or implements the method according to claim 48.

65. A computer-readable storage medium comprising a program, which, when executed by a processing unit, performs the method according to any one of claims 25 to 34, or implements the method according to any one of claims 49 to 54.

66. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the method according to any one of claims 22 to 24 is implemented, or the method according to claim 48 is implemented.

67. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the method according to any one of claims 25 to 34 is implemented, or the method according to any one of claims 49 to 54 is implemented.

Images