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

Information management system, method and device Download PDF

Info

Publication number
CN115720137A
CN115720137A CN202110977568.9A CN202110977568A CN115720137A CN 115720137 A CN115720137 A CN 115720137A CN 202110977568 A CN202110977568 A CN 202110977568A CN 115720137 A CN115720137 A CN 115720137A
Authority
CN
China
Prior art keywords
service
identity information
verified
needs
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110977568.9A
Other languages
Chinese (zh)
Inventor
康鑫
朱成康
王海光
李铁岩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202110977568.9A priority Critical patent/CN115720137A/en
Publication of CN115720137A publication Critical patent/CN115720137A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

The application provides a system, a method and a device for information management, wherein a user grasps complete identity information of the user through first equipment, and second equipment acquires identity information required to be verified by different services through different second public keys, so that privacy protection of the identity information of the user is enhanced. The method comprises the following steps: the second device initiates a registration request to the server. The server sends the type of the information which needs to be verified by the first service and the identification 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 the information which needs to be verified of the first service from the second device, and obtains the information which needs to be verified of the first service from the information which is locally stored in the first device according to the type of the information which needs to be verified of the first service, and a binding relationship exists between the information which needs to be verified of the first service and a public key of the second device.

Description

Information management system, method and device
Technical Field
The present application relates to the field of artificial intelligence security, and in particular, to a method and an apparatus for image processing.
Background
With the generalization and diversification of network activities, various identities are flooded in the network space, and the management of network identities faces a lot of serious problems.
The phenomena of identity information leakage, network fraud, network bank fund stealing and the like caused by improper network identity management frequently occur, and great hidden dangers are brought to the safety of lives and properties of people. In addition, the digitization of social activities enables personal sensitive identity data to be spread in a plurality of different network applications, more and more enterprises have the role of identity management, whether identity information can be safely and effectively managed, whether identity management services are reliable or not and the like, and the problems are widely concerned.
Disclosure of Invention
The embodiment of the application provides a system, a method and a device for identity information management, aiming at different identity information which needs to be verified of each service, different service identities are generated, and effective protection is carried out on data privacy and safety of a user.
In view of the above, a first aspect of the present application provides a system for identity information management, including: the device comprises a first device, a second device and a server. And the second equipment 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 type of the identity information needing to be verified of the first service and the identifier of the first service. And the second device is also used for establishing a binding relationship between the public key of the second device and the identifier of the first service. The first device is used for acquiring the type of the identity information which needs to be verified of the first service from the second device, and acquiring the identity information which needs to be verified of the first service from the identity information which is locally stored in the first device according to the type of the identity information which needs to be verified of the first service, wherein a binding relationship exists between the identity information which needs to be verified of the first service and a 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 device, and other devices except the first device cannot acquire the complete identity information of the user, so that privacy protection of the identity information of the user is enhanced. In addition, for the difference of the identity information required to be verified for each service, the public key of the different second device is bound with the identity information required to be verified for different services. Equivalently, a plurality of subordinate identities are provided for each master 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 cannot 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, to the block link node, the encrypted identity information that the first service needs to be verified. And the block chain node is used for establishing a binding relationship between the encrypted identity information of the first service to be verified and the public key of the second device. In this embodiment, the identity information that the first service needs to be authenticated is stored on the blockchain node. The identity information of the first service needing to be verified is maintained by the block link nodes, the identity information of the first service needing to be verified 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, to the second device, identity information that the encrypted first service needs to be verified. The second device is further configured to establish a binding relationship between the encrypted identity information that needs to be verified for the first service and a public key of the second device. In the embodiment, the identity information of the first service needing to be verified is stored on the second device, and the storage resource and the communication resource of the block chain are saved.
In a first possible implementation manner of the first aspect, the first device is further configured to delete the encrypted identity information, which is locally stored in the first device and needs to be verified, of the first service after the encrypted identity information, which needs to be verified, of the first service is sent. In this embodiment, after the registration is completed, after the identity information that needs to be verified for the encrypted first service has been stored on the second device or the blockchain, the encrypted first service locally stored in the first device may be deleted, so as to save local storage resources 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 this embodiment, the private key of the first device may be generated according to the biometric feature of the user, so that the first device does not need to locally store the private key of the first device, and when the first device is lost, the risk of losing the private key is avoided.
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, the DID is registered by the first public key, so that the first public key is bound to the unique DID, and after the server side acquires the DID, the server side may query the first public key according to the DID, and verify the identity based on the first public key, for example, verify that the received digital signature comes from the first device. If different first devices employ the same first public key, it may result in the DID obtained 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 also checks the acquired DID, and if the same DID is not stored in the current blockchain, the registration is considered to be 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, from the second device, an identifier of the first service. 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 the first service needs to be verified, 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: the device comprises a first device, a second device and a server. And the second equipment 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 identifier 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. And the second device is further used for generating 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 sending the digital signature of the second device and the public key of the second device to the first device. And the first device is used for acquiring the identity information which is bound with the public key of the second device and needs to be verified of the first service after the digital signature of the second device is verified to come 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 for the first service. And the server is further used for acquiring the digital signature of the first device, and acquiring the identity information of the first service which needs to be verified after the digital signature of the first device is verified to come from the first device.
In a first possible implementation of the second aspect, the system further comprises a blockchain node. The first device is specifically configured to acquire, from the block link point, the encrypted identity information of the first service that needs to be verified and 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 of the first service that needs to be verified, so as to acquire the identity information of the first service that needs to be verified.
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 and 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 of the first service, and decrypt, according to a 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 further configured to delete a private key of the first device and 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 feature of the user after verifying that the digital signature of the second device comes from the second device, and generate a private key of the first device according to the biometric feature.
Third aspect an embodiment of the present application provides a system for identity information management, including: the system comprises a first device, a second device and a server. And the second equipment 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 type of the identity information needing to be verified of the first service and the identifier of the first service. The first device is configured to obtain, from the second device, a type of identity information that needs to be verified for the first service, and obtain, 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 from the identity information locally stored in the first device, where 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 the identifier of the first service. The first device is further configured to perform encryption processing on the identity information that needs to be verified for the first service according to the target key.
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, comprising: the device comprises a first device, a second device and a server. And the second equipment 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 identifier 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 the biometric features of the user acquired by the first device, the second key is a key generated according to the identifier of the first device, and the third key is a key generated according to the identifier of the first service. The first device is further configured to decrypt, according to the target key, the encrypted identity information of the first service, which needs to be verified, and obtain the identity information of the first service, which needs to be verified. The first device further encrypts the identity information of the first service, which needs to be verified, by using the public key according to the server, so that the server obtains the identity information of the first service, which needs to be verified, 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.
Fifth aspect, an identity information management method provided in an embodiment of the present application 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 a registration request to the server. And the second equipment receives a first message sent by the server in response to the registration request, wherein the first message carries the type of the identity information needing to be verified of the first service and the identifier of the first service. The second device establishes a binding relationship between the public key of the second device and the identifier of the first service. The second device sends the type of the identity information which needs to be verified of the first service to the first device, so that the first device obtains the identity information which needs to be verified of the first service from the identity information which is locally stored in the first device according to the type of the identity information which needs to be verified of the first service, and a binding relationship exists between the identity information which needs to be verified of the first service and a public key of the second device.
In a first possible implementation of the fifth aspect, the method further comprises: and 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 relationship between the encrypted identity information of the first service to be verified and the public key of the second equipment.
In a first possible implementation of the fifth aspect, the method further comprises: the second device receives the private key of the second device and the public key of the second device sent by the first device.
In a first possible implementation manner of the fifth aspect, the application is 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 method comprises the steps that the first device obtains the type of identity information needing to be verified of a first service from the second device, and obtains the identity information needing to be verified of the first service from the identity information locally stored in the first device according to the type of the identity information needing to be verified of the first service, wherein a binding relation exists between the identity information needing to be verified of the first service and a public key of the second device.
In a first possible implementation of the fifth aspect, the method further comprises: the first device establishes a binding relationship between the identity information to be verified of the first service and a public key of the second device.
In a first possible implementation of the fifth aspect, the method further comprises: and the first equipment encrypts the identity information which needs to be verified of the first service according to the public key of the first equipment.
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 sends the encrypted identity information of the first service to be verified to the block link point, so that the block link point establishes a binding relationship between the encrypted identity information of the first service to be verified and a public key of the second device.
In a first possible implementation of the fifth aspect, the method further comprises: the first device sends the encrypted identity information of the first service to be verified to the second device, so that the second device establishes a binding relationship between the encrypted identity information of the first service to be verified and a public key of the second device.
In a first possible implementation of the fifth aspect, the method further comprises: and after the first device sends the encrypted identity information which needs to be verified of the first service, deleting the encrypted identity information which needs to be verified of the first service and is locally stored in the first device.
In a first possible implementation of the fifth aspect, the method further comprises: the first device obtains the biological characteristics of the user and generates a private key of the first device according to the biological characteristics.
In a first possible implementation of the fifth aspect, the method further comprises: the first device registers the decentralized identity DID with the public key of the first device.
In a first possible implementation of the fifth aspect, the method further comprises: the first device generates a private key of the second device and a public key of the second device, and transmits the private key of the second device and the public key of the second device to the second device.
In a first possible implementation of the fifth aspect, the method further comprises: the first device obtains the identifier of the first service from the second device. The first device generates a private key of the second device, comprising: and the first equipment generates a private key of the second equipment according to the identification of the first service, the identity information which needs to be verified by the first service and the private key of the first equipment.
A sixth aspect of the present embodiment provides a method for managing identity information, where the method 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. And the second equipment 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 equipment searches the public key of the second equipment bound with the first service identification according to the identification 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 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.
In a first possible implementation manner of the sixth aspect, the method 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: after the first device verifies that the digital signature of the second device comes from the second device, identity information, which is bound with the public key of the second device and needs to be verified, of the first service is obtained. 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 which needs to be verified by the first service.
In a first possible implementation manner of the sixth aspect, the system further includes a blockchain node, and after the first device verifies that the digital signature of the second device comes from the second device, the obtaining of identity information, which is bound to a public key of the second device and needs to be verified, of the first service includes: after the first device verifies that the digital signature of the second device comes from the second device, the encrypted identity information, which is bound with the public key of the second device and needs to be verified, of the first service is obtained from the link point of the block, and the encrypted identity information, which needs to be verified, of the first service is decrypted according to the private key of the first device, so that the identity information, which needs to be verified, of the first service is obtained.
In a first possible implementation manner of the sixth aspect, after the first device verifies that the digital signature of the second device comes from the second device, acquiring identity information that needs to be verified for the first service bound with the public key of the second device, includes: after the first device verifies that the digital signature of the second device comes from the second device, the encrypted identity information, which is bound with the public key of the second device and needs to be verified, of the first service is obtained from the second device, and the encrypted identity information, which needs to be verified, of the first service is decrypted according to the private key of the first device, so that the identity information, which needs to be verified, of the first service is obtained.
In a first possible implementation manner of the sixth aspect, after the first device verifies that the digital signature of the second device comes from the second device, acquiring identity information that needs to be verified for the first service bound with the public key of the second device, includes: after the first device verifies that the digital signature of the second device comes from the second device, the encrypted identity information of the first service, which needs to be verified, is locally obtained from the first device, and the encrypted identity information of the first service, which needs to be verified, is decrypted according to a private key of the first device, so that the identity information of the first service, which needs to be verified, is obtained.
In a first possible implementation of the sixth aspect, the method further comprises: and after the first device sends the digital signature of the first device, deleting the private key of the first device and the identity information which needs to be verified by the first service.
In a first possible implementation manner of the sixth aspect, the method further includes the first device obtaining the biometric feature of the user after verifying that the digital signature of the second device comes from the second device, and generating the private key of the first device according to the biometric feature.
A seventh aspect of the embodiments of the present application provides a method for identity information management, where the method 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 a registration request to the server. The second device receives a first message sent by the server, wherein the first message carries the type of the identity information to be verified of the first service and the identifier of the first service.
An eighth aspect of the present application provides a method for identity information management, where the method 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 method comprises the steps that a first device obtains the type of identity information needing to be verified of a first service from a second device, and obtains the identity information needing to be verified of the first service from the identity information locally stored in the first device according to the type of the identity information needing to be verified of the first service, the identity information needing to be verified of the first service is bound with a target key, the target key is generated based on a first key, a second key and a third key, the first key is generated according to the biological characteristics of a user obtained by the first device, the second key is generated according to the identification of the first device, and the third key is generated according to the identification of the first service. And the first equipment encrypts the identity information which needs to be verified of the first service according to the target key.
A ninth aspect of the present application provides a method for identity information management, where the method 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. And the second equipment receives an Identity Request (IR) message sent by the server, wherein the IR message carries the identifier of the first service. And the second equipment sends the identification of the first service to the first equipment.
A tenth aspect of the embodiments of the present application provides a method for identity information management, where the method 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 the 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, wherein the first key is a key generated according to the biological characteristics of the 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. And the first equipment decrypts the encrypted identity information needing to be verified of the first service according to the target secret key so as to acquire the identity information needing to be verified of the first service. The first device encrypts the identity information, which needs to be verified, of the first service according to the public key of the server, so that the server obtains the identity information, which needs to be verified, of the first service after decrypting according to the private key of the server.
In an eleventh aspect, embodiments of the present application provide a second apparatus, where the second apparatus has a function of implementing the second apparatus in the method described in the above fifth aspect, seventh aspect, or ninth aspect. The function 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, the present embodiments provide a first device, where the second device has a function of implementing the first device in the method described in the above sixth aspect, eighth aspect, or tenth aspect. The function can be realized by hardware, and can also be realized by hardware executing corresponding software. 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 apparatus, including: a processor and a memory, wherein the processor and the memory are interconnected by a line, and the processor calls the program code in the memory to execute the processing-related functions of the method according to any one of the fifth aspect, the seventh aspect or the ninth aspect. 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, wherein the processor and the memory are interconnected by a line, and the processor calls the program code in the memory for executing the processing-related functions of 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, the present application provides an apparatus, which may also be referred to as a digital processing chip or chip, where the chip includes a processing unit and a communication interface, the processing unit obtains program instructions through the communication interface, and the program instructions are executed by the processing unit, and the processing unit is configured to execute the functions related to the processing in any of the optional implementations of the fifth aspect, the seventh aspect or the ninth aspect.
In a sixteenth aspect, embodiments of the present application provide an apparatus, which may also be referred to as a digital processing chip or a chip, where the chip includes a processing unit and a communication interface, and the processing unit obtains program instructions through the communication interface, and the program instructions are executed by the processing unit, and the processing unit is configured to execute functions related to processing in any of the optional implementations of the sixth aspect, the eighth aspect, or the tenth aspect.
In a seventeenth aspect, embodiments of the present application provide a computer-readable storage medium, which includes instructions that, when executed on a computer, cause the computer to perform the method of any one of the optional embodiments of the fifth aspect, the seventh aspect, or the ninth aspect.
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-mentioned sixth, 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 structural diagram of another identity management system according to an embodiment of the present application;
fig. 4 is a schematic diagram of an exemplary application scenario provided in the embodiment of the present application;
fig. 5 is a schematic flowchart of an information management method according to an embodiment of the present application;
fig. 6 is a schematic flowchart of another information management method according to an embodiment of the present application;
fig. 7 is a schematic flowchart of another information management method according to an embodiment of the present application;
fig. 8 is a schematic flowchart of another information management method according to an embodiment of the present application;
fig. 9 is a schematic flowchart of another information management method according to an embodiment of the present application;
fig. 10 is a schematic flowchart of another information management method according to an embodiment of the present application;
fig. 11 is a schematic flowchart of another information management method according to an embodiment of the present application;
fig. 12 is a schematic flowchart of another information management method according to an embodiment of the present application;
fig. 13 is a schematic structural diagram of a second apparatus according to an embodiment of the present disclosure;
fig. 14 is a schematic structural diagram of a first apparatus according to an embodiment of the present disclosure;
fig. 15 is a schematic structural diagram of another second apparatus provided in an embodiment of the present application;
fig. 16 is a schematic structural diagram of another first apparatus provided in 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 technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Centralized identity management refers to the issuance and control of a user's identity by an organization or server. The specific process is as follows: the user provides some information to the service provider and applies for an identity based on this information, the service provider generates an identity (typically a username and password) for the user, stores this 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, and a server of a service provider compares the user identity information stored in the server with the user identity information stored in the server, and allows the user to use the service after the user identity information passes verification. The most common scenario involves a user registering for a service, obtaining an account and password, logging in through the account and password, and using the service.
Centralized identity management schemes, organizations or central servers have complete control over the identity of users, including the ability to revoke, change, etc. the identity of users at any time, resulting in users not having the right to control the identity of users, or even being informed. In addition, when a system bug occurs in an organization or a central server, a large amount of user identity information may be leaked, and the identity information of the user is not guaranteed.
In order to solve the above problem, an embodiment of the present application provides an identity management scheme, which solves a potential security risk of user privacy disclosure brought by a centralized identity management scheme. Since the embodiments of the present application relate to a large amount of knowledge related to public keys, certificates, encryption, decryption, and signature technologies, for facilitating understanding of the solutions provided by the embodiments of the present application, the related knowledge will be first introduced.
A one-way hash function, also called a one-way hash (hash) function, is a function for changing an input message string of an arbitrary length into an output string of a fixed length, and making it difficult to obtain the input string from the output string. This output string is referred to as the hash value of the message. Typically for generating message digests, key encryption, etc. The one-way hash function includes the following advantages:
1. the length of the encrypted ciphertext is fixed (i.e., the resulting hash value is fixed for three columns of messages of any length).
2. If the plaintext is different, the hashed result must be different.
3. If the plaintext is the same, the encrypted ciphertext must be the same (the same data is encrypted, and the encrypted ciphertext is the same).
4. Has one-way performance and can not reversely calculate.
Asymmetric cryptography (asymmetric cryptography) is a type of cryptographic algorithm in which a pair of keys is required, one being a private key (referred to simply as the private key) and the other being a public key (referred to simply as the public key). The two keys are mathematically related, and the information obtained by encrypting the key of a certain user can be decrypted only by the decryption key of the user. If one is known, the other cannot be calculated. Thus, if one of a pair of keys is disclosed (public key), the secret nature of the other is not compromised (the secret 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 with the private key can be decrypted with the public key for the client to verify that the data or file issued by the party holding the private key is complete and accurate, and the receiver knows that the information really comes from someone who holds the private key, which is called a digital signature, and the public key is in the form of a digital certificate. For example, an installer downloaded from the web, typically with a digital signature of the program producer, can prove that the program was indeed issued by the author (company) and not forged and not tampered by a third party (authentication/verification).
The process of digital signature is further described below in conjunction with fig. 1: the data sending party performs HASH calculation on the text to be transmitted, and the obtained result is used as the abstract 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 takes the transmission text, but needs to confirm whether the text is the transmitted content and whether the text is tampered in the middle. Therefore, the signature is decrypted by taking the own held public key (the data encrypted by one key in the key pair can be decrypted by using the other key certainly), the digest of the text is obtained, then the HASH algorithm same as that of the sender is used for calculating the digest value, and then the digest value is compared with the digest obtained by decryption, if the two are completely consistent, the text is not tampered. The process of verifying whether the two are completely identical is the process of signature verification.
In the process of signing, a party receiving data needs to preserve a public key by self, but because each sender has a public key, the party receiving data needs to preserve a great number of public keys, and the problem of difficult management exists. And the locally stored public key can be possibly tampered and replaced without slave discovery. In order to solve this problem, a unified certificate authority may manage the public keys of all parties that need to send data, and authenticate and encrypt the public keys. This authority is also known as the Certificate Authority (CA) as we often speak. The encrypted public key is authenticated, i.e. a certificate, also called CA certificate, which contains much information, most importantly, the public key of the applicant. The CA organization uses a unified key pair to encrypt the public key, and uses the private key in the public key. Therefore, after the applicant takes the certificate, when the applicant sends data, the private key of the applicant generates a signature, the certificate and the sending content are sent to the other party, after the other party takes the certificate, the certificate needs to be decrypted to obtain a public key in the certificate, the public key in a 'unified key pair' of a CA (certificate authority) needs to be used for decryption, the public key is a commonly-known CA root certificate, and the public key usually needs to be downloaded to a certificate authority and installed on a corresponding client side for receiving the data, such as a browser. This public key only needs to be installed once. With the public key, the certificate can be decrypted, the public key of the sender is taken, then the signature sent by the sender is decrypted, the digest is obtained, the digest is recalculated, and the comparison is performed so as 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 authentication. The scheme provided by the embodiment of the application can enable the user to have an autonomous identity, namely, the user has an identity system with an autonomous right and a control right. The biggest difference between autonomous identity and centralized identity management is that a user has specific autonomous and control over identity, while a service provider does not have control over identity. In addition, more importantly, the scheme provided by the embodiment of the application can ensure that each service provider can only obtain partial identity information which needs to be verified by the service provider, cannot obtain complete identity information of the 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 leaked, and the safety of the identity information is further guaranteed.
Referring to fig. 2, a schematic structural diagram of an identity management system provided in the embodiment of the present application is shown. The scheme provided by the embodiment of the application at least relates to a three-party execution main body, and the three-party execution main body comprises a main identity management device, a device using the service and a server.
And the master identity management device is used for managing all identity information of the user. According to the scheme provided by the embodiment of the application, the user has the self-authority and the control right on the identity information, and all the identity information is kept by the user and can be stored on the master identity management equipment. In some possible embodiments, the master identity management device may be a device that the user can carry around, for example, the master identity management device may be a smart watch, smart glasses, a smart ring, or the like, and may also be other electronic devices such as a mobile phone.
A device for using the service, for using the service. For example, clients corresponding to different services can be installed on a device using the service, and a user can use different services by operating the client, such as using a shopping service, using a reading service, using a social service, using a game service, and the like. The device using the service may not store any identity information and may interact with the master identity management device to obtain partial identity information from the master identity management device. According to the scheme provided by the embodiment of the application, the service using equipment and the master identity management equipment are two different pieces of equipment, and the same master identity management equipment can correspond to a plurality of pieces of equipment using the service. In some possible embodiments, the device using the service may be a device facilitating installation of the service, such as a mobile phone, a PAD, and the like. Or other electronic devices such as a smart watch, smart glasses and a smart ring.
And the server is used for providing services for the equipment using the services. In some scenarios, the server does not need any identity information provided by the device using the service when the server allows the device using the service to access the server, and in other scenarios, the server needs the device using the service to provide the relevant identity information to allow the device using the service to access the server. The embodiment of the application focuses on a scenario that a server needs to provide related identity information by using a device of a service.
It should be noted that, although fig. 2 illustrates 3 servers, 4 devices using services and 2 master identity management devices, this does not represent a limitation to the number of them in the embodiment of the present application, and in a practical application scenario, more or fewer servers, devices using services and master identity management devices are included.
Referring to fig. 3, a schematic structural diagram of another identity management system provided in the embodiment of the present application is shown. The scheme provided by the embodiment of the application also relates to a block chain.
A Block chain consists of a series of growing records, which become blocks (blocks). The blocks are linked together by cryptographic techniques, each block containing the hash value, time stamp, transaction data, etc. of the previous block. The blockchain is essentially a distributed multi-backup database, but the most important difference from the database is that the storage of data is formed by multi-party consensus, and the hash chain is used for protecting historical data, so that the data cannot be tampered. Compared with the traditional database technology, the characteristic that the blockchain data cannot be tampered with is easier to obtain the trust of the user, so that the multi-party cooperation can be better supported. In general, the public key generated by the master identity management device is important, and it is also necessary to ensure that the public key generated by each master identity management device is unique, so that it is necessary to ensure that the public key generated by the master identity management device is authentic. Therefore, the application ensures that the tamper-proof property of the blockchain is adopted, decentralized Identity (DID) is registered on the blockchain through the public key, so that each public key corresponds to a unique DID, and the public key generated by each master identity management device is tamper-proof.
Based on the architectures described in fig. 2 and fig. 3, fig. 4 is a schematic diagram of a typical application scenario provided by the embodiment of the present application. As shown in fig. 4, the identity information of the user is diverse, such as name, date of birth, address, education level, medical record, income, and the like. The master identity management device may obtain the identity information through a variety of different channels, such as obtaining education level from a school and obtaining medical records from a hospital. The master identity management device locally generates a private key of the master 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 that owns the public key can verify the digital signature. Different services are installed on equipment using the services, the services are sometimes called services in the application, and the services have the same meaning when the difference between the services is not particularly emphasized. The identity information that needs to be verified for each service may be different, such as gaming class services that need to verify the user's age, financial class services that need to verify the user's income, 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 cannot acquire all information of the user. Specifically, in the embodiment of the present application, a plurality of service identities are set for a master identity, and in the embodiment of the present application, a device using a service has a plurality of public and private key pairs, a service is bound to a public key in each public and private key pair, and identity information that needs to be verified for the service is bound, so that the device using the service adopts an identity access service corresponding to the service, only identity information that needs to be verified for the service is provided in a verification stage, and the master identity is not used to access each service, and all identity information is not provided in the verification stage. By the method, the user has the specific self-authority and control right on the identity, each service provider can only obtain partial identity information which needs to be verified by the service provider, complete identity information of the user cannot be obtained, and the safety of the identity information of the user is ensured.
The following describes a scheme provided by an embodiment of the present application. The scheme provided by the embodiment of the present application may include an identity registration stage and an identity using stage, and a plurality of schemes provided by the embodiment of the present application will be described below from these two aspects respectively.
1. Identity registration phase-scheme 1
Fig. 5 is a schematic flow chart of an information management method according to an embodiment of the present application, as follows.
501. The first device generates a first private 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 specific manner of generating the first private key is not limited in this embodiment, and any manner capable of generating the first private key and the first public key corresponding to the first private key may be adopted in this embodiment. In this embodiment, the first private key and the public key related to the first private key may also be generated based on certain information, such as but not limited to a password set by the user, an identity number of the user, and a medical insurance account number of the user, so that the first private key and the first public key may be generated according to the certain information and a preselected 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 obtain the first private key from the private space when the first device needs to use the first private key. 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 according to some information provided by the user and the selected key generation algorithm and then used.
In another possible implementation, the first device obtains a biological characteristic of the user, generates a first private key according to the biological characteristic of the user, and generates a first public key corresponding to the first private key. The biometric features of the user include, but are not limited to, fingerprint information and iris information. In this embodiment, the first device does not need to 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 features of the user and then generate the first private key according to the biometric features of the user. Because 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, other people except the user cannot obtain 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, a smart ring, smart glasses, a smart bracelet, or the like. In most scenes, the user can carry the close-fitting intelligent devices close to the skin, and the embodiment of the application stores the main identity information of the user in the close-fitting intelligent devices, so that the user can better control the main identity information.
502. The first device registers a Decentralized IDentity (DID) with the first public key.
DID allows an individual or organization to fully own the identity of ownership, management and control of his digital identity and its data. Compared with the traditional identity system based on PKI, the DID digital identity system established based on the block chain has the characteristics of ensuring the trueness and credibility of data, protecting the privacy and safety of users, having strong portability and the like.
In some embodiments, the DID may be a unique identification indicating a mapping relationship between a real entity and a presentity. The DID may include a URL scheme identification, an identification for the DID method, and a DID method specific identification. Each DID may point to a corresponding DID document. The DID document may include descriptive text in a preset format (e.g., JSON-LD) about the DID and the owner of the DID. The DID may be used as a Uniform Resource Identifier (URI) for locating a DID document. The DID document may include various attributes such as context, DID 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 that defines a plurality of operations that may be performed with respect to the DID.
Verifiable Statements (VCs) may allow authorization, endorsement, and validation between different entities. In a business environment, a service or product provider can use its customers' DIDs and VCs to identify and authenticate customers and provide services or products accordingly.
In some embodiments, a VC may provide verifiable online information regarding the quality, characteristics, relationships, and other relevant information of an entity. The VC may contain descriptive text in a pre-set format (e.g., JSON-LD) that describes one or more statements about the DID (e.g., age of the DID owner, educational background of the DID owner) and an endorsement of the statements by the entity. The VC may include various attributes such as context, identification, type, credential topic, publisher, publication date, attestation, expiration date, status, representation, other suitable attributes, or any combination thereof. A VC may specify the type of its declaration (manifest), which may indicate the structure of the declaration. This may prompt the VC issuer and VC verifier to do the processing automatically.
The owner of the DID can 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 requires proof that the individual has been over 18 years old. The individual may be the owner of the DID and may request a VC issued by a governmental agency that provides citizen age verification. The business entity can verify the VC to ensure that the individual meets the age requirements. In this case, the individuals may be DID owners and VC holders; the government agency may be a VC publisher and the business entity may be a VC verifier.
In this embodiment of the application, the DID is registered by the first public key, so that the first public key is bound with the unique DID, and after the server side obtains the DID, the server side may query the first public key according to the DID, and verify the identity based on the first public key, for example, verify that the received digital signature comes from the first device.
If different first devices use the same first public key, it may result in the DID obtained 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 also checks the acquired DID, and if the same DID is not stored in the current blockchain, the registration is considered to be 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 a shopping-like service, a social-like service, a gaming-like service, and so forth. Generally, various services can be accessed only after a user registers, or a server of the service stores relevant data generated by the user in using the service after the user registers, and the relevant data can be acquired when the user accesses the service according to a registered account.
In the solution provided in the embodiment of the present application, after the second device initiates the registration request to the server, it is not necessary to wait for the server to generate an identity (generally, a user name and a password) for the user, and it is also not necessary for the server to issue the identity to the user. In the solution provided in the embodiment of the present application, the second device initiates a registration request to the server, so as to obtain identity information that the server needs to verify. The following steps will be specifically explained.
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 embodiment, the first message carries a category of identity information to be verified. For example, for the game class service, after the second device initiates the registration request to the game class server, the category carrying the identity information to be verified in the first message may include the age. For another example, for a social service, after the second device initiates a registration request to the social server, the category of the identity information to be verified carried in the first message may include an identification number, an academic calendar, and the like.
In a possible embodiment, the first message may also carry other information, such as a service identifier (service id), where the service identifier of each service is used to indicate a unique service. Or, the service identifier and the service are in a one-to-one correspondence relationship.
505. The second device sends a second message to the first device.
And after receiving the first message sent by the server, the second device acquires a second message according to the first message and sends the second message to the first combination.
In one possible implementation, the content carried by the second message is identical to the content carried by the first message. For example, the category of the identity information to be verified is carried in the first message, and the second device forwards the content carried in the first message to the first device through the second message, that is, the category of the identity information to be verified carried in the first message is also carried in the second message. For another example, the first message carries the category and the service identifier of the 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, that is, the second message also carries the category and the service identifier of the identity information to be verified carried by the first message.
In one possible implementation, the content carried in the second message may be part of the content carried in the first message. For example, the category and the service identifier of the identity information to be verified are carried in the first message, the second device may send only a part of the content in the content carried in the first message to the first device through the second message, for example, send only the category of the identity information to be verified carried in the first message to the first device through the second message.
It can be understood that the second message must carry the category of the identity information to be verified carried in the first message, in a preferred embodiment, the category may also carry a service identifier, and in addition, the second message may also carry other information.
In one possible embodiment, 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 the first device and the second device, and the second device sends the second message to the second device through a Transport Layer Security (TLS).
506. The first device obtains the identity information which needs to be verified by the service.
And searching the identity information corresponding to each category according to the category of the identity information needing to be verified, which is carried in the second message, wherein the searched identity information corresponding to each type forms the first identity information. Such as the first device having stored therein all of the user's identity information including, but not limited to, name, date of birth, address, education level, medical records, income, and the like. When the category indication of the identity information to be verified carried in the second message includes a name and a date of birth, the first device obtains the name and information corresponding to the date of birth from all the identity information, and assuming that the name of the user is zhang and the date of birth is 1/2000, the first identity information may include zhang and 1/2000, or the first identity information may include the name: zhang III; the date of birth: year 2000, 1 month and 1 day. The embodiment of the present application does not limit the specific representation 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 a possible implementation manner, the second device may generate a second private key and a second public key corresponding to the second private key, and the manner of generating the private key and the public key corresponding to the private key is not limited in the embodiments of the present application, and will not be described repeatedly below. 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 embodiment, the first device may derive the second private key according to the related information, and further may obtain the second public key according to the second private key. In this embodiment, the first device may derive the second private key according to the acquired information, and the first device may not need to store the second private key. For example, in one possible implementation, the first private key may be derived according to the first identity information, the first public key and the service identifier obtained through the above steps. Specifically, the first identity information, the first public key and the service identifier may be respectively used as parameters of a Key Derivation Function (KDF), the second private key is obtained according to a value of the KDF, and the second public key corresponding to the second private key is further 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 acquires the service identifier, for example, in step 505, the first device may also establish a correspondence between the service identifier and the first identity information. When the first device establishes the 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 and prevent the first identity information stored on the first device from being easily revealed, the first identity information may be encrypted by the first public key.
In one possible implementation, the first identity information and the service identifier may be encrypted according to the first public key.
510. And the first equipment sends the encrypted first identity information and the first identifier to the block chain.
The first identifier may be the second public key, and may also be a service identifier.
The first device may send a digital signature to the blockchain, where the digital signature carries the encrypted first identity information and the first identifier. After the blockchain verifies that the digital signature comes 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 id corresponds to a DID Document (DID Document).
And establishing a binding relation between the first identifier and the encrypted first identity information in the block chain. 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. And the second equipment establishes a binding relationship between the second public key and the service identifier.
In a possible implementation manner, the second device may generate the second private key and the second public key, and then after the first message acquired by the second device, the 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 transmitted by the first device. In a possible embodiment, the first device may send the second private key and the second public key to the second device through a secure channel, where the secure channel is understood with reference to the secure channel described in step 505, and details are not repeated here. In this embodiment, after receiving the second public key and the second private key sent by the first device, the second device establishes a binding relationship between the second public key and the service identifier, and since the second public key and the second private key are in a one-to-one correspondence relationship, it is equivalent to query the unique second private key according to the service identifier.
And after the second device acquires the second private key and the second public key, storing the second public key, 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, the second device may send a third message 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 a possible implementation manner, after the first device acquires the third message sent by the second device, the first identity information locally stored by the first device or the first identity information may be deleted.
In one possible implementation, if the first device is a first private key generated according to a biometric feature of the user, the first device may perform a deletion process on the locally stored first private key after acquiring the third message.
In a possible implementation manner, if the first device generates the second private key and the second public key, after the first device obtains the third message, the first device may delete the locally stored second private key.
It should be noted that, on the basis of 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 steps of: the first device prompts 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, and the prompt mode of the successful registration is not limited in the embodiment of the present application. For example, the user may be prompted that the service/service registration described in the above steps was successful. As another example, some steps may not be performed, such as in one possible embodiment, step 502, or step 508 may not be performed. In fact, the number of steps included in each embodiment described in the present application example may be more or less, and the description thereof is not repeated below.
In addition, it should be noted that, on the basis of the embodiment described in fig. 5, the order between the above-described steps 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 order of the steps in each embodiment described in the present application may be exchanged or the steps may be executed synchronously, and details are not repeated below.
As can be seen from the embodiment corresponding to fig. 5, in the registration phase, different identity information (first identity information) is generated for different identity information that needs to be verified for each service, and the different identity information is bound to different second public keys, which is equivalent to that in the embodiment of the present application, multiple subordinate identities are set for each master identity, and each subordinate identity is used for accessing one service. The user can master the complete identity information of the user through the first device, and other devices except the first device cannot acquire the complete identity information of the user, so that the privacy protection of the identity information of the user is enhanced.
The following describes a login procedure corresponding to the registration procedure described above with reference to fig. 5.
2. Identity use phase (also referred to herein as the Login phase) -scheme 1
Fig. 6 is a schematic flow chart of an information management method according to an embodiment of the present application, as follows.
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 embodiment, the service identifier is carried in the IR message. In one possible embodiment, the IR message carries the service identity and the certificate of the server. 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). 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 the unique identifier 123 of the server and the timestamp 10, the second device verifies the validity of the unique identifier 123 of the server and the timestamp 10 in the IR message after acquiring the IR message: if the second device determines that the unique identifier 123 really exists by querying the corresponding unique identifier database, and the timestamp 11 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 10 are valid, that is, the second device determines that the IR message is a valid IR message. The second device then proceeds to perform subsequent steps, such as performing step 602.
602. And the second equipment acquires a second private key according to the service identifier.
As described above, in the registration phase, the second device obtains the second private key and the second public key, and the second device establishes the 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 the 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 embodiment, the IR message is carried in the digital signature. In addition, the second device also sends the public key of the second device to the first device.
In one possible embodiment, the digital signature and the second public key may be sent to the first device in the same message. In one possible implementation, the digital signature and the second public key may be sent to the first device by different messages.
In one possible implementation, the digital signature and the second public key may be sent 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. And the first device verifies the digital signature sent by the second device according to the received public key of the second device. The process of how to verify the digital signature has been described above and will not be repeated here.
If the verification is passed, the subsequent steps are continued, for example, step 605 is executed, and if the verification is not passed, the subsequent steps are not executed.
605. The first device obtains a first private key.
In one possible embodiment, 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 embodiment, if the first private key is generated by the biometric feature of the user at the registration stage, the biometric feature of the user is obtained after the first device verifies that the digital signature of the second device passes. The first device generates a first private key according to the acquired biological characteristics of the user, and can also generate a first public key corresponding to the first private key in the same way as the registration stage.
606. The first device obtains the encrypted first identity information from the blockchain.
The first device may send a digital signature to the blockchain, the digital signature carrying the first identifier. 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 comes from the first device according to the public key of the first device, the blockchain queries, according to the service identifier, the encrypted first identity information corresponding to the service identifier. For another example, if the first identifier is the second public key in the registration phase, in the login phase, 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 comes from the first device according to the public key of the first device, the blockchain queries the encrypted first identity information corresponding to the second public key according to the second public key.
After the block chain inquires 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, since the first public key is used to encrypt the first identity information in the registration phase, the first device may decrypt the encrypted first identity information by using the first private key corresponding to the first public key in the login phase 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 by using the first private key, wherein the digital signature carries the first identity information. In a possible implementation, the digital signature may also carry a service identifier. In one possible implementation, the digital signature may also carry an anti-replay parameter.
In a possible embodiment, after the first device sends the digital signature to the second device and the first identity information is sent to the second device, the first identity information, the first public key, and the service identifier 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, and only forward the acquired digital signature to the server.
In one possible embodiment, after acquiring the digital signature sent by the first device, the second device may verify the first digital signature by using the public key of the first device, and after the verification is passed, that is, after the digital signature is verified to be from the first device, send the digital signature to the server.
610. The server verifies the digital signature by the first public key.
The server verifies the received digital signature by the public key of the first device, and the description of how to verify the digital signature has been introduced above and is not repeated here.
In one possible implementation, the server may query the DID of the first device from the blockchain, and obtain the public key of the first device according to the DID uniquely corresponding to the first device.
611. And after the server is successfully verified, allowing the second equipment to access the server.
And after the server successfully verifies, if the digital signature is determined to be sent by the first device, allowing the second device to access the server, namely allowing the second device to use the corresponding service/service.
In one possible embodiment, the server may further send a notification message that the authentication is successful to the second device or the first device.
In one possible embodiment, the second device is not allowed to access the server if the authentication fails.
As can be seen from the embodiment corresponding to fig. 6, in the identity using stage, each server can only obtain the identity information that the server needs to verify, but cannot obtain all the identity information of the user, so that the privacy and the security of the user identity are increased. In addition, the scheme provided by the embodiment of the application can conveniently revoke the second public key, and ensure the safety 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 previous public key of the second device. And the first device can regenerate and generate a 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, the first private key does not need to be stored in the first device, and the safety of the identity information is further improved. In addition, the public key of the second device is stored on the second device, so that the second device is convenient to authenticate and use 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. In addition, it should be noted that, on the basis of the embodiment described in fig. 6, the order between the various steps described above may be exchanged, or may be executed 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 with reference to a specific embodiment.
1. Identity registration phase-scheme 2
Fig. 7 is a schematic flow chart of an information management method according to an embodiment of the present application, as follows.
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 obtains the identity information which needs to be verified by the service.
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 can be understood with reference to steps 501 to 509 in the embodiment corresponding to fig. 5, and are not repeated here.
710. The first device stores the encrypted first identity information.
Unlike the embodiment described in fig. 5, in which the encrypted first identity information is stored in the blockchain, in the embodiment described in fig. 7, the first device stores the encrypted first identity information locally, and saves the storage resources and communication resources of the blockchain.
And the first equipment establishes a binding relation between the first identifier and the encrypted first identity information. The first identifier may be the second public key, and may also be a 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 with the second public key.
If different second devices use the same second public key, or multiple different services of the second devices are bound to the same public key, different first identity information may be bound to the same second public key, which may also cause confusion in the login stage, for example, the first device may mistakenly send the first identity information to the second device, thereby causing the server authentication failure. For example, the first device has two corresponding second devices, which are a second device a and a second device B, respectively. 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 the first identity information bound with the second public key A to the second device A. However, if the second public key a is the same as the second public key B, the first device may send the first identity information bound with the second public key B to the second device a, and if the first identity information bound with the second public key a is not the same as the first identity information bound with the second public key B, the authentication may fail after the second device a sends the first identity information bound with 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 the first identity information bound with the second public key A to the second device. However, if the second public key a is the same as the second public key B, 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 is not the same as the first identity information bound to the second public key B, the second device a may send the first identity information bound to the second public key B to the server, which may result in a failure in authentication. For example, the service a is a game-like service, the first identity information bound to the second public key a includes an age, the service B is a financial-like service, and the first identity information bound to the second public key B includes a income condition. If the revenue situation is sent to the server of service a, it may result in a failure of the authentication.
In order to solve the above problem, the first device registers the DID with the second public key, and the blockchain also checks the obtained DID, and if the same DID is not stored in the current blockchain, the registration is considered to be successful, and the second public key is bound to the unique DID.
712. And the second equipment establishes a binding relationship between the second public key and the service identifier.
713. The second device sends a third message to the first device.
Step 712 and step 713 may be understood with reference to step 511 and step 512 in the corresponding embodiment of fig. 5, and are not repeated herein.
2. Identity use phase (also referred to herein as login phase) -scheme 2
Fig. 8 is a schematic flow chart of an information management method according to an embodiment of the present application, which is described 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 may be understood with reference to steps 601 to 605 in the embodiment corresponding to fig. 6, and are not repeated herein.
806. The first device locally obtains the encrypted first identity information.
And the first equipment queries the local storage according to the first identifier so as 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 phase, the first device queries, according to the service identifier, encrypted first identity information corresponding to the service identifier in the login phase. For another example, if the first identifier is the second public key in the registration phase, in the login phase, the first device queries the encrypted first identity information corresponding to the second public key according to the second public key.
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 by means of the first public key.
811. And after the server is successfully verified, allowing the second equipment to access the server.
Step 807 to step 811 can be understood by referring to step 607 to step 611 in the corresponding embodiment of fig. 6, and will not be repeated herein.
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. In addition, it should be noted that, on the basis of the embodiments described in fig. 7 and fig. 8, the order between the various steps described above may be exchanged, or may be executed synchronously.
In the solutions described in fig. 7 and 8, in addition to the advantages described in the embodiments described in fig. 5 and 6, the encrypted first identity information is stored in the first device, which saves the storage resources and communication resources of the block chain. In some possible embodiments, the encrypted first identity information may also be stored in the second device, which is described below in connection with specific embodiments.
1. Identity registration phase-scheme 3
Fig. 9 is a schematic flow chart of an information management method according to an embodiment of the present application, as follows.
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 obtains identity information which needs to be verified by the service.
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 embodiment corresponding to fig. 7, and are not repeated here.
910. The first device registers the DID with the second public key.
Step 910 can be understood with reference to step 711 in the corresponding embodiment of fig. 7, and is not repeated here.
911. The second device obtains the encrypted first identity information and the second public key.
In one possible implementation, the second device may generate the second private key and the second public key. In one possible implementation, if the first device generates the second private key and the second public key, the second device receives the second public key and the second private key sent by the first device. In a possible embodiment, 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 details are not repeated here.
The second device obtains the encrypted first identity information from the first device. In one possible embodiment, the first device may send the encrypted first identity information to the second device through the secure channel. In one possible embodiment, the first device may send the encrypted first identity information, and the second private key and the second public key to the second device through the same message. In one possible embodiment, the first device may send the encrypted first identity information, and the second private key and the second public key to the second device through different messages.
And after the second device or the encrypted first identity information and the second public key are obtained, storing the encrypted first identity information, the second public key and the second private 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, since the second public key and the second private key are in one-to-one correspondence, it is equivalent to query the unique second private key according to the service identifier.
The second device obtains a second public key bound with the service identifier, and then can obtain first identity information bound with the second public key.
In one possible embodiment, a binding relationship between the service identifier and the first identity information may also be established. After the second device obtains the service identifier, the encrypted first identity information bound to the service identifier may be directly obtained.
In the embodiment illustrated in fig. 9, the second device locally stores the encrypted first identity information, and since the second device is generally a mobile phone and has higher security performance, 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 may be understood with reference to step 512 in the corresponding embodiment of fig. 5, and details are not repeated here.
2. Identity use phase (also referred to herein as login phase) -scheme 3
Fig. 10 is a schematic flow chart of an information management method according to an embodiment of the present application, which is described as follows.
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.
Step 1001 to step 1002 can be understood with reference to step 601 and step 602 in the corresponding embodiment of fig. 6, and are not 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. In addition, 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 encrypted first identity information bound to the public key may be further obtained according to the second public key bound to the service identifier. If the binding relationship 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 embodiment, the digital signature and the second public key may be sent to the first device in the same message. In one possible implementation, the digital signature and the second public key may be sent to the first device by different messages.
In one possible implementation, the digital signature and the second public key may be sent 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 can be understood by referring to step 604 and step 605 in the corresponding embodiment of fig. 6, and are not repeated here.
1006. The first device decrypts the first identity information through the first private key.
After the first device acquires the encrypted first identity information from the second device, the first device decrypts the encrypted first identity information through the first private key to acquire 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 by means of the first public key.
1010. And after the server is successfully verified, allowing the second equipment to access the server.
Step 1007 to step 1010 can be understood by referring to step 608 to step 611 in the corresponding embodiment of fig. 6, and are 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 generally 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 above with reference to fig. 5 to 10, a public-private key pair is utilized in the identity registration phase and the identity use phase, such as introducing a first private key, a first public key corresponding to the first private key, a second private key, and a second public key corresponding to the second private key. In some embodiments, asymmetric encryption techniques may not be used, and symmetric encryption techniques may be used. The following description is made in conjunction with specific embodiments.
1. Identity registration phase-scheme 4
Fig. 11 is a schematic flow chart of an information management method according to an embodiment of the present application, which is described as follows.
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 obtain the first private key from the private space when the first device needs to use the first private key.
In one possible implementation, the first device obtains a biometric feature of the user and generates the first key based on the biometric feature of the user. The biometric features of the user include, but are not limited to, fingerprint information and iris information. In this embodiment, the first device does not need to store the first key, and when the first device needs to use the first key, the first device may first obtain the biometric features of the user and then generate the first key according to the biometric features of the user. Because the first device does not need to store the first secret key, the security of the first private key is increased, and even if the first device is lost, other people except the user cannot obtain the private key of the first device.
1102. The first device generates a second key based on the identity of the first device.
Each device has a unique corresponding identifier, and the specific representation manner of the identifier of the first device is not limited in the embodiment of the present application. For example, the identifier of the first device is determined according to an International Mobile Equipment Identity (IMEI) and a media access control address (MAC) address. For example, as the identity of the first device based on the identity of the access network.
And generating a second key according to the unique corresponding identifier of the first equipment.
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 can be understood by referring to step 503 and step 504 in the embodiment corresponding to fig. 5, and are not repeated here.
1105. And the second equipment generates a third key according to the service identifier.
And if the second equipment generates a third key according to the service identifier, the second equipment establishes a binding relationship between the service identifier and the third key.
1106. The second device sends the targeted message to the first device.
The target message carries the category of the identity information to be verified and a third key. For example, for the game class service, after the second device initiates the registration request to the game class server, the category of the identity information to be verified carried in the first message may include an age. For another example, for a social service, after the second device initiates a registration request to the social server, the category of the identity information to be verified carried in the first message may include an identification number, an academic calendar, and the like.
In one possible implementation, the target message carries the category of the identity information to be verified and the service identifier. In such an embodiment, step 1105 may not be performed and the third key may be generated by the first device according to the service identity. And if the third key is generated by the first equipment according to the service identifier, the first equipment establishes a binding relationship between the service identifier and the third key.
In one possible implementation, the target message may carry a category of identity information to be verified, a service identifier, and a third key.
1107. The first device obtains a target key.
The first device synthesizes a target key according to the first key, the second key and the third key. The embodiment of the application does not limit the specific manner and the slave target key, and only the target key is required to be synthesized together according to the first key, the second key and the third key.
1108. The first device obtains first identity information.
The first device acquires the identity information that needs to be verified for the service, and step 1108 may be understood with reference to step 506 in the embodiment corresponding to fig. 5, which is not repeated herein.
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 implementation, the first device establishes a binding between the third key and the encrypted first identity information.
In one possible embodiment, 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 identifier 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 obtaining that the first identity information has been encrypted by the first device through the target key, the second device may send a feedback message to the first device to notify that the second device has received the message sent by the first device (step 1110).
In a possible implementation manner, after the first device acquires the feedback message sent by the second device, the first key, the second key, the third key, and the target key may be deleted.
In one possible implementation, the first device may prompt the user that the registration was successful.
2. Identity use phase (also referred to herein as login phase) -scheme 4
Fig. 12 is a schematic flow chart of an information management method according to an embodiment of the present application, which is described 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 details are not repeated here.
1202. And the second equipment acquires a third key according to the service identifier.
Fig. 11 illustrates an embodiment, where 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 acquires the service identifier, the second device may acquire the third key bound to the service identifier.
1203. The second device sends an IR message to the first device along with the third key.
In one possible embodiment, if the third key is generated by the first device during the registration phase, the second device may only send an IR message to the first device, the third key being generated by the first device based on the service identity.
In one possible embodiment, 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 acquires the biological characteristics of the user and generates a first secret key according to the biological characteristics of the user. The first device obtains the identifier of the first device, and the first device obtains the second key according to the identifier of the first device. Obviously, the biometric features of the user are the same as those used in the enrollment phase, and the identifier is the same as that used in the enrollment phase, and the explanation of this embodiment is not repeated.
1205. The first device obtains a target key.
The first device synthesizes a target key from the first key, the second key, and the third key in the same manner as in the registration phase.
In a possible implementation manner, the third key may be obtained by the first device according to the service identifier, or the third key may be generated by the second device according to the service identifier and then sent to the first device.
1206. The first device obtains the encrypted first identity information.
In one possible embodiment, the first device establishes a binding between the third key and the encrypted first identity information if in the registration phase. In the login phase, the first device may search, according to the obtained third key, for the encrypted first identity information bound to the third key.
In one possible embodiment, the first device establishes a binding relationship between the target key and the encrypted first identity information if in the registration phase. The first device may, in the login phase, look up the encrypted first identity information bound to the target key, based on the target key.
In one possible embodiment, the first device establishes a binding relationship between the service identity and the encrypted first identity information if in the registration phase. In the login phase, the first device may search for the encrypted first identity information bound to the service identifier according to the service identifier.
1207. The first device decrypts the first identity information by 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 embodiment, after the first device completes step 1207 or step 1208, the first key, the second key, the third key, and the target key may be deleted.
1209. The second device transmits the first identity information encrypted by the public key of the server to the server.
1210. And 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 equipment to access the server.
The embodiments described in fig. 5 to fig. 10 are all solutions designed based on a public key system, and when the solutions are applied, the requirements on the computing power of the device may be relatively high, and the power consumption is relatively large. The embodiments described in fig. 11 and 12 use a symmetric key based scheme, which requires less computing power and less functionality for the device. In addition, the embodiments described in fig. 11 and fig. 12 use the identifier of the first device as a partial key to synthesize a symmetric key, thereby completing strong binding between the device and the user key and achieving better security. Meanwhile, the symmetric key is simple to implement and mature in technology.
The foregoing describes the system and method provided by the present application in detail, and the following describes the apparatus provided by the present application.
Referring to fig. 13, a schematic structural diagram of a second apparatus provided in the present application is shown.
The second device includes:
the transceiver module 1301 is configured to initiate a registration request to the 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 category of information that needs to be verified for the first service and an identifier of the first service.
And 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 transceiving module 1301 is further configured to send the type of the information that the first service needs to be verified to the first device, so that the first device obtains the information that the first service needs to be verified from the information locally stored in the first device according to the type of the information that the first service needs to be verified, where a binding relationship exists between the information that the first service needs to be verified and a public key of the second device.
In a possible implementation manner, the transceiver module 1301 is further configured to receive information that the encrypted first service needs to be verified, where the information is sent by the first device. The processing module 1303 is further configured to establish a binding relationship between the information that needs to be verified of the encrypted first service and the public key of the second device.
In a possible implementation manner, 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. The transceiver module 1301 is 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 the identifier of the first service. And 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 by 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 comes from the second device, the information that the first service bound to the public key of the second device needs to be verified is obtained.
In one possible embodiment, the transceiver module 1301 is configured to initiate a registration request to a server. The transceiver 1301 receives a first message sent by the server, where the first message carries a type of information that needs to be verified for the first service and an identifier of the first service. The transceiving module 1301 is further configured to send the type of the information that the first service needs to be verified to the second device.
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, a storage module 1302 is further included for storing the data acquired by the transceiver module.
Referring to fig. 14, a schematic structural diagram of a first apparatus provided in the present application is shown.
The first device includes:
the transceiver module 1401 is configured to obtain the type of the information that needs to be verified for the first service from the second device, and obtain the information that needs to be verified for the first service from the storage module 1402 of the first device according to the type of the 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, the device further includes a processing module 1403, configured to establish a binding relationship between the information that needs to be verified for the first service and the public key of the second device.
In one possible implementation, the processing module 1403 is further configured to encrypt the information that the first service needs to be verified according to the public key of the first device.
In one possible embodiment, the transceiver module 1401 is further configured to: and sending the encrypted information which needs to be verified of the first service to the block link point, so that the block link point establishes a binding relationship between the encrypted information which needs to be verified of the first service and a public key of the second device.
In a possible implementation manner, the transceiver module 1401 is further configured to send, to the second device, the encrypted information that the first service needs to be verified, so that the second device establishes a binding relationship between the encrypted information that the first service needs to be verified and a public key of the second device.
In a possible implementation, the processing module 1403 is further configured to: after the first device sends the information that the encrypted first service needs to be verified, the information that the encrypted first service needs to be verified and stored locally in the first device is deleted.
In a possible implementation, the processing module 1403 is further configured to: a private key of the first device is generated from the biometric of the user.
In a possible implementation, the processing module 1403 is further configured to: the decentralized identity DID is registered with the public key of the first device.
In one possible implementation, the processing module 1403 is further configured to: a private key of the second device and a public key of the second device are generated. 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 embodiment, the transceiver module 1401 is further configured to: an identification of the first service is obtained from the second device. The processing module 1403 is specifically configured to generate the private key of the second device according to the identifier of the first service, the information that the first service needs to be verified, and the private key of the first device.
In a possible implementation, the processing module 1403 is further configured to obtain information that the 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 comes from 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 for the first service.
In a possible implementation, the processing module 1403 is specifically configured to: and after the digital signature of the second device is verified to come from the second device, acquiring the encrypted information, which is bound with the public key of the second device and needs to be verified, of the first service from the link point of the block, and decrypting the encrypted information, which needs to be verified, of the first service according to the private key of the first device to acquire the information, which needs to be verified, of the first service.
In a possible implementation, the processing module 1403 is specifically configured to, after verifying that the digital signature of the second device comes from the second device, obtain, from the second device, information that needs to be verified of the encrypted first service, which is bound to the public key of the second device, and decrypt, according to the private key of the first device, the encrypted information that needs to be verified of the first service, so as to obtain the information that needs to be verified of the first service.
In a possible implementation, the processing module 1403 is specifically configured to, after the first device verifies that the digital signature of the second device comes from the second device, locally obtain, from the first device, the encrypted information that needs to be verified for the first service, and decrypt, according to a private key of the first device, the encrypted information that needs to be verified for the first service, so as to obtain the information that needs to be verified for the first service.
In a possible embodiment, the processing module 1403 is further configured to delete the private key of the first device and the information that the first service needs to be verified 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 the biometric feature of the user after verifying that the digital signature of the second device comes from the second device, and generate the private key of the first device according to the biometric feature.
In a possible embodiment, the transceiver module 1401 is further configured to obtain, from the second device, a type of information that needs to be authenticated for the first service, and obtain, according to the type of the information that needs to be authenticated for the first service, the information that needs to be authenticated for the first service from information that is locally stored in the first device, where the information that needs to be authenticated 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 characteristic 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 the identifier of the first service. The processing module 1403 is further configured to perform encryption processing on the information that needs to be verified for the first service according to the target key.
In a possible implementation, the processing module 1403 is further configured to delete the first key, the second key, the third key, and the target key.
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 embodiment, the transceiver module 1401 is further configured to obtain an identifier of the first service from the second device. The processing module 1403 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 the biometric characteristic of the user acquired by the first device, the second key is a key generated according to the identifier of the first device, and the third key is a key generated according to the identifier of the first service. The processing module 1403 is further configured to decrypt the encrypted information that needs to be verified of the first service according to the target key, and obtain the information that needs to be verified 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 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 in 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. Among other things, the memory 1502 has program instructions and data stored therein.
The memory 1502 stores program instructions and data corresponding to the steps of fig. 5-12 described previously.
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 above.
A transceiver 1503 for receiving or transmitting data.
Alternatively, the foregoing home device shown in fig. 15 may be a chip.
Referring to fig. 16, a schematic structural diagram of another first apparatus provided in 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 a line. Among other things, memory 1602 has stored therein program instructions and data.
The memory 1602 stores program instructions and data corresponding to the steps described above in fig. 5-12.
The processor 1601 is configured to perform the method steps of the first apparatus as described in any of the embodiments of 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 provided in the present application is described as follows.
The server may include a processor 1701 and a memory 1702. The processor 1701 and the memory 1702 are interconnected by wires. Among other things, memory 1702 has stored therein program instructions and data.
The memory 1702 stores program instructions and data corresponding to the steps of fig. 5-12 described above.
The processor 1701 is configured to perform the method steps performed by the server shown in any of the embodiments of fig. 5-12 described above.
A transceiver 1703 for receiving or transmitting data.
Alternatively, the aforementioned access control node shown in fig. 17 may be a chip.
Also provided in embodiments of the present application is 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 as described in the embodiments shown in fig. 5-12.
An embodiment of the present application further provides an information management apparatus, which may also be referred to as a digital processing chip or a chip, where the chip includes a processing unit and a communication interface, the processing unit obtains program instructions through the communication interface, and the program instructions are executed by the processing unit, and the processing unit is configured to execute the method steps shown in any one of the foregoing fig. 5 to fig. 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 processor, or the functionality of the processor, as described above. When integrated with memory, 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 a memory, the digital processing chip can be connected with an external memory through a communication interface. The digital processing chip implements the method steps shown in any of the embodiments of fig. 5-12 described above according to program codes stored in an external memory.
Embodiments of the present application also provide a computer program product, which when running on a computer, causes the computer to execute the steps of the method as described in the foregoing embodiments shown in fig. 5 to 12.
The information management device provided by the embodiment of the application may be a chip, and the chip includes: a processing unit, which may be, for example, a processor, and a communication unit, which may be, for example, an input/output interface, a pin or a circuit, etc. The processing unit may execute computer-executable instructions stored by the storage unit to cause a chip within the server to perform the methods described in the embodiments of fig. 5-12 above. Optionally, the storage unit is a storage unit in the chip, such as a register, a cache, and the like, and the storage unit may also be a storage unit located outside the chip in the radio access device, such as a read-only memory (ROM) or another type of static storage device that may store static information and instructions, a Random Access Memory (RAM), and the like.
Specifically, the processing unit or the processor may be a Central Processing Unit (CPU), a Network Processor (NPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or the like. A general purpose processor may be a microprocessor or any conventional processor or the like.
It should be noted that the above-described embodiments of the apparatus are merely illustrative, where the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. In addition, in the drawings of the embodiments of the apparatus provided in the present application, the connection relationship between the modules indicates that there is a communication connection therebetween, and may be implemented as one or more communication buses or signal lines.
Through the above description of the embodiments, those skilled in the art will clearly understand that the present application can be implemented by software plus necessary general-purpose hardware, and certainly can also be implemented by special-purpose hardware including special-purpose integrated circuits, special-purpose CPUs, special-purpose memories, special-purpose components and the like. Generally, functions performed by computer programs can be easily implemented by corresponding hardware, and specific hardware structures for implementing the same functions may be various, such as analog circuits, digital circuits, or dedicated circuits. However, for the present application, the implementation of a software program is more preferable. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a readable storage medium, such as a floppy disk, a usb disk, a removable hard disk, a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk of a computer, and includes instructions for enabling a computer device (which may be a personal computer, a server, or a network device) to execute the methods described in the embodiments of the present application.
In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, it 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, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device, such as a server, a data center, etc., that is integrated with one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), among others.
The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be implemented in other sequences than those illustrated or described herein. Moreover, 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.
Finally, it should be noted that: the above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application.

Claims (67)

1. A system for identity information management, comprising: a first device, a second device and a server;
the second device is used for initiating a registration request to the server;
the server is configured to send a first message to the second device in response to the registration request, where the first message carries a type of identity information that needs to be verified for the first service and an identifier of the first service;
the second device is further configured to establish a binding relationship between 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 the identity information that needs to be verified for the first service, and obtain, 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 from the identity information locally stored in the first device, where a binding relationship exists between the identity information that needs to be verified for the first service and a public key of the second device.
2. The system of claim 1, wherein the first device is further configured to encrypt the identity information that needs to be verified for the first service 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, to the block link node, encrypted identity information that the first service needs to be verified;
and the block chain node is used for establishing a binding relationship between the encrypted identity information of the first service to be verified and the public key of the second device.
4. The system according to 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 that needs to be verified for the first service and a public key of the second device.
5. The system of claim 3 or 4,
the first device is further configured to delete the encrypted identity information, which is locally stored in the first device and needs to be verified, of the first service after the encrypted identity information, which needs to be verified, of the first service is sent.
6. The system according to any one of claims 1 to 5,
the first device is further configured to obtain a biological feature of a user, and generate a private key of the first device according to the biological feature.
7. The system of any one of claims 1 to 6,
the first device is further configured to register a decentralized identity DID with a public key of the first device.
8. The system according to any one of claims 1 to 7,
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,
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 for the first service, and the private key of the first device.
10. A system for identity information management, comprising: a first device, a second device and a server;
the second device is used for initiating 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 an identifier of a 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 bound to the identifier of the first service;
the second device is further configured to generate 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 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, which is bound to a public key of the second device and needs to be verified, of the first service 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 for the first service;
the server is further configured to obtain the digital signature of the first device, and obtain the identity information that needs to be verified for the first service after verifying that the digital signature of the first device is from the first device.
11. The system of claim 10, further comprising a blockchain node;
the first device is specifically configured to obtain, from the block link point, encrypted identity information that is bound to a public key of the second device and needs to be verified of the first service, and decrypt, according to a 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.
12. The system of claim 10,
the first device is specifically configured to obtain, from the second device, the encrypted identity information of the first service that needs to be verified and 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 of the first service that needs to be verified, so as to obtain the identity information of the first service that needs to be verified.
13. The system of claim 10,
the first device is specifically configured to locally obtain, from the first device, encrypted identity information that needs to be verified of the first service, and decrypt, according to a 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.
14. The system of any one of claims 10 to 13,
the first device is further configured to delete the private key of the first device and the identity information that needs to be verified for the first service after the digital signature of the first device is sent.
15. The system of any one of claims 10 to 14,
the first device is further configured to obtain a biometric feature of the user after verifying that the digital signature of the second device comes from the second device, and generate a private key of the first device according to the biometric feature.
16. A system for identity information management, comprising: a first device, a second device and a server;
the second device is used for initiating a registration request to the server;
the server is configured to send a first message to the second device in response to the registration request, where the first message carries a type of identity information that needs to be verified for the first service and an identifier of the first service;
the first device is configured to obtain, from the second device, a type of identity information that needs to be verified for the first service, and obtain, according to the type of identity information that needs to be verified for the first service, the identity information that needs to be verified for the first service from the identity information locally stored in the first device, where 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 characteristic 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 the identifier of the first service;
the first device is further configured to encrypt, according to the target key, the identity information that needs to be verified for the first service.
17. The system of claim 16,
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,
the second device is further configured to generate the third key according to the identifier of the first service, and establish a binding relationship between the third key and the identifier of the first service.
19. A system for identity information management, comprising: a first device, a second device and a server;
the second device is used for initiating 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 an identifier of a first service;
the first device is configured to obtain an identifier of the first service from the second device;
the first device is further configured to generate a target key 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 a first service;
the first device is further configured to decrypt, according to the target key, the encrypted identity information of the first service, which needs to be verified, so as to obtain the identity information of the first service, which needs to be verified;
the first device is further configured to encrypt the identity information that needs to be verified for the first service according to the public key of the server, so that the server obtains the identity information that needs to be verified for the first service after decrypting according to the private key of the server.
20. The system of claim 19,
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,
the second device is further configured to obtain the third key bound to the identifier of the first service, and send the third key to the first device.
22. A method for identity information management is applied to an identity information management system, wherein the identity information management system comprises a first device, a second device and a server, and the method comprises the following steps:
the second equipment initiates a registration request to a server;
the second equipment receives a first message sent by the server in response to the registration request, wherein the first message carries the type of identity information needing to be verified by the first service and the identifier 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 type of the identity information which needs to be verified of the first service to the first device, so that the first device obtains the identity information which needs to be verified of the first service from the identity information which is locally stored in the first device according to the type of the identity information which needs to be verified of the first service, and a binding relationship exists between the identity information which needs to be verified of the first service and a public key of the second device.
23. The method of claim 22, further comprising:
the second device receives the encrypted identity information which is sent by the first device and needs to be verified of the first service;
and the second equipment establishes a binding relationship between the encrypted identity information of the first service needing to be verified and a public key of the second equipment.
24. The method according to claim 22 or 23, further comprising:
and the second device receives the private key of the second device and the public key of the second device sent by the first device.
25. A method for managing identity information is applied to an identity information management system, wherein the identity information management system comprises a first device, a second device and a server, and the method comprises the following steps:
the first device obtains the type of the identity information which needs to be verified of the first service from the second device, and obtains the identity information which needs to be verified of the first service from the identity information which is locally stored in the first device according to the type of the identity information which needs to be verified of the first service, wherein a binding relationship exists between the identity information which needs to be verified of the first service and a public key of the second device.
26. The method of claim 25, further comprising:
and the first equipment establishes a binding relationship between the identity information which needs to be verified by the first service and the public key of the second equipment.
27. The method of claim 25, further comprising:
and the first equipment encrypts the identity information needing 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, and wherein the method further comprises:
and the first device sends 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 a public key of the second device.
29. The method of claim 27, further comprising:
the first device sends the encrypted identity information of the first service to be verified to the second device, so that the second device establishes a binding relationship between the encrypted identity information of the first service to be verified and a public key of the second device.
30. The method of claim 28 or 29, further comprising:
and after the encrypted identity information which needs to be verified of the first service is sent by the first equipment, deleting the encrypted identity information which needs to be verified of the first service and is locally stored by the first equipment.
31. The method of any one of claims 25 to 30, further comprising:
the first device obtains the biological characteristics of a user and generates a private key of the first device according to the biological characteristics.
32. The method of any one of claims 25 to 31, further comprising:
the first device registers a decentralized identity DID with a public key of the first device.
33. The method of any one of claims 25 to 32, 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 of any one of claims 25 to 32, further comprising:
the first device acquires the identifier 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 a private key of the second equipment according to the identification of the first service, the identity information of the first service needing to be verified and the private key of the first equipment.
35. A second device, applied to an identity information management system including a first device, the second device, and a server, the second device comprising:
the receiving and sending module is used for initiating a registration request to the server;
the transceiver module is further configured to receive a first message sent by the server in response to the registration request, where the first message carries a type of identity information that needs to be verified for a first service and an identifier of the first service;
the processing module is used for establishing a binding relationship between the public key of the second device and the identifier of the first service;
the transceiver module is further configured to send the type of the identity information that needs to be verified for the first service to the first device, so that the first device obtains the identity information that needs to be verified for the first service from the identity information locally stored in the first device according to the type of the identity information that needs to be verified for the first service, where a binding relationship exists between the identity information that needs to be verified for the first service and a public key of the second device.
36. The second apparatus of claim 35,
the transceiver module is further configured to receive 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 that needs to be verified for the first service and the public key of the second device.
37. The second apparatus according to claim 35 or 36,
the transceiver module 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.
38. A first device, applied to an identity information management system including the first device, a second device, and a server, the first device comprising:
and the transceiver module is used for acquiring the type of the identity information to be verified of the first service from the second device, and acquiring the identity information to be verified of the first service from the storage module of the first device according to the type of the identity information to be verified of the first service, wherein a binding relationship exists between the identity information to be verified of the first service and a public key of the second device.
39. The first device of claim 38, wherein the device further comprises a processing module configured to:
and establishing a binding relationship between the identity information which needs to be verified by 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 which needs 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, and wherein the transceiver module is further configured to:
and sending the encrypted identity information which needs to be verified of the first service to the block link point, so that the block link point establishes a binding relationship between the encrypted identity information which needs to be verified of the first service and a public key of the second device.
42. The first device of claim 40, wherein the transceiver module is further configured to:
the first device sends the encrypted identity information of the first service to be verified to the second device, so that the second device establishes a binding relationship between the encrypted identity information of the first service to be verified and a public key of the second device.
43. The first device of claim 41 or 42, wherein the processing module is further configured to:
and after the encrypted identity information which needs to be verified of the first service is sent by the first equipment, deleting the encrypted identity information which needs to be verified of the first service and is locally stored by the first equipment.
44. The first device of any one of claims 38 to 43, wherein the processing module is further configured to:
a private key of the first device is generated from a biometric of a user.
45. The first device of any one of claims 38 to 43, 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 one of claims 38 to 45, 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 a private key of the second device and a public key of the second device to the second device.
47. The first device of any one of claims 38 to 46, wherein the transceiver module is further configured to:
acquiring the 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 for the first service, and the private key of the first device.
48. A method for identity information management is applied to an identity information management system, wherein the identity information management system comprises a first device, a second device and a server, and the method comprises the following steps:
the second equipment 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 a 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 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.
49. A method for identity information management is applied to an identity information management system, wherein the identity information management system comprises a first device, a second device and a server, and the method comprises the following steps:
after the first device verifies that the digital signature of the second device comes from the second device, acquiring identity information, which is bound with a public key of the second device and needs to be verified, of the first service;
and the first equipment generates a digital signature of the first equipment according to a private key of the first equipment, wherein the digital signature carries identity information which needs to be verified by the first service.
50. The method of claim 49, wherein the system further comprises a blockchain node, and after the first device verifies that the digital signature of the second device comes from the second device, the first device obtains the identity information, which needs to be verified, of the first service bound to the public key of the second device, and the method comprises:
after the first device verifies that the digital signature of the second device comes from the second device, the encrypted identity information, which is bound with the public key of the second device and needs to be verified, of the first service is obtained from the link point of the block, and the encrypted identity information, which needs to be verified, of the first service is decrypted according to the private key of the first device, so that the identity information, which needs to be verified, of the first service is obtained.
51. The method of claim 49, wherein 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 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, which is bound with the public key of the second device and needs to be verified, of the first service is obtained from the second device, and the encrypted identity information, which needs to be verified, of the first service is decrypted according to the private key of the first device, so that the identity information, which needs to be verified, of the first service is obtained.
52. The method of claim 49, wherein 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 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 needing to be verified is locally acquired from the first device, and the encrypted identity information of the first service needing to be verified is decrypted according to the private key of the first device, so that the identity information of the first service needing to be verified is acquired.
53. The method of any one of claims 49 to 52, further comprising:
and after the first device sends the digital signature of the first device, deleting the private key of the first device and the identity information which needs to be verified by the first service.
54. The method of any one of claims 49 to 53, further comprising:
and after the first device verifies that the digital signature of the second device comes from the second device, the first device acquires the biological characteristics of the user and generates the private key of the first device according to the biological characteristics.
55. A second device, 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 sending module is used for initiating an access request to the server;
the receiving and sending 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 by using a private key of the second device corresponding to the public key of the second device;
the transceiver 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 is from the second device, the identity information, which is bound to the public key of the second device and needs to be verified, of the first service is acquired.
56. A first device, applied to an identity information management system, the identity information management system including a first device, a second device, and a server, the first device comprising:
the processing module is used for acquiring identity information which is bound with a public key of second equipment and needs to be verified of the first service after the digital signature of the second equipment is verified to come from the second equipment;
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 for the first service.
57. The first device of claim 56, wherein the system further comprises a blockchain node, and wherein the processing module is specifically configured to:
after the digital signature of the second device is verified to come from the second device, the encrypted identity information which is bound with the public key of the second device and needs to be verified of the first service is obtained from the link point of the block, and the encrypted identity information which needs to be verified of the first service is decrypted according to the private key of the first device, so that the identity information which needs to be verified of the first service is obtained.
58. The first device of claim 56, wherein the processing module is specifically configured to:
after the digital signature of the second device is verified to come from the second device, the encrypted identity information which is bound with the public key of the second device and needs to be verified of the first service is obtained from the second device, and the encrypted identity information which needs to be verified of the first service is decrypted according to the private key of the first device so as to obtain the identity information which needs to be verified of the first service.
59. The first device of claim 56, wherein the 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 needing to be verified is locally obtained from the first device, and the encrypted identity information of the first service needing to be verified is decrypted according to the private key of the first device, so that the identity information of the first service needing to be verified is obtained.
60. The first device of any one of claims 56 to 59, wherein the processing module is further configured to:
and after the transceiver module sends the digital signature of the first device, deleting the private key of the first device and the identity information of the first service needing to be verified.
61. The first device of any one of claims 56 to 60, wherein the processing module is further configured to:
and after the digital signature of the second device is verified to come from the second device, the biological characteristics of the user are obtained, and the private key of the first device is generated according to the biological characteristics.
62. A second device comprising a processor coupled to a memory, the memory storing a program that when executed by the processor implements the method of any of claims 22 to 24 or implements 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 implements the method of any of claims 25 to 34 or implements the method of any 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, characterized in that the computer programs/instructions, when executed by a processor, implement the method of any one of claims 22 to 24 or the method of claim 48.
67. A computer program product comprising computer programs/instructions, characterized in that the computer programs/instructions, 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.
CN202110977568.9A 2021-08-24 2021-08-24 Information management system, method and device Pending CN115720137A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110977568.9A CN115720137A (en) 2021-08-24 2021-08-24 Information management system, method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110977568.9A CN115720137A (en) 2021-08-24 2021-08-24 Information management system, method and device

Publications (1)

Publication Number Publication Date
CN115720137A true CN115720137A (en) 2023-02-28

Family

ID=85254769

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110977568.9A Pending CN115720137A (en) 2021-08-24 2021-08-24 Information management system, method and device

Country Status (1)

Country Link
CN (1) CN115720137A (en)

Similar Documents

Publication Publication Date Title
US11139951B2 (en) Blockchain system and data processing method for blockchain system
US10979418B2 (en) Template-based distributed certificate issuance in a multi-tenant environment
CN109862041B (en) Digital identity authentication method, equipment, device, system and storage medium
CN108768988B (en) Block chain access control method, block chain access control equipment and computer readable storage medium
JP6547079B1 (en) Registration / authorization method, device and system
CN106104562B (en) System and method for securely storing and recovering confidential data
US10567370B2 (en) Certificate authority
CN113691502B (en) Communication method, device, gateway server, client and storage medium
JP2020528695A (en) Blockchain authentication via hard / soft token verification
US20170147808A1 (en) Tokens for multi-tenant transaction database identity, attribute and reputation management
US8683209B2 (en) Method and apparatus for pseudonym generation and authentication
CN109450843B (en) SSL certificate management method and system based on block chain
CN109618326A (en) User dynamic identifier generation method, service registration method and login verification method
CN111835526B (en) Method and system for generating anonymous credential
JP2001326632A (en) Distribution group management system and method
Zhou et al. EverSSDI: blockchain-based framework for verification, authorisation and recovery of self-sovereign identity using smart contracts
EP2805298B1 (en) Methods and apparatus for reliable and privacy protecting identification of parties' mutual friends and common interests
ES2665887T3 (en) Secure data system
Kim et al. On the security of two remote user authentication schemes for telecare medical information systems
US11604888B2 (en) Digital storage and data transport system
CN109981287A (en) A kind of code signature method and its storage medium
Kravitz Transaction immutability and reputation traceability: Blockchain as a platform for access controlled iot and human interactivity
CN114154125B (en) Identity authentication scheme without block chain certificate in cloud computing environment
CN113051540B (en) Application program interface safety grading treatment method
KR20200016506A (en) Method for Establishing Anonymous Digital Identity

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination