October 31, 2012 | Written by: Jonathan Barney
Share this post:
My last post on encryption and key management in the cloud generated some interesting comments. I am still polishing a follow up to address the questions around encryption gateways and application level encryption in the cloud. In the meantime I have been working on some trusted computing projects and decided to pen those thoughts down. I hope to tie all the discussions together in a later post.
Looking at the evolution of computer architecture, computer security has essentially been an afterthought. Traditionally, computer security has been established after system booting is largely complete. The infrastructure surrounding and supporting systems has had minimal or unclear security properties. A dependable “witness” to a system’s security is needed for an outside party to decide if it trusts that system. Additionally, starting at power on reset, systems must establish a trusted computing base in order to allow hypervisors and operating systems to boot into trusted states with the confidence that undetectable bootkits and rootkits are not present. Prior to trusted computing, no objective, incorruptible witness to a system’s security has been available. There has been no trusted computing base so there has been no method to protect secrets from exposure to a system that has booted into a questionable security state. In short, trusted computing addresses the fundamental security shortcomings which are present in the majority of computer architectures today.
To accomplish the goal of measuring a systems code with an incorruptible third party and establishing a trusted computing base, the firmware and systems management code in a platform that run prior to booting a hypervisor or operating system must also be measured and placed in a secure, trusted state. Prior to trusted computing, these platform hardware and platform firmware entities were implicitly trusted and were not required to offer proof that they were in a trusted state.
One of the key tools used in trusted computing is the TPM. The TPM primarily provides the following functionality:
- The TPM provides platform configuration registers (PCRs) which the TPM uses to store program measurements built from hash extend commands. These measurements when combined with a digest of what has been measured can be used to determine the programmatic state of a system. System firmware and software uses the TPM PCRs to record the program state of a computer.
- The TPM provides a key hierarchy that can be used for attestation of a computers state, sealing of secrets to PCRs, signing, protection of private keys, etc.
When the TPM is combined with trusted computing software (roots of trust for measurement, attestation agents) complete trusted computing solutions which establish trust and security starting a system reset are achieved.
Why is this interesting in the cloud? It comes back to trust. If we are moving data to the cloud, we want to be able to do more than just trust the cloud provider. A trusted cloud would give customers a way to attest meaningful information around the hardware they are deploying their applications on. Of course there are some problems with this.
How do you attest the state of a virtual machine? Why through a virtual TPM that exists in the hypervisor. Well, how do you trust a vTPM? As a cloud service provider do you want customers attesting not only their vTPM, but also the state of the physical TPM? How do you give them access that deep in the stack and preserve the security and integrity of the system?
Ideally a customer could attest both the vTPM and the pTPM and know with confidence that they are running on hardware in a good, known state. They may also be able to tell that they are running on hardware that they have paid and contracted for, they may also be able to validate the location of the hardware and many other interesting things from a security perspective.
A Trusted Cloud would be a great place to start for customers who desire a known state of the hardware stack for something like regulated workloads. From a cloud provider perspective, what happens when the hardware comes up in an attested state that deviates from a known good state? It could certainly cause bad goodwill for the CSP to have a customer find compromised hardware before the CSP.
I believe trusted computing and trusted clouds will be a boon to security conscious cloud adopters.