The present disclosure relates to a method, performed by a virtualization platform of a node having a virtual trusted platform module, vTPM, for booting a virtual machine, VM in a trusted state. The disclosure also relates to a method performed by a virtual trusted platform module in a node and to such node.

BACKGROUND

The Trusted Computing Group (TCG) has developed a series of specifications that enable to build infrastructures of servers where users and servers can assess if a service/server is trustworthy or not. An important component in the TCG approach is the so-called Trusted Platform Module (TPM), a physical security chip designed to securely store keys and host protective processing capabilities to implement the basic security controls in the server systems. Specifically, the TCG defines servers having so called "Roots of Trust (RoT)" which can be viewed as engines designed for a specific task that, possibly in cooperation with each other, provide immutable security control/functions. The TCG has defined three Roots of Trust, namely the "Root of Trust of Measurement (RTM)", the "Root of Trust of Storage (RTS)", and the "Root of Trust of Reporting (RTR)". In this view, a TPM is a component that implements a RTS and a RTR while the RTM is typically realized in the host system (the server) where the TPM resides. Services or applications either on the server or connected to the TPM via a communication channel can utilize the TPM for several purposes. Like already mentioned the TPM can be used in solutions where a system or user wants to assess if another server/service is trustworthy. Towards this end, the TCG has specified a procedure by which a remote entity (user or server) can send an attestation request to a target system that, when equipped with a TPM and properly configured, can send securely attestation data to the remote entity. Furthermore, services can utilize the secure storage functions of the TPM to protect sensitive data such as keys for secured communication. Another important use of the TPM is to assist in

implementing secure boot procedures. One such procedure is often referred to as "measured boot" in which the initial (boot) software is verified (measured) and where the measurements are stored securely in the TPM. These measurements can later be used in attestation procedures using the interplay of RTS and RTR of the TPM.

In recent years and in connection with the development of cloud technologies many servers and services run on virtualized processing systems such as, for example, offered by Xen™, KVM™, or VMware™. Consequently, there is also some demand for providing either TPM functionality or special trusted platform modules in such virtual environments, such that user working on a VM can utilize TPM functionality as if he would work directly on a hardware platform.

SUMMARY The present disclosure addresses these and other aspects related to trusted computing in cloud environments.

In accordance with the present disclosure a method is performed by a virtualization platform of a node having a virtual trusted platform module, vTPM, for booting a virtual machine, VM in a trusted state and comprises measuring by the vTPM or a dedicated component of the virtualization platform an initial executable code prior to a boot sequence of the VM and processing the initial measurement. A second executable code is measured by the initial executable code during the boot sequence of the VM to provide a second measurement associated with the second executable code of the VM to the vTPM. The processed initial measurement is extended by the vTPM with the second measurement to obtain a first extended measurement.

Such approach enables an isolation of the measurement and extension of the PCR of a virtual TPM from the VM's emulation and the VM's image. The level of trust to the measurements of the virtual trusted computing boot vTCB becomes nearly the same as if it would be a physical machine. In a further aspect, a previously measured executable code provides during the boot sequence of the VM at least one third measurement of at least a third executable code or subsequently code to be executed during the boot sequence of the VM to the vTPM. The vTPM performs extensions of previously extended measurements associated with the previously measured executable code with at least a third measurement. The steps are repeated, until a predefined event during the boot sequence of the VM occurs.

In other words, the initial measurement is conducted by the vTPM prior to the boot sequence and subsequent measurements are conducted by executable code of the VM during the boot sequence and provided to the vTPM, which in returns extends the previous measurement with the subsequent. The initial executable code acts as a root of trust, the initial measurement is first element of the chain of trusts and subsequent measurements conducted by the executable code form a chain of extensions.

Measurements can be provided to the vTPM by communicating via a dedicated interface provided by the virtualization platform with the executable code of the VM. This allows using existing secure interfaces, for instance TIS interface.

In another aspect, extending the initial measurement can comprise hashing the processed initial measurement with the second measurement. Likewise extending a previously extended measurement can comprise hashing previously extended measurements with the at least one third measurement. Extending can further comprise storing or writing the hashed result back in a virtual Platform Configuration Register, vPCR, from which the processed initial measurement and/or the previously extended measurements were read.

The use of vPCRs enables to use the vTPM for cloud solution in the same way as it would be a physical TPM with physical PCRs. Each set of vPCRs can be associated in an aspect with the execution of a specific VM. Hence, a single vTPM with a plurality of vPCRs can serve several VMs in a cloud environment.

In another aspect, the vTPM extends one or more virtual Platform Configuration Register(s), vPCR with a secret value obtained from a trusted platform module, pTPM of the network node and with the initial measurement. Alternatively the vTPM extends in a virtual Platform Configuration Register, vPCR, a secret value obtained from a trusted platform module, pTPM of the network node with the initial measurement. In this regard, the vTPM may also extend at least one of the initial, second and at least the third measurement; and the extended initial, second and previously stored measurements with a secret value provided by a trusted platform module, pTPM of the network node.

Measuring or conducting a measurement can comprise hashing the initial executable code prior to the boot sequence of the VM or a portion of the executable code during the boot sequence. Hashing can be performed using a pre-specified hash function, which basically maps data, sometimes of arbitrary length to data of a fixed size. The hash-function can for example be a secure hash function defined by NIST or any other respective organisation. Examples of such hash functions include, but are not limited to MD5, SHA1, SHA2-224/256/384/512, SHA3- 224/256/384/512, SHAKE128 and SHAKE256.

Another aspect of the present disclosure deals with the virtual trusted platform module being arranged or executed in a node. A method comprises measuring an initial executable code prior to a boot sequence of a virtual machine, VM to obtain an initial measurement; extending at least one virtual platform configuration register, vPCR associated with the VM with the initial measurement to provide a processed initial measurement; receiving by the initial executable code of the virtual machine, a second measurement associated with a measurement by the initial executable code of a second executable code; and extending the processed initial measurement with the second measurement.

Extending the at least one vPCR may comprise in this regard to provide at least one vPCR associated with the VM and extend the at least one vPCR with a secret that is bound or sealed to a physical trusted platform module, pTPM on the node or extend the at least one vPCR with a secret that is associated with the VM.

In this regard the expression extending the at least one vPCR can comprise to hash the at least one vPCR with the initial measurement; and store the result of the hashing in the at least one vPCR to obtain the processed initial measurement.

The above-proposed method performs the initial steps and builds the root of trust. In a further aspect, the method comprises receiving by an executable code during the boot sequence of the VM, for which a measurement has been previously received, at least one third measurement associated with measuring least one third executable code; extending a previously stored measurement with the at least one third measurement; and repeating the steps of receiving by an executable code and extending the previously stored measurement until a predefined event during the boot sequence.

In other words, the initial measurement is conducted by the vTPM prior to the boot sequence and subsequent measurements are conducted by executable code of the VM during the boot sequence and provided to the vTPM, which in returns extends the previous measurement with the subsequent. Hence, the initial measurement acts as a root of trust and subsequent measurements conducted by the executable code form a chain of extensions.

In a node having one or more processors and a trusted platform module, pTPM, the one or more processors are configured to execute a virtualization platform configured to execute at least one virtual machine, VM and a virtual trusted platform, vTPM, configured to communicate with the pTPM of the node and to provide trusted platform functionality, TPM functionality to the VM via a dedicated interface provided by the virtualization platform. The vTPM is configured to obtain an initial measurement of an initial executable code prior to a boot sequence of the VM. The vTPM is configured to extend at least one virtual platform configuration register, vPCR associated with the execution of the VM with the initial measurement to obtain a processed initial measurement and to receive a second measurement provided by the initial executable code in response to measuring a second executable code by the initial executable code during the boot sequence of the VM. Further the vTPM is configured to extend the processed initial measurement with the second measurement.

In an aspect the vTPM comprises a plurality of virtual Platform Configuration Register, vPCR configured to store the processed initial and/or second measurement and/or an extension thereof. The plurality of virtual configuration registers can be associated with different VM to be executed when necessary. As a result, the VM can in operation use the vTPM and the associated vPCR as if those would correspond to a physical PCR.

It may be suitable to initialize the vPCR with a predefined value prior to extending the vPCR with the initial measurement. Consequently, the vTPM may be in an aspect configured to obtain a secret value securely bound or sealed to the pTPM and to extend the at least one vPCR with the secret value. Another aspect is related to the handling of chains of measurements. The vTPM may further be configured to receive by a previously measured executable code during the boot sequence of the VM, at least one third measurement associated with a third executable code during the boot sequence of the VM and extend a previously stored measurement associated with the previously measured executable code with the at least one third measurement. The previous steps may be repeated until a predefined event during the boot sequence of the VM.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, the present disclosure will be described in detail in connection with several embodiments and with reference to the drawings, in which: Figure 1 illustrates a state machine for a virtual machine, VM

Figure 2 shows an embodiment of a trusted computing based configured to execute several virtual machines,

Figure 3 shows an embodiment of a method for booting a virtual machine in a trusted state,

Figure 4 shows another embodiment of the method for booting a virtual machine in a trusted state,

Figure 5 illustrates different aspects of the methods for booting a virtual machine in a trusted state,

Figure 6 illustrates different aspects of the methods for booting a virtual machine in a trusted state, Figure 7 shows an embodiment of a method performed by a virtual trusted platform module,

Figure 8 illustrates different aspects of the methods performed by a virtual trusted platform module,

Figure 9 shows a node having one or more processors and a trusted platform module,

Figure 10 illustrates a functional embodiment of a node configured to execute virtual machines in a trusted state.

DETAILED DESCRIPTION For the purpose of the present disclosure, a virtual machine (VM) is an emulation of a given computer system. Virtual machines operate based on the computer architecture and functions of a real or hypothetical computer, and their implementations may involve specialized hardware, software, or a combination thereof. There are different kinds of virtual machines, each with different functions. System virtual machines (also termed full virtualization VMs) provide a complete substitute for the targeted real machine and a level of function needed to execute a full operating system.

The VM itself is executed by a virtualization platform on a so called host system. Said host system is a real computer platform comprising one or more processors, memory, storage, input/output devices and other hardware elements. Various computer capable of executing one or more VM exist and are readily available. The computer platform can be connected to a network enabling a user to access the platform itself and the virtual machine executed thereon via the virtualization platform. In such case the computer platform is called node.

A virtualization platform may be a hypervisor that uses native execution to share and manage hardware, allowing multiple different environments, isolated from each other, to be executed on the same physical machine. Modern hypervisors use hardware-assisted virtualization, which provides efficient and full virtualization by using virtualization-specific hardware capabilities, primarily from the host processors.

Some virtualization platforms, such as Q.EMU, are designed to also emulate different architectures and allow execution of software applications and operating systems written for another CPU or architecture. Operating-system-level virtualization allows the resources of a computer to be partitioned via the kernel's support for multiple isolated user space instances, which are usually called containers and may look and feel like real machines to the end users.

The life cycle of a virtual machine, VM can be visualized by its state machines, illustrating the different operating states and the transition between those operating states. Figure 1 shows such a state machine for a VM.

A VM is usually created from a template, i.e. using a copy of a previously saved VM where an operating system, OS has been installed with a setup that may be generic or been configured for a specific purpose. A VM may also be created from scratch, e.g. attach an ISO file and install the OS from the virtualized CD/DVD-ROM.

Once running, the state of the VM may come into one of the following states:

Saved; a gracefully shutdown of the operating system, where all running applications has been terminated.

Suspended; the VM is stopped and then the entire current state of the VM is saved, which later can be resumed in the exact same state when it was stopped.

Down; a running VM may have failed due to e.g. a HW issue or it has been ungracefully shutdown. When the VM is shutdown, a new image of the VM is saved to be launched at a later stage. This cycle we call for shutdown/launch. The image of the VM itself may be a simple file containing all information. After a normal shutdown or even suspension the saved image can be moved or copied. For instance an image of a shutdown VM can be copied and then relaunched on a plurality of different virtualization platform or on the same virtualization platform a couple of times. Such procedures may be allowed or prohibited depending on security policies and enforcement mechanisms implemented.

When a VM is migrated or the operator takes a snapshot then the VM is suspended at the source location, and then resumed at the destination location. This cycle is called for suspend/resume procedures. Of course the suspend/resume cycle may also occur on the same machine. Through the above definition of suspend/resume, this part of the lifetime cycle includes migration of the VM as well.

If a VM stems from systems that originally used trusted platform module, TPM functions one has to the option to introduce a virtual TPM (vTPM) that is associated with its VM. This option becomes increasingly important as users expect to work under a VM as if they would work with real existing hardware. Hence, there is a growing need to have efficient vTPM solutions that fulfil the functional needs and security demands of VMs and the applications/services implemented therein. The technical and security challenges of realizing vTPM solutions have been the subject of various research work, see for instance in S. Berger et al., "vTPM: Virtualizing the trusted platform module," in In USENIX Security, pp. 305-320, 2006, which is incorporated herein by reference in its entirety addressing some, but not all of potential issues involved. One aspect involved is the related to the virtualization of a trusted computing base vTCB, as users may require a system and an operation that can be trusted. As VM is by nature a virtual environment, one needs to establish a respective vTCB, thus preventing a third party from tampering the environment by, for instance, executing a VM on a non-trusted platform.

Likewise, there is a need to confirm that a VM has booted in a trusted state so it can be considered as trusted base.

The term "Trusted Computing Base" corresponds to a computing system as a set of all hardware, firmware and software that are critical for the security of the computing system and should always behave in a trusted way. If the firmware/software parts of the TCB booted and launched in a trusted way, then the security and external user secrets and other vital functionality on top of the TCB may be bound to the trusted state of the TCB. This way, the trusted state of the TCB is directly depending on the existence of a Trusted Boot (TB), which itself is a part of the TCB as well.

In a physical machine a Trusted Boot (TB) can be one of or both: verified boot, and measured boot. A TB usually starts with a microcode, an initially executable code, IEC, which is usually hard to tamper as it resides in read-only memory, ROM close to the main processor, CPU or integrated in the CPU. The IEC serves as the root of trust for a trusted boot. Then, the IEC checks the signature of the next code in a verifiable boot, and/or measures the code in a measured boot. This process is repeated until the booting procedure is finished.

Measured boot makes it possible later to attest the system remotely and also to bind and/or seal secrets to the trusted state of the machine. Typically, a measured boot requires a root of trust for measurements, and for this purpose many solutions use a physical TPM, or pTPM. For example, Intel TXT uses TPM for a trusted measured boot, as well as the corresponding boot loader called tboot. Measurements on each step of the trust chain are used to extend certain platform configuration registers, PCRs in the physical TPM. The sequence of such measurements ends up in a certain value of one or several PCRs in the TPM. When PCRs have the values that match to the sequence of loadings and measures of trusted components, then the system is then said to be in a trusted state.

In this regard, the term "measure" generally refers to perform a specific function on a piece of data. In this regard, the specific function is often a hash function like SHA-1 or SHA-2 or any of the one mentioned previously, but not limited hereto. For the purpose of illustration, only an exemplary hash function is used in the following. Applying a hash function onto some data is referred to as hashing the data. The respective result of measuring data is a value, called measurement. For example, measuring the piece of data called 'data' results in the measurement: = SHA-l(data). Measurements can be of code, data structures, configuration, information, or anything that can be loaded into memory. To further protect the integrity of the measurements, the measurements are not written directly into PCRs, but rather a PCR is "extended" with a measurement. This means that the TPM takes the current value of the PCR, extends the PCR with the measurement by hashing them together, and replaces the content of the PCR with that hash result. PCR : = SHA-1(PCR | | SHA-l(data)). The effect of such extension is that the only way to arrive at a particular measurement in a PCR is to extend exactly the same measurements in exactly the same order. Therefore, if any module being measured has been modified, the resulting PCR value will be different and thus it is easy to detect if any code, configuration, data, etc. that has been measured had been altered or corrupted. Virtualization platforms and other applications can now be executed by the OS. For instance, the OS may execute a virtualization platform used for executing VM's at a later stage and other applications. The various applications, hardware and OS combined form the TCB of the execution platform.

The present disclosure proposes aspects concerning virtualization of a TCB and particular how to bring a virtual TCB into a trusted state.

Virtualization of a system with TCB requires a solution to support a virtual TPM associated to the VM. Provided that the virtualization platform, including the boot and the VM emulation software is measured, a TCB of the execution platform can be assumed Figure 2 shows an embodiment of such a TCB of an execution platform configured to execute one or more VM. The TCB of the execution platform comprises the platform specific component, like Hardware, BIOS, OS and has performed a trusted boot itself. The Operating systems has executed the virtualization platform, which comprises one or more virtual BIOS images, vBIOS that represent the virtual hardware base of the virtualization platform. The Execution platform also comprises a virtual TPM Device, vTPM Device interacting with the virtualization platform and providing access to TPM functionality. In some embodiments the vTPM Device can be part of the virtualization platform, like in hypervisor solution, in which it is part of the solution. In case of KVM/OEMU platforms it may be a separate vTPM Device. The vTPM Device is the execution engine that supports the TPM functionality for the VM (not illustrated in Figure 2). The vTPM Device may integrate a TPM emulator and pass TPM commands from the VM to the emulator. The vTPM Device may use any type of channel to communicate with a TPM emulator or even a physical TPM of the execution platform, and by this way vTPM Device supports the TPM functionality for the VM. In some operation and/or instances the vTPM Device may act as a proxy providing functionality by passing the respective requests and commands to the underlying pTPM.

The vTPM may include specific information that is associated with a dedicated VM. For this purpose, the vTPM may include a plurality of virtual platform configuration registers, vPCR, which can be initialized and bound to the pTPM. They can be associated with individual VM. As such it is possible to use the vTPM with its TPM functionality for several VMs. The VM may communicate with the vTPM Device via an interface according to TPM Interface Specification, via a low level FIFO hardware interface specified by TCG for communication with a TPM or the newer Command Response Buffer (CRB) interface, or any other appropriate interface. The simulation of the TIS interface may be done by the virtualization platform, such as KVM/OEMU. However, there could be other means and channels how the VM and the vTPM Device establish a communication channel. The overall vTPM therefore comprises the vTPM Device, the TPM functionality, vPCRs, , the Secret Seeds (in TPM specification 2.0)/Endorsement Key (in TPM specification 1.2), eventually further parts of the context and all necessary communication channels and interfaces. In a trusted measured boot of a physical system, as explained earlier, the root of trust is the initial executable code, IEC, which starts measuring the next block of software that is to be loaded and executed. In virtual machines, the initial executable code IEC is often a part of the VM image and/or the BIOS image itself. In some implementations, e.g. in KVM/Q.EMU, the BIOS image may be separate from the VM image. Hence, those images can be modified at any stage and particularly in the initial stage. When booting the tampered initial executable boot is executed and measures the next block of code. As a result, the whole chain of booting of the VM may extend the vPCRs of the vTPM with the right values and in the right order, but at the end of booting VM cannot be trusted. In some circumstances it may not even possible to detect that it can't be trusted.

The present disclosure proposes that during the VM's launch procedure, the vTPM, parts thereof or another component of the virtualization platform measures the IEC of the VM and extends a relevant vPCR of the vTPM. This is done prior to the boot sequence of the VM. By this way, the root of trust, (that is the IEC in the physical world) is moved from the VM down to the vTPM, parts thereof and/or a specific component of the virtualization platform.

The link between the physical TCB to the virtual TCB can, for example, be established by also extending to the vPCR of the vTPM a secret value sealed to the PCRs of the physical TPM that are the measurements of the TCB of the execution platform. In general a combination secret and public value can be used to extend the vPCR before the VM boot. In case when vTPM and/or the vTPM Device is a pass-through to the physical TPM, then the vTPM and/or the vTPM Device can perform a dynamic measurement to the physical TPM, i.e., those PCRs that can be cleared by a special secure code - the part of the TCB of the execution platform.

Figure 3 shows an embodiment of a method, performed by a virtualization platform of a node having a virtual trusted platform module, vTPM, for booting a virtual machine, VM in a trusted state. The method comprises in a first step measuring (Sll) an initial executable code, IEC prior to a boot sequence of the VM and processing (S12) the initial measurement. This step is performed by the vTPM or a dedicated component of the virtualization platform. In an subsequentstep, the VM may be launched by the virtualization platform (S131), which in turn executes the IEC (S132). In a next step, the initial executable code executed by the VM measures (S13) a second executable code during the boot sequence of the VM to provide (S14) a second measurement associated with the second executable code of the VM to the vTPM. The virtualization platform by use of the vTPM extends (S15) the processed initial measurement with the second measurement to obtain a first extended measurement. These first steps ensure a proper generation of the root of trust. Further executable code can rely on the root of trust and build a trust chain until the boot sequence is completed. For this purpose, the method may optionally repeatedly (S19) comprise providing in step S16 at least a third measurement by a previously measured executable code to the vTPM and extending (S18) the previously extended measurement with the at least a third measurement. These additionally measurement are performed by the executable code during the boot sequence within the launched VM.

The previously mentioned step of measuring the IEC of VM by the vTPM or a component of the virtualization platform prior to boot sequence can comprise hashing the IEC. In this regard, each measurement of executable code, that is the initial, second and at least a third measurement can comprise hashing such code.

Providing the second and at least one third measurement can optionally include that the respective executable code which performed the measurement of the subsequent block pushes the measurement into the vTPM using the dedicated interface (e.g., TIS), which brings the TPM command (Extend the vPCR) to the vTPM via the emulator of the VE or vTPM Device. The vTPM in turn may extend the respective vPCR value with said measurement. In this regard, the vTPM may also extend not only one PCR, but can extend the same measurement to a set of selected PCRs and/or extend different measurements to different sets of PCRs.

Figure 4 illustrates another aspect of the present disclosure. A method performed by a virtualization platform of a node having a virtual trusted platform module, vTPM, for booting a virtual machine, VM in a trusted state comprises in a first step to measure by the vTPM or another dedicated component of the virtualization platform the IEC or a portion thereof prior to launch of the VM itself. For instance, the virtualization platform can start a VM emulator, VME, which in turn measures the IEC of VM image prior to initiating the boot sequence of the VM images itself. For example, the VME can in an aspect hash the IEC to obtain the initial measurement. In a subsequent step S12, the initial measurement is further processed. For instance, optionally the virtualization platform or the vTPM can provide in step S121 at least one vPCR, which is associated with the VM to be executed. The vPCR is also initialized with a pre-defined value. In step S122, the at least one vPCR is then extended the initial measurement, for example the initial measurement is hashed with the value of the vPCR and the results stored back in the at least one vPCR.

In addition to an initialization, which can be performed by the vTPM, the VME or the vTPM can optionally further obtain a secret as illustrated in steps S1211 or S1212. In Step S1211, the vTPM extends the initialized vPCR with a secret that is bound to the pTPM of the host system. In this step the vTPM retrieves a secret that is sealed or bound to the physical TPM of the hardware, e.g. the result of the trusted boot of the hardware and extends its own vPCR with said secret. Such approach would practically bind the trusted state of the VM after execution to the trusted boot of the host system. In an alternative, the initialized vPCR is extended with a secret that is associated to the respective VM or a part thereof, for instance the IEC. In another alternative, the vTPM or the VME uses the secret as obtained above to first measure a combination of the secret and the initial measurement and then extends its vPCR with the result of the combined measurement.

After steps S12, the VME may start emulating the VM. At that stage, the VME may not measure any more executable codes, but act as some kind of proxy between the VM and the corresponding vTPM. In accordance with this approach, the second executable code in step S13 is measured by the IEC within the VM. Subsequently it is provided in step S14 to the vTPM. Such provision requires communication using a dedicated interface, which is established between the VM and the vTPM. The IEC pushes the second measurement using said interface to the vTPM. In particular, the IEC sends a TPM command, e.g. "Extend the vPCR" via the dedicated interface the VME or the vTPM Device. The command causes the vTPM to extend the vPCR associated with the VM with the second measurement in step S15.

Step S15 concerning extension of the processed initial measurement is illustrated in Figure 5 including further optional aspect already partly addressed above. The processed initial measurement can be hashed with the second measurement. In this regard, the expression hashing means that the vPCR comprising the processed initial measurement is hashed together with the second measurement. The following formula for such extension may apply for example vPCR:=SHA-l(vPCR | | second measurement), wherein SHA-1 is a hash function whose parameters are the second measurement and the content on the vPCR, that is the processed initial measurement. The result is stored or written back to the respective vPCR. In a similar manner, all subsequent measurement can be extended. Figure 6 illustrates some aspects of step S18, in which previously extended measurement are extended with the at least a third measurement provided by executable code during the boot sequence of the VM. In optional step S181 a previously extended measurement stored in a vPCR and corresponding to the end link of the measurement chain is further extended with the at least a third measurement. The result is then stored in the respective vPCR.

Another aspect of the present disclosure is illustrated in Figure 7. It shows an embodiment of a method performed by a vTPM. The method is used to support the trusted measured boot procedure of a VM such that a trusted boot can be assumed even when booting a VM. In a first step, the vTPM measures an IEC of the VM prior to the boot sequence of the VM itself. The measurement will obtain an initial result, also referred to as initial measurement. In this embodiment, the measurement is performed by the vTPM or a part thereof. Such measurement may include for example hashing, S611 the IEC using a specific function. For instance, the initial measurement can be defined as X:=SHA2-512(IEC), wherein X is the initial measurement result and SHA-512 is an exemplary hash function having IEC as parameter. The vTPM may contain one or more vPCRs associated with the VM. In step S62 the vPCR, which may be initialized with a pre-defined value is extended with the initial measurement to obtain the processed initial measurement. For this purpose, the vTPM may for example hash the respective vPCR together with the initial measurement as stated in S621 and store the result back in the vPCR, see step S622. The stored result is referred to as the processed initial measurement.

The VM emulator may then launch the VM, which in turn executes the IEC initiating the boot sequence. The IEC measures the next portion of the executable of code and pushes the result to the vTPM. Consequently, the vTPM receives in step S63 a second measurement by the IEC associated with the measurement of the second executable code by the IEC. The processed initial measurement is in Step S64 extended with the second measurement in a similar way as described above. The extension is the initial step after which executed code during the boot sequence can measure and further extend the extended second measurement. Optionally, the method comprises steps S65, in which the vTPM receives at least a third measurement from an executed code during the boot sequence. The executed code can have been previously measured. In step S66, the vTPM extends the previously extended measurement associated with the executed code with the at least third measurement. These two steps of measuring by the executable code in the VM during the boot sequence and the subsequent extension can be repeated until a pre-defined triggering point.

Figure 7 shows some further optional aspects of the process steps S62, in which the vPCR in the vTPM is extended with the initial measurement to provide the processed initial measurement. The vPCR is a virtual configuration register, which is provided by the vTPM on request and initialized with a predetermined value. The vPCR is associated with the respective VM to be executed. As a result, the vTPM can comprise a plurality of such vPCRs, wherein each one or a sub-plurality of the plurality of vPCRs is associated with a VM to be executed. The vTPM is therefore not restricted to a single VM, but can serve more than one VM. In step S623, a vPCR is associated by the vTPM with the VM to be executed and provided for further usage. In one option, the initialized vPCR can be directly extended with the initial measurement. Like in pTPM, the vPCR can normally not be directly written into by users or from userspace, but rather the content of the vPCR is hashed together with some other data and the result saved or stored back in the vPCR. The extension of the initialized vPCR with the initial measurement is illustrated by the arrow from step S623 directly to step S621. After hashing the content of the PCR with the initial measurement, the results are stored back in the vPCR.

In an alternative solution, the vTPM retrieves a secret bound or sealed to the pTPM of the host platform. Communication between the vTPM and the pTPM is done via the TIS or another suitable interface. The vTPM requests a secret from the pTPM and then extends its vPCRs with said secret. This binds the vTPM and later also the VM to the host platform. In an alternative embodiment, the vTPM can request such secret from another authorized host via a secured network connection. Such authorized host could for example perform a separate attestation with the pTPM of the platform host and other functionality. After extending the vPCR with the retrieved secret, the method continues with steps S621 and S623. Another approach is illustrated by step S625. In such case, the vTPM requests a secret associated with the VM and extends the vPCR with said secret. Then, the method continues with step S621 as previously explained.

In the present embodiment, extension of the vPCR occurs sequentially, that is first the vPCR is extended with the secret and then with the initial measurement. The order of such extension can vary. For instance it is possible first to extend the initiated vPCR with the initial measurement and then with the retrieved secret. Alternatively, any logical operation may be performed between the initial measurement and the secret.

The approach proposed in the present disclosure has the advantage that any secret associated with the VM and/or bound to the pTPM is only visible to the vTPM, or parts thereof on the trusted execution platform. The the secret can be decrypted conditioned on the physical TCB, but it is not revealed to the VM. Instead the VM is just the results of the extension in S621, for instance a value of the vPCR, that is the result of a hash operation, for example = hash("init value" 1 1 secret). Figure 9 illustrates an embodiment of a node enabled to perform a trusted virtual boot as disclose above. The node 100 can be part of a network (not shown in here). It comprises one or more processors 101, which are connected to a memory 105. The memory can for example be a RAM, SRAM and the like. The processors are via a physical interface TIS also coupled to a physical trusted platform module 102. The memory comprises a virtualization platform 103 configured to execute at least one virtual machine 108, one of which is shown herein. Memory 105 is also connected via the interface TIS to the trusted platform module 102.

Node 100 further comprises a virtual trusted platform module vTPM, 106, which in this exemplary embodiment is part of the virtualization platform. The vTPM is configured to communicate with the pTPM of the node and to provide trusted platform functionality to the VM 108 when applicable via a dedicated interface provided by the virtualization platform. For example, the dedicated interface can include a virtual TIS interface vTIS. The interface vTIS may follow the specification set by the trusted computing group, but also any other secure communication interface. The vTPM is further configured to obtain an initial measurement of an IEC prior to a boot sequence of VM 108. The initial measurement may be obtained prior to initialization of the VM. The vTPM is also configured to extend at least one virtual platform configuration register, vPCR 107 associated with the execution of the VM with the initial measurement to obtain a processed initial measurement. The vTPM 106 may include the vPCR 107. vTPM 106 can also be configured to initialize vPCR 107 before extension. vTPM 106 is configured to receive a second measurement provided by the initial executable code in response to measuring a second executable code by the initial executable code during the boot sequence of the VM. Finally, the vTPM is configured to extend the processed initial measurement with the second measurement. From the perspective of VM 108, the vTPM 106 therefore offers the same functionality and acts in the same way as if it is a physical TPM.

The connection between the vTPM and the pTPM via the interface TIS enables the vTPM to bind or seal its vPCRs with a secret provided by the pTPM. Extension of a vPCR in this regard can include obtaining a secret bound to or sealed to the pTPM and extending the vPCR with the secret, e.g. hashing the vPCR and the secret to obtain a hash result, which is saved back into the vPCR. The secret can be obtained from the pTPM 102. It is however also possible to obtain the secret from another network node, e.g. from an authorization server, which may have performed attestation with the pTPM of the host platform.

In an aspect, the vTPM comprises a plurality of vPCRs, three of which are illustrated in Figure 9. One or more of the plurality of vPCR 107 can be associated to a single VM 108 and configured to store the processed initial and/or second measurement and/or an extension thereof. This gives a high flexibility depending on the needs and requirements. In another aspect, the virtualization platform, a dedicated portion thereof or the vTPM is configured to hash the initial executable code during the boot sequence of the VM or a portion of the initial executable code of the boot sequence to provide the initial measurement. The extension of the vPCR with the initial measurement prior to the launch sequence and performed by the vTPM or dedicated portions of the virtualization platform form the root of trust for VM 108.

To further support launch and initialization of the VM that is during the boot of the VM, the vTPM is configured to receive by a previously measured executable code during the boot sequence of the VM at least a third measurement associated with a third executable code during the boot sequence of the VM. The vTPM is further configured to extend a previously stored measurement associated with the previously measured executable code with the at least a third measurement. These steps may be repeated until a predefined event during the boot sequence of the VM, for example until the boot sequence of the kernel in the VM is completed. The vTPM may comprise functionality to perform extension of the processed initial and the previously stored measurement. In this regard the vTPM may use own function, so for instance an implementation of hash function. Alternatively, the vTPM may utilize the functions available at the pTPM of the host platform via the dedicated interface between the vTPM and the pTPM. In such case, the vTPM acts more like a proxy passing TPM requests and commands from the VM to the pTPM. Nevertheless, from the perspective of the VM, the vTPM provides the TPM functionality. A combination of providing own functionality and acting as a proxy is also possible.

In an exemplary operation of the node, a user pushes a button or issues a command to start or launch a respective VM. Such command can be issues locally, but also over a network. This enables a user over a network to launch a VM on a host platform in a trusted state. In a first step, the virtualization platform 103 in memory 105 starts executing a VM emulator or a respective hypervisor with some parameters. One of those parameters is the file of the VM image itself. The VM emulator loads the VM image into memory but does not start the emulation yet. Hence, no boot sequence is initiated. The virtualization platform then calls for the vTPM 106 and informs the vTPM about the expected launch of the VM. It may also provide vTPM Context, which includes VM specific information of the vTPM. Such vTPM context can include endorsements, internal secret and other data associated with the VM. The vTPM sets one or more vPCR to a predefined init state and associates those vPCRs with the VM. The initialization can be facilitated by the vTPM Context, which may include the pre-defined values. The vTPM may also initialize a secure interface vTIS for communication between the VM and the vTPM, if such has not yet be done. The interface vTIS may be a virtual interface following the specification set by the trusted computing group, but also any other secure communication interface.

Parallel or as a subsequent step, the VM emulator, the vTPM or another dedicated function of the virtualization platform measures the IEC of the VM. The measurement result X is the result of the hash function X=hash(IEC). In this example, the IEC is loaded in the memory 105 that is the content of a certain address range within the memory is read and hashed. In an alternative embodiment, the VM emulator, the dedicated function or the vTPM can perform such measurement directly on a portion the image file including the IEC. In a further alternative, the VM emulator may measure the IEC during the load sequence of the VM into the memory.

The vTPM or the VM emulator may also obtain a secret value. Such value can be obtained from the pTPM of the host platform. In such case, the VM emulator may utilize the vTPM or part thereof as a proxy. In an alternative embodiment, the secret may be associated with the VM and could be part of the vTPM context obtained earlier. The obtained secret is pushed to the vTPM 106 and the vTPM extends one or more of its vPCR 107 associated with the VM with the secret. By doings so it may help to bind the vPCR associated with the VM to the pTPM of the host platform or the VM.

Then the VM emulator pushes the previously measured IEC result X to the vTPM, which in turn extends its vPCR with the results. For instance the vTPM may calculate vPCR=hash(X | | vPCR). Optionally the VM emulator or the vTPM may combined the result X with the previously obtained secret and calculate a new result X'. For example X' could be calculated as X'=hash(secret | | X). The new result X' is then pushed to the vTPM to extend its vPCR. The newly extended vPCR corresponds to the processed initial measurement and builds the root of trust for the subsequent boot sequence. After these first steps, the VM emulator starts to emulate the VM. After the VM emulator has started to emulate the VM, the emulator itself does not measure anything anymore, but only emulates the VM and works as a proxy in communication between the VM and its corresponding vTPM. The VM now initializes the VM booting sequence by executing the IEC. In a non-trusted system without measured boot, the IEC just continues with the booting sequence and the vTPM and the root of trust in the vPCR associated with the VM may not be used. To perform a virtual trusted boot however, the IEC will at some point measure a second boot block or executable code for the booting sequence. It can do so by itself or utilize functionality of the vTPM. For instance, it may call a function provided by the vTPM, which hashes a given data range, said data range corresponding to the executable code. The result Y=hash(second executable code) obtained by the IEC is pushed by the IEC into its vTPM using the dedicated interface vTIS, which transmits the respective TPM command (e.g. "Extend the vPCR with Y") to the vTPM. The vTPM 106 in turn extends the respective vPCR 107 value with Y.

In a subsequent step the second executable code is executed and the lEC passes the execution to the second boot block. The second executable block can now continue measuring a third boot block and repeat the process until a specific event is triggered.

Figure 10 illustrates another embodiment of a node from a functional perspective disclosing several aspects of the proposed principle.

Node 100 shows a snapshot of the trusted execution platform, which is structured in a layer shaped manner. The lower layers correspond to the host platform and they include the hardware of the host platform, the pTPM of the host platform, some lEC used to boot the host platform, BIOS and other parts. The host platform has performed a trusted boot and has launched the kernel and the operating system in a trusted state. The kernel provides system calls, access to hardware devices, network capabilities and so forth. On top of the kernel layer in the application layer of the trusted execution platform, the OS has started a vTPM Device with vTPM functionality. The vTPM Device or the underlying virtualization platform provides an interface TIS to the pTPM of the host platform, as well as one or more vPCRs. The vTPM Device also provides one or more virtual interfaces vTIS to the VM as explained later below. The combination of the vTPM Device, the interfaces and the TPM functionality resembles the vTPM.

The trusted execution platform also comprises a virtualization platform having a VM emulator, one of more virtual BIOS images and other functionality to emulate and execute one or more VMs. The virtualization platform communicates with the vTPM Device and the vTPM. In the present example the virtualization platform has executed a first VMl. VMl has performed a virtual trusted boot making use of the methods as discussed above. In particular, the lEC of VMl has been measured by a dedicated portion of the virtualization platform and its result pushed to the vTPM via the vTIS interface. The vTPM has extended vPCRl associated with VMl with the measurement. The lEC then has continued to boot and measured the BIOS of VMl. The different executable coeds have been measured and pushed via the vTIS to the vTPM. In these subsequent steps, the virtualization platform acts like a proxy and the executable code in VM1 directly requests TPM functionality via the interface vTIS.

In addition to the first VM1, the virtualization platform just executed a second VM, named VM2, by extracting the image into the memory and measuring the IEC of VM2. The measurement results have been pushed to the vTPM together with the request to extend the configuration register. The vTPM has associated vPCR2 with VM2 and the virtual trusted boot. Consequently, vTPM has extended vPCR2 with the measurement result provided by the virtualization platform. The IEC can now measure a second executable code and push the result to the vTPM or continue the boot sequence without trusted functionality. In an alternative embodiment of the above, each VM is associated with an individual vTPM, meaning that the virtualization platform comprises one or more vTPM's to serve one or more VM's executed by the virtualization platform. Each vTPM comprises a set of dedicated vPCR's associated with the respective VM and this would include vPCRs, endorsement keys, secret seeds of the TPM. The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated"