WO2018162060A1

WO2018162060A1 - Methods and devices for attesting an integrity of a virtual machine

Info

Publication number: WO2018162060A1
Application number: PCT/EP2017/055491
Authority: WO
Inventors: Mihai SERB; Ioan-Silviu VLASCEANU
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2017-03-08
Filing date: 2017-03-08
Publication date: 2018-09-13
Also published as: CN110770729B; CN110770729A

Abstract

The present invention relates to a method for attesting, by an attestation server (230), an integrity of a virtual machine (VM) supported by a hypervisor (HV) running on a server (210). The method comprises the steps of encrypting a first nonce using a virtual endorsement key, vEK, sending a VM attestation request to the VM (212) and a HV attestation request to the HV (214), wherein the VM attestation request comprises the encrypted first nonce, receiving a VM attestation report from the VM (212), the VM attestation report being generated by the VM (212), and a HV attestation report from the HV (214), the HV attestation report being generated by the HV (214), verifying whether the VM attestation report is based on the first nonce, and validating the integrity of the VM (212) on the basis of the verification of the VM attestation report and on the basis of the HV attestation report. Moreover, the invention relates to a corresponding system (200) as well as corresponding servers (230, 210).

Description

METHODS AND DEVICES FOR ATTESTING AN INTEGRITY OF A VIRTUAL

MACHINE

TECHNICAL FIELD

In general, the present invention relates to the field of attestation of virtualizable computer systems. More specifically, the present invention relates to methods and devices for attesting an integrity of a virtual machine. BACKGROUND

The trusted computing group (TCG) has defined some means through which a software integrity of a platform can be measured and, subsequently, validated by a remote verifier or attestation server. The process of validating the integrity of a platform is called attestation or remote attestation (see "TCG PC Client Specific Implementation

Specification for Conventional BIOS", http://www.trustedcomputinggroup.org/wp- content/uploads/TCG_PCCIientlmplementation_1 -21_1_00.pdf) in order to highlight the fact that the validation of the integrity measurements should be performed by an entity which does not run on the platform which is being attested.

With the advent of virtualization software, a new direction in remote attestation research has begun, namely the remote attestation of virtual platforms. In particular, the TCG has defined (see "Virtualized Trusted Platform Architecture Specification",

http://www.trustedcomputinggroup.org/wpcontent/uploads/TCG_VPWG_Architecture_V1 - 0_R0-26_FINAL.pdf) two basic requirements for a remote attestation of a virtual platform: deep attestation and layer binding.

In order to better illustrate how the remote attestation of a virtual platform can be performed, in figure 1 , a schematic diagram of different components of a server is shown, wherein a hypervisor (HV) supporting virtual trusted platform modules (vTPMs) and virtual core roots of trust for measurement (vCRTMs) is running on a physical platform (compute node) supporting a physical core root of trust for measurement (pCRTM) and a physical trusted platform module (pTPM). Moreover, two virtual machines (VM) are running on the hypervisor. The virtual machines VMs rely on virtual roots of trust (vRoTs) which are implemented in software and are equivalent to the physical roots of trust (pRoTs) of a physical platform. The vRoT run on the hypervisor and assist in the attestation process of the virtual machine or platform they are assigned to. They are also considered inherently trusted in the virtual platform itself, because (as in the case of pRoTs), they use a different execution domain from the one of the software of which they should attest the integrity. In the case of the pRoTs, an execution domain separation is provided by the fact that the pRoTs execute within a different chip (i.e., the pTPM). In the case of vRoTs, the execution domain separation is provided by the capabilities of the hypervisor or virtualization layer to separate the execution of the virtual platform code from the HV code where the vRoTs are executed. Moreover, the pTPMs and the vTPMs provide implementations of the pRoTs/ vRoTs required to enable a remote attestation of physical platforms or virtual platforms, respectively. As mentioned above, the vRoTs are software components running in a different execution environment than the one of the software which should be attested. According to the deep attestation requirements, for a remote attestation of a virtual platform or machine, it is required to validate not only the measurements of its software, but also the measurements of the underlying virtualization layer which implements the vRoTs. This can be achieved by using a remote attestation for both the virtualization layer or HV and the virtual platform or VM and only make a judgment on the integrity status of the later based on the combined result of its measurements validation and that of the virtualization layer.

A successful validation of the virtualization layer measurements by means of a remote attestation, as required by a deep attestation, provides some guarantees that the vRoTs (implemented in the virtualization layer or HV) have not been tampered and the virtualization layer is behaving as expected.

From this validation result, it may also be inferred that the virtualization layer has assigned the correct set of vRoT instances (e.g., vCRTM and vTPM instances) to the virtual platform. This, however is not enough for the following reasons. The virtualization layer is responsible for running sets of vRoT instances of multiple virtual platforms, but there is no explicit guarantee provided regarding the assignment of a specific set of vRoT instances to a specific virtual platform. There is not even an explicit guarantee that the set of vRoT instances assigned to the virtual platform are indeed running on that virtualization layer. This issue is also called by the TCG the layer binding problem (see the above mentioned reference "Virtualized Trusted Platform Architecture Specification"). The remote verifier should be provided proof that the virtual platform is using the specified set of vRoT instances running on the specified virtualization layer. In the absence of such a proof, the reliability of the integrity validation result is diminished, since there is uncertainty regarding the vRoTs used to generate the integrity report and the validation result itself cannot be fully trusted.

In view of the above, a remote attestation procedure that does not fulfill the requirements of deep attestation and layer binding can still be able to calculate an integrity status for a virtual platform, however the relevance of this status can be questionable. In particular, in absence of the guarantees provided by deep attestation and layer binding, it can be difficult to determine whether the virtual roots of trust (vRoTs) the virtual platform relies on have been tampered or falsified. Conversely, a remote attestation procedure that fulfills the requirements of deep attestation and layer binding ensures trust in the vRoTs (and the integrity reports generated by them) as they effectively become part of the so-called chain of trust starting from the hardware RoT, e.g., the physical core root of trust measurement (pCRTM) and the physical TPM (see "TCG Attestation PTS Protocol: Binding to TNC IF-M",

http://www.trustedcomputinggroup.org/resources/tcg_attestation_pts_protocol_binding_to _tnc_ifm).

However, a solution which allows to implement both the deep attestation and layer binding requirements on a software level in an efficient scalable manner has not yet been provided.

In WO2016085592 A1 , a scalable solution addressing the deep attestation and layer binding problem is described, wherein the solution is based on secure enclaves (i.e. Intel SGX technology) to provide evidence that the vTPM is running on the specified HV. The solution both scales and fulfills the requirements of deep attestation and layer binding, however it is highly dependent on the specific hardware support in the physical platform (i.e. SGX support, TXT support, write-once registers, etc.).

Thus, there is a need for improved methods and devices for attesting the integrity of a virtual machine. SUMMARY

It is an object of the invention to provide for an improved methods and devices for attesting the integrity of a virtual machine. The devices may be computing devices such as data center servers, personal computers or terminal devices. Throughout the description the word server refers to a device as defined above.

The foregoing and other objects are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, the invention relates to a method for attesting, by an attestation server, an integrity of a virtual machine (VM) supported by a hypervisor (HV) running on a server, the method comprising the steps of encrypting a first nonce using a virtual endorsement key, vEK, sending a VM attestation request to the VM and a HV attestation request to the HV, wherein the VM attestation request comprises the encrypted first nonce, receiving a VM attestation report from the VM, the VM attestation report being generated by the VM, and a HV attestation report from the HV, the HV attestation report being generated by the HV, verifying whether the VM attestation report is based on the first nonce, and validating the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation report.

In a first possible implementation form of the method according to the first aspect as such, the method further comprises the steps of verifying whether the HV attestation report includes the vEK and the first nonce, and validating the integrity of the VM if the VM attestation report is based on the first nonce and if the HV attestation report includes the vEK and the first nonce.

In a second possible implementation form of the method according to the first aspect as such or the first implementation form thereof, the encrypting of the first nonce is performed according to a privacy certificate authority (PCA) protocol defined by the trusted computing group (TCG).

According to a second aspect, the invention relates to a method for generating attestation reports, by a virtual machine (VM) and by a hypervisor (HV) running on a server, the method comprising the steps of receiving, by the VM, a VM attestation request, and, by the HV, a HV attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK, decrypting, by a virtual trusted platform module, vTPM, running on the HV, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM, receiving, by the VM, a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, generating, by the VM, a VM attestation report about the VM, the VM attestation report comprising the first quote, and generating, by the HV, a HV attestation report about the HV.

In a first possible implementation form of the method according to the second aspect as such, the method further comprises the steps of storing, by the vTPM, the first nonce and the vEK, the stored first nonce and the vEK being accessible by the HV, and reading, by the HV, the stored first nonce and the vEK, wherein the generated HV attestation report includes the stored first nonce and the vEK.

In a second possible implementation form of the method according to the second aspect as such or the first implementation form thereof, the method further comprises the steps of hashing, by the VM, the first nonce, generating, by the VM, the first quote on the basis of the hashed first nonce, hashing, by the HV, the first nonce and the vEK, receiving, by the HV, a second quote from a physical trusted platform module (pTPM) of the server, wherein the second quote is generated on the basis of the hashed first nonce and of the vEK and wherein the second quote is signed with a physical attestation identity key (pAIK), and including, by the HV, the second quote in the HV attestation report about the HV.

According to a third aspect, the invention relates to an attestation server for attesting an integrity of a virtual machine (VM) supported by a hypervisor (HV) running on a server, wherein the attestation server comprises a processor configured to encrypt a first nonce using a virtual endorsement key, vEK, and a transmitting unit configured to send a VM attestation request to the VM and a HV attestation request to the HV, wherein the VM attestation request comprises the encrypted first nonce, and a receiving unit configured to receive a VM attestation report from the VM, the VM attestation report being generated by the VM, and a HV attestation report from the HV, the HV attestation report being generated by the HV, and wherein the processor is further configured to verify whether the VM attestation report is based on the first nonce, and to validate the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation report. The transmitting and receiving unit may be implemented by a transceiver or by separate independent units. In a first possible implementation of the attestation server according to the third aspect as such, the attestation sever comprises a public part of the vEK (VEK_PUB), a public part of a virtual attestation identity key vAIK (VAI K_PUB), a public part of a physical endorsement key pEK (pEKpuEs) and a public part of a physical attestation identity key pAIK (PAI K_PUB), and wherein the processor is further configured to validate the integrity of the VM by means of the VM attestation report, of the VAI K_PUB and of the VEK_PUB, and to validate the integrity of the HV by means of the HV attestation report, of the pAIK_PUB and of the pEK_PUB-

According to a fourth aspect the invention relates to a server which is configured to run a virtual machine (VM) and a hypervisor (HV), wherein the virtual machine VM is configured to receive a VM attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK, wherein the hypervisor HV is configured to receive a HV attestation request, to decrypt, by a virtual trusted platform module, vTPM, running on the HV, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM, wherein the virtual machine VM is furthermore configured to receive a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, and to generate a VM attestation report about the VM, the VM attestation report comprising the first quote, and wherein the hypervisor HV is furthermore configured to generate a HV attestation report about the HV.

According to a fifth aspect the invention relates to a system comprising an attestation server and a server, wherein the attestation server comprises a processor configured to encrypt a first nonce using a virtual endorsement key, vEK; and a transceiver configured to send a VM attestation request to the VM and a HV attestation request to the HV, wherein the VM attestation request comprises the encrypted first nonce, and to receive a VM attestation report from the VM, the VM attestation report being generated by the VM, and a HV attestation report from the HV, the HV attestation report being generated by the HV, wherein the processor is further configured to verify whether the VM attestation report is based on the first nonce, and to validate the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation report, and wherein the server comprises a virtual machine (VM) and a hypervisor (HV) running on the server, wherein the virtual machine VM is configured to receive a VM attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK, wherein the hypervisor HV is configured to receive a HV attestation request, to decrypt, by a virtual trusted platform module, vTPM, running on the HV, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM, wherein the virtual machine VM is furthermore configured to receive a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, and to generate a VM attestation report about the VM, the VM attestation report comprising the first quote, and wherein the hypervisor HV is furthermore configured to generate a HV attestation report about the HV.

According to a sixth aspect, the invention relates to a computer program comprising a program code for performing the method of the first aspect or any one of the

implementation forms thereof or the method of the second aspect or any one of the implementation forms thereof when executed on a computer.

The invention can be implemented in hardware and/or software. BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments of the invention will be described with respect to the following figures, wherein: Fig. 1 shows a schematic diagram of server comprising a hypervisor and two virtual machines;

Fig. 2 shows a schematic diagram of a system comprising an attestation server and a server comprising a hypervisor and a virtual machine according to an embodiment;

Fig. 3 shows a schematic diagram of a system comprising an attestation server and a server comprising a hypervisor and a virtual machine according to an embodiment;

Fig. 4 shows a schematic diagram of a system comprising an attestation server and a server comprising a hypervisor and a virtual machine according to an embodiment; Fig. 5 shows a schematic diagram illustrating several steps of a method for attesting an integrity of a virtual machine according to an embodiment;

Fig. 6 shows a schematic diagram illustrating several steps of a method for attesting an integrity of a hypervisor according to an embodiment;

Fig. 7 shows schematic diagram of a method for attesting an integrity of a virtual machine according to an embodiment; and Fig. 8 shows a schematic diagram of a method for generating attestation reports by a virtual machine and by a hypervisor running on a server according to an embodiment.

In the various figures, identical reference signs will be used for identical or at least functionally equivalent features.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In the following description, reference is made to the accompanying drawings, which form part of the disclosure, and in which are shown, by way of illustration, specific aspects in which the present invention may be placed. It is understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, as the scope of the present invention is defined by the appended claims. For instance, it is understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if a specific method step is described, a corresponding device may include a unit to perform the described method step, even if such unit is not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary aspects described herein may be combined with each other, unless specifically noted otherwise.

Figure 2 shows a schematic diagram of a system 200 comprising an attestation server 230 and a server 210 comprising a hypervisor 214 and a virtual machine 212 according to an embodiment. In one embodiment, the attestation server 230 and the server 210 can communicate via a communication channel 220, for instance, a wired or wireless communication channel 220. The attestation server 230 can attest the integrity of the virtual machine (VM) 212 supported by the hypervisor (HV) 214 running on the server 210. In one embodiment, the attestation server 230 comprises a processor 232 configured to encrypt a first nonce using a virtual endorsement key, vEK, and a transceiver 234. The transceiver 234 can be configured to send a VM attestation request to the VM 212 and a HV attestation request to the HV 214, wherein the VM attestation request comprises the encrypted first nonce, and to receive a VM attestation report from the VM 212, the VM attestation report being generated by the VM 212, and a HV attestation report from the HV 214, the HV attestation report being generated by the HV 214. Furthermore, the processor 232 can be configured to verify whether the VM attestation report is based on the first nonce, and to validate the integrity of the VM 212 on the basis of the verification of the VM attestation report and on the basis of the HV attestation report.

Although reference is made in the previous paragraph to a transceiver, it is clear that this is not the only possible implementation. The transmitting and receiving function in this and in the following embodiments can also be carried out by separate independent units, such as a transmitter (transmitting unit) and a receiver (receiving unit).

The server 210 can generate, by means of the VM and of the HV, attestation reports of the virtual machine VM 212 and of the hypervisor HV 214 running on the server 210. In one embodiment, the virtual machine VM 212 as well as the hypervisor HV 214 are configured to receive, from the attestation server 230, the VM attestation request and the HV attestation request, respectively.

The VM attestation request can comprise the encrypted first nonce encrypted using the virtual endorsement key, vEK. Moreover, the HV 214 can be configured to decrypt, by a virtual trusted platform module, vTPM, running on the HV 214, the encrypted first nonce on the basis of the vEK stored in the vTPM in response to a decryption request from the VM 212. The virtual machine VM 212 can furthermore be configured to receive a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, and to generate a VM attestation report about the VM, the VM attestation report comprising the first quote. The hypervisor HV 214 can furthermore be configured to generate the HV attestation report about the HV 214.

In embodiments of the invention, the attestation of the HV 214 is initiated after the VM attestation report or integrity report has been already received by the attestation server 230 or remote verifier. In embodiments of the invention, different channels are used for attesting the VM 212 and the HV 214, namely the attestation server 230 connects to both VM 212 and HV 214 independently, as schematically illustrated in figure 3. This embodiment of the invention allows a multiple channel independent deep attestation and has the advantage of performing a deep attestation of the VM 212 and of the HV 214 in a scalable manner.

Moreover, in embodiments of the invention, the server 210 can support a plurality of VMs running on the same HV 214, and the attesting server 230 can attest the plurality of VM at once. Once all integrity reports or attestation reports of the plurality VMs have been received by the remote verifier or attestation server 230, the attestation server 230 can initiate an attestation of the HV 214. Since the attestation of the HV 214 is performed after the attestation of all VMs, the solution scales. Embodiments of the invention allow also to implement a scalable layer binding into the aforementioned multiple channel independent deep attestation. To this aim, in

embodiments of the invention, the layer binding mechanism is tailored to the architecture of the multiple channel independent deep attestation and the scalability is advantageously maintained unchanged, as explained in the following steps.

Firstly, the encrypted nonce during VM attestation is used, which can only be decrypted by a vRoT (i.e., vTPM running on the HV 214) that holds the private parts of both the vRoT instance identification key and of the vRoT instance integrity report signing key. Secondly, during the decryption of the nonce by the vRoT instance (running on the HV 214), the public part of the identification key (the key which was used for decryption) and the decrypted nonce are added to a list maintained in the HV 214.

Thirdly, during the HV attestation, the list created by multiple executions of the previous step, is included in the HV integrity report or HV attestation report and later taken into consideration during the validation of the VM integrity report or VM attestation report in order to determine if the layer binding requirements are met. Therefore, embodiments of the invention provide the advantage of a solution which allows to implement both the deep attestation and layer binding requirements on a software level in an efficient scalable manner. Figure 4 shows a schematic diagram of an embodiment of the system 200 comprising the attestation server 230 according to an embodiment and the server 210 according to an embodiment, which comprises the hypervisor 214, the virtual machine 212 and the physical platform or compute node 216. In this embodiment of the invention, the attestation server 230 is configured to perform the VM attestation of the VM 212 and the HV attestation of HV 214 on the basis of the aforementioned multiple channels independent deep attestation method. Each of the VMs 212 and the HV 214 can be attested as an independent platform while, later on, the attestation server 230 can correlate the results of each VM attestation with the one of the HV 214 it is running on. This embodiment has the advantage that the deep attestation requirements are appropriately addressed and the VM integrity report or attestation report is built on top of a CoT rooted in the pRoT of the HV 214.

Since the VMs as well as the HV 214 can be treated as independent platforms, according to an embodiment of the invention, the keys used to sign integrity reports (AIKs - attestation identity keys) of each platform as well as their golden measurements are pre- registered in the attestation server 230, wherein the golden measurements define a set of measurements describing a state of the software of a platform that is considered to be not tampered. There are several established ways to collect and register the golden measurements in the attestation server 230, which are outside the scope of this disclosure, as are the methods for registering the AIKs.

Once the aforementioned pre-requisites are met, an attestation protocol, as defined by the TCG (see "TCG Attestation PTS Protocol: Binding to TNC IF-M":

http://www.trustedcomputinggroup.org/resources/tcg_attestation_pts_protocol_binding_to _tnc_ifm) can be executed in order to create an integrity report or attestation report for each platform and deliver it to the attestation server 230 for evaluation.

In embodiment of the invention, the main steps of such an attestation protocol can be summarized as follows: Firstly, the attestation server 230 establishes a network connection to an attestation agent running on the target platform (i.e., VM 212 or HV 214) via the communication channel 220. Secondly, the attestation server 230 generates a random nonce and it includes it in the attestation request sent to the attestation agent of the VM 212 or HV 214 (steps 1 .1 and 2.1 in Fig. 4).

Thirdly, the attestation agent collects integrity data and requests a signature or quote form the pTPM/vTPM (steps 1 .3 and 2.3 in Fig. 4). Then, it provides also the nonce received from attestation server 230 so that it is also included in the signed data. This ensures freshness of information (i.e., anti-replay protection). Finally, the integrity data together with the quote (which together form the integrity report) are sent back to the attestation server 230 for evaluation (steps 1 .4 and 2.4 in Fig. 4).

According to the deep attestation requirements, the HV attestation should be performed only after the integrity reports of all the targeted VMs running on top of it have successfully been received by the attestation server 230. The processor 232 of the attestation server 230 can be configured to execute this sequence, namely the HV attestation is initiated only after the VM attestations are completed. If the processor 232 cannot execute this sequence, the VM integrity reports or attestation reports may not be fully trusted, since a potential attacker can have a (arguably short) time window to compromise the vRoTs without being detected during the current attestation cycle. In embodiments of the invention, once the VMs integrity reports and the respective HV integrity reports are received by the attestation server 230, the attestation server 230 can validate the integrity state of both platforms types, namely VMs and HV 214. The integrity report of the HV is validated before starting the validation of any of the integrity reports of the VMs running on top of it. This ensures that the integrity reports of VMs are validated only in case it can be shown, by means of the HV integrity report validation, that their respective vRoTs are not tampered.

One example of procedure for performing the validation of a platforms integrity report is described in the above mentioned TCG specifications "TCG Attestation PTS Protocol: Binding to TNC IF-M", and the main steps of this procedure are given in the following. 1 ^st step: The signature of the quote is verified using the previously registered public part of the AIK for that specific platform. This effectively proves (or disproves) the integrity of the rest of the data in the integrity report. 2^nd step: The nonce, which is part of the signed data in the quote is checked against the value sent by the attestation server 230 at the beginning of the attestation procedure in the attestation request (step 3.2.1 and step 3.1 .1 in Fig. 4).

3^rd step: If the validation of the signed quote and the nonce is successful, then the attestation server 230 verifies the measurements in the integrity report against golden measurements registered for that platform or a profile that is applicable to that platform (it usually does not scale to register golden measures for each platform, as multiple platforms have the same software configuration). The attestation reports generated according to embodiments of the invention provide strong deep attestation and layer binding proofs.

Figure 5 shows a schematic diagram illustrating several steps of a method for attesting the integrity of the virtual machine VM 212 according to an embodiment.

In this embodiment, firstly, the attestation server 230 or attestation authority (AA) encrypts the nonce sent to the VM 212 with the public part of the virtual endorsement key (vEK). The vEK, similar to an EK for pTPMs, is generated at the creation of the vTPM instance (assigned to the VM 212) and cannot be removed. Its purpose is to serve as an identifier of the vTPM instance (see also step 1 .1 in Fig. 4). The encryption can be performed according to a privacy certificate authority (PCA) protocol defined by the TCG, which is supported both in TPM family 1 .2 (see TPM Main Part 3 Commands, clause 15.2, "TPM Activate Identify": http://trustedcomputinggroup.org/wp-content/uploads/TPM-main- 1 .2-Rev94-part-3.pdf) and TPM family 2.0 (Trusted Platform Module Library Part 3:

Commands, clause 12.5, "TPM2_ActivateCredential":

http://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-3- Commands-01 .16-code.pdf) specifications. The decryption can only be performed inside a vTPM that contains the private parts of both vEK and vAIK (which can later be used to sign the quote).

Secondly, the VM attestation agent of the VM 212 decrypts the nonce using the vTPM, which can contain the private part of vEK and vAIK. Only if the VM 212 has access to the specified vTPM instance, it can successfully perform this step (see also step 1 .2 in Fig. 4). Additionally, the vTPM can store (e.g., write to a file) in the HV file system the decrypted nonce and public part of vEK (vEKPUB) used for decrypting that nonce. Thirdly, the VM attestation agent of the VM 212 requests a quote from the vTPM signed with the vAIK (see also step 1 .3 in Fig. 4). Moreover, the VM attestation agent can provide the vTPM a hash of the previously decrypted nonce for inclusion in the quote. Hashing the nonce provides the advantage that the actual nonce value is known only by the attestation server 230 or AA and the VM 212 that has access to the correct vTPM instance, even when the protocol is executed over a non-secure connection (attacker cannot replay an attestation sequence).

Figure 6 shows a schematic diagram illustrating several steps of a method for attesting the integrity of the hypervisor 214 according to an embodiment.

In this embodiment, firstly, during the HV attestation process, the attestation agent running on the HV 214 can create a list with information regarding the public parts of vEKs of each active vTPM instance and the nonces which are used to decrypt (see also step 2.2 in Fig. 4). The list is created by the HV attestation agent based on the data exported by each vTPM instance to the HV file system (see also the description of step 1 .2 with reference to Fig. 5).

Secondly, the list of VEK_PUB and the associated decrypted nonces list can be hashed and this hash can be included in the pTPM signed quote that is part of the HV integrity report (see also step 2.3 in Fig. 4). The generated hash can be combined (a hash over both) with the nonce provided by the attestation server 230 or AA in the HV attestation request. This provides the advantage that, at the same time, an attacker cannot perform a replay attack and also that the quote signatures prove the integrity of the list. Thirdly, the integrity report sent back to the attestation server 230 or AA can also include the list of vEKs and nonces (see also step 2.4 in Fig. 4).

The HV attestation agent can ensure that the VEK_PUB and nonces exported by the vTPM instances which have been included in the list sent as part of the HV integrity report are removed from the file system. Since the nonces are relevant only for one (the current) attestation cycle, there is no advantage to accumulate this information over time. This can also reduce the data payload in the HV integrity report.

Moreover, during the HV 214 integrity report validation, a database can be updated with the contents of the list containing the public parts of vEKs and the nonces which they can decrypt on the HV 214. The database can record the links between a HV identity, a vEK and a nonce that was decrypted by the vEK, as part of a vTPM instance running on the identified HV (see also step 3.1 .3 of Fig. 4). Furthermore, during the VM integrity report validation, two additional checks can be performed. It can be checked whether the nonce in the quote is actually a hash of the nonce sent encrypted in the attestation request. A successful verification of the nonce implies that the VM 212 can have access to the appropriate vTPM instance containing the private parts of both vEK and vAIK (see also step 3.2.1 in Fig. 4). The nonce can further be checked against the database updated in step 3.1 .3 of Fig. 4, during HV integrity report validation (see also the aforementioned steps of the HV 214 validation method). If the nonce is found in the database as being processed with the expected vEK and on the expected HV 214, it can provide a sufficient evidence that the layer binding was properly addressed (see also step 3.2.3 in Fig. 4).

An advantage of the attestation method of the VM 212 and of HV 214 according to embodiments of the invention is that it provides a cryptographic proof that the vTPM used in VM attestation was running on the expected HV 214. This is due the fact that only a vTPM with the proper vEK and vAIK can decrypt the nonce sent encrypted by the attestation server 230 or AA. Moreover, the HV attestation protocol provides signed proof by means of the quote that the nonce decryption operation was performed on that specific HV 214.

Another advantage of embodiments of the attestation method of virtual machines and of the HV 214 is that it scales, supporting deployments with big numbers of VMs running on the same HV 214. This is facilitated by that fact that only one HV attestation is required following the attestation of multiple different VMs, without any impact on security.

Furthermore, the attestation method also helps in limiting the attack surface, as it does not require invasive introspection of vTPM sensitive internal data by other HV components. The VEKPUB and nonces that originate from the vTPM instances can be collected by the HV through a simple "push" mechanism: the vTPM instance can write these values to designated areas of the HV file system. This can effectively be a one-way, write-only communication channel that can be enforced and protected through existing confinement technologies (e.g., SELinux). Conversely, performing this through a request/response based data exchange interface between the vTPM instance and another HV component (possibly the HV attestation agent), can increase the attack surface on both VM 212 and HV 214. Any bugs in this interface might can led to either unauthorized introspection (HV to VM attack) or VM breakout (VM to HV attack). Figure 7 shows schematic diagram of a method 700 for attesting the integrity of the virtual machine VM 212 according to an embodiment.

The method 700 comprises the steps of encrypting 702 a first nonce using a virtual endorsement key, vEK, sending 704 a VM attestation request to the VM and a HV attestation request to the HV, wherein the VM attestation request comprises the encrypted first nonce, receiving 706 a VM attestation report from the VM, the VM attestation report being generated by the VM, and a HV attestation report from the HV, the HV attestation report being generated by the HV, verifying 708 whether the VM attestation report is based on the first nonce, and validating 710 the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation report.

The method 700 can be performed by the attestation server 230 described in the context of figure 2. Further features of the method 700 result directly from the functionality of the attestation server 230 and its different implementation forms.

Figure 8 shows a schematic diagram of a method 800 for generating attestation reports by the virtual machine VM 212 and by the hypervisor HV 214 running on the server 210 according to an embodiment. The method 800 comprises the steps of receiving 802, by the VM 212, a VM attestation request, and, by the HV 214, a HV attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK, decrypting 804, by a virtual trusted platform module, vTPM, running on the HV 214, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM 212, receiving 806, by the VM 212, a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, generating 808, by the VM 212, a VM attestation report about the VM 212, the VM attestation report comprising the first quote, and generating 810, by the HV 214, a HV attestation report about the HV 214. The method 800 can be performed by the server 210 described in the context of figure 2. Further features of the method 800 result directly from the functionality of the server 210 and its different implementation forms.

While a particular feature or aspect of the disclosure may have been disclosed with respect to only one of several implementations or embodiments, such feature or aspect may be combined with one or more other features or aspects of the other implementations or embodiments as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms "include", "have", "with", or other variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprise". Also, the terms "exemplary", "for example" and "e.g." are merely meant as an example, rather than the best or optimal. The terms "coupled" and "connected", along with derivatives may have been used. It should be understood that these terms may have been used to indicate that two elements cooperate or interact with each other regardless whether they are in direct physical or electrical contact, or they are not in direct contact with each other.

Although specific aspects have been illustrated and described herein, it will be

appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific aspects shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the specific aspects discussed herein.

Although the elements in the following claims are recited in a particular sequence with corresponding labeling, unless the claim recitations otherwise imply a particular sequence for implementing some or all of those elements, those elements are not necessarily intended to be limited to being implemented in that particular sequence.

Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Of course, those skilled in the art readily recognize that there are numerous applications of the invention beyond those described herein. While the present invention has been described with reference to one or more particular embodiments, those skilled in the art recognize that many changes may be made thereto without departing from the scope of the present invention. It is therefore to be understood that within the scope of the appended claims and their equivalents, the invention may be practiced otherwise than as specifically described herein.

Claims

1 . Method (700) for attesting, by an attestation server (230), an integrity of a virtual machine (VM, 212) supported by a hypervisor (HV, 214) running on a server (210), the method (700) comprising the steps of: encrypting (702) a first nonce using a virtual endorsement key, vEK; sending (704) a VM attestation request to the VM (212) and a HV attestation request to the HV (214), wherein the VM attestation request comprises the encrypted first nonce; receiving (706) a VM attestation report from the VM (212), the VM attestation report being generated by the VM (212), and a HV attestation report from the HV (214), the HV attestation report being generated by the HV (214); verifying (708) whether the VM attestation report is based on the first nonce; and validating (710) the integrity of the VM (212) on the basis of the verification of the VM attestation report and on the basis of the HV attestation report.

2. The method (700) of claim 1 , wherein the method (700) further comprises the steps of: verifying whether the HV attestation report includes the vEK and the first nonce; and validating the integrity of the VM (212) if the VM attestation report is based on the first nonce and if the HV attestation report includes the vEK and the first nonce.

3. The method (700) of claim 1 or 2, wherein the encrypting of the first nonce is performed according to a privacy certificate authority (PCA) protocol defined by the trusted computing group (TCG).

4. Method (800) for generating attestation reports, by a virtual machine (VM, 212) and by a hypervisor (HV, 214) running on a server (210), the method (800) comprising the steps of: receiving (802), by the VM (212), a VM attestation request, and, by the HV (214), a HV attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK; decrypting (804), by a virtual trusted platform module, vTPM, running on the HV (214), the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM (212); receiving (806), by the VM (212), a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce; generating (808), by the VM (212), a VM attestation report about the VM (212), the VM attestation report comprising the first quote; and generating (810), by the HV (214), a HV attestation report about the HV (214).

5. The method (800) of claim 4, wherein the method (800) further comprises the steps of: storing, by the vTPM, the first nonce and the vEK, the stored first nonce and the vEK being accessible by the HV (214); and reading, by the HV (214), the stored first nonce and the vEK, wherein the generated HV attestation report includes the stored first nonce and the vEK.

6. The method (800) of claim 4 or 5, wherein the method (800) further comprises the steps of: hashing, by the VM (212), the first nonce; generating, by the VM (212), the first quote on the basis of the hashed first nonce; hashing, by the HV (214), the first nonce and the vEK; receiving, by the HV (214), a second quote from a physical trusted platform module (pTPM) of the server (210), wherein the second quote is generated on the basis of the hashed first nonce and of the vEK and wherein the second quote is signed with a physical attestation identity key (pAIK); and including, by the HV (214), the second quote in the HV attestation report about the HV (214).

7. An attestation server (230) for attesting an integrity of a virtual machine (VM, 212) supported by a hypervisor (H V, 214) running on a server (210), wherein the attestation server (230) comprises: a processor (232) configured to encrypt a first nonce using a virtual endorsement key, vEK; a transmitting unit (234) configured to send a VM attestation request to the VM (212) and a HV attestation request to the HV (214), wherein the VM attestation request comprises the encrypted first nonce, and a receiving unit configured to receive a VM attestation report from the VM (212), the VM attestation report being generated by the VM (212), and a HV attestation report from the HV (214), the HV attestation report being generated by the HV (214); and wherein the processor (232) is further configured to verify whether the VM attestation report is based on the first nonce, and to validate the integrity of the VM (212) on the basis of the verification of the VM attestation report and on the basis of the HV attestation report.

8. The attestation server (230) of claim 7, wherein the attestation sever (230) comprises a public part of the vEK (VEK_PUB), a public part of a virtual attestation identity key vAIK (VAIK_PUB), a public part of a physical endorsement key pEK (pEK_PUB) and a public part of a physical attestation identity key pAIK (pAIK_PUB) , and wherein the processor (232) is further configured to validate the integrity of the VM (212) by means of the VM attestation report, of the VAI KPUB and of the VEK_PUB, and to validate the integrity of the HV (214) by means of the HV attestation report, of the pAIK_PUB and of the pEK_PUB.

9. A server (210) configured to run a virtual machine (VM, 212) and a hypervisor (HV, 214), wherein: the virtual machine VM (212) is configured to receive a VM attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key, vEK; wherein the hypervisor HV (214) is configured to receive a HV attestation request, to decrypt, by a virtual trusted platform module, vTPM, running on the HV, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM (212); wherein the virtual machine VM (212) is furthermore configured to receive a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, and to generate a VM attestation report about the VM (212), the VM attestation report comprising the first quote; and wherein the hypervisor HV (214) is furthermore configured to generate a HV attestation report about the HV (214).

10. A system (200) comprising an attestation server (230) and a server (210), wherein the attestation server (230) comprises a processor (232) configured to encrypt a first nonce using a virtual endorsement key, vEK; and a transmitting unit (234) configured to send a VM attestation request to the VM (212) and a HV attestation request to the HV (214), wherein the VM attestation request comprises the encrypted first nonce, and a receiving unit configured to receive a VM attestation report from the VM (212), the VM attestation report being generated by the VM (212), and a HV attestation report from the HV (214), the HV attestation report being generated by the HV (214), wherein the processor (232) is further configured to verify whether the VM attestation report is based on the first nonce, and to validate the integrity of the VM on the basis of the verification of the VM attestation report and on the basis of the HV attestation report, and wherein the server (210) comprises a virtual machine (VM, 212) and of a hypervisor (HV, 214) running on the server (210), wherein the virtual machine VM (212) is configured to receive a VM attestation request, wherein the VM attestation request comprises an encrypted first nonce encrypted using a virtual endorsement key vEK, wherein the hypervisor HV (214) is configured to receive a HV attestation request, to decrypt, by a virtual trusted platform module, vTPM, running on the HV, the encrypted first nonce on the basis of a vEK stored in the vTPM in response to a decryption request from the VM (212), wherein the virtual machine VM (212) is furthermore configured to receive a first quote from the vTPM, wherein the first quote is signed with a virtual attestation identity key, vAIK, stored in the vTPM and comprises the first nonce, and to generate a VM attestation report about the VM (212), the VM attestation report comprising the first quote, and wherein the hypervisor HV (214) is furthermore configured to generate a HV attestation report about the HV (214).

1 1 . A computer program comprising a program code for performing the methods (700, 800) of claims 1 to 6 when executed on a computer.