How to run applications securely

Abstract

The present invention relates to a method for securely executing an application on a second device, the memory space of the application including an execution enclave configured to access a memory of the second device storing sealed data obtained by the sealing enclave by sealing a predefined message on the first device with a first hardware key associated with the first device based on a value dependent on an identity of the sealing enclave, the method comprising: a) obtaining the sealed data in the memory (E1); b) obtaining an enclave identity of the execution enclave (E2); c) obtaining a second hardware key associated with the second device based on the obtained enclave identity and verifying using the obtained second hardware key and the obtained sealed data that the second device is authorized to execute the application (E3); d) if the verification is successful, continuing the execution of the application on the second device (E4).

Description

[Technical Field]

[0001] The present invention relates to virtualization and containerization solutions, and more particularly to a method for securely running applications on a device. [Background technology]

[0002] The ever-increasing bandwidth of high-speed networks and advances in virtualization and containerization solutions have made software execution increasingly hardware-agnostic. It is now easy to launch a program execution on a virtual server in a cloud service without having to deal with the hardware on which the program will run. Similarly, container systems and virtual machine solutions make it easy to deploy applications on multiple hardware systems and to seamlessly switch the execution of virtual machine or container instances from one machine to another.

[0003] Moving an application from one machine to another too easily can be problematic when, for security or legal reasons, execution should be limited to a few specific machines.

[0004] For example, it may be desirable to restrict execution to specific personal or corporate machines to prevent an attacker from cloning a virtual machine or container and later (re)starting it on their own computer in order to access secrets held by the application.

[0005] Similarly, when a program is executed on a cloud system, it may be desirable to prevent the program's execution from being migrated to a machine with lower security characteristics that is known to be part of a group of compromised machines or that is shared with other users of the cloud system, in order to prevent attackers from spying on the program's execution if different users' applications are not sufficiently isolated from each other.

[0006] Such an application may monitor the hardware machine on which it runs by querying the machine's operating system (OS) or hypervisor for information about that hardware, and may take appropriate action if it discovers that the machine on which it is running is either unauthorized or has been altered since the application's initialization. Nevertheless, such techniques can be defeated by a rogue OS or hypervisor, for example, when execution occurs on an attacker's computer.

[0007] Consequently, what is needed is a way to allow an application to check which hardware machine it is running on and whether this machine has changed since the application was initialized, without requiring the application to trust any lower-level programs (such as the OS or hyper-level) to do so. Summary of the Invention [Means for solving the problem]

[0008] To this end, and according to a first aspect, the present invention therefore provides a method for securely executing an application on a second device, wherein the memory space of said application comprises an execution enclave configured to access a memory of the second device storing sealed data obtained by said sealing enclave by sealing on said first device a predefined message using a first hardware key associated with said first device based on a value dependent on the identity of a sealing enclave; by the execution enclave to verify that the second device is authorized to run the application; a) obtaining the sealed data in the memory; - b) obtaining an enclave identity of said execution enclave; - c) obtaining a second hardware key associated with the second device based on the obtained enclave identity, and verifying, using the obtained second hardware key and the obtained sealed data, that the second device is authorized to run the application; - d) if the verification is successful, continuing to execute the application on the second device.

[0009] It allows checking the identity of a second device against the identity of a first device while preventing other software, such as an OS or hypervisor, from interfering with the verification process. It also allows checking that the same enclave is sealing the data and verifying the sealed data.

[0010] In one embodiment, the first and second hardware keys are derived from a first device hardware master key and the value that depends on the identity of the sealing enclave, and from a second device hardware master key and the value that depends on the identity of the execution enclave, respectively.

[0011] It allows the enclave to obtain a key that depends on both the hardware and the identity of the enclave. Using such a key, verification can only be successful if the sealing and executing enclaves for the first and second devices involved are a single enclave.

[0012] In a first embodiment, the sealed data is generated by the sealing enclave by encrypting the predetermined message and the value dependent on the identity of the sealing enclave using the first hardware key.

[0013] It allows for the generation of sealed data that can only be decrypted using the appropriate second hardware key. The decrypted data then allows for the identity of the execution enclave to be checked against the identity of the sealing enclave.

[0014] In a second embodiment, the sealed data is generated by the sealing enclave by using the first hardware key to generate a signature from the predetermined message and the value that depends on the identity of the sealing enclave.

[0015] It allows generating a signature that can only be verified using the appropriate second hardware key. The decrypted data then allows checking the identity of the Execution Enclave against the identity of the Sealing Enclave.

[0016] The value that depends on the identity of the sealing enclave may include a hash of data that includes the enclave code of the sealing enclave.

[0017] In one embodiment, the first hardware key and the second hardware key are sealing keys (SEAL_KEY) of the first device and the second device, respectively, according to SGX technology, which are obtained by the sealing enclave and the execution enclave, respectively, using the EGETKEY function of SGX technology.

[0018] Using SGX technology makes it possible to derive from the hardware of each device a key that is unique to this device and not visible outside the device.

[0019] The enclave identity may be the value of an enclave-specific field MRENCLAVE according to SGX technology.

[0020] Such a value can be effectively used to uniquely identify an enclave and make the sealed data dependent on the enclave's identity.

[0021] In another embodiment, the first and second hardware keys are obtained from the output of physical unclonable functions of the first and second devices, respectively, triggered by a sealing enclave and an execution enclave, respectively.

[0022] Using a PUF function makes it possible to obtain an output that is specific to the device hardware, and which cannot be copied to another device.

[0023] The verification that the second device is authorized to run the application includes: - unsealing the obtained sealed data using the obtained second hardware key to obtain unsealed data; - comparing the unsealed data with the predetermined message. may include:

[0024] Such a comparison allows for verification that the second hardware key can be successfully used to unseal the sealed data, thereby proving the relationship between the first device and the second device.

[0025] The steps a) to d) performed by the execution enclave may be performed at the initialization of the application or during its execution.

[0026] The verification that the second device is authorized to run the application may be verification that the second device is identical to the first device.

[0027] Such verification allows the application to verify that the device on which it is running has not been altered since the generation of the sealed data.

[0028] The first device and second device may belong to a group of trusted devices, a first hardware key may be a group signing key for the group of trusted devices, the signature generated by a sealing enclave may be a group signature that certifies that the first device belongs to the group of trusted devices, and verifying that the second device is authorized to run the application may be verifying that the second device is in the group of trusted devices by verifying the signature using the second hardware key as a group signing key.

[0029] It allows an application to check whether the second device on which the application runs is part of a group of trusted devices that includes the first device that executed the sealing enclave, and it allows defining such a group of trusted devices to which the application's execution can be migrated, ensuring that the application runs only on trusted devices.

[0030] The method according to the first aspect may include taking dedicated warning action or suspending execution of the application by the execution enclave when verification that the second device is authorized to run the application fails.

[0031] It allows an application to take action, such as preventing the application from running, when it discovers that it is running on an untrusted device.

[0032] In one embodiment, the application is a virtual machine under the control of a hypervisor, and the execution of steps a) to d) by an execution enclave is triggered by the virtual machine when the virtual machine is resumed after a previous shutdown or hibernation.

[0033] It allows the virtual machine to check on which device it will run after resuming, and it allows the virtual machine itself to prevent the application from running if it has been migrated to an untrusted device during its hibernation.

[0034] According to a second aspect, the present invention relates to a computer program product directly loadable into the memory of at least one computer, said computer program product comprising software code instructions for performing the steps of the method according to the first aspect of the invention when said product is executed on a computer.

[0035] According to a third aspect, the present invention provides a second device comprising a processor, a memory configured to store sealed data obtained by a sealing enclave by sealing on the first device a value that depends on a predefined message and an identity of the sealing enclave using a first hardware key and an input / output interface associated with the first device; A second device, wherein said processor and said input / output interface are configured to perform the steps of the method according to the first aspect of the invention.

[0036] To the accomplishment of the foregoing and related ends, the one or more embodiments comprise the features hereinafter fully described and particularly pointed out in the claims.

[0037] The following description and the annexed drawings set forth in detail certain illustrative aspects and indicate merely some of the various ways in which the principles of the embodiments may be employed. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the drawings, and the disclosed embodiments are intended to include all such aspects and their equivalents. [Brief explanation of the drawings]

[0038] [Figure 1] FIG. 2 is a schematic diagram of the execution of an application according to a first embodiment of the present invention; [Figure 2] FIG. 4 is a schematic diagram of the execution of an application according to a second embodiment of the present invention. [Figure 3] 1 is a schematic diagram of a device according to an embodiment of the present invention. [Figure 4] FIG. 1 is a schematic diagram of steps performed by a sealing enclave invoked by an application running on a first device according to an embodiment of the present invention. [Figure 5] FIG. 1 is a schematic diagram of the steps taken by an execution enclave that is invoked by an application when it is executed on a second device when the application wishes to verify that the second device is authorized to run the application according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0039] The present invention relates to a method for securely running an application on a device by enabling this application to check on which hardware machine it runs and whether this machine has changed since the application was initialized.

[0040] To do so, the first idea of ​​the present invention is to have the application, at some point during its execution on the first device, generate sealed data obtained by sealing a predetermined message and store it on the first device. Then, at a later time, when the application wants to check the hardware on which it runs, hereinafter referred to as the second device, the application can verify that the second device is authorized to run the application by accessing the memory of the second device that stores the sealed data and checking the authenticity of the sealed data stored in the second device memory.

[0041] The fact that the second device stores the correct sealed data is not sufficient proof that this device can be trusted. Therefore, the second idea of ​​the present invention is to make the cryptographic key used to generate and verify the sealed data dependent on the hardware machine running the application. By doing so, verification of the sealed data by the application on the second device will be successful only if the second device is the same as the first device or if they both belong to a trusted group of devices, i.e., the cryptographic key used to verify the sealed data, called the second hardware key, corresponds to the cryptographic key used to seal the data in the first place.

[0042] Finally, a third idea of ​​the present invention is to ensure that, when an application performs its verification of the sealed data, it truly has access to the second hardware key provided by the second device hardware and direct access to the hardware by having this verification performed by a protected side application isolated from other applications and even from other software with higher privileges (e.g., operating system, hypervisor). In the remaining description, such a side application will be referred to by the term "enclave," as used in SGX technology to describe such side applications. Nevertheless, as will become clear below, the present invention is not limited to the use of SGX technology to perform the sealing and verification operations. Using such an enclave can prevent attacks based on a compromised application or OS providing an incorrect key to the verifying process in order to hide the key truly provided by the second device hardware.

[0043] In the first embodiment shown in Figure 1, the application 101 is a standard application executed by the first or second device hardware 102 under the control of an OS 103 running on the machine. As will be explained hereafter, the sealing operations and the verification of the sealed data are performed by a software enclave 104 that is invoked by the application whenever needed.

[0044] In a second embodiment shown in Figure 2, the application is a virtual machine 201 under the control of a hypervisor 202 running on first or second device hardware 203. The hypervisor may be of Type 1, with direct access to the hardware 203, as shown in Figure 2. Alternatively, it may be of Type 2 and run on top of the host OS. In both cases, the virtual machine 201 includes a guest operating system, and the sealing and sealed data verification operations may be performed by an enclave of the guest OS that runs OS code, called an OS enclave 204, that is invoked by the application whenever necessary.

[0045] In a third embodiment, the application is a container executed by the first or second device hardware under the control of a container engine running on top of an OS running on the machine. As will be described hereinafter, in this embodiment, the sealing and sealed data verification operations are performed by a software enclave that is invoked by the application whenever needed.

[0046] 3 is a schematic diagram of a first device and a second device. It may include a processor 201 connected via a bus 202 to random access memory (RAM) 203, read-only memory (ROM) 204, and / or non-volatile memory (NVM) 205. It may further include a communication interface 206 used to connect the device to various forms of wireless networks, such as a wide area network, a WiFi network, or a cellular network. Alternatively, such a device may connect to a network via a wired network connection such as Ethernet. The device may also include an input / output interface 207 that provides an interface to a user of the device, such as one or more screens, loudspeakers, a mouse, a tactile surface, a keyboard, etc.

[0047] The first and second devices may be, for example, personal computers or computer servers, which may be part of a cloud infrastructure that performs remote computation for cloud services.

[0048] The following paragraphs describe steps taken by an enclave, hereafter referred to as a sealing enclave, invoked by an application running on a first device to leave a trace dependent on the identity of the first device, allowing subsequent verification of the device running the application, as illustrated in FIG. 4.

[0049] In a first sealing step S1, the sealing enclave obtains its identity, which may for example be an enclave code that uniquely identifies the sealing enclave.

[0050] In a second sealing step S2, the sealing enclave obtains a first hardware key associated with the first device.

[0051] In a first embodiment, providing a cryptographic key associated with device hardware relies on SGX technology. In such a case, the first hardware key may be a sealing key SEAL_KEY of the first device according to SGX technology, which the sealing enclave may obtain using the EGETKEY function of SGX technology. In such a case, the enclave identity obtained in the first sealing step may be an enclave-specific field MRENCLAVE according to SGX technology.

[0052] In a second embodiment, the first device may include a physical unclonable function (PUF), and the sealing enclave may obtain the first hardware key from the output of the PUF. For example, the sealing enclave may trigger the PUF using a predefined input challenge, which may derive the first hardware key from the PUF's response to the challenge.

[0053] In both embodiments, the first hardware key may be derived from the first device hardware master key and from a value that depends on the obtained identity of the sealing enclave. For example, the first device may store a root sealing key, and field MRENCLAVE may be used as an argument to the EGETKEY function to derive the first hardware key from the root sealing key and field MRENCLAVE. When using a PUF, the first hardware key may be derived from the output of the PUF and from a value that depends on the obtained identity of the sealing enclave.

[0054] In the third sealing step S3, the sealing enclave generates sealed data by sealing a predetermined message using the obtained first hardware key based on a value that depends on the identity of the sealing enclave. When the first hardware key was derived from the identity of the sealing enclave, the result of such sealing naturally depends on the identity of the sealing enclave. When the first hardware key does not depend on the identity of the sealing enclave, the sealing enclave may generate sealed data by sealing a value that depends on both the predetermined message and the identity of the sealing enclave.

[0055] In a first embodiment, the sealing enclave may seal by, for example, performing encryption. The sealing enclave may encrypt only a predetermined message using a first hardware key when the first hardware key is derived from the sealing enclave identity or a concatenation of the predetermined message and a value that depends on the obtained enclave identity. Such encryption may be performed using, for example, the Advanced Encryption Standard (AES), Elliptic Curve Encryption Scheme (ECIES), and RSA.

[0056] In a second embodiment, the sealing enclave may seal by generating a signature: the sealing enclave may sign only a predefined message using a first hardware key when the first hardware key was derived from the sealing enclave identity or a value that depends on the predefined message and the obtained enclave identity.

[0057] In both embodiments, the obtained enclave identity dependent value can be a hash of data containing the enclave code of the sealing enclave or an enclave specific field MRENCLAVE.

[0058] In a fourth sealing step S4, the sealing enclave may store the generated sealed data in non-volatile memory of the first device to enable subsequent verification of the hardware running the application using the sealed data.

[0059] These sealing steps may occur at the initialization of the application, during its execution, or at the end of the application's execution. For example, when the application is a container or virtual machine, these steps may occur when the application is shut down or when it goes into hibernation.

[0060] The following paragraphs describe the steps performed by an enclave, hereafter referred to as the execution enclave, that is invoked by an application when it is executed on a second device when the application wishes to verify that the second device is authorized to run the application, as illustrated in FIG. 5.

[0061] In a first execution step E1, the execution enclave obtained the sealed data in the memory of the second device, which were produced by the sealing enclave as described above in the sealing steps S1 to S4.

[0062] In a second execution step E2, the execution enclave obtains its own enclave identity. As explained above with respect to the sealing enclave identity, such identity may be, for example, an enclave code that uniquely identifies the execution enclave, or an enclave-specific field MRENCLAVE according to SGX techniques.

[0063] In a third execution step E3, the execution enclave obtains a second hardware key associated with the second device based on the obtained enclave identity and verifies, using the obtained second hardware key and the obtained sealed data, that the second device is authorized to execute the application.

[0064] As described above with respect to the first hardware key, the second hardware key may be a sealing key SEAL_KEY of the second device according to SGX technology, which the execution enclave may obtain using the EGETKEY function of SGX technology. Alternatively, the second device may include a physical unclonable function (PUF), and the execution enclave may obtain the second hardware key from the output of the PUF, as described above with respect to the first hardware key. The second hardware key may be derived from the second device hardware master key and from a value that depends on the obtained identity of the execution enclave.

[0065] Such verification may include an unsealing step in which the execution enclave unseals the obtained sealed data using a second hardware key to obtain unsealed data. It may also include a comparing step in which the execution enclave compares the unsealed data with a predetermined message. When the sealed data has been generated by sealing both a predetermined message and a value that depends on the identity of the sealing enclave, this step may also include comparing the unsealed data with the obtained enclave identity of the execution enclave.

[0066] Alternatively, when the sealed data includes a signature of the data, such verification may consist in verifying this signature using a predetermined message and, if necessary, the obtained enclave identity of the executing enclave.

[0067] In the first embodiment, the verification that the second device is authorized to run the application is a verification that the second device is identical to the first device, i.e., that the device currently running the application is the very same device that generated the sealed data. To ensure this, the execution enclave may, for example, check that the unsealed data is identical to a known, predefined message and, if a sealing enclave identity was included in the sealed data, that it is identical to the obtained enclave identity. The sealed data can be successfully unsealed only if the second hardware key is identical to the first hardware key, resulting in successful verification. Because the hardware key is tied to the hardware and cannot be tampered with by another application or the OS / hypervisor thanks to the enclave, this is proof that the device running the execution enclave is the same device that executed the sealing enclave. Such verification also verifies that the enclave identity remains the same, either by inclusion of the enclave identity in the sealed data or by reliance of the first and second hardware keys on the enclave identity, which ensures that the sealed data was generated by the same enclave and not by a different enclave invoked by a different application on the same hardware machine.

[0068] In a second embodiment, verifying that the second device is authorized to run the application is verifying that the second device is in a group of trusted devices using a group signature. To do so, each device belonging to this group may store a group signature key that depends on the device's hardware and that allows the device to either generate a signature attesting to its membership in the group as sealed data or to verify the group signature on sealed data.

[0069] In such a case, the first hardware key is such a group signature key for a group of trusted devices, the signature generated by the sealing enclave is a group signature that proves that the first device belongs to this group of trusted devices, and verification that the second device is authorized to run the application is verification that the second device is in said group of trusted devices by verifying the signature using the second hardware key as the group signature key. In such a case, verification of the signature using the second hardware key is successful only if the second device truly belongs to the group of trusted devices. Otherwise, it does not possess a group signature key for this group, and verification using a key that is not a group signature key for the group fails. In the case of SGX technology, such a group signature mechanism may be based on a Root Provisioning Key that is specific to each machine of the device but known by the CPU manufacturer, which allows deriving a group signature key for a given group of devices based on the group signature.

[0070] These execution steps may occur at the initialization of the application or during its execution. For example, when the application is a container or virtual machine, these steps may occur when the application is resumed after shutdown or hibernation.

[0071] When the verification that the second device is authorized to run the application is successful, the execution of the application continues on the second device in a fourth execution step E4.

[0072] When the verification that the second device is authorized to run the application fails, it means that the second device is neither the same as the first device nor another device in the group of trusted devices. In such cases, the execution enclave may take dedicated warning actions, such as sending a warning message to the application or sending a warning email to the user, signaling an external entity, destroying all its secrets, or suspending the execution of the application.

[0073] The security mechanism according to the present invention can be bypassed by an attacker by preventing an application from invoking an execution enclave that verifies that the second device is authorized to run the application. To enforce the use of an enclave, OS code running on the second device, either natively or within a virtual machine, can be modified so that critical services or functions of the OS, such as the Linux ELF loader, include, at the beginning of their execution, calls to an execution enclave that triggers verification that the second device is authorized. By doing so, such critical services will not run unless the enclave is invoked and the second device is successfully recognized as the same as the first device or as belonging to the same group of trusted devices.

[0074] According to a second aspect, the present invention relates to a computer program product directly loadable into the memory of at least one computer, said computer program product comprising software code instructions for performing the steps of the methods described hereinbefore when said product is executed on a computer.

[0075] According to a third aspect, the present invention provides a second device comprising a processor, a memory configured to store sealed data obtained by a sealing enclave by sealing on the first device a value that depends on a predefined message and an identity of the sealing enclave using a first hardware key and an input / output interface associated with the first device; a second device, wherein said processor and said input / output interface are configured to perform the steps of the method previously described herein.

Claims

1. A method for securely executing an application (101) on a second device (102, 203), comprising: the memory space of the application includes an execution enclave (104, 204) configured to access a memory (205) of a second device that stores sealed data obtained by the sealing enclave by sealing a predetermined message on the first device using a first hardware key associated with the first device based on a value that depends on the identity of a sealing enclave; by the execution enclave to verify that the second device is authorized to run the application; a) obtaining the sealed data in the memory (E1); b) obtaining an enclave identity of said execution enclave (E2); c) obtaining a second hardware key associated with the second device based on the obtained enclave identity, and verifying that the second device is authorized to run the application using the obtained second hardware key and the obtained sealed data (E3); d) If the verification is successful, continuing the execution of the application on the second device (E4). Including, wherein the first and second hardware keys are derived from a first device hardware master key and the value that depends on the identity of the sealing enclave, and from a second device hardware master key and a value that depends on the identity of the execution enclave, respectively.

2. 2. The method of claim 1, wherein the sealed data is generated by the sealing enclave by encrypting the predetermined message and the value that depends on the identity of the sealing enclave using the first hardware key.

3. 2. The method of claim 1, wherein the sealed data is generated by the sealing enclave by using the first hardware key to generate a signature from the predetermined message and the value that depends on the identity of the sealing enclave.

4. 4. The method of claim 1, wherein the value dependent on the identity of the sealing enclave comprises a hash of data including the enclave code of the sealing enclave.

5. 4. The method of claim 1, wherein the first and second hardware keys are sealing keys (SEAL_KEY) of the first and second devices, respectively, according to SGX technology, and are obtained by a sealing enclave and an execution enclave, respectively, using an EGETKEY function of the SGX technology.

6. 6. The method of claim 5, wherein the enclave identity is the value of an enclave-specific field MRENCLAVE according to SGX technology.

7. 4. The method of claim 1, wherein the first and second hardware keys are obtained from outputs of physical unclonable functions of the first and second devices, respectively, triggered by a sealing enclave and an execution enclave.

8. The verification that the second device is authorized to run the application includes: unsealing the obtained sealed data using the obtained second hardware key to obtain unsealed data; comparing the unsealed data with the predetermined message; 4. The method of claim 1, comprising:

9. 4. The method of claim 1, wherein steps a) to d) performed by an execution enclave are performed at the initialization of the application or during its execution.

10. The method of claim 1 , wherein the verification that the second device is authorized to run the application is a verification that the second device is identical to the first device.

11. 4. The method of claim 3, wherein the first device and the second device belong to a group of trusted devices, a first hardware key is a group signing key for the group of trusted devices, the signature generated by a sealing enclave is a group signature that certifies that the first device belongs to the group of trusted devices, and verifying that the second device is authorized to run the application is verifying that the second device is in the group of trusted devices by verifying the signature using the second hardware key as a group signing key.

12. 4. The method of claim 1, further comprising: when verification that the second device is authorized to run the application fails, taking dedicated warning actions or suspending execution of the application by the execution enclave.

13. 4. The method of claim 1, wherein the application is a virtual machine under the control of a hypervisor, and wherein the execution of steps a) through d) by an execution enclave is triggered by the virtual machine when the virtual machine is resumed after a previous shutdown or hibernation.

14. A computer program directly loadable into the memory of at least one computer, said computer program comprising software code instructions for performing the method according to any one of claims 1 to 3, when said computer program is run on a computer.

15. a second device (102, 203) comprising a processor (201) and a memory (205), the memory (205) configured to store sealed data obtained by the sealing enclave by sealing on the first device a predetermined message and a value depending on the identity of the sealing enclave using a first hardware key associated with the first device and an input / output interface (207); A second device (102, 203), wherein the processor and the input / output interface are configured to perform the method of any one of claims 1 to 3.

Images