TPM-backed Virtualisation

Virtualisation is the process of creating virtual computing systems or resources, such as a storage device or network. Virtual Machines (VMs) can imitate indepen-dent computing platforms (guest machines) with potentially different OSs that run upon the hardware of the host platform (host machine). VMs are instantiated and managed by a hypervisor or Virtual Machine Manager (VMM). Hypervisors are designed to provide strong isolation between guest machines to prevent a compromised guest machine from easily influencing other guest machines.

Software-only virtualisation, such as Android application sandboxing, is used in preventing inter-application compromises, as well as in commercial hypervisors, such as Xen, for guest-to-guest and guest-to-host security in cloud computing.

In this section, several key technologies are explored that instantiate TEEs using a TPM to launch a trusted hypervisor layer. These technologies make use of a Dynamic Root of Trust for Measurement (DRTM) and the concept of ‘late launch’. Here, secure boot is performed as usual in which hashes of critical boot components, e.g. BIOS and MBR, are loaded into PCRs 1–16 (see Section2.3.1).

Next, without requiring a reboot, the remaining PCRs (17–23) are reset to zero, and then the code necessary to load the TEE is measured and stored into these PCRs before it is executed. This assists in launching a trusted state without rebooting the entire machine in order to remeasure the relevant components. In this section, the major commercial and highly-cited academic technologies are examined.

Intel Trusted eXecution Technology (TXT)

Intel Trusted eXecution Technology (TXT) [80], formerly known as LaGrande technology, aims to defend computing platforms from generalised software at-tacks, including firmware, BIOS and rootkit attack vectors. TXT constructs a chain of trust using secure boot, which utilises the TPM as a root of trust. Late launch, performed using the SKENTER Intel CPU, is subsequently used to measure the state of the Intel TXT VMM launcher code. Any underlying system modifications to the BIOS, MBR or VMM, such as by rootkits and other surreptitious software, can be detected from deviations in the launch configuration from the TPM’s PCR values. TXT interoperates with Intel’s Virtualisation Technology (Intel VT) [81], which provides native hardware virtualisation extensions for providing high degree of isolation while retaining performance. Facilities are also offered for

FIGURE2.7: Using Intel TXT for trusted hypervisor launch and VM instantiation [79].

platform attestation in which a local or remote party is able to determine the trust status of the launch configuration of the platform or VM, i.e. whether or not it was instantiated correctly. A disadvantage of TXT is its significant hardware Trusted Computing Based (TCB), comprising the TPM, CPU chipset, motherboard and system buses. Figure2.7 illustrates a high-level architecture for instantiating trusted launch of VMs using TXT.

AMD Secure Virtual Machine (SVM)

AMD Secure Virtual Machine (SVM) is a TXT-like, DRTM-based environment for AMD chipsets that launches a trusted hypervisor using a TPM 1.2 on the com-puter’s motherboard. SVM provides a set of hardware extensions to maximise the efficiency of world switches between the hypervisor and guest domains, and allows the allocation of I/O device that can only be accessed by a particular guest machine (but not others) [82]. Similar to Intel TXT, SVM provides support for at-testation of the boot values measured with late-launch, which is performed using the SKINT CPU instruction. SVM provides an additional security mechanism,

‘automatic memory clear’, which erases the system’s memory contents after a reset to prevent an adversary from accessing secrets by simply reading memory contents.

Flicker & TrustVisor

McCune et al. [83] propose Flicker – a system architecture for protecting sensitive code execution from an adversary that controls the BIOS, OS and DMA-enabled devices. The aim of Flicker is to allow trusted execution of small arbitrary applications. Like Intel TXT and SVM, Flicker uses late-launch but, rather than launching a hypervisor, it pauses execution in order to run a small piece of application logic known as a Flicker module containing security-sensitive code.

Flicker executes the remainder of the paused execution flow, i.e. in the untrusted OS, after completing the execution of the Flicker module. Flicker modules are linked with and managed by another entity, the Secure Loader Block (SLB), for erasing secrets kept in memory, returning values through a bespoke Linux kernel module, and triggering the resumption of the untrusted OS’s execution.

Flicker application code is extended into PCR 17 by the SLB Core, which has an intentionally small TCB (0.312kB or 94 lines of code). This PCR value is included in remote attestation quotes such that remote entities can be convinced of the Flicker application’s operating state. Flicker is implemented and evaluated across a range of applications, including rootkit detection (up to 1022ms overhead), SSH password authentication (up to 937ms), and certificate signing (906ms).

TrustVisor is a second proposal by McCune et al. [84] that, like Flicker [83], allows the execution of sensitive applications while retaining a small TCB. Its primary difference is the use of an attestable, slimline hypervisor upon which sen-sitive applications are executed, rather than attesting an individual application.

TrustVisor is, hence, similar to Intel TXT and AMD SVM, but purposely omits scheduling and inter-process communication in order to minimise its software TCB. TrustVisor is larger than Flicker in terms of its software TCB – <10k lines of C and X86 Assembly, compared to Flicker’s <1k LOC – but yields greater performance, with only 7% overhead versus unprotected code. TrustVisor, like Flicker, is launched using a TPM using late-launch and attested similarly by extending a PCR responsible for the hypervisor code. TrustVisor also exposes individually virtualised ‘micro TPMs’ to each descendent application, in which the keys of each virtualised TPM is derived from the host (hardware) TPM, thus preventing applications from unsealing other applications’ sealed secrets. The state of each application is measured upon launch into a single PCR held in each micro TPM launched by TrustVisor. During remote attestation, these micro TPM PCRs are aggregated into a single value alongside the TPM’s PCR values collected at boot-time, rather than extending a virtually arbitrary number of application states into the TPM’s PCRs.