The basic scheme

The basic scheme involves the most simple secure workflow. A tpm-bound public key is shared with the cloud consumer who uses this key to deliver his or her hvks to the domt in encrypted form. The domt will then request the tpm to decrypt the hvks on its behalf.

The public key used is not an ordinary asymmetric key but a certified binding key which guarantees that the key can only be used by trusted software. Using certified binding keys for securely delivering secrets has been successfully applied before [Sad+07].(Although such previous use cases are in a non-cloud scenario, this does not affect how the tc technology works.)

Figure 5.4 exhibits the interaction with the tpm to set up and distribute a certified binding key. For clarity, we omitted the required tpm overhead such as encapsulating commands in osap and oiap sessions1 and supplying authentication data (password) parameters.2 Likewise, we assume that the tpm has been taken ownership of, and that either the srk authentication data (password) is set to a well-known value or that domt possesses this information.

The first step in the scheme is that domt creates a certified binding key which is represented as the pair (PK_BIND, SK_BIND). Second, this key and its 1_{These sessions are used to protect the freshness of communication with the tpm and also}

obviate the need to send passwords to the tpm in cleartext.

2_{We do not use a nonce in the key certification. The reason is that it is not important}

when the key has been generated and certified, but what its properties are. Because the binding key is non-migratable, these properties will never change[SSB07, p. 61].

5. Architecture

:consumer _{:dom0 :domt :tpm}

hTPMiReadPubEK() PKEK hTPMi_{PCRRead(pcr=17..19)} r := {p17, . . . , p19} hTPMiCreateWrapKey( type=bind, pcrs=r, locality=2, parentKey=HSRK )

PKBIND, ESKBIND

hTPMiLoadKey2(PKBIND, ESKBIND)

HBIND

hTPMiCertifyKey(key=HBIND, by=PKEK)

CBIND store( PKBIND, CBIND, PKEK ) retrieve() PKBIND, CBIND, PKEK

Figure 5.4: Interactions between consumer, dom0_{, domt and tpm for receiving} a binding key.

PK is a public key, ESK is a tpm-encrypted secret key, C is a certificate, H is a tpm-specific key handle.

certificates are stored in dom0_{, since domt does not have network access. Third,} dom0 distributes the key and its certificates to the cloud consumer (though in practice this would flow via the cloud infrastructure). Before using the key, the cloud consumer will verify the certificates and check whether the software to which the key is bound corresponds to a list of known hash digests of trusted software.

Data structures. Once the cloud consumer is in possession of the certified binding key and has verified it, he or she can use this to encrypt hvks and send these to the cloud. However, not only the hvks are encrypted (req. R1); the vm as a whole needs to be encrypted, too (req. R2). This is captured in the following definitions. (These data structures are discussed in more detail in appendix B.2.)

• Encrypted virtual machine (evm): the cloud consumer’s vm, encrypted using a symmetric key.

• Virtual machine control blob (vmcb): a blob of important metadata regarding the vm, in particular the symmetric key used for the evm. This blob itself is encrypted using the npk.

• Node public key (npk): a name for the set of the public binding key and its certificates (the ek public key with its endorsement credential and the certificate on the binding key which describes the pcrs used). When we use the term node, we refer to one of the physical vm-hosting machines in the csp’s data center.

5.3.1.1. Discussion on the basic scheme

While the thus far described scenario provides ample security against eaves- droppers, there is room for improvement.

1. The appraising party (the consumer) has no guarantee that the ek belongs to a real tpm and not a malicious, virtual tpm. A solution for this is to rely on endorsement credentials supplied by tpm manufacturers together with the tpm. (That is, if appraisers trust the manufacturer.) In practice, however, such certificates are not consistently issued by manufacturers, and even if we find one then we cannot rely on it for this very reason, since csps do not like to be locked-in to specific vendors.

5. Architecture

2. In the protocol we encrypt the vmcb for one specific tpm. This means that the vm cannot be migrated to another machine. It also removes the freedom on the csp’s part of deciding where the vm is run (e.g., in a part of the cloud which is under the least load at that moment) but instead necessitates that the vm is deployed on the specific node for which the binding key was given to the consumer.

3. The burden of interpreting the pcrs lies at the consumer. Verifying pcr measurements is notoriously demanding: the number of valid configura- tions in a commodity os is huge due to the sprawl of libraries and all the different versions of this software. The challenger has, in theory, to analyze whether every existing operating system and every patch-level has the “desired” configuration [SS04].

Fortunately, the set of valid software configurations of the tcb we are considering in this thesis (the hypervisor plus a few tools) is a magnitudes smaller than the configurations in a typical Windows or Linux tcb. Moreover, we can be much more stringent in which version we allow or not. One may expect a csp to be resolute in keeping systems up to date (even if the outdated version has not been proven vulnerable), more so than one may expect of end users in a desktop trusted computing setting. Nevertheless, it remains a daunting task for consumers to verify the hashes themselves if the task is not delegated. Consumers would need to compile all the software themselves in order to verify the hashes. Moreover, any proprietary changes made to Xen by the csp will — unless the reluctant csps cooperate and give insight into their modifications — cause mismatches.

4. The privacy of the csp is at risk. It is in the csp’s interest to keep the cloud appearing homogeneous to consumers, but this is hard to guarantee.

a) Two consumers can easily see if they are co-resident by comparing their received binding key fingerprints.

b) When recognizing a key fingerprint, it is easy for consumers to see that they have been hosted at a certain node before, and cloud consumers can use this information to determine the size of the cloud using the birthday paradox.

Obfuscation techniques can be conceived (e.g., a fresh key for each cus- tomer for each machine) but they will require careful engineering.