Architecture for supporting attestation of a virtual machine in a single step

[0001] IBM® is a registered trademark of International Business Machines Corporation, Armonk, N.Y., U.S.A. Other names used herein may be registered trademarks, trademarks or product names of International Business Machines Corporation or other companies.

[0002] 1. Field of the Invention

[0003] This invention relates to improving the performance of attestation to the state of virtual machines on virtualizeable computer systems through a single-step attestation process.

[0004] 2. Description of Background

[0005] The TRUSTED COMPUTING GROUP (TCG) has defined a transitive trust model architecture where software measures the next layer of software before that layer is executed. The digests of these measurements are extended through a one-way hash function into Platform Configuration Registers (PCRs) contained in a TRUSTED PLATFORM MODULE (TPM). The names of the measured file or data and the digest values are appended to a list of measurements. The overall procedure begins with a Core Root of Trusted for Measurement (CRTM), which is code that is run early in the boot process after a computer system has been started.

[0006] During the remote attestation process, a set of PCRs is quote-digested and digitally signed with a trusted signing key, such as for example an Attestation Identity Key (AIK). The remote party/system validates the AIK certificate issued by a trusted privacy certificate authority, the digital signature of the quote, and the integrity of the measurement list by comparing it to the PCR state included in the quote. Once the measurement list has been evaluated, the remote system uses it to determine whether the attesting system is running trusted software.

[0007] In an exemplary embodiment, evaluating the state of a software environment means to replay the log of all hashes of software that was started on the system. If one or multiple pieces of software were started on a system that is determined to be untrusted, the whole system may be declared as untrusted. Untrusted software may be recognized through a hash that explicitly identifies a piece of software to be untrusted or through a hash that is not known to the evaluating system. The replay of the log of all hashes has to match with the state of the PCR registers that affected these logs and were returned in a quote. Further, the signature over the state of the PCR registers must be verifiable.

[0008] Virtualizeable systems allow users to spawn multiple virtual machines (VM) that each can run an Operating System independently from those of other VMs. An implementation of such a system may offer the capability to spawn new VMs from within a VM, thus creating a hierarchy of VMs with a parent-child relationship between creating and created VMs. On many virtualizeable systems an initial VM is created during system boot. This VM serves for system management purposes and is for example used for the creation and destruction of other VMs.

[0009] For the purpose of supporting trusted computing in a virtualizeable system it is expected that within each VM software is running that implements support for the transitive trust model architecture described previously. An outside challenger who wants to establish trust into a VM would not only be interested in establishing trust into the software running inside of that VM, but also in the software that has been used to start this VM from inside its parent VM. This includes the operating system inside the parent VM, applications involved in the process of starting a VM, the underlying virtualization layer (hypervisor), and all other layers used during system startup including the CRTM.

[0010] In a typical system, the trust establishment would require a challenger to perform several different steps by individually challenging all VMs on the direct path (in the hierarchy) from the root VM to the one of interest. This is regarded as necessary since all these VMs are part of the trust chain to the one of interest. If one of these VMs is untrusted, its descendants are also untrusted. The proposed architecture, that in part gives rise to the present invention, creates a solution that allows more efficient support for establishing trust into a VM by allowing a one-step attestation process.

[0011] The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method of mapping platform configuration registers of a TRUSTED PLATFORM MODULE or virtual TRUSTED PLATFORM MODULE instance into the register space of a virtual TRUSTED PLATFORM MODULE, said method comprising: reading a state of a platform configuration register from an internal state of the processing TRUSTED PLATFORM MODULE if the platform configuration register is a non-mapped platform configuration register; and requesting selectively the state of a plurality of mapped platform configuration registers from a source providing the plurality of mapped platform configuration registers.

[0012] Also, the shortcomings of the prior art are overcome and additional advantages are provided through the provision of a computer readable medium for remotely attesting to the state of a virtual machine, said computer readable medium comprising: a program code for controlling a computer system, said controlling further comprising: sending a request to said virtual machine for quoting a plurality of mapped platform configuration registers and a plurality of non-mapped platform configuration registers; receiving a plurality of quote signatures covering the plurality of mapped platform configuration registers and the plurality of non-mapped platform configuration registers of the request in a quote response; and evaluating the current state of the virtual machine.

[0013] Also, the shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method of attesting to a plurality of child virtual machines that are direct descendants of a parent virtual machine, the method comprising: sending a quote request for quoting a plurality of mapped platform configuration registers and a plurality of non-mapped platform configuration registers to a first child virtual machine; and receiving results of the quote request and evaluating the current state of the first child virtual machine, the first child virtual machine having a first child state. The state of one or multiple parent virtual machines is described through the state of mapped platform configuration registers. If the state of those registers is determined to represent the state of one or multiple parent virtual machines that is untrusted, the first child virtual machine is declared as untrusted as well as all other child virtual machines, since they are all direct descendants of that untrusted parent virtual machine. Otherwise the state of those registers represents the state of one or multiple trusted parent virtual machines. Further the state of the child virtual machine is evaluated through the state of the non-mapped platform configuration registers. If the state of the child virtual machine is declared as trusted, the state of all mapped platform configuration registers is remembered. When quote requests are sent to the other child virtual machines, the state of mapped platform configuration registers is only evaluated if it has changed since their previous evaluation. The state of the child virtual machine is evaluated through the state of its non-mapped platform configuration registers. This process is repeated until all child virtual machines have been evaluated. If during the evaluation of all child virtual machines the state of mapped platform registers is determined to represent an untrusted state, then child virtual machines that have previously been declared to be trusted may now be declared to be untrusted.

[0014] System and computer program products corresponding to the above-summarized methods are also described and claimed herein.

[0015] Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. For a better understanding of the invention with advantages and features, refer to the description and to the drawings.

[0016] As a result of the summarized invention, technically we have achieved a solution which through the mapping of PCR registers, the procedure of attesting to the overall state of a virtual machine can be accelerated, since the state of all measurements relevant to the trustworthiness of a virtual machine are all visible in the combined view of mapped and non-mapped PCR registers.

[0023] The detailed description explains the preferred embodiments of the invention, together with advantages and features, by way of example with reference to the drawings.

[0024] Turning now to the drawings in greater detail, the present invention allows a virtual TPM instance to map the PCR register state of a parent virtual TPM instance into its own register space and export the state of those registers to applications inside the virtual machine associated with the virtual TPM instance. Through the mapping of PCR registers, the procedure of attesting to the overall state of a virtual machine can be accelerated, since the state of all measurements relevant to the trustworthiness of a virtual machine are all visible in the combined view of mapped and non-mapped PCR registers. Mapped registers reflect the state of trustworthiness of those virtual machines that were involved in the creation of the virtual machine that is being challenged.

[0025] Virtualizeable systems allow users to spawn multiple VMs that each can run an Operating System. In many virtualizeable systems an initial VM is created automatically during startup of the system and used for system management purposes, such as creation and destruction of other VMs. For the purpose of building architecture supporting trusted computing, this initial Operating System also logically owns device access to the hardware TPM of the system and runs software supporting the aforementioned transitive trust model architecture.

[0026] In a virtualizeable system, a virtualized TRUSTED PLATFORM MODULE (vTPM) offers trusted computing functionality to each VM that is started after the VM that is hosting the vTPM. The vTPM is typically hosted in the management VM. The vTPM's primary task is to spawn a virtual TPM instance for each VM requiring access to TPM functionality. Each created virtual TPM instance is then associated with a VM throughout the lifetime of that VM. Such a virtual TPM instance then offers the full TPM functionality to its associated VM as the hardware TPM does to the management VM. This includes providing access to a set of PCR registers that can be controlled by software running inside the VM.

[0027] It is expected that Operating System software running inside each VM also implements the previously described transitive trust model architecture and takes measurements of each piece of software before execution control is transferred to that software. This measurement-taking software can be designed such that the digest of the measurements are extended into a PCR register whose index is distinct from the ones of the measurement-taking software inside the VM hosting the vTPM. For practicality reasons that index would typically be an increment of one compared to the highest PCR register index used by measurement-taking software inside the parent VM.

[0028] An outside challenger who is interested in establishing trust into a VM is not only interested in the software that is running inside that VM, but also needs to be able to establish trust into other components of the system. This includes the software layers up to the CRTM, such as the previously mentioned hierarchy of VMs and the software running inside of each VM, the hypervisor of the system, the used boot loader and others pieces of software.

[0029] The proposed architecture allows a challenger to establish trust into any VM by only challenging that VM. The single challenge reveals all relevant measurements and the log of names of measured applications and data such that the challenger can decide about whether to establish trust into a VM. This result is achieved through mapping a subset of PCR registers of the parent VM into the set of PCR registers of the challenged VM. The mapped registers include all the ones used by software implementing the transitive trust model architecture. Furthermore, a driver inside the challenged VM is implemented such that the part of the measurement log-affecting mapped PCR registers can be fetched from the parent VM. PCR registers that are mapped into the PCR register set of a virtual TPM instance cannot be extended but are read-only since they are not logically owned by that virtual TPM instance. All non-mapped register can be modified as usual. It should be noted that mapping of PCR registers is an optional feature and virtual TPM instances can still be created, even on the same system, that do not map any of the parent TPM's PCR registers into their space. It should also be noted that this architecture can map a subset of the hardware TPM's PCR register into the space of each virtual TPM.

[0030] Referring to FIG. 1 there is illustrated one example of the parent-child relationship between virtual TPM instances in a system. In an exemplary embodiment, the virtual TPM instance 202 can be regarded as the root virtual TPM instance with two child virtual TPM instances 204 and 206. Virtual TPM instance 208 is the child virtual TPM instance of virtual TPM instance 206. The hardware TPM 200 is a system's hardware TPM and shown for completeness reasons.

[0031] Referring to FIG. 2 there is illustrated one example of the mapping of a subset of the hardware TPM's PCR registers into the register space of a virtual TPM instance. In an exemplary embodiment, hardware TPM 300, which corresponds to the hardware TPM 200 in FIG. 1, has a set of PCR registers 302 of which a subset 304 of those registers is mapped into the PCR register set of a virtual TPM instance 310, which for example corresponds to the virtual TPM instance 202 in FIG. 1. Various programs are using the mapped registers 304 and implement the transitive trust model architecture. Such application programs may include a PC's BIOS, the boot loader and an integrity measurement architecture running inside the virtual machine that is associated with the hardware TPM.

[0032] In an exemplary embodiment, it should be noted that an implementation of a virtual TPM can be made completely in hardware. In such a configuration, the hardware TPM 200 would not map its platform configuration registers into the register space of any virtual TPM instance of such a virtual TPM.

[0033] The PCR register set 304 that is mapped into the register space of the virtual TPM offers read-only registers 312 to applications communicating with the virtual TPM instance 310. All other registers 314 of the virtual TPM instance 310 can be modified by applications communicating with the virtual TPM instance. Inside the virtual machine that is associated with the virtual TPM instance 310 an integrity measurement architecture is running and using one of the non-mapped registers that allow modifications (read and write access). It should be appreciated that not only the hardware TPM 300 as illustrated in FIG. 2 can provide platform configuration registers for mapping, but also the Virtual Trusted Platform 310 module instance can provide platform configuration registers for mapping into the register space of one or multiple of its child virtual TPM instances, such as for example virtual TPM instances 202, 206, and 208 in FIG. 1.

[0034] Referring to FIG. 3 there is illustrated one example of a method illustrating the process of reading the PCR register values from the virtual TPM instance's internal state or from the source providing the mapped registers.

[0035] In this regard, in an exemplary embodiment, the present invention provides a method for mapping PCR registers of a parent virtual TPM instance or the hardware TPM into the PCR register space of a virtual TPM instance, comprising: receiving a request to read the state of a PCR register, and determining whether the index of the PCR register corresponds to a PCR register that is mapped; and reading the state of the PCR register from the source providing the mapped PCR register if it is a mapped PCR register, or reading the state of the PCR register from the virtual TPM instance's internal state if it is not a mapped PCR register; and returning the state of the PCR register. The method 400 begins in block 402.

[0036] In block 402 the contents of a PCR register ‘n’ whose contents may either be mapped or not mapped is read. The request to read the content of a PCR register is received by a virtual TPM instance or the hardware TPM. Processing then moves to decision block 404.

[0037] In decision block 404 a determination is made as to whether the PCR register ‘n’ is a mapped register or a register whose contents are fully managed by the virtual TPM instance. If the resultant is in the affirmative that is the PCR register ‘n’ is a mapped register the processing moves to block 406. If the resultant is in the negative that is the PCR register ‘n’ is not mapped then processing moves to block 408.

[0038] In block 406, in an exemplary embodiment, if it is determined in decision block 404 that the register is a mapped register, then a request for reading the register content is formulated and sent to the source providing the mapped register. Processing then returns to block 402 of the parent TPM, which receives the request.

[0039] In block 408, if it is determined in decision block 404 that the register is owned by the entity evaluating the request, thus a negative resultant in decision block 404, then the register content is read from the internal state. Processing then moves to block 410.

[0040] In block 410 the value is returned and the routine is exited.

[0041] Referring to FIG. 4 there is illustrated one example of a method illustrating the process of quoting a set of PCR registers containing mapped and non-mapped registers using a key that is owned by the virtual TPM instance. In an exemplary embodiment, routine 500 effectuates a method of quoting the contents of PCR registers using a given key. The method begins in block 502.

[0042] In block 502 a request to quote the contents of a set of PCR registers is received by the virtual TPM instance or the hardware TPM. Processing then moves to block 504.

[0043] In block 504 the contents of all mapped and non-mapped PCR registers are read from their sources according to the procedure described in routine 400. Processing then moves to block 506. In block 506, in accordance to the policy of the system or the implementation of the entity handling the request, the signature for the quote response is made using a key owned by this entity. Processing then moves to block 508.

[0044] In block 508 the resulting signature and quote are returned to the caller. The routine is then exited.

[0045] Referring to FIG. 5 there is illustrated one example of a method 600 illustrating the process of quoting a set of PCR registers using keys that are owned by the virtual TPM instances or the hardware TPM that maps the registers. The method begins in block 602.

[0046] In block 602, in an exemplary embodiment, the request to quote the contents of a set of PCR registers is received by the virtual TPM instance or the hardware TPM. Processing then moves to block 604.

[0047] In block 604 a determination is made as to which of the registers selected for quoting by the caller are mapped registers ‘M’ and non-mapped registers ‘U’. Processing then moves to block 606.

[0048] It should be noted that the mapping of the PCR registers into the PCR register set of a virtual TPM instance also has an effect on how the virtual TPM instance can issue quotes for different combinations of PCR register sets spanning only mapped registers ‘M’, only non-mapped registers ‘U’ or both types of mapped and non-mapped PCR registers ‘M’ and ‘U’. Three combinations of requests for signing the state of PCR registers are possible. These options include:

[0049] 1. A request for a quote that involves only mapped PCR registers ‘M’. In this case the virtual TPM instance may forward the request to the parent virtual TPM instance or the hardware TPM requesting a signature using that TPM's signing key, i.e., AIK, or it may issue a signature over the PCR registers itself, depending on the policy of the system.

[0050] 2. A request for a quote that involves only non-mapped PCR registers ‘U’. In this case the virtual TPM instance issues the signature using its own signing key, i.e., AIK; and

[0051] 3. A request for a quote that involves mapped registers ‘M’ and non-mapped PCR registers ‘U’. In this case the virtual TPM could split up the quote request in two sub-requests. The one sub-request would span only mapped PCR registers ‘M’ and would be forwarded as a quote request to the parent virtual TPM instance, which would treat the request according to these rules. The other sub-request would only cover non-mapped PCR registers ‘U’ and would be treated according to option 2 above.

[0052] In block 606 a request for a quote of the register set ‘M’ is sent to the parent virtual TPM instance or the hardware TPM along with the handle of a key that can perform the signing of the quote. It is ‘waited’ until the response, a signature over the state of the register set ‘M’, has been returned. To process such a request, execution returns to block 602 and resumes in 606 when the response has been received. Processing then moves to block 608. In block 608 the quote response for the non-mapped registers ‘U’ is formed and a signature is provided. Processing then moves to block 610.

[0053] In block 610 results from blocks 606 and 608 are combined in a response and returned to the caller. The routine is then exited.

[0054] In an exemplary embodiment, the present invention provides a method for mapping PCR registers of a parent virtual TPM instance or the hardware TPM into the PCR register space of a virtual TPM instance, comprising: receiving a request to extend the state of a PCR register, and determining whether the index of the PCR register corresponds to a PCR register that is mapped; returning an error value if it is a mapped PCR register, or extending the state of the PCR register held in the virtual TPM instance's internal state if it is not a mapped PCR register; and storing the extended state into the PCR register.

[0055] Another exemplary embodiment of the present invention provides a method of a virtual TPM instance to quote a set of PCR registers, comprising: determining that the set of PCRs spans only non-mapped PCR registers and forming and signing the quote using the virtual TPM instance's own signing key (i.e., AIK); determining that the set of PCR registers spans only mapped PCR registers and forwarding the quote request to the parent virtual TPM instance or hardware TPM for quoting; determining that the set of PCR registers spans mapped and non-mapped PCR registers and determining the policy for issuing quote signatures for this case; reading the state of the PCR registers from their appropriate sources and signing the quote using the virtual TPM instance's attestation identity key in accordance to the policy of the system; or reading the state of the PCR registers and signing the non-mapped registers with the virtual TPM instance's signing key and formulating a quote request for the mapped PCR registers and forwarding the request to the parent virtual TPM instance or hardware TPM for performing the quote.

[0056] Another exemplary embodiment of the present invention provides a method to challenge a virtual machine by sending a single request for quoting of a set of PCR registers and a request for the log of measurements affecting the quoted set of PCR registers, comprising: formulating and sending the request for quoting a set of PCR registers to the challenged VM; receiving the response from the challenged VM containing one or multiple quotes and a log of measurements; determining which subset of PCR registers has been quoted with which signing key; verifying each quote signature individually; evaluating those entries in the log of measurements that affected the set of PCRs contained in the quote; determining whether to establish trust into a VM based on the software that has been started on the remote system.

[0057] Another exemplary embodiment of the present invention provides a method for efficient large-scale trust establishment into VMs running on a particular system comprising: sending a quote request and evaluating its response to a first VM according to the previously described aspect of the invention; remembering the state of mapped PCR registers for subsequent evaluations; sending quote requests to each subsequent VM on the same system and determining that the state of mapped register has not changed and requesting measurement logs only for those platform configuration registers whose value is different than those that have previously already been evaluated and evaluating the state of the system.

[0058] Another exemplary embodiment of the present invention provides a method for efficiently determining the trustworthiness of child VMs in a system, comprising: determining that a VM is declared not trustworthy and therefore declaring all its descending VMs, such as for example its child-VMs, as not trustworthy.

[0059] Therefore, the present invention provides a method, system and program product to efficiently challenge and establish trust into a VM by establishing trust into all relevant pieces of software affecting the trustworthiness of a VM.

[0060] The capabilities of the present invention can be implemented in software, firmware, hardware or some combination thereof. In an embodiment of the present invention, a virtual TPM that has the capability to map PCR registers into the register space of virtual TPM instances can be implemented in software. It may have the ability to map the registers of a present hardware TPM into the register space of one or multiple of its virtual TPM instances. In another embodiment of the present invention, a virtual TPM with those capabilities may be fully implemented in a piece of hardware.

[0061] As one example, one or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.

[0062] Computer readable media can include transitory and non-transitory mediums.

[0063] Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.

[0064] The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.

[0065] While the preferred embodiment to the invention has been described, it will be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the invention first described.