Archive

Trusted computing and clouds

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:

  1. 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.
  2. 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.

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Archive Stories

Why we added new map tools to Netcool

I had the opportunity to visit a number of telecommunications clients using IBM Netcool over the last year. We frequently discussed the benefits of have a geographically mapped view of topology. Not just because it was nice “eye candy” in the Network Operations Center (NOC), but because it gives an important geographically-based view of network […]

Continue reading

How to streamline continuous delivery through better auditing

IT managers, does this sound familiar? Just when everything is running smoothly, you encounter the release management process in place for upgrading business applications in the production environment. You get an error notification in one of the workflows running the release management process. It can be especially frustrating when the error is coming from the […]

Continue reading

Want to see the latest from WebSphere Liberty? Join our webcast

We just released the latest release of WebSphere Liberty, 16.0.0.4. It includes many new enhancements to its security, database management and overall performance. Interested in what’s new? Join our webcast on January 11, 2017. Why? Read on. I used to take time to reflect on the year behind me as the calendar year closed out, […]

Continue reading