Professional Documents
Culture Documents
MPI-SWS
P i m
l u
s t e r
U s e r P u b l i c
N 3 N 4
S y s a d
m i n
components to manage the clusters. For simplicity, our
N e t w o r k
E T E
N 3 N 4
S y s a d m i n
1 .
1. nN C M
4 . F
2. {M LT C , nN }EK p , nT C
TC
2
.
3. P}
{{M LN , nT C }EK p , T KN P
1. {α, #α}KV M {nU , KV M }T K P
T KT
N T C
TC
3
.
N C
4
.
4. {accepted}T K P 2. {{{nU , KV M }T K P , nN }T K p ,
TC N
N
N }T K P
2 .
TC
3. {{nN , nU , KV M }T K P }T K p
Figure 3: Message exchange during node registration.
C
N T
3 .
N TC
4. {nU , N }KV M
implementation. The TC can cope with the occurrence Figure 4: Message exchange during VM launch.
of events such as adding or removing nodes from a clus-
ter, or shutting down nodes temporarily for maintenance
or upgrades. A user can verify whether the IaaS service ing, for each node within the security perimeter, the
P
secures its computation by attesting to the TC. public endorsement key EKN identifying the node’s
To secure the VMs, each TVMM running at each node TPM, and the expected measurement list M LN . The
cooperates with the TC in order to 1) confine the exe- ETE makes some properties of the TC securely avail-
cution of a VM to a trusted node, and to 2) protect the able to the public, namely the EKTPC , the M LT C , and
VM state against inspection or modification when it is the T KTPC (identifying the TC). Both the M LN and the
in transit on the network. The critical moments that re- M LT C express the canonical configurations that a re-
quire such protections are the operations to launch, and mote party is expected to observe when attesting to the
migrate VMs. In order to secure these operations, the platform running on a node N or on the TC, respectively.
TCCP specifies several protocols (see Section 3.2). Due In order to be trusted, a node must register with the TC
to space constraints, we do not address other critical op- by complying to the protocol depicted on Figure 3. In
erations such as suspend/resume allowed by Xen. steps 1 and 2, N attests to the TC to avoid an imperson-
We assume an external trusted entity (ETE) that hosts ation of the TC by an attacker: N sends a challenge nN
the TC, and securely updates the information provided to to the TC, and the TC replies with its bootstrap measure-
the TC about the set of nodes deployed within the IaaS ments M LT C encrypted with EKTp C to guarantee the
perimeter, and the set of trusted configurations. Most im- authenticity of the TC. If the MT C matches the expected
portantly, sysadmins that manage the IaaS have no priv- configuration, it means the TC is trusted. Reversely, the
ileges inside the ETE, and therefore cannot tamper with TC also attests to N by piggybacking a challenge nT C in
the TC. We envision that the ETE should be maintained message 2, and checking whether the node is authentic,
by a third party with little or no incentive to collude with and is running the expected configuration (step 3). The
p P
the IaaS provider e.g., by independent companies analo- node generates a keypair hT KN , T KN i, and sends its
gous to today’s certificate authorities like VeriSign. public key to the TC. If both peers mutually attest suc-
P
cessfully, the TC adds T KN to its node database, and
sends message 4 to confirm that the node is trusted. Key
3.2 Detailed Design T KN certifies that node N is trusted.
In this section we detail the most relevant TCCP mech- In the case that a trusted node reboots, the TCCP must
anisms. We describe the protocols that manage the set guarantee that the node’s configuration remains trusted,
of nodes of the platform that are trusted (Section 3.2.1), otherwise the node could compromise the security of the
p
and the protocols that secure the operations involving TCCP. To ensure this, the node only keeps T KN in mem-
VM management, namely launching and migrating VMs ory causing the key to be lost once the machine reboots.
(Section 3.2.2). In these protocols, we use the fol- The node is thus banned from the TCCP, since it will not
lowing notation for cryptographic operations. The pair be able to decrypt messages encrypted with the previous
hK p , K P i represents the private-public keys of an asym- key, and must repeat the registration protocol.
metric cryptography keypair. Notation {y}K x indicates
that data y is encrypted with key K x . We use a specific 3.2.2 Virtual machine management
notation for the following keys: EKx denote endorse-
ment keys, T Kx indicate trusted keys, and Kx denote We present the TCCP protocols to secure the VM launch
session keys. Nonces nx , unique numbers generated by and migration operations. When launching a VM, the
x, help detect message replays. TCCP needs to guarantee that 1) the VM is launched on
a trusted node, and 2) the sysadmin is unable to inspect
or tamper with the initial VM state as it traverses the path
3.2.1 Node management
between the user and the node hosting the VM. The ini-
The TC dynamically manages the set of trusted nodes tial VM state α contains the VM image (VMI) (that can
that can host a VM by maintaining a directory contain- be personalized and contain secret data) and the user’s
1. {{Nd , ns1 }T K p , Ns }T K P secure the transfer of the VM state. Before accepting the
N TC
P }
2. {{ns1 , T KN T K P }T K
p
C M
3 .
N d
d Ns TC
key, Nd first verifies that Ns is trusted (steps 4 and 5).
3. {{KS , ns2 }T K p , Ns }T K P If both nodes mutually authenticate successfully, Nd ac-
6 . Ns Nd
. 5
.
4. {{Ns , nd }T K p , Nd }T K P knowledges the acceptance of the session key to the KS
Nd TC
(step 6), and, in message 7, Ns finally transfers the en-
. 4
7
P }
5. {{nd , T KN P }T K p
s TK Nd TC
V M
1
.
6. {nd }KS
crypted and hashed VM state to the Nd , guaranteeing the
confidentiality and integrity of the VM.
N s T
2 .