Data structures

In this appendix we discuss the two most important data structures which play a role in our implementation.

EncryptedVM. In Fig. B.3 we exhibit how we apply a full disk encryption (fde) scheme to secure the vm (the precise fde scheme follows later in appendix B.8.1). The notion of a vm that the cloud consumer might have, is in fact simply a filesystem on a virtual disk with n sectors. By applying encryption on each sector of this virtual disk using key s, we get the data structure we refer to as the encrypted virtual machine (evm).

We remark that the symmetric key s is not only used for encrypting the filesystem but also for important pieces of metadata which also need to be protected (discussed below). Hence, key s plays a central role in our data structures. For maximum entropy, and considering that the key never needs to be entered by the user, this key should be generated randomly by the cloud consumer’s software the first time.

Merkle tree. For efficiency reasons, fde schemes are typically designed such that decrypting a single sector does not depend on the decryption of other sectors (although the position with respect to other sectors matter, i.e., swapping will be detected).

This has no consequences for confidentiality as long as the block cipher is sufficient and the fde scheme does not leak information. However, for integrity,

uuid& Policy Merkle tree Counter value vtpm- nv s concatenated Master key s k Memory blob s hmac s Merkle tree vtpm- nv Master

key s domc id domu id

vmcb:

s =encrypt

with key s

csinfo:

Figure B.4: The vmcb data structure (which is provided to the domt by the

consumer), and the csinfo data structure (which is injected into the domc later). Variable s is a randomly-generated symmetric key also used in evm (cf. Fig. B.3) and k is the public binding key. As visible, s itself is encrypted

by k. For all encryption, padding and cbc are applied if necessary.

the implications are that any tampering with the ciphertext at a single position will only scramble parts of the plaintext and not the complete filesystem. Such tampering might go undetected with the user (violation of integrity of vm, R2). Furthermore, by default such a scheme offers no protection against an adversary rolling back certain blocks with older versions (freshness, R4).

Integrity protection using message authentication codes (macs) is a well known approach in information security. Moreover, as identified by Yun et al., it is inevitable that each block will have to be hashed in order to achieve complete integrity protection of a disk — this cannot be reduced further[YSK09].

Therefore, we calculate macs of all the disk sectors and construct a hash tree of these, i.e., a Merkle tree [Mer87]. In the upper part of Fig. B.3 an example of such a Merkle tree is shown. After the construction of the Merkle tree is complete, the encrypted virtual disk EVM is the first component of the tuple that will be sent to the cloud later on. For the sake of integrity, the Merkle tree much be protected as secure as the key s, though it suffices to store only the topmost hash, since the tree can be rebuilt with only the topmost hash.

Metadata. Figure B.4 shows the virtual machine control blob (vmcb) structure. The vmcb contains metadata regarding the vm which the consumer wants to virtualize. The uuid is uniquely generated for this vm and is unencrypted to ease administration for the csp.

The virtual tpm non-volatile memory (vtpm-nv) contains the non-volatile memory of the consumer’s vtpm. By determining the contents of the vtpm-nv beforehand, the consumer is able to secure high value keys under all circum-

B. Implementation details

stances (req. R1_{); even if the vm is compromised, the hvks remain secure.} The virtual counter value (cf. tc introduction, section 2.3) is the value the virtual counter had at the time of vmcb update. The value will be initialized to zero by the cloud consumer when creating the vmcb. The domt will maintain a set of virtual counters indexed on the uuid of the vmcbs. This ensures that a malicious insider cannot rollback the vmcb — nor the evm of which the Merkle tree is a digest (req. R4).

The memory blob is an optional parameter and will not be used directly by the cloud consumer. When Xen saves the execution state of a vm to disk, the ram of the vm is an additional asset that needs to be protected with the same requirements as the evm.

The hash-based message authentication code (hmac) glues all the properties of the vmcb together and prevents individual properties from being rolled back by a malicious insider (req. R4). The master key s will be encrypted using an asymmetric key k, which refers to the certified binding key of the target platform.

The csinfo shown in Fig. B.4 refers to the data which is injected into domc during domain creation (cf. Fig. 6.6). The csinfo contain certain data from the vmcb as well as two domain identifiers; by injecting these values in domc by a trusted source (domt), domc cannot be tricked into offering the passthrough encryption to the wrong domain by a malicious insider abusing the Xenstore (req.R3_{, coupling of vm and hvks). We discuss this attack and its implications} in more detail in appendix E.

Figure B.5 exhibits the interaction between the entities when deploying a vm. In the first phase, the consumer takes preparatory steps which are merely the implementation steps of constructing the entities shown in Fig. B.4, namely the evm and vmcb structures. Because domu is indirectly built (cf. Fig. 6.6), the evm (variable d) stays in dom0 _{and only the vmcb (variable b) is transfered to} domt.