7.5 Security Architecture
7.5.3 Virtual TPM
In order to successfully use a virtual TPM as trust anchor, the following requirements must be satisfied:
R.1: Performance This goal states that the overhead from using a TPM in a VM should be negligible compared to directly executing commands on the TPM. The VM should therefore be able to execute TPM commands at nearly the same speed as when these commands are used on a non-virtualized machine.
R.2: Compatibility It should be possible to execute TPM command code in a VM without modifying the code or adapting it to the virtualized environment. Therefore, we explicitly forbid using paravirtualization techniques [185].
R.3: Simplicity A fault in a VMM can cause a failure in all VMs which could result in a crashing VM. A VMM that provides abstraction and sharing of a TPM should therefore be as simple as possible [132].
R.4: Security A TPM that is used in a VM should provide the same security prop-erties as if the TPM would be accessed natively.
R.5: Minimal modifications to the specification If the specifications by the TCG must be modified, these modifications should be as slight as possible, leaving the modifications and the specification as compatible as possible.
To satisfy these requirements, we are using a virtual TPM that is implemented in software and runs inside the Management VM. The advantage of a software TPM is that the requirements R.1, R.2, and R.5 can be achieved very easily, while the requirements R.5 and R.3 are harder to achieve. To achieve R.5, the software TPM needs to be protected by the hardware TPM to enable storing of persistent data. R.3 is partly achieved by implementing a software TPM that is as simple as possible.
In order to place trust into measurements reported from a virtual TPM, a com-plete trust chain from the hardware-based trust anchor up to and including the end application needs to be established. This includes all measurements performed by the hardware TPM as specified by the TCG [170], the bootloader (e.g., TrustedGrub [8]) and the hypervisor and the VM instances, including the virtual appliances. When a virtual TPM spawns, its PCR values are initialized with values from the underlying hardware TPM, as shown in Figure 7.4.
PCR Content of TPM Content of vTPM
0..7 Measurmnt. of CRTM and BIOS Measurmnt. of CRTM and BIOS
8..15 Measurmnt. of the Bootloader and TVMM Measurmnt. of the Bootloader and TVMM
16 empty Measurmnt. of the virtual appliance
17.. empty for free use
Figure 7.4: Mapping of the PCR values
In order to report the platform configuration of a TVM, a strong binding between vTPM and TPM must exist. Otherwise, it would be possible for the vTPM to report PCR values to a remote entity that are different from the ones that were measured by
7.5. SECURITY ARCHITECTURE 121 the underlying hardware TPM. Berger et al. [20] have already proposed three differ-ent solutions for this problem. After careful considerations, we decided to employ the solution in which each virtual AIK is bound to a hardware AIK. We believe that this solution has several advantages over the others. On the one hand it has strong similar-ities to the concepts provided by the TCG specifications as an additional Privacy-CA, and on the other hand, it allows quick spawning of additional vTPM instances.
(Hardware-) TPM
AIK
(1) Creates Privacy-CA or
DAA System
(2) Create credentials vTPM
vAIK
(3) Creates Attestation
Service
TPM-Manager Signature (from step 4)
(7) Uses for RA
(7) Create credentials
Virtualization layer
(5) Create and encrypt vAIK credential
(4) Signs the vAIK using TPM_Quote (6) Decrypt credentials
Figure 7.5: Binding the vTPM to TPM
Figure 7.5 shows the association of a vTPM with an underlying hardware TPM, as realized by our architecture. In step 1, the host TPM creates an AIK and in step 2 retrieves a corresponding credential through a Privacy-CA or via DAA [23]. In step 3, the vTPM then creates a vAIK, which is signed by the Host TPM, using his own AIK.
To prevent replay and masquerading attacks, aNonce provided by the vTPM instance, an additional timestamp, and the hash values of the hardware TPM’s PCR[0..15] are embedded into this signed message. The integration of the PCR value in the vAIK credential is necessary, since a trusted software configuration could otherwise be forged.
In Section 7.7.2, we will discuss why this concept prevents an attacker from forging a trusted software configuration. The corresponding credential is then encrypted using the KvEK and sent to the vTPM instance (5), that is in possession ofKvEK−1 and, therefore, able to decrypt this message. A vAIK credential contains the vTPM generated public vAIK and consists of:
•Timestamp
•Hardware PCR[0..15]
•Nonce
• vAIK
signed withAIK
•AIK credentials
For the remote attestation process, thevAIK is used to perform theTPM Quote com-mand. The verifying party can then decide whether the remote platform configuration is trusted by validating thevAIK credential and the delivered output of theTPM Quote command. A platform configuration is deemed trusted if the following conditions are satisfied:
• The vAIK is authentic and generated by a vTPM
• The vTPM is authentic and protected by a hardware TPM
• The hypervisor including management VM is in a trusted system state
• The hardware TPM is authentic
• The TVM is in a trusted state