User key protection method, device, storage medium and system

Abstract

The application provides a user key protection method, device, storage medium and system. A cloud virtual machine includes a processor supporting confidential computing, an untrusted memory space and a trusted memory space. The method includes obtaining a KMS program of a user, loading first program code in the KMS program to the trusted memory space, and loading second program code to the untrusted memory space. A first public key is generated through the first program code, and the first public key is sent to a user server through the second program code. A ciphertext entropy parameter encrypted by the first public key on a first entropy parameter is received from the user server through the second program code. The first entropy parameter is decrypted based on a first private key through the first program code, a user key is generated based on the first entropy parameter, and the user key is stored in the trusted memory space. The generation, use and storage of the user key are in the trusted memory space, and the cloud service provider cannot access the trusted memory space, thereby ensuring the security of the user key.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet, and in particular to a user key protection method, device, storage medium and system. BACKGROUND

[0002] Protecting the data security of users on a public cloud, especially the privacy data security, has always been a matter of concern for users on the cloud. There are mainly two goals for protecting the data security of users on the cloud: one is not to be threatened by access of other users on the cloud, and the other is not to be threatened by access of cloud service providers. At present, many mechanisms of cloud service providers can meet the needs of the first goal, but cannot meet the needs of the second goal.

[0003] Taking the key data of a user as an example, in the current design, the user key is entrusted to a cloud service provider for custody, that is, the generation, storage and use of the user key are all implemented based on the service interface provided by the cloud service provider, and the user key is in a state that can be taken and accessed by the cloud service provider. The user can only trust that the cloud service provider will not abuse the privilege. But this is difficult to dispel the doubts of users with high security requirements.

[0004] Therefore, the cloud service provider of the public cloud needs to provide a security solution of zero trust of the user to the cloud service provider, to ensure that the key data of the user cannot be taken or accessed by the cloud service provider, and to guarantee the security of the generation, use and storage of the user key in the environment of the public cloud. SUMMARY

[0005] Embodiments of the present application provide a user key protection method, device, storage medium and system for protecting the security of a user key.

[0006] In a first aspect, embodiments of the present application provide a user key protection method applied to a virtual machine in the cloud, wherein the virtual machine comprises a processor supporting confidential computing, an untrusted memory space and a trusted memory space, and the method comprises:

[0007] obtaining a key management service program of a user, wherein the key management service program comprises first program code related to key generation and use and second program code other than the first program code; wherein the first program code is loaded into the trusted memory space, and the second program code is loaded into the untrusted memory space;

[0008] generating a first public key through the first program code, and sending the first public key to a user-side server through the second program code;

[0009] receive a ciphertext entropy parameter sent by the user terminal server through the second program code, the ciphertext entropy parameter being obtained by encrypting a first entropy parameter by the user terminal server using the first public key;

[0010] decrypt the first entropy parameter based on a first private key corresponding to the first public key through the first program code, and generate a user key of the user based on the first entropy parameter, the user key being stored in the trusted memory space.

[0011] In a second aspect, an embodiment of the present application provides a user key protection device, applied to a virtual machine in the cloud, the virtual machine comprising a processor supporting confidential computing, an untrusted memory space and a trusted memory space, and the device comprises:

[0012] a program deployment module configured to obtain a key management service program of a user, the key management service program comprising first program code related to key generation and use and second program code other than the first program code; wherein the first program code is loaded into the trusted memory space, and the second program code is loaded into the untrusted memory space;

[0013] an entropy parameter transmission module configured to generate a first public key through the first program code, send the first public key to a user terminal server through the second program code, and receive a ciphertext entropy parameter sent by the user terminal server through the second program code, the ciphertext entropy parameter being obtained by encrypting a first entropy parameter by the user terminal server using the first public key;

[0014] a user key generation module configured to decrypt the first entropy parameter based on a first private key corresponding to the first public key through the first program code, and generate a user key of the user based on the first entropy parameter, the user key being stored in the trusted memory space.

[0015] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor and a communication interface; wherein the memory stores executable code, when the executable code is executed by the processor, the processor executes the user key protection method according to the first aspect.

[0016] In a fourth aspect, an embodiment of the present application provides a non-transitory machine readable storage medium, the non-transitory machine readable storage medium stores executable code, when the executable code is executed by a processor of an electronic device, the processor can at least implement the user key protection method according to the first aspect.

[0017] In a fifth aspect, an embodiment of the present application provides a user key protection system, comprising:

[0018] a user terminal server, a virtual machine in the cloud, the virtual machine comprising a processor supporting confidential computing, an untrusted memory space and a trusted memory space; wherein the processor is configured to perform the following steps:

[0019] obtaining a key management service program of the user, the key management service program comprising a first program code related to key generation and usage and a second program code other than the first program code; wherein the first program code is loaded into the trusted memory space and the second program code is loaded into the untrusted memory space;

[0020] generating a first public key through the first program code and sending the first public key to the user terminal server through the second program code;

[0021] receiving a ciphertext entropy parameter sent by the user terminal server through the second program code, the ciphertext entropy parameter being obtained by encrypting a first entropy parameter with the first public key by the user terminal server;

[0022] decrypting the first entropy parameter based on a first private key corresponding to the first public key through the first program code, generating a user key of the user based on the first entropy parameter, and storing the user key in the trusted memory space;

[0023] the user terminal server is configured to encrypt a first entropy parameter with the first public key to obtain the ciphertext entropy parameter and send the ciphertext entropy parameter to the virtual machine through the second program code.

[0024] In the embodiment of the application, the user can use the key management service program to manage the user's key. The key management service program can be deployed into a virtual machine of the user in the cloud after being audited by the user. Specifically, the key management server program can be divided into two parts of code: a first program code and a second program code, wherein the first program code is the core program code closely related to the generation and use of the key, and the program code other than this is the second program code. In fact, the second program code mainly provides some service interfaces for external access. The virtual machine comprises a processor supporting confidential computing, an untrusted memory space and a trusted memory space. In fact, the trusted memory space is a memory space encrypted by hardware based on confidential computing technology, and external applications such as cloud service providers cannot access this part of the memory space, i.e. this part of the memory space is invisible to these external applications. The first program code is loaded into the trusted memory space and the second program code is loaded into the untrusted memory space, so that the function code related to the generation and use of the user key is encapsulated in the trusted memory space.

[0025] Based on the above deployment result, when a user key needs to be generated, an entropy parameter for generating a user key needs to be transmitted by the user's own user server, but in order to ensure security, the entropy parameter needs to be transmitted in ciphertext. To this end, on the virtual machine side, a public-private key pair is generated based on the first program code in the trusted memory space, which includes a first public key and a first private key, and then the first public key generated by the first program code is transmitted to the second program code in the untrusted memory space, so as to be sent to the user server by the second program code. The user server encrypts the above-mentioned entropy parameter using the first public key, calls the second program code to transmit the ciphertext entropy parameter to the first program code in the trusted memory space, and decrypts the entropy parameter using the first private key based on the first program code, and then generates a user key according to the entropy parameter, and saves the user key in the trusted memory space, but does not fall into the disk in the virtual machine. Since the above-mentioned trusted memory space is protected by hardware, such as the generation process of the above-mentioned first private key and user key, and the generated user key is not out of the trusted memory space, and cannot be obtained by the cloud service provider, thereby realizing the security protection of the user key. BRIEF DESCRIPTION OF DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0027] Figure 1 A schematic diagram of a virtual machine provided by the embodiment of the present application is provided.

[0028] Figure 2 A schematic diagram of a user key protection system provided by the embodiment of the present application is provided.

[0029] Figure 3 A flowchart of a user key protection method provided by the embodiment of the present application is provided.

[0030] Figure 4 A flowchart of a user key protection method provided by the embodiment of the present application is provided.

[0031] Figure 5 An interactive flowchart of a remote authentication process of a user server provided by the embodiment of the present application is provided.

[0032] Figure 6 A flowchart of a user key protection method provided by the embodiment of the present application is provided.

[0033] Figure 7An interaction flowchart of a two-way authentication process between a cloud application and a KMS program provided by an embodiment of the present application is shown in FIG. 1.

[0034] Figure 8 A flowchart of a KMS private key protection process provided by an embodiment of the present application is shown in FIG. 2.

[0035] Figure 9 A structural schematic diagram of a user key protection device provided by an embodiment of the present application is shown in FIG. 3.

[0036] Figure 10 A structural schematic diagram of an electronic device provided by an embodiment of the present application is shown in FIG. 4. DETAILED DESCRIPTION

[0037] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in detail with reference to the accompanying drawings. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application. In addition, the sequence of steps in each of the following method embodiments is only an example, not a strict limitation.

[0038] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the embodiments of the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0039] First, some concepts involved in the embodiments of the present application are explained and described.

[0040] User master key: Customer Main Key, abbreviated as CMK, used to derive user work key.

[0041] Work key: Work Key, abbreviated as WK, a key that can be derived and obtained by the user, and the user's cloud application can obtain the work key to perform data encryption and decryption.

[0042] Entropy parameter: Entropy, a piece of key material, used as a parameter for generating a key.

[0043] Key management service program: Key Management Service, abbreviated as KMS.

[0044] Software Guard Extensions (SGX) is a confidential computing technology, which is actually a set of CPU instruction extensions, can create a trusted execution environment (enclave) to protect code and data, so that root permission cannot access, so that applications can use it to isolate code and data in a specific trusted area, prevent the underlying operating system from being controlled after the attack on itself, and at the same time, the software management can also not trust cloud service providers.

[0045] enclave: Enclave refers to the protected part of the processor and memory of the hardware, that is, Enclave provides a trusted running environment for applications and data.

[0046] User server: refers to a server that is owned by the user, not controlled by the cloud service provider, and trusted. The user needs to generate, encrypt, and store the user entropy parameter on the server to prevent the entropy parameter from being leaked.

[0047] priK1, pubK1: is a temporary asymmetric key generated by the KMS program, the private key is priK1, and the public key is pubK1. The public key will be passed to the user server to encrypt the entropy parameter for generating CMK.

[0048] priK2, pubK2: is a public-private key pair generated by the user server, the public key is pubK2, and the private key is priK2.

[0049] Remote attestation: is a mechanism provided by SGX, which allows the trusted running environment to prove to the verifier the integrity of its application, the correctness of the hardware platform (running in SGX and having the correct attributes, such as not working in debug mode), and the identity of the developer.

[0050] Confidential computing attestation server, such as SGX attestation server, is an infrastructure for remote attestation of trusted running environments.

[0051] Certificate Authority (CA) is a third-party trust authority that provides network identity authentication services using public key technology, mainly checks the legitimacy of the identity of the certificate holder and is responsible for issuing and managing digital certificates to prevent certificates from being forged or tampered with. It is an authoritative and impartial third-party trust authority. The certificate issued by CA is also called digital certificate.

[0052] CA certificate: also known as root certificate, is a certificate issued by CA to itself, which is the starting point of the trust chain. Installing a root certificate means trusting this CA.

[0053] KMS certificate: a certificate issued by the CA to the KMS program, the certificate containing the KMS public key. The issuance process of the KMS certificate is simply that: the user first generates a public-private key pair corresponding to the KMS program, transmits the KMS public key and some KMS program-related attribute information to the CA, and the CA will eventually issue a digital certificate, i.e., the KMS certificate, to the user, which includes the KMS public key and also has the signature information of the CA. Among them, the CA has its own CA private key and CA public key, uses the CA private key for signature, and uses the CA public key for signature verification. The CA certificate contains the CA public key.

[0054] Taking the user key including CMK and WK as an example, in the current design, the CMK is entrusted to the cloud service provider for custody, and the WK is also generated by calling the interface provided by the cloud service provider, and is encrypted and derived by the CMK. That is, the cloud service provider has the privilege of using the user's CMK, and the user can only trust the cloud service provider not to abuse the privilege. But it is difficult to dispel the doubts of users with high security requirements.

[0055] Therefore, the embodiment of the application provides a user key protection scheme based on confidential computing, which can enable the user to maintain zero trust for the cloud service provider and manage the generation, use, storage and the like of the key by the user himself. The cloud service provider cannot access or use the hardware-protected key by using the operating system, virtual machine management program, firmware, application program interface (API interface) and the like.

[0056] The core idea is that the user creates a virtual machine (i.e., a virtual machine instance) on a public cloud for providing a key management service. The virtual machine needs to support confidential computing capability for encapsulating the CMK and WK and the code for accessing and using them into a trusted running environment. In the embodiment of the application, the trusted running environment refers to a trusted memory space. The working principle is that the user's CMK is derived and generated by an entropy parameter input by an external trusted source, and the user's WK is derived from the CMK, and neither the CMK nor the WK is stored on the cloud, but is stored in the trusted memory space.

[0057] The entire key management service program is composed of a trusted part and an untrusted part. The trusted part contains the CMK, WK, some public and private keys, certificates and other sensitive data, and key-related program code. The function of this part of program code mainly includes the generation of CMK, the derivation of WK, the export of WK and the identity authentication of the function calling party. The untrusted part mainly provides a network service interface to provide services to the outside.

[0058] The KMS program providing the key protection function for the user needs to be deployed in the virtual machine constructed by the user on the cloud. Figure 1A composition diagram of a virtual machine is provided for an embodiment of the present application, as shown in Figure 1 The virtual machine includes a processor supporting confidential computing, an untrusted memory space, and a trusted memory space.

[0059] The processor can be a virtual CPU, denoted as vCPU in the diagram. The supported confidential computing function can be an SGX function, but is not limited thereto. Based on the confidential computing function, the memory space in the virtual machine can be divided into an untrusted memory space and a trusted memory space that is encrypted and protected.

[0060] As described above, the KMS program includes first program code related to key generation and use and second program code other than the first program code, i.e., the first program code is the trusted part of the KMS program as described above, and the second program code is the untrusted part of the KMS program as described above, mainly including some service interfaces for external access.

[0061] When the KMS program is deployed in the virtual machine, the first program code therein is loaded into the trusted memory space, and the second program code is loaded into the untrusted memory space. If an external object wants to use the function provided by the first program code, it needs to call the corresponding service interface in the second program code, and cannot directly call the first program code.

[0062] In actual application, the KMS program can be a software file, and the first program code and the second program code each correspond to a sub-file in the software file. The sub-files corresponding to the first program code and the second program code can have different suffix formats, so as to distinguish the two types of program codes, or the naming of the sub-files can include a keyword for distinguishing the two types of program codes. Thus, according to these differences, when the KMS program is deployed in the virtual machine, the first program code and the second program code therein can be identified.

[0063] In addition, the first program code can include not only code for providing core functions such as key generation, caller authentication, etc., but also some public data, as shown in Figure 1 such as the KMS certificate, the CA certificate, some public and private keys (such as pubK2 and KMS public key) mentioned above, so that these public data are loaded into the trusted memory space together with the core function code. In addition, the sensitive data such as pubK1 and priK1 generated in the trusted memory space are also stored.

[0064] For ease of understanding, the first program code in the trusted memory space and the second program code in the untrusted memory space are divided into function modules according to the core functions they provide. As shown in Figure 1As shown in the trusted memory space, the second program code in the untrusted memory space mainly provides service interface functions including a remote authentication interface, a CMK generation interface, and a working key acquisition interface. The first program code in the trusted memory space mainly provides code modules including CMK generation code, WK generation code, and authentication code.

[0065] Based on the virtual machine, the embodiment of the application further provides a key protection system comprising the virtual machine, as shown in the system architecture. Figure 2 As shown in the system architecture, in addition to the virtual machine shown in the trusted memory space, the system can further comprise a user terminal server, a confidential computing authentication server, and a user's cloud application. Figure 1 As shown in the virtual machine, the user terminal server is a server trusted by the user and can be controlled by the user, and is mainly used to transmit an entropy parameter for generating a CMK to the virtual machine, generate the priK2 and pubK2, and complete authentication of the trusted running environment.

[0066] The confidential computing authentication server is a server maintained by a service provider providing confidential computing for the vCPU in the virtual machine, and is mainly used to complete authentication of the trusted running environment in cooperation with the user terminal server.

[0067] In the embodiment of the application, the trusted running environment mainly refers to a virtual machine environment in which the KMS program runs, such as the running environment of the trusted memory space and the vCPU.

[0068] The cloud application refers to an application program deployed by the user constructing the virtual machine in the cloud. During data transmission, the cloud application can request the KMS program to provide a working key, so as to use the obtained working key to encrypt and transmit the data to be transmitted, thereby ensuring data security.

[0069] Based on the system architecture, the generation of the CMK and the WK and the related authentication process will be described below in combination with the following embodiments.

[0070] Based on the system architecture, the generation of the CMK and the WK and the related authentication process will be described below in combination with the following embodiments.

[0071] Figure 3 A flowchart of a user key protection method provided by the embodiment of the application, which can be executed by a processor supporting confidential computing technology in a cloud virtual machine, as shown in the flowchart. Figure 3 As shown in the flowchart, the method comprises the following steps:

[0072] 301, acquire a key management service program of a user, first program code related to key generation and use in the key management service program is loaded into a trusted memory space, and second program code other than the first program code is loaded into an untrusted memory space.

[0073] 302、generating a first public key through the first program code, and sending the first public key to the user-side server through the second program code.

[0074] 303、receiving a ciphertext entropy parameter sent by the user-side server through the second program code, the ciphertext entropy parameter being obtained by encrypting the first entropy parameter by the user-side server using the first public key.

[0075] 304、decrypting the first entropy parameter based on the first private key corresponding to the first public key through the first program code, generating a user key of the user based on the first entropy parameter, and storing the user key in the trusted memory space.

[0076] In actual application, the KMS program received by the user's virtual machine side is not necessarily a program designed and written by the user himself, but can be obtained from a cloud service provider or other third party. Therefore, the user can first download the KMS program through the user-side device (such as the user's own PC or also the user-side server), compile and review the KMS program in the local user-side device to determine whether the KMS program contains malicious code content.

[0077] Of course, the user can also modify and edit the KMS program. For example, after obtaining the CA certificate, KMS certificate, KMS public key, KMS private key and pubK2 / priK2 generated by the user-side server, the user can carry the CA certificate, KMS certificate, KMS public key and pubK2 in the KMS program and upload them to the cloud virtual machine.

[0078] Specifically, after the user reviews the KMS program locally and finds no abnormalities, the user can apply for a KMS certificate from the CA. Before applying for the KMS certificate from the CA, a pair of public and private keys, KMS private key and KMS public key, need to be generated for the reviewed KMS program, which are used as the identity of the KMS program. Then, the KMS public key and some attribute information of the user and the KMS program are provided to the CA, and the CA generates a KMS certificate corresponding to the KMS program of the user based on these information. The KMS certificate contains the KMS public key and CA signature information, wherein the CA signature information is simply the result of signing the attribute information using the CA private key (the private key in the public and private key pair of the CA) by the CA. In this way, the user-side device can obtain the KMS certificate and the CA certificate from the CA.

[0079] In addition, the user terminal device can further obtain a public key pubK2 of a public-private key pair (pubK2 / priK2) generated by the user terminal server from the user terminal server. The public-private key pair generated by the user terminal server is mainly used for the KMS program in the virtual machine to authenticate the identity of the user terminal server. When the user terminal device is the user terminal server, it can be understood that there is no need for the user terminal device to obtain the public key from the user terminal server.

[0080] The user terminal device can then edit the KMS certificate, the KMS public key, the CA certificate, and pubK2 into the audited KMS program, specifically, into the file declared as trusted code in the KMS program. That is, the file corresponding to the KMS program can include first program code as a trusted part and second program code as an untrusted part. The information is added to the trusted part, so that when deployed to the virtual machine subsequently, it is loaded into the trusted memory space together with the first program code.

[0081] It should be noted that priK2 is only stored in the user terminal server, but the KMS private key still needs to be stored in the trusted memory space of the cloud virtual machine. Because it is a private key, the transmission security has higher requirements. Generally, the transmission of the KMS private key is performed after the remote authentication of the trusted runtime environment of the user terminal server is completed, which will be described in detail below.

[0082] In practical applications, when the user terminal device side completes the audit of the KMS program and adds the related certificates and public keys of the asymmetric key to the KMS program, the user terminal device can upload the KMS program to the cloud virtual machine.

[0083] Specifically, the user can first generate a public-private key pair for signing the KMS program, which is used as the user identity identifier, wherein the user private key is represented as priK0 and the user public key is represented as pubK0.

[0084] Afterwards, the KMS program is signed using the pair of public and private keys. The signing algorithm can be implemented using tools provided in the prior art, and here only the core process is briefly described: first, according to the declaration results of the trusted part and the untrusted part in the KMS program, the trusted part, i.e., the first program code (the first program code in the following also contains some certificates, asymmetric keys and other sensitive data in the above example) is subjected to a hash calculation, and the calculation result is denoted as hash1. In fact, the hash1 is the measurement value of the first program code. Afterwards, the hash1 is encrypted using the user private key priK0, and the encryption result is taken as the signature result C1. Afterwards, the signature result C1, hash1, user public key pubK0, enclave attribute information (such as security version number, etc.), application identifier of the KMS program, etc. are all or partially packaged together with the KMS program into a file package, which can be referred to as a program image file package, and the file package is uploaded to the cloud virtual machine.

[0085] The virtual machine parses the file package and deploys a corresponding trusted running environment in the virtual machine according to the enclave attribute information therein. For example, the memory space is divided into trusted and untrusted parts, and the trusted memory space is subjected to encryption processing using corresponding confidential computing technology. Afterwards, after the trusted running environment is constructed, the first program code in the KMS program can be loaded into the trusted memory space, and the second program code can be loaded into the untrusted memory space.

[0086] Specifically, the virtual machine parses the user public key pubK0 from the file package, decrypts the signature result using the user public key pubK0 to obtain hash1, and performs the same hash calculation on the received first program code in the KMS program to obtain hash1'. If hash1 = hash1', it is determined that the KMS program has not been tampered with during the transmission process of uploading to the cloud, and the more core first program code therein has not been tampered with. Afterwards, the first program code in the KMS program is loaded into the trusted memory space, and the second program code is loaded into the untrusted memory space.

[0087] In addition, it should be noted that if the above file package is uploaded to the cloud by a user terminal device other than the user terminal server, the user terminal device also needs to send the above signature result C1 or hash1 and the user public key pubK0 to the user terminal server, and the user terminal server will use these information in the subsequent remote authentication process.

[0088] The above describes one implementation process of steps 301-302. After loading the first and second program codes from the KMS program into their respective memory spaces through this process, the user key can be protected based on the KMS program in the virtual machine. Because the first program code closely related to the generation and use of the user key, as well as some related sensitive data, are confined to the trusted memory space—a trusted runtime environment—and this trusted runtime environment is managed by the user, external objects such as cloud service providers cannot access this trusted runtime environment, thus ensuring the security of the user key and allowing the user to maintain zero trust in the cloud service provider.

[0089] The process of generating the user key in steps 303-304 above will be briefly explained below.

[0090] In the virtual machine, the vCPU can first generate a first public key pubK1 and a first private key priK1 by executing the code in the first program code that generates a public-private key pair. Then, the first public key pubK1 is sent to the client server through the service interface in the second program code that transmits the public and private keys.

[0091] The client-side server generates an entropy parameter, called the first entropy parameter, used to generate the user key. The client-side server then encrypts the first entropy parameter using the first public key pubK1 to obtain the ciphertext entropy parameter. Afterwards, the client-side server calls the service interface in the second program code used to transmit this entropy parameter (e.g., ...). Figure 1 The CMK generation interface (illustrated in the diagram) sends the ciphertext entropy parameter to the virtual machine side. Then, this service interface transmits the received ciphertext entropy parameter to the corresponding functional code in the trusted memory space, such as... Figure 1 The diagram illustrates the CMK generation code. This code is executed to decrypt the first entropy parameter based on the first private key priK1, and then generates the user's key based on the first entropy parameter. This user key is stored in a trusted memory space. For example, this user key is CMK.

[0092] In the above process, the generation of the user key requires the use of a first entropy parameter passed in by the user. To ensure security, this first entropy parameter needs to be transmitted in ciphertext. The asymmetric key required for encryption is generated by the first program code in the trusted memory space. The private key does not leave the trusted memory space and cannot be obtained from the outside.

[0093] In an optional embodiment, to ensure security, the KMS program on the virtual machine side can also authenticate the user-side server, and the authentication process needs to use the public key pubK2 generated by the user-side server and stored in the trusted memory space of the virtual machine mentioned above. Here, the public-private key pair generated by the user-side server is referred to as the second public key pubK2 and the second private key priK2, the second private key priK2 is stored locally on the user-side server, and the second public key pubK2 is loaded into the trusted memory space together with the first program code in the KMS program.

[0094] Based on this, after the user-side server encrypts the first entropy parameter using the first public key pubK1 to obtain the first ciphertext, the second private key priK2 is used to encrypt the first ciphertext to obtain the second ciphertext, and then the service interface for transmitting the entropy parameter in the second program code is called to send the second ciphertext to the virtual machine, such as the CMK generation interface shown in Figure 1 After that, the service interface transmits the received second ciphertext to the corresponding function code in the trusted memory space, such as the CMK generation code shown in Figure 1 The function code is run to decrypt the second ciphertext based on the second public key pubK2 to obtain the first ciphertext, and then decrypt the first ciphertext using the first private key priK1 to obtain the first entropy parameter, and generate the user's user key based on the first entropy parameter.

[0095] Wherein, the second public key pubK2 can successfully decrypt the first ciphertext, and the first private key priK1 can decrypt the first entropy parameter, which indicates that the user-side device has passed the identity authentication.

[0096] In summary, by loading the core program code and sensitive data related to the generation and use of the user key in the KMS program into the trusted memory space of the virtual machine, and loading the program code as a service interface into the untrusted memory space, the user-side server trusted by the user accesses the trusted memory space through these service interfaces, the trusted memory space is invisible to the cloud service provider other than the user, that is, the cloud service provider cannot access the trusted memory space, and the sensitive data such as the user key generated in the trusted memory space will not be written to the disk of the virtual machine, thereby ensuring the security of the user key. Because the disk of the virtual machine can be accessed by the cloud service provider.

[0097] Figure 4 A flowchart of a user key protection method provided for an embodiment of the application, which can be executed by a processor supporting confidential computing technology in a cloud virtual machine, as shown in Figure 4 The method comprises the following steps:

[0098] 401、Obtain the KMS program of the user, the first program code related to key generation and use in the KMS program is loaded into the trusted memory space, and the second program code other than the first program code is loaded into the untrusted memory space.

[0099] 402、In response to the authentication request of the user terminal server, send the running report of the first program code to the user terminal server through the second program code, so that the user terminal server completes the authentication of the running environment of the first program code and the authentication of the first program code based on the running report, wherein the running report includes the first public key generated by the first program code.

[0100] 403、Receive the ciphertext entropy parameter sent by the user terminal server through the second program code, which is obtained by encrypting the first entropy parameter with the first public key.

[0101] 404、Through the first program code, decrypt the first entropy parameter based on the first private key corresponding to the first public key, generate the user key of the user based on the first entropy parameter, and store the user key in the trusted memory space.

[0102] The remote authentication process triggered by the user terminal server is introduced in this embodiment. The remote authentication process mainly needs to complete the authentication of the running environment of the first program code and the authentication of the first program code.

[0103] In short, the user terminal server first needs to authenticate that the first program code and data in the enclave, i.e. the trusted memory space, are trusted (not tampered with), and at the same time, the enclave is executed in a correct and legal processor environment supporting confidential computing. Only when it is confirmed that the running environment of the first program code is trusted and the first program code is not tampered with, the first entropy parameter can be passed to the first program code, preventing the first entropy parameter from being leaked, which allows the attacker (including the cloud service provider) to calculate the user key.

[0104] As described in step 402 above, the above authentication process involves the interaction between the user terminal server and the virtual machine (vCPU), and in fact, in addition to this, a confidential computing authentication server also needs to be used.

[0105] In summary, obtaining the user's KMS program in step 401 can specifically involve obtaining the KMS program and the fourth public key contained in the public-private key pair used to sign the first program code from the user's terminal device. The fourth public key in this public-private key pair is the user's public key pubK0 mentioned above, and the corresponding fourth private key is the user's private key priK0. Based on this, the process of sending the execution report of the first program code to the user's terminal server via the second program code in step 402 can include: generating a first metric value corresponding to the first program code; generating an execution report, which includes the first metric value and the fourth public key pubK0; signing the execution report using the derived key R corresponding to the processor to obtain a first signature result, where the derived key R is allocated to the processor by the confidential computing authentication server; and sending the first signature result and the execution report to the user's terminal server so that the user's terminal server can verify the first signature result through the confidential computing authentication server to complete the authentication of the execution environment of the first program code.

[0106] Wherein, the first metric value and the fourth public key pubK0 are used to enable the client server to use the fourth public key pubK0 to verify the second signature result to obtain the second metric value, and compare the second metric value with the first metric value to complete the authentication of the first program code; wherein, the second signature result is obtained by the client device encrypting the second metric value generated by the first program code using the fourth private key priK0, and the client device and the client server may be the same or different.

[0107] For ease of understanding, combined with Figure 5 The above authentication process is illustrated in the diagram, where it is assumed that the user-end device is the user-end server.

[0108] Figure 5 An interactive flowchart of a remote authentication process for a client server provided in an embodiment of the present invention is shown below. Figure 5 As shown, the method includes the following steps:

[0109] 501. The client server sends an authentication request to the virtual machine.

[0110] Specifically, the client-side server calls Figure 1 The remote authentication interface in the untrusted memory space, as illustrated in the diagram, triggers the authentication request, and the remote authentication interface sends the authentication request to the corresponding authentication code in the trusted memory space.

[0111] 502. The virtual machine generates a running report of the first program code in the trusted memory space, and signs the running report using the derived key corresponding to the vCPU to obtain the first signature result. The running report includes the first metric value and the fourth public key corresponding to the first program code.

[0112] Specifically, the process of the vCPU in the virtual machine generating the running report can be: compiling the first program code in the trusted memory space, and then performing hash calculation to obtain a first measurement value hash2, and then generating the running report, wherein the running report contains hash2, the fourth public key pubK0, and the first public key pubK1. In addition, the running report can optionally include attribute information of the virtual machine side trusted running environment, such as an enclave security version number, a working mode, and the like, and can also include identification information of the vCPU, such as a product serial number.

[0113] The fourth public key pubK0 is stored in the trusted memory space when the KMS program is deployed to the virtual machine, and the first public key pubK1 can be temporarily generated by executing related code in the first program code.

[0114] Since the trusted running environment of the virtual machine is built, the virtual machine applies a derivative key corresponding to the vCPU from the confidential computing certification server, denoted as R. The derivative key R is actually a key generated according to a root key generated in the confidential computing certification server, and the derivative keys applied by different processors are different. Therefore, the derivative key R is actually the identity of the vCPU in the current virtual machine.

[0115] The process of signing the running report using the derivative key R corresponding to the vCPU can be: performing hash calculation on the running report to obtain hash3, and encrypting hash3 using the derivative key R to obtain a first signature result C3.

[0116] 503, the virtual machine sends the running report and the first signature result to the user terminal server.

[0117] Specifically, the running report and the first signature result are sent to the user terminal server through the remote authentication interface in the untrusted memory space.

[0118] 504, the user terminal server sends the running report and the first signature result to the confidential computing certification server.

[0119] 505, the confidential computing certification server verifies the first signature result based on the derivative key corresponding to the vCPU in the virtual machine.

[0120] 506, the confidential computing certification server sends indication information of passing the verification to the user terminal server.

[0121] The user-side server needs to authenticate the trusted running environment of the first program code by means of the confidential computing authentication server. Specifically, the confidential computing authentication server determines the derived key R corresponding to the vCPU in the current virtual machine according to the local key allocation record, decrypts the first signature result C3 using the derived key R to obtain hash3, performs hash calculation on the running report to obtain hash4, and if has3 = hash4, it is determined that the running report is signed by the legitimate hardware, i.e. the vCPU in the current virtual machine is indeed the hardware authorized by the confidential computing authentication server to provide corresponding confidential computing capability. At this time, the confidential computing authentication server sends indication information of signature pass to the user-side server.

[0122] 507、The user-side server extracts the fourth public key and the first metric value from the running report, and authenticates the first program code based on the fourth public key and the first metric value.

[0123] Specifically, as described above, before uploading the KMS program to the virtual machine in the cloud, the user-side device (which can be a user-side server) performs hash calculation on the first program code in the locally audited KMS program to obtain a second metric value hash1, and encrypts hash1 using a fourth private key priK0 to obtain a second signature result C1. The second signature result C1 can be stored in the user-side server, and the fourth public key pubK0 can also be stored in the user-side server.

[0124] Based on this, after the user-side server extracts the fourth public key pubK0 and the first metric value hash2 from the running report, the user-side server can compare whether the locally stored fourth public key pubK0 is consistent with the fourth public key extracted from the running report. If they are consistent, the second signature result C1 is decrypted using the fourth public key pubK0 to obtain hash1, and hash1 is compared with hash2 extracted from the running report to determine whether they are consistent. If they are consistent, it is determined that the first program code in the trusted memory space has not been tampered with.

[0125] After completing the authentication of the first program code, the user-side server can generate a first entropy parameter, encrypt the first entropy parameter based on the first public key pubK1 extracted from the running report, and transmit it to the first program code in the trusted memory space for user key generation.

[0126] Through the above remote authentication process, the user-side server provides the ciphertext entropy parameter to the first program code in the trusted memory space only when it confirms that the first program code has not been tampered with and is running in a correct and legitimate trusted running environment, thereby ensuring the security of the user key generated based on the entropy parameter.

[0127] Figure 6A flowchart of a user key protection method provided by an embodiment of the present application, which can be executed by a processor supporting confidential computing technology in a cloud virtual machine, is shown in FIG. 6. The method includes the following steps: Figure 6

[0128] 601. Obtain a key management service program of a user, load a first program code related to key generation and use in the key management service program to a trusted memory space, and load a second program code other than the first program code to an untrusted memory space.

[0129] 602. Generate a first public key through the first program code, and send the first public key to a user-side server through the second program code.

[0130] 603. Receive a ciphertext entropy parameter sent by the user-side server through the second program code, which is obtained by encrypting a first entropy parameter with the first public key.

[0131] 604. Decrypt the first entropy parameter based on a first private key corresponding to the first public key through the first program code, generate a user master key based on the first entropy parameter, and store the user master key in the trusted memory space.

[0132] 605. Receive a work key acquisition request sent by a cloud application through the second program code, which includes an authentication certificate of the cloud application.

[0133] 606. Verify the authentication certificate of the cloud application through the first program code, and generate an encryption and decryption key corresponding to the work key when the verification is passed.

[0134] 607. Generate a first work key corresponding to the work key acquisition request according to the user master key through the first program code, encrypt the first work key with the encryption and decryption key, and send the encrypted first work key to the cloud application through the second program code.

[0135] In the embodiment, the cloud application can be a certain cloud application deployed by the user in the cloud, such as a cloud game application, a cloud rendering application, etc.

[0136] In an optional embodiment, the work key acquisition request can also include a second entropy parameter generated by the cloud application, so that the first WK is generated according to the CMK and the second entropy parameter. That is, the CMK and the second entropy parameter can be taken as input parameters of the WK generation algorithm to calculate the corresponding first WK.

[0137] ​The second entropy parameter can avoid the problem that other cloud applications access the WK of the current cloud application by force, even if the first entropy parameter used to generate the CMK is leaked.

[0138] The steps 605-606 correspond to the KMS program (the authentication process of the cloud application). In fact, the cloud application can also authenticate the KMS program, that is, the two-way authentication is performed, and the first WK is generated for the cloud application based on the first program code after the two-way authentication is completed. The KMS program in the embodiment mainly refers to the first program code in the trusted memory space, because most of the work is completed by the first program. However, the cloud application interacts with the first program code through the second program code.

[0139] In general, the authentication process of the cloud application to the KMS program is that the virtual machine sends the authentication certificate (KMS certificate) of the KMS program stored in the trusted memory space to the cloud application through the second program code in response to the WK acquisition request, so that the cloud application verifies the KMS certificate.

[0140] After the cloud application and the KMS program complete the two-way authentication, the above-mentioned encryption and decryption key P is negotiated.

[0141] In the embodiment, when the cloud application of the user needs to use the WK derived from the CMK of the user for data encryption transmission for data security transmission, the WK acquisition request can be triggered to the virtual machine. Specifically, the WK acquisition request can be issued through the acquisition WK interface in the untrusted memory space as shown in FIG. 7, and then the WK acquisition request is sent to the corresponding WK generation code. The WK generation code can call the authentication code to complete the two-way authentication with the cloud application, and then generate the first WK. The first WK is fed back to the cloud application through the interface. Of course, some information such as the KMS certificate can also be transmitted to the cloud application through the interface in the authentication process. Figure 1

[0142] In practical application, in addition to the second entropy parameter and the authentication certificate of the cloud application (hereinafter referred to as the cloud application certificate), the WK acquisition request can also include a work key identifier. The work key identifier can be a sequential number starting from 0 or 1, which is used to indicate the number of the work key. Because the same cloud application can apply for a corresponding WK whenever data transmission is needed, the work key identifier can be used to distinguish different WK. The work key identifier can be converted into a string of characters according to a set algorithm, and the second entropy parameter, the CMK and the work key identifier are used as input parameters of the WK generation algorithm to generate the first WK corresponding to the work key identifier.

[0143] ​The mutual authentication process between the cloud application and the KMS program will be described in detail below. Here, it is only emphasized that after the mutual authentication of the two is completed, a symmetric key P can be negotiated for encrypting the generated first WK, and the encrypted first WK is fed back to the cloud application. The cloud application uses the symmetric key P to decrypt the first WK.

[0144] Optionally, the mutual authentication between the cloud application and the KMS program can be implemented by using a mutual Transport Layer Security (mTLS) protocol.

[0145] For ease of understanding, the following will be described in combination with Figure 7 The mutual authentication process between the cloud application and the KMS program will be described in detail below. Here, it is only emphasized that after the mutual authentication of the two is completed, a symmetric key P can be negotiated for encrypting the generated first WK, and the encrypted first WK is fed back to the cloud application. The cloud application uses the symmetric key P to decrypt the first WK. Figure 7 The mutual authentication process between the cloud application and the KMS program can include the following steps:

[0146] 701. The cloud application sends a handshake request to the KMS program.

[0147] 702. The KMS program sends a KMS certificate to the cloud application, and the KMS certificate includes a KMS public key.

[0148] 703. The cloud application verifies the legality of the KMS certificate using the CA certificate, and extracts the KMS public key from the KMS certificate.

[0149] 704. The cloud application sends a cloud application certificate to the KMS program, and the cloud application certificate includes a public key of the cloud application.

[0150] 705. The KMS program verifies the legality of the cloud application certificate using the CA certificate, and extracts the cloud application public key from the cloud application certificate.

[0151] 706. The KMS program and the cloud application negotiate a session encryption key using the public key of the other party.

[0152] The above embodiment only briefly introduces the mutual authentication process between the cloud application and the KMS program. In fact, it can be understood that the program code used for mutual authentication with the cloud application is actually the first program code located in the trusted memory space. However, the cloud application needs to call the corresponding second program code in the untrusted memory space to interact. For the convenience of description, the description of calling the program code is not shown in the above embodiment.

[0153] The process of the cloud application verifying the legality of the KMS certificate using the CA certificate in step 703 will be described below.

[0154] Since the CA certificate is public, the cloud application and the KMS program can download the CA certificate from the CA. As described above, for the KMS program, the CA certificate and the KMS certificate have been loaded into the trusted memory space in advance.

[0155] In fact, the KMS certificate includes the KMS public key, in addition to the signature result Cx of signing the KMS program related information using the CA private key in the CA certificate and the KMS program related information. Specifically, the KMS program related information can include the KMS public key and other attribute information of the KMS program, and the KMS program related information is hashed to obtain hash_x, and the CA private key is used to encrypt hash_x to obtain the signature result Cx.

[0156] After the cloud application receives the KMS certificate, the CA public key in the CA certificate is used to decrypt the signature result Cx to obtain hash_x, and the KMS program related information included in the KMS certificate is hashed to obtain hash_x', and if hash_x = hash_x', it is determined that the KMS certificate passes the signature verification, and the KMS public key is extracted from the KMS certificate.

[0157] The KMS program authenticates the cloud application in the same way. The cloud application certificate includes the public key of the cloud application, the signature result Cy of signing the cloud application information using the CA private key in the CA certificate, and the cloud application information. Specifically, the cloud application information can include the public key of the cloud application and other attribute information of the cloud application. The cloud application information is hashed to obtain hash_y, and the CA private key is used to encrypt hash_y to obtain the signature result Cy.

[0158] After the KMS program (i.e. the first program code) receives the cloud application certificate, the CA public key in the CA certificate is used to decrypt the signature result Cy to obtain hash_y, and the cloud application information included in the cloud application certificate is hashed to obtain hash_y', and if hash_y = hash_y', it is determined that the cloud application certificate passes the signature verification, and the public key of the cloud application is extracted from the cloud application certificate.

[0159] After the KMS program and the cloud application obtain the public key of the other party, a symmetric key P, i.e. a session encryption key, can be negotiated.

[0160] Simplified, the above key negotiation process can be:

[0161] The cloud application generates a first random number, encrypts the first random number using the KMS public key, and then transmits the encrypted first random number to the KMS program, i.e. to the first program code. In the first program code, the KMS private key is used to decrypt it to obtain the first random number.

[0162] Similarly, the KMS program side (in the above first program code) generates a second random number, encrypts the second random number using the public key of the cloud application, and then transmits the encrypted second random number to the cloud application, which decrypts it using the private key of the cloud application to obtain the second random number.

[0163] In this way, the KMS program and the cloud application both obtain the above two random numbers, and then generate the same symmetric key P by the same key generation algorithm using the two random numbers as input parameters. After generating the above first WK, the key P is used to encrypt and transmit it.

[0164] Through the above mutual authentication of the cloud application and the KMS program, the security of WK generation and access can be ensured.

[0165] As described above, in the process of negotiating the symmetric key P between the cloud application and the KMS program, the private key of the KMS program, KMS private key, needs to be used. Therefore, the KMS private key needs to be pre-stored in the trusted memory space to protect the KMS private key.

[0166] As described above, the user generates a pair of public and private keys as the identity of the KMS program: the third public key and the third private key, i.e., the KMS public key and the KMS private key. Because the public key is provided to other parties, the transmission of the public key does not have high security requirements, so the KMS public key can be uploaded to the virtual machine together with the first program code in the KMS program, and then loaded into the trusted memory space. However, the KMS private key has high security requirements and needs to be stored in the trusted memory space in a secure manner.

[0167] Figure 8 A flowchart of a KMS private key protection process provided by an embodiment of the application, which can be executed by the virtual machine side as described above. As shown in the flowchart, the process can include the following steps: Figure 8

[0168] 801. Receive the ciphertext private key sent by the user terminal server through the second program code, which is obtained by encrypting the third private key corresponding to the KMS program using the first public key by the user terminal server.

[0169] 802. Decrypt the third private key based on the first private key through the first program code, and store the third private key in the trusted memory space.

[0170] 803. Generate a second working key for encrypting the third private key according to the user master key through the first program code, and encrypt the third private key using the second working key; store the third private key encrypted using the second working key in the disk of the virtual machine through the second program code.​

[0171] 804、in response to the virtual machine being restarted, the encrypted third private key is loaded from the disk into the trusted memory space by the second program code, and the third private key is decrypted by the first program code using the second working key.

[0172] In the embodiment, the third private key is the KMS private key, the first public key is pubK1, the first private key is priK1, and the second working key is denoted as second WK.

[0173] As can be seen from the above steps, in the embodiment, the secure storage of the KMS private key is divided into three stages: an initial stage, a virtual machine shutdown stage, and a virtual machine restart stage.

[0174] The initial stage is the stage of storing the KMS private key into the trusted memory space for the first time. As described in step 801 above, after generating the first public key pubK1 and the first private key priK1 by the first program code and sending pubK1 to the user-side server, the user-side server can use pubK1 to encrypt the KMS private key and transmit it to the trusted memory space. Specifically, the second program code can include a service interface for transmitting the KMS private key, and the first program code also includes KMS private key storage code corresponding to the service interface.

[0175] As described above, the first public key pubK1 is also used to encrypt the first entropy parameter generated by the user-side server. Based on this, the KMS private key can be encrypted and transmitted by pubK1 together with the first entropy parameter, so that the service interface for transmitting the KMS private key in the second program code can be the same service interface as the service interface for transmitting the entropy parameter.

[0176] It can be understood that, whether it is a trusted memory space or an untrusted memory space, it is memory after all, and the information stored therein will be emptied after the virtual machine is shut down after running for a period of time. Therefore, when the virtual machine is shut down, the code related to KMS private key storage in the first program code in the trusted memory space is executed, and the function of the code is as follows: based on the CMK, a second WK is generated, the KMS private key is encrypted using the second WK, and the encrypted KMS private key is stored in the disk of the virtual machine. In fact, when the WK generation algorithm requires inputting the WK identifier as a parameter in addition to the CMK, a specific WK identifier can be pre-configured to be used to generate the second WK for encrypting the KMS private key, and the WK identifier is prohibited to be used by the user's cloud application. For example, setting WK identifier = 0 is used to generate the second WK.

[0177] Afterwards, when the virtual machine is started again, the service interface in the second program code for reading the KMS private key from the disk reads the encrypted KMS private key from the disk and passes it to the corresponding code in the first program code, which decrypts the KMS private key using the previously generated second WK and stores it in the trusted memory space. In this way, when the cloud application requests the WK subsequently, the KMS private key can be used to complete the mutual authentication process between the cloud application and the KMS program as described above.

[0178] Since the KMS private key is also encrypted by the second WK before being stored in the disk during the shutdown of the virtual machine, the generation and storage of the second WK are in the trusted memory space, and the second WK cannot be obtained by external objects such as cloud service providers, so the KMS private key cannot be obtained, thereby ensuring the security of the KMS private key.

[0179] The user key protection device of one or more embodiments of the present application will be described in detail below. Those skilled in the art can understand that these devices can be configured by using commercially available hardware components through the steps taught by the present application.

[0180] Figure 9 A structural schematic diagram of a user key protection device provided for an embodiment of the present application, which is applied to a virtual machine in the cloud, the virtual machine including a processor supporting confidential computing, an untrusted memory space, and a trusted memory space, as shown in Figure 9 The device includes a program deployment module 11, an entropy parameter transmission module 12, and a user key generation module 13.

[0181] The program deployment module 11 is configured to obtain a key management service program of a user, the key management service program including first program code related to key generation and use and second program code other than the first program code; wherein the first program code is loaded into the trusted memory space, and the second program code is loaded into the untrusted memory space.

[0182] The entropy parameter transmission module 12 is configured to generate a first public key through the first program code and send the first public key to a user server through the second program code; and receive a ciphertext entropy parameter sent by the user server through the second program code, the ciphertext entropy parameter being obtained by encrypting a first entropy parameter with the first public key by the user server.

[0183] The user key generation module 13 is configured to decrypt the first entropy parameter based on a first private key corresponding to the first public key through the first program code, and generate a user key of the user based on the first entropy parameter, the user key being stored in the trusted memory space.

[0184] Optionally, the entropy parameter transmission module 12 is specifically configured to: in response to an authentication request of the user-side server, send a running report of the first program code to the user-side server through the second program code, so that the user-side server completes authentication of a running environment of the first program code and authentication of the first program code based on the running report, wherein the first public key is included in the running report.

[0185] Optionally, the second public key of the user-side server is contained in the key management service program to be loaded into the trusted memory space; the ciphertext entropy parameter is a second ciphertext obtained by encrypting a first ciphertext obtained by encrypting a first entropy parameter by the first public key by the second private key of the user-side server after the user-side server encrypts the first entropy parameter by the first public key; the second public key and the second private key are a pair of public and private key pairs. Based on this, the entropy parameter transmission module 12 is specifically configured to: based on the second public key, decrypt the second ciphertext to obtain the first ciphertext through the first program code, and based on the first private key, decrypt the first ciphertext to obtain the first entropy parameter.

[0186] Optionally, the user key is a user master key, and the apparatus further comprises a working key processing module configured to: receive, through the second program code, a working key acquisition request sent by a cloud application, wherein the working key acquisition request includes an authentication certificate of the cloud application; verify the authentication certificate of the cloud application through the first program code, and generate an encryption and decryption key corresponding to a working key when the verification is passed; generate a first working key corresponding to the working key acquisition request according to the user master key through the first program code, and encrypt the first working key by using the encryption and decryption key; and send the encrypted first working key to the cloud application through the second program code.

[0187] Optionally, the working key acquisition request includes a second entropy parameter; and the first working key is generated according to the user master key and the second entropy parameter.

[0188] Optionally, the working key processing module is further configured to: in response to the working key acquisition request, send an authentication certificate of the key management service program stored in the trusted memory space to the cloud application through the second program code, so that the cloud application verifies the authentication certificate of the key management service program; and wherein the encryption and decryption key is negotiated when it is determined that the authentication certificate of the cloud application is verified and the cloud application determines that the authentication certificate of the key management service program is verified.

[0189] Optionally, the user key is a user master key, and the apparatus further comprises a private key protection module configured to receive a ciphertext private key sent by the user-side server through the second program code, the ciphertext private key being obtained by encrypting a third private key corresponding to the key management service program by the user-side server using the first public key; decrypt the third private key based on the first private key through the first program code, and store the third private key in the trusted memory space; wherein the authentication certificate of the key management service program is included in the key management service program to be loaded into the trusted memory space; the third public key corresponding to the key management service program is included in the authentication certificate of the key management service program, and the third public key and the third private key form a pair of public and private key.

[0190] Optionally, the private key protection module is further configured to: generate a second working key for encrypting the third private key according to the user master key through the first program code, and encrypt the third private key using the second working key; store the encrypted third private key in the disk of the virtual machine through the second program code; in response to the re-starting of the virtual machine, load the encrypted third private key from the disk to the trusted memory space through the second program code; and decrypt the third private key using the second working key through the first program code.

[0191] Optionally, the program deployment module 11 is specifically configured to: obtain the key management service program and a fourth public key included in a pair of public and private keys for signing the first program code from the user-side device. The entropy parameter transmission module 12 is specifically configured to: generate a first measurement value corresponding to the first program code; generate the running report, wherein the first measurement value and the fourth public key are included in the running report; sign the running report using a derived key corresponding to the processor to obtain a first signature result, wherein the derived key is assigned to the processor by a confidential computing certification server; and send the first signature result and the running report to the user-side server, so that the user-side server verifies the first signature result through the confidential computing certification server to complete the authentication of the running environment of the first program code. Wherein the first measurement value and the fourth public key are used to make the user-side server verify a second signature result using the fourth public key to obtain a second measurement value, and compare the second measurement value with the first measurement value to complete the authentication of the first program code; wherein the second signature result is obtained by encrypting the second measurement value using a fourth private key corresponding to the fourth public key after the user-side device generates the second measurement value from the first program code, and the user-side device is the same as or different from the user-side server.

[0192] Figure 9 The apparatus shown can perform the steps executed by the virtual machine in the foregoing embodiments, and the detailed execution process and technical effects are described in the foregoing embodiments, which will not be described here.

[0193] In one possible design, the above Figure 9 The structure of the user key protection apparatus shown can be implemented as an electronic device. As shown in the figure, Figure 10 The electronic device can include a processor 21, a memory 22, and a communication interface 23. The memory 22 stores executable code, and when the executable code is executed by the processor 21, the processor 21 can at least implement the user key protection method executed by the virtual machine in the foregoing embodiments.

[0194] In addition, the embodiment of the present application provides a non-transitory machine readable storage medium, which stores executable code, and when the executable code is executed by the processor of the electronic device, the processor can at least implement the user key protection method provided in the foregoing embodiments.

[0195] The apparatus embodiments described above are only schematic, and the units described as separate components can or can not be physically separate. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment. Those skilled in the art can understand and implement without creative labor.

[0196] From the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a general hardware platform, and of course can also be implemented by means of a combination of hardware and software. Based on such understanding, the above technical solutions can be embodied in the form of a computer program product, and the present application can be implemented in the form of a computer program product containing computer usable program code in one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.).

[0197] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A user key protection method, characterized in that, A virtual machine applied in the cloud, the virtual machine including a processor supporting confidential computing, an untrusted memory space, and a trusted memory space, the method comprising: The user's key management service program is obtained. The key management service program includes first program code related to key generation and use, and second program code other than the first program code. The first program code is loaded into the trusted memory space, and the second program code is loaded into the untrusted memory space. The user's second public key is included in the key management service program and is loaded into the trusted memory space. The first public key is generated by the first program code, and the first public key is sent to the client server by the second program code. The system receives a ciphertext entropy parameter sent by the user server through the second program code. The ciphertext entropy parameter is a second ciphertext obtained by encrypting the first entropy parameter with the first public key to obtain the first ciphertext, and then encrypting the first ciphertext with the second private key of the user server. The second public key and the second private key are a public-private key pair. The system uses the first program code to decrypt the second ciphertext based on the second public key to obtain the first ciphertext, and to decrypt the first ciphertext based on the first private key to obtain the first entropy parameter. The system generates a user key based on the first entropy parameter, and the user key is stored in the trusted memory space.

2. The method according to claim 1, characterized in that, Sending the first public key to the client server via the second program code includes: In response to the authentication request from the client server, the execution report of the first program code is sent to the client server through the second program code, so that the client server can complete the authentication of the execution environment of the first program code and the authentication of the first program code based on the execution report, wherein the execution report includes the first public key.

3. The method according to claim 1, characterized in that, The user key is the user master key, and the method further includes: The second program code receives a working key acquisition request sent by a cloud application, the working key acquisition request including the authentication certificate of the cloud application; The first program code verifies the authentication certificate of the cloud application and generates an encryption / decryption key corresponding to the working key when the verification is successful. The first program code generates a first working key corresponding to the working key acquisition request based on the user master key, and encrypts the first working key using the encryption / decryption key. The encrypted first working key is sent to the cloud application via the second program code.

4. The method according to claim 3, characterized in that, The working key acquisition request includes a second entropy parameter; The first working key is generated based on the user master key and the second entropy parameter.

5. The method according to claim 3, characterized in that, The method further includes: In response to the working key acquisition request, the second program code sends the authentication certificate of the key management service program stored in the trusted memory space to the cloud application, so that the cloud application can verify the authentication certificate of the key management service program; wherein, the encryption and decryption key is negotiated when the cloud application determines that the authentication certificate of the key management service program has been verified and when the cloud application determines that the authentication certificate of the key management service program has been verified.

6. The method according to any one of claims 1 to 5, characterized in that, The user key is the user master key, and the method further includes: The client receives a private key sent by the client server through the second program code. The private key is obtained by the client server encrypting the third private key corresponding to the key management service program using the first public key. The third private key is decrypted based on the first private key using the first program code, and then stored in the trusted memory space. The authentication certificate of the key management service program is included in the key management service program and is loaded into the trusted memory space; the authentication certificate of the key management service program includes the third public key corresponding to the key management service program, and the third public key and the third private key are a public-private key pair.

7. The method according to claim 6, characterized in that, The method further includes: The first program code generates a second working key for encrypting the third private key based on the user's master key, and the second working key is used to encrypt the third private key. The encrypted third private key is stored in the disk of the virtual machine through the second program code; In response to the restart of the virtual machine, the encrypted third private key is loaded from the disk into the trusted memory space via the second program code; The third private key is decrypted using the second working key through the first program code.

8. The method according to claim 2, characterized in that, The user key management service program includes: Obtain the key management service program and the fourth public key contained in the public-private key pair used to sign the first program code from the user terminal device; The step of sending the execution report of the first program code to the client server via the second program code includes: Generate the first metric value corresponding to the first program code; Generate the operation report, which includes the first metric and the fourth public key; The running report is signed using the derived key corresponding to the processor to obtain a first signature result, wherein the derived key is assigned to the processor by the confidential computing authentication server; The first signature result and the running report are sent to the client server, so that the client server can verify the first signature result through the confidential computing authentication server to complete the authentication of the running environment of the first program code. The first metric value and the fourth public key are used to enable the client server to use the fourth public key to verify the second signature result to obtain the second metric value, and to compare the second metric value with the first metric value to complete the authentication of the first program code; wherein, the second signature result is obtained by the client device encrypting the second metric value generated by the first program code using the fourth private key corresponding to the fourth public key, and the client device may be the same as or different from the client server.

9. An electronic device, characterized in that, include: The system includes a memory, a processor, and a communication interface; wherein the memory stores executable code, and when the executable code is executed by the processor, the processor performs the user key protection method as described in any one of claims 1 to 8.

10. A non-transitory machine-readable storage medium, characterized in that, The non-transitory machine-readable storage medium stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the user key protection method as described in any one of claims 1 to 8.

11. A user key protection system, characterized in that, include: The user-side server and the cloud-based virtual machine, wherein the virtual machine includes a processor supporting confidential computing, an untrusted memory space, and a trusted memory space; wherein the processor is used to perform the following steps: The user's key management service program is obtained. The key management service program includes first program code related to key generation and use, and second program code other than the first program code. The first program code is loaded into the trusted memory space, and the second program code is loaded into the untrusted memory space. The user's second public key is included in the key management service program and is loaded into the trusted memory space. The first public key is generated by the first program code, and the first public key is sent to the client server by the second program code. The client receives a ciphertext entropy parameter sent by the client server through the second program code. The ciphertext entropy parameter is a second ciphertext obtained by the client server encrypting the first entropy parameter with the first public key to obtain the first ciphertext, and then encrypting the first ciphertext with the second private key of the client server. The second public key and the second private key are a public-private key pair. The first program code decrypts the second ciphertext based on the second public key to obtain the first ciphertext, and decrypts the first ciphertext based on the first private key to obtain the first entropy parameter; the user's user key is generated based on the first entropy parameter, and the user key is stored in the trusted memory space; The client server is configured to encrypt the first entropy parameter using the first public key to obtain the ciphertext entropy parameter, and send the ciphertext entropy parameter to the virtual machine through the second program code.

12. The system according to claim 11, characterized in that, The user key is the user master key, and the processor is further configured to: The second program code receives a working key acquisition request sent by a cloud application, the working key acquisition request including the cloud application's authentication certificate and second entropy parameter; The first program code verifies the authentication certificate of the cloud application and generates an encryption / decryption key corresponding to the working key when the verification is successful. The first program code generates a first working key corresponding to the working key acquisition request based on the user master key and the second entropy parameter, and encrypts the first working key using the encryption / decryption key. The encrypted first working key is sent to the cloud application via the second program code.

Images