Communications of the ACM

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