Method of backing up a key and method of restoring a key

Abstract

This specification provides a method for backing up a key, comprising: deriving a hardware key based on a system state metric stored in the Platform Configuration Register (PCR) of a Trusted Platform Module (TPM); performing a first encryption and a second encryption on the target key to obtain a first ciphertext; performing the first encryption using the hardware key in the TPM, and performing the second encryption using a white-box encryption software module; and exporting the first ciphertext to obtain backup data of the target key.

Description

Technical Field

[0001] This specification relates to the field of privacy protection technology in one or more embodiments, and in particular to a method for backing up a key and a method for recovering a key. Background Technology

[0002] Enterprises often store sensitive data on their servers that requires privacy protection. To protect this data, enterprises typically encrypt it using encryption keys before storing it. These encryption keys are usually stored in the server's Hardware Security Module (HSM), but the keys stored in the HSM can be lost due to hardware failures or other reasons.

[0003] There is a lack of a solution in the relevant technologies for backing up keys while ensuring key security. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide a method for backing up a key and a method for recovering a key.

[0005] According to a first aspect of one or more embodiments of this specification, a method for backing up a key is provided, comprising:

[0006] The hardware key is derived from the system state metric stored in the Platform Configuration Register (PCR) in the Trusted Platform Module (TPM).

[0007] The target key is encrypted first and second to obtain the first ciphertext; the first encryption is performed in the TPM using the hardware key, and the second encryption is performed using the white-box encryption software module.

[0008] Export the first ciphertext to obtain backup data of the target key.

[0009] According to a second aspect of one or more embodiments of this specification, a method for recovering a key is provided, comprising:

[0010] Receive the first encrypted text imported;

[0011] The hardware key is derived from the system state metric stored in the PCR of the TPM; the hardware key is derived from the metric stored in the PCR of the TPM.

[0012] The first ciphertext is decrypted in a first and second manner. The first ciphertext is decrypted twice based on the hardware key and the software key to obtain the target key. The first decryption is performed in TPM using the hardware key, and the second decryption is performed using the white-box encryption software module.

[0013] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the method described in the first or second aspect of the embodiments of this specification.

[0014] According to a fourth aspect of the embodiments of this specification, a computer device is provided, the computer device comprising:

[0015] processor;

[0016] Memory used to store processor-executable instructions;

[0017] The processor executes the executable instructions to implement the method as described in the first or second aspect of the embodiments of this specification.

[0018] According to a fifth aspect of the embodiments of this specification, a computer program product is provided that, when executed by a processor, implements the method described in the first or second aspect of the embodiments of this specification.

[0019] This specification provides a method for backing up keys. By performing software and hardware encryption on the target key, key security is ensured while key backup is achieved. Furthermore, hardware encryption uses a hardware key derived from a metric value. Since the metric value reflects the current state of the computer device, hardware encryption binds the target key to the current metric value. This ensures that the hardware key can only be obtained on the current computer, preventing other devices from decrypting the target key, thus improving the security and reliability of hardware encryption. Software encryption employs a white-box encryption algorithm. White-box encryption algorithms are a type of encryption implementation that, even when the key and algorithm implementation are completely exposed to attackers, still strives to protect the key from direct extraction. Compared to ordinary encryption algorithms, it "embeds and obfuscates" the key in the code and lookup table, making it difficult to directly obtain the plaintext key even if the program is completely cracked. By using a white-box encryption algorithm, even if the server is controlled by an attacker, the attacker cannot obtain the plaintext key and therefore cannot decrypt it, further increasing the security of the software encryption.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0022] Figure 1 This is a diagram illustrating the use of a master key.

[0023] Figure 2 This is a flowchart of a method for backing up keys.

[0024] Figure 3 This is a schematic diagram of a method for backing up keys.

[0025] Figure 4 This is a flowchart of a method for recovering a key.

[0026] Figure 5 A diagram illustrating a method for recovering a key.

[0027] Figure 6 It is a hardware structure diagram of a computer device. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0029] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0030] Enterprise servers often store a lot of sensitive data, such as important documents and user account logins. To protect the security of sensitive data, it needs to be encrypted before storage. Furthermore, to enhance security, different business units within an enterprise often use different business keys for encryption.

[0031] like Figure 1 As shown, different business keys are generally derived from a master key. Specifically, an enterprise's server hardware security module (HSM) can generate a master key using a random number generator and derive different business keys based on different derivation parameters. The HSM is a hardware device responsible for key generation, storage, and signature verification.

[0032] In an alternative implementation, such as Figure 1 As shown, the Trusted Platform Module (TPM) can be used to generate keys. The TPM is a standalone security chip used to securely generate, store, and use sensitive data such as keys within the device. Unlike other HSMs, the TPM has a Platform Configuration Register (PCR). The PCR is a register in the TPM used to store platform (computer) status metrics. The PCR stores the "metric results" of system startup and critical components, which are the accumulated values ​​after hashing code or data from the Basic Input / Output System (BIOS), bootloader, kernel, and critical configurations.

[0033] TPM can achieve sealing through PCR, an encryption process that binds a key to a specific platform state. Specifically, TPM can derive a hardware key from the metrics stored in the PCR and use this hardware key to encrypt the data to complete the sealing.

[0034] In TPM, the master key is typically encrypted using the aforementioned hardware key and stored in the TPM's storage area. However, hardware failure may lead to the loss of the master key in the TPM, or changes in platform status may prevent the retrieval of the hardware key, thus making it impossible to decrypt the stored master key.

[0035] Therefore, this specification provides a method for backing up keys. By performing software and hardware encryption on the target key, key backup is achieved while ensuring key security.

[0036] Furthermore, hardware encryption uses a hardware key derived from a metric value. Since the metric value reflects the current state of the computer device, hardware encryption binds the target key to the current metric value. This ensures that the hardware key can only be obtained within the current computer, preventing other devices from decrypting the target key and improving the security and reliability of hardware encryption.

[0037] The software encryption uses a white-box encryption algorithm. A white-box encryption algorithm is a type of encryption implementation that, while fully exposing the key and algorithm implementation to the attacker, still strives to protect the key from direct extraction. Compared to ordinary encryption algorithms, it "embeds and obfuscates" the key within the code and lookup tables, making it difficult to directly obtain the plaintext key even if the program is completely cracked.

[0038] By using white-box encryption algorithms, even if the server is controlled by an attacker, the attacker cannot obtain the plaintext key and therefore cannot decrypt it, which further increases the security of software encryption.

[0039] Next, we will combine Figure 2 This manual describes a method for backing up a key. For example... Figure 2 As shown, it includes the following steps:

[0040] Step 201: Derive the hardware key based on the system state metric stored in the PCR in the TPM.

[0041] In an optional implementation, the software encryption method mentioned above in this specification can be applied to the virtualization layer (hypervisor, also known as a virtual machine monitor). In other words, the white-box encryption software module used to perform software encryption is set in the virtualization layer hypervisor. Since the virtualization layer can take over physical memory management and utilize hardware virtualization mechanisms to divide physical memory into mutually invisible and inaccessible "virtual memory views," which are provided to each virtual machine, the virtualization layer, and the host machine respectively. Therefore, memory isolation can be achieved through the virtualization layer, preventing the host machine from accessing the virtualization layer's memory space. Thus, performing software encryption in the virtualization layer improves encryption security.

[0042] When the software encryption method described in this specification is applied to the virtualization layer, such as... Figure 3 As shown, in step 1, TPM can measure the state of the virtualization layer and store the measured values ​​in PCR. Further, according to... Figure 3 In step 2 of the process, TPM can derive the hardware key based on the metric values ​​stored in PCR.

[0043] It should be noted that, Figure 3 Solid lines represent actual modules or components in a computer, while dashed lines represent data processed within the computer.

[0044] Furthermore, for the target key that needs to be backed up in this specification, in an optional implementation, it can be the master key mentioned above. Since the business key can be derived from the master key, to reduce storage, only the master key can be backed up. When a business key is required, it can be derived from the master key. Of course, the above examples do not represent a limitation of this specification, and other keys can also be used as the target key.

[0045] Regarding the method of obtaining the target key, in one optional implementation, after the target key is generated, it can be stored in the non-volatile (NV) storage area of ​​the TPM. The data stored in the NV storage area can be data encrypted with the aforementioned hardware key, which improves security. In this case, the target key can be obtained from the NV storage area.

[0046] In another alternative implementation, the target key can be backed up immediately after generation, meaning it is not stored on the current computer. If the target key is needed, it can be restored from the backup data. After use, the target key is deleted from the current computer.

[0047] Since an attacker might gain control of the host machine, which can obtain PCR metrics by calling the TPM's interface, and can also call the TPM's data acquisition interface to decrypt data stored in the NV memory using the hardware key derived from the metrics, thereby obtaining the target key, the attack would not be able to obtain the target key stored in the TPM even if the attacker gains control of the host machine. This improves the security of the target key.

[0048] In other words, if the target key is the master key, such as Figure 3 As shown, the process of obtaining the target key may include Figure 3 Step 3 involves obtaining the master key derived from the TPM's random number generator and using it as the target key.

[0049] Step 203: Perform first encryption and second encryption on the target key respectively to obtain the first ciphertext.

[0050] The first encryption is performed in the TPM using the hardware key, and the second encryption is performed using a white-box encryption software module.

[0051] Specifically, the target key needs to be encrypted using both software and hardware to obtain the first ciphertext.

[0052] The first encryption refers to hardware encryption. As mentioned earlier, hardware encryption is also known as sealing. Sealing refers to the encryption process of binding a key to a specific platform state. Through hardware encryption, the target key can be bound to the current computer state, thus ensuring that only the current computer can decrypt and obtain the target key.

[0053] The second type of encryption refers to software encryption, which is encryption using white-box encryption software modules.

[0054] Regarding the order of hardware encryption and software encryption, in one optional implementation, hardware encryption can be performed first, followed by software encryption. In other words, the first encryption includes: the TPM encrypts the target key stored in the TPM using the hardware key to obtain a second ciphertext; the second encryption includes: encrypting the second ciphertext using the white-box encryption software module to obtain a first ciphertext.

[0055] In another alternative implementation, software encryption can be performed first, followed by hardware encryption. In other words, the second encryption includes: encrypting the target key using a white-box encryption software module to obtain a third ciphertext; the first encryption includes: the TPM encrypting the third ciphertext using the hardware key to obtain a first ciphertext.

[0056] Specifically, when software encryption is performed by a virtual machine, such as Figure 3 As shown, step 4 can be executed first, using the white-box encryption software module to encrypt the target key to obtain the third ciphertext block (the meaning of the ciphertext block is the same as the ciphertext). Then, step 5 is executed, where the TPM can use the hardware key to encrypt the third ciphertext block to obtain the first ciphertext block. Figure 3 The hardware encryption process can be achieved by the virtualization layer calling the TPM's encryption interface, so that the TPM can use the hardware key for encryption.

[0057] It should be noted that, Figure 3 Although the plaintext of the target key is exported to the virtualization layer, the memory isolation mechanism of the virtualization layer prevents attackers from accessing the plaintext of the target key through memory access, even if they gain control of the host machine. This execution through the virtualization layer enhances the security of the encryption process. Furthermore, executing white-box encryption algorithms (i.e., algorithms executed by white-box encryption software modules) through the virtualization layer increases the difficulty for attackers to crack white-box encryption algorithms, further improving the security of the target key.

[0058] Step 205: Export the first ciphertext to obtain backup data of the target key.

[0059] After obtaining the first ciphertext, the backup data of the target key (the first ciphertext) can be exported and stored. The ciphertext can be exported to any storage device, such as [specific storage location]. Figure 3 The database shown.

[0060] When software encryption is performed by a virtualization layer, such as Figure 3 As shown, step 205 can first be executed. Figure 3 Step 6 exports the first ciphertext from the virtualization layer to the host's application layer. Then, step 7 is executed, where the application layer's backup tool backs up the first ciphertext to the database.

[0061] In one optional implementation, a first ciphertext packet corresponding to the first ciphertext can be exported. Besides the first ciphertext, the first ciphertext packet may also include data such as a checksum generated based on the first ciphertext, a timestamp, and the length of the first ciphertext. This allows verification through these data to determine whether the first ciphertext has been modified due to hardware issues during storage, thus ensuring the correctness of the first ciphertext. This process can be performed by an application-layer backup tool.

[0062] The verification here can use a CRC32 checksum. CRC checksum is a cyclic redundancy check mechanism based on polynomial operations, used to detect whether errors occur in data during transmission or storage. CRC32 is a CRC checksum algorithm that uses a 32-bit checksum (polynomial length is 32 bits) and is commonly used in network protocols, file integrity verification, and other scenarios.

[0063] Since the host machine can obtain the PCR metric value and thus the hardware key by calling the TPM interface, to prevent attackers from using the hardware key to decrypt the first ciphertext and obtain the target key, in an optional implementation, after the computer starts up and the PCR stored metric value has been used (e.g., using the hardware key derived from the metric value to encrypt the target key), the metric value stored in the PCR can be modified. If the PCR metric value is not needed after startup, it can be modified immediately. Conversely, if the PCR metric value is still needed, a restart can be performed to update the PCR metric value. After restarting, the metric value is modified after it has been used.

[0064] In other words, when software encryption is performed by the virtualization layer, the aforementioned metrics are used to characterize the state of the virtualization layer at the moment of startup completion. Correspondingly, after executing step 205, the virtualization layer can also call the interface of the TPM's extended PCR to modify the metrics stored in the PCR.

[0065] In PCR, the metric value uses an "extend" mechanism, meaning it can only be updated once with a new hash based on the original value, thus preventing rollback or arbitrary overwriting. The extended PCR interface provided by TPM allows you to pass a new metric hash to a specified PCR register, and TPM performs a hash extension on the current PCR metric value and writes back the result.

[0066] The PCR includes multiple registers, each storing different metrics. In one optional implementation, the metrics used to generate the hardware key can be from multiple registers, such as PCR0-9 and PCR12. Correspondingly, during PCR expansion, only the metric in one register needs to be modified, for example, modifying the metric stored in PCR12.

[0067] Because the PCR metric cannot be rolled back, even if an attacker gains control of the host machine, they cannot update the metric to bring it back to a normal state, thus preventing the attacker from obtaining the hardware key while controlling the host machine.

[0068] and Figure 2 Corresponding to the methods shown, this specification also illustrates a method for recovering a key, such as... Figure 4 As shown, it includes:

[0069] Step 401: Receive the imported first ciphertext.

[0070] Specifically, it can receive backup data of the target key.

[0071] In one alternative implementation, the received first ciphertext can be stored in the form of a first ciphertext packet mentioned above. The correctness of the first ciphertext can then be verified using the check value in the first ciphertext packet. If the verification passes, the first ciphertext is received.

[0072] In other words, step 401 may include receiving an imported first ciphertext packet; the first ciphertext packet includes a first ciphertext and a check value, the check value being generated based on the first ciphertext; the first ciphertext of the first ciphertext packet is verified using the check value, and if the verification determines that the first ciphertext has not been modified, the first ciphertext is received.

[0073] This ensures the accuracy of the received first ciphertext and prevents the recovery of an incorrect target key from an incorrect first ciphertext.

[0074] Furthermore, when equipped with a virtualization layer, such as Figure 5 As shown, step 1 can be executed first, where the application-layer backup tool receives the first ciphertext stored in the external database. Then, step 2 is executed, where the application layer imports the first ciphertext into the virtualization layer, and the virtualization layer stores the first ciphertext in a non-volatile storage area. For example, it might receive the imported first ciphertext and store it in the non-volatile NV storage area of ​​the TPM. Here, the first ciphertext can be stored in the NV storage area without encryption. Correspondingly, in an optional implementation, after executing step 405, the first ciphertext stored in the NV storage area can be deleted.

[0075] Among them, with Figure 3 similar, Figure 5 Solid lines represent actual modules or components in a computer, while dashed lines represent data processed within the computer.

[0076] The reason for storing the first ciphertext in the NV storage area before the decryption step is that, as mentioned earlier, the virtualization layer needs to prevent attackers from obtaining the hardware key and then decrypting the first ciphertext stored in the external storage area. During operation, the correct metric value cannot be directly obtained, thus preventing the acquisition of the hardware key for decryption. Therefore, it is necessary to persistently store the first ciphertext before restarting the virtualization layer to measure the state of the virtualization layer after the restart, and then re-store the new metric value in the PCR of the restarted TPM.

[0077] Step 403: Derive the hardware key based on the system state metric stored in the PCR in the TPM.

[0078] The implementation method for this step is the same as that for step 201, and will not be repeated here.

[0079] In one alternative implementation, as described above, the virtualization layer modifies the metric in the PCR. In this case, to obtain the correct metric, the virtualization layer can be restarted; the TPM measures the state of the virtualization layer at the time of restart and stores the measured metric in the PCR; the TPM derives the hardware key based on the metric stored in the PCR.

[0080] In other words, such as Figure 3 As shown, the virtualization layer state at the time of restart completion is measured in step 3, and the hardware key is obtained in step 4 using the measurement value stored in PCR.

[0081] Step 405: Perform first decryption and second decryption on the first ciphertext to obtain the target key.

[0082] The first decryption is performed in the TPM using the hardware key, and the second decryption is performed using a white-box encryption software module.

[0083] The first decryption, corresponding to the first encryption, refers to the hardware decryption process. This process is also called unseal, which is the process of verifying the platform status and decrypting the key. The second decryption, corresponding to the second encryption, refers to the software decryption process, which uses a white-box encryption software module to decrypt the encryption using the corresponding decryption algorithm.

[0084] The order of the first decryption and the second decryption is related to the order of the first encryption and the second encryption.

[0085] In one alternative implementation, during encryption, a first encryption is performed first, followed by a second encryption. Therefore, during decryption, the second decryption is performed first, followed by the first decryption.

[0086] In other words, the second decryption includes: using a white-box encryption software module to decrypt the target key to obtain the second ciphertext; the first decryption includes: the TPM using the hardware key to decrypt the second ciphertext to obtain the target key.

[0087] In another alternative implementation, during encryption, such as Figure 3 As shown, the second encryption was performed first, followed by the first encryption. Therefore, during decryption, as follows... Figure 5 As shown, first execute step 5 to perform the first decryption (hardware decryption), then execute step 6 to perform the second decryption (software decryption).

[0088] In other words, the first decryption includes: the TPM using the hardware key to decrypt the first ciphertext to obtain the third ciphertext; the second decryption includes: using a white-box encryption software module to decrypt the third ciphertext to obtain the target key.

[0089] In an alternative implementation, as described above, after the virtualization layer has started up and completed what needs to be done using the hardware key, the virtualization layer can call the interface of the TPM's extended PCR to modify the metric stored in the PCR.

[0090] In this way, since the PCR metric value is immediately changed after startup, attackers cannot obtain the accurate metric value, and therefore cannot obtain the hardware key. This increases the reliability of the first ciphertext.

[0091] This specification also provides a device for backing up a key, comprising:

[0092] The hardware key derivation module is used to derive hardware keys based on the system state metrics stored in the Platform Configuration Register (PCR) of the Trusted Platform Module (TPM).

[0093] An encryption module is used to perform a first encryption and a second encryption on the target key to obtain a first ciphertext; the first encryption is performed in the TPM using the hardware key, and the second encryption is performed using a white-box encryption software module.

[0094] The export module is used to export the first ciphertext, obtaining backup data of the target key.

[0095] This specification also provides a device for a recovery key, comprising:

[0096] The import module is used to receive the first encrypted text to be imported;

[0097] The hardware key derivation module is used to derive the hardware key based on the system state metric stored in the PCR in the TPM.

[0098] The decryption module is used to perform a first decryption and a second decryption on the first ciphertext to obtain the target key; the first decryption is performed in the TPM using the hardware key, and the second decryption is performed using the white-box encryption software module.

[0099] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0100] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0101] like Figure 6 As shown, Figure 6 A hardware structure diagram of an embodiment of a computer device is shown. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are internally connected to each other via the bus 1050.

[0102] In addition, the computer device may also include a TPM (not shown in the figure) for hardware encryption and hardware decryption.

[0103] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification. The processor implements the above-described methods by running executable instructions.

[0104] The memory 1020 for storing processor-executable instructions can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1020.

[0105] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0106] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0107] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0108] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0109] This specification also provides a computer program product that, when executed by a processor, implements the above-described method for backing up a key or method for restoring a key.

[0110] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method for backing up a key or method for restoring a key.

[0111] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0112] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0113] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0114] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

Claims

1. A method for backing up a key, comprising: The hardware key is derived from the system state metric stored in the Platform Configuration Register (PCR) in the Trusted Platform Module (TPM). The target key is encrypted first and second to obtain the first ciphertext; the first encryption is performed in the TPM using the hardware key, and the second encryption is performed using the white-box encryption software module. Export the first ciphertext to obtain backup data of the target key.

2. The method according to claim 1, wherein, The first encryption includes: the TPM encrypts the target key stored in the TPM using the hardware key to obtain the second ciphertext; The second encryption includes: encrypting the second ciphertext using the white-box encryption software module to obtain the first ciphertext.

3. The method according to claim 1, wherein, The second encryption includes: encrypting the target key using a white-box encryption software module to obtain the third ciphertext; The first encryption includes: the TPM using the hardware key to encrypt the third ciphertext to obtain the first ciphertext.

4. The method according to claim 1, wherein, The white-box encryption software module is located in the virtualization layer Hypervisor.

5. The method according to claim 4, wherein the metric is used to characterize the state at the time the virtualization layer completes startup; After exporting the first ciphertext and obtaining backup data for the target key, the process further includes: The virtualization layer calls the interface of TPM's extended PCR to modify the metrics stored in the PCR.

6. The method according to claim 1, further comprising: Obtain the master key derived from the TPM random number generator and use it as the target key.

7. A method for recovering a key, comprising: Receive the first encrypted text imported; The hardware key is derived from the system state metric stored in the PCR in the TPM; The first ciphertext is decrypted in the first and second steps to obtain the target key; the first decryption is performed in the TPM using the hardware key, and the second decryption is performed using the white-box encryption software module.

8. The method according to claim 7, wherein, The first decryption includes: the TPM using the hardware key to decrypt the first ciphertext to obtain the third ciphertext; The second decryption includes: using a white-box encryption software module to decrypt the third ciphertext to obtain the target key.

9. The method according to claim 7, wherein, The second decryption includes: using a white-box encryption software module to decrypt the target key to obtain the second ciphertext; The first decryption includes: the TPM using the hardware key to decrypt the second ciphertext to obtain the target key.

10. The method according to claim 7, wherein, The white-box encryption software module is located in the virtualization layer.

11. The method according to claim 10, wherein the metric is used to characterize the state at the time the virtualization layer completes startup; After obtaining the target key, the following is also included: The virtualization layer calls the interface of TPM's extended PCR to modify the metrics stored in the PCR.

12. The method of claim 11, wherein receiving the imported first ciphertext comprises: Accept the imported first ciphertext and store it in the non-volatile NV storage area of ​​TPM; The process of deriving the hardware key based on the metric values ​​stored in the TPM's PCR includes: The virtualization layer is restarted; TPM measures the state of the virtualization layer at the moment of restart completion and stores the measured values ​​in PCR; TPM derives the hardware key based on the metric values ​​stored in PCR.

13. The method according to claim 7, wherein, The first ciphertext received includes: Receive the imported first ciphertext packet; the first ciphertext packet includes a first ciphertext and a check value, the check value being generated based on the first ciphertext; The first ciphertext of the first ciphertext packet is verified using the verification value. If the verification confirms that the first ciphertext has not been modified, the first ciphertext is received.

14. A computer device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-13 by executing the executable instructions.

Images