More On High Assurance (via TPM) Cloud Environments
- Image via Wikipedia
Back in September 2009 after presenting at the Intel Virtualization (and Cloud) Security Summit and urging Intel to lead by example by pushing the adoption and use of TPM in virtualization and cloud environments, I blogged a simple question (here) as to the following:
Does anyone know of any Public Cloud Provider (or Private for that matter) that utilizes Intel’s TXT?
Interestingly the replies were few; mostly they were along the lines of “we’re considering it,” “…it’s on our long radar,” or “…we’re unclear if there’s a valid (read: economically viable) use case.”
At this year’s RSA Security Conference, however, EMC/RSA, Intel and VMware made an announcement regarding a PoC of their “Trusted Cloud Infrastructure,” describing efforts to utilize technology across the three vendors’ portfolios to make use of the TPM:
The foundation for the new computing infrastructure is a hardware root of trust derived from Intel Trusted Execution Technology (TXT), which authenticates every step of the boot sequence, from verifying hardware configurations and initialising the BIOS to launching the hypervisor, the companies said.
Once launched, the VMware virtualisation environment collects data from both the hardware and virtual layers and feeds a continuous, raw data stream to the RSA enVision Security Information and Event Management platform. The RSA enVision is engineered to analyse events coming through the virtualisation layer to identify incidents and conditions affecting security and compliance.
The information is then contextualised within the Archer SmartSuite Framework, which is designed to present a unified, policy-based assessment of the organisation’s security and compliance posture through a central dashboard, RSA said.
It should be noted that in order to take advantage of said solution, the following components are required: a future release of RSA’s Archer GRC console, the upcoming Intel Westmere CPU and a soon-to-be-released version of VMware’s vSphere. In other words, this isn’t available today and will require upgrades up and down the stack.
Sam Johnston today pointed me toward an announcement from Enomaly referencing the “High Assurance Edition” of ECP which laid claims of assurance using the TPM beyond the boundary of the VMM to include the guest OS and their management system:
Enomaly’s Trusted Cloud platform provides continuous security assurance by means of unique, hardware-assisted mechanisms. Enomaly ECP High Assurance Edition provides both initial and ongoing Full-Stack Integrity Verification to enable customers to receive cryptographic proof of the correct and secure operation of the cloud platform prior to running any application on the cloud.
- Full-Stack Integrity Verification provides the customer with hardware-verified proof that the cloud stack (encompassing server hardware, hypervisor, guest OS, and even ECP itself) is intact and has not been tampered with. Specifically, the customer obtains cryptographically verifiable proof that the hardware, hypervisor, etc. are identical to reference versions that have been certified and approved in advance. The customer can therefore be assured, for example, that:
- The hardware has not been modified to duplicate data to some storage medium of which the application is not aware
- No unauthorized backdoors have been inserted into the cloud managment system
- The hypervisor has not been modified (e.g. to copy memory state)
- No hostile kernel modules have been injected into the guest OS
This capability therefore enables customers to deploy applications to public clouds with confidence that the confidentiality and integrity of their data will not be compromised.
Of particular interest was Enomaly’s enticement of service providers with the following claim:
…with Enomaly’s patented security functionality, can deliver a highly secure Cloud Computing service – commanding a higher price point than commodity public cloud providers.
I’m looking forward to exploring more regarding these two example solutions as they see the light of day (and how long this will take given the need for platform-specific upgrades up and down the stack) as well as whether or not customers are actually willing to pay — and providers can command — a higher price point for what these components may offer. You can bet certain government agencies are interested.
There are potentially numerous benefits with the use of this technology including security, compliance, assurance, audit and attestation capabilities (I hope also to incorporate more of what this might mean into the CloudAudit/A6 effort) but I’m very interested as to the implications on (change) management and policy, especially across heterogeneous environments and the extension and use of TPM’s across mobile platforms.
Of course, researchers are interested in these things too…see Rutkowska, et. al and “Attacking Intel Trusted Execution Technology” as an example.
/Hoff
Related articles by Zemanta
- Quick Question: Any Public Cloud Providers Using Intel TXT? (rationalsurvivability.com)
- EMC, Intel, VMware team to secure private clouds (sfgate.com)
- EMC, Intel, VMware team up on cloud computing security (newstatesman.com)
- RSA extends security tools to VMware (infoworld.com)
- Cloud Computing Security: What The Big Guns Have In Store (readwriteweb.com)
- Intel Launches Its Most Secure Data Center Processor (eon.businesswire.com)
- Enomaly ECP 3.1.0 Service Provider Edition Released (elasticvapor.com)
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png)
I've been studying TPM for a while since it caught my eye on the What's New with vSphere list (http://www.vmware.com/support/vsphere4/doc/vsp_40_new_feat.html) under Security, supposedly it's already a feature in vSphere. I actually bought a TPM chip for an HP server to use but VMware has zero documentation on how to use it with vSphere. According to someone I asked at VMware only ESXi supports it and it is enabled with an advanced setting that enables the use of tboot. It does require a TPM chip that supports Intel's TXT or AMD's SEM technology. Supposedly an API exists to monitor the TPM PCR's but it is not public yet. If TXT was successful, the vmkernel fingerprint is reported in PCR19 otherwise, if the host has TPM but TXT was not used, it will show in PCR8, otherwise PCRs should be NULL. VMware also stated that there might not be any production server platforms out there ‘today’ which can support TXT. I've tried getting answers out of AMD & Intel on what chipsets support this but have not gotten a good answer. TPM looks like a good security feature but it looks like it's not ready to be used with VMware yet despite their marketing it as a feature in vSphere as there is no way to monitor it.
To your points about vSphere readiness, I believe this is why it was discussed that 4.1 would be required for true utility. I will have more details shortly.
/Hoff
Hi Eric, Hoff,
TPM is supported in ESX 4.0, but only through Static Root of Trust Measurement (SRTM). The PCR values can be retrieved through the public vSphere APIs. Look for Data Object HostTpmDigestInfo. The measurement values will be stored in PCR8. ESX 4.1 will support tboot, but as noted, there are currently no production servers that can use TXT or tboot.
Wade
Thanks for the information regarding vSphere, Wade.
When you said "there are currently no production servers that can use TXT or tboot" were you referring to the comment I made re: needing the Westmere chipset?
I'm interested in how Enomaly pulls this off…or if they're referring to the same futures.
/Hoff
Hoff, thanks for the post. I'd be happy to give a deep dive into how we've developed Enomaly High Assurance Editions (HAE) in partnership with Intel.
Generally, to securely establish the integrity of the remote platform Enomaly’s HAE system uses Intel’s TXT processor extensions along with a Trusted Computing Group (TCG) Trusted Platform Module (TPM). Enomaly HAE also uses a mechanism called remote attestation, which until now has only been explored [mostly] in experimental research settings. Thanks in part to the work of our lead security architect, Dr David Lie, we've taken the bold step of making attestation practical by integrating it into the ECP system targeting IaaS hosting providers. HAE takes care of all the complexity of making the attestation requests, ensuring that the requests cannot be tampered with and distilling the result of the attestation requests into a simple and easy to understand safe / not safe message. This can also be integrated into existing monitoring and business processes to ensure only truly secure remote cloud environments are being utilized.
@beaker
Yes, ESX 4.1 support of TXT is dependent on release of the Westmere chipset.
I posted some more details of Enomaly HAE on my ElasticVapor blog > http://tiny.cc/ECPHAE
A system that securely boots insecure software is still an insecure system.
Still awaiting information from Enomaly on what measures they take to prevent XSRF attacks against their API and web interface.
Sam
@Reuven Cohen, Enomaly Founder & CTO
Reuven, can you comment on the availability and dependencies for deployment of ECPHAE? Specifically, do I need Westmere like VMW does as Wade references above?
/Hoff
Hoff, are you questioning whether ECPHAE is vapor at this point because of Wade's comment that there are no production servers that support Intel TXT?
Presumably they tested it on something with a an Intel CPU, a TPM and TXT support on they wouldn't be claiming it was "available immediately". TXT is supported in varying degrees of useful in a variety of Intel chipsets and configurations- has been since vPro.
I have no trouble taking Reuven's statements at face value, although how significant the news is up for debate.
@carl
No, you're missing my point.
Quite simply, whilst the ECPHAE *software* may be "available immediately" it doesn't mean that the hardware to support it is — specifically, Enomaly participates in the Intel Developer program, they could have tested or coded against pre-release chipsets or in advance of chipset availability to enable said functionality.
My questions aren't aimed at VMW vs. Enomaly…they *are* however targeted specifically at that which you said when you mentioned "TXT is supported in varying degrees of useful in a variety of Intel chipsets and configurations- has been since vPro." << so which "degrees of useful[ness]" do we get with current chipsets in conjunction with ECPHAE?
However, the announcement you reference in your article was made by EMC/RSA, VMware and, wait-for-it, *INTEL* You said that Enomaly beat EMC/RSA/VMW to the punch in the delivery of this solution which seems pretty darned odd considering what I just mentioned, no?
Again, I'm uninterested in who-beats-who-to-what but rather what the dependencies are in order to exploit this functionality — you'll notice I made it a point to get to the bottom of it re: the VMW/EMC/RSA announcement. All I'm trying to do is the same for the Enomaly one since I wrote this blog about both of these offerings in advance of your article.
Hope this clears things up.
When @ruv gets back from China, I'm sure he'll comment for clarity.
/Hoff
I agree, very good questions, which Reuven apparently promises to clear up. I also share your curiosity over exactly what this implementation does.
If its consumer-grade TPM that says, "hurr dis computah is running da OK OS on da OK hard drive", that's inevitably going to lead to questions of its greater utility. What's the point of a cloud platform that tells me its really truly honestly running Xen when I ask it, if I can randomly throw any old image from anywhere on there? and so on…
There is no doubt that Xen supports tboot on plenty of vPro chipsets in lots of different servers. I can see that part of ECPHAE as absolutely possible.
If Enomaly said "we can do what VMware and Intel promised down the road right now" I would be more startled. But if it's saying, 'We're already down the road with this while Vmware is noodling around with EMC, even if it's not the bees knees', then I'm OK with it.
The RSA intelVMware fest was clearly a little deeper than just verifying a server is running a hypervisor, which is all tboot would get you; there was talk of trusted chain through the whole stack- it was also clearly a goal in progress.
Also, RE VMWare/Enomaly, According to Intel, Enomaly now supports some flavors of ESX. Don't know the details, but that's some of my confusion right there- I thought Rueven was says he could do something with it VMWare could not, which, again, would be startling. He tweeted that its Xen-only, which answers that question.
Otherwise, I eagerly await the full disclosure of what TXT functions are supported, where the trust chain starts and ends, and what chipsets and servers this works on; I'll run out and buy 12. You hear me Dell?? 12! maybe 15, even 🙂
So with the release of new servers using the Intel x56xx series processors and vSphere 4.1 on the streets, what's the status of TXT in the real world? My new HP laptop supports TXT, but how about X56xx based servers with a TPM? Yes I can use the TPM with vSphere v4.1 and enable the tboot flag, but what's that really doing for me? How can I know if my server is really doing TXT?
VMware, Intel, and RSA presented on this topic with a working demo this year at VMworld. Session SE9600. From the looks of it, it is still a way from wide spread use in the operational environment. Their use case was ensuring a VM was executing in a correct geo-location as derived from NIST 800-53 SC-7.
My question now that we have a functional and trusted infrastructure, even from a demo prospective, how long until the platform layer takes advantage of the provided trust? The software layer? I will bet money that VMware will incorporate some future functionality in their vFabric product.