Multi-scene-oriented secret key hosting method and storage medium

Abstract

The invention discloses a multi-scene-oriented secret key trusteeship method and a storage medium, and the method comprises the steps: an application server establishes a connection with a trusteeship system end, and the application server sends a secret key, a secret key trusteeship request and an encryption mode request to the trusteeship system end; the trusteeship system end receives a secret key, a secret key trusteeship request and an encryption mode request, the secret key comprises a public key and a private key, the trusteeship system end responds to the secret key trusteeship request, the public key is adopted to encrypt the secret key according to the requested encryption mode to obtain a ciphertext, the ciphertext has an initial validity period, and the trusteeship system end trusteeship the ciphertext in the initial validity period. The ciphertext corresponds to the application server. According to different scene requirements, a specific encryption mode is selected to carry out customization processing, so that the requirement of multi-scene hosting service can be met.

Description

Technical Field

[0001] The present invention relates to the technical field of key escrow, and more specifically, to a method and storage medium for multi-scenario key escrow. Background Art

[0002] Currently, general encryption services generally use relatively single encryption methods to encrypt keys. The more common methods are symmetric encryption through AES, DES, 3DES; and asymmetric encryption through RSA, DSA, ECC. After encrypting the content, the key is stored. The escrow party obtains the escrowed encrypted content by actively querying, achieving secure storage through the method of centralized escrow encryption of important content.

[0003] However, the current key escrow system scenarios and single-way encryption cannot meet the needs of multi-user scenarios. Most escrow systems are for static content storage services, querying and updating operations of general business systems. After updating from the management background, it is difficult to achieve real-time update of the business escrow system. There is only one version for the same escrowed content, that is, the original content is immediately overwritten after updating the escrowed content, and the usage requirements of multi-version coexistence cannot be met in some specific scenarios.

[0004] Therefore, the present invention provides a method and storage medium for multi-scenario key escrow. Summary of the Invention

[0005] In view of this, the present invention provides a method and storage medium for multi-scenario key escrow to meet the usage requirements of multi-scenario escrow services and multi-version coexistence.

[0006] On the one hand, the present invention provides a method for multi-scenario key escrow, which is applied to an application server and an escrow system, and includes:

[0007] The application server establishes a connection with the escrow system;

[0008] The application server sends a key, a key escrow request, and an encryption method request to the escrow system;

[0009] The escrow system receives the key, the key escrow request, and the encryption method request. The key includes a public key and a private key. The escrow system responds to the key escrow request, encrypts the key according to the requested encryption method using the public key to obtain a ciphertext. The ciphertext has an initial validity period. The escrow system escrows the ciphertext within the initial validity period, and the ciphertext corresponds to the application server;

[0010] If the hosting system end updates the ciphertext, the updated ciphertext corresponds to the application server end, and the updated ciphertext has an updated validity period. If the updated ciphertext is within the updated validity period and the original ciphertext is within the initial validity period, the hosting system end hosts both the updated ciphertext and the original ciphertext simultaneously.

[0011] Optionally, the hosting system end updates the ciphertext, including:

[0012] The server of the hosting system end updates the ciphertext according to a preset active task;

[0013] Optionally, the hosting system end updates the ciphertext, including:

[0014] The ciphertext is updated by connecting an external device to the PRG interface of the hosting system end.

[0015] Optionally, after the hosting system end updates the ciphertext, it includes:

[0016] The hosting system end pushes the updated ciphertext to the corresponding application server end.

[0017] Optionally, if the hosting system end does not update the ciphertext, after the hosting system end hosts the ciphertext within the initial validity period, it includes:

[0018] The application server end sends a ciphertext application request to the hosting system end. The hosting system end receives and responds to the ciphertext application request, and sends the ciphertext to the corresponding application server end. The ciphertext has an identifier of the requested encryption method;

[0019] The application server end receives the ciphertext, obtains the encryption method according to the identifier, and decrypts the ciphertext using the private key and the encryption method to obtain the plaintext.

[0020] Optionally, if the hosting system end updates the ciphertext, after the hosting system end hosts both the updated ciphertext and the original ciphertext simultaneously, it includes:

[0021] The application server end sends a ciphertext application request to the hosting system end. If the hosting system end hosts both the updated ciphertext and the original ciphertext simultaneously, the hosting system end receives and responds to the ciphertext application request, and sends the updated ciphertext or the original ciphertext to the corresponding application server end. Both the updated ciphertext and the original ciphertext have an identifier of the requested encryption method;

[0022] The application server receives the updated ciphertext or the original ciphertext, obtains the encryption method according to the identifier, and decrypts the updated ciphertext or the original ciphertext by using the private key and the encryption method to obtain the plaintext.

[0023] Optionally, the application server establishing a connection with the hosting system end includes:

[0024] The application server includes a software development kit, and the software development kit connects to the hosting system end to establish a data transmission path between the application server and the hosting system end.

[0025] Optionally, both the hosting system end and the software development kit include encryption method data packets, and the ciphertext has an identifier of the requested encryption method;

[0026] The hosting system end obtains the requested encryption method from the encryption method data packet at the hosting system end according to the encryption method request;

[0027] The application server obtains the encryption method corresponding to the identifier from the encryption method data packet of the software development kit according to the identifier.

[0028] Optionally, the encryption method is a symmetric encryption method or an asymmetric encryption method.

[0029] On the other hand, the present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the method for multi-scenario key hosting as described in any one of the above.

[0030] Compared with the prior art, the method and storage medium for multi-scenario key hosting provided by the present invention at least achieve the following beneficial effects:

[0031] 1. The method and storage medium for multi-scenario key hosting provided by the present invention include: the application server establishing a connection with the hosting system end, the application server sending a key, a key hosting request, and an encryption method request to the hosting system end; the hosting system end receiving the key, the key hosting request, and the encryption method request, the key includes a public key and a private key, the hosting system end responds to the key hosting request, encrypts the key by using the public key according to the requested encryption method to obtain a ciphertext, the ciphertext has an initial validity period, the hosting system end hosts the ciphertext within the initial validity period, and the ciphertext corresponds to the application server. By selecting a specific encryption method for customized processing according to different scenario requirements, the requirements for multi-scenario hosting services can be met.

[0032] 2. The method and storage medium for multi-scenario key escrow provided by the present invention include: If the escrow system updates the ciphertext, the updated ciphertext corresponds to the application server, and the updated ciphertext has an updated validity period. If the updated ciphertext is within the updated validity period and the original ciphertext is within the initial validity period, the escrow system escrows both the updated ciphertext and the original ciphertext. By having multiple versions of the ciphertext valid, the escrow scenario can be made more flexible and the switching can be smoother through multiple-version control, meeting the escrow requirements of some special scenarios. Of course, any product implementing the present invention does not necessarily need to achieve all the above-mentioned technical effects simultaneously.

[0033] Other features and advantages of the present invention will become clear from the following detailed description of the exemplary embodiments of the present invention with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The drawings incorporated in and constituting a part of this specification illustrate embodiments of the present invention and, together with the description, serve to explain the principles of the present invention.

[0035] Figure 1 is a flowchart of a method for multi-scenario key escrow provided by the present invention;

[0036] Figure 2 is another flowchart of a method for multi-scenario key escrow provided by the present invention;

[0037] Figure 3 is yet another flowchart of a method for multi-scenario key escrow provided by the present invention;

[0038] Figure 4 is yet another flowchart of a method for multi-scenario key escrow provided by the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0039] Now, various exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be noted that: Unless otherwise specifically stated, the relative arrangements, numerical expressions, and numerical values of the components and steps set forth in these embodiments do not limit the scope of the present invention.

[0040] The following description of at least one exemplary embodiment is merely illustrative in nature and in no way serves as a limitation on the present invention or its application or use.

[0041] Technologies, methods, and devices known to those of ordinary skill in the relevant art may not be discussed in detail, but where appropriate, the said technologies, methods, and devices should be regarded as part of the specification.

[0042] In all the examples shown and discussed here, any specific values should be construed as merely exemplary and not as a limitation. Thus, other examples of the exemplary embodiments may have different values.

[0043] It should be noted that like reference numerals and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.

[0044] Referring to Figure 1 and Figure 2 , Figure 1 is a schematic flowchart of a method for multi-scenario key escrow provided by the present invention, Figure 2 is another schematic flowchart of the method for multi-scenario key escrow provided by the present invention, to illustrate a specific embodiment of the method for multi-scenario key escrow provided by the present invention, which is applied to an application server and an escrow system, and includes:

[0045] The application server establishes a connection with the escrow system, and the application server sends a key, a key escrow request, and an encryption method request to the escrow system;

[0046] The escrow system receives the key, the key escrow request, and the encryption method request. The key includes a public key and a private key. The escrow system responds to the key escrow request, encrypts the key using the public key according to the requested encryption method to obtain a ciphertext, the ciphertext has an initial validity period, and the escrow system escrows the ciphertext within the initial validity period, and the ciphertext corresponds to the application server.

[0047] It can be understood that the initial validity period of the ciphertext can be from the moment of ciphertext generation to a preset moment. Of course, it is not limited thereto, and the initial validity period can be set according to actual needs, and this embodiment does not make specific limitations thereto. When the ciphertext is within the initial validity period, the ciphertext is valid, and the escrow system escrows the ciphertext; if the ciphertext has exceeded the initial validity period, the ciphertext becomes invalid, and the escrow system no longer escrows the ciphertext. The application server can select the encryption method required by the service for escrow to meet the encryption requirements of the vast majority.

[0048] Compared with the prior art, the method for multi-scenario key escrow provided by this embodiment has at least the following advantages:

[0049] The method for multi-scenario key escrow provided in this embodiment includes: establishing a connection between the application server and the escrow system, and the application server sending a key, a key escrow request, and an encryption method request to the escrow system; the escrow system receiving the key, the key escrow request, and the encryption method request, where the key includes a public key and a private key, the escrow system responding to the key escrow request, encrypting the key using the public key according to the requested encryption method to obtain a ciphertext, the ciphertext having an initial validity period, and the escrow system escrowing the ciphertext within the initial validity period, and the ciphertext corresponding to the application server. By selecting a specific encryption method for customized encryption and decryption processing according to different scenario requirements, the requirements for multi-scenario escrow services can be met.

[0050] In some alternative embodiments, referring to Figure 1 and Figure 3 , Figure 3 is another flowchart of the method for multi-scenario key escrow provided by the present invention. The method for multi-scenario key escrow provided by the present invention further includes:

[0051] If the escrow system updates the ciphertext, the updated ciphertext corresponds to the application server, and the updated ciphertext has an updated validity period. If the updated ciphertext is within the updated validity period and the original ciphertext is within the initial validity period, the escrow system escrows both the updated ciphertext and the original ciphertext.

[0052] It can be understood that when the escrow system updates the ciphertext, the updated ciphertext will not overwrite the original content, but will escrow both the updated ciphertext and the original ciphertext. Of course, this is not limited to this. If the escrow system updates the ciphertext n times, as long as the n updated ciphertexts and the original ciphertext are all within the validity period, the escrow system escrows the n updated ciphertexts and the original ciphertext at the same time, and the n updated ciphertexts and the original ciphertext in escrow become effective at the same time, that is, multiple versions of the ciphertext in the form of tokens coexist. Through the control of multiple versions, the escrow scenario is more flexible and the switching is smoother, meeting the escrow requirements of some special scenarios.

[0053] In some alternative embodiments, the escrow system updating the ciphertext includes:

[0054] The server of the escrow system updates the ciphertext according to a preset active task;

[0055] Or, the ciphertext is updated by connecting an external device to the PRG interface of the escrow system.

[0056] It can be understood that the preset active task can be to update the ciphertext every preset time period. Of course, this is not limited to this. It can also be to update the ciphertext when a preset condition is met, which can be set according to actual needs. This embodiment does not make specific limitations on this.

[0057] In some alternative embodiments, referring to Figure 4 , Figure 4 is another flowchart of the method for multi-scenario key escrow provided by the present invention. After the escrow system end updates the ciphertext, it includes:

[0058] The escrow system end pushes the updated ciphertext to the corresponding application server.

[0059] It can be understood that the escrow system end monitors the changes of the escrow content and actively pushes the updated ciphertext to the corresponding application server. This function realizes the ability to reduce the request pressure of the escrow main service after the increase in the number of clusters, and reduces the latency risk of data inconsistency in the cluster caused by data updates. By actively pushing the changes of the escrow content, the consistency and effectiveness of the data in the cluster are improved, and after the increase in the number of clusters, the main service performance of the escrow system end has no obvious request pressure.

[0060] In some alternative embodiments, continuing to refer to Figure 1 , if the escrow system end does not update the ciphertext, after the escrow system end escrows the ciphertext within the initial validity period, it includes:

[0061] The application server sends a ciphertext application request to the escrow system end. The escrow system end receives and responds to the ciphertext application request, and sends the ciphertext to the corresponding application server. The ciphertext has an identifier of the requested encryption method;

[0062] The application server receives the ciphertext, obtains the encryption method according to the identifier, and decrypts the ciphertext using the private key and the encryption method to obtain the plaintext.

[0063] It can be understood that when the escrow system end encrypts using the specified encryption method and public key to obtain the escrowed ciphertext, and the application server decrypts the ciphertext using the private key, a specific encryption method is still required. Therefore, the ciphertext is marked with the identifier of the requested encryption method, which is convenient for the application server to know the specific encryption method and decrypt it in combination with the private key.

[0064] In some alternative embodiments, continuing to refer to Figure 1 , if the escrow system end updates the ciphertext, after the escrow system end escrows both the updated ciphertext and the original ciphertext, it includes:

[0065] The application server sends a ciphertext application request to the escrow system end. If the escrow system end escrows both the updated ciphertext and the original ciphertext, the escrow system end receives and responds to the ciphertext application request, and sends the updated ciphertext or the original ciphertext to the corresponding application server. Both the updated ciphertext and the original ciphertext have an identifier of the requested encryption method;

[0066] The application server receives the updated ciphertext or the original ciphertext, obtains the encryption method according to the identifier, and decrypts the updated ciphertext or the original ciphertext using the private key and the encryption method to obtain the plaintext.

[0067] It can be understood that as long as the updated ciphertext or the original ciphertext is within its corresponding validity period, it will take effect. Due to factors such as the excessive number of application servers connected to the hosting system side or network latency, the ciphertext issued by the hosting system side in response to the ciphertext application request is sometimes not the latest version of the ciphertext. As long as the issued ciphertext is within the validity period, the application server can use its own private key to decrypt it, ensuring the reliability of key escrow.

[0068] In some alternative embodiments, with continued reference to Figure 2 , establishing a connection between the application server and the hosting system side includes:

[0069] The application server includes a software development kit, and the software development kit connects to the hosting system side to establish a data transmission path between the application server and the hosting system side.

[0070] It can be understood that in this embodiment, the software development kit is an SDK. Of course, it is not limited to this. The SDK establishes a data transmission path between the application server and the hosting system side, so that the ciphertext or the updated ciphertext can be transmitted to the corresponding application server.

[0071] In some alternative embodiments, both the hosting system side and the software development kit include encryption method data packets, and the ciphertext has an identifier of the requested encryption method;

[0072] The hosting system side obtains the requested encryption method from the encryption method data packet on the hosting system side according to the encryption method request;

[0073] The application server obtains the encryption method corresponding to the identifier from the encryption method data packet of the software development kit according to the identifier.

[0074] It can be understood that attaching encryption method data packets to the hosting system side and the software development kit facilitates customized encryption processing according to the requirements of the application server, thereby enabling different encryption methods to be used for different scenarios.

[0075] In some alternative embodiments, the encryption method is a symmetric encryption method or an asymmetric encryption method.

[0076] It is understandable that the symmetric encryption methods are AES, DES, 3DES, etc., and the asymmetric encryption methods are RSA, DSA, ECC, etc. The application server can select a specific symmetric encryption method or a specific non-encryption method according to requirements, that is, the application server can select one of AES, DES, 3DES, RSA, DSA, ECC, etc. as the encryption method to encrypt the secret key, so as to achieve customized encryption.

[0077] Based on the same inventive concept, the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the method for multi-scenario secret key escrow as described in any one of the above embodiments.

[0078] In the above embodiments of the present invention, the descriptions of the respective embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0079] As can be seen from the above embodiments, the method and storage medium for multi-scenario secret key escrow provided by the present invention at least achieve the following beneficial effects:

[0080] 1. For the method and storage medium for multi-scenario secret key escrow provided by the present invention, the application server can select the encryption method required by the service for escrow, meeting the encryption requirements of the vast majority. By selecting a specific encryption method for customized encryption and decryption processing according to different scenario requirements, the needs of multi-scenario escrow services can be met.

[0081] 2. For the method and storage medium for multi-scenario secret key escrow provided by the present invention, through the control of multiple versions, the escrow scenario is more flexible and the switching is smoother, meeting the escrow requirements of some special scenarios.

[0082] 3. For the method and storage medium for multi-scenario secret key escrow provided by the present invention, the escrow system side listens to the change situation of the escrow content and actively pushes the updated ciphertext to the corresponding application server. This function realizes the ability to reduce the request pressure of the main escrow service after the increase in the number of clusters, and reduces the delay risk of data inconsistency in the cluster caused by data updates. By actively pushing the change of the escrow content, the consistency and effectiveness of the data in the cluster are improved, and after the increase in the number of clusters, the performance of the main service of the escrow system side has no obvious request pressure.

[0083] Although some specific embodiments of the present invention have been described in detail by way of examples, those skilled in the art should understand that the above examples are only for the purpose of illustration and not for the purpose of limiting the scope of the present invention. Those skilled in the art should understand that the above embodiments can be modified without departing from the scope and spirit of the present invention. The scope of the present invention is defined by the appended claims.

Claims

1. A method for multi-scenario key escrow, characterized in that: Applied to application servers and hosting systems, including: The application server establishes a connection with the hosting system; The application server sends a secret key, a secret key escrow request and an encryption method request to the escrow system; The hosting system receives the secret key, the secret key hosting request and the encryption method request, wherein the secret key includes a public key and a private key, the hosting system responds to the secret key hosting request, uses the public key to encrypt the secret key according to the requested encryption method to obtain a ciphertext, the ciphertext has an initial validity period, the hosting system hosts the ciphertext within the initial validity period, and the ciphertext corresponds to the application server; If the hosting system updates the ciphertext, the updated ciphertext corresponds to the application server, and the updated ciphertext has an updated validity period. If the updated ciphertext is within the updated validity period and the original ciphertext is within the initial validity period, the hosting system hosts the updated ciphertext and the original ciphertext at the same time.

2. The multi-scenario key escrow method according to claim 1, characterized in that: The hosting system updates the ciphertext, including: The server at the hosting system end updates the ciphertext according to a preset active task.

3. The method for multi-scenario key escrow according to claim 1, characterized in that: The hosting system updates the ciphertext, including: The ciphertext is updated by connecting an external device to the PRG interface of the hosting system.

4. The method for multi-scenario key escrow according to claim 1, characterized in that: After the hosting system updates the ciphertext, it includes: The hosting system side pushes the updated ciphertext to the corresponding application server side.

5. The method for multi-scenario key escrow according to claim 1, characterized in that: If the hosting system does not update the ciphertext, the hosting system, after hosting the ciphertext within the initial validity period, includes: The application server sends a ciphertext application request to the hosting system, the hosting system receives and responds to the ciphertext application request, and sends the ciphertext to the corresponding application server, the ciphertext having an identifier of the requested encryption method; The application server receives the ciphertext, obtains the encryption method according to the identifier, and decrypts the ciphertext using the private key and the encryption method to obtain plaintext.

6. The method for multi-scenario key escrow according to claim 1, characterized in that: If the hosting system updates the ciphertext, the hosting system hosts the updated ciphertext and the original ciphertext at the same time, including: The application server sends a ciphertext application request to the hosting system. If the hosting system hosts both the updated ciphertext and the original ciphertext, the hosting system receives and responds to the ciphertext application request, and sends the updated ciphertext or the original ciphertext to the corresponding application server. Both the updated ciphertext and the original ciphertext have the identifier of the requested encryption method. The application server receives the updated ciphertext or the original ciphertext, obtains the encryption method according to the identifier, and decrypts the updated ciphertext or the original ciphertext using the private key and the encryption method to obtain plaintext.

7. The method for multi-scenario key escrow according to claim 1, characterized in that: The application server establishes a connection with the hosting system, including: The application server includes a software development kit, which is connected to the hosting system to establish a data transmission path between the application server and the hosting system.

8. The method for multi-scenario key escrow according to claim 7, characterized in that: The hosting system end and the software development kit both contain an encryption mode data packet, and the ciphertext has an identification of the encryption mode requested; The hosting system end obtains the requested encryption mode in the encryption mode data packet of the hosting system end according to the encryption mode request; The application server obtains the encryption method corresponding to the identifier from the encryption method data packet of the software development kit according to the identifier.

9. The method for multi-scenario key escrow according to claim 1, characterized in that: The encryption method is a symmetric encryption method or an asymmetric encryption method.

10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor, the method for multi-scenario key custody as described in any one of claims 1 to 9 is implemented.

Images