CN118041518A - Key protection method, device, system and storage medium - Google Patents

Abstract

The application provides a key protection method, a device, a system and a storage medium, which are applied to a first virtual machine, wherein the first virtual machine comprises a first trusted execution environment, and the method comprises the following steps: reading key encryption information from a disk; the key encryption information is obtained by encrypting a private key of the first encryption key according to the second encryption key; determining a decryption random number and generating a new second encryption key according to the decryption random number; the key encryption information is decrypted using the new second encryption key to determine the private key of the first encryption key. Therefore, the key encryption information can be decrypted without additionally inputting a password by a user, and the security of the service key in the disc dropping process is improved.

Description

Key protection method, device, system and storage medium

Technical Field

The present application relates to the field of network information security technologies, and in particular, to a method, an apparatus, a system, and a storage medium for protecting a key.

Background

The trusted execution environment (Trusted Execution Environment, TEE) is a secure environment that builds a protected data run through the hardware CPU. For an application program, the TEE is a content container with a very high security coefficient, and mainly stores sensitive data and codes generated in the application program, and meanwhile, confidentiality and integrity of the data can be guaranteed.

For private computing platforms, secure management of traffic keys in the TEE is critical. To avoid that the service key is not lost after the server is restarted, the service key is generally temporarily stored in the disk. To prevent key leakage, which typically requires the TEE to encrypt before writing the key to disk, many TEEs currently support encrypted storage, but some TEE technologies do not provide encrypted storage, which may result in the service keys in the TEE being decrypted during the doffing process, creating a security risk.

Disclosure of Invention

The application mainly provides a key protection method, a device, a system and a storage medium, which can increase the security of a service key in the process of disc dropping through a probability recovery method of the service key under the condition that a user does not need to additionally input a password.

The technical scheme of the application is realized as follows:

In a first aspect, an embodiment of the present application provides a key protection method, applied to a first virtual machine, where the first virtual machine includes a first trusted execution environment, the method includes:

reading key encryption information from a disk; the key encryption information is obtained by encrypting a private key of the first encryption key according to the second encryption key;

Determining a decryption random number and generating a new second encryption key according to the decryption random number;

The key encryption information is decrypted using the new second encryption key to determine the private key of the first encryption key.

In a second aspect, an embodiment of the present application provides a key protection method, which is applied to a second virtual machine, where the second virtual machine includes a second trusted execution environment, and the second virtual machine is in communication connection with the first virtual machine; the method comprises the following steps:

When a key resetting request sent by the first virtual machine is not received, reading an encryption service key from a disk, and sending the encryption service key to the first virtual machine;

Performing key negotiation with the first virtual machine to determine a target key;

Receiving an encrypted service key sent by a first virtual machine based on the response of the first virtual machine to the encrypted service key;

and decrypting the encrypted service key according to the target key to obtain the target service key.

In a third aspect, an embodiment of the present application provides a first key protection apparatus, including:

The reading unit is configured to read key encryption information from the magnetic disk, wherein the key encryption information is obtained by encrypting a private key of the first encryption key according to the second encryption key;

a generation unit configured to determine a decryption random number and generate a new second encryption key based on the decryption random number;

And a decryption unit configured to decrypt the key encryption information using the new second encryption key, and determine a private key of the first encryption key.

In a fourth aspect, an embodiment of the present application provides a second key protection apparatus, including:

The sending unit is configured to read the encryption service key from the disk and send the encryption service key to the first virtual machine when the key resetting request sent by the first virtual machine is not received;

the determining unit is configured to carry out key negotiation with the first virtual machine and determine a target key;

The sending unit is further configured to receive the encrypted service key sent by the first virtual machine based on the response of the first virtual machine to the encrypted service key;

the determining unit is further configured to decrypt the encrypted service key according to the target key to obtain the target service key.

In a fifth aspect, an embodiment of the present application provides a key protection system, including:

The system comprises a first virtual machine and a second virtual machine, wherein the first virtual machine is in communication connection with the second virtual machine;

a first virtual machine for performing the steps of the key protection method as described in the first aspect;

a second virtual machine for performing the steps of the key protection method as described in the second aspect.

In a sixth aspect, embodiments of the present application provide a computer readable storage medium, which when executed by a processor, implements the steps of the key protection method as described in the first aspect, or the steps of the key protection method as described in the second aspect.

The application provides a key protection method, a device, a system and a storage medium, wherein a first trusted execution environment can encrypt a private key of a first encryption key by using a generated second encryption key, and can also generate a new second encryption key by using a decryption random number generated in the first trusted execution environment to decrypt key encryption information to obtain the private key of the first encryption key. Therefore, encryption and decryption of the key encryption information are carried out in the first trusted execution environment, and the user does not need to additionally memorize the key, so that a malicious attacker is prevented from acquiring a password by monitoring keyboard input of the user, and the security of the key in the disc dropping process is improved on the premise of ensuring successful recovery of the key.

Drawings

Fig. 1 is a schematic flow chart of a key protection method according to an embodiment of the present application;

fig. 2 is a second schematic step flow diagram of a key protection method according to an embodiment of the present application;

fig. 3 is a second schematic step flow diagram of a key protection method according to an embodiment of the present application;

fig. 4 is a schematic step flow diagram of a key protection method according to an embodiment of the present application;

Fig. 5 is a detailed flowchart of a key protection method according to an embodiment of the present application;

fig. 6 is a schematic step flow diagram of a key protection method according to an embodiment of the present application;

Fig. 7 is a detailed interaction flow diagram of a key protection method according to an embodiment of the present application;

fig. 8 is a schematic diagram of a composition structure of a key protection system according to an embodiment of the present application;

Fig. 9 is a schematic diagram of a composition structure of a first key protection device according to an embodiment of the present application;

Fig. 10 is a schematic diagram of a composition structure of a second key protection device according to an embodiment of the present application;

Fig. 11 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application.

Detailed Description

For a more complete understanding of the nature and the technical content of the embodiments of the present application, reference should be made to the following detailed description of embodiments of the application, taken in conjunction with the accompanying drawings, which are meant to be illustrative only and not limiting of the embodiments of the application.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the application only and is not intended to be limiting of the application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is to be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with one another without conflict.

It should also be noted that the term "first\second\third" in relation to embodiments of the present application is used merely to distinguish similar objects and does not represent a particular ordering for the objects, it being understood that the "first\second\third" may be interchanged in a particular order or sequence, where allowed, to enable embodiments of the present application described herein to be practiced in an order other than that illustrated or described herein.

TEE technology is a security technology based on hardware isolation that ensures confidentiality and security of code executing in a separate area by providing that area at the chip level for code execution, which separate area cannot be obtained from the software and hardware level by other programs. Based on such features, TEEs are typically used to run high security-requiring privacy computing platforms.

The TEE is a trusted execution environment, and includes a TEE root key that is invisible to a custom program running in the TEE, and can only be used in a TEE related function interface, so the TEE root key is invisible to the outside. Currently, TEE technology also adds a key derivation function, i.e., using a TEE root key and a random number, a new key is generated using a key derivation algorithm such as a Hash-based Message Authentication Code (HMAC) message authentication code. Since the new key is generated in the TEE and the TEE root key is not visible to the outside, if the program running in the TEE has no vulnerability, the generated new key is also not visible to the outside.

Key management functions are critical to the privacy computing platform, which provide symmetric keys, asymmetric keys, for various algorithm components in the privacy computing platform, which are known as business keys, for use in a wide variety of algorithms, such as federal learning, multiparty Secure computing (MPC), etc. The key management function has various implementation manners, wherein the service key is stored in the TEE, and even the TEE participates in the service key negotiation process, so that better security assurance is provided for the key management function, and the TEE ensures that the key stored in a security area cannot be revealed or tampered. Meanwhile, in order to ensure that the server can be quickly recovered after abnormal restarting and abnormal exit of software, the TEE is generally required to store a service key in a safe area of the server in a disk for a period of time, and when the key is not used any more, the backup of the key in the disk is deleted.

Storing the service key in the TEE to disk in order to prevent key leakage requires the TEE to encrypt before writing the key to disk, many TEEs currently support the encryption storage function, but some TEE techniques do not provide the encryption storage function, i.e., confidential data in the TEE is decrypted during the disk drop. This feature means that when the TEE is used to implement key management, the service key used by the private computing platform will be stored in the disk in the clear, and security features such as leakage prevention and tamper resistance brought by the TEE will be disabled, which is not acceptable for the private computing platform.

In one possible implementation manner, the related art proposes a concept for solving the problem, specifically, a root key is solidified in a program, encryption is performed by using the root key before the TEE writes the service key into the hard disk, so as to achieve the effect of encrypting the dropped disc by using the service key, and when the service key needs to be restored to a security area in the TEE, the service key after encryption read from the disk is decrypted by using the root key.

In another possible implementation, the related art proposes another idea to solve this problem, specifically using two TEEs and an asymmetric encryption technology, where TEE B is used to generate an asymmetric key (hereinafter referred to as encryption key 1), TEE a generates a service key and encrypts the service key using the public key in encryption key 1 and then falls down, and when TEE a restarts to read the encrypted service key from the disk and then sends it to TEE B, TEE B decrypts it using the private key of encryption key 1, so as to complete service key recovery. The encryption key 1 in TEE B still needs to be processed so that TEE a can perform the key recovery process, one method is for the user to enter a password when TEE B is started, and then TEE B encrypts the private key in encryption key 1 using the password and falls on the disk. When the TEE B needs to perform key recovery, the user is required to input a password and encrypt the encrypted data in the disk using the password, completing the key recovery process.

While curing a root key in a program may solve the problem in TEE key recovery, this approach introduces a potential security problem in that curing a key in a program means that a malicious attacker may find the root key in the binary file of the stored program, which may create a significant security problem for the encrypted traffic key in disk. While using two TEEs and asymmetric encryption techniques requires the user to provide a user password for key encryption, once the user forgets the password or makes an error in the input process, the key cannot be decrypted. Meanwhile, the TEE cannot protect keyboard input, and once the server where the TEE B is located is knocked into the notch and the keyboard input of the server is monitored, a user password can be easily obtained, so that great safety risk is brought to key management.

Based on the technical problems described above, the embodiment of the present application provides a key protection method, which can encrypt a private key of a first encryption key by using a second encryption key in a first trusted execution environment to obtain key encryption information, and generate a new second encryption key by using a decryption random number during decryption, thereby realizing probability recovery of key encryption information and obtaining the private key of the first encryption key. Therefore, through the probability recovery mode of the key, a user does not need to memorize an additional key or password in the decryption process, a malicious attacker is prevented from acquiring the password by monitoring keyboard input, and the security in the key disc dropping process is improved.

The application is further described in detail below with reference to the accompanying drawings and specific examples.

Fig. 1 is a flowchart illustrating steps of a key protection method according to an embodiment of the present application, where the method is applied to a first virtual machine, and the first virtual machine includes a first trusted execution environment.

The first virtual machine may be a complete computer system running on a server, simulated by software, with complete hardware system functions, and running in a completely isolated environment. It should be noted that, in some cases, the first virtual machine may also be a physical computer.

The first trusted execution environment, hereinafter also referred to as TEE B, is a separate secure area on the CPU in the first virtual machine that is isolated from other environments, ensuring that the code and data loaded inside is protected in terms of confidentiality and integrity.

As shown in fig. 1, the method may include:

s101, reading key encryption information from a disk.

The key encryption information is obtained by encrypting a private key of the first encryption key according to the second encryption key.

Other trusted execution environments may be run on the first virtual machine or other virtual machines, and some mutually isolated trusted applications are run on the trusted execution environments, and part of the trusted applications generate service keys in the running process, so that the service keys are generally temporarily stored in a disk in order to ensure that the service keys can be recovered quickly after the server is restarted abnormally and the software is exited abnormally. To ensure the running security of trusted applications, these service keys need to be encrypted at the time of the landing. In the embodiment of the application, the first trusted execution environment can be used for providing keys, namely private keys of the first encryption keys, for encrypting the service keys to other running trusted execution environments. In order to prevent the private key of the first encryption key from decrypting the service key at the time of restart, the private key of the first encryption key also needs to be encrypted and then dropped.

The second encryption key and the first encryption key may both be keys generated in the first trusted execution environment. Wherein the first encryption key may comprise a public key and a private key, the public key being operable to encrypt the service key and the private key being operable to decrypt the service key. The second encryption key generation, encryption and decryption processes are all inside the TEE B, and a symmetric encryption mode can be used, i.e. the second encryption key only contains one key.

The key encryption information may be ciphertext information generated within the first trusted execution environment after encrypting a private key of the first encryption key with the second encryption key. After the TEE B finishes encryption, the TEE B can be temporarily stored in a disk, and when decryption is needed, the key encryption information is directly read out from the disk for decryption.

S102, determining a decryption random number and generating a new second encryption key according to the decryption random number.

The decryption random number may be a number generated by a random number generator in TEE B, which may generate one or more random integers within a preset range, and the random number generator may use various random number generation algorithms, such as, for example, a linear congruence algorithm (Linear Congruential Generator, LGG), a linear feedback shift register algorithm, a meisen rotation algorithm, etc., although not limited in any way.

By using the decryption random number, the first trusted execution environment may generate a new second encryption key in a derived manner, which may be used to decrypt the first encryption key.

S103, decrypting the key encryption information by using the new second encryption key to determine the private key of the first encryption key.

Next, a decryption operation is performed using the new second encryption key generated by the random number derivation and the key encryption information according to a predetermined convention at the time of encryption, to obtain the private key of the first encryption key.

It will be appreciated that, due to the use of symmetric encryption, only the same second encryption key is used for encryption and decryption for the private key of the first encryption key, and the decryption is successful, determining the private key of the first encryption key.

It should be noted that the generation process of the new second encryption key may be similar to the generation process of the second encryption key for encrypting the information by the encryption key, but since the second encryption key is derived from the newly generated decryption random number, it may be different from the second encryption key generated at the time of encryption, resulting in decryption failure. How to determine the private key of the first encryption key after the decryption failure will be described in detail in the following embodiments.

In the embodiment of the application, the second encryption key is generated by using the decryption random number generated in the first trusted execution environment, so that the key encryption information is decrypted, and the probability recovery mode of the key ensures that a user does not need to memorize an additional key or password in the decryption process, thereby preventing a malicious attacker from acquiring the password by monitoring the keyboard input and improving the security in the key process.

In some embodiments, as shown in fig. 2, in the step S102, the generation of the new second encryption key according to the decrypted random number may be implemented by the following steps S201 to S202.

S201, determining a decryption seed value according to the decryption random number.

The decryption random number generated by the random number generator is an integer in a preset range, and the probability of value taking is high. In order to improve the probability of success in decryption, TEE B may further perform remainder processing on the generated decryption random number m to obtain a decryption seed value n. For example, n=m4 may be calculated, where n is in the range of {0,1,2,3} for any value of the decryption random number, so that the probability of generating a new second encryption key at the time of decryption is 1/4 as that of generating a second encryption key at the time of encryption, i.e., the probability of successfully recovering the private key of the first encryption key is 1/4.

It will be appreciated that the modulus in the process of taking the remainder of the decrypted random number may be set to 4, but may also be set to 2, 3, 5, etc. Illustratively, if the modulus value is set to 2, then the probability of successful recovery of the private key of the first encryption key is 1/2; if the modulus is set to a value of 5, then the probability of successful recovery of the private key of the first encryption key is 1/5. That is, in the embodiment of the present application, the value of the modulus may be specifically set as required, so as to change the probability of successful recovery of the private key of the first encryption key.

S202, generating a new second encryption key according to the decryption seed value and the root key of the first trusted execution environment.

The root key of the first trusted execution environment is the basis of the whole key system in the TEE B, is stored inside the TEE B, and is also the key with the highest security level in the key system, and cannot be obtained from outside.

Therefore, in the embodiment of the present application, the fixed root key and the random decryption seed value are used inside the TEE B, and the second encryption key generated by the derivative function cannot be obtained externally.

The processing of the derivative function can be understood as a special hash.

In the embodiment of the application, the second encryption key is generated by utilizing the root key and the decryption seed value generated internally in the first trusted execution environment, and the root key is invisible to the outside, so that even if a malicious attacker guesses the value of the random number, the correct second encryption key cannot be generated through the derivative function, thereby ensuring the security of the second encryption key.

In some embodiments, as shown in fig. 3, before the step S101, the step of reading the key encryption information from the disk may further include the following steps:

S301, determining an encrypted random number, and determining an encrypted seed value according to the encrypted random number.

The encrypted random number may be generated by the same random number generator as the decrypted random number, or may be generated by another random number generator, and the generation range may be the same or different, and is not limited herein.

However, in order to ensure that the decryption is successful, the range of the encrypted seed value and the range of the decrypted seed value need to be the same, that is, the calculation mode of generating the encrypted seed value by using the encrypted random number needs to be the same as the calculation mode of generating the decrypted seed value by using the decrypted random number. Illustratively, if both are remainder processing, the values of the modes need to be the same.

S302, generating a second encryption key according to the encryption seed value and the root key of the first trusted execution environment.

As in the above embodiment, the root key is the highest security level key stored inside the first trusted execution environment and cannot be obtained externally.

TEE B may generate a second encryption key using the same derivation function as in the above embodiment using the encryption seed value and root key.

It will be appreciated that since the root key and the derivative function are fixed, the second encryption key generated is the same in the case where the encrypted seed value is the same as the decrypted seed value.

S303, encrypting the private key of the first encryption key by using the second encryption key to obtain key encryption information, and writing the key encryption information into a disk.

As in the above embodiment, the first encryption key is an asymmetric key, the public key of which is used to encrypt the service key, and the private key is used to decrypt the service key. Therefore, the security of the private key stored in the disk is critical to the security of the service key, and then the private key needs to be encrypted before it is written to disk.

The TEE B may encrypt a private key of the first encryption key using the generated second encryption key using a pre-agreed encryption algorithm, generating key encryption information.

The first encryption key may be a key generated using an elliptic curve encryption algorithm (Ellipse Curve Ctyptography, ECC) or an RSA encryption algorithm, although the first encryption key may be a key generated by other asymmetric encryption algorithms.

In the embodiment of the application, after the first encryption key is encrypted in the TEE B, the key encryption information is generated and then the disc is fallen, the encrypted key cannot be obtained from the outside, and the security of the private key of the first encryption key in the disc is improved.

In some embodiments, in step S103, decrypting the key encryption information using the new second encryption key to determine the private key of the first encryption key may include: when the new second encryption key is used for decrypting the key encryption information, if the decryption is successful, the decryption result is determined as the private key of the first encryption key.

It can be understood that when the new second encryption key generated in the TEE B is the same as the second encryption key used in encryption, that is, the encrypted random number is the same as the decrypted random number, the key encryption information can be successfully decrypted according to a predetermined encryption algorithm, so as to obtain the private key of the first encryption key.

It should be noted that, whether the key encryption information is successfully decrypted is determined, whether the decrypted result is legal or not may be determined, for example, whether the length is correct, whether some fields are included, etc.

Further, the method may further include: if the decryption fails, a re-key request is sent to the second virtual machine, new key encryption information is generated, and the new key encryption information is updated to the disk.

The second virtual machine may exist on the same physical machine as the first virtual machine or may exist on a different physical machine.

If the encrypted random number is different from the decrypted random number, the new second encryption key is generated and is different from the second encryption key used in encryption, and the key encryption information cannot be successfully decrypted according to a preset encryption algorithm, so that the private key of the first encryption key is obtained, and decryption fails.

When decryption fails, in order to prevent malicious attacks, TEE B may send a rekeying request to the second virtual machine, and then regenerate the first encryption key, thereby generating new key encryption information and landing. The rekeying request may be sent to the second virtual machine to empty the information including the second virtual machine to empty the service key and the private key encrypted using the first encryption key for the service key.

In the embodiment of the application, different treatments are carried out according to success or failure of decryption after decryption, so that the key encryption information is cracked by a malicious program in a mode of multiple trial and error, and the security of the key encryption information is improved.

In some embodiments, as shown in fig. 4, in step S103, the step of decrypting the key encryption information with the new second encryption key and determining the private key of the first encryption key may further include the following steps:

s401, receiving an encryption service key sent by the second virtual machine.

Because the process of encrypting the service key is completed on the second virtual machine, the encrypted service key is written into the disk of the physical machine where the second virtual machine is located. Therefore, if the second virtual machine is not on the same physical machine as the first virtual machine, the second physical machine may read the encrypted service key from the disk and then send the encrypted service key to the first virtual machine.

It can be understood that if the first virtual machine and the second virtual machine are on the same physical machine, the first virtual machine can also access to the disk storing the encrypted service key, and at this time, the first virtual machine may also directly read the encrypted service key from the disk.

S402, decrypting the encrypted service key by using the private key of the first encryption key to obtain a decrypted service key.

As in the previous embodiment, the public key of the first encryption key is used to encrypt the service key and the private key of the first encryption key is used to decrypt the service key. Therefore, after the encrypted service key is successfully decrypted by using the private key of the first encryption key, the decrypted service key, that is, the plaintext of the service key, can be obtained.

S403, encrypting the decryption service key and sending the encrypted decryption service key to the second virtual machine.

The decrypted service key is a plaintext of the service key, and is required to be provided for trusted service in the second virtual machine, so that the decrypted service key can be encrypted by using a temporary algorithm and sent to the second virtual machine in order to avoid the plaintext of the service key from being leaked because the first virtual machine and the second virtual machine are monitored in the communication process.

It can be understood that if the communication security between the first virtual machine and the second virtual machine is high, the decryption service key may not be encrypted, and may be selected according to the security requirement.

In the embodiment of the application, after the encrypted service key is decrypted by using the private key of the first encryption key, the encrypted service key is encrypted again by using the temporary encryption algorithm and then sent to the second virtual machine, so that the plaintext of the service key is ensured to only appear in the trusted execution environment, and the security risk caused by leakage is avoided.

In some embodiments, as shown in fig. 5, a detailed flowchart of a key protection method provided by an embodiment of the present application is shown. As shown in fig. 5, the detailed flow may include:

S501, when the second virtual machine does not receive the key resetting request sent by the first virtual machine, the second virtual machine reads the encryption service key from the disk.

It can be understood that if the second virtual machine does not receive the rekeying request sent by the first virtual machine, it indicates that in the first virtual machine, the decryption of the private key of the first encryption key is successful, and the correct private key of the first encryption key is obtained.

Further, since the service key is in the second virtual machine, the encryption is performed by the public key of the first encryption key. Then, after judging that the re-key request is not received, the second virtual machine can read the encrypted service key from the disk.

S502, the second virtual machine sends the encryption service key to the first virtual machine.

Meanwhile, the first virtual machine receives the encryption service key sent by the second virtual machine.

As in the previous embodiments, the first virtual machine and the second virtual machine may be on the same or different physical machines, but the first virtual machine and the second virtual machine are communicatively connected and may communicate with each other.

After the second virtual machine reads the encrypted service key, the private key of the first encrypted key for decrypting the encrypted service key is inside the first virtual machine, so if the first virtual machine and the second virtual machine are not in the same physical machine, the second virtual machine can send the encrypted service key to the first virtual machine for decryption. Or if the first virtual machine and the second virtual machine are in the same physical machine, the first virtual machine can directly access the disk, acquire the encryption service key and decrypt the encryption service key.

S503, performing key negotiation to determine the target key.

The determining of the target key may include: the first virtual machine and the second virtual machine carry out key negotiation to determine a target key; alternatively, the second virtual machine performs key negotiation with the first virtual machine to determine the target key.

It should be noted that, after the first virtual machine decrypts the encrypted service key, a plaintext of the service key is obtained. In the case that the communication between the first virtual machine and the second virtual machine is not encrypted, the plaintext of the service key may be stolen in the communication process, resulting in the leakage of the service key. Therefore, after the first virtual machine decrypts to obtain the target key, before sending the plaintext of the service key to the second virtual machine, the two parties of communication agree on a shared target key, encrypt the plaintext of the service key, and then transmit the encrypted plaintext.

In this way, the first virtual machine and the second virtual machine may negotiate to determine the target key. Illustratively, the first virtual machine and the second virtual machine may negotiate using Diffie-HELLMAN KEY Exchange (DHKE) to determine the target key.

S504, the first virtual machine encrypts the decrypted service key by using the target key to obtain the encrypted service key.

It can be understood that the target key is a temporary key, and after the target key is determined by negotiation, the first virtual machine can encrypt the service key by using the temporary target key, and send the encrypted service key after generating the encrypted service key.

S505, the first virtual machine sends the encrypted service key to the second virtual machine.

Meanwhile, based on the response of the first virtual machine to the encrypted service key, the second virtual machine receives the encrypted service key sent by the first virtual machine.

After the first virtual machine generates the encrypted service key, the encrypted service key is sent to the second virtual machine through a communication channel between the first virtual machine and the second virtual machine.

S506, the second virtual machine decrypts the encrypted service key according to the target key to obtain the target service key.

It should be noted that, if the first virtual machine negotiates with the second virtual machine using DHKE, according to the protocol process of the protocol, the decrypted target key on the second virtual machine may not be the same key as the encrypted target key on the first virtual machine, but the second virtual machine may determine the decrypted target key based on power modulo operation.

After the target key is determined, the second virtual machine decrypts the encrypted service key sent by the first virtual machine by using the target key to obtain the target service key, namely the plaintext of the service key.

In step S403, the decryption service key is encrypted and sent to the second virtual machine, which may be implemented in steps S503 to S505.

In the embodiment of the application, the first virtual machine and the second virtual machine negotiate to determine the target key, encrypt the service key and then send the service key, and improve the security of the service key in the communication process before realizing the secure communication.

In some embodiments, as shown in fig. 6, the method provided by the embodiment of the present application may further include the following steps:

s601, when a re-key request sent by the first virtual machine is received, all service keys managed in the second trusted execution environment are set to be invalid, and all encrypted service keys in the disk are deleted.

It may be appreciated that the second trusted execution environment may include a plurality of service keys, and when the second virtual machine receives the rekeying request, it indicates that decryption of the key encryption information fails in the first virtual machine. At this time, to avoid malicious hacking, the first virtual machine may send a rekeying request to the second virtual machine, so that the second virtual machine empties the service key and encrypts the service key with the private key of the first encryption key.

S602, receiving a public key of a new first encryption key sent by the first virtual machine.

As in the previous embodiment, after the first virtual machine fails to decrypt the key encryption information, the first virtual machine regenerates the first encryption key and sends the public key of the newly generated first encryption key to the second virtual machine.

S603, encrypting the service key to be encrypted by using the public key of the new first encryption key, generating a new encryption service key, and writing the new encryption service key into the disk.

It should be noted that, after the second virtual machine receives the rekeying request and clears the service key, a new service key will be regenerated.

Further, after receiving the public key of the new first encryption key, the second virtual machine encrypts the new service key by using the public key to generate a new encrypted service key, and finally writes the new encrypted service key into the disk of the physical machine.

In the embodiment of the application, after the second virtual machine receives the re-key request, the service key is regenerated and encrypted, thereby avoiding malicious cracking of the service password and improving the security of service key storage.

In some embodiments, fig. 7 is a detailed interaction flow diagram of a key protection method according to an embodiment of the present application. As shown in fig. 7, the detailed interaction flow may include:

S701, generating a random number m, and calculating n=m4.

S702, the root key and m derivative encryption key 2 are used.

S703, decrypting the ciphertext of the private key using the encryption key 2.

S704, judging whether decryption is successful.

S705, if successful, receives the encrypted service key from TEE a.

S706, decrypting the ciphertext by using the private key.

S707, key negotiation with TEE a generates a temporary key.

S708, encrypting the service key plaintext by using the temporary key generated by negotiation.

S709, the encrypted service key is transmitted to TEE a.

S710, ending.

S711, if it fails, a rekeying request is sent to TEE a.

S712, the encryption key 1 is regenerated.

S713, the public key part is transmitted.

S714, end.

The steps S705 to S71 are related steps executed after the decryption is judged to be successful, and the steps S711 to S714 are related steps executed after the decryption is judged to be failed.

S715, judging whether a rekey request is received.

S716, if yes, setting all keys in the TEE A as invalid.

S717, all encrypted service keys are deleted from the disk.

S718, the public key in encryption key 1 is received from TEE B.

S719, the new service key encryption is using the received public key.

S720, if not, reading the encrypted service key from the disk.

S721, the encrypted content is sent to TEE B.

S722, wait for key negotiation with TEE B to generate a temporary key.

S723, receive the service key ciphertext sent by TEE a.

And S724, decrypting by using the temporary key to obtain a service key plaintext.

The steps S715 to S719 are steps executed after the reception of the rekeying request, and the steps S720 to S724 are steps executed after the reception of the rekeying request.

Wherein S701-S714 are key recovery related processes of TEE B, and S7 XX-S7 XX are key recovery related processes of TEE A. Here, TEE a participates in the service key generation and negotiation process, and TEE B provides TEE a with keys required for key security landing and ensures security landing of keys used by itself.

Referring to fig. 7, for the foregoing key protection method, a specific flow chart is as follows:

tee B key recovery related procedure.

1.1. Encryption key 1 generation and use.

1.1.1. A key for asymmetric encryption is generated, which may be a key of an ECC or RSA encryption algorithm, referred to as encryption key 1.

The public key of encryption key 1 is sent into TEE a.

1.2. Encryption key 2 generation and use.

1.2.1. The random number m is generated using a random number generator built into TEE B and n=m% 4 is calculated, where n is a possible value {0,1,2,3}, each value having a probability of occurrence of 1/4.

1.2.2. The key derivation interface in TEE B is invoked and the value n is entered, i.e. the root key and m are used, the encryption key 2 is derived, and the root key of TEE B and the value n are used in the derivation process. Since the encryption key 2 is generated inside the TEE B, the TEE B ensures that the encryption key 2 cannot be obtained externally; meanwhile, since the root key of the TEE is invisible to the outside, even if a malicious attacker guesses the value of the random number, the encryption key 2 in the TEE B cannot be obtained through the key derivation algorithm.

1.2.3. The private key in the encryption key 1 is encrypted using the encryption key 2, and then the encryption result is written to the disk.

Recovery after re-run of tee B.

1.3.1. The 1.2.1 process is performed to obtain the value n, and then the 1.2.2 process is performed to generate the encryption key 2, but at this time, it cannot be determined whether the generated encryption key 2 is the same key as the encryption key 2 generated in 1.2.

1.3.2. The ciphertext of the private key in the encryption key 1 in the magnetic disk is read into the TEE B, then the ciphertext of the private key is decrypted by using the encryption key 2, and then whether decryption is successful or not is further judged.

1.3.3. If the decryption is successful, the private key part in the encryption key 1 is restored, and the restoration process is ended.

1.3.4. If the decryption fails, a key resetting request is sent to the TEE A, and the TEE A is required to reset all keys.

1.3.5. And executing the processes of 1.1.1 and 1.1.2, regenerating the encryption key 1, encrypting the generated private key of the encryption key 1 by using the encryption key 2, and writing the encryption result into the disk to replace the encrypted content of the private key in the original encryption key 1 in the disk. In addition, the public key portion of encryption key 1 is also sent to TEE a.

Key recovery related procedure in tee a.

When the TEE A key is recovered, whether a key resetting request is received is firstly judged, and then two situations are possibly determined according to the judging result, wherein one situation is that the key resetting request is received, and the other situation is that the key resetting request is not received, and the key recovery flow of the TEE A in the two situations is respectively described below.

2.1. A rekey request is received.

2.1.1. All keys managed in the current TEE a are set to invalid.

2.1.2. All encrypted service keys are deleted from the disk.

2.1.3. The public key in the new encryption key 1 is received from TEE B.

2.1.4. The public key received by the 2.1.3 process is used when the generated and negotiated key falls on the disc, that is, the newly generated service key encryption is performed by using the received public key.

2.2. No rekey request is received.

2.2.1. Reads the encrypted traffic key from disk and sends the encrypted content to TEE B.

Meanwhile, TEE B receives the encrypted traffic key from TEE a.

After receiving the encrypted content, the tee B decrypts the ciphertext using the private key in the encryption key 2 to obtain the plaintext of the service key.

And 2.2.3. The TEE B performs key negotiation with the TEE A to generate a temporary key, wherein the temporary key is a key used by symmetric encryption algorithms such as AES, SM4 and the like.

The TEE B encrypts the plaintext of the service key by using the temporary key generated by negotiation, then sends the encryption result to the TEE A, and the key used in encryption is the key generated by negotiation in the process of 2.2.3.

After receiving the service key ciphertext sent by the TEE a, the TEE a uses the temporary decryption generated by negotiation in the 2.2.3 process to obtain the plaintext of the service key.

2.2.6. So far, the service key recovery is successful.

It should be noted that, in the embodiment of the present application, the problem that the key management system cannot safely drop in a part of TEE is solved by using the probability recovery method of the encryption key 2, and the user of the key management system does not need to memorize additional keys and passwords; the thought that the random number with the occurrence frequency of 1/4 and the root key derive a new key ensures that the key cannot be revealed due to disc dropping and the like, and the possibility of successful recovery of the key is provided.

In addition, in the embodiment of the application, the security problem caused by the key solidification in the program can be solved, the user is not required to memorize the key, a malicious attacker is prevented from acquiring the password by monitoring the keyboard input, and the security of the system is improved. Therefore, the technical scheme of the embodiment of the application can be applied to a data security management and control platform product, and the product has unified, professional, compliance and high-efficiency deployed data security prevention and control means so as to meet the data security protection requirements of a cross-service system and a cross-data platform, thereby improving privacy protection.

As shown in fig. 8, an embodiment of the present application further provides a key protection system 80, including:

a first virtual machine 801, and a second virtual machine 802, the first virtual machine 801 being communicatively connected to the second virtual machine 802.

The first virtual machine 801 is configured to perform the method performed by the first virtual machine 801 in the foregoing embodiment.

The second virtual machine 802 is configured to perform the method performed by the second virtual machine 802 in the foregoing embodiment.

Referring to fig. 9, an embodiment of the present application further provides a first key protection device 90, applied to a first virtual machine, where the device includes:

A reading unit 901 configured to read key encryption information from a disk, where the key encryption information is obtained by encrypting a private key of a first encryption key according to a second encryption key;

a generating unit 902 configured to determine a decryption random number and generate a new second encryption key from the decryption random number;

The decryption unit 903 is configured to decrypt the key encryption information using the new second encryption key, and determine the private key of the first encryption key.

In some embodiments, the generating unit 902 is further configured to determine a decrypted seed value based on the decrypted random number; and generating a new second encryption key according to the decrypted seed value and the root key of the first trusted execution environment.

In some embodiments, the generating unit 902 is further configured to determine an encrypted random number and determine an encrypted seed value from the encrypted random number; generating a second encryption key according to the encryption seed value and the root key of the first trusted execution environment; and encrypting the private key of the first encryption key by using the second encryption key to obtain key encryption information, and writing the key encryption information into the disk.

In some embodiments, the decryption unit 903 is further configured to determine, when decrypting the key encryption information using the new second encryption key, a result of the decryption as a private key of the first encryption key if the decryption is successful.

In some embodiments, the decryption unit 903 is further configured to send a rekeying request to the second virtual machine if the decryption fails, generate new key encryption information, and update the new key encryption information to the disk.

In some embodiments, the generating unit 902 is further configured to receive an encrypted service key sent by the second virtual machine; decrypting the encrypted service key by using the private key of the first encryption key to obtain a decrypted service key; encrypting the decrypted service key and transmitting the encrypted service key to the second virtual machine.

In some embodiments, the generating unit 902 is further configured to perform key negotiation with the second virtual machine to determine a target key; and encrypting the decrypted service key by using the target key to obtain an encrypted service key, and transmitting the encrypted service key to the second virtual machine.

Referring to fig. 10, an embodiment of the present application further provides a second key protection device 100, applied to a second virtual machine, where the device includes:

a sending unit 1001 configured to read an encrypted service key from a disk and send the encrypted service key to the first virtual machine when a key resetting request sent by the first virtual machine is not received;

A determining unit 1002 configured to perform key negotiation with the first virtual machine, and determine a target key;

the sending unit 1001 is further configured to receive the encrypted service key sent by the first virtual machine based on the response of the first virtual machine to the encrypted service key;

The determining unit 1002 is further configured to decrypt the encrypted service key according to the target key to obtain the target service key.

In some embodiments, the determining unit 1002 is further configured to, when receiving the rekeying request sent by the first virtual machine, set all service keys managed in the second trusted execution environment to invalid, and delete all encrypted service keys in the disk; receiving a public key of a new first encryption key sent by a first virtual machine; and encrypting the service key to be encrypted by using the public key of the new first encryption key, generating a new encryption service key, and writing the new encryption service key into the disk.

It will be appreciated that in this embodiment, the "unit" may be a part of a circuit, a part of a processor, a part of a program or software, etc., and may of course be a module, or may be non-modular. Furthermore, the components in the present embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional modules.

The integrated units, if implemented in the form of software functional modules, may be stored in a computer-readable storage medium, if not sold or used as separate products, and based on such understanding, the technical solution of the present embodiment may be embodied essentially or partly in the form of a software product, which is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or processor to perform all or part of the steps of the method described in the present embodiment. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Accordingly, the present embodiment provides a computer readable storage medium storing a computer program which, when executed by at least one processor, implements the steps of the method of any of the preceding embodiments.

In some embodiments, referring to fig. 11, a schematic diagram of a specific hardware structure of an electronic device according to an embodiment of the present application is shown. As shown in fig. 11, the electronic device 11 may include: a communication interface 1101, a memory 1102, and a processor 1103; the various components are coupled together by a bus system 1104. It is to be appreciated that the bus system 1104 is employed to facilitate connected communications between the components. The bus system 1104 includes a power bus, a control bus, and a status signal bus in addition to the data bus. But for clarity of illustration, the various buses are labeled as bus system 1104 in fig. 11. Wherein:

a communication interface 1101, configured to receive and transmit signals during a process of transmitting and receiving information with a power supply device;

a memory 1102 for storing a computer program capable of running on the processor 1103;

A processor 1103, configured to, when executing the computer program, perform:

reading key encryption information from a disk; the key encryption information is obtained by encrypting a private key of the first encryption key according to the second encryption key;

determining a decryption random number and generating a new second encryption key according to the decryption random number;

And decrypting the key encryption information by using the new second encryption key to determine the private key of the first encryption key.

Or processor 1103, and is further configured to, when executing the computer program, perform:

When a key resetting request sent by the first virtual machine is not received, reading an encryption service key from a disk, and sending the encryption service key to the first virtual machine;

performing key negotiation with the first virtual machine to determine a target key;

receiving an encrypted service key sent by the first virtual machine based on the response of the first virtual machine to the encrypted service key;

And decrypting the encrypted service key according to the target key to obtain a target service key.

It will be appreciated that memory 1102 in embodiments of the application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (STATIC RAM, SRAM), dynamic random access memory (DYNAMIC RAM, DRAM), synchronous dynamic random access memory (Synchronous DRAM, SDRAM), double data rate Synchronous dynamic random access memory (Double DATA RATE SDRAM, DDRSDRAM), enhanced Synchronous dynamic random access memory (ENHANCED SDRAM, ESDRAM), synchronous Link DRAM (SLDRAM), and Direct memory bus RAM (DRRAM). The memory 1102 of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

And the processor 1103 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the method described above may be performed by integrated logic circuitry in hardware or instructions in software in the processor 1103. The Processor 1103 may be a general purpose Processor, digital signal Processor (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), field programmable gate array (Field Programmable GATE ARRAY, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in the memory 1102, and the processor 1103 reads information in the memory 1102, and combines the hardware with the steps of the method.

It is to be understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For a hardware implementation, the Processing units may be implemented within one or more Application SPECIFIC INTEGRATED Circuits (ASICs), digital signal processors (DIGITAL SIGNAL Processing, DSPs), digital signal Processing devices (DSP DEVICE, DSPD), programmable logic devices (Programmable Logic Device, PLDs), field-Programmable gate arrays (Field-Programmable GATE ARRAY, FPGA), general purpose processors, controllers, micro-controllers, microprocessors, other electronic units for performing the functions described herein, or a combination thereof.

For a software implementation, the techniques described herein may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory and executed by a processor. The memory may be implemented within the processor or external to the processor.

Optionally, as another embodiment, the processor 1103 is further configured to perform the steps of the method of any of the preceding embodiments when the computer program is run.

The above description is not intended to limit the scope of the application, but is intended to cover any modifications, equivalents, and improvements within the spirit and principles of the application.

The present application also provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the steps of the key protection method provided by the above method embodiments.

It should be appreciated that the description of the storage medium and apparatus embodiments above is similar to that of the method embodiments described above, with similar benefits as the method embodiments. For technical details not disclosed in the storage medium, the storage medium and the device embodiments of the present application, please refer to the description of the method embodiments of the present application.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" or "some embodiments" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" or "in some embodiments" in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application. The foregoing embodiment numbers of the present application are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments. The foregoing description of various embodiments is intended to highlight differences between the various embodiments, which may be the same or similar to each other by reference, and is not repeated herein for the sake of brevity.

It should also be noted that, in the present disclosure, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing embodiment numbers of the present application are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.

The methods disclosed in the method embodiments provided by the application can be arbitrarily combined under the condition of no conflict to obtain a new method embodiment.

The features disclosed in the several product embodiments provided by the application can be combined arbitrarily under the condition of no conflict to obtain new product embodiments.

The features disclosed in the embodiments of the method or the apparatus provided by the application can be arbitrarily combined without conflict to obtain new embodiments of the method or the apparatus.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (13)

1. A key protection method applied to a first virtual machine, the first virtual machine including a first trusted execution environment, the method comprising:

reading key encryption information from a disk; the key encryption information is obtained by encrypting a private key of the first encryption key according to the second encryption key;

determining a decryption random number and generating a new second encryption key according to the decryption random number;

And decrypting the key encryption information by using the new second encryption key to determine the private key of the first encryption key.

2. The method of claim 1, wherein the generating a new second encryption key from the decrypted random number comprises:

Determining a decryption seed value according to the decryption random number;

and generating the new second encryption key according to the decryption seed value and the root key of the first trusted execution environment.

3. The method of claim 1, wherein prior to reading the key encryption information from the disk, the method further comprises:

determining an encrypted random number, and determining an encrypted seed value according to the encrypted random number;

Generating the second encryption key according to the encryption seed value and the root key of the first trusted execution environment;

And encrypting a private key of the first encryption key by using the second encryption key to obtain the key encryption information, and writing the key encryption information into the disk.

4. The method of claim 1, wherein decrypting the key encryption information using the new second encryption key, determining a private key of the first encryption key, comprises:

And when the new second encryption key is used for decrypting the key encryption information, if the decryption is successful, determining a decryption result as a private key of the first encryption key.

5. The method according to claim 4, wherein the method further comprises:

and if the decryption fails, sending a re-key request to the second virtual machine, generating new key encryption information, and updating the new key encryption information to the disk.

6. The method according to any one of claims 1 to 5, wherein after determining the private key of the first encryption key, the method further comprises:

Receiving an encryption service key sent by the second virtual machine;

Decrypting the encrypted service key by using the private key of the first encryption key to obtain a decrypted service key;

encrypting the decryption service key and sending the decryption service key to the second virtual machine.

7. The method of claim 6, wherein encrypting the decrypted service key and transmitting to the second virtual machine comprises:

performing key negotiation with the second virtual machine to determine a target key;

and encrypting the decryption service key by using the target key to obtain an encrypted service key, and sending the encrypted service key to the second virtual machine.

8. The key protection method is characterized by being applied to a second virtual machine, wherein the second virtual machine comprises a second trusted execution environment, and the second virtual machine is in communication connection with the first virtual machine; the method comprises the following steps:

When a key resetting request sent by the first virtual machine is not received, reading an encryption service key from a disk, and sending the encryption service key to the first virtual machine;

performing key negotiation with the first virtual machine to determine a target key;

receiving an encrypted service key sent by the first virtual machine based on the response of the first virtual machine to the encrypted service key;

And decrypting the encrypted service key according to the target key to obtain a target service key.

9. The method of claim 8, wherein the method further comprises:

When a key resetting request sent by the first virtual machine is received, setting all service keys managed in the second trusted execution environment to be invalid, and deleting all encrypted service keys in a disk;

receiving a public key of a new first encryption key sent by the first virtual machine;

And encrypting the service key to be encrypted by using the public key of the new first encryption key, generating a new encryption service key, and writing the new encryption service key into the disk.

10. A first key protection device, comprising:

The reading unit is configured to read key encryption information from the magnetic disk, wherein the key encryption information is obtained by encrypting a private key of the first encryption key according to the second encryption key;

A generation unit configured to determine a decryption random number and generate a new second encryption key according to the decryption random number;

And the decryption unit is configured to decrypt the key encryption information by using the new second encryption key and determine the private key of the first encryption key.

11. A second key protection device, comprising:

a sending unit configured to read an encrypted service key from a disk and send the encrypted service key to the first virtual machine when a key resetting request sent by the first virtual machine is not received;

The determining unit is configured to carry out key negotiation with the first virtual machine and determine a target key;

The sending unit is further configured to receive the encrypted service key sent by the first virtual machine based on the response of the first virtual machine to the encrypted service key;

The determining unit is further configured to decrypt the encrypted service key according to the target key to obtain the target service key.

12. A key protection system, comprising:

the system comprises a first virtual machine and a second virtual machine, wherein the first virtual machine is in communication connection with the second virtual machine;

the first virtual machine for performing the method of any of claims 1-7;

the second virtual machine being configured to perform the method of any of claims 8-9.

13. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method according to any of claims 1-7 or the method according to any of claims 8-9.