CN115720137B - Information management system, method and device - Google Patents

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

Information management system, method and device

Technical Field

The application relates to the field of artificial intelligence safety, in particular to an image processing method and device.

Background

With the generalization and diversification of network activities, various identities are filling in network space, and management of network identities faces a number of serious problems.

Phenomena such as identity information leakage, network fraud, network bank funds stealing and the like caused by improper network identity management frequently occur, and huge hidden hazards are brought to life and property safety of people. In addition, the digitization of social activities enables personal sensitive identity data to be distributed over a plurality of different network applications, so that more and more enterprises have the role of identity management, and the problems of whether the identity information can be safely and effectively managed, whether the identity management service is trustworthy and the like are brought into wide attention.

Disclosure of Invention

The embodiment of the application provides a system, a method and a device for managing identity information, which aim at different identity information required to be verified for each service, generate different service identities and effectively protect the data privacy and the safety of users.

In view of this, a first aspect of the present application provides a system for identity information management, comprising a first device, a second device, and a server. And the second device is used for initiating a registration request to the server. And the server is used for responding to the registration request and sending a first message to the second equipment, wherein the first message carries the identity information type of the first service to be verified and the identification of the first service. The second device is further configured to establish a binding relationship between a public key of the second device and the identity of the first service. The first device is used for acquiring the identity information type of the first service to be verified from the second device, acquiring the identity information of the first service to be verified from the identity information locally stored in the first device according to the identity information type of the first service to be verified, and binding the identity information of the first service to be verified and the public key of the second device.

In the embodiment of the application, the user grasps the complete identity information of the user through the first equipment, and other equipment except the first equipment cannot acquire the complete identity information of the user, so that the privacy protection of the identity information of the user is enhanced. In addition, the identity information required to be verified is bound with the identity information required to be verified of different businesses through the public key of different second equipment aiming at the difference of the identity information required to be verified of each business. Equivalently, a plurality of subordinate identities are set for each main identity, each subordinate identity corresponding to a public key of the second device, each subordinate identity being used for accessing a service. Each service can only acquire the identity information which needs to be verified, and can not acquire the complete identity information of the user, so that the privacy protection of the identity information of the user is further enhanced.

In a first possible implementation of the first aspect, the system further comprises a blockchain node. The first device is further configured to send the encrypted identity information to the block link to be verified. And the blockchain node is used for establishing a binding relation between the encrypted identity information required to be verified by the first service and the public key of the second device. In such an embodiment, the identity information that the first service needs to verify is maintained on the blockchain node. The block chain link point maintains the identity information to be verified of the first service, so that the identity information to be verified of the first service is guaranteed not to be tampered, and the stability of the scheme is improved.

In a first possible implementation manner of the first aspect, 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 used for establishing a binding relationship between the encrypted identity information required to be verified by the first service and the public key of the second device. In this embodiment, the identity information to be verified of the first service is stored on the second device, so that storage resources and communication resources of the blockchain are saved, and since the second device is usually a mobile phone, the security performance is higher, and the encrypted first identity information is stored in the mobile phone, so that the security of the identity information can be improved.

In a first possible implementation manner of the first aspect, the first device is further configured to delete the identity information to be verified of the encrypted first service stored locally in the first device after sending the identity information to be verified of the encrypted first service. In this embodiment, after the registration is completed, after the identity information that needs to be verified by the encrypted first service is already stored on the second device or the blockchain, the encrypted first service that is locally stored by the first device may be deleted, so as to save the local storage resource of the first device.

In a first possible implementation manner of the first aspect, the first device is further configured to obtain a biometric feature of the user, and generate a private key of the first device according to the biometric feature. In such an embodiment, the private key of the first device may be generated according to the biometric of the user, so that the first device does not need to locally store the private key of the first device, and the first device is not at risk of losing the private key.

In a first possible implementation manner of the first aspect, the first device is further configured to register the decentralized identity DID with a public key of the first device. In this embodiment, in the embodiment of the present application, the DID is registered with the first public key, so that the first public key is bound to the unique DID, and after the server side obtains the DID, the first public key may be queried according to the DID, and the identity may be verified based on the first public key, for example, to verify that the received digital signature is from the first device. If the different first devices use the same first public key, it may result in the DID acquired from the plurality of different first devices being the same. In order to enable each first device to have a unique DID, after the first device acquires the DID, the blockchain may check the acquired DID again, and if the same DID is not stored in the current blockchain, the registration is considered successful, and the first public key is bound to the unique DID.

In a first possible implementation manner 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.

In a first possible implementation manner of the first aspect, the first device is further configured to obtain an identification 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 the identifier of the first service, the identity information that needs to be verified by the first service, and the private key of the first device.

In a 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. And the second device is used for initiating an access request to the server. And the server is used for responding to the access request and sending an Identity Request (IR) message to the second equipment, wherein the IR message carries the identification of the first service. And the second device is also used for searching the public key of the second device bound with the first service identifier according to the identifier of the first service. 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. And the first equipment is used for acquiring the identity information to be verified of the first service bound with the public key of the second equipment after verifying that the digital signature of the second equipment comes from the second equipment. The first device is further configured to generate a digital signature of the first device according to a 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 used for acquiring the digital signature of the first device, and acquiring identity information required to be verified by the first service after verifying that the digital signature of the first device comes from the first device.

In a first possible implementation manner of the second aspect, the system further includes a blockchain node. The first device is specifically configured to obtain, from the blockchain node, identity information to be verified of the encrypted first service bound to the public key of the second device, and decrypt, according to the private key of the first device, the identity information to be verified of the encrypted first service, so as to obtain the identity information to be verified of the first service.

In a first possible implementation manner of the second aspect, the first device is specifically configured to obtain, from the second device, the encrypted identity information that needs to be verified of the first service that is bound to the public key of the second device, and decrypt, according to the private key of the first device, the encrypted identity information that needs to be verified of the first service, so as to obtain the identity information that needs to be verified of the first service.

In a first possible implementation manner of the second aspect, the first device is specifically configured to locally obtain, from the first device, the encrypted identity information that needs to be verified for the first service, and decrypt, according to the private key of the first device, the encrypted identity information that needs to be verified for the first service, so as to obtain the identity information that needs to be verified for the first service.

In a first possible implementation manner of the second aspect, the first device is further configured to delete the private key of the first device and the identity information that needs to be verified by the first service after sending the digital signature of the first device.

In a first possible implementation manner of the second aspect, the first device is further configured to obtain a biometric of the user after verifying that the digital signature of the second device is from the second device, and generate the private key of the first device according to the biometric.

In a third aspect, an embodiment of the present application provides a system for managing identity information, including a first device, a second device, and a server. And the second device is used for initiating a registration request to the server. And the server is used for responding to the registration request and sending a first message to the second equipment, wherein the first message carries the identity information type of the first service to be verified and the identification of the first service. The first device is used for acquiring the type of identity information required to be verified by the first service from the second device, acquiring the identity information required to be verified by the first service from the identity information locally stored in the first device according to the type of the identity information required to be verified by the first service, binding the identity information required to be verified by the first service with a target key, wherein the target key is generated based on a first key, a second key and a third key, the first key is a key generated according to the biological characteristics of a user acquired by the first device, the second key is a key generated according to the identification of the first device, and the third key is a key generated according to the identification of the first service. The first device is further configured to encrypt, according to the target key, identity information that needs to be verified for the first service.

In a first possible implementation manner 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.

In a first possible implementation manner 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.

A fourth aspect of the present application provides an identity information management system, including a first device, a second device, and a server. And the second device is used for initiating an access request to the server. And the server is used for responding to the access request and sending an Identity Request (IR) message to the second equipment, wherein the IR message carries the identification of the first service. The first device is used for acquiring the identification of the first service from the second device. The first device is further configured to generate a target key according to a first key, a second key and a third key, where the first key is a key generated according to a biometric feature of a user acquired by the first device, the second key is a key generated according to an identifier of the first device, and the third key is a key generated according to an identifier of the first service. The first device is further configured to decrypt the encrypted identity information of the first service that needs to be verified according to the target key, and obtain the identity information of the first service that needs to be verified. The first device further encrypts the identity information to be verified of the first service according to the public key of the server, so that the server obtains the identity information to be verified of the first service after decrypting according to the private key of the server.

In a first possible implementation manner 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.

In a first possible implementation manner 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.

In a fifth aspect, the embodiment of the application provides a method for managing identity information, which is applied to an identity information management system. The second device receives a first message sent by the server in response to the registration request, wherein the first message carries the identity information type of the first service to be verified and the identification of the first service. The second device establishes a binding relationship between the public key of the second device and the identity of the first service. The second device sends the identity information type to be verified of the first service to the first device, so that the first device obtains the identity information to be verified of the first service from the identity information locally stored in the first device according to the identity information type to be verified of the first service, and a binding relationship exists between the identity information to be verified of the first service and a public key of the second device.

In a first possible implementation manner of the fifth aspect, the method further includes the step that the second device receives the identity information, which is sent by the first device and needs to be verified, of the encrypted first service. The second device establishes a binding relationship between the encrypted identity information of the first service to be verified and the public key of the second device.

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

In a first possible implementation manner of the fifth aspect, the method 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 that the first device obtains the type of identity information to be verified of a first service from the second device, and obtains the identity information to be verified of the first service from identity information locally stored in the first device according to the type of the identity information to be verified of the first service, and a binding relationship exists between the identity information to be verified of the first service and a public key of the second device.

In a first possible implementation manner of the fifth aspect, the method further includes the first device establishing a binding relationship between identity information that the first service needs to verify and a public key of the second device.

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

In a first possible implementation manner of the fifth aspect, the system further includes a blockchain node, and the method further includes the first device sending the encrypted identity information that needs to be verified for the first service 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 service and a public key of the second device.

In a first possible implementation manner of the fifth aspect, the method further includes the first device sending 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 a public key of the second device.

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

In a first possible implementation manner of the fifth aspect, the method further includes the first device obtaining a biometric of the user and generating a private key of the first device according to the biometric.

In a first possible implementation manner of the fifth aspect, the method further comprises the first device registering the decentralized identity DID with a public key of the first device.

In a first possible implementation manner of the fifth aspect, the method further comprises 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.

In a first possible implementation manner of the fifth aspect, the method further includes the first device obtaining an identification of the first service from the second device. The first device generates a private key of the second device, which comprises the first device generates the private key of the second device according to the identification of the first service, the identity information required to be verified by the first service and the private key of the first device.

A sixth aspect of the embodiment of the application provides a method for managing identity information, which is applied to an identity information management system. The second device receives an Identity Request (IR) message sent by the server in response to the access request, wherein the IR message carries the identification of the first service. And the second device searches the public key of the second device bound with the first service identifier according to the first service identifier. The second device generates a digital signature of the second device by using a private key of the second device corresponding to the public key 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 acquires identity information to be verified of a first service bound with the public key of the second device.

In a first possible implementation manner of the sixth aspect, the method is applied to an identity information management system, and the identity information management system comprises a first device, a second device and a server, and includes that after the first device verifies that a digital signature of the second device comes from the second device, obtaining identity information to be verified of a first service bound with a public key of the second device. The first device generates a digital signature of the first device according to a private key of the first device, wherein the digital signature carries identity information to be verified of the first service.

In a first possible implementation manner of the sixth aspect, the system further includes a blockchain node, after the first device verifies that the digital signature of the second device is from the second device, the first device obtains identity information to be verified of the first service bound to the public key of the second device, including obtaining, after the first device verifies that the digital signature of the second device is from the second device, encrypted identity information to be verified of the first service bound to the public key of the second device from the blockchain node, decrypting the encrypted identity information to be verified of the first service according to the private key of the first device, so as to obtain the identity information to be verified of the first service.

In a first possible implementation manner of the sixth aspect, after the first device verifies that the digital signature of the second device is from the second device, acquiring identity information to be verified of the first service bound to the public key of the second device includes acquiring, after the first device verifies that the digital signature of the second device is from the second device, encrypted identity information to be verified of the first service bound to the public key of the second device from the second device, decrypting the encrypted identity information to be verified of the first service according to the private key of the first device, so as to acquire the identity information to be verified of the first service.

In a first possible implementation manner of the sixth aspect, after the first device verifies that the digital signature of the second device is from the second device, acquiring identity information that needs to be verified of the first service bound to the public key of the second device includes locally acquiring encrypted identity information that needs to be verified of the first service from the first device after the first device verifies that the digital signature of the second device is from the second device, decrypting the encrypted identity information that needs to be verified of the first service according to the private key of the first device, so as to acquire the identity information that needs to be verified of the first service.

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

In a first possible implementation manner of the sixth aspect, the method further includes the steps that after the first device verifies that the digital signature of the second device is from the second device, the biometric of the user is obtained, and the private key of the first device is generated according to the biometric.

The seventh aspect of the embodiment of the application provides a method for managing identity information, which is applied to an identity information management system. The second device receives a first message sent by the server, wherein the first message carries the identity information type of the first service to be verified and the identification of the first service.

An eighth aspect of the present application provides an identity information management method, applied to an identity information management system, where the identity information management system includes a first device, a second device, and a server, where the method includes that the first device obtains a type of identity information that needs to be verified for a first service from the second device, and obtains the identity information that needs to be verified for the first service from identity information locally stored in the first device according to the type of the identity information that needs to be verified for the first service, the identity information that needs to be verified for the first service is bound to a target key, the target key is generated based on a first key, a second key, and a third key, the first key is a key generated according to a biometric feature of a user obtained by the first device, the second key is a key generated according to an identifier of the first device, and the third key is a key generated according to an identifier of the first service. The first device encrypts the identity information to be verified of the first service according to the target key.

A ninth aspect of the embodiment of the present application provides a method for managing identity information, which is applied to an identity information management system, where 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, wherein the IR message carries the identification of the first service. The second device sends an identification of the first service to the first device.

A tenth aspect of the embodiment of the present application provides a method for managing identity information, which is applied to an identity information management system, where the identity information management system includes a first device, a second device, and a server, and the method includes: the first device obtains an identification of the first service from the second device. The first device generates a target key according to a first key, a second key and a third key, the first key is a key generated according to the biological characteristics of a user acquired by the first device, the second key is a key generated according to the identification of the first device, and the third key is a key generated according to the identification of the first service. The first device decrypts the encrypted identity information of the first service to be verified according to the target key so as to acquire the identity information of the first service to be verified. The first device encrypts the identity information to be verified of the first service according to the public key of the server, so that the server obtains the identity information to be verified of the first service after decrypting according to the private key of the server.

In an eleventh aspect, an embodiment of the present application provides a second device having a function of implementing the second device in the method described in the fifth aspect, the seventh aspect, or the ninth aspect. The functions can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above.

In a twelfth aspect, an embodiment of the present application provides a first device, where the second device has a function of implementing the first device in the method described in the sixth aspect, or the eighth aspect, or the tenth aspect. The functions can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above.

In a thirteenth aspect, an embodiment of the present application provides a second device, including a processor and a memory, where the processor and the memory are interconnected by a line, and the processor invokes program code in the memory to perform a processing-related function in a method according to any one of the fifth, seventh, or ninth aspects. Alternatively, the home device may be a chip.

In a fourteenth aspect, an embodiment of the present application provides a first device, including a processor and a memory, where the processor and the memory are interconnected by a line, and the processor invokes program code in the memory for performing the processing-related functions in the method according to any one of the sixth, eighth, or tenth aspects. Alternatively, the home device may be a chip.

In a fifteenth aspect, an embodiment of the present application provides an apparatus, which may also be referred to as a digital processing chip or chip, the chip comprising a processing unit and a communication interface, the processing unit obtaining program instructions via the communication interface, the program instructions being executed by the processing unit, the processing unit being configured to perform a process-related function as in any of the optional embodiments of the fifth, seventh or ninth aspects described above.

In a sixteenth aspect, an embodiment of the present application provides an apparatus, which may also be referred to as a digital processing chip or chip, the chip comprising a processing unit and a communication interface, the processing unit obtaining program instructions via the communication interface, the program instructions being executed by the processing unit, the processing unit being configured to perform a process-related function as in any of the optional embodiments of the sixth, eighth or tenth aspects described above.

In a seventeenth aspect, embodiments of the present application provide a computer readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the method of any of the alternative embodiments of the fifth or seventh or ninth aspects described above.

In an eighteenth aspect, embodiments of the present application provide a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of any of the above-described alternative embodiments of the sixth or eighth or tenth aspects.

Drawings

FIG. 1 is a schematic flow chart of generating a digital signature and verifying the digital signature;

FIG. 2 is a schematic diagram of an identity management system according to an embodiment of the present application;

FIG. 3 is a schematic diagram of another identity management system according to an embodiment of the present application;

Fig. 4 is a schematic diagram of a typical application scenario provided in an embodiment of the present application;

Fig. 5 is a flow chart of an information management method according to an embodiment of the present application;

FIG. 6 is a flowchart illustrating another information management method according to an embodiment of the present application;

FIG. 7 is a flowchart illustrating another information management method according to an embodiment of the present application;

FIG. 8 is a flowchart illustrating another information management method according to an embodiment of the present application;

FIG. 9 is a flowchart illustrating another information management method according to an embodiment of the present application;

FIG. 10 is a flowchart illustrating another information management method according to an embodiment of the present application;

FIG. 11 is a flowchart illustrating another information management method according to an embodiment of the present application;

FIG. 12 is a flowchart of another information management method according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a second device according to an embodiment of the present application;

fig. 14 is a schematic structural diagram of a first device according to an embodiment of the present application;

fig. 15 is a schematic structural diagram of another second apparatus according to an embodiment of the present application;

Fig. 16 is a schematic structural diagram of another first device according to an embodiment of the present application;

Fig. 17 is a schematic structural diagram of a server according to an embodiment of the present application.

Detailed Description

The following description of the technical solutions according to the embodiments of the present application will be given with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

Centralized identity management refers to the issuance and control of the identity of a user by an organization or server. The specific flow is that the user provides some information to the service provider and based on the information applies for identity, the service provider generates identity (user name and password in general) for the user, saves the information on the server, and then issues the identity to the user. When a user accesses a service, identity information (generally, a user name and a password) needs to be provided, a server of a service provider compares the user identity information stored by the server with the user identity information, and after the user identity information passes the verification, the user is allowed to use the service. The most common scenario involves a user registering for a service, obtaining an account number and a password, logging in through the account number and password, and using the service.

The centralized identity management scheme, the organization or the central server has complete control right on the identity of the user, and the user identity can be revoked and changed at any time, so that the user does not have the right to control the user identity, and even has the right to know. In addition, when a system vulnerability occurs in an organization or a central server, a large amount of user identity information may be revealed, and the user identity information is not guaranteed.

In order to solve the problems, the embodiment of the application provides an identity management scheme for solving the potential safety hazard of user privacy disclosure caused by a centralized identity management scheme. Because the embodiments of the present application relate to a large amount of knowledge related to public keys, certificates, encryption and decryption, and signature techniques, in order to facilitate understanding of the schemes provided by the embodiments of the present application, the knowledge is first described.

A one-way hash function, also known as a one-way hash (hash) function, a hash function, is a function that changes an input message string of arbitrary length into an output string of fixed length and from which it is difficult to obtain the input string. This output string is called the hash value of the message. Typically for generating a message digest, key encryption, etc. The one-way hash function includes the following advantages:

1. the length of the encrypted ciphertext is fixed-length (i.e., the hash value obtained is fixed-length for three columns of messages of arbitrary length).

2. If the plaintext is not identical, the hashed result must not be identical.

3. If the plaintext is the same, then the encrypted ciphertext must be the same (the same encrypted ciphertext is the same for the same data).

4. The method has unidirectionality and can not reversely calculate.

Asymmetric encryption (ASYMMETRIC CRYPTOGRAPHY) is a type of cryptographic algorithm in which a pair of keys is required, one being a private key (abbreviated as private key) and the other being a public key (abbreviated as public key). The two keys are mathematically related, and the information obtained by encrypting a key of a user can only be decrypted by using the decryption key of the user. If one is known, the other cannot be calculated. So if one of a pair of keys is disclosed (public key), the secret nature of the other is not compromised (the private nature of the private key is not compromised). If the encryption key is a public key, this is used by the client to upload encrypted data to the owner of the private key, which is referred to as public key encryption. If the decryption key is a public key, the information encrypted by the private key can be decrypted by the public key, and the data or the file issued by the party holding the private key is verified to be complete and accurate by the client, the receiver can know that the information is really from someone holding the private key, which is called a digital signature, and the form of the public key is a digital certificate. For example, an installer downloaded from the web, typically with a digital signature of the program producer, may prove that the program was indeed issued by the author (company) and not forged by a third party and not tampered with (authentication/verification).

The process of digital signature is further described below in conjunction with fig. 1, in which the data sender performs a HASH calculation on the text to be transmitted, and the obtained result is used as a summary of the text to be transmitted. The private key of the data sender is used for encrypting the abstract of the text to be transmitted, and the obtained ciphertext is called the signature of the transmission process. The data receiving end receives the transmission text, but needs to confirm whether the text is the sent content or not, and whether the text is tampered in the middle. Therefore, the signature is decrypted by taking the public key held by the user (the data encrypted by one key in the key pair can be decrypted by the other key), the abstract of the text is obtained, then the abstract value is calculated by using the same HASH algorithm as the sender, and the abstract value is compared with the abstract obtained by decryption, and the abstract value are completely consistent, so that the text is not tampered. The process of verifying whether the two are identical is the process of signature verification.

In the signing process, the party receiving the data needs to store the public key, but because each sender has a public key, the party receiving the data needs to store a very large number of public keys, and the management is difficult. And the locally stored public key may be tampered with and replaced without discovery. To solve this problem, a unified certificate authority can manage public keys of all parties needing to send data, and authenticate and encrypt the public keys. This organization is also known as the certificate issuer (CERTIFICATE AUTHORITY, CA). The public key after authentication and encryption is a certificate, also called a CA certificate, which contains a lot of information, and most importantly, the public key of the applicant. The CA mechanism uses a unified key pair when encrypting the public key and uses the private key when encrypting the public key. Thus, after the applicant takes the certificate, when sending the data, the applicant uses the private key to generate a signature, sends the signature, the certificate and the sending content to the other party, after the other party takes the certificate, the applicant needs to decrypt the certificate to obtain the public key in the certificate, and the decryption needs to use the public key in the 'unified key pair' of the CA institution, namely the CA root certificate which we commonly call, and generally needs to be downloaded to the certificate issuing institution and installed on the corresponding client for receiving the data, such as a browser. This public key only needs to be installed once. With this public key, the certificate can be decrypted, the public key of the sender is taken, the signature sent by the sender is decrypted, the digest is obtained, and the digest is recalculated and compared to verify the integrity of the data content.

The scheme provided by the embodiment of the application can be suitable for any scene needing identity verification. The scheme provided by the embodiment of the application can enable the user to have an autonomous identity, namely an identity system with the user having the autonomy and the control right. The greatest difference between autonomous identity and centralized identity management is that the user has specific autonomy and control over the identity, while the service provider does not have control over the identity. In addition, more importantly, the scheme provided by the embodiment of the application can ensure that each service provider can only acquire part of identity information required to be verified by the service provider, cannot acquire complete identity information of a user, and ensures the safety of the identity information of the user. In addition, through the scheme provided by the embodiment of the application, when the equipment of the user is lost, the identity information of the user cannot be easily revealed, and the safety of the identity information is further ensured.

Referring to fig. 2, an architecture diagram of an identity management system according to an embodiment of the present application is provided. The scheme provided by the embodiment of the application at least relates to a three-party executive main body, which comprises main identity management equipment, equipment for using services and a server.

And the main identity management equipment is used for managing all identity information of the user. The scheme provided by the embodiment of the application has the advantages that the user has autonomy and control right on the identity information, and all the identity information is stored by the user, and can be stored on the main identity management equipment. In some possible embodiments, the primary identity management device may be a device that a user may carry next to the skin, for example, the primary identity management device may be a smart watch, smart glasses, smart ring, etc., and may also be other electronic devices such as a mobile phone.

A device for using a service for using the service. For example, clients corresponding to different services can be installed on the device using the services, and the user can use the different services, such as shopping service, reading service, social service, game service, and the like, by operating the clients. The device using the service may not store any identity information thereon, and may interact with the primary identity management device to obtain part of the identity information from the primary identity management device. According to the scheme provided by the embodiment of the application, the device using the service and the main identity management device are two different devices, and can correspond to a plurality of devices using the service for the same main identity management device. In some possible embodiments, the device that uses the service may be a device that facilitates installation of the service, such as a cell phone, PAD, or the like. Other electronic devices such as intelligent watches, intelligent glasses, intelligent rings and the like can also be used.

And the server is used for providing services for the equipment using the services. In some scenarios, the server allows the device using the service to access the server without requiring the device using the service to provide any identity information, and in other scenarios, the server requires the device using the service to provide relevant identity information before allowing the device using the service to access the server. The embodiment of the application focuses on the scene that the server needs to provide relevant identity information by using the equipment of the service.

It should be noted that, although fig. 2 shows 3 servers, 4 devices using services, and 2 primary identity management devices, this does not represent an embodiment of the present application to limit the number of the devices, and in a practical application scenario, the devices using services, and the primary identity management devices are included in more or fewer servers.

Referring to fig. 3, a schematic architecture diagram of another identity management system according to an embodiment of the present application is provided. The scheme provided by the embodiment of the application also relates to a block chain.

The blockchain consists of a series of growing records that become blocks (blocks). The blocks are linked together by cryptographic techniques, each block containing a hash value of the previous block, a time stamp, transaction data, etc. Blockchains are essentially a distributed multi-backed up database, but differ from databases in the biggest way that the storage of data is made through multiparty consensus and the use of hash chains to protect historical data, making the data tamper-proof. Compared with the traditional database technology, the characteristic that the blockchain data cannot be tampered is easier to obtain the trust of the user, so that multiparty cooperation can be better supported. In general, the public key generated by the primary identity management device is important, and it is also necessary to ensure that the public key generated by each primary identity management device is unique, and thus it must be ensured that the public key generated by the primary identity management device is authentic. Thus, the present application ensures that each public key corresponds to a unique DID and that each master identity management device generated public key is tamper-proof by employing the tamper-proof nature of the blockchain to register a de-centralized identity (decentralized identity, DID) on the blockchain via the public key.

Based on the architecture described in fig. 2 and 3, fig. 4 is a schematic diagram of a typical application scenario provided in an embodiment of the present application. As shown in fig. 4, the identity information of the user is various, such as name, date of birth, address, education level, medical records, income, and the like. The primary identity management device may obtain the identity information through a plurality of different channels, for example, obtain education degrees from schools and obtain medical records from hospitals, and the embodiment of the application does not limit how the primary identity management device obtains the identity information of the user. The primary identity management device locally generates a private key of the primary identity management device and a public key corresponding to the private key. The identity may be digitally signed by a private key so that a device having the public key can verify the digital signature. The device using the service is provided with different services, which are sometimes referred to as business according to the present application, and the same meaning is indicated when the distinction between the two is not particularly emphasized. The identity information that needs to be verified for each service may be different, such as the age of the user that needs to be verified for a game-like service, the income of the user that needs to be verified for a financial-like service, and so on. Therefore, according to the embodiment of the application, each service can only acquire the identity information which needs to be verified, and can not acquire all the information of the user. Specifically, in the embodiment of the application, a plurality of service identities are set for the main identity, and the embodiment of the application uses the service equipment to have a plurality of public and private key pairs, wherein the public key in each public and private key pair is used for binding a service, and the service information to be verified is bound to realize that the service equipment adopts the corresponding identity access service of the service, only the identity information to be verified of the service is provided in the verification stage, and each service is not accessed by the main identity, and all the identity information is not provided in the verification stage. By the method, the user has specific autonomy and control right on the identity, each service provider can be ensured to only acquire part of identity information required to be verified by the service provider, the complete identity information of the user can not be acquired, and the safety of the identity information of the user is ensured.

The following describes a scheme provided by the embodiment of the application. The scheme provided by the embodiment of the application can comprise an identity registration stage and an identity use stage, and various schemes provided by the embodiment of the application are respectively described below from the two aspects.

1. Identity registration phase-scheme 1

Referring to fig. 5, a flow chart of an information management method according to an embodiment of the present application is shown below.

501. The first device generates a first private key (SECRET KEY, SK) and a first Public Key (PK).

In one possible implementation, the first device may 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 is not limited to a specific manner of generating the first private key, and any manner of generating the first private key and the first public key corresponding to the first private key may be adopted in the embodiment of the present application. In such an embodiment, the first private key and the public key associated with the first private key may also be generated based on certain information, such as, but not limited to, a user-set password, a user's identification number, a user's medical insurance account, so that the first private key and the first public key may be generated from the certain information and a pre-selected key generation algorithm. In this embodiment, the first device may always store the first private key, for example, store the first private key in a private space of the first device, and when the first device needs to use the first private key, obtain the first private key from the private space. Or in this embodiment, the first device may not store the first private key, and when the first device needs to use the first private key, the first private key is generated and then used according to some information provided by the user and the selected key generation algorithm.

In another possible implementation, the first device obtains a biometric of the user, generates a first private key based on the biometric of the user, and a first public key corresponding to the first private key. The biological characteristics of the user include, but are not limited to, fingerprint information and iris information. In this embodiment, the first device need not store the first private key, and when the first device needs to use the first private key, the first device may first obtain the biometric of the user, and then generate the first private key according to the biometric of the user. Since the first device does not need to store the first private key, the security of the first private key is increased, and even if the first device is lost, people other than the user cannot acquire the private key of the first device.

In a preferred embodiment, the first device may be a personal smart device such as a smart watch, smart ring, smart glasses, smart bracelet, etc. In most scenes, users can carry the intelligent devices close to the body, and the embodiment of the application stores the main identity information of the users in the intelligent devices close to the body, so that the users can better control the main identity information.

502. The first device registers a decentralised IDentity (decentralized IDentity, DID) with the first public key.

DID allows individuals or organizations to fully possess identities of ownership, management, and control of their digital identities and their data. Compared with the traditional identity system based on PKI, the DID digital identity system established based on the blockchain has the characteristics of ensuring the authenticity and credibility of data, protecting the privacy safety of users, being strong in portability and the like.

In some embodiments, the DID may be a unique identification indicating a mapping relationship between the real entity and the presentity. The DID may include URL scheme identification, identification for the DID method, and DID method specific identification. Each DID may point to a corresponding DID document. The DID document may include descriptive text about the DID and a preset format (e.g., JSON-LD) of the owner of the DID. The DID may be used as a Uniform Resource Identifier (URI) for locating the DID document. The DID document may include various attributes such as context, DID topic, public key, authentication, authorization, and delegation, service endpoint, creation, update, attestation, extensibility, other suitable attributes, or any combination thereof. The DID document may define or point to a resource defining a plurality of operations that may be performed with respect to the DID.

Verifiable Claims (VCs) may allow authorization, endorsements, and acknowledgements between different entities. In a business environment, a service or product provider may use its customer's DID and VC to identify and authenticate the customer and provide the service or product accordingly.

In some embodiments, the VC may provide verifiable online information about the quality, characteristics, relationships, and other related information of the entity. VC may contain descriptive text in a pre-set format (e.g., JSON-LD) describing one or more claims about DID (e.g., age of DID owner, educational background of DID owner), and endorsements of the claims by the entity. The VC may include various attributes such as context, identity, type, credential topic, publisher, release date, proof, expiration date, status, representation, other suitable attributes, or any combination thereof. The VC may specify the type of its declaration (claim), which may indicate the structure of the declaration. This may prompt the VC publisher and VC verifier to automatically process.

The owners of DID may participate in the identity management system in different roles. For example, an individual may desire to use a service provided by a business entity that needs to prove that the individual has exceeded 18 years old. The individual may be the owner of the DID and may request a VC issued by a government agency that provides for citizen age verification. The business entity may verify the VC to ensure that the individual meets age requirements. In this case, the individual may be a DID owner and a VC holder, the government entity may be a VC publisher, and the business entity may be a VC verifier.

In the embodiment of the application, the DID is registered through the first public key, so that the first public key and the unique DID are bound, and after the server side obtains the DID, the first public key can be queried according to the DID, and the identity is verified based on the first public key, for example, the received digital signature is verified to come from the first device.

If the different first devices use the same first public key, it may result in the DID acquired from the plurality of different first devices being the same. In order to enable each first device to have a unique DID, after the first device acquires the DID, the blockchain may check the acquired DID again, and if the same DID is not stored in the current blockchain, the registration is considered successful, and the first public key is bound to the unique DID.

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

The user may access a variety of services through the second device, such as accessing shopping class services, social class services, gaming class services, and the like. In general, various services can be accessed only after a user is registered, or a server of the service can save related data generated by the user in using the service after the user is registered, and when the user accesses the service according to a registered account, the related data can be obtained.

In the scheme provided by the embodiment of the application, after the second equipment initiates the registration request to the server, the server does not need to wait for the server to generate the identity (generally, the user name and the password) for the user, and the server does not need to issue the identity to the user. In the scheme provided by the embodiment of the application, the second equipment initiates the registration request to the server so as to acquire the identity information which needs to be verified by the server. Specific explanation will be made in the following steps.

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

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 a category of identity information that needs to be verified. For example, for a game service, after the second device initiates a registration request to the game server, the category of the first message carrying the identity information to be verified may include an age. For another example, for the social service, after the second device initiates the registration request to the social server, the category of the identity information to be verified in the first message may include an identification card number, an academy, and the like.

In one possible embodiment, the first message may further carry other information, such as a service identifier (SERVICE ID), where the service identifier of each service is used to represent a unique service. Or, the service identification and the service are in one-to-one correspondence.

505. The second device sends a second message to the first device.

After receiving the first message sent by the server, the second device obtains the second message according to the first message, and sends the second message to the first merger.

In one possible embodiment, the content carried by the second message is identical to the content carried by the first message. For example, the first message carries the category of identity information to be verified, and the second device forwards the content carried by the first message to the first device through the second message, i.e. the second message also carries the category of identity information to be verified carried by the first message. For another example, the first message carries the category of the identity information to be verified and the service identifier, and the second device forwards the content carried by the first message to the first device through the second message, that is, the second message also carries the category of the identity information to be verified and the service identifier carried by the first message.

In one possible implementation, the content carried by the second message may be part of the content carried in the first message. For example, the first message carries the category of the identity information to be verified and the service identifier, and the second device may send only part of the content in the content carried in the first message to the first device through the second message, for example, only the category of the identity information to be verified carried in the first message is sent to the first device through the second message.

It can be understood that the second message must carry the category of identity information to be verified, which is carried in the first message, and in a preferred embodiment, the second message may also carry a service identifier, and in addition, other information may also be carried in the second message.

In one possible implementation, the second device may send the second message to the first device over the secure channel. Any scheme of transmission through a secure channel may be adopted in the embodiments of the present application, for example, a secure connection may be established between a first device and a second device, where the second device sends a second message to the second device through a secure network transmission protocol (transport layer security, TLS).

506. The first device acquires identity information of the service to be verified.

According to the category of the identity information to be verified, which is carried in the second message, searching the identity information corresponding to each category, and forming the first identity information by the searched identity information corresponding to each category. Such as the first device having stored therein all identity information of the user including, but not limited to, name, date of birth, address, education level, medical records, income, etc. When the category indication of the identity information to be verified, which is carried in the second message, includes a name and a date of birth, the first device acquires the name and information corresponding to the date of birth from all the identity information, and if the name of the user is Zhang three and the date of birth is 1 month 1 day of 2000, the first identity information may include Zhang three and 1 month 1 day of 2000, or the first identity information may include a name of Zhang three and a date of birth of 1 month 1 day of 2000. The embodiment of the application does not limit the specific implementation manner of the first identity information.

507. The first device obtains a second public key of the second device.

In one possible implementation, the first device may obtain a pair of public and private keys from the other device as the public and private keys of the second device.

In one possible implementation manner, the manner of generating the private key and the public key corresponding to the private key is not limited, and will not be repeated in the following description. In such an embodiment, after the second device generates the second private key and the second public key, the public key of the second device may be sent to the first device.

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

In one possible implementation, the first device may derive a second private key according to the related information, and may further obtain the second public key according to the second private key. In this embodiment, the first device may be enabled to estimate the second private key according to the acquired information, so that the first device does not need to store the second private key. For example, in one possible implementation, the first private key may be derived from the first identity information, the first public key, and the service identifier obtained through the steps described above. Specifically, the first identity information, the first public key and the service identifier may be respectively used as parameters of a key deduction function (key derivation function, KDF), the second private key is obtained according to the value of the KDF, and further the second public key corresponding to the second private key is obtained according to the second private key.

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

After the first device acquires the second public key and the first identity information, a binding relationship between the second public key and the first identity information is established, so that one second public key corresponds to the unique first identity information.

In one possible implementation, if the first device obtains the service identifier, for example, in step 505, the first device obtains both the service identifier and the first identity information, then a correspondence between the service identifier and the first identity information may also be established. When the first device establishes a correspondence between the service identifier and the first identity information, the correspondence between the second public key and the first identity information may not be established.

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

In order to increase the security of the first identity information, the first identity information stored on the first device is not easily revealed, and the first identity information can be encrypted through the first public key.

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

510. The first device sends the encrypted first identity information and the first identification to the blockchain.

The first identifier may be the second public key, or may be the service identifier.

The first device may send a digital signature to the blockchain, the digital signature carrying the encrypted first identity information and the first identification. After the blockchain verifies that the digital signature is from the first device according to the public key of the first device, the blockchain stores the encrypted first identity information in a DID Document (DID Document) corresponding to the DID registered by the first device. Each DID identity corresponds to a DID Document (DID Document).

And establishing a binding relation between the first identifier and the encrypted first identity information in the blockchain. For example, a binding relationship between the second public key and the encrypted first identity information is established, or a binding relationship between the service identifier and the encrypted first identity information is established.

511. The second device establishes a binding relationship between the second public key and the service identity.

In one possible implementation, the second device may generate the second private key and the second public key, and after the first message acquired by the second device, a binding relationship between the second public key and the service identifier may be established.

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 manner, the first device may send the second private key and the second public key to the second device through the secure channel, where the secure channel is understood with reference to the secure channel described in step 505, and the description is not repeated here. In this embodiment, after the second device receives the second public key and the second private key sent by the first device, a binding relationship between the second public key and the service identifier is established, and because the second public key and the second private key are in a one-to-one correspondence relationship, the unique second private key can be queried according to the service identifier.

After the second device obtains the second private key and the second public key, the second device stores the second public key and the second private key, and the binding relationship between the second public key and the service identifier.

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

After the second device establishes the binding relationship between the second public key and the service identifier, a third message may be sent to the first device, so that the first device obtains the state of the second device. In one possible embodiment, the third message may be used to indicate that the registration was successful.

In one possible implementation manner, after the first device acquires the third message sent by the second device, the first device may perform deletion processing on the first identity information stored locally by the first device, or the first identity information.

In one possible implementation, if the first device is a first private key generated according to the biometric feature of the user, the first device may perform a deletion process on the locally stored first private key after the first device has acquired the third message.

In one possible implementation, if the first device generates the second private key and the second public key, the first device may delete the locally stored second private key after acquiring the third message.

It should be noted that, based on the embodiment described in fig. 5, the embodiment of the present application may include more or fewer steps. For example, in one possible implementation, the method may further include the step of the first device prompting that the registration is successful. After the first device obtains the third message sent by the second device, the first device may prompt the user that the registration is successful. For example, the user may be prompted for successful service/traffic registration as described in the steps above. As another example, some steps may not be performed, such as in one possible implementation, step 502 may not be performed, or step 508 may not be performed. In fact, the steps involved in each embodiment described in the embodiments of the present application may be more or less, and the detailed description thereof will not be repeated.

Furthermore, it should be noted that, based on the embodiment described in fig. 5, the order of the steps described above may be exchanged, for example, step 511 may be performed before step 506 to step 510, or may be performed in synchronization with step 506 to step 510. In fact, the sequence of each step in each embodiment described in the embodiments of the present application may be exchanged or each step is executed synchronously, which will not be repeated herein.

As can be seen from the corresponding embodiment of fig. 5, in the registration stage, for each service, different identity information (first identity information) is generated for each identity information to be verified, and the different identity information is bound to a different second public key, which is equivalent to setting a plurality of subordinate identities for each main identity in the embodiment of the present application, and each subordinate identity is used for accessing a service. The user can master the complete identity information of the user through the first equipment, and other equipment except the first equipment cannot acquire the complete identity information of the user, so that privacy protection of the identity information of the user is enhanced.

The login procedure corresponding to the above-described registration procedure described in fig. 5 will be described.

2. Identity usage phase (also referred to herein as Login phase) -scheme 1

Referring to fig. 6, a flow chart of an information management method according to an embodiment of the present application is shown below.

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

After the second device initiates an access request to the server, the server sends an Identity Request (IR) message to the second device.

In one possible implementation, the IR message carries a service identification. In one possible implementation, the IR message carries the service identification and the server's credentials. In one possible implementation, the IR message carries the service identifier, the certificate of the server, and the anti-replay authentication parameter, for example, the anti-replay authentication parameter may be a random number (Nonce), which is not limited by the specific manner in which the embodiment of the present application performs the anti-replay authentication parameter. In one possible embodiment, the anti-replay parameter is a time stamp and/or a sequence number characterizing the generation time of the access request. For example, assuming that the IR message sent by the server to the second device includes a unique identifier 123 of the server and a timestamp of 10:00, the second device, after acquiring the IR message, verifies the validity of the unique identifier 123 of the server and the timestamp of 10:00, if the second device determines that the unique identifier 123 is actually present by querying a corresponding unique identifier database, and the timestamp of 11:30 is before the current time and within a preset time range, the second device determines that the unique identifier 123 of the server of the IR message and the timestamp of 10:00 are valid, i.e. the second device determines that the IR message is a valid IR message. The second device then proceeds to perform subsequent steps, such as step 602.

602. And the second equipment acquires a second private key according to the service identifier.

The second device obtains the second private key and the second public key in the registration phase, and establishes a binding relationship between the second public key and the service identifier. After the second device obtains the service identifier according to the IR message, the second public key uniquely corresponding to the service identifier may be obtained according to a binding relationship between the service identifier stored in the second device and the second public key. Then, since one second public key corresponds to the unique second private key, the second private key can be obtained according to the second public key uniquely corresponding to the service identifier.

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

The second device generates a digital signature from the second private key obtained in step 602.

In one possible implementation, the digital signature carries an IR message. The second device also sends the public key of the second device to the first device.

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.

In one possible implementation, the digital signature and the second public key may be transmitted to the first device over a secure channel.

604. The first device verifies the digital signature.

The first device receives the digital signature sent by the second device and the 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 procedure for how to verify the digital signature has been described above and will not be repeated here.

If the verification is passed, the following steps are continued, for example, step 605 is executed, and if the verification is not passed, the following steps are not executed.

605. The first device obtains a first private key.

In one possible implementation, if the first private key is stored locally at the first device during the registration phase, the first private key is obtained locally from the first device after the first device verifies that the digital signature of the second device passes.

In one possible implementation, if the first private key is generated by the user's biometric feature during the registration phase, the user's biometric feature is obtained after the first device verifies that the second device's digital signature passes. The first device may generate the first private key according to the acquired biometric feature of the user, and may also generate the first public key corresponding to the first private key in the same manner as the registration stage.

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

The first device may send a digital signature to the blockchain, the digital signature carrying the first identification therein. The first identity in the login phase is the same as the first identity in the registration phase. For example, if the first identifier is a service identifier in the registration stage, in the login stage, the first device sends a digital signature to the blockchain, where the digital signature carries the service identifier, and after the blockchain verifies that the digital signature is from the first device according to the public key of the first device, the first encrypted identity information corresponding to the service identifier is queried according to the service identifier. For another example, if the first identifier is the second public key in the registration stage, the first device sends a digital signature to the blockchain, where the digital signature carries the second public key, and after the blockchain verifies that the digital signature is from the first device according to the public key of the first device, the first encrypted identity information corresponding to the second public key is queried according to the second public key.

After the blockchain queries the encrypted first identity information according to the first identifier, the encrypted first identity information is sent to the first device, so that the first device can acquire the encrypted first identity information.

607. The first device decrypts the first identity information using the first private key.

After the first device obtains the encrypted first identity information from the blockchain, the first device adopts the first public key to encrypt the first identity information in the registration stage, so that the first device can utilize the first private key corresponding to the first public key to decrypt the encrypted first identity information in the login stage to obtain the first identity information.

608. The first device sends a digital signature to the second device.

The first device generates a digital signature using the first private key, the digital signature carrying 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 anti-replay parameters.

The first device sends the digital signature to the second device, and 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 that are locally stored in the first device may be deleted.

609. The second device forwards the digital signature to the server.

In one possible implementation, the second device may not verify the digital signature, but simply forward the obtained digital signature to the server.

In one possible embodiment, after the second device obtains the digital signature sent by the first device, the first digital signature may be verified by the public key of the first device, and after the verification is passed, the digital signature is verified to be from the first device, and then the digital signature is sent to the server.

610. The server verifies the digital signature with the first public key.

The server verifies the received digital signature by means of the public key of the first device, and the description of how to verify the digital signature has been described above is not repeated here.

In one possible implementation, the server may query the blockchain for the DID of the first device, and obtain the public key of the first device based on the DID to which the first device uniquely corresponds.

611. And after the server is successfully verified, allowing the second device to access the server.

After the server verifies successfully, the digital signature is determined to be sent by the first device, and the second device is allowed to access the server, namely the second device is allowed to use the corresponding service/business.

In one possible implementation, the server may also send a notification message to the second device or the first device that authentication was successful.

In one possible implementation, the second device is not allowed to access the server if the authentication is not passed.

As can be seen from the embodiment corresponding to fig. 6, in the identity usage stage, each server can only obtain the identity information required to be verified by the server, but cannot obtain all the identity information of the user, so that the privacy and security of the user identity are improved. In addition, the scheme provided by the embodiment of the application can conveniently cancel the second public key, and ensure the security of the user identity information. For example, after the second device is lost, the first device may set the public key of the second device to be invalid, and the second device may no longer request the first device to send the identity information based on the public key of the previous second device. And, the first device may regenerate the new second public key to establish a binding relationship with the new second device. In addition, the scheme provided by the embodiment of the application can generate the first private key according to the biological characteristics of the user, and the first private key does not need to be stored in the first equipment, so that the safety of the identity information is further improved. In addition, the public key of the second device is stored in the second device, so that the authentication and use are convenient at any time.

It should be noted that more or fewer steps may be included on the basis of the embodiment described in fig. 6 above. Furthermore, it should be noted that, based on the embodiment described in fig. 6, the order between the steps described above may be exchanged or may be performed synchronously.

In the above-described schemes of fig. 5 and 6, the encrypted first identity information is stored in the blockchain, and in some other embodiments, the encrypted first identity information may also be stored in the first device or the second device, which is described below in connection with the specific embodiments.

1. Identity registration phase-scheme 2

Referring to fig. 7, a flow chart of an information management method according to an embodiment of the present application is shown below.

701. The first device generates a first private key and a first public key.

702. The first device registers the DID with the first public key.

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

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

705. The second device sends a second message to the first device.

706. The first device acquires identity information of the service to be verified.

707. The first device obtains a second public key of the second device.

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

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

Steps 701 to 709 may be understood with reference to steps 501 to 509 in the corresponding embodiment of fig. 5, and the detailed description is not repeated here.

710. The first device stores the encrypted first identity information.

Unlike the embodiment depicted in fig. 5, where the encrypted first identity information is stored in the blockchain, in the embodiment depicted in fig. 7, the first device stores the encrypted first identity information locally, saving storage resources and communication resources of the blockchain.

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

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

If the same second public key is adopted by different second devices, or multiple different services of the second devices are all bound to the same public key, the same second public key may bind different first identity information, and confusion may be caused in a login stage, for example, the first device may send the first identity information to the second device by mistake, which may further cause a server verification failure. For example, the first device has two corresponding second devices, namely a second device a and a second device B. If the public key of the second device a is the second public key a, the public key of the second device B is the second public key B. The first identity information bound by the second public key A is first identity information A, and the first identity information bound by the second public key B is first identity information B. In the login stage, after the first device verifies that the digital signature passes according to the second public key A, the first device sends first identity information bound with the second public key A to the second device A. However, if the second public key a and the second public key B are the same, the first device may send the first identity information bound to the second public key B to the second device a, and if the first identity information bound to the second public key a and the first identity information bound to the second public key B are not the same, verification may fail after the second device a sends the first identity information bound to the second public key B to the server. For another example, two different services, namely, service a and service B, are registered on the second device, and it is assumed that the public key corresponding to service a is the second public key a and the public key corresponding to service B is the second public key B. The first identity information bound by the second public key A is first identity information A, and the first identity information bound by the second public key B is first identity information B. In the login stage, after the first device verifies that the digital signature passes according to the second public key A, the first device sends first identity information bound with the second public key A to the second device. However, if the second public key a and the second public key B are the same, the first device may send the first identity information bound to the second public key B to the second device a, and if the first identity information bound to the second public key a and the first identity information bound to the second public key B are not the same, verification may fail after the second device a sends the first identity information bound to the second public key B to the server. For example, service a is a game-like service, the first identity information bound to the second public key a includes age, service B is a financial-like service, and the first identity information bound to the second public key B includes revenue. If the revenue situation is sent to the server of service a, verification failure may result.

In order to solve the above problem, the first device registers the DID with the second public key, and the blockchain checks the obtained DID, and if the same DID is not stored in the current blockchain, the registration is considered successful, and the second public key is bound to the unique DID.

712. The second device establishes a binding relationship between the second public key and the service identity.

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

Step 712 and step 713 may be understood by referring to step 511 and step 512 in the corresponding embodiment of fig. 5, and the detailed description will not be repeated here.

2. Identity usage phase (also referred to herein as Login phase) -scheme 2

Referring to fig. 8, a flow chart of an information management method according to an embodiment of the present application is shown below.

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

802. And the second equipment acquires a second private key according to the service identifier.

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

804. The first device verifies the digital signature.

805. The first device obtains a first private key.

Steps 801 to 805 can be understood with reference to steps 601 to 605 in the corresponding embodiment of fig. 6, and the detailed description will not be repeated here.

806. The first device obtains the encrypted first identity information from the local.

And the first equipment queries the local storage according to the first identification to acquire the encrypted first identity information.

The first identity in the login phase is the same as the first identity in the registration phase. For example, if the first identifier is a service identifier in the registration stage, in the login stage, the first device queries encrypted first identity information corresponding to the service identifier according to the service identifier. For another example, if the first identifier is the second public key in the registration stage, the first device queries the encrypted first identity information corresponding to the second public key according to the second public key in the registration stage.

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

808. The first device sends a digital signature to the second device.

809. The second device forwards the digital signature to the server.

810. The server verifies the digital signature with the first public key.

811. And after the server is successfully verified, allowing the second device to access the server.

Steps 807 to 811 can be understood with reference to steps 607 to 611 in the corresponding embodiment of fig. 6, and the detailed description will not be repeated here.

It should be noted that more or fewer steps may be included on the basis of the embodiments described in fig. 7 and 8 above. Furthermore, it should be noted that, on the basis of the embodiments described in fig. 7 and 8, the order between the steps described above may be exchanged or may be performed synchronously.

In the schemes described in fig. 7 and 8, in addition to having the advantages described in the embodiments described in fig. 5 and 6, the encrypted first identity information is stored in the first device, saving the storage resources and communication resources of the blockchain. In some possible embodiments, the encrypted first identity information may also be stored in the second device, which is described below in connection with the specific embodiments.

1. Identity registration phase-scheme 3

Referring to fig. 9, a flow chart of an information management method according to an embodiment of the present application is shown below.

901. The first device generates a first private key and a first public key.

902. The first device registers the DID with the first public key.

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

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

905. The second device sends a second message to the first device.

906. The first device acquires identity information of the service to be verified.

907. The first device obtains a second public key of the second device.

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

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

Steps 901 to 909 can be understood with reference to steps 701 to 709 in the corresponding embodiment of fig. 7, and the detailed description will not be repeated here.

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

Step 910 may be understood by referring to step 711 in the corresponding embodiment of fig. 7, and a detailed description is not repeated here.

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

In one possible implementation, it may be that the second device generates 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 manner, the first device may send the second private key and the second public key to the second device through the secure channel, where the secure channel is understood with reference to the secure channel described in step 505, and the description is not repeated here.

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 over a secure channel. In one possible implementation, the first device may send the encrypted first identity information, and the second private key and the second public key, to the second device via the same message. In one possible implementation, the first device may send the encrypted first identity information, and the second private key and the second public key, to the second device via different messages.

And the second device or the second device stores the encrypted first identity information, the second public key and the second private key after encrypting the first identity information and the second public key.

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.

After the second device establishes the binding relationship between the second public key and the service identifier, the second public key and the second private key are in one-to-one correspondence, which is equivalent to that the unique second private key can be queried according to the service identifier.

The second device obtains a second public key bound to the service identifier, and further obtains first identity information bound to the second public key.

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

In the embodiment described in fig. 9, the second device locally stores the encrypted first identity information, and since the second device is usually a mobile phone, the security performance is higher, and the security of the identity information can be improved by storing the encrypted first identity information in the mobile phone.

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

Step 913 can be understood with reference to step 512 in the corresponding embodiment of fig. 5, and the detailed description will not be repeated here.

2. Identity usage phase (also referred to herein as Login phase) -scheme 3

Referring to fig. 10, a flow chart of an information management method according to an embodiment of the present application is shown below.

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

1002. And the second equipment acquires a second private key according to the service identifier.

Steps 1001 to 1002 may be understood with reference to steps 601 and 602 in the corresponding embodiment of fig. 6, and the detailed description will not be repeated here.

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

The second device generates a digital signature according to the second private key obtained in step 602, where the digital signature carries the IR message and the encrypted first identity information. The second device also sends the public key of the second device to the first device.

Specifically, after the second device obtains the service identifier, the second device may further obtain the encrypted first identity information bound to the public key according to the second public key bound to the service identifier. If the binding relation between the service identifier and the encrypted first identity information is established in the registration stage, the second device can directly acquire the encrypted first identity information bound with the service identifier according to the service identifier after acquiring the service identifier.

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.

In one possible implementation, the digital signature and the second public key may be transmitted to the first device over a secure channel.

1004. The first device verifies the digital signature.

1005. The first device obtains a first private key.

Step 1004 and step 1005 may be understood by referring to step 604 and step 605 in the corresponding embodiment of fig. 6, and the detailed description will not be repeated here.

1006. The first device decrypts the first identity information through the first private key.

After the first device obtains the encrypted first identity information from the second device, the first device decrypts the encrypted first identity information through the first private key to obtain the first identity information.

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

1008. The second device forwards the digital signature to the server.

1009. The server verifies the digital signature with the first public key.

1010. And after the server is successfully verified, allowing the second device to access the server.

Steps 1007 to 1010 may be understood with reference to steps 608 to 611 in the corresponding embodiment of fig. 6, and the detailed description is not repeated here.

In the solutions described in fig. 9 and fig. 10, in addition to the advantages described in the embodiments described in fig. 5 and fig. 6, the encrypted first identity information is stored in the second device, and since the second device is usually a mobile phone, the security performance is higher, and the security of the identity information can be improved by storing the encrypted first identity information in the mobile phone.

In the embodiments described in the above fig. 5 to 10, the public-private key pair is utilized in the identity registration stage and the identity usage stage, for example, a first private key is introduced, 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. In some embodiments, asymmetric encryption techniques may not be employed, but symmetric encryption techniques may also be employed. The following description is made in connection with specific embodiments.

1. Identity registration phase-scheme 4

Referring to fig. 11, a flow chart of an information management method according to an embodiment of the present application is shown below.

1101. The first device generates a first key.

In one possible implementation, the first device may randomly generate the first key. In this embodiment, the first device may always store the first private key, for example, store the first private key in a private space of the first device, and when the first device needs to use the first private key, obtain the first private key from the private space.

In one possible implementation, the first device obtains a biometric of the user and generates the first key based on the biometric of the user. The biological characteristics of the user include, but are not limited to, fingerprint information and iris information. In such an embodiment, the first device need not store the first key, and when the first device needs to use the first key, the first key may be first obtained from the user's biometric and then generated from the user's biometric. Since the first device does not need to store the first key, the security of the first private key is increased, and even if the first device is lost, people other than the user cannot acquire the private key of the first device.

1102. The first device generates a second key based on the identification of the first device.

Each device has a unique corresponding identifier, and the embodiment of the application does not limit the specific implementation manner of the identifier of the first device. For example, the first device is identified based on an international mobile equipment identity (international mobile equipment identity, IMEI) and a media access control address (MEDIA ACCESS control address, MAC) address. And as an identification of the first device, e.g. based on the access network identification.

And generating a second key according to the unique corresponding identifier of the first device.

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

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

Step 1103 and step 1104 may be understood with reference to step 503 and step 504 in the corresponding embodiment of fig. 5, and the detailed description will not be repeated here.

1105. The second device generates a third key according to the service identification.

And if the second device generates a third key according to the service identifier, the second device establishes a binding relationship between the service identifier and the third key.

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

The target message carries the category of identity information to be verified and a third key. For example, for a game service, after the second device initiates a registration request to the game server, the category of the first message carrying the identity information to be verified may include an age. For another example, for the social service, after the second device initiates the registration request to the social server, the category of the identity information to be verified in the first message may include an identification card number, an academy, and the like.

In one possible implementation, the target message carries the category of identity information and the service identifier that need to be verified. In such an embodiment, step 1105 may not be performed and the third key may be generated by the first device based on the service identification. If the first device generates a third key according to the service identifier, the first device establishes a binding relationship between the service identifier and the third key.

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

1107. The first device obtains a target key.

The first device synthesizes the target key from the first key, the second key, and the third key. The embodiment of the application does not limit the specific mode and the mode adopted from the target key, and only needs to ensure that the target key is synthesized together according to the three keys, namely the first key, the second key and the third key.

1108. The first device obtains first identity information.

Step 1108 may be understood by referring to step 506 in the embodiment corresponding to fig. 5 when the first device obtains the identity information that needs to be verified for the service, which is not repeated here.

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

1110. The first device establishes a binding relationship.

In one possible embodiment, the first device establishes a binding relationship between the third key and the encrypted first identity information.

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

In one possible implementation, the first device establishes a binding relationship between the service identification and the encrypted first identity information.

1111. The first device informs the second device that the first identity information has been encrypted by the target key.

1112. The second device sends feedback information to the first device.

After the second device obtains that the first device has encrypted the first identity information with the target key, a feedback message may be sent to the first device informing the second device that the message sent by the first device has been received (step 1110).

In one possible implementation manner, after the first device acquires the feedback message sent by the second device, deletion processing may be performed on the first key, the second key, the third key, and the target key.

In one possible implementation, the first device may prompt the user for successful registration.

2. Identity usage phase (also referred to herein as Login phase) -scheme 4

Referring to fig. 12, a flowchart of an information management method according to an embodiment of the present application is shown below.

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

Step 1201 can be understood by referring to step 601 in the corresponding embodiment of fig. 6, and the detailed description is not repeated here.

1202. And the second equipment acquires a third key according to the service identifier.

The corresponding embodiment of fig. 11 describes that, in the registration phase, the second device establishes a binding relationship between the third key and the service identifier, so that after the second device obtains the service identifier, the second device may obtain the third key bound to the service identifier.

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

In one possible implementation, if the third key is generated by the first device during the registration phase, the second device may send only an IR message to the first device, the third key being generated by the first device from the service identity.

In one possible implementation, the second device may send the IR message and the third key to the first device over the secure channel.

1204. The first device obtains a first key and a second key.

The first device obtains a biometric of the user and generates a first key based on the biometric of the user. The first device obtains an identification of the first device, and the first device obtains a second key according to the identification of the first device. Obviously, the biometric characteristic of the user is the same as that adopted in the registration stage, and the identification is the same as that adopted in the registration stage, and the explanation of this embodiment of the present application will not be repeated.

1205. The first device obtains a target key.

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

In one possible implementation manner, the third key may be obtained by the first device according to the service identifier, or the third key may be sent to the first device after being generated by the second device according to the service identifier.

1206. The first device obtains the encrypted first identity information.

In one possible embodiment, if in the registration phase, the first device establishes a binding relationship between the third key and the encrypted first identity information. In the login stage, the first device may search for the encrypted first identity information bound to the third key according to the obtained third key.

In one possible implementation, if in the registration phase, the first device establishes a binding relationship between the target key and the encrypted first identity information. The first device may, during the login phase, look up the encrypted first identity information bound to the target key based on the target key.

In one possible implementation, if in the registration phase, the first device establishes a binding relationship between the service identity and the encrypted first identity information. In the login stage, the first device may search the encrypted first identity information bound to the service identifier according to the service identifier.

1207. The first device decrypts the first identity information with the target key.

1208. The first device transmits first identity information encrypted by a public key of the server to the second device.

In one possible implementation, after the first device completes step 1207 or step 1208, the deletion process may be performed on the first key, the second key, the third key, and the target key.

1209. The second device transmits the first identity information encrypted by the public key of the server to the server.

1210. The server decrypts the first identity information encrypted by the public key of the server through the private key of the server, and verifies the first identity information.

1211. And after the server is successfully verified, allowing the second device to access the server.

The embodiments described in fig. 5 to 10 are all based on public key system design, and may require a relatively high computing power of the device and relatively high power consumption during application. The embodiments described in fig. 11 and 12 use a symmetric key based scheme with relatively low computational requirements on the device and relatively small functionality. In addition, the embodiments described in fig. 11 and fig. 12 use the identity of the first device as a partial key to synthesize a symmetric key, so that the strong binding between the device and the user key is completed, and the security is also better. Meanwhile, the symmetric key is simple to implement and mature in technology.

The foregoing describes in detail the system and method of the present application, and the following describes the apparatus of the present application.

Referring to fig. 13, a schematic structural diagram of a second apparatus is provided in the present application.

The second device includes:

a transceiver module 1301, configured to initiate a registration request to a server.

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

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.

The transceiver module 1301 is further configured to send, to the first device, a type of information that needs to be verified by the first service, so that the first device obtains, from information locally stored in the first device, the information that needs to be verified by the first service, where a binding relationship exists between the information that needs to be verified by the first service and a public key of the second device.

In a possible implementation manner, the transceiver module 1301 is further configured to receive information that needs to be verified, sent by the first device, of the encrypted first service. The processing module 1303 is further configured to establish a binding relationship between the encrypted information that needs to be verified by the first service and the public key of the second device.

In one possible implementation, the transceiver module 1301 is further configured to receive a private key of the second device and a public key of the second device, which are sent by the first device. A transceiver module 1301, configured to initiate an access request to a server. The transceiver module 1301 is further configured to receive 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 processing module 1303 is configured to search, according to the identifier of the first service, a public key of the second device bound to the identifier of the first service. The processing module 1303 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 1301 is further configured to send the digital signature of the second device and the public key of the second device to the first device, so that after the first device verifies that the digital signature of the second device is from the second device, the first service bound to the public key of the second device obtains information that needs to be verified.

In one possible implementation, the transceiver module 1301 is configured to initiate a registration request to a server. The transceiver module 1301 receives a first message sent by the server, where the first message carries the type of information that needs to be verified by the first service and the identifier of the first service. The transceiver module 1301 is further configured to send, to the second device, a type of information that needs to be verified by the first service.

In a possible implementation manner, 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.

In a possible implementation manner, the device further includes a storage module 1302, configured to store data acquired by the transceiver module.

Referring to fig. 14, a schematic structural diagram of a first apparatus is provided in the present application.

The first device includes:

The transceiver module 1401 is configured to obtain, from the second device, a type of information that needs to be verified for the first service, and obtain, from the storage module 1402 of the first device, information that needs to be verified for the first service according to the type of information that needs to be verified for the first service, where a binding relationship exists between the information that needs to be verified for the first service and a public key of the second device.

In a possible implementation manner, the device further includes a processing module 1403, configured to establish a binding relationship between the information that needs to be verified by the first service and the public key of the second device.

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

In one possible implementation, the transceiver module 1401 is further configured to send the encrypted information that needs to be verified to the block link point, so that the block link point establishes a binding relationship between the encrypted information that needs to be verified for the first service and the public key of the second device.

In a possible implementation manner, the transceiver module 1401 is further configured to send the encrypted information that the first service needs to be verified to the second device, so that the second device establishes a binding relationship between the encrypted information that the first service needs to be verified and the public key of the second device.

In a possible implementation manner, the processing module 1403 is further configured to delete the information that needs to be verified of the encrypted first service stored locally in the first device after the first device sends the information that needs to be verified of the encrypted first service.

In one possible implementation, the processing module 1403 is further configured to generate a private key of the first device based on the biometric of the user.

In a possible implementation, the processing module 1403 is further configured to register the decentralized identity DID with a public key of the first device.

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

In one possible implementation, the transceiver module 1401 is further configured to obtain an identification of the first service from the second device. The processing module 1403 is specifically configured to generate a private key of the second device according to the identifier of the first service, information that the first service needs to verify, and the private key of the first device.

In one possible implementation, the processing module 1403 is further configured to obtain, after verifying that the digital signature of the second device is from the second device, information that needs to be verified by the first service bound to the public key of the second device. The processing module 1403 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 information that needs to be verified by the first service.

In one possible implementation, the processing module 1403 is specifically configured to obtain, from the blockchain node, information that the encrypted first service bound to the public key of the second device needs to be verified after verifying that the digital signature of the second device is from the second device, and decrypt the information that the encrypted first service needs to be verified according to the private key of the first device to obtain the information that the first service needs to be verified.

In one possible implementation manner, the processing module 1403 is specifically configured to obtain, from the second device, information that the encrypted first service bound to the public key of the second device needs to be verified after verifying that the digital signature of the second device is from the second device, and decrypt the information that the encrypted first service needs to be verified according to the private key of the first device, so as to obtain the information that the first service needs to be verified.

In one possible implementation manner, the processing module 1403 is specifically configured to, after the first device verifies that the digital signature of the second device is from the second device, locally obtain, from the first device, information that the encrypted first service needs to be verified, and decrypt, according to the private key of the first device, the information that the encrypted first service needs to be verified, so as to obtain the information that the first service needs to be verified.

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

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

In one possible implementation, the transceiver module 1401 is further configured to obtain, from the second device, a type of information that needs to be verified by the first service, and obtain, from information locally stored in the first device, the information that needs to be verified by the first service according to the type of information that needs to be verified by the first service, where the information that needs to be verified by the first service is bound to a target key, 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 according to a biometric of a user obtained by the first device, the second key is a key generated according to an identifier of the first device, and the third key is a key generated according to an identifier of the first service. The processing module 1403 is further configured to encrypt the information that needs to be verified for the first service according to the target key.

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

In a possible implementation manner, 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.

In one possible implementation, the transceiver module 1401 is further configured to obtain the identity of the first service from the second device. The processing module 1403 is further configured to generate the target key according to a first key, a second key and a third key, where the first key is a key generated according to a biometric feature of the user acquired by the first device, the second key is a key generated according to an identifier of the first device, and the third key is a key generated according to an identifier of the first service. The processing module 1403 is further configured 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 further configured 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 according to the private key of the server.

Referring to fig. 15, a schematic structural diagram of another second apparatus provided by the present application is as follows.

The second device may include a processor 1501 and a memory 1502. The processor 1501 and the memory 1502 are interconnected by wires. Wherein program instructions and data are stored in memory 1502.

The memory 1502 stores program instructions and data corresponding to the steps of fig. 5-12.

The processor 1501 is configured to perform the method steps performed by the second device as described in any of the embodiments of fig. 5-12.

A transceiver 1503 for receiving or transmitting data.

Alternatively, the home device shown in fig. 15 described above may be a chip.

Referring to fig. 16, another schematic structure of the first apparatus provided by the present application is as follows.

The first device may include a processor 1601 and a memory 1602. The processor 1601 and the memory 1602 are interconnected by wires. Wherein program instructions and data are stored in memory 1602.

The memory 1602 stores program instructions and data corresponding to the steps in fig. 5 to 12.

The processor 1601 is configured to perform method steps performed by the first device as described in any of the previous embodiments shown in fig. 5-12.

A transceiver 1603 for receiving or transmitting data.

Alternatively, the aforementioned access control node shown in fig. 16 may be a chip.

Referring to fig. 17, a schematic structural diagram of a server according to the present application is described below.

The server may include a processor 1701 and a memory 1702. The processor 1701 and the memory 1702 are interconnected by a wire. Wherein program instructions and data are stored in memory 1702.

The memory 1702 stores program instructions and data corresponding to the steps of fig. 5-12.

The processor 1701 is configured to perform the method steps performed by the server as described in any of the embodiments of fig. 5-12.

A transceiver 1703 for receiving or transmitting data.

Alternatively, the aforementioned access control node shown in fig. 17 may be a chip.

Embodiments of the present application also provide a computer-readable storage medium having a program stored therein, which when run on a computer causes the computer to perform the steps of the method described in the embodiments shown in fig. 5-12 described above.

The embodiment of the application also provides an information management device, which can also be called a digital processing chip or a chip, wherein the chip comprises 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, and the processing unit is used for executing the method steps shown in any embodiment of the foregoing fig. 5-12.

The embodiment of the application also provides a digital processing chip. The digital processing chip has integrated therein circuitry and one or more interfaces for implementing the above-described processor, or functions of the processor. When the memory is integrated into the digital processing chip, the digital processing chip may perform the method steps of any one or more of the preceding embodiments. When the digital processing chip is not integrated with the memory, the digital processing chip can be connected with the external memory through the communication interface. The digital processing chip implements the method steps described above in any of the embodiments of fig. 5-12 according to program code stored in an external memory.

Embodiments of the present application also provide a computer program product which, when run on a computer, causes the computer to perform the steps of the method described in the embodiments shown in figures 5-12 above.

The information management device provided by the embodiment of the application can be a chip, and the chip comprises a processing unit and a communication unit, wherein the processing unit can be a processor, and the communication unit can be an input/output interface, a pin, a circuit or the like. The processing unit may execute the computer-executable instructions stored in the storage unit to cause the chip in the server to perform the method described in the embodiments shown in fig. 5-12. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, or the like, and the storage unit may also be a storage unit in the wireless access device side located outside the chip, such as a read-only memory (ROM) or other type of static storage device that may store static information and instructions, a random access memory (random access memory, RAM), or the like.

In particular, the aforementioned processing unit or processor may be a central processing unit (central processing unit, CPU), a Network Processor (NPU), a graphics processor (graphics processing unit, GPU), a digital signal processor (DIGITAL SIGNAL processor, DSP), an Application Specific Integrated Circuit (ASIC) or field programmable gate array (field programmable GATE ARRAY, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. The general purpose processor may be a microprocessor or may be any conventional processor or the like.

It should be further noted that the above-described apparatus embodiments are merely illustrative, and that the units described as separate units may or may not be physically separate, and that units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the drawings of the embodiment of the device provided by the application, the connection relation between the modules represents that the modules have communication connection, and can be specifically implemented as one or more communication buses or signal lines.

From the above description of the embodiments, it will be apparent to those skilled in the art that the present application may be implemented by means of software plus necessary general purpose hardware, or of course by means of special purpose hardware including application specific integrated circuits, special purpose CPUs, special purpose memories, special purpose components, etc. Generally, functions performed by computer programs can be easily implemented by corresponding hardware, and specific hardware structures for implementing the same functions can be varied, such as analog circuits, digital circuits, or dedicated circuits. But a software program implementation is a preferred embodiment for many more of the cases of the present application. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a readable storage medium, such as a floppy disk, a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access memory (random access memory, RAM), a magnetic disk or an optical disk of a computer, etc., including several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to execute the method according to the embodiments of the present application.

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

The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may 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 may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be stored by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Drive (SSD)), etc.

The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It should be noted that the above is only a specific embodiment of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes or substitutions are covered by the scope of the present application.

Claims (67)

1. The identity information management system is characterized by comprising 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 by a first service and an identifier of the first service;

the second device is further configured to establish a binding relationship between a public key of the second device and the identifier of the first service;

The first device is configured to obtain, from the second device, a type of identity information to be verified for the first service, and obtain, from identity information locally stored in the first device, identity information to be verified for the first service according to the type of identity information to be verified for the first service, where a binding relationship exists between the identity information to be verified for the first service and a public key of the second device, and the public key of the second device corresponds to the unique identity information to be verified for the first service.

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

3. The system of claim 2, further comprising a blockchain node,

The first device is further configured to send encrypted identity information to be verified for the first service to the blockchain node;

the blockchain node is configured to establish a binding relationship between the encrypted identity information required to be verified by the first service and the public key of the second device.

4. The system of claim 2, wherein the first device is further configured to send, to the second device, the encrypted identity information that the first service needs to be verified;

the second device is further configured to establish a binding relationship between the encrypted identity information required to be verified by the first service and a public key of the second device.

5. The system of claim 3 or 4, wherein the system comprises a plurality of sensors,

And the first device is further configured to delete the encrypted identity information of the first service that needs to be verified, which is stored locally in the first device, after the encrypted identity information of the first service that needs to be verified is sent.

6. The system of any one of claim 1 to 4, wherein,

The first device is further configured to obtain a biometric feature of a user, and generate a private key of the first device according to the biometric feature.

7. The system of any one of claim 1 to 4, wherein,

The first device is further configured to register a decentralized identity DID using a public key of the first device.

8. The system of any one of claim 1 to 4, wherein,

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 of claim 8, wherein the system further comprises a controller configured to control the controller,

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 the identifier of the first service, the identity information that needs to be verified by the first service, and the private key of the first device.

10. The identity information management system is characterized by comprising 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 used for responding to the access request and sending an Identity Request (IR) message to the second equipment, wherein the IR message carries the identification of the first service;

the second device is further configured to search, according to the identifier of the first service, a public key of the second device that is bound to the identifier of the first service;

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 obtain identity information to be verified of the first service bound to a public key of the second device after verifying that the digital signature of the second device is from the second device;

the first device is further configured to generate a digital signature of the first device according to a 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 a digital signature of the first device, and obtain identity information to be verified by the first service after verifying that the digital signature of the first device is from the first device.

11. The system of claim 10, wherein the system further comprises a blockchain node;

The first device is specifically configured to obtain, from the blockchain node, encrypted identity information to be verified of the first service bound to a public key of the second device, decrypt, according to a private key of the first device, the encrypted identity information to be verified of the first service, and obtain the identity information to be verified of the first service.

12. The system of claim 10, wherein the system further comprises a controller configured to control the controller,

The first device is specifically configured to obtain, from the second device, encrypted identity information to be verified of the first service, where the encrypted identity information is bound to a public key of the second device, and decrypt, according to a private key of the first device, the encrypted identity information to be verified of the first service, so as to obtain the identity information to be verified of the first service.

13. The system of claim 10, wherein the system further comprises a controller configured to control the controller,

The first device is specifically configured to locally obtain, from the first device, encrypted identity information that needs to be verified for the first service, and decrypt, according to a private key of the first device, the encrypted identity information that needs to be verified for the first service, so as 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, wherein,

And the first device is further configured to delete the private key of the first device and the identity information to be verified 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, wherein,

The first device is further configured to obtain a biometric feature of the user after verifying that the digital signature of the second device is from the second device, and generate a private key of the first device according to the biometric feature.

16. The identity information management system is characterized by comprising 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 by a 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 by the first service, and obtain, from identity information that is locally stored by the first device, the identity information that needs to be verified by the first service, where the first service needs to be verified 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 according to a biometric feature of a user obtained by the first device, the second key is a key generated according to an identifier of the first device, and the third key is a key generated according to an identifier of the first service;

The first device is further configured to encrypt, according to the target key, identity information that needs to be verified by the first service.

17. The system of claim 16, wherein the system further comprises a controller configured to control the controller,

The first device is further configured to delete the first key, the second key, the third key, and the target key.

18. The system of claim 16 or 17, wherein the system comprises a plurality of sensors,

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. The identity information management system is characterized by comprising 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 used for responding to the access request and sending an Identity Request (IR) message to the second equipment, wherein the IR message carries the identification of the first service;

the first device is configured to obtain, from the second device, an identifier of the first service;

The first device is further configured to generate a target key according to a first key, a second key and a third key, where the first key is a key generated according to a biological feature of a user acquired by the first device, the second key is a key generated according to an identifier of the first device, and the third key is a key generated according to an identifier of a first service;

the first device is further configured to decrypt the encrypted identity information of the first service that needs to be verified according to the target key, so as to obtain the identity information of the first service that needs to be verified;

the first device is further configured to encrypt the identity information to be verified of the first service according to the public key of the server, so that the server obtains the identity information to be verified of the first service after decrypting according to the private key of the server.

20. The system of claim 19, wherein the system further comprises a controller configured to control the controller,

The first device is further configured to delete the first key, the second key, the third key, and the target key.

21. The system of claim 19 or 20, wherein the system comprises a plurality of sensors,

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 of identity information management, characterized by being applied to an identity information management system, the identity information management system comprising a first device, a second device and a server, the method comprising:

the second device initiates a registration request to a server;

the second device receives a first message sent by the server in response to the registration request, wherein the first message carries the identity information type of a first service to be verified and the identification of the first service;

The second device establishes a binding relationship between a public key of the second device and the identifier of the first service;

The second device sends the identity information type to be verified of the first service to the first device, so that the first device obtains the identity information to be verified of the first service from the identity information locally stored in the first device according to the identity information type to be verified of the first service, a binding relationship exists between the identity information to be verified of the first service and a public key of the second device, and the public key of the second device corresponds to the unique identity information to be verified of the first service.

23. The method of claim 22, wherein the method further comprises:

The second equipment receives the encrypted identity information, which is sent by the first equipment and needs to be verified, of the first service;

And the second equipment establishes a binding relation between the encrypted identity information required to be verified by the first service and the public key of the second equipment.

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, which are sent by the first device.

25. A method of identity information management, characterized by being applied to an identity information management system, the identity information management system comprising a first device, a second device and a server, the method comprising:

The first device obtains the identity information type of the first service to be verified from the second device, and obtains the identity information of the first service to be verified from the identity information locally stored in the first device according to the identity information type of the first service to be verified, a binding relationship exists between the identity information of the first service to be verified and the public key of the second device, and the public key of the second device corresponds to the unique identity information of the first service to be verified.

26. The method of claim 25, wherein the method further comprises:

The first device establishes a binding relationship between identity information to be verified by the first service and a public key of the second device.

27. The method of claim 25, wherein the method further comprises:

And the first equipment encrypts the identity information to be verified of the first service according to the public key of the first equipment.

28. The method of claim 27, wherein the system further comprises a blockchain node, the method further comprising:

And the first equipment sends the encrypted identity information required to be verified by the first service to the blockchain node so that the blockchain node establishes a binding relationship between the encrypted identity information required to be verified by the first service and the public key of the second equipment.

29. The method of claim 27, wherein the method further comprises:

and the first equipment sends the encrypted identity information to be verified of the first service to the second equipment so that the second equipment establishes a binding relationship between the encrypted identity information to be verified of the first service and a public key of the second equipment.

30. The method according to claim 28 or 29, wherein the method further comprises:

And after the first equipment sends the encrypted identity information of the first service needing verification, deleting the encrypted identity information of the first service needing verification, which is stored locally by the first equipment.

31. The method according to any one of claims 25 to 29, further comprising:

the first device obtains a biometric feature of a user and generates a private key of the first device according to the biometric feature.

32. The method according to any one of claims 25 to 29, further comprising:

The first device registers the decentralized identity DID using a public key of the first device.

33. The method according to any one of claims 25 to 29, further comprising:

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, further comprising:

The first device obtains the identification of the first service from the second device;

the first device generating a private key of the second device, comprising:

and the first equipment generates the private key of the second equipment according to the identification of the first service, the identity information required to be verified by the first service and the private key of the first equipment.

35. A second device for use in an identity information management system, the identity information management system comprising a first device, the second device, and a server, the second device comprising:

the receiving and transmitting module is used for initiating a registration request to the server;

The receiving and transmitting module is further configured to receive 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 by a first service and an identifier of the first service;

the processing module is used for establishing a binding relation between the public key of the second equipment and the identifier of the first service;

The receiving-transmitting module is further configured to send, to the first device, a type of identity information that needs to be verified by the first service, so that the first device obtains, from identity information locally stored in the first device, the identity information that needs to be verified by the first service according to the type of identity information that needs to be verified by the first service, where a binding relationship exists between the identity information that needs to be verified by the first service and a 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 by the first service.

36. The second apparatus of claim 35, wherein the second apparatus comprises a plurality of sensors,

The receiving and transmitting module is further used for receiving the encrypted identity information, which is sent by the first device and needs to be verified, of the first service;

The processing module is further configured to establish a binding relationship between the encrypted identity information to be verified of the first service and the public key of the second device.

37. The second device according to claim 35 or 36, wherein,

The receiving and transmitting module is further configured to receive a private key of the second device and a public key of the second device, where the private key and the public key are sent by the first device.

38. A first device for use in an identity information management system, the identity information management system comprising the first device, a second device and a server, the first device comprising:

the receiving and transmitting module is used for acquiring the type of the identity information required to be verified of the first service from the second equipment, acquiring the identity information required to be verified of the first service from the storage module of the first equipment according to the type of the identity information required to be verified of the first service, wherein a binding relationship exists between the identity information required to be verified of the first service and the public key of the second equipment, and the public key of the second equipment corresponds to the unique identity information required to be verified of the first service.

39. The first device of claim 38, wherein the device further comprises a processing module for:

and establishing a binding relation between the identity information to be verified of the first service and the public key of the second device.

40. The first device of claim 39, wherein the processing module is further configured to:

and encrypting the identity information to be verified of the first service according to the public key of the first device.

41. The first device of claim 40, wherein the system further comprises a blockchain node, the transceiver module further configured to:

And sending the encrypted identity information of the first service to be verified to the blockchain node so that the blockchain node establishes a binding relationship between the encrypted identity information of the first service to be verified and the public key of the second device.

42. The first device of claim 40, wherein the transceiver module is further configured to:

and the first equipment sends the encrypted identity information to be verified of the first service to the second equipment so that the second equipment establishes a binding relationship between the encrypted identity information to be verified of the first service and a public key of the second equipment.

43. The first device of claim 41 or 42, wherein the processing module is further configured to:

And after the first equipment sends the encrypted identity information of the first service needing verification, deleting the encrypted identity information of the first service needing verification, which is stored locally by the first equipment.

44. The first device of any of claims 39 to 42, wherein the processing module is further configured to:

And generating a private key of the first device according to the biological characteristics of the user.

45. The first device of any of claims 39 to 42, wherein the processing module is further configured to:

And registering the decentralized identity DID by using the public key of the first device.

46. The first device of any of claims 39 to 42, wherein 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, to the second device, a private key of the second device and a public key of the second device.

47. The first device of any of claims 39 to 42, wherein the transceiver module is further configured to:

acquiring an identification of the first service from the second equipment;

the processing module is specifically configured to generate a private key of the second device according to the identifier of the first service, the identity information that needs to be verified by the first service, and the private key of the first device.

48. A method of identity information management, characterized by being applied to an identity information management system, the identity information management system comprising a first device, a second device and a server, the method comprising:

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, wherein the IR message carries an identifier of a first service;

the second device searches the public key of the second device bound with the first service identifier according to the identifier of the first service;

The second device generates a digital signature of the second device by using a private key of the second device corresponding to the public key 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 identity information which is bound with the public key of the second device and needs to be verified by the first service.

49. A method of identity information management, characterized by being applied to an identity information management system, the identity information management system comprising a first device, a second device and a server, the method comprising:

After the first equipment verifies that the digital signature of the second equipment comes from the second equipment, acquiring identity information which is bound with the public key of the second equipment and needs to be verified by a first service, wherein the public key of the second equipment corresponds to the unique identity information which needs to be verified by the first service;

The first device generates a digital signature of the first device according to the private key of the first device, wherein the digital signature carries identity information to be verified of the first service.

50. The method of claim 49, wherein the system further comprises a blockchain node, wherein the first device, after verifying that the digital signature of the second device is from the second device, obtains identity information that the first service bound to the public key of the second device needs to verify, comprising:

After the first device verifies that the digital signature of the second device comes from the second device, the encrypted identity information of the first service, which is bound with the public key of the second device, is obtained from the blockchain node, and the encrypted identity information of the first service, which is required to be verified, is decrypted according to the private key of the first device, so that the identity information of the first service, which is required to be verified, is obtained.

51. A method as defined in claim 49, wherein the first device, after verifying that the digital signature of the second device is from the second device, obtaining identity information to be verified for the first service bound to the public key of the second device comprises:

After the first device verifies that the digital signature of the second device comes from the second device, the encrypted identity information of the first service, which is bound with the public key of the second device and needs to be verified, is obtained from the second device, and the encrypted identity information of the first service, which needs to be verified, is decrypted according to the private key of the first device, so that the identity information of the first service, which needs to be verified, is obtained.

52. A method as defined in claim 49, wherein the first device, after verifying that the digital signature of the second device is from the second device, obtaining identity information to be verified for the first service bound to the public key of the second device comprises:

After the first device verifies that the digital signature of the second device comes from the second device, the encrypted identity information of the first service to be verified is locally obtained from the first device, and the encrypted identity information of the first service to be verified is decrypted according to the private key of the first device so as to obtain the identity information of the first service to be verified.

53. The method of any one of claims 49 to 52, further comprising:

After the first device sends the digital signature of the first device, deleting the private key of the first device and the identity information to be verified by the first service.

54. The method of any one of claims 49 to 52, further comprising:

And after the first equipment verifies that the digital signature of the second equipment comes from the second equipment, acquiring the biological characteristics of the user, and generating a private key of the first equipment according to the biological characteristics.

55. A second device, characterized by being applied to an identity information management system, the identity information management system including a first device, the second device, and a server, the second device comprising:

The receiving and transmitting module is used for initiating an access request to the server;

The receiving and transmitting module is further configured to receive an identity request IR message sent by the server in response to the access request, where the IR message carries an identifier of a first service;

The processing module is used for searching the public key of the second equipment bound with the first service identifier according 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 receiving-transmitting module is further configured to send the digital signature of the second device and the public key of the second device to the first device, so that after the first device verifies that the digital signature of the second device comes from the second device, the identity information, which is bound with the public key of the second device and needs to be verified, of the first service is obtained.

56. A first device for use in an identity information management system, the identity information management system comprising a first device, a second device, and a server, the first device comprising:

The processing module is used for acquiring identity information to be verified of a first service bound with a public key of second equipment after verifying that the digital signature of the second equipment comes from the second equipment, wherein the public key of the second equipment corresponds to the unique identity information to be verified of the first service;

the processing module is further configured to generate a digital signature of the first device according to a private key of the first device, where the digital signature carries identity information that needs to be verified by the first service.

57. The first device of claim 56, wherein said system further comprises a blockchain node, said processing module being specifically configured to:

After the digital signature of the second equipment is verified, acquiring encrypted identity information, which is bound with a public key of the second equipment, of the first service to be verified from the blockchain node, decrypting the encrypted identity information, which is required to be verified, of the first service according to a private key of the first equipment, so as to acquire the identity information, which is required to be verified, of the first service.

58. The first device of claim 56, wherein said processing module is specifically configured to:

after verifying that the digital signature of the second device comes from the second device, acquiring encrypted identity information, which is bound with the public key of the second device and needs to be verified, of the first service from the second device, decrypting the encrypted identity information, which needs to be verified, of the first service according to the private key of the first device, so as to acquire the identity information, which needs to be verified, of the first service.

59. The first device of claim 56, wherein said processing module is specifically configured to:

After the first device verifies that the digital signature of the second device comes from the second device, the encrypted identity information of the first service to be verified is locally obtained from the first device, and the encrypted identity information of the first service to be verified is decrypted according to the private key of the first device so as to obtain the identity information of the first service to be verified.

60. The first device of any one of claims 56 to 59, wherein said processing module is further configured to:

After the receiving and transmitting module sends the digital signature of the first device, deleting the private key of the first device and the identity information to be verified of the first service.

61. The first device of any one of claims 56 to 59, wherein said processing module is further configured to:

After verifying that the digital signature of the second device comes from the second device, the biometric feature of the user is obtained, and a private key of the first device is generated according to the biometric feature.

62. A second device comprising a processor coupled to a memory, the memory storing a program that when executed by the processor performs the method of any of claims 22 to 24 or performs the method of claim 48.

63. A first device comprising a processor coupled to a memory, the memory storing a program that when executed by the processor performs the method of any one of claims 25 to 34 or performs the method of any one of claims 49 to 54.

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

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

66. A computer program product comprising computer programs/instructions which when executed by a processor implement the method of any of claims 22 to 24 or the method of claim 48.

67. A computer program product comprising computer programs/instructions which when executed by a processor implement the method of any of claims 25 to 34 or the method of any of claims 49 to 54.