cloud providers have a strong incentive
to bolster the confidence of their customers, such transparency conflicts
with an operational desire to maintain
some degree of secrecy regarding the
software stack for competitive reasons.
At the End of a Long Day...
Friday, 21: 17. Transmogrifica head-
quarters, Palo Alto…
Robin and Andrea are reflecting on
their long day in the boardroom.
“Well, we got green lights from security and legal. Sam’s team just called to
say they’ve got it all tested and set up.
We should be starting any time now,”
says Andrea.
“The cloud scares me, Andrea. It’s
powerful, convenient, and deadly. Before we realize it, we’ll be relying on it,
without understanding all the risks.
And if that happens, it’ll be our necks.
But it’s been right for us this time
around. Good call.”
Epilogue. Transmogrifica completed the contract ahead of schedule with
generous bonuses for all involved. Centralized computation was a successful
experiment, and Transmogrifica today
specializes in tailoring customer workloads for faster cloud processing. The
150-node cluster server remains unpurchased.
Conclusion
Cloud computing, built with powerful
servers at the center and thin clients at
the edge, is a throwback to the main-frame model of computing. Seduced
by the convenience and efficiency of
such a model, users are turning to the
cloud in increasing numbers. However, this popularity belies a real security
risk, one often poorly understood or
even dismissed by users.
Cloud providers have a strong in-
centive to engineer their systems to
tion keys from the DRAM of the host
or run a malicious hypervisor to do
the same. While the former is a dif-
ficult, if not impossible, problem to
solve, recent advances help allow us-
ers to gain some assurance about the
underlying system.
Trust and Attestation
Consider the following scenario commonly seen in fiction: Two characters
meet for the first time, with one, much
to the surprise of the other, seeming to
act out of character. Later, it becomes
apparent that a substitution has occurred and the character is an imposter. This illustrates a common problem in security, where a user is forced
to take the underlying system at its
word, with no way of guaranteeing it is
what it claims to be. This is particularly important in cloud environments,
as the best security and auditing techniques are worthless if the platform
disables them.
“Trusted boot” is a technology
that allows users to verify the identity
of the underlying platform that was
booted. While ensuring the loaded
virtualization platform is trusted, it
makes no further guarantees about
security; the system could have been
compromised after the boot and still
be verified successfully. Two tech-
niques that provide a trusted boot are
unified extensible firmware interface
(UEFI) and trusted platform module
(TPM). While differing in implemen-
tation, both rely on cryptographic
primitives to establish a root of trust
for the virtualization platform.
UEFI is a replacement for the BIOS
and is the first software to be executed
during the boot process. In a secure
boot, each component of the boot process verifies the identity of the next
one by calculating its digest or hash
and comparing it against an expected
value. The initial component requires
a platform key in the firmware to attest
its identity. TPM differs slightly in its
execution; rather than verify the identity of each component while booting,
a chain with the digest of each component is maintained in the TPM. Verification is deferred for a later time. Clients can verify the entire boot chain of
a virtualization platform, comparing it
against a known-good value, a process
called “remote attestation.”
Trusted-boot techniques give users
a way to gain more concrete guarantees about the virtualization platform
to which they are about to commit
sensitive data. By providing a way to
verify themselves, then allowing users
to proceed only if they are satisfied that
certain criteria are met, they help overcome one of the key concerns in cloud
computing. However, this increased
security comes at a cost; to realize the
full benefit of attestation, the source
code, or at least the binaries, must be
made available to the attestor. While
Figure 3. Multiple independent toolstacks.
User A’s
Toolstack
User B’s
Toolstack
Control VM (Commodity OS)
Xen
Managed By
Qemu
Disk
Controller
Network
Device
Disk
Controller
Network
Device
User B’s VM User A’s VM
Figure 4. Nested virtualization.
Hypervisor (Outer)
VM 1
User A’s
Hypervisor (Inner)
VM 2 VM 3
User B’s
Hypervisor (Inner)