is also based on a virtual machine monitor, called anisolation kernel, which establishes two different execution environments, i.e, VMs, with different trust-levels. NGSCB highly depends on hardware virtualization technology as well as on Trusted Computing technology. NGSCB also requires a security kernel (nexus) that runs on the isolation kernel. This nexus has similarities to the TVM in our approach. However, it does not provide any means of using attestation techniques for trust-establishment.
Secvisor is another very interesting approach that has been proposed by Seshadri et al. [148]. In this approach, the authors propose a very small virtual machine mon-itor that heavily makes use of virtualization-supportive hardware. Since Secvisor only supports one virtual machine, the hypervisor does not need to perform scheduling or interrupt handling and is, thus, very small. Secvisor aims at ensuring code integrity for commodity OS kernels. However, since it only supports one virtual machine, isolated security sensitive environments that can be used for sensitive transactions can hardly be formed.
Jansen et al. [87] also showed how the integrity of different virtual machines can be ensured by adding Trusted Computing technology to a virtual machine monitor. In this context, Jansen et al. make use of the Xen-hypervisor and, similar to us, add Trusted Computing to the Dom0. However, in contrast to our work, Jansen et al. propose to integrate the attestation service in the privileged Dom0. We believe that this approach is rather impractical since integrating the attestation service inside the Dom0 increases the complexity of this Domain. In addition, Jansen et al. only implemented parts of their design, and, therefore, it can only be speculated how the exact realization will look.
7.10 Summary
We have presented the design and security mechanism of a security architecture that is capable of supporting attestation techniques. Our proposed security architecture is based on virtualization-techniques and provides an isolated security environment where confidential data can be processed. We introduced a four layer protection architecture based on virtualization technology and attestation techniques. The four layer approach enables (1) leveraging attestation techniques for trust-establishment by achieving a meaningful attestation process and (2) containing security breaches in an isolated com-partment. This approach guarantees software integrity and prevents an attacker from tampering with the software configuration of a platform. Our proposed security archi-tecture can be used as a foundation for constructing next-generation secure operating systems that rely on Trusted Computing technology. Since we do not use some sort of sealing techniques, sytem updates in our architecture can be easily handled. However, the virtual TPM used in our approach is not able to achieve all our introduced security requirements for a virtual TPM. As a result, a new approach which we will discuss in the next chapter is necessary.
Chapter 8
Virtualization-Enhanced TPMs
In this chapter, we present the design of a TPM that supports hardware-based virtual-ization techniques. Our approach enables multiple virtual machines to use the complete power of a hardware TPM by providing for every virtual machine (VM) the illusion that it has its own hardware TPM. The approach presented in this chapter uses recent de-velopments in the virtualization technology of processor architectures. This chapter shares some material with Enhancing Trusted Platform Modules with Hardware-Based Virtualization Techniques [157].
8.1 Introduction
We have seen in the preceding chapters, that using the attestation mechanisms of the TPM requires a system that is based on virtualization [123]. This is especially true if a system wants to demonstrate to a remote party that it is in a trusted state by using the attestation facilities of a TPM.
Virtualization technologies are getting increasing interest from both industry and academia because they offer an alternative means of hardening an operating system and, thus, of increasing system security [14, 118]. This trend is also reflected in the current hardware architectures. Intel [37, 38] and AMD [6] have added virtualization support to their processor architectures in order to accommodate emerging developments that require the support of multiple virtual machines (VMs) on a single entity. This is not only of interest in the server market, where the execution of multiple commodity operating systems should be supported on a single machine, but also in the client area, where there is a need to completely increase system security and reliability [167].
Unfortunately, as already mentioned in Chapter 7, the TPM was never designed to be used in virtual environments, and is, thus, not capable of being used in a system that is based on virtualization. We circumvented this fact be introducing a software TPM in Chapter 7 that enables the different virtual machines to use their own virtual TPM.
However, this approach does not provide the same security level, since the virtual TPM is completely implemented in software and, thus, cryptographic secrets are temporarily not protected by hardware. If for example an attacker gained control of the Management
139
VM, he might be able to access the secure storage of a virtual TPM and access sensitive VM data.
To provide life-time protection of cryptographic secrets and the possibility of using the functionalities of a hardware-based TPM inside the VMs, we propose to use a TPM that is capable of supporting virtualization with hardware measures. We present the design of such a TPM and show how the interactions between the VMs and the TPM could be realized. The approach presented in this chapter utilizes hardware-based virtualization techniques as provided through Intel’s VT processor architecture.
The remainder of this chapter is organized as follows: we first look in Section 8.8 at other work that is related to our proposal. We then extract requirements for a hardware-based virtual TPM and present the main idea of our approach in Section 8.2.
In Section 8.3, we explain our architecture and the components that are involved in our approach. Section 8.4 shows how we enable the different VMs to directly use the underlying hardware TPM. Section 8.5 presents the protocol for securely migrating a TPM context to another VM. In Section 8.6, we explain how the endorsement credentials for the different TPM contexts are handled and how the TPM management commands are realized. We summarize with Section 8.9.