CN108173648B

CN108173648B - Digital security processing method, device and storage medium based on private key escrow

Info

Publication number: CN108173648B
Application number: CN201711481070.3A
Authority: CN
Inventors: 闻庆峰; 王胜男
Original assignee: Guangdong Xinjian Information Technology Co ltd; Shuan Times Technology Co ltd
Current assignee: Guangdong Xinjian Information Technology Co ltd; Shuan Times Technology Co ltd
Priority date: 2017-12-29
Filing date: 2017-12-29
Publication date: 2021-01-26
Anticipated expiration: 2037-12-29
Also published as: CN108173648A

Abstract

A method, apparatus, and medium for digital security processing based on private key escrow, the method of one embodiment comprising: receiving a signature request sent by the client, and returning a signature response to the client, wherein the signature response carries the fifth key generation parameter and the sixth key generation parameter; receiving a third ciphertext acquisition request sent by the client, and carrying a sixth client key generated by the client according to a sixth key generation parameter and the user identification code; returning a third ciphertext acquisition response to the client, wherein the third ciphertext acquired response carries a third ciphertext extracted from the stored fifth private key ciphertext encryption result; and receiving a third ciphertext decryption response returned by the client, carrying a third decryption result obtained by decrypting the third ciphertext by the client, decrypting the private key ciphertext based on the third decryption result and then digitally signing, encrypting the private key ciphertext according to a sixth client key to obtain a sixth private key ciphertext encryption result, and storing a sixth key generation parameter and the sixth private key ciphertext decryption result in an associated manner. The scheme of the embodiment improves the safety of digital safety processing.

Description

Digital security processing method, device and storage medium based on private key escrow

Technical Field

The present invention relates to the field of network security technologies, and in particular, to a digital security processing method based on private key escrow, a computer device, and a computer storage medium.

Background

With the development of internet technology and the rise of e-government e-commerce, businesses such as internet banking, internet working, internet shopping and the like have gradually entered the lives of the masses and are changing and developing rapidly. When many critical business operations and transmission of sensitive information are involved, digital signature technology is generally used to realize security protection such as integrity verification, tamper resistance and repudiation resistance of data. At present, private keys are mainly stored and signed by mechanisms and enterprise users through devices such as intelligent password keys and intelligent IC cards, the devices such as the intelligent password keys and the intelligent IC cards are generally kept by special persons, application is needed each time the devices are used, the process is tedious, the devices are unchanged in use, and hardware devices based on a PC (personal computer) end are difficult to meet the requirements along with the increase of mobile scenes.

Disclosure of Invention

Based on this, an object of the embodiments of the present application is to provide a digital secure processing method based on private key escrow, a computer device, and a computer storage medium.

A digital security processing method based on private key escrow includes the following steps:

receiving mechanism private key application information forwarded by a server when receiving a mechanism private key escrow request sent by a first client, wherein the mechanism private key escrow request carries the mechanism private key application information;

sending a first processing request to the server, and receiving a first processing response returned by the server based on the first processing request, wherein the first processing response carries a first key generation parameter;

and generating a first client key according to the first key generation parameter and the user identification code, and sending first confirmation information to the server, wherein the first confirmation information carries the first client key.

sending a signature request to a server;

receiving a signature response returned by the server, wherein the signature response carries a fifth key generation parameter and a sixth key generation parameter;

generating a fifth client key according to the fifth key generation parameter and the user identification code, generating a sixth client key according to the sixth key generation parameter and the user identification code, and sending a third ciphertext acquisition request to the server, wherein the sixth client key is carried by the third ciphertext acquisition request;

receiving a third ciphertext acquisition response returned by the server, wherein the third ciphertext acquisition response carries a third ciphertext extracted from a stored fifth private key ciphertext encryption result;

and decrypting the third ciphertext to obtain a third decryption result, and sending a third ciphertext decryption response to the server, wherein the third ciphertext decryption response carries the third decryption result.

receiving a signature request sent by a client, and returning a signature response to the client according to the signature request, wherein the signature response carries a fifth key generation parameter and a sixth key generation parameter;

receiving a third ciphertext acquisition request sent by the client, wherein the third ciphertext acquisition request carries a sixth client key generated by the client according to the sixth key generation parameter and the user identification code;

returning a third ciphertext acquisition response to the client, wherein the third ciphertext acquisition response carries a third ciphertext extracted from a stored fifth private key ciphertext encryption result;

and receiving a third ciphertext decryption response returned by the client, wherein the third ciphertext decryption response carries a third decryption result obtained by decrypting a third ciphertext by the client, and after a private key ciphertext is decrypted based on the third decryption result, performing digital signature, encrypting the private key ciphertext according to a sixth client key to obtain a sixth private key ciphertext encryption result, and storing a sixth key generation parameter and the sixth private key ciphertext decryption result in an associated manner.

receiving mechanism private key authorization request information forwarded by a server when receiving a mechanism escrow private key authorization request sent by a first client;

sending a second processing request to the server based on the mechanism private key authorization request information, and receiving a second processing response returned by the server based on the second processing request, wherein the second processing response carries a second key generation parameter and a third key generation parameter;

generating a second client key according to the second key generation parameter and the user identification code, generating a third client key according to the third key generation parameter and the user identification code, and sending a first ciphertext acquisition request to the server;

receiving a first ciphertext acquisition response returned by the server, wherein the first ciphertext acquisition response carries a first ciphertext determined based on a stored second private key ciphertext encryption result;

and decrypting the first ciphertext according to the second client key to obtain a first decryption result, and sending a first ciphertext decryption response to the server, wherein the first ciphertext decryption response carries the first decryption result.

sending a request for applying for obtaining the authorization of the private key to the server, and receiving a response for applying for obtaining the authorization of the private key returned by the server, wherein the response for applying for obtaining the authorization of the private key also carries a fourth key generation parameter;

generating a fourth client key according to the fourth key generation parameter and the user identification code, and sending a second ciphertext acquisition request to the server, wherein the second ciphertext acquisition request also carries the fourth client key;

receiving a second ciphertext acquisition response returned by the server, wherein the second ciphertext acquisition response carries a second ciphertext extracted from the stored private key ciphertext authorization encryption result;

and decrypting the second ciphertext to obtain a second decryption result, and sending a second ciphertext decryption response to the server, wherein the second ciphertext decryption response carries the second decryption result.

when receiving an organization escrow private key authorization request, forwarding organization private key authorization request information to a client;

receiving a second processing request sent by the client, and returning a second processing response to the client according to the second processing request, wherein the second processing response carries a second key generation parameter and a third key generation parameter;

receiving a first ciphertext acquisition request sent by the client, wherein the first ciphertext acquisition request carries a third client key generated according to the third key generation parameter and a user identification code;

returning a first ciphertext acquisition response to the client, wherein the first ciphertext acquisition response carries a first ciphertext determined based on a stored second private key ciphertext encryption result;

receiving a first ciphertext decryption response returned by the client, wherein the first ciphertext decryption response carries a first decryption result obtained by decrypting the first ciphertext by the client, and after a private key ciphertext is decrypted based on the first decryption result, encrypting the private key ciphertext based on a public key of a user to be authorized to obtain a private key ciphertext authorization encryption result, and encrypting the private key ciphertext according to a third client key to obtain a third private key ciphertext encryption result; and storing the third key generation parameter and the third private key ciphertext decryption result in an associated manner.

receiving an authorization request for applying for obtaining a private key sent by a client, and returning an authorization response for applying for obtaining the private key to the client, wherein the authorization response for applying for obtaining the private key carries a fourth key generation parameter;

receiving a second ciphertext acquisition request sent by the client according to the application acquisition private key authorization response, wherein the second ciphertext acquisition request carries a fourth client key generated by the client according to the fourth key generation parameter and the user identification code;

returning a second ciphertext acquisition response to the client, wherein the second ciphertext acquisition response carries a second ciphertext extracted from the stored private key ciphertext authorization encryption result;

receiving a second ciphertext decryption response returned by the client, wherein the second ciphertext decryption response carries a second decryption result obtained by the client decrypting the second ciphertext, and after a private key ciphertext is decrypted based on the second decryption result, an authorization result is obtained, and the private key ciphertext is encrypted according to a fourth client key to obtain a fourth private key ciphertext encryption result; and storing the fourth key generation parameter and the fourth private key ciphertext decryption result in an associated manner.

Based on the scheme of the embodiment, the signature private key of the mechanism is hosted at the server, and when the digital security related digital security processing processes such as signature, authorization and authorization acquisition are performed each time, the client and the server cooperatively complete the signature, authorization and authorization acquisition processes based on the private key ciphertext hosted by the server, and on the basis of completing the signature, authorization and authorization acquisition each time, the client further generates a new client key, the server further generates a new private key ciphertext encryption result based on the new client key, and accordingly updates the stored private key ciphertext encryption result, so that the participation of the user of the client is required each time of digital security processing, the private key ciphertext encryption results used each time are different, and the server background personnel can be prevented from keeping the private key ciphertext to falsify the user signature, thereby further improving the security of the digital security process.

Drawings

FIG. 1 is a schematic diagram of an application environment of the present solution according to an embodiment;

FIG. 2 is a flow diagram that illustrates a method for digital secure processing based on private key escrow, in one embodiment;

FIG. 3 is a schematic flow chart diagram of a method for digital secure processing based on private key escrow in another embodiment;

FIG. 4 is a schematic flow chart diagram of a method for digital secure processing based on private key escrow in another embodiment;

FIG. 5 is a schematic flow chart diagram of a method for digital secure processing based on private key escrow in another embodiment;

FIG. 6 is a schematic flow chart diagram of a method for digital secure processing based on private key escrow in another embodiment;

FIG. 7 is a schematic flow chart diagram of a method for digital secure processing based on private key escrow in another embodiment;

FIG. 8 is an interaction flow diagram of a private key escrow-based digital security process in a specific example;

FIG. 9 is an interaction flow diagram of a digital security process based on private key escrow in another specific example;

FIG. 10 is an interaction flow diagram of a digital security process based on private key escrow in another specific example;

fig. 11 is an interaction flow diagram of a private key escrow-based digital security process in another specific example.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

Fig. 1 is a schematic diagram of an application environment related to the solution of the present application in an embodiment, and referring to fig. 1, the solution of the present embodiment relates to a first terminal 101, a second terminal 102, and a server 103, and in some embodiments, further relates to a cryptographic engine 104, and in other embodiments, further may relate to a third terminal 105 and a fourth terminal 106. The first terminal 101, the second terminal 102, the third terminal 105, and the fourth terminal 106 are connected to the server 102 through a network, the cryptographic engine 104 is connected to the server 103 only, and in some embodiments, the cryptographic engine 104 may be configured as a part of the server 103. The crypto machine 103 is configured to generate an encrypted private key ciphertext and export and import the encrypted private key ciphertext for signature, and is only capable of communicating with the server 102. The first terminal 101, the second terminal 102, the third terminal 105, and the fourth terminal 106 may specifically be a desktop terminal, a mobile terminal, or other devices, which may initiate a private key escrow or a private key authorization process when a private key needs to be escrowed to the server 103, or perform verification in a private key escrow application process, or authorize a private key escrowed at the server 103 to the server 103, or obtain authorization of a private key stored by the server 103 from the server 103, or perform signature using a private key escrowed by the server 103 when digital signature needs to be performed, where the mobile terminal may specifically be at least one of a mobile phone, a tablet computer, a notebook computer, and the like, and the server 103 may be implemented by an independent server or a server cluster composed of multiple servers.

In some embodiments of the present application scheme, taking as an example that the first terminal 101 initiates a process of hosting a private key to the server 103, the second terminal 102 is configured to perform a signature using the private key hosted by the server 103, the third terminal 105 is configured to perform a verification in a process of applying for hosting the private key or to authorize the private key hosted by the server 103 to the server 103, and the fourth terminal 106 is configured to obtain authorization of the private key stored by the server 103 from the server 103, the first terminal 101, the second terminal 102, the third terminal 105, and the fourth terminal 106 may be different terminal devices respectively, or may refer to the same terminal device, and only different functions are implemented in different technical scenarios.

In some embodiments, the first terminal 101 may initiate a process of hosting the private key to the server 103 or applying for organization to host the private key authorization through a webpage, an APP application, or other application form, and may be used for submitting an organization to host the private key application and applying for organization to host the private key authorization by a sponsor. The second terminal 102 may be signed with a private key hosted at the server 103 through a web page, APP application or other form of application. In some specific examples, the first terminal 101 and the second terminal 102 may be the same terminal, that is, may be integrated in the same webpage, APP application, or other application form, so as to initiate a process of hosting the private key to the server 103 and initiating a process of signing by an authority hosting the private key authorizer using the private key hosted by the server.

In some embodiments, the third terminal 105 may complete the process of applying for the organization escrow private key and authorizing other users to use the organization escrow private key through an APP application, and has SM2 key generation and operation functions, which may be used for a legal person to confirm that the organization escrow private key applies for and authorizes other users to use the organization escrow private key on behalf of the authority. The fourth terminal 106 can complete that other users (users represented by the illegal person) obtain authority-managed private key authorization through another APP application, and has a certificate application function, and also has a key generation parameter (such as SM2 key generation) and an operation function. In some specific examples, the same APP may be installed on the third terminal 105 and the fourth terminal 106, that is, a corporate representative may complete the process of applying for and authorizing other users to use the organization to host the private key through the APP, and other users of a non-corporate representative may obtain authorization of the organization to host the private key through the APP.

It is to be understood that in some other specific examples, all the above processing procedures that need to be executed by the first terminal 101, the second terminal 102, the third terminal 105, and the fourth terminal 106 may also be completed through a web page or the same APP, such as initiating a private key escrow or a private key authorization procedure, performing verification in a process of applying for private key escrow, authorizing the private key hosted by the server 103 to the server 103, obtaining authorization of the private key stored by the server 103 from the server 103, performing signature using the private key hosted by the server 103 when digital signature needs to be performed, and the like.

Fig. 2 shows a flowchart of a digital security processing method based on private key escrow in an embodiment, which is described by taking a processing procedure of a terminal as an example, as shown in fig. 2, the method in this embodiment includes steps S201 to S204.

Step S201: and sending a signature request to a server.

The signing request can be sent by any organization personnel with signing authority based on a terminal used by the organization personnel, and the organization personnel with signing authority can be a legal representative of the organization or an account number of a personnel who has the highest decision authority for the organization private key escrow, or other personnel who obtain authorization to have the organization which adopts the private key for signing. The signature request may carry data to be signed that needs to be signed.

Step S202: and receiving a signature response returned by the server, wherein the signature response carries a fifth key generation parameter and a sixth key generation parameter.

The fifth key generation parameter and the sixth key generation parameter may be parameters that any terminal may use to generate a client key, and the fifth key generation parameter and the sixth key generation parameter in a specific example may be randomly generated random numbers.

In one embodiment, the signed response may also carry a seventh verification parameter. The seventh authentication parameter is used for the user of the terminal to input, so that the server can perform authentication when receiving the information sent by the terminal. The seventh verification parameter may be any parameter that can be verified, such as a randomly generated random number, which may be in any possible form, such as randomly generated numbers, chinese characters, character strings, or combinations thereof.

Step S203: and generating a fifth client key according to the fifth key generation parameter and the user identification code, generating a sixth client key according to the sixth key generation parameter and the user identification code, and sending a third ciphertext acquisition request to the server, wherein the sixth client key is carried by the third ciphertext acquisition request.

The manner of generating the fifth client key according to the fifth key generation parameter and the user identification code and generating the sixth client key according to the sixth key generation parameter and the user identification code is not limited, and the fifth client key may be generated by using a key derivation function KDF, a hash function, or the like, for example.

In one specific example, the step of generating the fifth client key according to the fifth key generation parameter and the user identification code may include: and generating a fifth client private key according to the fifth key generation parameter and the user identification code, and deriving a fifth client public key according to the fifth client private key. At this time, the fifth client key includes the fifth client public key. The step of generating the sixth client key according to the sixth key generation parameter and the user identification code may include: and generating a sixth client private key according to the sixth key generation parameter and the user identification code, and deriving a sixth client public key according to the sixth client private key. At this time, the sixth client key includes the sixth client public key.

In an embodiment, when the signature response further carries a seventh verification parameter, before sending the third ciphertext acquisition request to the server, the method may further include the step of: and acquiring the eighth verification parameter input by the user. At this time, the eighth verification parameter is also carried in the third ciphertext acquisition request. In case the input by the end user is correct, this eighth authentication parameter should be the same as the seventh authentication parameter described above.

Step S204: and receiving a third ciphertext acquisition response returned by the server, wherein the third ciphertext acquisition response carries a third ciphertext extracted from a stored fifth private key ciphertext encryption result.

In an embodiment, the third ciphertext determined based on the stored fifth private key ciphertext encryption result may be determined in any possible manner, and taking the example of obtaining the fifth private key ciphertext encryption result based on the SM2 encryption manner, the stored fifth private key ciphertext encryption result may be split into C1, C2, and C3 according to the SM2 ciphertext format, and C1 is used as the third ciphertext.

The specific way to decrypt the third ciphertext is not limited in this embodiment. And based on the third ciphertext decryption response carrying the third decryption result, the server side can conveniently analyze whether the third decryption result is correct, so that the client side and the server side are matched with each other to complete the signature process.

In one embodiment, the method of the present embodiment may further include steps S211 to S213 below to complete the escrow of the private key of the organization.

Step 211: receiving mechanism private key application information forwarded by a server when receiving a mechanism private key escrow request sent by a first client, wherein the mechanism private key escrow request carries the mechanism private key application information.

In some embodiments, the first client sending the organization's private key escrow request may be a different client than the client performing the method of this embodiment, such as an organization's sponsor that needs to initiate private key escrow initiating the organization's private key escrow request through the first client. The private key application information of the organization may include related information (such as organization ID, etc.) of the organization (such as an enterprise), and may also include related information of a sponsor. After receiving the application information of the private key of the organization, the server can obtain the account number of the person with the highest decision authority on the legal representative of the organization or the person with the highest decision authority on the private key of the organization based on the related information (such as the organization ID) of the organization, and forward the application information of the private key of the organization to the client corresponding to the account number of the person with the highest decision authority on the legal representative or the person with the highest decision authority on the private key of the organization, that is, the client where the method of the embodiment is executed.

Step S212: sending a first processing request to the server, and receiving a first processing response returned by the server based on the first processing request, wherein the first processing response carries a first key generation parameter.

The first key generation parameter may be any parameter that can be used by the client to generate the client key. In a specific example, the first key generation parameter may be a random number.

In one embodiment, the first processing response may further include a first authentication parameter, where the first authentication parameter is used for a user of the terminal to input, so that the server can perform authentication when receiving the information sent by the terminal. The first verification parameter may be any parameter that can be verified, such as a randomly generated random number, which may be in any possible form, such as randomly generated numbers, chinese characters, character strings, or combinations thereof.

Step S213: and generating a first client key according to the first key generation parameter and the user identification code, and sending first confirmation information to the server, wherein the first confirmation information carries the first client key.

The user Identification code may be a Personal Identification Number (PIN) of the terminal executing the method of the present embodiment, and the PIN may be read from the terminal by itself or input by a user of the terminal.

The manner of generating the first client key according to the first key generation parameter and the user identification code is not limited, and the first client key may be generated by using a key derivation function KDF, a hash function, or the like, for example. In one particular example, a first client private key may be generated from a first key generation parameter and a user identification code, and a first client public key may be derived from the first client private key. At this time, the first client key includes the first client public key.

In an embodiment, when the first processing response further includes the first verification parameter, before sending the first confirmation information to the server, the method may further include the step of: and acquiring a second verification parameter input by the user. At this time, the first confirmation information also carries the second verification parameter. In case the end user input is correct, this second authentication parameter should be the same as the first authentication parameter described above.

In an embodiment, before the sending the first acknowledgement information to the server, the method may further include:

signing the first validation information. Therefore, the first confirmation information can be further confirmed to be issued by the authorization of a client user (such as a legal representative of an organization or a person with the highest decision authority for the organization private key escrow) through the signature of the client, and the non-repudiation of the first confirmation information is improved, so that the safety is further improved.

In a specific example, the first confirmation information may also carry a second client digital certificate.

In one embodiment, the scheme of this embodiment may further include the following steps S221 to S225 to complete the authorization of the escrow private key.

Step S221: and receiving the mechanism private key authorization request information forwarded by the server when receiving the mechanism escrow private key authorization request sent by the first client.

In some embodiments, the first client sending the organization hosting the private key authorization request may be a different client than the client performing the method of this embodiment, such as an organization hosting the private key authorization request initiated by a sponsor of the organization that needs to initiate the organization hosting the private key authorization request through the first client. After receiving the authorization request of the organization escrow private key, the server may obtain an account number of a person with the highest decision authority on a corporate representative of the organization or on an account number of a person with the highest decision authority on the organization private key escrow based on related information (such as an organization ID) of the organization, and forward the authorization information of the organization private key to a client (i.e., a client at which the method of this embodiment is performed) corresponding to the account number of the person with the highest decision authority on the corporate representative or on the organization private key escrow.

Step S222: and sending a second processing request to the server based on the mechanism private key authorization request information, and receiving a second processing response returned by the server based on the second processing request, wherein the second processing response carries a second key generation parameter.

The second key generation parameter may be any parameter that can be used by the client to generate the client key. In a specific example, the second key generation parameter may be a random number.

In an embodiment, the second processing response may further include a third authentication parameter, where the third authentication parameter is used for being input by the user of the terminal, so that the server can perform authentication when receiving the information sent by the terminal. The third verification parameter may be any parameter that can be verified, such as a randomly generated random number, which may be in any possible form, such as randomly generated numbers, chinese characters, character strings, or combinations thereof.

Step S223: and generating a second client-side secret key according to the second secret key generation parameter and the user identification code, and sending a first ciphertext acquisition request to the server side.

The user identification code may be a PIN code of the terminal executing the method of the embodiment, and the PIN code may be read from the terminal by itself or may be input by a user of the terminal.

The manner of generating the second client key according to the second key generation parameter and the user identification code is not limited, and the second client key may be generated by using a key derivation function KDF, a hash function, or the like, for example. In one specific example, a second client private key is generated from the second key generation parameter and the user identification code, and a second client public key is derived from the second client private key. At this time, the second client key includes the second client public key.

In an embodiment, when the second processing response further includes a third verification parameter, before sending the first ciphertext acquisition request to the server, the method may further include: and acquiring a fourth verification parameter input by the user. At this time, the fourth verification parameter is also carried in the first ciphertext acquisition request. In case the input by the end user is correct, this fourth authentication parameter should be the same as the third authentication parameter described above.

Step S224: and receiving a first ciphertext acquisition response returned by the server, wherein the first ciphertext acquisition response carries a first ciphertext determined based on a stored second private key ciphertext encryption result.

In one embodiment, the first ciphertext determined based on the stored second private key ciphertext encryption result may be determined in any possible manner, and taking the example of obtaining the second private key ciphertext encryption result based on the SM2 encryption manner, the stored second private key ciphertext encryption result may be split into C1, C2, and C3 according to the SM2 ciphertext format, and C1 is used as the first ciphertext.

Step S225: and decrypting the first ciphertext according to the second client key to obtain a first decryption result, and sending a first ciphertext decryption response to the server, wherein the first ciphertext decryption response carries the first decryption result.

The specific way to decrypt the first ciphertext is not limited in this embodiment. Based on the first ciphertext decryption response carrying the first decryption result, the server side can analyze whether the first decryption result is correct or not conveniently, and therefore the client side and the server side are matched with each other to complete the authorization of the escrow private key.

On the other hand, in an embodiment, the second processing response may further carry a third key generation parameter; the third key generation parameter in one particular example may also be a randomly generated random number.

At this time, before the sending of the first ciphertext acquisition request to the server, the method may further include: and generating a third client-side key according to the third key generation parameter and the user identification code. The manner of generating the third client key according to the third key generation parameter and the user identification code is not limited, and the third client key may be generated by using a key derivation function KDF, a hash function, or the like, for example. In one specific example, the step of generating the third client key according to the third key generation parameter and the user identification code may include: and generating a third client private key according to the third key generation parameter and the user identification code, and deriving a third client public key according to the third client private key. The third client key comprises the third client public key.

At this time, the first ciphertext obtaining request further carries the third client-side key.

And the second processing response carries the certificate of the user to be authorized. In another embodiment, before sending the first ciphertext obtaining request to the server, the method may further include the steps of: and signing the first ciphertext acquisition request.

In one embodiment, the method in this embodiment further includes the following steps S231 to S234 to obtain authorization to use the escrow private key.

Step S231: and sending an application and acquisition private key authorization request to the server, and receiving an application and acquisition private key authorization response returned by the server.

In a specific example, a user (to be authorized) of the organization who needs to apply for authorization to obtain the escrow private key and needs to be subsequently signed with a private key stored in the server may initiate the request for obtaining the authorization of the private key through the client, where the request for obtaining the authorization of the private key may carry related information of the user to be authorized.

In one embodiment, the application for obtaining the private key authorization response may further include a fifth verification parameter. The fifth authentication parameter is used for the user of the terminal to input, so that the server can perform authentication when receiving the information sent by the terminal. The fifth verification parameter may be any parameter that can be verified, such as a randomly generated random number, which may be in any possible form, such as randomly generated numbers, chinese characters, character strings, or combinations thereof.

In one embodiment, the request for obtaining the private key authorization response may further carry a fourth key generation parameter. The fourth key generation parameter may be any parameter that the client may use to generate a client key. In a specific example, the fourth key generation parameter may be a random number.

Step S232: and sending a second ciphertext acquisition request to the server according to the application acquisition private key authorization response.

In an embodiment, when the request for obtaining the private key authorization further carries a fifth verification parameter, before sending the second ciphertext obtaining request to the server, the method may further include: and acquiring a sixth verification parameter input by the user. At this time, the sixth verification parameter is also carried in the second ciphertext acquisition request. In case the input by the end user is correct, the sixth authentication parameter should be the same as the above-mentioned fifth authentication parameter.

In an embodiment, when the request for obtaining the private key authorization further carries a fourth key generation parameter, before sending the second ciphertext obtaining request to the server, the method may further include: and generating a fourth client key according to the fourth key generation parameter and the user identification code. At this time, the second ciphertext obtaining request also carries the fourth client-side key. The user identification code may be a PIN code of the terminal executing the method of the embodiment, and the PIN code may be read from the terminal or may be input by a user of the terminal.

The manner of generating the fourth client key according to the fourth key generation parameter and the user identification code is not limited, and the fourth client key may be generated by using a key derivation function KDF, a hash function, or the like, for example. In one specific example, the step of generating the fourth client key according to the fourth key generation parameter and the user identification code may include: and generating a fourth client private key according to the fourth key generation parameter and the user identification code, and deriving a fourth client public key according to the fourth client private key. At this time, the fourth client key includes the fourth client public key.

Step S233: and receiving a second ciphertext acquisition response returned by the server, wherein the second ciphertext acquisition response carries a second ciphertext extracted from the stored private key ciphertext authorization encryption result.

In an embodiment, the second ciphertext may be determined based on the stored private key ciphertext authorization encryption result in any possible manner, and taking the example of obtaining the private key ciphertext authorization encryption result based on the SM2 encryption manner, the stored private key ciphertext authorization encryption result may be split into C1, C2, and C3 according to the SM2 ciphertext format, and C1 is used as the second ciphertext.

Step S234: and decrypting the second ciphertext to obtain a second decryption result, and sending a second ciphertext decryption response to the server, wherein the second ciphertext decryption response carries the second decryption result.

The specific way to decrypt the second ciphertext is not limited in this embodiment. And based on the second ciphertext decryption response carrying the second decryption result, the server side can conveniently analyze whether the second decryption result is correct, so that the client side and the server side are matched with each other to complete the process of applying for obtaining the authorization of the private key.

Fig. 3 shows a flowchart of a digital security processing method based on private key escrow in another embodiment, which is described by taking a processing procedure of the server 103 as an example. As shown in fig. 3, the digital security processing method based on private key escrow in this embodiment includes steps S301 to S304.

Step S301: and receiving a signature request sent by the client, and returning a signature response to the client according to the signature request, wherein the signature response carries a fifth key generation parameter and a sixth key generation parameter.

The client sending the signature request may be a client used by any organization personnel with signature authority, and the organization personnel with signature authority may be a legal representative of the organization or an account of a person who has the highest decision authority for hosting the private key of the organization, or may be other persons who have obtained authorization to have an organization signed by using the private key. The signature request may carry data to be signed that needs to be signed.

Step S302: and receiving a third ciphertext acquisition request sent by the client, wherein the third ciphertext acquisition request carries a sixth client key generated by the client according to the sixth key generation parameter and the user identification code.

The manner in which the client generates the fifth client key according to the fifth key generation parameter and the user identification code and generates the sixth client key according to the sixth key generation parameter and the user identification code is not limited, and the fifth client key may be generated by using a key derivation function KDF, a hash function, or the like, for example.

In a specific example, the step of the client generating the fifth client key according to the fifth key generation parameter and the user identification code may include: and generating a fifth client private key according to the fifth key generation parameter and the user identification code, and deriving a fifth client public key according to the fifth client private key. At this time, the fifth client key includes the fifth client public key. The step of generating the sixth client key according to the sixth key generation parameter and the user identification code may include: and generating a sixth client private key according to the sixth key generation parameter and the user identification code, and deriving a sixth client public key according to the sixth client private key. At this time, the sixth client key includes the sixth client public key.

In an embodiment, when the signature response further carries a seventh verification parameter, at this time, the third ciphertext obtaining request further carries an eighth verification parameter input by the user. At this time, the method of this embodiment may further include the steps of: verifying consistency of the eighth verification parameter and the seventh verification parameter. In case the end user input is correct, this eighth authentication parameter should be the same as the seventh authentication parameter described above.

Step S303: and returning a third ciphertext acquisition response to the client, wherein the third ciphertext acquisition response carries a third ciphertext extracted from the stored fifth private key ciphertext encryption result.

Step S304: and receiving a third ciphertext decryption response returned by the client, wherein the third ciphertext decryption response carries a third decryption result obtained by decrypting a third ciphertext by the client, and after a private key ciphertext is decrypted based on the third decryption result, performing digital signature, encrypting the private key ciphertext according to a sixth client key to obtain a sixth private key ciphertext encryption result, and storing a sixth key generation parameter and the sixth private key ciphertext decryption result in an associated manner. The private key ciphertext may be a private key ciphertext obtained by parsing an encryption result of the fifth private key ciphertext.

The specific way to decrypt the third ciphertext is not limited in this embodiment. Based on the third ciphertext decryption response carrying the third decryption result, the server side can analyze whether the third decryption result is correct, so that the client side and the server side are matched with each other to complete the application process of the escrow private key authorization. In addition, when performing digital signature, in one embodiment, after the private key ciphertext and the data to be signed are sent to the cryptographic machine, the cryptographic machine performs signature to obtain a digital signature result.

The association storage of the sixth key generation parameter and the sixth private key ciphertext decryption result may be the update of the fifth private key ciphertext encryption result already stored by the server and the key generation parameter corresponding to the fifth private key ciphertext encryption result. Namely, the server no longer stores the fifth private key ciphertext encryption result and the corresponding key generation parameter, but stores the associated sixth private key generation parameter and the sixth private key ciphertext decryption result, so that the server is ensured to always generate a new private key ciphertext encryption result based on the participation of the user of the terminal after each signature, the server is ensured to have different private key ciphertext encryption results used when the server performs the signature each time, background personnel of the server can be prevented from keeping the private key ciphertext to falsely act as the signature of the user, and the safety of digital security processing is further improved.

In one embodiment, the method of this embodiment may further include the following steps S311 to S315 to complete the escrow of the private key of the organization.

Step S311: and when receiving an organization private key escrow request, forwarding the organization private key application information to the client, wherein the organization private key escrow request carries the organization private key application information.

In some embodiments, the client sending the organization private key escrow request may be a different client than the client receiving the forwarded organization private key application information, such as an organization's sponsor that needs to initiate private key escrow initiating the organization private key escrow request through the first client. After receiving the mechanism private key application information, the server can obtain an account number of a legal person representative of the mechanism or a person who has the highest decision authority for the mechanism private key escrow based on the relevant information (such as the mechanism ID) of the mechanism, and forwards the mechanism private key application information to a client corresponding to the account number of the legal person representative or the person who has the highest decision authority for the mechanism private key escrow.

Step S312: and receiving a first processing request sent by the client, and returning a first processing response to the client according to the first processing request, wherein the first processing response carries a first key generation parameter.

Step S313: and receiving first confirmation information sent by the client, wherein the first confirmation information carries a first client key generated by the client based on the first key generation parameter and the user identification code.

The client may generate the first client key from the first key generation parameter and the user identification code in any possible manner, such as using a key derivation function KDF, a hash function, or the like. In one particular example, the client may generate a first client private key from the first key generation parameter and the user identification code, and derive a first client public key from the first client private key. The first client key may then comprise the first client public key. The user identification code may be a PIN code of the terminal 101, and the PIN code may be obtained by the client from the terminal device where the client is located, or may be input by the user of the client.

In an embodiment, in a case that the first processing response further includes a first authentication parameter, the first confirmation information further carries a second authentication parameter input by a user of the client. In case the user input of the client is correct, this second authentication parameter should be the same as the first authentication parameter described above.

In this case, before proceeding to the next step S314, the method may further include the steps of: verifying the second verification parameter is consistent with the first verification parameter. And under the condition that the second verification parameter is consistent with the first verification parameter, the next step S304 is carried out, otherwise, failure information is returned to the client side or the current processing flow is directly exited.

In one example, in the case that the client signs the first confirmation information, the validity of the signature of the first confirmation information may be further verified. The particular way of verifying the validity of the signature can be done in any possible way.

In a specific example, the first confirmation information may also carry a second client digital certificate. At this time, the server may verify the validity of the signature of the first validation information through the second client digital certificate.

Step S314: and acquiring a private key ciphertext, and encrypting the private key ciphertext based on the first client key to acquire a first private key ciphertext encryption result.

One specific example may be to obtain the private key cryptogram from crypto engine 104. The way of encrypting the private key ciphertext by the first client key may be performed in any possible way.

Step S315: and storing the first key generation parameter and the first private key ciphertext encryption result in a correlation manner.

In one embodiment, the scheme of this embodiment may further include the following steps S321 to S325 to complete the authorization of the escrow private key.

Step S321: and when receiving an authority escrow private key authorization request, forwarding authority private key authorization request information to the client.

In some embodiments, the client sending the organization-hosted private key authorization request may be a different client than the client receiving the forwarded organization-private key authorization request information, such as an organization-hosted private key authorization request initiated by a first client by an author of the organization that desires to initiate the organization-hosted private key authorization request. After receiving the authorization request of the organization escrow private key, the server can obtain the account number of the person with the highest decision authority on the corporate representative of the organization or the person with the highest decision authority on the organization private key escrow based on the related information (such as the organization ID) of the organization, and forwards the authorization information of the organization private key to the client corresponding to the account number of the person with the highest decision authority on the corporate representative or the person with the highest decision authority on the organization private key escrow (namely, the client receiving the forwarded authorization request information of the organization private key).

Step S322: and receiving a second processing request sent by the client, and returning a second processing response to the client according to the second processing request, wherein the second processing response carries a second key generation parameter.

Step S323: and receiving a first ciphertext acquisition request sent by the client.

In an embodiment, in a case that the second processing response further includes a third verification parameter, the first ciphertext acquisition request further carries a fourth verification parameter input by the user of the client. In case the user input of the client is correct, this fourth authentication parameter should be the same as the third authentication parameter described above.

Therefore, in this case, before proceeding to the next step S324, the method may further include the steps of: verifying consistency of the fourth verification parameter with the third verification parameter. And under the condition that the fourth verification parameter is consistent with the third verification parameter, the next step S324 is entered, otherwise, failure information is returned to the client or the current processing flow is directly exited.

In one example, the second processing response also carries the to-be-authorized user credentials. In another example, the method of the present embodiment further comprises the steps of: and verifying the validity of the signature of the first ciphertext acquisition request. The particular way of verifying the validity of the signature can be done in any possible way.

Step S324: and returning a first ciphertext acquisition response to the client, wherein the first ciphertext acquisition response carries a first ciphertext determined based on the stored second private key ciphertext encryption result.

In one embodiment, the first ciphertext determined based on the stored second private key ciphertext encryption result may be obtained in any possible manner, and taking the second private key ciphertext encryption result obtained based on the SM2 encryption manner as an example, the stored second private key ciphertext encryption result may be split into C1, C2, and C3 according to the SM2 ciphertext format, and C1 is used as the first ciphertext.

Step S325: and receiving a first ciphertext decryption response returned by the client, wherein the first ciphertext decryption response carries a first decryption result obtained by decrypting the first ciphertext by the second client, and after a private key ciphertext is decrypted based on the first decryption result, encrypting the private key ciphertext based on a public key of a user to be authorized to obtain a private key ciphertext authorization encryption result. The private key ciphertext may be a private key ciphertext obtained by parsing an encryption result of the second private key ciphertext.

The specific way of decrypting the first ciphertext based on the second client-side key is not limited in this embodiment. The first ciphertext decryption response carries a first decryption result, and the server side can analyze whether the first decryption result is correct or not, so that the client side and the server side are matched with each other to finish the authorization of the escrow private key.

On the other hand, in one embodiment, the second processing response may further carry a third key generation parameter; the third key generation parameter in one particular example may also be a randomly generated random number.

At this time, the first ciphertext obtaining request also carries a third client-side secret key generated by the client side according to a third secret key generation parameter and the user identification code. The manner in which the client generates the third client key according to the third key generation parameter and the user identification code is not limited, and the third client key may be generated by using a key derivation function KDF, a hash function, or the like, for example. In a specific example, the client generates a third client private key according to the third key generation parameter and the user identification code, and derives a third client public key according to the third client private key. The third client key comprises the third client public key.

At this time, the first ciphertext obtaining request further carries the third client-side key. And the method of the embodiment can also comprise the following steps:

encrypting the private key ciphertext according to the third client key to obtain a third private key ciphertext encryption result;

and storing the third key generation parameter and the third private key ciphertext decryption result in an associated manner.

The storage of the third key generation parameter and the third private key ciphertext encryption result in association may be an update of the second key generation parameter and the second private key ciphertext encryption result that have been stored by the server. Namely, the server no longer stores the incidence relation between the second key generation parameter and the second private key ciphertext encryption result, but stores the incidence relation between the third key generation parameter and the third private key ciphertext encryption result, so that the server always generates a new private key ciphertext encryption result based on the participation of the user of the terminal after each processing, the server is ensured to use different private key ciphertext encryption results when executing the authorization process each time, and background personnel of the server can be prevented from keeping the private key ciphertext to falsify the user signature, thereby further improving the safety of digital security processing.

In one embodiment, the method in this embodiment further includes the following steps S331 to S334, so that the user represented by the illegal person obtains authorization to use the escrowed private key.

Step S331: and receiving an authorization request for applying for obtaining the private key sent by the client, and returning an authorization response for applying for obtaining the private key to the client.

In a specific example, a user (to be authorized) of the organization who needs to apply for authorization to obtain the escrow private key and needs to be subsequently signed with a private key stored in the server may initiate the request for applying for obtaining the authorization of the private key through the client, where the request for applying for obtaining the authorization of the private key may carry related information of the user to be authorized.

Step S332: and receiving a second ciphertext acquisition request sent by the client according to the request for acquiring the private key authorization response.

In an embodiment, when the request for obtaining the authorization response of the private key further carries a fifth verification parameter, the second ciphertext obtaining request further carries a sixth verification parameter input by the user. In case the end user input is correct, this sixth authentication parameter should be the same as the fifth authentication parameter described above.

In an embodiment, when the request for obtaining the authorization of the private key further carries a fourth key generation parameter, the second ciphertext obtaining request further carries a fourth client-side key generated by the client according to the fourth key generation parameter and the user identification code.

The manner in which the client generates the fourth client key according to the fourth key generation parameter and the user identification code is not limited, and the fourth client key may be generated by using a key derivation function KDF, a hash function, or the like, for example. In a specific example, the client generates a fourth client private key according to the fourth key generation parameter and the user identification code, and derives a fourth client public key according to the fourth client private key. At this time, the fourth client key includes the fourth client public key.

Step S333: and returning a second ciphertext acquisition response to the client, wherein the second ciphertext acquisition response carries a second ciphertext extracted from the stored private key ciphertext authorization encryption result.

In an embodiment, the second ciphertext determined based on the private key ciphertext authorization encryption result may be determined in any possible manner, and taking the example of obtaining the private key ciphertext authorization encryption result based on the SM2 encryption manner, the private key ciphertext authorization encryption result may be split into C1, C2, and C3 according to the SM2 ciphertext format, and C1 is used as the second ciphertext.

Step S334: and receiving a second ciphertext decryption response returned by the client, wherein the second ciphertext decryption response carries a second decryption result obtained by the client decrypting the second ciphertext, and an authorization result is obtained after a private key ciphertext is decrypted based on the second decryption result.

The specific way to decrypt the second ciphertext is not limited in this embodiment. Based on the second ciphertext decryption response carrying the second decryption result, the server side can analyze whether the second decryption result is correct, so that the client side and the server side are matched with each other to complete the application process of the authorization of the escrow private key.

Wherein, under the condition that the escrow private key authorization application response carries the fourth key generation parameter and the second ciphertext acquisition request carries the fourth client-side key, after the private key ciphertext is decrypted based on the second decryption result, the method may further include the steps of:

encrypting a private key ciphertext according to the fourth client key to obtain a fourth private key ciphertext encryption result; the private key ciphertext may be a private key ciphertext obtained by decrypting an authorized encryption result of the private key ciphertext.

And storing the fourth key generation parameter and the fourth private key ciphertext decryption result in an associated manner.

The related storage of the fourth key generation parameter and the fourth private key ciphertext decryption result may be the update of the private key ciphertext encryption result already stored by the server and the key generation parameter corresponding to the private key ciphertext encryption result. Therefore, after a new user obtains authorization, the server side always generates a new private key ciphertext encryption result based on participation of the user of the terminal, the server side is ensured to use different private key ciphertext encryption results after processing each time, background personnel of the server side are prevented from reserving the private key ciphertext to pretend to be a user signature, and the safety of digital security processing is further improved.

Fig. 4 shows a flowchart of a digital security processing method based on private key escrow according to another embodiment, which is described by taking a processing procedure of a terminal as an example, and as shown in fig. 4, the method in this embodiment includes steps S401 to S405.

Step S401: and receiving the mechanism private key authorization request information forwarded by the server when receiving the mechanism escrow private key authorization request sent by the first client.

Step S402: and sending a second processing request to the server based on the mechanism private key authorization request information, and receiving a second processing response returned by the server based on the second processing request, wherein the second processing response carries a second key generation parameter and a third key generation parameter. The second processing response in one specific example also carries a third authentication parameter.

Step S403: and generating a second client key according to the second key generation parameter and the user identification code, generating a third client key according to the third key generation parameter and the user identification code, and sending a first ciphertext acquisition request to the server, wherein the first ciphertext acquisition request carries the third client key.

In a specific example, in a case that the second processing response carries the third verification parameter, before sending the first ciphertext acquisition request to the server, the method further includes: and acquiring a fourth verification parameter input by the user. At this time, the first ciphertext obtaining request also carries the fourth verification parameter.

Step S404: and receiving a first ciphertext acquisition response returned by the server, wherein the first ciphertext acquisition response carries a first ciphertext determined based on a stored second private key ciphertext encryption result.

Step S405: and decrypting the first ciphertext according to the second client-side key to obtain a first decryption result, and sending a first ciphertext decryption response to the server side, wherein the first ciphertext decryption response carries the first decryption result.

Other technical features in the present embodiment may be the same as those in the embodiment described above.

Fig. 5 is a schematic flowchart of a digital security processing method based on private key escrow according to another embodiment, which is described by taking a processing procedure of a server as an example, and as shown in fig. 5, the method in this embodiment includes steps S501 to S505.

Step S501: and when receiving the mechanism escrow private key authorization request, forwarding mechanism private key authorization request information to the client.

Step S502: and receiving a second processing request sent by the client, and returning a second processing response to the client according to the second processing request, wherein the second processing response carries a second key generation parameter and a third key generation parameter.

Step S503: and receiving a first ciphertext acquisition request sent by the client, wherein the first ciphertext acquisition request carries a third client key generated by the client based on the third key generation parameter and the user identification code.

Step S504: and returning a first ciphertext acquisition response to the client, wherein the first ciphertext acquisition response carries a first ciphertext determined based on the stored second private key ciphertext encryption result.

Step S505: receiving a first ciphertext decryption response returned by a client, wherein the first ciphertext decryption response carries a first decryption result obtained by the client decrypting the first ciphertext, and after a private key ciphertext is decrypted based on the first decryption result, the private key ciphertext is encrypted based on a public key of a user to be authorized to obtain a private key ciphertext authorization encryption result, and the private key ciphertext is encrypted according to a third client key to obtain a third private key ciphertext encryption result; and storing the third key generation parameter and the third private key ciphertext decryption result in an associated manner. The private key ciphertext may be a private key ciphertext obtained by decrypting the second private key ciphertext encryption result.

Fig. 6 shows a flowchart of a digital security processing method based on private key escrow according to another embodiment, which is described by taking a processing procedure of a terminal as an example, and as shown in fig. 6, the method in this embodiment includes steps S601 to S604.

Step S601: and sending a request for applying for obtaining the authorization of the private key to the server, and receiving a response for applying for obtaining the authorization of the private key returned by the server, wherein the response for applying for obtaining the authorization of the private key also carries a fourth key generation parameter.

Step S602: and generating a fourth client key according to the four-key generation parameter and the user identification code, and sending a second ciphertext acquisition request to the server, wherein the second ciphertext acquisition request also carries the fourth client key.

Step S603: and receiving a second ciphertext acquisition response returned by the server, wherein the second ciphertext acquisition response carries a second ciphertext extracted from the stored private key ciphertext authorization encryption result.

Step S604: and decrypting the second ciphertext to obtain a second decryption result, and sending a second ciphertext decryption response to the server, wherein the second ciphertext decryption response carries the second decryption result.

Fig. 7 is a schematic flowchart illustrating a digital security processing method based on private key escrow according to another embodiment, where the embodiment is described by taking a processing procedure of a server as an example, and as shown in fig. 7, the method in this embodiment includes steps S701 to S704.

Step S701: and receiving an authorization request for applying for obtaining the private key sent by the client, and returning an authorization response for applying for obtaining the private key to the client, wherein the authorization response for applying for obtaining the private key carries a fourth key generation parameter.

Step S702: and receiving a second ciphertext acquisition request sent by the client according to the application acquisition private key authorization response, wherein the second ciphertext acquisition request carries a fourth client key generated by the client according to the fourth key generation parameter and the user identification code.

Step S703: and returning a second ciphertext acquisition response to the client, wherein the second ciphertext acquisition response carries a second ciphertext extracted from the stored private key ciphertext authorization encryption result.

Step S704: receiving a second ciphertext decryption response returned by the client, wherein the second ciphertext decryption response carries a second decryption result obtained by the client decrypting the second ciphertext, and after a private key ciphertext is decrypted based on the second decryption result, an authorization result is obtained, and the private key ciphertext is encrypted according to a fourth client key to obtain a fourth private key ciphertext encryption result; and storing the fourth key generation parameter and the fourth private key ciphertext decryption result in an associated manner. The private key ciphertext may be a private key ciphertext obtained by decrypting an authorized encryption result of the private key ciphertext.

As described above, in the embodiment of the present application, the signature private key of the organization user is hosted in the server, the data to be signed is sent to the server when digital signature is required, and the server returns the signature value to the user after completing the digital signature, thereby implementing the digital signature. And the private key ciphertext is encrypted once again every time the signature operation is carried out, so that the signature can be completed only by the participation of a user.

In the specific technical implementation process, the scheme of the embodiment of the application comprises two processes: an organization escrow private key application and an organization escrow private key signature. In the case that the corporate representative may authorize other users to sign, four processes may also be involved: the method comprises the steps of applying for the organization escrow private key, authorizing the organization escrow private key, obtaining authorization for the organization escrow private key and signing the organization escrow private key. The organization escrow private key application is initiated by an organization sponsor and confirmed and generated by an enterprise legal representative. If other users need to use the structure private key, the user initiates the organization to host the private key authorization, and an enterprise legal representative confirms the authorization and the authorized user obtains the authorization. After the authorized user is authorized, both the corporate representative and the authorized user may execute the authority to host the private key signature.

For convenience of explanation, in the following description of the example, four processes including an organization escrow private key application, an organization escrow private key authorization, an organization escrow private key acquisition authorization, and an organization escrow private key signature are exemplified. Referring to fig. 8 to 11, in the following examples, for convenience of description, the following setting conditions are exemplified: the client 1 is used for submitting an organization escrow private key application by a sponsor, escrow private key authorization by a user application organization and escrow private key signature by a using organization, and the client 2 is used for a legal person to escrow private key application on behalf of a confirmation organization and authorize other users to use the organization escrow private key and obtain organization escrow private key authorization by other users (authorized users), wherein the client 1 can be a webpage or an APP application, and the client 2 can be an APP application and has the functions of key generation (such as SM2 key generation), operation and certificate application. It is understood that in other technical implementations, the settings for the client may be different.

As shown in fig. 8 to 11, the server interacts with the client 1, the client 2 and the cryptographic machine in this example, so as to save and manage the private key of the organization, and to bind the private key cryptograph by the user of the organization and authorize the user to use the private key cryptograph. The cipher machine is used for generating the encrypted private key ciphertext, exporting and importing the encrypted private key ciphertext for signature, and the cipher machine can only communicate with the server side.

Based on the settings described above, the following is exemplified in detail with reference to specific examples. In these specific examples, a corporate representative of an enterprise and a user (authorized user) who obtains authority to host private keys first generate a pair of keys (e.g., SM2 key pair) through their use to a client (e.g., client 2) and apply for a corresponding user certificate (e.g., SM2 certificate).

Fig. 8 is a schematic diagram of an interaction flow of a digital security process based on private key escrow in a specific example, which is illustrated by taking a process of an organization escrowing a private key application as an example.

As shown in fig. 8, in a specific mechanism escrow private key application process, after a sponsor opens a client 1 through a terminal used by the sponsor, an organization private key escrow instruction is issued by clicking a relevant button, control, and the like on the client 1, and after receiving the organization private key escrow instruction, the client 1 sends an organization private key escrow request to a server. The organization private key escrow request may carry organization private key application information, where the organization private key application information may include related information (e.g., organization ID, etc.) of an organization (e.g., an enterprise), and may also include related information of a sponsor, and in this embodiment, specific types and contents of the organization private key application information are not limited.

After receiving the organization private key escrow request, the server stores the organization private key application information or related information contained in the organization private key application information, such as related information of a storage organization and related home information of a sponsor. Subsequently, based on the related information of the organization (such as the organization ID), the service end may obtain an account number of a corporate representative of the organization or a person who has the highest decision right to host the private key of the organization (for simplicity, the following embodiments are described by taking the corporate representative as an example), and forward the application information of the private key of the organization to the client 2 corresponding to the account number of the corporate representative.

After receiving the mechanism private key application information returned by the server, the client 2 sends a first processing request to the server to request to obtain the relevant key generation parameters. It is to be understood that in the processing procedure corresponding to fig. 8, a legal person in the organization or a person who has the highest decision authority for the organization private key escrow participates in the relevant processing of the client 2.

After receiving the first processing request, the server generates a first verification parameter ry1 and a first key generation parameter rm1, where the first verification parameter ry1 and the first key generation parameter rm1 may both be random numbers. And then returning a first processing response to the client 2, wherein the first verification parameter ry1 and the first key generation parameter rm1 are carried in the first processing response.

After receiving the first processing response, the client 2 may display the first verification parameter ry1 and prompt the user to input the verification parameter ry1 and a user identification number (PIN code). The user of client 2 (a corporate representative or a person with the highest decision authority on the organization's private key escrow) may enter the authentication parameter ry1 and a PIN code based on the prompt. The verification parameter entered by the user based on the prompt is referred to as the second verification parameter ry 1' in this example.

Subsequently, the client 2 calculates a first client key based on the first key generation parameter rm1 and the PIN code. One specific example may be to do this by first calculating a first client private key d based on a first key generation parameter rm1 and a PIN code₁：d₁F1(PIN, rm1), where the function f1() may be any function that may be used to generate a key, such as a key derivation function KDF, a hash function, etc. And then based on the first client private key d₁Deriving a first client public key P₁＝[d₁]G, wherein G is the base point of the SM2 elliptic curve, (d)₁,P₁) Is a pair of SM2 keys for encrypting the private key ciphertext of the organization. In one specific example, the first client public key P may be used₁And sending the key as a first client key to the server.

Subsequently, the client 2 uses the legal person to represent the private key to apply for information of the private key of the organization, the second verification parameter ry 1' input by the user, and the first client key P₁Signing is carried out to obtain a signature value s, and first confirmation information is sent to a server side, wherein the first confirmation information can carry: an authorized user certificate (e.g. a certificate of a corporate representative or of the highest administrator of the enterprise), a second authentication parameter ry 1', a first client key P₁And a signature value s.

After receiving the first confirmation information sent by the client 2, the server determines whether the second verification parameter ry 1' carried in the first confirmation information is consistent with the locally stored first verification parameter ry1, and if not, returns an error result, and if so, continues to execute the subsequent steps.

And the server side verifies whether the signature value s is valid by using an authorized user certificate (such as a legal representative certificate), if the signature value s is invalid, an error result is returned, and otherwise, a private key ciphertext is obtained. Specifically, the method may be to send a private key ciphertext acquisition request to the crypto engine, and receive a private key ciphertext D returned by the crypto engine.

After obtaining the private key ciphertext D, the server side utilizes the first client side secret key P₁Encrypting the private key ciphertext D to obtain a first private key ciphertext encryption result H₁The encryption algorithm may be any possible algorithm, such as the SM2 encryption algorithm. Then the server side encrypts a first key generation parameter rm1, an authorized user certificate (such as a legal representative certificate), a signature value s and a first private key ciphertext encryption result H₁And storing. The operation result, which may be notification information that the organization private key escrow was successfully performed, is then returned to the client 1 and the client 2.

After the private key of the organization is successfully managed to the server, the legal representative of the organization can further authorize other users to use the private key managed at the server, so that the legal representative of the organization can authorize the server through the client 2, and then the server authorizes other users needing to use the private key.

Fig. 9 is a schematic diagram of an interaction flow of a digital security process based on private key escrow in a specific example, which is illustrated by taking a process of an organization escrowing private key authorization as an example.

As shown in fig. 9, in a specific process of authority-managed private key authorization, after a user to be authorized, an enterprise legal person, a sponsor, or another user opens a client 1 through a terminal used by the user, an authority-managed private key authorization instruction is issued by clicking a relevant button, control, or the like on the client 1, and after receiving the authority-managed private key authorization instruction, the client 1 sends an authority-managed private key authorization request to a server. The authority escrow private key authorization request may carry private key authorization application information, where the private key authorization application information may include related information (such as an authority ID and the like) of an authority (such as an enterprise), and may also include a to-be-authorized user certificate (a legal representative certificate), and in this embodiment, specific types and contents of the private key authorization application information are not limited.

After receiving the mechanism escrow private key authorization request, the server stores the private key authorization application information or related information contained in the private key authorization application information, such as storing a user certificate to be authorized. Subsequently, the server may obtain an account number of a legal person representative of the organization based on the related information (such as the organization ID) of the organization, and forward the organization escrow private key authorization request to the client 2 corresponding to the account number of the legal person representative.

After receiving the mechanism escrow private key authorization request, the client 2 sends a second processing request to the server to request to obtain the relevant key generation parameters. It is to be understood that, in the processing procedure corresponding to fig. 9, a legal person representative of an organization participates in the relevant processing of the client 2.

The server side reads the second key generation parameter rm2 from the storage device after receiving the second processing request. The second key generation parameter rm2 is a key generation parameter that is newly stored after being used by a legal representative for the organization hosting private key generation, authorization. Assuming that the above organization does not perform any authorization, use by a legal representative, etc. after hosting the private key generation, and does not adopt other methods to update the stored key generation parameters, the second key generation parameter rm2 should be the above-mentioned stored first key generation parameter rm 1.

In addition, the server generates a third verification parameter ry2 and a third key generation parameter rm3, and both the third verification parameter ry2 and the third key generation parameter rm3 may be random numbers. And then returning a second processing response to the client 2, wherein the third verification parameter ry2, the second key generation parameter rm2 and the third key generation parameter rm3 are carried in the first processing response.

After receiving the second processing response, the client 2 may display the third verification parameter ry2 and prompt the user to input the verification parameter ry2 and a user identification number (PIN code). The user of client 2 (e.g., a corporate representative) may enter the authentication parameter ry2 and a PIN code based on the prompt. The verification parameter entered by the user based on the prompt is referred to as the fourth verification parameter ry 2' in this example.

Subsequently, the client 2 calculates a second client key based on the second key generation parameter rm2 and the PIN code. One specific example may be to calculate the second client private key d based on the second key generation parameter rm2 and the PIN code₂：d₂F1(PIN, rm2), where the function f1() may be any function that may be used to generate a key, such as a key derivation function KDF, a hash function, etc.

On the other hand, the client 2 also calculates a third client key based on the third key generation parameter rm3 and the PIN code. One specific example may be that the third client private key d is calculated based on the third key generation parameter rm3 and the PIN code₃：d₃F1(PIN, rm3), where the function f1() may be any function that may be used to generate a key, such as a key derivation function KDF, a hash function, etc. And then based on the third client private key d₃Deriving a third client public key P₃＝[d₃]G, wherein G is the base point of the SM2 elliptic curve, (d)₃,P₃) Is a pair of SM2 keys for encrypting the private key ciphertext of the organization. This third client public key P may be used in one specific example₃And sending the key as a third client-side key to the server side.

Subsequently, the client 2 utilizes the legal representative private key to input the fourth verification parameter ry 2', the third key generation parameter rm3 and the third client key P for the user₃And signing the certificate of the user to be authorized to obtain a signature value s, and sending a first ciphertext acquisition request to the server, wherein the first ciphertext acquisition request carries: the fourth verification parameter ry 2', the third key generation parameter rm3 and the third client key P input by the user₃And a signature value s.

After receiving the first ciphertext acquisition request sent by the client 2, the server verifies whether the fourth verification parameter ry 2' carried in the first ciphertext acquisition request is consistent with the locally stored third verification parameter ry2, if not, an error result is returned, and if so, the server continues to execute the subsequent steps.

The server side reads the representative certificate of the legal person from the storage device, verifies whether the signature value s is valid or not by using the representative certificate of the legal person, returns an error result if the signature value s is invalid, and otherwise reads the stored second private key ciphertext encryption result H from the storage device₂. The second private key ciphertext encryption result H₂Generation, authorization, and generation of legal agent for organization escrow private keyAnd the table encrypts the result by using the latest stored private key ciphertext. Assuming that the mechanism does not perform any processes of authorization, representative use of a legal person and the like after the mechanism escrow private key is generated, and does not adopt other methods to update the stored key generation parameters, the second private key ciphertext encryption result H₂It should be the first private key ciphertext encryption result H stored above₁。

Taking the example of obtaining the encryption result of the private key ciphertext by encrypting with SM2, the encryption result H of the second private key ciphertext may be obtained according to the SM2 ciphertext format₂Splitting into C₁、C₂And C₃And returns a first ciphertext acquisition response to the client 2, wherein the first ciphertext acquisition response carries a first ciphertext C₁。

After receiving the first ciphertext acquisition response, the client 2 adopts the generated second client private key d₂：d₂Decrypting the first ciphertext to obtain a first decryption result (x) of f1(PIN, r2)_2,y₂)＝[d₂]C₁Then, a first ciphertext decryption response is returned to the server side, wherein the first ciphertext decryption response carries a first decryption result x₂||y₂。

The server receives the first ciphertext decryption response returned by the client 2, and verifies the correctness of the first decryption result in the first ciphertext decryption response, in a specific example, the following method may be used: calculating t 2-KDF (x)₂||y₂)，D＝C₂⊕t₂，u＝SM3(x₂||D||y₂) D is the mechanism managed private key ciphertext after decryption, and then u and C are verified₃And if the two are consistent, returning an error result, and if the two are consistent, continuously executing the subsequent steps.

The server side encrypts a second private key ciphertext encryption result H by using the public key of the user to be authorized (which may be the public key read from the certificate or other pre-stored public keys)₂Corresponding private key ciphertext D to obtain a private key ciphertext authorization encryption result H₀The encryption algorithm may employ SM 2.

In addition, the server side also utilizes a third client side secret key P₃Encryption of privateThe cipher text D of the third private key is obtained₃The encryption algorithm may employ SM 2.

At any time, the server stores a third key generation parameter rm3, a signature value s and a private key ciphertext authorization encryption result H₀And a third private key ciphertext encryption result H₃(ii) a And the server no longer stores the second key generation parameter rm2 and the second private key ciphertext encryption result H₂. And then returning operation results to the client 1 and the client 2, wherein the operation results can be specifically results of successfully performed authority private key authorization.

After the legal representative successfully authorizes the organization escrow private key, other users of the organization can obtain authorization from the server side so as to be capable of executing a signature process by using the escrow structure private key.

Fig. 10 is a schematic diagram of an interaction flow of a digital security process based on private key escrow in another specific example, which is illustrated by taking a process of an organization escrowing a private key to obtain authorization.

As shown in fig. 10, in the process of obtaining authorization by hosting a private key by a specific organization, after a user to be authorized opens a client 2 through a terminal used by the user, the user clicks a related button, control, or the like on the client 2 to issue an instruction for obtaining the authorization of the private key, and after receiving the instruction for obtaining the authorization of the private key, the client 2 sends a request for obtaining the authorization of the private key to a server. The request for obtaining the authorization of the private key can carry the relevant information of the user to be authorized.

After receiving the request for obtaining the authorization of the private key, the server generates a fifth verification parameter ry3 and a fourth key generation parameter rm4, where the fifth verification parameter ry3 and the fourth key generation parameter rm4 may both be random numbers. And then returning an authorization response of applying for obtaining the private key to the client 2, wherein the authorization response of applying for obtaining the private key carries the fifth verification parameter ry3 and the fourth key generation parameter rm 4.

After receiving the request for obtaining the private key authorization response, the client 2 may display the fifth verification parameter ry3, and prompt the user to input the verification parameter ry3 and the user identification number (PIN code). The user to be authorized of the client 2 can enter the authentication parameter ry3 and the PIN code based on the prompt. The verification parameter entered by the user based on the prompt is referred to as the sixth verification parameter ry 3' in this example.

Subsequently, the client 2 calculates a fourth client key based on the fourth key generation parameter rm4 and the PIN code. One specific example may be that the fourth client private key d is calculated based on the fourth key generation parameter rm4 and the PIN code₄：d₄F1(PIN, rm4), where the function f1() may be any function that may be used to generate a key, such as a key derivation function KDF, a hash function, etc. And then based on the fourth client private key d₄Deriving a fourth client public key P₄＝[d₄]G, wherein G is the base point of the SM2 elliptic curve, (d)₄,P₄) Is a pair of SM2 keys for encrypting the private key ciphertext of the organization. This fourth client public key P may be used in one specific example₄And sending the key as a fourth client-side key to the server side.

Subsequently, the client 2 sends a second ciphertext acquisition request to the server, where the second ciphertext acquisition request carries a sixth verification parameter ry 3' and a fourth client key P input by the user₄。

After receiving the second ciphertext acquisition request sent by the client 2, the server verifies whether the sixth verification parameter ry 3' carried in the second ciphertext acquisition request is consistent with the locally stored fifth verification parameter ry3, if not, an error result is returned, and if so, the subsequent steps are continuously executed.

The server side reads the stored private key ciphertext authorization encryption result H from the storage device₀Obtaining the private key ciphertext authorization encryption result H by encrypting by using SM2₀For example, the private key ciphertext may be authorized to encrypt result H in the SM2 ciphertext format₀Splitting into C₁、C₂And C₃And returns a second ciphertext acquisition response to the client 2, wherein the second ciphertext acquisition response carries a second ciphertext C₁。

After receiving the second ciphertext acquisition response, the client 2 utilizes the private key K of the user to be authorized₁For the second ciphertext C₁Decrypting to obtain a second decryption result (x)₂,y₂)＝[K₁]C₁. Wherein the private key K₁Corresponding to the public key of the user to be authorized encrypted during the authorization of the organization escrow private key. And then returning a second ciphertext decryption response to the server, wherein the second ciphertext decryption response carries a second decryption result x₂||y₂。

The server receives the second ciphertext decryption response returned by the client 2, and verifies the correctness of the second decryption result in the second ciphertext decryption response, which may be performed in the following manner in one specific example: calculating t 2-KDF (x)₂||y₂)，D＝C₂⊕t₂，u＝SM3(x₂||D||y₂) D is the mechanism managed private key ciphertext after decryption, and then u and C are verified₃If the two are consistent, returning an error result if the two are not consistent, and continuing to execute the subsequent steps if the two are consistent;

the server also utilizes a fourth client key P₄Encrypting the private key ciphertext D to obtain a fourth private key ciphertext encryption result H₄The encryption algorithm may employ SM 2. Subsequently, the server stores the fourth key generation parameter rm4 and the fourth private key ciphertext encryption result H₄(ii) a And the server no longer stores the previous private key ciphertext encryption result and the corresponding key generation parameter (such as the second key generation parameter rm2 and the second private key ciphertext encryption result H described above)₂). And then returns an operation result to the client 2, specifically, a result of successful authorization.

Based on the scheme of the application, the legal representative of the structure and the authorized user (authorized user) can adopt an organization private key hosted by a server side to carry out signature. Fig. 11 shows an interaction flow diagram of a digital security process based on private key escrow in another specific example, and the interaction flow is described by taking a signature process as an example.

Referring to fig. 11, in a specific process of digital signature, after a user (legal representative of an organization or authorized user) who needs to perform digital signature opens the client 1 through a terminal used by the user, a signature instruction is issued by clicking a relevant button, control, or the like on the client 1. After receiving the signature command, the client 1 sends a signature request to the server. The signature request may carry data to be signed that needs to be signed.

After receiving the signing request, the server reads a fifth key generation parameter rm5 from the storage device (if the user is an enterprise legal person, rm5 represents the key generation parameter stored latest after being used in the process of generating, authorizing and signing the organization escrow private key, and if the user is an authorized user, rm5 represents the key generation parameter stored latest after being used by the authorized user in the process of obtaining authorization and signing the organization escrow private key), and generates a seventh verification parameter ry4 and a sixth key generation parameter rm 6. And then, a signature response is returned to the server, wherein the signature response carries a seventh verification parameter ry4, a fifth key generation parameter rm5 and a sixth key generation parameter rm 6.

After receiving the second processing response, the client 1 may display the seventh verification parameter ry4 and prompt the user to input the verification parameter ry4 and the user identification number (PIN code). The user of client 1 (legal representative or authorized user) may enter the authentication parameter ry4 and a PIN code based on the prompt. The verification parameter entered by the user based on the prompt is referred to as the eighth verification parameter ry 4' in this example.

Subsequently, the client 2 calculates a fifth client key based on the fifth key generation parameter rm5 and the PIN code. One specific example may be that the fifth client private key d is calculated based on the fifth key generation parameter rm5 and the PIN code₅：d₅F1(PIN, rm5), where the function f1() may be any function that may be used to generate a key, such as a key derivation function KDF, a hash function, etc.

On the other hand, the client 2 also calculates a sixth client key based on the sixth key generation parameter rm6 and the PIN code. One specific example may be that the sixth client private key d is calculated based on the sixth key generation parameter rm6 and the PIN code₆：d₆F1(PIN, rm6), where the function f1() may be any function that may be used to generate a key, such as a key derivation function KDF, a hash function, etc. And then based on the sixth guestPrivate key d of client₆Deriving a sixth client public key P₆＝[d₆]G, wherein G is the base point of the SM2 elliptic curve, (d)₆,P₆) Is a pair of SM2 keys for encrypting the private key ciphertext of the organization. This sixth client public key P may be used in one specific example₆And sending the key to the server as a sixth client key.

Then, the client 1 sends a third ciphertext acquisition request to the server, where the third ciphertext acquisition request carries: the user-entered eighth authentication parameter ry 4', sixth client key P₆In the case of a signature, the signature value s may also be carried.

After receiving the third ciphertext acquisition request sent by the client 1, the server verifies whether the eighth verification parameter ry 4' carried in the third ciphertext acquisition request is consistent with the locally stored seventh verification parameter ry4, if not, an error result is returned, and if so, the server continues to execute the subsequent steps.

The server side reads the stored fifth private key ciphertext encryption result H from the storage device₅(if the user is a corporate judge, H)₅In the processes of generating, authorizing and signing the organization escrow private key, a legal representative uses the latest stored private key ciphertext encryption result; if the user is an authorized user, H₅The latest stored private key ciphertext encryption result after being used by the authorized user in the process of obtaining authorization and signature for the mechanism managed private key). Taking the example of obtaining the encryption result of the private key ciphertext by using SM2 for encryption, the fifth private key ciphertext encryption result H may be obtained according to SM2 ciphertext format₅Splitting into C₁、C₂And C₃And returns a third ciphertext acquisition response to the client 2, wherein the third ciphertext acquisition response carries a third ciphertext C₁。

After receiving the third ciphertext acquisition response, the client 1 adopts the generated fifth client private key d₅：d₅Decrypting the third ciphertext to obtain a third decrypted result (x) f1(PIN, rm5)₂,y₂)＝[d₅]C₁Then, a third ciphertext decryption response is returned to the server side, and the first ciphertext decryption response carries the third decryptionResult x₂||y₂。

The server receives the third ciphertext decryption response returned by the client 1, and may verify the correctness of the third decryption result in the third ciphertext decryption response, in a specific example, the following method may be used: calculating t 2-KDF (x)₂||y₂)，

u＝SM3(x₂||D||y₂) D is the mechanism managed private key ciphertext after decryption, and then u and C are verified₃And if the two are consistent, returning an error result, and if the two are consistent, continuously executing the subsequent steps.

And the server side signs the data to be signed based on the decrypted private key ciphertext D to obtain a digital signature result. In a specific example, the signing process may be completed in combination with a cryptographic engine, and specifically, the signing process may be completed by: and the server side sends the data to be signed and the private key ciphertext D to the cipher machine, and the cipher machine signs the data to be signed by adopting the private key ciphertext D to obtain a digital signature result and returns the digital signature result to the server side. After the server calculates the digital signature result by itself or obtains the digital signature result returned by the cipher machine, the server can return the digital signature result to the client 1, thereby completing the digital signature process.

The server also utilizes a sixth client key P₆Encrypting the private key ciphertext D to obtain a sixth private key ciphertext encryption result H₆The encryption algorithm may employ SM 2. Subsequently, the server stores a sixth key generation parameter rm6 and a sixth private key ciphertext encryption result H₆(ii) a And the server no longer stores the previous private key ciphertext encryption result and the corresponding key generation parameter (such as the above-mentioned fifth key generation parameter r5 and fifth private key ciphertext encryption result H)₅)。

Based on the examples described above, there is also provided in one embodiment a computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor when executing the program implements the method of any one of the embodiments described above.

The computer device in one embodiment, which may be a terminal or a server in fig. 1, includes a processor, a memory, a network interface, and an input device connected by a system bus. Wherein the memory includes a non-volatile storage medium and an internal memory. The non-volatile storage medium of the computer device stores an operating system and may also store a computer program that, when executed by the processor, causes the processor to implement a digital secure processing method based on private key escrow. The internal memory may also have stored therein a computer program that, when executed by the processor, causes the processor to perform a digital security processing method based on private key escrow. It will be appreciated by those skilled in the art that the architecture described herein is merely a block diagram of some of the structures associated with the embodiments of the present application and is not intended to limit the computing devices to which the embodiments of the present application may be applied, as a particular computing device may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

It will be understood by those skilled in the art that all or part of the processes in the methods of the embodiments described above may be implemented by a computer program, which is stored in a non-volatile computer-readable storage medium, and in the embodiments of the present application, the program may be stored in the storage medium of a computer system and executed by at least one processor in the computer system to implement the processes of the embodiments including the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

Accordingly, in an embodiment, a storage medium is further provided, on which a computer program is stored, wherein the program, when executed by a processor, implements the digital security processing method based on private key escrow as in any one of the above embodiments.

The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A digital security processing method based on private key escrow includes the following steps:

sending a signature request to a server;

2. The method of claim 1, wherein the signed response further carries a seventh verification parameter;

before sending the third ciphertext decryption response to the server, the method further comprises the following steps: acquiring an eighth verification parameter input by a user;

and the third ciphertext decryption response also carries the eighth verification parameter.

3. The method according to claim 1 or 2, characterized in that before sending the signature request to the server, it further comprises the steps of:

receiving mechanism private key application information forwarded by a server when receiving a mechanism private key escrow request sent by a first client;

4. The method of claim 3, comprising at least one of:

the first item: before sending the first confirmation information to the server, the method further comprises the following steps: signing the first confirmation information;

the second term is: the first confirmation information also carries a client digital certificate;

the third item: the first processing response also carries a first verification parameter; before sending the first confirmation information to the server, the method further comprises the following steps: acquiring the user identification code and a second verification parameter input by a user; the first confirmation information also carries the second verification parameter.

5. The method according to claim 1 or 2, characterized in that before sending the signature request to the server, it further comprises the steps of:

sending a second processing request to the server based on the mechanism private key authorization request information, and receiving a second processing response returned by the server based on the second processing request, wherein the second processing response carries a second key generation parameter;

generating a second client key according to the second key generation parameter and the user identification code, and sending a first ciphertext acquisition request to the server;

6. The method of claim 5, comprising at least one of:

the first item: the second processing response also carries a third key generation parameter; before sending the first ciphertext acquisition request to the server, the method further comprises the following steps: generating a third client key according to the third key generation parameter and the user identification code; the first ciphertext acquisition request also carries the third client key;

the second term is: the second processing response also carries a third verification parameter; before sending the first ciphertext acquisition request to the server, the method further comprises the following steps: acquiring the user identification code and a fourth verification parameter input by a user; the first ciphertext acquisition request also carries the fourth verification parameter;

the third item: the second processing response also carries a certificate of the user to be authorized; before sending the first ciphertext acquisition request to the server, the method further comprises the following steps: and signing the first ciphertext acquisition request.

7. The method according to claim 1 or 2, characterized in that before sending the signature request to the server, it further comprises the steps of:

sending a request for applying for obtaining the authorization of the private key to the server, and receiving a response for applying for obtaining the authorization of the private key returned by the server;

sending a second ciphertext acquisition request to the server according to the application acquisition private key authorization response;

8. The method of claim 7, comprising at least one of:

the first item: the application obtains the private key authorization response and also carries a fourth key generation parameter; before sending the second ciphertext acquisition request to the server, the method further comprises the following steps: generating a fourth client key according to the fourth key generation parameter and the user identification code; the second ciphertext acquisition request also carries the fourth client-side key;

the second term is: the application obtains a private key authorization response and also carries a fifth verification parameter; before sending the second ciphertext acquisition request to the server, the method further comprises the following steps: acquiring the user identification code and a sixth verification parameter input by a user; the second ciphertext obtaining request also carries the sixth verification parameter.

9. A digital security processing method based on private key escrow includes the following steps:

10. The method of claim 9, wherein the signed response further carries a seventh verification parameter; the third ciphertext acquisition request also carries an eighth verification parameter input by the user;

before returning the third ciphertext acquisition response to the client, the method further comprises the following steps: verifying consistency of the eighth verification parameter and the seventh verification parameter.

11. The method according to claim 9 or 10, further comprising, before receiving the signature request sent by the client, the steps of:

when receiving an organization private key escrow request, forwarding organization private key application information to the client;

receiving a first processing request sent by the client, and returning a first processing response to the client according to the first processing request, wherein the first processing response carries a first key generation parameter;

receiving first confirmation information sent by the client, wherein the first confirmation information carries a first client key generated by the client based on the first key generation parameter and the user identification code;

obtaining a private key ciphertext, and encrypting the private key ciphertext based on the first client key to obtain a first private key ciphertext encryption result;

and storing the first key generation parameter and the first private key ciphertext encryption result in a correlation manner.

12. The method of claim 11, comprising at least one of:

the first item: the first processing response further comprises a first verification parameter; the first confirmation information also carries a second verification parameter input by the user; before obtaining the private key ciphertext, the method further comprises the following steps: verifying the second verification parameter to be consistent with the first verification parameter;

the second term is: before obtaining the private key ciphertext, the method further comprises the following steps: verifying the validity of the signature of the first validation information;

the third item: the first confirmation information also carries a second client digital certificate; and before the private key ciphertext is obtained, verifying the validity of the signature of the first confirmation information through a second client-side digital certificate.

13. The method according to claim 9 or 10, further comprising, before receiving the signature request sent by the client, the steps of:

when an organization escrow private key authorization request is received, forwarding organization private key authorization request information to the client;

receiving a second processing request sent by the client, and returning a second processing response to the client according to the second processing request, wherein the second processing response carries a second key generation parameter;

receiving a first ciphertext acquisition request sent by the client;

and receiving a first ciphertext decryption response returned by the client, wherein the first ciphertext decryption response carries a first decryption result obtained by decrypting the first ciphertext by the client, and after a private key ciphertext is decrypted based on the first decryption result, encrypting the private key ciphertext based on a public key of a user to be authorized to obtain a private key ciphertext authorization encryption result.

14. The method of claim 13, further comprising at least one of:

the first item: the second processing response also carries a third key generation parameter; the first ciphertext acquisition request also carries a third client-side secret key generated by the client side according to the third secret key generation parameter and the user identification code;

the method further comprises the steps of: encrypting the private key ciphertext according to the third client key to obtain a third private key ciphertext encryption result; storing the third key generation parameter and the third private key ciphertext decryption result in an associated manner;

the second term is: the second processing response also carries a third verification parameter; the first ciphertext acquisition request also carries a fourth verification parameter input by the user;

before returning the first ciphertext acquisition response to the client, the method further comprises the following steps: verifying consistency of the fourth verification parameter and the third verification parameter;

the third item: the second processing response also carries a certificate of the user to be authorized;

before returning the first ciphertext acquisition response to the client, the method further comprises the following steps: and verifying the validity of the signature of the first ciphertext acquisition request.

15. The method according to claim 9 or 10, further comprising the step of:

receiving an authorization request for applying for obtaining a private key sent by the client, and returning an authorization response for applying for obtaining the private key to the client;

receiving a second ciphertext acquisition request sent by the client according to the application acquisition private key authorization response, and returning a second ciphertext acquisition response to the client, wherein the second ciphertext acquisition response carries a second ciphertext extracted from a stored private key ciphertext authorization encryption result;

and receiving a second ciphertext decryption response returned by the client, wherein the second ciphertext decryption response carries a second decryption result obtained by the client decrypting the second ciphertext, and an authorization result is obtained after a private key ciphertext is decrypted based on the second decryption result.

16. The method of claim 15, further comprising at least one of:

the first item: the application obtains a private key authorization response carrying a fourth key generation parameter; the second ciphertext acquisition request carries a fourth client-side secret key generated by the client side according to the fourth secret key generation parameter and the user identification code;

the method further comprises the steps of: encrypting a private key ciphertext according to the fourth client key to obtain a fourth private key ciphertext encryption result; storing the fourth key generation parameter and the fourth private key ciphertext decryption result in an associated manner;

the second term is: the application obtains a private key authorization response and also carries a fifth verification parameter; the second ciphertext acquisition request also carries a sixth verification parameter input by the user;

before returning the second ciphertext acquisition response to the client, the method further comprises the following steps: verifying consistency of the sixth verification parameter and the fifth verification parameter.

17. A digital security processing method based on private key escrow includes the following steps:

18. The method of claim 17, comprising at least one of:

the first item: the second processing response also carries a third verification parameter; before sending the first ciphertext acquisition request to the server, the method further comprises the following steps: acquiring a fourth verification parameter input by a user; the first ciphertext acquisition request also carries the fourth verification parameter;

the second term is: the second processing response also carries a certificate of the user to be authorized; before sending the first ciphertext acquisition request to the server, the method further comprises the following steps: and signing the first ciphertext acquisition request.

19. A digital security processing method based on private key escrow includes the following steps:

20. The method of claim 19, wherein the request for obtaining the private key authorization response further carries a fifth verification parameter;

before sending the second ciphertext acquisition request to the server, the method further comprises the following steps: acquiring the user identification code and a sixth verification parameter input by a user;

the second ciphertext obtaining request also carries the sixth verification parameter.

21. A digital security processing method based on private key escrow includes the following steps:

receiving a first ciphertext acquisition request sent by the client, wherein the first ciphertext acquisition request carries a third client key generated by the client according to the third key generation parameter and the user identification code;

receiving a first ciphertext decryption response returned by the client, wherein the first ciphertext decryption response carries a first decryption result obtained by decrypting the first ciphertext by the client, and after a private key ciphertext is decrypted based on the first decryption result, encrypting based on a public key ciphertext of a user to be authorized to obtain a private key ciphertext authorization encryption result, and encrypting the private key ciphertext according to a third client key to obtain a third private key ciphertext encryption result; and storing the third key generation parameter and the third private key ciphertext decryption result in an associated manner.

22. The method of claim 21, further comprising at least one of:

the first item: the second processing response also carries a third verification parameter; the first ciphertext acquisition request also carries a fourth verification parameter input by the user;

the second term is: the second processing response also carries a certificate of the user to be authorized;

23. A digital security processing method based on private key escrow includes the following steps:

24. The method of claim 23, wherein: the application obtains a private key authorization response and also carries a fifth verification parameter; the second ciphertext acquisition request also carries a sixth verification parameter input by the user;

25. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the steps of the method of any one of claims 1 to 24 are implemented when the program is executed by the processor.

26. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 24.