CN112187466B - Identity management method, device, equipment and storage medium - Google Patents

Identity management method, device, equipment and storage medium Download PDF

Info

Publication number
CN112187466B
CN112187466B CN202010904673.5A CN202010904673A CN112187466B CN 112187466 B CN112187466 B CN 112187466B CN 202010904673 A CN202010904673 A CN 202010904673A CN 112187466 B CN112187466 B CN 112187466B
Authority
CN
China
Prior art keywords
identity
user
private key
application
target
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.)
Active
Application number
CN202010904673.5A
Other languages
Chinese (zh)
Other versions
CN112187466A (en
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.)
Sangfor Technologies Co Ltd
Original Assignee
Sangfor 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 Sangfor Technologies Co Ltd filed Critical Sangfor Technologies Co Ltd
Priority to CN202010904673.5A priority Critical patent/CN112187466B/en
Publication of CN112187466A publication Critical patent/CN112187466A/en
Application granted granted Critical
Publication of CN112187466B publication Critical patent/CN112187466B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

The embodiment of the application discloses an identity management method, an identity management device, identity management equipment and a storage medium, wherein the method comprises the following steps: responding to a change operation of a user on state data in a target application, and acquiring a message body for changing the state data by the identity application layer under the condition that the identity and the authority of the user pass verification, wherein the target application is one of at least two applications served by the server side; the identity application layer determines a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application; the identity application layer sends the message body and the target private key to trusted hardware; decrypting the target private key by the trusted hardware, and signing the message body by using the decrypted target private key to obtain a signed message body; the trusted hardware sends the signed message body to the target application to realize the change of the state data in the target application.

Description

Identity management method, device, equipment and storage medium
Technical Field
The embodiment of the application relates to the technical field of blockchains, and relates to, but is not limited to, an identity management method, an identity management device, identity management equipment and a storage medium.
Background
The prior blockchain application identity management method comprises the following steps: the identity security layer is built independently without identity security construction and application. The private key of the identity management method without identity security construction is easy to lose, once the private key is lost, the subsequent private key recovery and asset recovery processes are very complex, and the situation that the private key is lost to mean the asset is lost even occurs in most of the current blockchain applications; the independent construction identity security layer is a software-level private key escrow, has poorer security than hardware-level escrow, and has the possibility of rewriting the operation flow.
Disclosure of Invention
In view of this, embodiments of the present application provide an identity management method, apparatus, device, and storage medium.
The technical scheme of the embodiment of the application is realized as follows:
in a first aspect, an embodiment of the present application provides an identity management method applied to a blockchain server, where the server includes an identity application layer and trusted hardware, including:
responding to a change operation of a user on state data in a target application, and acquiring a message body for changing the state data by the identity application layer under the condition that the identity and the authority of the user pass verification, wherein the target application is one of at least two applications served by the server side; the identity application layer determines a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application; the identity application layer sends the message body and the target private key to trusted hardware; decrypting the target private key by the trusted hardware, and signing the message body by using the decrypted target private key to obtain a signed message body; the trusted hardware sends the signed message body to the target application to realize the change of the state data in the target application.
In a second aspect, an embodiment of the present application provides an identity management device, applied to a blockchain server, where the server includes an identity application layer and trusted hardware, the device includes:
the system comprises an acquisition module, a verification module and a verification module, wherein the acquisition module is used for responding to the change operation of a user on state data in a target application, and the identity application layer acquires a message body for changing the state data under the condition that the identity and the authority of the user pass verification, wherein the target application is one of at least two applications served by the server; the first determining module is used for determining a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application; the first sending module is used for sending the message body and the target private key to the trusted hardware by the identity application layer; the signature module is used for decrypting the target private key by the trusted hardware, and signing the message body by using the decrypted target private key to obtain a signed message body; and the second sending module is used for sending the message body with the completed signature to the target application by the trusted hardware so as to realize the change of the state data in the target application.
In a third aspect, an embodiment of the present application provides an identity management device, including a memory and a processor, where the memory stores a computer program that can be run on the processor, and the processor executes the program to implement an identity management method of the above method.
In a fourth aspect, embodiments of the present application provide an identity management storage medium storing executable instructions for causing a processor to execute an identity management method implementing the above method.
The embodiment of the application provides an identity management method, an identity management device, identity management equipment and an identity management storage medium, wherein a server side can serve at least two applications, responds to changing operation of state data in a target application by a user, firstly, an identity application layer verifies identity and authority of the user, secondly, the identity application layer obtains a target private key corresponding to the target application, then trusted hardware decrypts the target private key and signs a message body, and finally, the signed message body is used for completing changing operation of the state data in the target application. In this way, the original private key is cryptographically hosted at the hardware level by the trusted authority that serves the user, and the signature interface of the trusted hardware can be invoked to sign the message body only by means of the user's biometric features. The method not only solves the problems that the private key of the user is difficult to store, memorize and use, but also better protects the security and the asset security of the private key of the user. By supporting the butt joint of multiple blockchain bottom platforms, a set of server can manage users of multiple blockchain applications at the same time without repeatedly constructing a blockchain identity security platform.
Drawings
FIG. 1A is a schematic diagram of an overall operation architecture of identity management according to an embodiment of the present application;
fig. 1B is a schematic implementation flow diagram of an identity management method according to an embodiment of the present application;
fig. 2 is a schematic implementation flow chart of an identity management method according to an embodiment of the present application;
fig. 3 is a schematic implementation flow chart of an identity management method according to an embodiment of the present application;
fig. 4A is a schematic flow chart of a method for private key registration according to an embodiment of the present application;
FIG. 4B is a flowchart illustrating a method for invoking private key signing according to an embodiment of the present disclosure;
fig. 5 is a schematic diagram of a composition structure of an identity management device according to an embodiment of the present application;
fig. 6 is a schematic diagram of a hardware entity of an identity management device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.
It should be understood that some embodiments described herein are merely used to explain the technical solutions of the present application, and are not used to limit the technical scope of the present application.
Fig. 1A is a schematic diagram of an overall operation architecture of identity management according to an embodiment of the present application, as shown in fig. 1A, where the schematic diagram includes: a management tool 101, trusted hardware (Trusted Execution Environment, TEE) 102, an identity application layer (Rich OS) 103, a target application 104, and a set of organization blockchain applications 105, wherein:
The management tool 101 is used for uniformly managing the blockchain identity, and can be understood as a blockchain server, and is a uniform blockchain identity management tool deployed in units of institutions, and a single piece of hardware can maintain a plurality of blockchain applications.
Trusted hardware 102, including a private key generation module, an advanced encryption standard (Advanced Encryption Standard, AES) module, and an elliptic curve digital signature algorithm (Elliptic Curve Digital Signature Algorithm, ECDSA) module, the TEE 102 providing externally: a private key generation interface and a data signature interface. The private key generation module is used for generating a 128-bit original private key according to a pseudo-random number algorithm according to the requirements of a user; the AES module is used for encrypting an original private key by using a symmetric encryption algorithm; the ECDSA module functions to encrypt the original private key using an elliptic curve digital signature algorithm.
The Rich OS 103 has a database for storing data at the bottom layer, and can play roles of unified user management, unified user authentication, unified private key management and unified authority management.
The target application 104, e.g., blockchain application a, is configured to provide operation and maintenance management services, blockchain application core services, and node unified access services.
The organization blockchain application group 105 may include blockchain application B, blockchain application C, blockchain application D, and the like.
The identity management method provided by the embodiment of the application is applied to a blockchain server, wherein the server comprises an identity application layer and trusted hardware, and as shown in fig. 1B, the method comprises the following steps:
step S101, responding to the change operation of a user to state data in a target application, and acquiring a message body for changing the state data by the identity application layer under the condition that the identity and the authority of the user pass verification, wherein the target application is one of at least two applications served by the server side;
the management tool 101 as shown in fig. 1A may serve at least two applications, namely, for example: the unified blockchain management tool 101 is deployed in units of organizations, and a single management tool 101 may maintain multiple blockchain applications, such as an organization blockchain application group 105.
The changing operation of the state data in the target application by the user comprises the following steps: the user needs to operate on account data on the blockchain application, such as: transfer operations, and the like. At this point, the user needs to invoke the target private key to sign the body of the message destined for the specified blockchain application, i.e., the target application. The message body is the transaction that alters the state data in the target application. The identity application layer, i.e. the rich execution environment, is used to verify the identity of the user and to provide services for trusted hardware. After the user applies for changing the state data in the target application, the target application requests the user authentication interface from the identity application layer, and after receiving the request, the identity application layer returns the identity authentication page uniform resource locator (Uniform Resource Locator, URL) to carry out biological authentication on the user.
Under the condition that the identity and the authority of the user pass verification, the identity application layer acquires a message body for changing the state data.
Step S102, the identity application layer determines a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application;
the database in the identity application layer 103 as shown in fig. 1A stores a target private key that the user needs to use when operating the target, where the target private key is a symmetrically encrypted original private key. The user's identification may be an identification such as an ID or an identification card number of the user that can uniquely identify the user, and the identification of the target application may be a blockchain address of the target application. And the identity application layer determines a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application.
Step S103, the identity application layer sends the message body and the target private key to trusted hardware;
as shown in fig. 1A, the trusted hardware 103 and the identity application layer 102 are mutually independent trusted execution environments, the trusted hardware provides a hardware-level storage space and a computation space isolated from the outside, and the identity application layer can initiate a request to the trusted hardware through a specific interface. Here, the trusted hardware may be any kind of product, but it is necessary to support a random number algorithm, a symmetric encryption algorithm, and an elliptic curve digital signature algorithm. The identity application layer sends the message body and the target private key to the trusted hardware.
Step S104, the trusted hardware decrypts the target private key, signs the message body by using the decrypted target private key, and obtains the signed message body;
the trusted hardware decrypts the target private key according to an encryption algorithm used when the original private key is encrypted, and then signs the message body by using the encrypted target private key to obtain the signed message body.
Step S105, the trusted hardware sends the signed message body to the target application, so as to implement the change of the state data in the target application.
The trusted hardware sends the signed message body to the target application, and the target application acquires the message body signed by the trusted hardware, which indicates that the message body is valid and legal and safe, so that the change of state data in the target application can be realized, for example: a transfer operation, etc. is performed.
In the embodiment of the application, the server side can serve at least two applications, respond to the change operation of the user on the state data in the target application, firstly, the identity application layer verifies the identity and authority of the user, secondly, the identity application layer obtains the target private key corresponding to the target application, then the trusted hardware decrypts the target private key and signs the message body, and finally, the signed message body is used for completing the change operation of the state data in the target application. In this way, the original private key is cryptographically hosted at the hardware level by the trusted authority that serves the user, and the signature interface of the trusted hardware can be invoked to sign the message body only by means of the user's biometric features. The method not only solves the problems that the private key of the user is difficult to store, memorize and use, but also better protects the security and the asset security of the private key of the user. By supporting the butt joint of multiple blockchain bottom platforms, a set of server can manage users of multiple blockchain applications at the same time without repeatedly constructing a blockchain identity security platform.
The embodiment of the application provides an identity management method, which is applied to a blockchain server, wherein the server comprises an identity application layer and trusted hardware, and as shown in fig. 2, the method comprises the following steps:
step S201, responding to the change operation of the user to the state data in the target application, and verifying the identity of the user by the identity application layer by utilizing the biological characteristics of the user;
here, the biometric authentication is not limited to: face recognition, voiceprint recognition, fingerprint recognition, iris recognition and two-factor authentication, wherein the two-factor authentication can comprise authentication of a short message verification code, mail verification, bank card verification and the like. The use of biometric features can verify whether it is the user's own initiated operation.
Step S202, in the case that the identity of the user passes verification, the identity application layer verifies the authority of the user according to the time of the change operation and the place of the change operation;
the time and place of the change operation are verified to verify that the user has authority to invoke the target private key "at this time". For example: the regulatory authorities specify that the user cannot transfer assets within the blockchain abroad, and if session IP at authentication is overseas IP, the user is not allowed to invoke private key signing.
Step 203, the identity application layer obtains a message body for changing the state data when the identity and the authority of the user pass verification, wherein the target application is one of at least two applications served by the server;
step S204, the identity application layer determines a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application;
step 205, the identity application layer sends the message body and the target private key to trusted hardware;
step S206, the trusted hardware decrypts the target private key, signs the message body by using the decrypted target private key, and obtains the signed message body;
step S207, the trusted hardware sends the signed message body to the target application to realize the change of the state data in the target application.
In the embodiment of the application, the authentication is performed first, then the authority of the user is verified according to the time and the place of the change operation, and only if both the authentication passes, the user can initiate a change request for changing the application state of the blockchain. In this way, a centralized auditing tool based on identity can be provided for the organization, the on-chain transactions of the supervision users can be visualized, abnormal operations of the users can be blocked through custom logic, and the supervision requirements are met, namely, the real naming of the blockchain account numbers is realized.
The identity management method provided by the embodiment of the application is applied to a blockchain server, wherein the server comprises an identity application layer and trusted hardware, and the method comprises the following steps:
step S211, responding to the change operation of a user on state data in a target application, and acquiring a message body for changing the state data by the identity application layer under the condition that the identity and the authority of the user pass verification, wherein the target application is one of at least two applications served by the server side;
step S212, the identity application layer determines a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application;
step S213, the identity application layer sends the message body and the target private key to trusted hardware;
step S214, the trusted hardware decrypts the target private key, signs the message body by using the decrypted target private key, and obtains the signed message body;
step S215, the trusted hardware sends the signed message body to the target application, so as to implement the change of the state data in the target application;
step S216, outputting a user behavior log of the target application or a user behavior audit report by using a user behavior audit interface of the server;
Step S217, outputting updated user catalogue, block chain address corresponding to the user and user information by using the user synchronous interface of the server;
the synchronous information is configured by the administrator in a self-defined way, and the mapping relation can be configured by the manager in a self-defined way. For example, in a field of the unified identity security platform called Name, the corresponding value of Name can be mapped into an application by configuration mapping, for example: call field. Here, the information synchronization may be based on the unit of the user. The user catalog synchronization is applicable to all applications, and only the blockchain address information corresponding to the user is synchronized for the blockchain application, so that mapping and binding of the user and the blockchain address are completed.
And step S218, forwarding the signed message body to each node of the target blockchain application by using a signature message forwarding interface of the server side so as to complete consensus uplink.
In the embodiment of the application, the server provides a user behavior audit interface, so that the target application can acquire a user behavior audit report taking the application as a unit; the user synchronization interface can enable the target application to acquire the latest user catalog, the blockchain address corresponding to the user and the user information; the message forwarding interface is signed so that the signed message can directly call a remote procedure call (Remote Procedure Call, RPC) interface provided by the underlying blockchain, and directly forward to each node to complete the consensus uplink.
The embodiment of the application provides an identity management method, which is applied to a blockchain server, wherein the server comprises an identity application layer and trusted hardware, as shown in fig. 3, and the method for applying a private key comprises the following steps:
step 301, responding to an application private key request sent by the user to the server through the target application, wherein the identity application layer determines whether an original private key corresponding to the target application exists or not according to a mapping relation when the user identity passes verification, and the mapping relation is a mapping relation between a user identifier and a blockchain address;
when a user needs to apply for the private key of the target application, a request for applying for the private key can be sent to the server through the target application, and the identity application layer needs to verify the identity of the user first. The method of verifying the identity of the user may use biometric authentication, not limited to: face recognition, voiceprint recognition, fingerprint recognition, iris recognition and two-factor authentication, wherein the two-factor authentication can comprise authentication of a short message verification code, mail verification, bank card verification and the like. The use of biometric features can verify whether it is the user's own initiated operation.
Here, the mapping relationship stored by the identity application layer may be a mapping between the user identification and the blockchain application address for which the private key application has been completed. The identity application layer can determine whether the original private key corresponding to the target application exists or not according to the mapping relation.
Step S302, under the condition that the identity application layer determines that the original private key does not exist, requesting the trusted hardware to generate the original private key;
and if the identity application layer determines that the original private key corresponding to the target application does not exist, requesting the trusted hardware to generate the original private key.
Step S303, the trusted hardware responds to the request and generates the original private key according to a pseudo-random number algorithm;
here, the random number algorithm may be based on any pseudo random number algorithm, but the seed (seed) of the algorithm needs to have uniqueness, and machine time, a user identity fuzzy characteristic value and the like can be selected. The 128-bit original private key may be generated directly from a pseudo-random number algorithm within the trusted hardware.
Step S304, the trusted hardware encrypts the original private key by using a symmetric encryption algorithm to obtain the target private key;
here, any symmetric encryption algorithm may be selected. Such as advanced encryption standards, etc. The advanced encryption standard is a symmetric encryption advanced encryption standard and has the characteristics of high speed and high security level.
Step S305, sending the target private key to the identity application layer for registration.
In the embodiment of the application, how the user applies for the target private key corresponding to the blockchain application through the server, firstly, the identity of the user is verified, secondly, whether the corresponding private key exists in the identity application layer or not is determined, then the original private key is generated in the trusted hardware according to the pseudo-random algorithm, and finally the trusted hardware encrypts the original private key to obtain the target private key and sends the target private key to the identity application layer for registration. Thus, the private key generated within the trusted hardware: the original private key is encrypted by a symmetric encryption algorithm, the original private key used for encryption is stored in the trusted hardware, and the encrypted target private key is stored in a database of the identity application layer. Because the original private key is stored in the trusted hardware and only the defined interface is opened, the original private key can never appear in an area outside the trusted hardware. Even if the database rights are obtained illegally, a hacker cannot obtain the plaintext private key.
The identity management method provided by the embodiment of the application is applied to a blockchain server, wherein the server comprises an identity application layer and trusted hardware, and the method for applying the private key comprises the following steps:
Step S311, responding to an application private key request sent by the user to the server through the target application, and returning an identity authentication page website by the identity application layer so as to enable the user to carry out biological characteristic authentication;
here, the user can log in the identity authentication page website provided by the identity application layer to perform identity authentication, and the authentication method can be face recognition, voiceprint recognition, fingerprint recognition, iris recognition and double-factor authentication, wherein the double-factor authentication can comprise authentication of a short message authentication code, mail authentication, bank card authentication and the like.
Step S312, the identity application layer determines that the identity of the user passes verification according to the biological characteristic authentication result;
step 313, in the case that the user identity passes the verification, the identity application layer determines whether an original private key corresponding to the target application exists in the user according to the mapping relation;
step S314, under the condition that the identity application layer determines that the original private key does not exist, requesting the trusted hardware to generate the original private key, wherein the mapping relation is the mapping relation between a user identifier and a blockchain address;
Step 315, the trusted hardware responds to the request and generates the original private key according to a pseudo-random number algorithm;
step S316, the trusted hardware encrypts the original private key by using a symmetric encryption algorithm to obtain the target private key;
step S317, the target private key is sent to the identity application layer for registration;
step S318, the trusted hardware generates a public key corresponding to the original private key according to an elliptic curve algorithm, and sends the public key to the identity application layer;
elliptic curve digital signature algorithm (Elliptic Curve Digital Signature Algorithm, ECDSA) is a digital signature algorithm based on elliptic curve cryptography. Elliptic Curve Digital Signature Algorithm (ECDSA) is a signature scheme applied to elliptic curves and having similar properties to the digital signature algorithm (Digital Signature Algorithm, DSA). ECDSA digital signature algorithms are generally considered to be the most widely standardized elliptic curve-based digital signature algorithms. The elliptic curve digital signature algorithm is an asymmetric encryption algorithm that requires two keys: public keys (public keys for short) and private keys (private keys for short). The public key and the private key are a pair, and if the data is encrypted by the public key, the data can be decrypted only by the corresponding private key. Here, any one of asymmetric encryption algorithms, which is not limited to elliptic curve digital signature algorithms, may be used to generate a public key corresponding to the original private key and send the public key to the identity application layer.
Step S319, the identity application layer generates a corresponding blockchain address according to the public key, and establishes the mapping relationship between the blockchain address and the user identifier.
Here, the mapping relationship is stored in the identity application layer, and can be used to determine whether the target application has the corresponding target private key when the private key is applied.
In the embodiment of the application, when a private key corresponding to a target application is applied, an identity application layer is required to return to an identity authentication page website so that the user performs biometric authentication, after a corresponding original private key is generated in trusted hardware, the trusted hardware generates a public key corresponding to the original private key according to an elliptic curve algorithm and sends the public key to the identity application layer, and the identity application layer generates a corresponding blockchain address according to the public key and establishes the mapping relation between the blockchain address and the user identifier. Therefore, before the application of the private key, the verified user identity can realize the security assurance of the application private key, and after the application of the private key, mapping management is established in the identity application layer, so that when the application of the private key, whether the target application has the corresponding target private key can be determined according to the mapping relation, and the management of the target private key is facilitated.
The related art blockchain application identity management method has the following two methods:
the method comprises the following steps: no identity safety construction. The method is characterized in that: 1. the private key plaintext is directly recorded by using paper materials or other physical materials (U shield and digital currency cold wallet), the private key is input into the terminal to sign the message body every time the signature is needed, and the terminal can not buffer the recorded private key. The possibility of theft of the private key in the mode is low, but physical materials are difficult to store, the signature process is quite complicated, and the usability requirement of most users on digital application cannot be met. 2. The private key is directly stored in a plain text or a ciphertext form in terminal equipment used by a user in daily life, and each signature is read by an application under a local catalog of the terminal and the message body is signed. Because the terminal is a daily device for users, the possibility of the private key being stolen is high, and even if the private key is encrypted by using a password, the password is also possibly monitored once the Trojan horse virus is implanted into the terminal because most users have weak security consciousness on the terminal. Therefore, storing the private key directly cannot guarantee the security of the private key, and once the software storing the private key in the terminal is not available or the terminal is not available, the private key cannot be retrieved.
The method has the following problems: 1. the private key is easy to lose, once the private key is lost, the subsequent private key recovery and asset recovery processes are very complex, and the situation that the private key is lost to mean the asset is lost even occurs in most of the current blockchain applications; 2. due to the lack of security awareness of the user, the private key may be stolen by lawbreakers through various ways, such as social engineering attacks, trojan virus implantation, and the like. Without identity security, the private key once stolen means that the asset security cannot be protected. 3. The user mastering the private key means mastering ownership and usage rights of the state mapped by the blockchain address corresponding to the private key, and the supervision organization needs to determine whether the underlying blockchain technology used by the private key supports the freezing operation or not in order to freeze the private key, if not, the supervision organization can only coordinate with other node parties and refuse the request sent by the address together, thereby freezing the rights owned by the private key. Even if the bottom technology supports account freezing operation, the supervision mechanism cannot unilaterally freeze the private key, and needs to initiate frozen voting and is supported by most nodes. However, both the above two methods can implement freezing of the authority of the private key by the supervision authority, but the implementation cost is very high, the freezing cannot be responded quickly and timely, and the risk is not controllable.
The second method is as follows: and (5) independently constructing an identity security layer. The method is characterized in that: 1. when the blockchain application is developed, a user private key hosting tool which is coupled with the application and based on the cloud is built, and when the user creates an application account, the application also helps a client to directly generate a private key and directly store the private key in a database of the cloud.
The second method has the following problems: 1. the independent construction of the identity security layer is usually accompanied by the development of blockchain applications, and many of the applications developers develop the identity security layer in a coupling manner with the development of the application layer. Not every application manufacturer can independently design and develop the identity security and the private key security, and whether the identity security layer is secure or not is uncertain; 2. with the popularity of blockchain technology, a single organization may need to run nodes of a blockchain of dimension, and if a blockchain identity system is independently built, a unified private key authority management design will be lacking, and each application of each chain may have its own identity system. The operation and maintenance management work of the block chain is emphasized, the externally exposed surface of the application is increased, and if the externally exposed surface of the application is too much, the system with the weakest security directly determines the security of all the systems; 3. software-level private key escrow is less secure than hardware-level escrow, and the operational flow is likely to be rewritten.
For the problems in the related art, the embodiment of the present application provides a method for performing private key registration at a blockchain server, as shown in the embodiment of fig. 4A; on the basis, the embodiment of the application also provides a method for calling the private key signature at the blockchain server, as shown in the embodiment of fig. 4B.
Fig. 4A is a flowchart of a method for private key registration according to an embodiment of the present application, taking a blockchain application a as an example of a target blockchain application, where a blockchain unified security identity management tool, that is, a blockchain server, is shown in fig. 4A, and includes:
step S401, applying for a private key of the blockchain application A;
the user initiates a request for a private key of blockchain application a.
Step S402, requesting a user authentication interface;
the blockchain application a requests a user authentication interface from the identity application layer in response to a user request.
Step S403, returning an identity authentication page URL;
the identity application layer returns an identity authentication page URL in response to the request of the blockchain application a.
Step S404, performing biometric authentication;
the user performs the biometric authentication on the authentication page. Biometric authentication is not limited to: face recognition, voiceprint recognition, fingerprint recognition, iris recognition and two-factor authentication, wherein the two-factor authentication can comprise authentication of a short message verification code, mail verification, bank card verification and the like. The use of biometric features can verify whether it is the user's own initiated operation.
Step S405, judging whether the user is operating;
the identity application layer judges whether the operation is the operation of the user or not according to the biological characteristic authentication result, and if not, the flow goes to the step S406; if it is the own operation, the flow goes to step S407.
Step S406, prompting authentication failure;
and outputting a prompt of authentication failure to the user.
Step S407, whether the address of the block chain application A is already owned;
when the user is confirmed to be operating, the identity application layer judges whether the user already has the address of the blockchain application A. If the user already has the address of blockchain application A, flow proceeds to step S408; if the user does not have an address for blockchain application A, flow proceeds to step S409.
Step S408, prompting the user that a private key exists;
a hint is output to the user that the address of blockchain application a, i.e., the private key corresponding to blockchain application a, is already owned.
Step S409, requesting the trusted hardware to generate a private key;
the identity application layer requests the trusted hardware to generate a private key corresponding to blockchain application a.
Step S410, generating a pseudo-random number;
the generation of the user private key in the trusted hardware may be based on any random number algorithm that the trusted hardware is self-contained, but it is necessary to ensure that the seed is unique.
Step S411, generating a public key corresponding to the private key according to an elliptic curve algorithm;
here, the trusted hardware may select an elliptic curve algorithm or any asymmetric encryption algorithm to generate the public key corresponding to the private key.
Step S412, generating a block chain application A address and establishing a mapping relation with the user ID;
and generating a blockchain application A address at an identity application layer, and establishing a mapping relation between the blockchain application A address and the user ID.
Step S413, synchronizing the user address to the blockchain application A;
the user address, i.e., the blockchain application a address generated at the identity application layer, is synchronized in blockchain application a to blockchain application a.
Step S414, obtaining an account address of the block chain application A;
the user obtains the blockchain application a account address.
Step S415, register is completed;
step S416, symmetrically encrypting the original private key by using a key in the trusted hardware based on a symmetric encryption algorithm;
the original private key is encrypted by a symmetric encryption algorithm, and the private key used for encryption is stored in trusted hardware.
Step S417, the encrypted private key is stored in the database of the identity application layer.
The feasible hardware provides a private key generation interface for the identity application layer, and the encrypted private key is stored in a database of the identity application layer by using the private key generation interface.
In the embodiment of the application, it is assumed that the user has registered an identity account in the blockchain unified identity management platform, and if the user has not registered in the blockchain unified identity management platform, the user needs to complete registration in the blockchain unified identity management platform to start the above procedure. Private key generated within trusted hardware: the SK is encrypted by a symmetric encryption algorithm, the KEY used for encryption is stored in trusted hardware, and the encrypted private KEY AES (SK) is stored in a database of an identity application layer. Since the original private key is stored in the trusted hardware and only the limited interface is opened, the plain text of the private key, i.e. the original private key, can never appear in an area outside the trusted hardware. Even if the database rights are obtained illegally, a hacker cannot obtain the plaintext private key.
Fig. 4B is a flowchart of a method for invoking private key signature according to an embodiment of the present application, taking a blockchain application a as a target blockchain application as an example, where a blockchain unified security identity management tool, that is, a blockchain server, is shown in fig. 4B, and includes:
step S420, a user performs a certain operation in the blockchain application A;
the user needs to do some operation in the blockchain application a. For example, the data state on blockchain application a needs to be changed.
Step S421, whether the state data on the blockchain is changed;
the blockchain application a determines whether the operation will change the state data on the blockchain, if not, the flow goes to step S422; if the status data is to be changed, the flow proceeds to step S423.
Step S422, continuing operation;
the user continues to operate on blockchain application a.
Step S423, returning an identity authentication page URL;
the identity application layer returns an identity authentication page URL to the user.
Step S424, performing biometric authentication;
the user performs biometric authentication. Biometric authentication is not limited to: face recognition, voiceprint recognition, fingerprint recognition, iris recognition and two-factor authentication, wherein the two-factor authentication can comprise authentication of a short message verification code, mail verification, bank card verification and the like. The use of biometric features can verify whether it is the user's own initiated operation.
Step S425, whether the user is operating;
the identity application layer determines whether the user is operating according to the authentication result. If not, flow goes to step S426; if it is the own operation, the flow goes to step S427.
Step S426, prompting authentication failure;
and outputting a prompt of authentication failure to the user.
Step S427, whether the private key has the right to call at the moment;
the authentication layer determines whether there is private key invoking authority at this point. For example: regulatory authorities specify that the user cannot transfer assets within the blockchain abroad, and if session IP at authentication is overseas IP, the user is not allowed to invoke private key signing). If it is determined that there is no private key transfer authority at this time, the flow goes to step S428, and if it is determined that there is private key transfer authority at this time, the flow goes to step S429.
Step 428, prompting the user that the private key has no permission to call;
and outputting a prompt that the user does not have the private key calling authority to the user.
S429, packaging the transaction of the user needing to call the private key signature;
the transaction referred to herein, the upper-level message body, is the message body that the user changes the blockchain application a data state. The blockchain application a encapsulates transactions that the user needs to invoke private key signatures.
Step S430, the database inquires the encrypted private key of the user, and takes the transaction and the encrypted private key as parameters to call the interface of the trusted hardware;
and querying the encrypted private key of the user by using a database in the identity application layer, and calling an interface of the trusted hardware by taking the transaction and the encrypted private key as parameters. Where trusted hardware would provide a data signature interface to the identity application layer.
Step S431, decrypting the private key of the user by using a key in the trusted hardware based on a symmetric encryption algorithm;
the encrypted private key is obtained at the identity application layer, and the private key of the user is decrypted in the trusted hardware based on the agreed symmetric encryption algorithm.
Step S432, signing the message by using the decrypted private key of the user based on an asymmetric encryption algorithm;
the trusted hardware signs the message with the decrypted user private key, i.e., the original private key, based on an asymmetric encryption algorithm. The message herein is referred to as the message body referred to above.
Step S433, receiving the signature message and synchronizing to the blockchain network to complete the consensus uplink;
the blockchain application a receives the signed message and synchronizes to the blockchain network to complete the consensus uplink.
Step S434, a transaction receipt is received.
The user receives a receipt of the completed transaction.
In the embodiment of the application, when the user needs the address state on the blockchain, the user needs to rely on the state change message signed by the private key for generating the address, so that only the operation related to changing the address state on the blockchain can be pulled up to enhance the authentication, and the user is allowed to invoke the private key to change the state on the blockchain of the user only after the authentication of the identity and the authority. The transaction receipt is returned to the user after the successful uplink, and the user does not receive an erroneous receipt because the message is not signed to the node if the authentication fails. The scheme is suitable for the condition that nodes such as a alliance chain, a private chain and the like are maintained by a trusted authority. Because the blockchain solves the trust problem between the enterprises of the maintenance node in the alliance chain scene, and cannot solve the trust problem between the users and the enterprises, the users theoretically trust the enterprises for providing services. For example, some tax states of the user are maintained in a blockchain commonly operated and maintained by tax bureau, human resource guarantee bureau, court and public security, so when the user is using the tax bureau service developed based on the blockchain, the user trusts the tax bureau, and thus the private key of the user is trusted by the tax bureau to meet the requirements of the production environment.
Based on the foregoing embodiments, the embodiments of the present application provide an identity management apparatus, where the apparatus includes each module included may be implemented by a processor in an identity management device; of course, the method can also be realized by a specific logic circuit; in an implementation, the processor may be a Central Processing Unit (CPU), a Microprocessor (MPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), or the like.
Fig. 5 is a schematic diagram of a composition structure of an identity management device provided in an embodiment of the present application, as shown in fig. 5, where, the identity management device 500 includes an obtaining module 501, a first determining module 502, a first sending module 503, a signing module 504, and a second sending module 505, where:
the obtaining module 501 is configured to respond to a change operation of a user on status data in a target application, where the target application is one of at least two applications served by the server, and in a case that an identity and authority of the user pass verification, the identity application layer obtains a message body for changing the status data;
a first determining module 502, configured to determine, by the identity application layer according to the identity of the user and the identity of the target application, a target private key from a database in the identity application layer;
A first sending module 503, configured to send the message body and the target private key to trusted hardware by the identity application layer;
a signing module 504, configured to decrypt the target private key by using the trusted hardware, and sign the message body by using the decrypted target private key to obtain a signed message body;
and the second sending module 505 is configured to send the signed message body to the target application by using the trusted hardware, so as to implement the change of the state data in the target application.
Based on the foregoing embodiments, an embodiment of the present application provides an identity management device, where the device further includes a first verification module and a second verification module, where the first verification module is configured to verify, by using a biometric feature of the user, an identity of the user by using the identity application layer; the second verification module is used for verifying the authority of the user according to the time of the change operation and the place of the change operation by the identity application layer under the condition that the identity of the user passes verification.
Based on the foregoing embodiments, the embodiments of the present application provide an identity management device, where the device further includes a first output module, a second output module, and a third output module, where the first output module is configured to output, using a user behavior audit interface of the server, a user behavior log of the target application, or a user behavior audit report; the second output module is used for outputting updated user catalogues, block chain addresses corresponding to users and user information by utilizing the user synchronization interface of the server; and the third output module is used for forwarding the signed message body to each node of the target blockchain application by utilizing the signature message forwarding interface of the server side so as to complete consensus uplink.
Based on the foregoing embodiment, the embodiment of the present application provides an identity management device, where the device further includes a second determining module, a request module, a first generating module, an encrypting module, and a third sending module, where the second determining module is configured to respond to an application private key request sent by the user to the server through the target application, and in a case that the user identity passes verification, the identity application layer determines whether an original private key corresponding to the target application exists for the user according to a mapping relationship, where the mapping relationship is a mapping relationship between a user identifier and a blockchain address; the request module is used for requesting the trusted hardware to generate the original private key under the condition that the identity application layer determines that the original private key does not exist; the first generation module is used for responding to the request by the trusted hardware and generating the original private key according to a pseudo-random number algorithm; the encryption module is used for encrypting the original private key by the trusted hardware by using a symmetric encryption algorithm to obtain the target private key; and the third sending module is used for sending the target private key to the identity application layer for registration.
Based on the foregoing embodiment, the embodiment of the present application provides an identity management device, where the device further includes a return module and a third determining module, where the return module is configured to respond to an application private key request sent by the user to the server through the target application, and the identity application layer returns an identity authentication page address, so that the user performs biometric authentication; the third determining module is configured to determine, by the identity application layer according to the biometric authentication result, that the identity of the user is verified.
Based on the foregoing embodiment, the embodiment of the present application provides an identity management device, where the device further includes a second generating module and an establishing module, where the second generating module is configured to generate, by using the trusted hardware, a public key corresponding to the original private key according to an elliptic curve algorithm, and send the public key to the identity application layer; the establishing module is used for generating a corresponding blockchain address by the identity application layer according to the public key and establishing the mapping relation between the blockchain address and the user identifier.
The description of the apparatus embodiments above is similar to that of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.
It should be noted that, in the embodiment of the present application, if the above-mentioned identity management method is implemented in the form of a software functional module, and is sold or used as a separate product, the identity management method may also be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied essentially or in a part contributing to the related art in the form of a software product stored in a storage medium, including several instructions for causing an electronic device (which may be a mobile phone, a tablet computer, a notebook computer, a desktop computer, etc.) to perform all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, an optical disk, or other various media capable of storing program codes. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.
Accordingly, embodiments of the present application provide a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the identity management method provided in the above embodiments.
Correspondingly, an embodiment of the present application provides an identity management device, fig. 6 is a schematic diagram of a hardware entity of the identity management device of the embodiment of the present application, as shown in fig. 6, the hardware entity of the identity management device 600 includes: comprising a memory 601 and a processor 602, said memory 601 storing a computer program executable on the processor 602, said processor 602 implementing the steps of the identity management method provided in the above embodiments when said program is executed.
The memory 601 is configured to store instructions and applications executable by the processor 602, and may also cache data (e.g., image data, audio data, voice communication data, and video communication data) to be processed or processed by the respective modules in the processor 602 and the identity management device 600, and may be implemented by a FLASH memory (FLASH) or a random access memory (Random Access Memory, RAM).
It should be noted here that: the description of the storage medium and apparatus embodiments above is similar to that of the method embodiments described above, with similar benefits as the method embodiments. For technical details not disclosed in the embodiments of the storage medium and the apparatus of the present application, please refer to the description of the method embodiments of the present application for understanding.
It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application. The foregoing embodiment numbers of the present application are merely for describing, and do not represent advantages or disadvantages of the embodiments.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above described device embodiments are only illustrative, e.g. the division of the units is only one logical function division, and there may be other divisions in practice, such as: multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. In addition, the various components shown or discussed may be coupled or directly coupled or communicatively coupled to each other via some interface, whether indirectly coupled or communicatively coupled to devices or units, whether electrically, mechanically, or otherwise.
The units described above as separate components may or may not be physically separate, and components shown as units may or may not be physical units; can be located in one place or distributed to a plurality of network units; some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may be separately used as one unit, or two or more units may be integrated in one unit; the integrated units may be implemented in hardware or in hardware plus software functional units.
Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the above method embodiments may be implemented by hardware related to program instructions, and the foregoing program may be stored in a computer readable storage medium, where the program, when executed, performs steps including the above method embodiments; and the aforementioned storage medium includes: a mobile storage device, a Read Only Memory (ROM), a magnetic disk or an optical disk, or the like, which can store program codes.
Alternatively, the integrated units described above may be stored in a computer readable storage medium if implemented in the form of software functional modules and sold or used as a stand-alone product. Based on such understanding, the technical solution of the embodiments of the present application may be embodied essentially or in a part contributing to the related art in the form of a software product stored in a storage medium, including several instructions for causing an identity management device (which may be a mobile phone, a tablet computer, a notebook computer, a desktop computer, etc.) to perform all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a removable storage device, a ROM, a magnetic disk, or an optical disk.
The methods disclosed in the several method embodiments provided in the present application may be arbitrarily combined without collision to obtain a new method embodiment.
The features disclosed in the several product embodiments provided in the present application may be combined arbitrarily without conflict to obtain new product embodiments.
The features disclosed in the several method or apparatus embodiments provided in the present application may be arbitrarily combined without conflict to obtain new method embodiments or apparatus embodiments.
The foregoing is merely an embodiment of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (12)

1. An identity management method applied to a blockchain server, wherein the server comprises an identity application layer and trusted hardware, and the method comprises the following steps:
responding to a change operation of a user on state data in a target application, and acquiring a message body for changing the state data by the identity application layer under the condition that the identity and the authority of the user pass verification, wherein the target application is one of at least two applications served by the server side;
The identity application layer determines a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application;
the identity application layer sends the message body and the target private key to trusted hardware;
decrypting the target private key by the trusted hardware, and signing the message body by using the decrypted target private key to obtain a signed message body;
the trusted hardware sends the signed message body to the target application to realize the change of the state data in the target application.
2. The method of claim 1, wherein the method further comprises:
the identity application layer verifies the identity of the user by using the biological characteristics of the user;
and under the condition that the identity of the user passes verification, the identity application layer verifies the authority of the user according to the time of the change operation and the place of the change operation.
3. The method of claim 1 or 2, wherein the method further comprises:
and outputting a user behavior log of the target application or a user behavior audit report by using the user behavior audit interface of the server.
4. The method of claim 1 or 2, wherein the method further comprises:
and outputting the updated user catalog, the blockchain address corresponding to the user and the user information by using the user synchronous interface of the server.
5. The method of claim 1 or 2, wherein the method further comprises:
and forwarding the signed message body to each node of the target blockchain application by using the signature message forwarding interface of the server to complete the consensus uplink.
6. The method of claim 1 or 2, wherein the method further comprises:
responding to an application private key request sent by the user to the server through the target application, and determining whether an original private key corresponding to the target application exists in the user according to a mapping relation by the identity application layer under the condition that the identity of the user passes verification, wherein the mapping relation is a mapping relation between a user identifier and a blockchain address;
requesting the trusted hardware to generate the original private key if the identity application layer determines that the original private key does not exist;
the trusted hardware responds to the request and generates the original private key according to a pseudo-random number algorithm;
The trusted hardware encrypts the original private key by using a symmetric encryption algorithm to obtain the target private key;
and sending the target private key to the identity application layer for registration.
7. The method of claim 6, wherein the method of verifying the identity of the user comprises:
responding to a private key application request sent by the user to the server through the target application, and returning an identity authentication page website by the identity application layer so as to enable the user to carry out biological characteristic authentication;
and the identity application layer determines that the identity of the user passes verification according to the biological characteristic authentication result.
8. The method of claim 6, wherein the method further comprises:
the trusted hardware generates a public key corresponding to the original private key according to an elliptic curve algorithm and sends the public key to the identity application layer;
and the identity application layer generates a corresponding blockchain address according to the public key, and establishes the mapping relation between the blockchain address and the user identifier.
9. An identity management device applied to a blockchain server, the server comprising an identity application layer and trusted hardware, the device comprising:
The system comprises an acquisition module, a verification module and a verification module, wherein the acquisition module is used for responding to the change operation of a user on state data in a target application, and the identity application layer acquires a message body for changing the state data under the condition that the identity and the authority of the user pass verification, wherein the target application is one of at least two applications served by the server;
the first determining module is used for determining a target private key from a database in the identity application layer according to the identification of the user and the identification of the target application;
the first sending module is used for sending the message body and the target private key to the trusted hardware by the identity application layer;
the signature module is used for decrypting the target private key by the trusted hardware, and signing the message body by using the decrypted target private key to obtain a signed message body;
and the second sending module is used for sending the message body with the completed signature to the target application by the trusted hardware so as to realize the change of the state data in the target application.
10. The apparatus of claim 9, wherein the apparatus further comprises:
the first verification module is used for verifying the identity of the user by the identity application layer through the biological characteristics of the user;
And the second verification module is used for verifying the authority of the user according to the time and the place of the change operation by the identity application layer under the condition that the identity of the user passes verification.
11. An identity management device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that the processor implements the steps of the method of any one of claims 1 to 8 when the program is executed.
12. A storage medium storing executable instructions for causing a processor to perform the steps of the method of any one of claims 1 to 8.
CN202010904673.5A 2020-09-01 2020-09-01 Identity management method, device, equipment and storage medium Active CN112187466B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010904673.5A CN112187466B (en) 2020-09-01 2020-09-01 Identity management method, device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010904673.5A CN112187466B (en) 2020-09-01 2020-09-01 Identity management method, device, equipment and storage medium

Publications (2)

Publication Number Publication Date
CN112187466A CN112187466A (en) 2021-01-05
CN112187466B true CN112187466B (en) 2023-05-12

Family

ID=73924106

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010904673.5A Active CN112187466B (en) 2020-09-01 2020-09-01 Identity management method, device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN112187466B (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113114625B (en) * 2021-03-16 2023-07-18 上海源庐加佳信息科技有限公司 User identity verification method, system, medium and terminal based on block chain
CN113408749B (en) * 2021-05-08 2024-08-13 中国移动通信集团陕西有限公司 Method, device, equipment and storage medium for generating operation data
CN113591070A (en) * 2021-08-10 2021-11-02 湖北天天数链技术有限公司 Digital identity management method, platform, device, electronic equipment and storage medium
CN114697122B (en) * 2022-04-08 2023-11-07 中国电信股份有限公司 Data transmission method, device, electronic equipment and storage medium
CN115085946B (en) * 2022-08-22 2022-11-04 航天信息股份有限公司 Cross-chain identity verification method and system based on block chain
CN115426179B (en) * 2022-09-01 2024-05-03 中国联合网络通信集团有限公司 Information retrieving method and device and electronic equipment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106161017A (en) * 2015-03-20 2016-11-23 北京虎符科技有限公司 ID authentication safety management system
CN109687959A (en) * 2018-12-29 2019-04-26 上海唯链信息科技有限公司 Key security management system and method, medium and computer program
CN111062716A (en) * 2019-11-29 2020-04-24 支付宝(杭州)信息技术有限公司 Method and device for generating block chain signature data and block chain transaction initiating system
CN111414599A (en) * 2020-02-26 2020-07-14 北京奇艺世纪科技有限公司 Identity authentication method, device, terminal, server and readable storage medium

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10079682B2 (en) * 2015-12-22 2018-09-18 Gemalto Sa Method for managing a trusted identity

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106161017A (en) * 2015-03-20 2016-11-23 北京虎符科技有限公司 ID authentication safety management system
CN109687959A (en) * 2018-12-29 2019-04-26 上海唯链信息科技有限公司 Key security management system and method, medium and computer program
CN111062716A (en) * 2019-11-29 2020-04-24 支付宝(杭州)信息技术有限公司 Method and device for generating block chain signature data and block chain transaction initiating system
CN111414599A (en) * 2020-02-26 2020-07-14 北京奇艺世纪科技有限公司 Identity authentication method, device, terminal, server and readable storage medium

Also Published As

Publication number Publication date
CN112187466A (en) 2021-01-05

Similar Documents

Publication Publication Date Title
CN112187466B (en) Identity management method, device, equipment and storage medium
US11818274B1 (en) Systems and methods for trusted path secure communication
JP6370722B2 (en) Inclusive verification of platform to data center
US9544297B2 (en) Method for secured data processing
US8196186B2 (en) Security architecture for peer-to-peer storage system
CN104798083B (en) For the method and system of authentication-access request
CN105681470B (en) Communication means, server based on hypertext transfer protocol, terminal
US20200412554A1 (en) Id as service based on blockchain
US11831753B2 (en) Secure distributed key management system
CN109981255B (en) Method and system for updating key pool
JP2007511810A (en) Proof of execution using random number functions
JP2010514000A (en) Method for securely storing program state data in an electronic device
CN104753674A (en) Application identity authentication method and device
EP3292654B1 (en) A security approach for storing credentials for offline use and copy-protected vault content in devices
JP2010231404A (en) System, method, and program for managing secret information
CN116250209A (en) Data management and encryption in a distributed computing system
CN108768650B (en) Short message verification system based on biological characteristics
CN114338091A (en) Data transmission method and device, electronic equipment and storage medium
CN115459929B (en) Security verification method, security verification device, electronic equipment, security verification system, security verification medium and security verification product
JP2006279269A (en) Information management device, information management system, network system, user terminal, and their programs
CN116346341A (en) Private key protection and server access method, system, equipment and storage medium
JPH1165443A (en) Management element system for individual authentication information
CN111404680B (en) Password management method and device
CN115150184B (en) Method and system for applying metadata in fabric block chain certificate
CN114005190B (en) Face recognition method for class attendance system

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
GR01 Patent grant
GR01 Patent grant