CN116388979A - Key escrow method, device, equipment and storage medium - Google Patents
Key escrow method, device, equipment and storage medium Download PDFInfo
- Publication number
- CN116388979A CN116388979A CN202310355214.XA CN202310355214A CN116388979A CN 116388979 A CN116388979 A CN 116388979A CN 202310355214 A CN202310355214 A CN 202310355214A CN 116388979 A CN116388979 A CN 116388979A
- Authority
- CN
- China
- Prior art keywords
- private key
- target user
- key
- authentication token
- information
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 75
- 238000012795 verification Methods 0.000 claims description 26
- 238000011084 recovery Methods 0.000 claims description 19
- 238000004364 calculation method Methods 0.000 claims description 6
- 238000004891 communication Methods 0.000 claims description 4
- 238000004590 computer program Methods 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 9
- 238000012545 processing Methods 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 239000003999 initiator Substances 0.000 description 3
- 230000011218 segmentation Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- KAICRBBQCRKMPO-UHFFFAOYSA-N phosphoric acid;pyridine-3,4-diamine Chemical compound OP(O)(O)=O.NC1=CC=NC=C1N KAICRBBQCRKMPO-UHFFFAOYSA-N 0.000 description 2
- YSCNMFDFYJUPEF-OWOJBTEDSA-N 4,4'-diisothiocyano-trans-stilbene-2,2'-disulfonic acid Chemical compound OS(=O)(=O)C1=CC(N=C=S)=CC=C1\C=C\C1=CC=C(N=C=S)C=C1S(O)(=O)=O YSCNMFDFYJUPEF-OWOJBTEDSA-N 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002427 irreversible effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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
- H04L9/321—Cryptographic 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 involving a third party or a trusted authority
- H04L9/3213—Cryptographic 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 involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
Abstract
The application provides a key escrow method, a device, equipment and a storage medium, and relates to the technical field of blockchain. The method comprises the following steps: acquiring an authentication token, distributed identity account information and a private key of a target user based on a first private key hosting request initiated by the target user; encrypting the private key based on the authentication token to obtain an encrypted private key; and establishing a corresponding relation between the encryption private key and the distributed identity account number of the target user, and storing the corresponding relation in a preset database. Compared with the prior art, the DID control method and device avoid the problem that if the DID private key of the user is lost, the user loses the DID control right.
Description
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a method, an apparatus, a device, and a storage medium for key escrow.
Background
With the development of internet technology, digital identities gradually come into the field of view of people, and the subjects to which digital identities relate are more than people, including organizations, and even future items. These persons or organizations, items cannot be taken or deleted without simply relying on the original centralized authority, and are identities that are carried throughout the life.
In the domestic alliance distributed identity identification DID scheme in the prior art, each user corresponds to a bottom private key, and when the user executes some account operations, the user needs to realize control rights of the DID by the private keys. Because of user habit, users tend to be less concerned about the underlying private key of the DID account.
But in this way, since the private key itself is stored in the decentralized application DAPP, if the user DID private key is lost, the user will lose control of that DID.
Disclosure of Invention
The present invention aims to provide a key escrow method, device, equipment and storage medium, which solve the problem that if a user DID private key is lost, the user will lose the control right of the DID in the prior art.
In order to achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:
in a first aspect, an embodiment of the present application provides a key escrow method, applied to a key escrow device, where the method includes:
acquiring an authentication token, distributed identity account information and a private key of a target user based on a first private key hosting request initiated by the target user;
encrypting the private key based on the authentication token to obtain an encrypted private key;
and establishing a corresponding relation between the encryption private key and the distributed identity account number of the target user, and storing the corresponding relation in a preset database.
In a second aspect, another embodiment of the present application provides a key escrow apparatus, the apparatus comprising: the device comprises an acquisition module, an encryption module and a storage module, wherein:
the acquisition module is used for acquiring an authentication token, distributed identity account information and a private key of a target user based on a first private key escrow request initiated by the target user;
the encryption module is used for encrypting the private key based on the authentication token to obtain an encrypted private key;
the storage module is used for establishing a corresponding relation between the encryption private key and the distributed identity account number of the target user and storing the corresponding relation to a preset database.
In a third aspect, another embodiment of the present application provides a key escrow device, including: a processor, a storage medium storing machine-readable instructions executable by the processor, the processor in communication with the storage medium via the bus when the key escrow device is running, the processor executing the machine-readable instructions to perform the steps of the method as set forth in any one of the first aspects above.
In a fourth aspect, another embodiment of the present application provides a storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the method according to any of the first aspects described above.
The beneficial effects of this application are: by adopting the key escrow method provided by the application, firstly, the key escrow equipment provided by the application has a notarization, the security is guaranteed, the problem that the private key of the target user is in leakage risk in the key escrow process is avoided to a certain extent, and in the embodiment of the application, after the authentication token and the private key of the target user are obtained, the key escrow equipment encrypts the private key according to the authentication token to obtain an encrypted private key, then, the corresponding relation between the encrypted private key and the distributed identity account of the target user is established, the problem that the distributed identity account of the target user cannot be recovered if the private key is lost is avoided, the retrievability of the private key of the target user is guaranteed, and in the key escrow process, the private key of the target user is the encrypted private key, so that the security of the private key of the target user is guaranteed.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, it being understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered limiting the scope, and that other related drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a flow chart of a key escrow method according to an embodiment of the present disclosure;
fig. 2 is a flow chart of a key escrow method according to another embodiment of the present disclosure;
fig. 3 is a flow chart of a key escrow method according to another embodiment of the present disclosure;
fig. 4 is a flow chart of a key escrow method according to another embodiment of the present disclosure;
fig. 5 is a flow chart of a key escrow method according to another embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of a key escrow device according to an embodiment of the present disclosure;
fig. 7 is a schematic structural diagram of a key escrow device according to another embodiment of the present disclosure;
fig. 8 is a schematic structural diagram of a key escrow device according to an embodiment of the present application.
Detailed Description
For the purposes of making the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of 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, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments.
The components of the embodiments of the present application, which are generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, as provided in the accompanying drawings, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, are intended to be within the scope of the present application.
Additionally, a flowchart, as used in this application, illustrates operations implemented in accordance with some embodiments of the present application. It should be understood that the operations of the flow diagrams may be implemented out of order and that steps without logical context may be performed in reverse order or concurrently. Moreover, one or more other operations may be added to the flow diagrams and one or more operations may be removed from the flow diagrams as directed by those skilled in the art.
To ensure an understanding of the present application, the following description is made with reference to certain terms:
distributed digital identity: distributed identities are more than people, including organizations, and even future items. These persons or organizations, items cannot be taken or deleted without simply relying on the original centralized authority, and are identities that are carried throughout the life.
Distributed identity (Decentralized Identifiers, DID): the digital identifier is a decentralised verifiable digital identifier and has the characteristics of distributed, autonomous and controllable, cross-chain multiplexing and the like. The entity can autonomously complete the registration, resolution, update or revocation operation of the DID. The DID resolves specifically into DID documents that include the unique identification code of the DID, the list of public keys and details of the public keys (holder, encryption algorithm, key status, etc.), and other attribute descriptions of the DID holder.
The verifiable claim (Verifiable Credential) provides a specification describing certain attributes that an entity has to enable evidence-based trust. The DID holder can prove to other entities (individuals, organizations, concrete things, etc.) that certain properties of himself are trusted by a verifiable statement. Meanwhile, by combining cryptography technologies such as digital signature, zero knowledge proof and the like, the statement can be safer and more reliable, and the privacy of the user is further ensured not to be infringed.
Dapp (Decentralised application): software applications that run publicly on the network, which are not different from ordinary applications, all have the same function, but are different in that Dapp runs on the P2P network.
The blockchain account has three major elements: private key, public key, address. Wherein:
public keys (public keys), private keys (private keys) are the content of cryptographic asymmetric encryption algorithms. As the name implies, public keys are public, while private keys are kept secure.
Private key: the public key is generated by random seed, and the private key is derived by algorithm. Because the public key is too long, an "address" appears for simplicity and practicality, the address being derived from the public key. These derivation processes are unidirectional irreversible. That is, the address cannot push the public key, and the public key cannot push the private key.
In the VC system, there are several participants:
issuer (Issuer): entities having user data and capable of developing VC, such as government, banking, university, etc. institutions and organizations.
Holder (Holder): the holder is the user. The user requests, receives and holds the VC from the Issuer entity and presents the VC to the verifier. The prescribed VC can be stored by itself, so that the VC can be used again later, for example, in a wallet.
A Verifier (Verifier) accepts a VC and verifies it, whereby the VC-presenting person may be provided with some type of service.
Identifier registration authorities (Verifiable Data Registry) maintain databases of DIDs, such as a blockchain, a distributed ledger.
The overall flow of DID and VC lifecycle may include the following:
1. holder user did registration and did document query
2. The issuer registers the did and becomes the issuer
3. The holder user applies for vc, and the issuer verifies that the did issues vc
4. The holder user provides the VC to the verifier, who verifies the user/issuer/signature information, etc., who may also invoke the issuer checkVC state.
Roles and information flows in the verifiable credential ecosystem are as follows:
the issuer discovers that a VC is a holder and that issuance always occurs before any other operations involving the credential. The holder may transfer one or more VCs to others; the holder may present one or more VCs to the verifier, and optionally present VPs; the verifier verifies the authenticity of the rendered VCs and VPs. Checking the suspension state of the VC is also included herein; the issuer may revoke the VC. The holder may delete the VC.
A key escrow method provided in the embodiments of the present application is explained below in conjunction with a plurality of specific application examples.
In a possible implementation manner, the embodiment of the present invention provides a key escrow method, and fig. 1 is a schematic flow chart of a key escrow method provided in an embodiment of the present application, as shown in fig. 1, where the method includes:
s101: based on a first private key hosting request initiated by a target user, acquiring an authentication token, distributed identity account information and a private key of the target user.
In the embodiment of the application, in order to ensure the privacy of the target user, the key escrow device is endorsed by a notarization department, the security of the key escrow device is guaranteed, the key escrow of the key escrow device is authoritative, and in the process of the key escrow, the private key of the target user is not easy to use or reveal.
In addition, in order to further ensure the privacy of the target user, in the embodiment of the present application, the authentication token, the distributed identity account information and the private key of the target user in the first private key escrow request sent by the target user to the key escrow device are all transmitted in an encrypted manner.
The authentication tokens are returned by an identity issuer system acquired in advance by a user and are generated based on a distributed identity identification account, each authentication token has own use time limit, a target user needs to initiate a first private key escrow request within preset use time after receiving the authentication token returned by the identity issuer system, and escrow failure can be caused if the time for initiating the first private key escrow request by the target user exceeds the preset use time; the preset use time is configured in the key escrow device in advance, for example: the specific preset use time can be flexibly adjusted according to the needs of the user, and is not limited to the above embodiments.
S102: and encrypting the private key based on the authentication token to obtain an encrypted private key.
After the authentication token and the private key of the target user are acquired, the private key is encrypted through the authentication token by the key escrow equipment, so that the encryption escrow of the private key of the target user is realized, and the encrypted private key cannot be acquired by other users.
In some possible embodiments, the validity of the authentication Token (Token) needs to be verified before the private key is encrypted based on the authentication Token; it is determined whether the authentication token is within a valid time and has a number of valid uses.
In the embodiment of the application, each Token can be used only once, and after the Token is used, the Token does not have the use times, namely the validity of the authentication Token cannot be verified; taking the preset expiration time of each Token as an example for 10 minutes, if the key escrow device detects that the current Token does not exceed the preset expiration time and the DID of the initiator of the current Token and the use times pass verification, the current Token is determined to pass the validity verification, and if the system key escrow device detects that the current Token does not exceed the preset expiration time and the DID of the initiator of the current Token and the use times pass verification, the relationship between the DId of the Token corresponding to the Token and the operation type is maintained in a cache, and the user is waited for calling.
S103: and establishing a corresponding relation between the encryption private key and the distributed identity account number of the target user, and storing the corresponding relation in a preset database.
After the corresponding relation between the encrypted private key and the distributed identity account number of the target user is established and stored in the preset database, if the subsequent private key of the target user is lost, the private key can be retrieved in the preset database according to the distributed identity account number of the target user, so that the problem that the distributed identity account number of the target user cannot be recovered due to the loss of the private key is avoided, and in the process of storing the private key, the security of the private key of the target user is ensured because the private key is encrypted through the authentication token.
By adopting the key escrow method provided by the application, firstly, the key escrow equipment provided by the application has a notarization, the security is guaranteed, the problem that the private key of the target user is in leakage risk in the key escrow process is avoided to a certain extent, and in the embodiment of the application, after the authentication token and the private key of the target user are obtained, the key escrow equipment encrypts the private key according to the authentication token to obtain an encrypted private key, then, the corresponding relation between the encrypted private key and the distributed identity account of the target user is established, the problem that the distributed identity account of the target user cannot be recovered if the private key is lost is avoided, the retrievability of the private key of the target user is guaranteed, and in the key escrow process, the private key of the target user is the encrypted private key, so that the security of the private key of the target user is guaranteed.
Optionally, on the basis of the foregoing embodiment, an embodiment of the present application may further provide a key hosting method, and an implementation procedure of the method is described below by way of example with reference to the accompanying drawings. Fig. 2 is a flow chart of a key escrow method according to another embodiment of the present application, as shown in fig. 2, before S101, the method may further include:
s111: the target user is obtained based on a second private key escrow request initiated by the identity issuer system.
Wherein the second private key escrow request includes: the method comprises the steps of user information, signature information and distributed identity account information of a target user, wherein the distributed identity account information is calculated by an identity issuer system based on the user information.
In the embodiment of the present application, the target user may be, for example, an individual user or an enterprise user, and when the target user is an individual user, the user information thereof may be, for example: at least two items of identity card information, name information, mobile phone number information or face information of the target person; when the target user is an enterprise user, the corresponding user information may be, for example: it should be understood that the above embodiments are only exemplary, and the content and number of information included in specific user information may be flexibly adjusted according to user needs, and are not limited to the above embodiments, and only the target user may be uniquely determined according to the user information, which is not limited in this application.
After a user initiates a second private key escrow request, the second private key escrow request is sent to the key escrow device based on an identity issuer system, after receiving user information of a target user, the identity issuer system calculates a DID according to the user information of the target user to obtain the DID after the identity issuer system receives the user information of the target user, then the identity issuer system signs the DID by using a private key of the target user to obtain signature information of the target user, and then the identity issuer system initiates the second private key escrow request to the key escrow device to apply for an authentication token.
S112: the second private key escrow request is validated.
In an embodiment of the present application, the verification process for verifying the second private key escrow request may, for example, include the following verification steps: firstly, verifying signature information, and determining whether the blockchain address information in the signature information is consistent with the blockchain address information of a target user; determining distributed identification information to be verified based on user information of a target user; determining whether the distributed identification information to be verified is consistent with the distributed identity account information; if the verification results are consistent, determining that the second private key escrow request passes verification; and if at least one inconsistency exists in the verification result, returning a request failure instruction to the client of the target user.
Specifically, the key escrow device will verify the signature of the target user first, and through the verification algorithm, the blockchain address of the signer can be deduced: if the signer is not the blockchain address of the target user, determining that the verification of the signature information fails, that is, determining that the second private key escrow request fails to call, and specifically, verifying the signature by using a logic code can be as follows;
| string signer＝veriySecp256k1Sign(sign,did) |
| signer=veriysecp 256k1Sign (signature, did) |
Subsequently, the key escrow equipment continues to verify the DID information of the target user, and after the key escrow equipment calculates to obtain DID to be verified (after the distributed identification information to be verified) through the input user information, the key escrow equipment determines whether the DID information to be verified is consistent with the DID information in the second private key escrow request; if the DID information of the target user is consistent, the DID information of the target user is successfully verified, otherwise, the DID information of the target user is failed to be verified, namely, the second private key escrow request is failed to be called; by the key escrow device actively calculating the to-be-verified did from the user information, it may be further ensured that the second private key escrow request was initiated or applied for by the target user himself. Because the identity issuer system itself does not store user identity information of the user, malicious invocation application hosting by the identity issuer can be precluded by such a 6-authentication approach.
Since in embodiments of the present application the key escrow device generates an authentication Token (Token) in the following manner: generating a Token through a did+ operation type of a target user and a time stamp, setting preset use time (preset effective time or preset expiration time) and preset use times of the Token, wherein each Token can only be initiated by a designated DID, and if the DID of an initiator is different from the DID of the Token, determining that the validity verification of the authentication Token is not passed; the operation type may be, for example, a managed or.
The logic code for determining Token may be, for example, as follows:
| token=sha3hash (did+type of operation (managed or resume) +timestamp) |
S113: and if the authentication is passed, sending an authentication token of the target user to the target user based on the identity account number.
If the authentication passes and the target user successfully receives the authentication token, the authentication token is deleted in the cache and is stored by the target user, and the setting mode ensures that the authentication token is only owned by the target user, namely, the privacy of the private key of the target user is ensured, and the situation that other users acquire the authentication token to threaten the privacy of the private key of the target user is avoided; when the target user needs to host his private key, it may request to host his private key by sending a second private key hosting request.
Optionally, on the basis of the foregoing embodiment, an embodiment of the present application may further provide a key hosting method, and an implementation procedure of the method is described below by way of example with reference to the accompanying drawings. Fig. 3 is a flow chart of a key escrow method according to another embodiment of the present application, as shown in fig. 3, before S101, the method may further include:
s121: and acquiring at least two sub-keys, and splicing the at least two sub-keys to obtain the managed key.
In the embodiment of the application, the managed Key (Key) can be used for carrying out Key segmentation setting for a plurality of administrators under the Key managed device, and carrying out character string series connection on each segmented sub-Key according to the segmentation Key word order, so that the administrators respectively set and configure own sub-keys, and respectively make own backups, and the managed keys cannot be leaked, and if a part of the sub-keys are leaked, the managed keys cannot be influenced, namely the managed keys are controlled by multiple persons and cannot be cracked by a small number of persons, so that the safety and the reliability of the managed keys are ensured.
S122: and carrying out hash calculation on the managed secret key to obtain the authentication token.
The authentication token (token) is obtained by performing hash calculation on the escrow key, where the hash calculation may be, for example, obtaining the authentication token from the first 32 bits of the hash of the escrow key, where the number of administrators may be, for example, 3, 5 or any integer, and the application is not limited in any way, and the following embodiments take the number of administrators may be, for example, 3 as an example, and the logic code for specifically determining the authentication token may be, for example, as follows:
in the embodiment of the application, after the authentication token is obtained, the corresponding relation between the distributed identity account number of the target user and the managed key can be stored in a preset local disk so as to be inquired by the key managed device, and the encrypted storage and recovery of the private key can be performed by using the managed key (authentication token) after hash calculation as an encryption factor; wherein: the managed key only can be queried by the private key managed system, and meanwhile, the managed key can only be stored in the memory of the private key managed system, and any other system cannot query; all blockchain private keys are encrypted and recovered using the hashed escrow key (authentication token).
Optionally, on the basis of the foregoing embodiment, an embodiment of the present application may further provide a key hosting method, and an implementation procedure of the method is described below by way of example with reference to the accompanying drawings. Fig. 4 is a flow chart of a key escrow method according to another embodiment of the present application, as shown in fig. 4, where the method may further include:
s131: and acquiring an authentication token and a distributed identity account number of the target user based on a private key recovery request initiated by the target user.
The private key recovery is generally applied to a scenario that the target user forgets or loses the private key to cause that the DID account of the target user cannot be used, and the private key of the target user is obtained by initiating a private key recovery request.
In the embodiment of the application, after the target user initiates the private key recovery request, the authentication token corresponding to the target user is still acquired based on the identity issuer system, and the authentication token is returned to the user, so that the user sends the private key recovery request with the authentication token to the key escrow equipment.
After the private key recovery request sent by the user is obtained, the key escrow device also needs to verify the authentication token in the private key recovery request, determine whether the authentication token is within a preset effective time and still has the use times, and execute the subsequent flow steps after the authentication is passed, otherwise, return a private key recovery failure indication.
The steps of private key recovery and private key escrow are approximately the same, and if the operation type is private key escrow, a request initiated by a user must carry the private key; if the operation type is private key recovery, the private key does not need to be input in a request initiated by the user; further in private key recovery, the DID of the target user is also determined for the identity issuer system based on the user information of the target user.
S132: based on the distributed identity account number of the target user, the corresponding relation between the distributed identity account number of the target user and the encryption private key is obtained in a preset database.
S133: and decrypting the encrypted private key based on the authentication token to obtain the private key.
S134: and sending the private key to the terminal equipment of the target user.
The specific implementation steps of the target user to recover the DID account based on the private key are similar to the private key encryption steps provided in the above embodiment, and the disclosure of the present application is omitted here.
For ease of understanding the present application, the following description will explain the key escrow method provided in the present application in one complete embodiment:
a target user (an individual user or an enterprise user) initiates a second private key escrow request, invokes an identity issuer system, inputs user information (identity card, name, mobile phone and face) or enterprise information (unified social credit code, enterprise legal information, legal information and mobile phone information) and the like; 3. after the identity issuer system authenticates the user information or the enterprise information, ensuring that the key escrow is initiated by a target user or a target enterprise, and then calculating to obtain the DID; then the identity issuing system signs the DID by using the private key of the identity issuer to obtain a signature; the identity issuer system calls key escrow equipment to apply for escrow token; the key escrow device verifies the signature of the identity issuer to ensure that only the designated identity issuer can apply for Token; verifying the DID of the target user, and applying for the managed Token of the DID after the verification is passed; in the embodiment of the application, the key escrow equipment is endorsed by a notarization department and has a legal efficiency platform, so that the safety and the reliability of the key escrow equipment are ensured; the identity issuer system returns the hosted Token to the target user, which saves it by itself.
The target user initiates a first private key hosting request to the key hosting device, and the token, the did and the private key of the target user are sent to the key hosting device in an encrypted transmission mode so as to call the key hosting device to host the private key of the target user; the Key escrow equipment verifies the Token to ensure the validity of the Token (whether the Token has the use times and whether the Token is within the preset use time), if the Token passes the verification, the Key escrow equipment encrypts the private Key through the Key Key to obtain an encryption Key, establishes a corresponding relation between the Key and the encryption private Key, and stores the Key, the encryption Key and the corresponding relation between the Key and the encryption Key into a database, so that the escrow of the private Key of the target user is completed.
For ease of understanding the present application, the following description will explain the key recovery method provided in the present application in a complete embodiment:
if the target user or the target enterprise needs to initiate the private key recovery, similar operations are performed in the private key escrow: after user information of a target user or enterprise information of a target enterprise is input, token for recovering private keys to an identity issuer; the identity system verifies and returns a recovered Token; then, the target user inputs token information and did information of the target user, and invokes the key escrow equipment to restore the key of the target user; repeating the steps of signing the target user, verifying the DID of the target user and verifying the Token, and after all the verification steps are passed, determining an encryption Key corresponding to the DID of the target user in a database by the Key hosting equipment according to the DID of the target user, decrypting the encryption Key based on the Key to obtain a decrypted private Key, and returning the decrypted private Key to the target user.
For facilitating understanding of the present application, a complete flow chart is taken as an example to explain a key escrow method provided by the present application, fig. 5 is a flow chart of a key escrow method provided by another embodiment of the present application, as shown in fig. 5, a DID and a user private key that are uniquely corresponding to a user are stored on a decentralised application program of the user, when the user initiates a private key escrow and recovery application to an identity issuer system, the identity issuer system initiates an application to a private key escrow system on a public place escrow center to obtain an authentication token corresponding to the private key of the user, and verifies validity of the obtained authentication token, where the authentication token is set by a plurality of administrator segments on the public place, and when the authentication token is set, the authentication token is set by an authentication token service on the public place escrow center, and the authentication token management service can perform query service on the authentication token.
In the embodiment of the application, all operations for the DAPP are operations performed by the user on the DID blockchain.
By adopting the key escrow method provided by the application, the identity of the target user is verified through the user identity of the target user, the DID uniquely corresponding to the target user is determined, and the escrow of the private key is performed through the DID verification, namely the recovery is performed through the DID verification, so that the effect of escrow closed loop is achieved, in the processes of escrow of the private key and recovery of the private key, the security of the private key of each user can be ensured through the key escrow equipment, the key escrow equipment not only has a public certificate, but also belongs to the user, the data can be ensured not to be utilized by other institutions or other individuals, the authentication token is not easy to be revealed through multi-person segmentation setting during the secret key of the key escrow equipment, the account security and privacy of the target user are further ensured, and the target user can retrieve the private key based on the DID of the target user under the condition that the DID account key of the target user is lost in advance through the encryption storage mode of the private key in the key escrow equipment.
The key escrow device provided in the present application is explained below with reference to the accompanying drawings, and the key escrow device may perform any one of the key escrow methods shown in fig. 1 to 5, and the specific implementation and the beneficial effects thereof are referred to above and are not repeated below.
Fig. 6 is a schematic structural diagram of a key escrow device according to an embodiment of the present application, as shown in fig. 6, where the device includes: an acquisition module 201, an encryption module 202, and a storage module 203, wherein:
the obtaining module 201 is configured to obtain an authentication token, distributed identity account information and a private key of a target user based on a first private key escrow request initiated by the target user;
the encryption module 202 is configured to encrypt the private key based on the authentication token to obtain an encrypted private key;
and the storage module 203 is configured to establish a corresponding relationship between the encryption private key and the distributed identity account of the target user, and store the corresponding relationship in a preset database.
Optionally, on the basis of the foregoing embodiment, an embodiment of the present application may further provide a key hosting device, where an implementation procedure of the device shown in fig. 6 is described below by way of example with reference to the accompanying drawings. Fig. 7 is a schematic structural diagram of a key escrow device according to another embodiment of the present application, as shown in fig. 7, where the device further includes: an authentication module 204 and a transmission module 205, wherein:
the obtaining module 201 is specifically configured to obtain a second private key escrow request initiated by the target user based on the identity issuer system; wherein the second private key escrow request includes: user information, signature information and distributed identity account information of a target user, wherein the distributed identity account information is calculated by an identity issuer system based on the user information;
a verification module 204, configured to verify the second private key escrow request;
if the verification is passed, the sending module 205 is configured to send an authentication token of the target user to the target user based on the identity account.
Optionally, the verification module 204 is specifically configured to verify the signature information, and determine whether the blockchain address information in the signature information is consistent with the blockchain address information of the target user;
the determining module 202 is specifically configured to determine distributed identification information to be verified based on user information of a target user; determining whether the distributed identification information to be verified is consistent with the distributed identity account information; if the verification results are consistent, determining that the second private key escrow request passes verification;
if at least one inconsistency exists in the verification result, the sending module 205 is specifically configured to return a request failure instruction to the client of the target user.
Optionally, the verification module 204 is specifically configured to verify the validity of the authentication token; it is determined whether the authentication token is within a valid time and has a number of valid uses.
Optionally, the obtaining module 201 is specifically configured to obtain at least two subkeys, and splice at least two subkeys to obtain a managed key;
the determining module 202 is specifically configured to perform hash calculation on the escrow key to obtain an authentication token.
Optionally, the storage module 203 is specifically configured to store a correspondence between the distributed identity account number of the target user and the authentication token in a preset local disk.
Optionally, the obtaining module 201 is specifically configured to obtain, based on a private key recovery request initiated by the target user,
acquiring an authentication token and a distributed identity account number of a target user;
the determining module 202 is specifically configured to obtain, in a preset database, a correspondence between the distributed identity account number of the target user and the encrypted private key based on the distributed identity account number of the target user; decrypting the encrypted private key based on the authentication token to obtain the private key;
the sending module 205 is specifically configured to send the private key to the terminal device of the target user.
The foregoing apparatus is used for executing the method provided in the foregoing embodiment, and its implementation principle and technical effects are similar, and are not described herein again.
The above modules may be one or more integrated circuits configured to implement the above methods, for example: one or more application specific integrated circuits (Application Specific Integrated Circuit, abbreviated as ASICs), or one or more microprocessors, or one or more field programmable gate arrays (Field Programmable Gate Array, abbreviated as FPGAs), etc. For another example, when a module above is implemented in the form of a processing element scheduler code, the processing element may be a general-purpose processor, such as a central processing unit (Central Processing Unit, CPU) or other processor that may invoke the program code. For another example, the modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).
Fig. 8 is a schematic structural diagram of a key escrow device provided in an embodiment of the present application, where the key escrow device may be integrated in a terminal device or a chip of the terminal device.
As shown in fig. 8, the key escrow apparatus includes: a processor 501, a bus 502, and a storage medium 503.
The processor 501 is configured to store a program, and the processor 501 invokes the program stored in the storage medium 503 to execute the method embodiments corresponding to fig. 1 to 5. The specific implementation manner and the technical effect are similar, and are not repeated here.
Optionally, the present application also provides a program product, such as a storage medium, on which a computer program is stored, including a program which, when being executed by a processor, performs the corresponding embodiments of the above-mentioned method.
In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of elements is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the 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 exist alone physically, 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.
The integrated units implemented in the form of software functional units described above may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium, and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (english: processor) to perform part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: u disk, mobile hard disk, read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk or optical disk, etc.
Claims (10)
1. A key escrow method, applied to a key escrow device, the method comprising:
acquiring an authentication token, distributed identity account information and a private key of a target user based on a first private key hosting request initiated by the target user;
encrypting the private key based on the authentication token to obtain an encrypted private key;
and establishing a corresponding relation between the encryption private key and the distributed identity account number of the target user, and storing the corresponding relation in a preset database.
2. The method of claim 1, wherein prior to obtaining the authentication token, the distributed identification account information, and the private key for the target user based on the target user initiated first private key escrow request, the method further comprises:
acquiring a second private key escrow request initiated by the target user based on an identity issuer system; wherein the second private key escrow request includes: the user information, signature information and the distributed identity account information of the target user, wherein the distributed identity account information is calculated by the identity issuer system based on the user information;
verifying the second private key escrow request;
and if the authentication is passed, sending an authentication token of the target user to the target user based on the identity account number.
3. The method of claim 2, wherein validating the private key escrow request comprises:
verifying the signature information, and determining whether the blockchain address information in the signature information is consistent with the blockchain address information of the target user;
determining distributed identification information to be verified based on the user information of the target user;
determining whether the distributed identification information to be verified is consistent with the distributed identity account information;
if the verification results are consistent, determining that the second private key escrow request passes verification;
and if at least one inconsistency exists in the verification result, returning a request failure instruction to the client of the target user.
4. The method of claim 1, wherein the method further comprises, prior to encrypting the private key based on the authentication token:
verifying the validity of the authentication token; it is determined whether the authentication token is within a valid time and has a number of valid uses.
5. The method of claim 1, wherein prior to obtaining the authentication token, the distributed identification account information, and the private key for the target user based on the target user initiated first private key escrow request, the method further comprises:
acquiring at least two sub-keys, and splicing the at least two sub-keys to obtain a managed key;
and carrying out hash calculation on the managed secret key to obtain the authentication token.
6. The method of claim 5, wherein the method further comprises:
and storing the corresponding relation between the distributed identity account number of the target user and the authentication token in a preset local disk.
7. The method of claim 1, wherein the method further comprises:
acquiring the authentication token and the distributed identity account number of the target user based on a private key recovery request initiated by the target user;
based on the distributed identity account number of the target user, acquiring the corresponding relation between the distributed identity account number of the target user and the encryption private key in the preset database;
decrypting the encrypted private key based on the authentication token to obtain the private key;
and sending the private key to the terminal equipment of the target user.
8. A key escrow device, the device comprising: the device comprises an acquisition module, an encryption module and a storage module, wherein:
the acquisition module is used for acquiring an authentication token, distributed identity account information and a private key of a target user based on a first private key escrow request initiated by the target user;
the encryption module is used for encrypting the private key based on the authentication token to obtain an encrypted private key;
the storage module is used for establishing a corresponding relation between the encryption private key and the distributed identity account number of the target user and storing the corresponding relation to a preset database.
9. A key escrow device, the device comprising: a processor, a storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium in communication over a bus when the key escrow device is in operation, the processor executing the machine-readable instructions to perform the method of any of the preceding claims 1-7.
10. A storage medium having stored thereon a computer program which, when executed by a processor, performs the method of any of the preceding claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310355214.XA CN116388979A (en) | 2023-03-29 | 2023-03-29 | Key escrow method, device, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310355214.XA CN116388979A (en) | 2023-03-29 | 2023-03-29 | Key escrow method, device, equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116388979A true CN116388979A (en) | 2023-07-04 |
Family
ID=86980244
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310355214.XA Pending CN116388979A (en) | 2023-03-29 | 2023-03-29 | Key escrow method, device, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116388979A (en) |
-
2023
- 2023-03-29 CN CN202310355214.XA patent/CN116388979A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230231711A1 (en) | Blockchain-implemented method and system | |
| KR102392420B1 (en) | Program execution and data proof scheme using multi-key pair signatures | |
| CN108292402B (en) | Determination of a common secret and hierarchical deterministic keys for the secure exchange of information | |
| US11888974B1 (en) | Secret sharing information management and security system | |
| US8464058B1 (en) | Password-based cryptographic method and apparatus | |
| CN111066286A (en) | Retrieving common data for blockchain networks using high availability trusted execution environments | |
| CN113162768B (en) | Intelligent Internet of things equipment authentication method and system based on block chain | |
| CN110969431B (en) | Secure hosting method, device and system for private key of blockchain digital coin | |
| EP2595340A2 (en) | Cryptographic document processing in a network | |
| WO2014068427A1 (en) | Reissue of cryptographic credentials | |
| Khan et al. | A brief review on cloud computing authentication frameworks | |
| Mishra et al. | MPoWS: Merged proof of ownership and storage for block level deduplication in cloud storage | |
| Salvakkam et al. | Design of fully homomorphic multikey encryption scheme for secured cloud access and storage environment | |
| Dharminder et al. | Construction of lightweight authentication scheme for network applicants using smart cards | |
| Hölzl et al. | Bridging the gap in privacy-preserving revocation: practical and scalable revocation of mobile eIDs | |
| Prabakaran et al. | Secure channel for financial transactions in cloud environment using blockchain technology | |
| CN116388979A (en) | Key escrow method, device, equipment and storage medium | |
| Shehu et al. | SPIDVerify: A Secure and Privacy-Preserving Decentralised Identity Verification Framework | |
| Mir et al. | Recovery of encrypted mobile device backups from partially trusted cloud servers | |
| Goodrich et al. | Notarized federated ID management and authentication | |
| Sampath et al. | Decentralized Digital Identity Wallet using Principles of Self-Sovereign Identity Applied to Blockchain | |
| WO2023077280A1 (en) | Certificate-less authentication and secure communication | |
| Kravitz | Exploration and impact of blockchain-enabled adaptive non-binary trust models | |
| Danda et al. | SSH-DAuth: Secret Sharing based Decentralized OAuth using Decentralized Identifier | |
| Mohammed | AN ANALYSIS OF THE ROBUST KEY REVEAL MECHANISM USED IN THE PUBLIC AUDIT MODEL FOR SECURE CLOUD STORAGE. |
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 |