CN112633884A - Local private key recovery method and device for transaction main body identity certificate - Google Patents
Local private key recovery method and device for transaction main body identity certificate Download PDFInfo
- Publication number
- CN112633884A CN112633884A CN202011619732.0A CN202011619732A CN112633884A CN 112633884 A CN112633884 A CN 112633884A CN 202011619732 A CN202011619732 A CN 202011619732A CN 112633884 A CN112633884 A CN 112633884A
- Authority
- CN
- China
- Prior art keywords
- private key
- server
- local private
- client
- hash value
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The application provides a local private key recovery method and a local private key recovery device for a transaction main body identity certificate, wherein the method comprises the following steps: the client signs a recovery data packet comprising the identification number of the transaction main body identity certificate and an encrypted local private key and sends the signature to the server through the fair node server; when the local private key is recovered, the client sends a request account number and an identity certificate identification number provided by a transaction main body to the server through the notarization node server; the server acquires a corresponding recovery data packet through the identification number of the identity certificate, verifies the request account, generates a verification code corresponding to the request account and a first hash value of the verification code, and sends the verification code to the request account; the client acquires the verification code, generates a second hash value of the verification code and sends the second hash value to the server through the notarization node server; and the server compares the second hash value with the first hash value for verification, and sends the encrypted local private key to the client through the fair node server when the second hash value is consistent with the first hash value. The method enables the transaction body to conveniently and safely retrieve the local private key.
Description
Technical Field
The application relates to the technical field of network security and block chaining, in particular to a local private key recovery method and device for a transaction principal identity certificate, electronic equipment and a computer readable medium.
Background
The transaction body needs to sign or encrypt the bidding document through a digital mobile Certificate (CA) in the process of participating in the transaction. Currently, the way in which a transaction principal applies CA is: the CA lock, such as a USBKey, is checked out of the counter by a certified CA institution. And when the transaction subject needs to bid, the CA lock is inserted into a computer to perform operations such as signature and encryption on the bid document.
Different workers in the transaction body need to use the CA lock to carry out the time-stamping, and need to register at a CA lock manager. After registering, the CA lock can be picked up and used, and then the return is carried out after the use.
The CA certificate private key is stored in a cloud encryption machine in a server, and on one hand, a plurality of people share one CA certificate through an authorization mechanism without repeated handling, and on the other hand, the use safety of the CA certificate is guaranteed; in addition, the application, use and authorization information of the CA certificate is stored in the block chain, and the whole process traceability is realized.
Disclosure of Invention
The application aims to provide a local private key recovery method of a transaction principal identity certificate, so as to solve the problem that the local private key representing the identity of the transaction principal is lost or needs to be retrieved when client hardware is replaced in the use process of an online CA certificate.
According to a first aspect of the present application, a method for local private key recovery of a transaction principal identity certificate is provided. The method comprises the following steps:
the client signs a recovery data packet comprising the identification number of the transaction main body identity certificate and an encrypted local private key together and sends the signature to the server through the fair node server;
when the local private key is recovered, the client sends a request account number and an identity certificate identification number provided by a transaction main body to the server through the notarization node server;
the server side obtains a corresponding recovery data packet through the identification number of the identity certificate, verifies the request account, generates a verification code corresponding to the request account and a first hash value of the verification code, and sends the verification code to the request account;
the client acquires the verification code through the request account, generates a second hash value of the verification code and sends the second hash value to the server through the notarization node server;
and the server compares the second hash value with the first hash value for verification, and sends the encrypted local private key to the client through the fair node server when the comparison is consistent.
According to some embodiments of the application, the local private key recovery method further comprises:
the client generates a local public and private key representing the identity of the transaction main body for the transaction main body, and shares the local public key;
a cloud encryption machine in the server side generates a first public and private key for the transaction main body, and shares the first public key;
an encryption gateway in the server side generates a second public and private key for the transaction main body and shares the second public key;
and when the local private key is recovered, the client generates a temporary third public private key for the transaction main body according to the recovery request, and shares the third public key.
According to some embodiments of the application, the encrypted local private key comprises: and the client uses the first public key to encrypt the local private key to generate an encrypted local private key.
According to some embodiments of the present application, the verifying the request account by the server includes: and when the request account number provided by the transaction body exists in the recovery data packet, the verification is passed.
According to some embodiments of the present application, the server generates a verification code corresponding to the request account and a first hash value thereof, and sends the verification code to the request account, including:
after a cloud encryption machine in the server generates a verification code corresponding to the request account and a first hash value of the verification code, a second public key is used for integrally encrypting the request account and the verification code, and the encrypted verification code is sent to an encryption gateway in the server;
and the encryption gateway in the server side decrypts the integrally encrypted request account and verification code by using a second private key to obtain the request account and the verification code, and sends the verification code to the request account in a form of short message.
According to some embodiments of the present application, the server compares and verifies the second hash value and the first hash value, and sends the encrypted local private key to the client through the fair node server after the comparison is consistent, including:
the cloud encryption machine in the server compares and verifies the second hash value with the first hash value;
after the comparison is consistent, the server side decrypts the encrypted local private key by using the first private key to obtain the local private key;
and the server side encrypts the local private key by using the third public key and then sends the encrypted local private key to the client side through the fair node server.
According to some embodiments of the application, the local private key recovery method further comprises:
and the client side decrypts the encrypted local private key by using the third private key to obtain the local private key.
According to a second aspect of the present application, a method for local private key recovery of a transaction principal identity certificate is provided. The method comprises the following steps:
signing a recovery data packet comprising a transaction main body identity certificate identification number and an encrypted local private key together, and sending the signature to a server through a fair node server;
when the local private key is recovered, the request account number and the identity certificate identification number provided by the transaction main body are sent to the server side through the notarization node server;
receiving a verification code sent by the server through the request account, generating a second hash value of the verification code, and sending the second hash value to the server through the notarization node server;
and decrypting the encrypted local private key sent by the server to obtain the local private key.
According to some embodiments of the application, the encrypted local private key comprises:
and the first public key generated by the server is used for encrypting the local private key to generate an encrypted local private key.
According to a third aspect of the present application, a local private key recovery method of a transaction principal identity certificate is provided. The method comprises the following steps:
acquiring a corresponding recovery data packet through an identity certificate identification number provided by a client and verifying a request account number provided by the client;
after the verification is passed, generating a verification code corresponding to the request account and a first hash value of the verification code, and sending the verification code to the request account;
comparing and checking a second hash value returned by the client with the first hash value;
and when the comparison is consistent, sending the encrypted local private key to the client through the public node server.
According to some embodiments of the application, the local private key recovery method further comprises:
a cloud encryption machine in the server side generates a first public and private key for the transaction main body, and shares the first public key;
and an encryption gateway in the server generates a second public and private key for the transaction main body, and shares the second public key.
According to some embodiments of the application, the sending the encrypted local private key to the client through the fair node server when the comparison is consistent comprises:
and encrypting the local private key by using the third public key generated by the client and then sending the encrypted local private key to the client through the fair node server.
According to a fourth aspect of the present application, a method for local private key recovery of a transaction principal identity certificate is provided. The method comprises the following steps:
sending a recovery data packet including a transaction main body identity certificate identification number and an encrypted local private key sent by a client to a server;
when a local private key is recovered, sending a request account number and an identity certificate identification number sent by the client to the server;
sending the second hash value sent by the client to the server;
and sending the encrypted local private key sent by the server to the client.
The present application further provides a local private key recovery device for a transaction principal identity certificate, comprising:
the recovery data submission module can be used for the client to sign a recovery data packet comprising the identification number of the transaction main body identity certificate and the encrypted local private key and send the signature to the server through the fair node server;
the recovery request submitting module can be used for sending a request account number and an identity certificate identification number provided by a transaction main body to a server side through a notarization node server by the client side when a local private key is recovered;
the verification data sending module can be used for generating a verification code corresponding to the request account and a first hash value thereof and sending the verification code to the request account after the server obtains a corresponding recovery data packet through the identification number of the identity certificate and verifies the request account;
the verification data return module can be used for the client to acquire the verification code through the request account, generate a second hash value of the verification code and send the second hash value to the server through the notarization node server;
and the recovery request verification module can be used for comparing and verifying the second hash value and the first hash value by the server side, and sending the encrypted local private key to the client side through the just node server when the comparison is consistent.
The present application further provides another local private key recovery apparatus for a transaction principal identity certificate, including:
the recovery data submitting module can be used for signing a recovery data packet comprising the identification number of the transaction main body identity certificate and the encrypted local private key and sending the signature to the server through the fair node server;
the recovery request submitting module can be used for sending a request account number and an identity certificate identification number provided by a transaction main body to a server side through the notarization node server when a local private key is recovered;
the verification data return module can be used for receiving a verification code sent by the server through the request account, generating a second hash value of the verification code and sending the second hash value to the server through the notarization node server;
the local private key decryption module can be used for decrypting the encrypted local private key sent by the server side to obtain the local private key.
The present application further provides another local private key recovery apparatus for a transaction principal identity certificate, including:
the request account verification module can be used for obtaining a corresponding recovery data packet through the identification number of the identity certificate provided by the client and verifying the request account provided by the client;
the verification data sending module can be used for generating a verification code corresponding to the request account and a first hash value of the verification code after the verification is passed and sending the verification code to the request account;
the recovery request verification module may be configured to compare and verify a second hash value returned by the client with the first hash value;
and the local private key sending module can be used for sending the encrypted local private key to the client through the public node server when the comparison is consistent.
The present application further provides another local private key recovery apparatus for a transaction principal identity certificate, including:
the recovery data transmission module can be used for sending a recovery data packet which comprises a transaction main body identity certificate identification number and is sent by the client and the encrypted local private key to the server;
the request data transmission module can be used for sending a request account number and an identity certificate identification number sent by the client to the server when a local private key is recovered;
the verification data transmission module can be used for sending the second hash value sent by the client to the server;
the local private key transmission module may be configured to send the encrypted local private key sent by the server to the client.
The present application further provides an electronic device, comprising: one or more processors; storage means for storing one or more programs; when executed by the one or more processors, cause the one or more processors to implement the local private key recovery method described above.
The present application also provides a computer readable medium having stored thereon a computer program which, when executed by a processor, implements the local private key recovery method described above.
According to the local private key recovery method, the verification code is sent by the server side, and the data is transmitted by the third-party public node server, so that a transaction main body can conveniently and safely retrieve the local private key.
Additional aspects and advantages of the present application will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the present application.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is apparent that the drawings in the following description are only some embodiments of the present application.
FIG. 1A illustrates a first portion of a timing diagram for a digital mobile certificate application method according to an exemplary embodiment of the present application;
FIG. 1B illustrates a first portion of a timing diagram for a digital mobile certificate application method according to an example embodiment of the present application;
fig. 1C shows a digital mobile certificate application method application diagram according to an example embodiment of the present application;
fig. 2A shows a sequence diagram of a recovery process of a local private key of a transaction principal in the digital mobile certificate application method according to an example embodiment of the present application;
fig. 2B shows a timing chart of a recovery process of the local private key of the transaction principal in the digital mobile certificate application method according to the example embodiment of the present application;
fig. 3 shows a flow chart of a local private key recovery method according to a first example embodiment of the present application;
fig. 4 shows a flow chart of a local private key recovery method according to a second example embodiment of the present application;
fig. 5 shows a flow chart of a local private key recovery method according to a third example embodiment of the present application;
fig. 6 shows a flow chart of a local private key recovery method according to a fourth example embodiment of the present application;
fig. 7 shows a block diagram of a local private key recovery apparatus according to a first example embodiment of the present application;
fig. 8 shows a block diagram of a local private key recovery apparatus according to a second example embodiment of the present application;
fig. 9 shows a block diagram of a local private key recovery apparatus according to a third example embodiment of the present application;
fig. 10 shows a block diagram of a local private key recovery apparatus according to a fourth example embodiment of the present application;
FIG. 11 shows a block diagram of a local private key recovery electronic device, according to an example embodiment of the present application.
Detailed Description
Example embodiments will now be described more fully hereinafter with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. These embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The same reference numerals denote the same or similar parts in the drawings, and thus, a repetitive description thereof will be omitted.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.
It will be understood that, although the terms first, second, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one element from another. Thus, a first component discussed below may be termed a second component without departing from the teachings of the present concepts. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.
Those skilled in the art will appreciate that the drawings are merely schematic representations of exemplary embodiments, which may not be to scale. The blocks or flows in the drawings are not necessarily required to practice the present application and therefore should not be used to limit the scope of the present application.
The inventors have found that the use of offline CA locks presents the following problems for the transaction agent:
first, existing CA locks are hardware media and can only be used by one at a time. When the transaction body needs to use the CA lock by a plurality of persons at the same time, a plurality of CA locks need to be handled. For the subject with large traffic, transaction costs are increased.
Second, the CA mechanisms for different regional certifications differ. Therefore, when the transaction subject performs the bidding in different areas, the CA locks of different CA organizations need to be handled, and the transaction cost is further increased.
Moreover, the hardware medium type CA lock does not use a recording trace in the using process, and the safety is not ensured.
Therefore, the application aims to provide a local private key recovery method of a transaction principal identity certificate, and the private key of a CA certificate is stored in a cloud encryption machine in a server; on one hand, a plurality of persons share one CA certificate through an authorization mechanism without repeated handling, and on the other hand, the use safety of the CA certificate is guaranteed; in addition, the application, use and authorization information of the CA certificate is stored in the block chain, and the whole process traceability is realized.
The technical solution of the present application will be described in detail below with reference to the accompanying drawings.
Fig. 1A illustrates a first portion of a timing diagram of a digital mobile certificate application method according to an example embodiment of the present application.
Fig. 1B illustrates a first portion of a timing diagram for a digital mobile certificate application method according to an example embodiment of the present application.
Fig. 1C shows an application diagram of a digital mobile certificate application method according to an example embodiment of the present application.
As shown in fig. 1A, 1B, and 1C, the general flow of the digital mobile certificate application method provided by the present application includes:
the client 110 generates a pair of local public and private keys for each transaction principal. For example, after the transaction subjects are successfully registered through the client APP in the client 110, a software development tool (SDK) embedded in the client 110 generates a pair of local public and private keys for each transaction subject, which are used as identity certificates representing each transaction subject, and the generated identity certificates are backed up to the server 130.
When a transaction principal applies for a CA certificate, a client 110 signs application information of the transaction principal using a local public and private key and then sends the signed application information to a server 130 through a notarization node server 120. For example, when the transaction principal applies for a CA certificate through a client APP in the client 110, the application information is signed by a local public and private key, and then sent to the notarization node server 120 through the client service device of the client 110, and then sent to the server 130 by the notarization node server 120.
The server 130 generates a certificate request file according to the signed application information, and signs the certificate request file by using a first public and private key generated for a transaction principal to generate a signed certificate request file including a first public key. For example, the cloud encryption engine in the server 130 generates a pair of first public and private keys as signature public and private keys of the transaction subject for each transaction subject initialization. After the server 130 generates the certificate request file, the server uses the first public key to generate a signature certificate request file containing the first public key, and obtains the identification number of the first public and private keys.
Next, the server 130 sends the signed certificate request file and the identification number of the first public and private keys to the client 110 through the public node server 120.
After receiving the signature certificate request file and the identification number of the first public and private keys, the client 110 sends the signature certificate request file to the digital mobile certificate authority 100, and applies for issuing a certificate to the CA authority.
The digital mobile certificate authority 100 verifies the signature certificate request file and then generates a second public and private key, encrypts the second private key by using the first public key in the signature certificate request file, and sends the encrypted second private key to the client. The second public and private keys are encrypted certificates issued by the CA organization to the transaction main body.
The client 110 sends the certificate information issued by the CA, such as the encrypted second private key and the identification number of the first public private key, to the server 130 through the fair node server 120. The fair node server 130 further stores the digital mobile certificate application information of the transaction subject to the blockchain 140 through the chain service device for uplink certificate storage.
The server 130 obtains the corresponding first private key from the private key database of the server 130 according to the identification number of the first public private key to decrypt the encrypted second private key to obtain the second private key, and stores the second private key, for example, in the private key database of the server 130. The server 130 may also share the second public key. Thus, the application of the CA certificate is completed. According to some embodiments of the present application, in order to further ensure the security of the second private key, the second private key obtained after decryption may be encrypted by using a local public key of the cloud encryption machine and then stored in the private key database.
In order to ensure the security of the CA certificate in the use process, the digital mobile certificate application method provided by the present application further includes performing authorization management on the CA certificate, as follows:
when the transaction principal applies for authorization of the digital mobile certificate, the client 110 signs the authorization request information with a local private key according to the authorization request information of the transaction principal, and then sends the signed authorization request information to the server 130 through the notarization node server 120. For example, the transaction body may apply for authorization through a client APP in the client 110. The notary node server 120 may also store the authorization request message to the blockchain 140 via a chain serving device for uplink credentialing.
The server 130 verifies the signed authorization request information by using the backed-up local public key and then passes authorization. For example, the server 130 sends the authorization request information to a cloud encryption machine in the server 130. And the cloud encryption machine verifies the signature information. And after passing the verification, authorizing according to the authorization request information, and returning authorization success. Thus, the authorization of the CA certificate is completed.
When the transaction principal uses the digital mobile certificate, for example, to encrypt or decrypt, after the client 110 signs the usage request information of the transaction principal using the local private key, the signed usage request information and the identification number of the second public private key requested to be used are sent to the server 130 through the notarization node server 120. For example, the transaction body may use a CA certificate through a client APP in the client 110, for example. The notary node server 120 may also store the usage request message to the blockchain 140 via a chain service device for uplink credentialing.
The server 130 verifies the signed use request information by using the backed-up local public key, and then obtains an encrypted second private key corresponding to the identification number of the second public private key requested to be used. For example, the corresponding encrypted second private key is obtained from the private key database according to the identification number of the second public private key requested to be used. According to some embodiments of the application, the encrypted second private key stored in the private key database is encrypted by a local public key of the cloud encryption engine. Thus, decryption may be performed using the local private key of the cloud encryptor.
The server 130 decrypts the encrypted second private key and then operates according to the use request information. For example, the cloud encryption machine in the server 130 decrypts the second private key and then performs an encryption or decryption operation according to the use request information. After the operation is successful, the server 130 may also operate to return success.
Fig. 2A shows a first time sequence diagram of a recovery process of a local private key in a digital mobile certificate application method according to an example embodiment of the present application.
Fig. 2B shows a timing chart of a recovery process of the local private key in the digital mobile certificate application method according to the example embodiment of the present application.
In the application method of the digital mobile certificate, the client generates a local public and private key for a transaction subject to serve as an identity certificate of the transaction subject. The local public and private keys are frequently used in the transaction process. When the transaction body changes the client hardware, for example, after a mobile phone is changed, the local private key needs to be recovered on the new client hardware, that is, the local private key is retrieved. In order to facilitate the recovery of the local private key by the transaction subject when the client hardware is replaced, the application also provides a local private key recovery method for the transaction subject identity certificate. The overall process of local private key recovery will be described below with reference to fig. 2A and 2B.
As shown in fig. 2A and 2B, when a transaction principal applies for a digital mobile certificate through the client 110, a pair of local public and private keys is generated for each transaction principal. For example, after the transaction subjects are successfully registered through the client APP in the client 110, a software development tool (SDK) embedded in the client 110 generates a pair of local public and private keys for each transaction subject, which are used as identity certificates representing each transaction subject, and the generated identity certificates are backed up to the server 130. The cloud encryption machine in the server 130 generates a first public and private key for the transaction subject, and shares the first public key. The encryption gateway in the server 130 generates a second public and private key for the transaction principal and shares the second public key.
The client 110 signs the account number list provided by the transaction subject for recovering the local private key with the local private key to generate a recovery data packet containing the identification number of the identity certificate. The account number list may be a list of backup mobile phone numbers provided by the transaction subject.
The client 110 uses the local private key to sign the recovery packet and the encrypted local private key together and sends the signature to the server 130 through the fair node server 120 for storage. For example, the client 110 may encrypt the local private key using a first public key generated by a cloud encryptor, generating an encrypted local private key.
When the local private key is recovered, the client 110 sends the request account number provided by the transaction subject and the identification number of the identity certificate requested to be recovered to the server 130 through the notarization node server 120. The client 110 may also generate a temporary third public and private key for the transaction principal according to the recovery request, and share the third public and private key.
The server 130 obtains a corresponding recovery data packet through the identification number of the identity certificate, verifies the request account, generates a verification code corresponding to the request account and a first hash value of the verification code, and sends the verification code to the request account in a form of a short message. The server 130 first finds a corresponding recovery data packet according to the identification number of the identity certificate requested to be recovered. And when the request account number provided by the transaction main body exists in the account number list of the recovery data packet, the verification is passed. After the verification, the encryption machine generates a verification code corresponding to the request account and a first hash value thereof, and then integrally encrypts the request account and the verification code by using a second public key and sends the encrypted verification code to an encryption gateway in the server 130. The encryption gateway decrypts the integrally encrypted request account and verification code by using a second private key to obtain the request account and the verification code, and sends the verification code to the request account in a form of short message.
The client 110 obtains the verification code through the request account, generates a second hash value of the verification code, and sends the second hash value to the server 130 through the notarization node server 120.
The server 130 compares the second hash value with the first hash value, and sends the encrypted local private key to the client 130 through the fair node server 120 after the comparison is consistent. For example, after receiving the second hash value, the server 130 sends the second hash value to the cloud encryption machine. And the cloud encryption machine compares and verifies the second hash value with the first hash value. After the comparison is consistent, the cloud encryption machine in the server 130 decrypts the encrypted local private key by using the first private key to obtain the local private key, and then encrypts the local private key by using the third public key and sends the encrypted local private key to the client 130 through the fair node server 120.
The client 110 decrypts the encrypted local private key using the third private key to obtain the local private key. At this point, the recovery of the local private key is completed.
Fig. 3 shows a flow chart of a local private key recovery method according to a first example embodiment of the present application.
As shown in fig. 3, according to a first exemplary embodiment of the present application, a local private key recovery method provided by the present application includes the following steps:
in step S110, the client signs the recovery packet including the transaction principal identity certificate identification number and the encrypted local private key together and sends the signature to the server through the fair node server.
When the transaction main bodies apply for the digital mobile certificate through the client, a pair of local public and private keys representing the identities of the transaction main bodies is generated for each transaction main body, and the local public keys are shared. The cloud encryption machine in the server side generates a first public and private key for the transaction main body, shares the first public key and uses the first public key as a signature certificate of the transaction main body. The encryption gateway in the server 130 generates a second public and private key for the transaction principal, and shares the second public key for verification of the recovery request of the transaction principal.
In order to perform identity authentication subsequently when the local private key needs to be restored, the client first submits the restoration data packet to the server for storage. For example, a client signs a list of account numbers provided by a transaction subject for recovering a local private key with the local private key to generate a recovery data packet containing an identification number of an identity certificate. The account number list may be a list of backup mobile phone numbers provided by the transaction subject. And the client signs the recovery data packet and the encrypted local private key together by using the local private key, and correspondingly binds each recovery data packet and the encrypted local private key with each transaction main body. The client can encrypt the local private key using the first public key to generate an encrypted local private key.
In step S120, when the local private key is recovered, the client sends the request account and the identification number of the identity certificate provided by the transaction principal to the server through the notarization node server. According to some embodiments of the application, when the local private key is recovered, the client side further generates a temporary third public private key for the transaction main body according to the recovery request, and shares the third public key for encrypted transmission of the recovered local private key in the transmission process.
In step S130, after obtaining the corresponding recovery data packet through the identification number of the identity certificate and checking the request account, the server generates a verification code corresponding to the request account and a first hash value thereof, and sends the verification code to the request account. For example, the server-side id certificate id number finds the corresponding reply packet. And when the request account number provided by the transaction body exists in the recovery data packet, the verification is passed. The request account number may be any one of the backup mobile phone numbers in the list of backup mobile phone numbers provided by the transaction subject in the recovery data packet.
According to some embodiments of the present application, a process of generating a verification code corresponding to the request account and a first hash value thereof and sending the verification code to the request account may be: and after a cloud encryption machine in the server generates a verification code corresponding to the request account and a first hash value thereof, integrally encrypting the request account and the verification code by using a second public key and transmitting the encrypted verification code to an encryption gateway in the server. The encryption gateway decrypts the integrally encrypted request account and verification code by using a second private key to obtain the request account and the verification code, and calls a short message service to send the verification code to the request account in a form of a short message.
In step S140, the client obtains the verification code through the request account, generates a second hash value, and sends the second hash value to the server through the notarization node server. For example, the transaction body enters the received authentication code into the client APP.
In step S150, the server compares the second hash value with the first hash value, and sends the encrypted local private key to the client through the fair node server when the comparison is consistent. The process of the comparison check may be: the cloud encryption machine in the server compares and verifies the second hash value with the first hash value; after the comparison is consistent, the server decrypts the encrypted local private key by using the first private key to obtain the local private key; and the server side encrypts the local private key by using the third public key and then sends the encrypted local private key to the client side through the fair node server. And after receiving the encrypted local private key, the client decrypts the encrypted local private key by using the third private key to obtain the local private key. At this point, the recovery of the local private key is completed.
Fig. 4 shows a flow chart of a local private key recovery method according to a second example embodiment of the present application.
As shown in fig. 4, according to a second exemplary embodiment of the present application, a local private key recovery method provided by the present application includes the following steps:
in step S210, the recovery data packet including the identification number of the transaction principal identity certificate and the encrypted local private key are signed together and sent to the server through the fair node server. According to some embodiments of the present application, when a transaction principal applies for a digital mobile certificate through a client, a pair of local public and private keys representing the identity of the transaction principal is generated for each transaction principal, and the local public and private keys are shared. In order to recover the local private key, the transaction body can back up the recovery data packet requesting recovery and the encrypted local private key at the server side. According to some embodiments of the application, the local private key can be encrypted by using the first public key generated by the server side to generate the encrypted local private key, so that the security is guaranteed.
In step S220, when the local private key is recovered, the request account number and the identification number of the identity certificate provided by the transaction principal are sent to the server through the notarization node server. According to some embodiments of the application, when the local private key is recovered, a temporary third public private key may be generated for the transaction subject according to the recovery request, and the third public key may be shared for encrypting and transmitting the retrieved local private key.
In step S230, receiving the verification code sent by the server through the request account, generating a second hash value of the verification code, and sending the second hash value to the server through the notarization node server;
in step S240, the encrypted local private key sent by the server is decrypted to obtain the local private key. For example, the local private key may be decrypted using the third private key.
Fig. 5 shows a flow chart of a local private key recovery method according to a third example embodiment of the present application.
As shown in fig. 5, according to a third exemplary embodiment of the present application, a local private key recovery method provided by the present application includes the following steps:
in step S310, a corresponding recovery data packet is obtained through the identification number of the identity certificate provided by the client, and the request account provided by the client is verified. For example, when the request account provided by the client exists in the recovery data packet, the check may be passed.
In step S320, after the verification is passed, a verification code corresponding to the request account and a first hash value thereof are generated and sent to the request account.
In step S330, a comparison check is performed between the second hash value returned by the client and the first hash value.
And in step S340, when the comparison is consistent, the encrypted local private key is sent to the client through the public node server. For example, the local private key is encrypted using the third public key generated by the client.
According to some embodiments of the present application, the local private key recovery method may further include: and a cloud encryption machine in the server side generates a first public and private key for the transaction main body, and shares the first public key for signature. And the encryption gateway in the server generates a second public and private key for the transaction main body, shares the second public key and is used for verifying the recovery request of the transaction main body.
Fig. 6 shows a flow chart of a local private key recovery method according to a fourth example embodiment of the present application.
As shown in fig. 6, according to a fourth exemplary embodiment of the present application, a local private key recovery method provided by the present application includes the following steps:
in step S410, the recovery data packet including the identification number of the transaction principal identity certificate and the encrypted local private key sent by the client are sent to the server.
In step S420, when the local private key is recovered, the request account and the identification number of the identity certificate sent by the client are sent to the server.
In step S430, the second hash value sent by the client is sent to the server.
In step S440, the encrypted local private key sent by the server is sent to the client.
Fig. 7 shows a block diagram of a local private key recovery apparatus according to a first exemplary embodiment of the present application.
According to the first exemplary embodiment of the present application, a local private key recovery apparatus 100 for a transaction principal identity certificate is provided, which includes a recovery data submitting module 110, a recovery request submitting module 120, an authentication data sending module 130, an authentication data returning module 140, and a recovery request authenticating module 150.
The recovery data submitting module 110 may be configured to sign the recovery data packet including the identification number of the transaction principal identity certificate and the encrypted local private key at the same time by the client, and send the signature to the server through the fair node server.
The recovery request submitting module 120 may be configured to, when recovering the local private key, send, by the client, the request account number and the identity certificate identification number provided by the transaction principal to the server through the notarization node server.
The verification data sending module 130 may be configured to, after the server obtains the corresponding recovery data packet through the identification number of the identity certificate and verifies the request account, generate a verification code corresponding to the request account and a first hash value thereof, and send the verification code to the request account.
The verification data returning module 140 may be configured to, by the client, obtain the verification code through the request account, generate a second hash value of the verification code, and send the second hash value to the server through the notarization node server.
The recovery request verification module 150 may be configured to compare and verify the second hash value and the first hash value by the server, and send the encrypted local private key to the client through the fair node server when the comparison is consistent.
Fig. 8 shows a block diagram of a local private key recovery apparatus according to a second example embodiment of the present application.
According to the second exemplary embodiment of the present application, a local private key recovery apparatus 200 for a transaction principal identity certificate is provided, which includes a recovery data submission module 210, a recovery request submission module 220, an authentication data return module 230, and a local private key decryption module 240.
The recovery data submitting module 210 may be configured to sign a recovery data packet including the identification number of the transaction principal identity certificate and the encrypted local private key together, and send the signature to the server through the fair node server;
the recovery request submitting module 220 may be configured to send a request account number and an identity certificate identification number provided by the transaction principal to the server through the notarization node server when recovering the local private key;
the verification data returning module 230 may be configured to receive a verification code sent by the server through the request account, generate a second hash value of the verification code, and send the second hash value to the server through the notarization node server;
the local private key decryption module 240 may be configured to decrypt the encrypted local private key sent by the server to obtain the local private key.
Fig. 9 shows a block diagram of a local private key recovery apparatus according to a third exemplary embodiment of the present application.
According to the third exemplary embodiment of the present application, a local private key recovery apparatus 300 for a transaction principal identity certificate is provided, which includes a request account number verification module 310, a verification data transmission module 320, a recovery request verification module 330, and a local private key transmission module 340.
The request account verification module 310 may be configured to obtain a corresponding recovery data packet through an identity certificate identification number provided by the client and verify a request account provided by the client;
the verification data sending module 320 may be configured to generate a verification code corresponding to the request account and a first hash value thereof after the verification passes, and send the verification code to the request account;
the recovery request verification module 330 may be configured to compare and verify a second hash value returned by the client with the first hash value;
the local private key sending module 340 may be configured to send the encrypted local private key to the client through the public node server when the comparison is consistent.
Fig. 10 is a block diagram showing a local private key recovery apparatus according to a fourth exemplary embodiment of the present application.
According to the fourth exemplary embodiment of the present application, a local private key recovery apparatus 400 for a transaction principal identity certificate is provided, which includes a recovery data transmission module 410, a request data transmission module 420, a verification data transmission module 430, and a local private key transmission module 440.
The recovery data transmission module 410 may be configured to send a recovery data packet including a transaction principal identity certificate identification number and an encrypted local private key, which are sent by a client, to a server;
the request data transmission module 420 may be configured to send a request account and an identity certificate identification number sent by the client to the server when recovering a local private key;
the verification data transmission module 430 may be configured to send the second hash value sent by the client to the server;
the local private key transmission module 440 may be configured to send the encrypted local private key sent by the server to the client.
Fig. 11 is a block diagram illustrating a local private key recovery electronic device for a transaction principal identity certificate according to an example embodiment of the present application.
The present application further provides a local private key recovery electronic device 700 for a transaction principal identity certificate. The electronic device 700 shown in fig. 11 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 11, electronic device 700 is embodied in the form of a general purpose computing device. The components of the electronic device 700 may include, but are not limited to: at least one processing unit 710, at least one memory unit 720, a bus 730 that couples various system components including the memory unit 720 and the processing unit 710, and the like.
The storage unit 720 stores program codes, which can be executed by the processing unit 710, so that the processing unit 710 executes the local private key recovery method according to the embodiments of the present application described in this specification.
The storage unit 720 may include readable media in the form of volatile memory units, such as a random access memory unit (RAM)7201 and/or a cache memory unit 7202, and may further include a read only memory unit (ROM) 7203.
The storage unit 720 may also include a program/utility 7204 having a set (at least one) of program modules 7205, such program modules 7205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
The electronic device 700 may also communicate with one or more external devices 7001 (e.g., touch screen, keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 700, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 700 to communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 750. Also, the electronic device 700 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network such as the internet) via the network adapter 760. The network adapter 760 may communicate with other modules of the electronic device 700 via the bus 730. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the electronic device 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
The present application also provides a computer readable medium, on which a computer program is stored, which when executed by a processor implements the above-described local private key recovery method.
According to the local private key recovery method, the server side sends the verification code to verify, and the third-party public node server transmits data, so that a transaction main body can conveniently and safely retrieve the local private key in the process of using the online CA certificate.
It should be understood that the above examples are only for clearly illustrating the present application and are not intended to limit the embodiments. Other variations and modifications will be apparent to persons skilled in the art in light of the above description. And are neither required nor exhaustive of all embodiments. And obvious variations or modifications of this invention may be made without departing from the spirit or scope of the invention.
Claims (20)
1. A local private key recovery method of a transaction principal identity certificate is characterized by comprising the following steps:
the client signs a recovery data packet comprising the identification number of the transaction main body identity certificate and an encrypted local private key together and sends the signature to the server through the fair node server;
when the local private key is recovered, the client sends a request account number and an identity certificate identification number provided by a transaction main body to the server through the notarization node server;
the server side obtains a corresponding recovery data packet through the identification number of the identity certificate, verifies the request account, generates a verification code corresponding to the request account and a first hash value of the verification code, and sends the verification code to the request account;
the client acquires the verification code through the request account, generates a second hash value of the verification code and sends the second hash value to the server through the notarization node server;
and the server compares the second hash value with the first hash value for verification, and sends the encrypted local private key to the client through the fair node server when the comparison is consistent.
2. The local private key recovery method of claim 1, further comprising:
the client generates a local public and private key representing the identity of the transaction main body for the transaction main body, and shares the local public key;
a cloud encryption machine in the server side generates a first public and private key for the transaction main body, and shares the first public key;
an encryption gateway in the server side generates a second public and private key for the transaction main body and shares the second public key;
and when the local private key is recovered, the client generates a temporary third public private key for the transaction main body according to the recovery request, and shares the third public key.
3. The local private key recovery method of claim 2, wherein the encrypted local private key comprises:
and the client uses the first public key to encrypt the local private key to generate an encrypted local private key.
4. The local private key recovery method of claim 1, wherein the verifying the request account by the server side comprises:
and when the request account number provided by the transaction body exists in the recovery data packet, the verification is passed.
5. The local private key recovery method of claim 2, wherein the step of generating, by the server, a verification code corresponding to the request account and a first hash value thereof and sending the verification code to the request account includes:
after a cloud encryption machine in the server generates a verification code corresponding to the request account and a first hash value of the verification code, a second public key is used for integrally encrypting the request account and the verification code, and the encrypted verification code is sent to an encryption gateway in the server;
and the encryption gateway in the server side decrypts the integrally encrypted request account and verification code by using a second private key to obtain the request account and the verification code, and sends the verification code to the request account in a form of short message.
6. The local private key recovery method of claim 3, wherein the server compares the second hash value with the first hash value for verification, and sends the encrypted local private key to the client through the public node server after the comparison is consistent, and the method comprises the following steps:
the cloud encryption machine in the server compares and verifies the second hash value with the first hash value;
after the comparison is consistent, the server side decrypts the encrypted local private key by using the first private key to obtain the local private key;
and the server side encrypts the local private key by using the third public key and then sends the encrypted local private key to the client side through the fair node server.
7. The local private key recovery method of claim 6, further comprising:
and the client side decrypts the encrypted local private key by using the third private key to obtain the local private key.
8. A local private key recovery method of a transaction principal identity certificate is characterized by comprising the following steps:
signing a recovery data packet comprising a transaction main body identity certificate identification number and an encrypted local private key together, and sending the signature to a server through a fair node server;
when the local private key is recovered, the request account number and the identity certificate identification number provided by the transaction main body are sent to the server side through the notarization node server;
receiving a verification code sent by the server through the request account, generating a second hash value of the verification code, and sending the second hash value to the server through the notarization node server;
and decrypting the encrypted local private key sent by the server to obtain the local private key.
9. The local private key recovery method of claim 8, further comprising:
generating a local public and private key representing the identity of a transaction principal for the transaction principal, and sharing the local public key;
and when the local private key is recovered, generating a temporary third public private key for the transaction main body according to the recovery request, and sharing the third public key.
10. The local private key recovery method of claim 8, wherein the encrypted local private key comprises:
and the first public key generated by the server is used for encrypting the local private key to generate an encrypted local private key.
11. A local private key recovery method of a transaction principal identity certificate is characterized by comprising the following steps:
acquiring a corresponding recovery data packet through an identity certificate identification number provided by a client and verifying a request account number provided by the client;
after the verification is passed, generating a verification code corresponding to the request account and a first hash value of the verification code, and sending the verification code to the request account;
comparing and checking a second hash value returned by the client with the first hash value;
and when the comparison is consistent, sending the encrypted local private key to the client through the public node server.
12. The local private key recovery method of claim 11, further comprising:
a cloud encryption machine in the server side generates a first public and private key for the transaction main body, and shares the first public key;
and an encryption gateway in the server generates a second public and private key for the transaction main body, and shares the second public key.
13. The local private key recovery method of claim 12, wherein sending the encrypted local private key to the client through the fair node server when the comparison is consistent comprises:
and encrypting the local private key by using the third public key generated by the client and then sending the encrypted local private key to the client through the fair node server.
14. A local private key recovery method of a transaction principal identity certificate is characterized by comprising the following steps:
sending a recovery data packet including a transaction main body identity certificate identification number and an encrypted local private key sent by a client to a server;
when a local private key is recovered, sending a request account number and an identity certificate identification number sent by the client to the server;
sending the second hash value sent by the client to the server;
and sending the encrypted local private key sent by the server to the client.
15. A local private key recovery apparatus for a transaction principal identity certificate, comprising:
the recovery data submission module is used for the client to sign a recovery data packet including the identification number of the transaction main body identity certificate and the encrypted local private key and send the signature to the server through the fair node server;
the recovery request submitting module is used for sending a request account number and an identity certificate identification number provided by a transaction main body to a server side through a notarization node server by the client side when a local private key is recovered;
the verification data sending module is used for generating a verification code corresponding to the request account and a first hash value thereof and sending the verification code to the request account after the server obtains a corresponding recovery data packet through the identification number of the identity certificate and verifies the request account;
the verification data return module is used for the client to acquire the verification code through the request account, generate a second hash value of the verification code and send the second hash value to the server through the notarization node server;
and the recovery request verification module is used for comparing and verifying the second hash value and the first hash value by the server side, and sending the encrypted local private key to the client side through the just node server when the comparison is consistent.
16. A local private key recovery apparatus for a transaction principal identity certificate, comprising:
the recovery data submitting module is used for signing a recovery data packet comprising the identification number of the transaction main body identity certificate and the encrypted local private key and sending the signature to the server through the fair node server;
the recovery request submitting module is used for sending a request account number and an identity certificate identification number provided by a transaction main body to a server side through a notarization node server when a local private key is recovered;
the verification data return module is used for receiving a verification code sent by the server through the request account, generating a second hash value of the verification code and sending the second hash value to the server through the notarization node server;
and the local private key decryption module is used for decrypting the encrypted local private key sent by the server side to obtain the local private key.
17. A local private key recovery apparatus for a transaction principal identity certificate, comprising:
the request account verification module is used for obtaining a corresponding recovery data packet through the identification number of the identity certificate provided by the client and verifying the request account provided by the client;
the verification data sending module is used for generating a verification code corresponding to the request account and a first hash value of the verification code after the verification is passed and sending the verification code to the request account;
the recovery request verification module is used for comparing and verifying a second hash value returned by the client with the first hash value;
and the local private key sending module is used for sending the encrypted local private key to the client through the public node server when the comparison is consistent.
18. A local private key recovery apparatus for a transaction principal identity certificate, comprising:
the recovery data transmission module is used for transmitting a recovery data packet which comprises a transaction main body identity certificate identification number and is transmitted by the client and the encrypted local private key to the server;
the request data transmission module is used for transmitting the request account number and the identity certificate identification number which are transmitted by the client to the server when a local private key is recovered;
the verification data transmission module is used for sending the second hash value sent by the client to the server;
and the local private key transmission module is used for sending the encrypted local private key sent by the server to the client.
19. An electronic device, comprising:
one or more processors;
storage means for storing one or more programs;
when executed by the one or more processors, cause the one or more processors to implement the local private key recovery method of any one of claims 1-14.
20. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the local private key recovery method of any one of claims 1 to 14.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011619732.0A CN112633884B (en) | 2020-12-30 | 2020-12-30 | Local private key recovery method and device for transaction main body identity certificate |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011619732.0A CN112633884B (en) | 2020-12-30 | 2020-12-30 | Local private key recovery method and device for transaction main body identity certificate |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112633884A true CN112633884A (en) | 2021-04-09 |
| CN112633884B CN112633884B (en) | 2022-11-18 |
Family
ID=75287307
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011619732.0A Active CN112633884B (en) | 2020-12-30 | 2020-12-30 | Local private key recovery method and device for transaction main body identity certificate |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112633884B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113393239A (en) * | 2021-06-16 | 2021-09-14 | 中国工商银行股份有限公司 | Transaction processing method, system, device, electronic equipment and storage medium |
| CN114221764A (en) * | 2021-12-17 | 2022-03-22 | 建信金融科技有限责任公司 | Public key updating method, device and equipment based on block chain |
| CN117272406A (en) * | 2023-11-23 | 2023-12-22 | 国泰新点软件股份有限公司 | Method, device, system and storage medium for verifying encrypted bidding document |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101567780A (en) * | 2009-03-20 | 2009-10-28 | 武汉理工大学 | Key management and recovery method for encrypted digital certificate |
| US20170048209A1 (en) * | 2015-07-14 | 2017-02-16 | Fmr Llc | Crypto Key Recovery and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems |
| CN109962784A (en) * | 2019-03-22 | 2019-07-02 | 西安电子科技大学 | A kind of data encrypting and deciphering and restoration methods based on the more certificates of digital envelope |
| CN110690957A (en) * | 2019-10-18 | 2020-01-14 | 如般量子科技有限公司 | Anti-quantum-computation private key backup, loss reporting and recovery method and system based on alliance chain and implicit certificate |
-
2020
- 2020-12-30 CN CN202011619732.0A patent/CN112633884B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101567780A (en) * | 2009-03-20 | 2009-10-28 | 武汉理工大学 | Key management and recovery method for encrypted digital certificate |
| US20170048209A1 (en) * | 2015-07-14 | 2017-02-16 | Fmr Llc | Crypto Key Recovery and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems |
| CN109962784A (en) * | 2019-03-22 | 2019-07-02 | 西安电子科技大学 | A kind of data encrypting and deciphering and restoration methods based on the more certificates of digital envelope |
| CN110690957A (en) * | 2019-10-18 | 2020-01-14 | 如般量子科技有限公司 | Anti-quantum-computation private key backup, loss reporting and recovery method and system based on alliance chain and implicit certificate |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113393239A (en) * | 2021-06-16 | 2021-09-14 | 中国工商银行股份有限公司 | Transaction processing method, system, device, electronic equipment and storage medium |
| CN114221764A (en) * | 2021-12-17 | 2022-03-22 | 建信金融科技有限责任公司 | Public key updating method, device and equipment based on block chain |
| CN117272406A (en) * | 2023-11-23 | 2023-12-22 | 国泰新点软件股份有限公司 | Method, device, system and storage medium for verifying encrypted bidding document |
| CN117272406B (en) * | 2023-11-23 | 2024-03-12 | 国泰新点软件股份有限公司 | Method, device, system and storage medium for verifying encrypted bidding document |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112633884B (en) | 2022-11-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112700245B (en) | Digital mobile certificate application method and device based on block chain | |
| CN112633884B (en) | Local private key recovery method and device for transaction main body identity certificate | |
| US7028180B1 (en) | System and method for usage of a role certificate in encryption and as a seal, digital stamp, and signature | |
| CN110311787B (en) | Authorization management method, system, device and computer readable storage medium | |
| CN106936588B (en) | Hosting method, device and system of hardware control lock | |
| CN107920052B (en) | Encryption method and intelligent device | |
| CN112565265B (en) | Authentication method, authentication system and communication method between terminal devices of Internet of things | |
| CN111030814A (en) | Key negotiation method and device | |
| CN110138548B (en) | Quantum communication service station key negotiation method and system based on asymmetric key pool pair and DH protocol | |
| CN101335754B (en) | Method for information verification using remote server | |
| CN105553654A (en) | Key information query processing method and device and key information management system | |
| CN111355591A (en) | Block chain account safety management method based on real-name authentication technology | |
| CN111353000A (en) | Transaction network system, method and device for safely opening electronic insurance | |
| CN114143306B (en) | Bid file transfer method and transfer device based on block chain | |
| CN101924734A (en) | Identity authentication method and authentication device based on Web form | |
| CN110176989B (en) | Quantum communication service station identity authentication method and system based on asymmetric key pool | |
| CN110365472B (en) | Quantum communication service station digital signature method and system based on asymmetric key pool pair | |
| CN115276978A (en) | Data processing method and related device | |
| CN117294484A (en) | Method, apparatus, device, medium and product for data interaction | |
| KR102056612B1 (en) | Method for Generating Temporary Anonymous Certificate | |
| US8261088B2 (en) | Secret authentication system | |
| CN114095165B (en) | Key updating method, server device, client device and storage medium | |
| US11502840B2 (en) | Password management system and method | |
| CN114584347A (en) | Verification short message receiving and sending method, server, terminal and storage medium | |
| CN110086627B (en) | Quantum communication service station key negotiation method and system based on asymmetric key pool pair and time stamp |
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 | ||
| CB03 | Change of inventor or designer information |
Inventor after: Jin Shicheng Inventor after: Fu Shijian Inventor after: Zhang Junfeng Inventor after: Li Xuezhi Inventor after: Guo Wei Inventor before: Jin Shicheng Inventor before: Wang Tongzhou Inventor before: Fu Shijian Inventor before: Zhang Junfeng Inventor before: Li Xuezhi Inventor before: Guo Wei |
|
| CB03 | Change of inventor or designer information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |