Open Stack

Cool, thanks for a great discussion, I've learned some things and
understood some of the assumptions behind TrustedComputingPools
as they are today.

In case anyone is interested an article with more details will be published
in a week or so at icisc.org

Hope the TrustedComputingPools blueprint makes it into Grizzly;


cheers,
/Nico.


On 21 November 2012 02:25, Tian, Kevin <kevin.tian at intel.com> wrote:

>  See you point. Somehow it looks like the user or TTP specifies a cloud
> stack to be deployed by the IaaS provider, and then TTP can measure that
> specific stack.****
>
> ** **
>
> Though I don’t know how important this usage will be, I do agree that
> having the user to check its unique secret is a good complement to the
> whole attestation stack.****
>
> ** **
>
> Thanks****
>
> Kevin****
>
> ** **
>
> *From:* Nicolae Paladi [mailto:n.paladi at gmail.com]
> *Sent:* Wednesday, November 21, 2012 12:41 AM
>
> *To:* Tian, Kevin
> *Cc:* Dugger, Donald D; openstack; Li, Susie; Wei, Gang; Maliszewski,
> Richard L
> *Subject:* Re: [Openstack] Plans for Trusted Computing in OpenStack****
>
>  ** **
>
> Looking a from a IaaS provider's point of view, it is indeed simpler to
> approach the attestation as****
>
> an additional service that would ensure that the host has not been
> corrupted in any way -- the client****
>
> then trusts the IaaS service provider, it's software deployment processes
> and it's people.****
>
> ** **
>
> And I do agree that when a malicious IaaS provider redeploys the stack, it
> can, as you said, insert holes****
>
> at any stack and with the current state of the TPM would be if not
> impossible, then practically very hard to****
>
> identify during an attestation. ****
>
> ** **
>
> However I would like to point out that I am considering the user case when
> it****
>
> is both needed and feasible to make a dedicated deployment for a customer,
> or a set of customers, that require****
>
> such special features. In this case the deployment codebase could first be
> verified and measured. Let's say that would****
>
> be the TTP doing it. Now when this same stack is deployed in production,
> the TTP would just have to ensure****
>
> that he trusted stack has not been changed. That matches very closely what
> is written in the second paragraph:****
>
> "****
>
> This is because IaaS provider builds and trusts its own deployed stack.
>  So the remote attestation service is built to help IaaS provider check
> whether the trusted stack has been changed on the hosts. Here the trust
> criteria is clear;****
>
> "****
>
> the only difference being that the TTP knows and has measured the stack
> prior to deployment.****
>
> ** **
>
> Yes it's not a fully encompassing solution cause hey, the IaaS provider
> could later silently migrate the VM to a different host with****
>
> a leaky hypervisor and all the trust is gone, but there are solutions to
> that as well.****
>
> ** **
>
> The point I earlier made about trusting the IaaS provider, it's codebase
> and the employees fits nicely with what is mentioned in the last****
>
> paragraph -- bugs and negligence can occur as well and this approach aims
> to also prevent from such things.****
>
> ** **
>
> Cheers, ****
>
> /Nico.****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On 16 November 2012 08:35, Tian, Kevin <kevin.tian at intel.com> wrote:****
>
> The assessment criteria is clear, that IaaS provider measures the whole
> cloud stack every time when it creates a new release, and then is compared
> to the run-time measurements on the running stack on the hosts in so-called
> attestation process. A failed attestation implicates the host is untrusted
> because the stack has been changed.****
>
>  ****
>
> This is because IaaS provider builds and trusts its own deployed stack.
>  So the remote attestation service is built to help IaaS provider check
> whether the trusted stack has been changed on the hosts. Here the trust
> criteria is clear;****
>
>  ****
>
> However, an external CA doesn’t build the stack, and I don’t know how CA
> can judge whether a specific cloud stack is trusted or not, even when IaaS
> provider is asked to share. A malicious IaaS provider can provide a evil
> stack with holes on any point. Here the ‘trust’ criteria is not clear.****
>
>  ****
>
> BTW, I do think your proposal might be a good complement to the existing
> remote attestation service from another angle. It’s possible that remote
> attestation framework, or scheduler, or other involved components contains
> bug, which lead to VM running on untrusted host even when the attestation
> fails. In that case, give the VM capability to detect its own secret sounds
> like an acknowledgement to a successful attestation, since a failed
> attestation can never inject the secret. J****
>
>  ****
>
> Thanks****
>
> Kevin****
>
>  ****
>
> *From:* Nicolae Paladi [mailto:n.paladi at gmail.com]
> *Sent:* Thursday, November 15, 2012 12:19 AM
> *To:* Tian, Kevin
> *Cc:* Dugger, Donald D; openstack; Li, Susie; Wei, Gang; Maliszewski,
> Richard L****
>
>
> *Subject:* Re: [Openstack] Plans for Trusted Computing in OpenStack****
>
>  ****
>
> That is correct, the variety of versions, components and patches is the
> first thing****
>
> that comes to everyone's mind with this approach. ****
>
> But the idea is not to have a trusted third party/CA that would be able to
> assess _all_ combinations.****
>
> With both approaches, the 'assessment' is left out as a stub or
> "assumption" (whichever you prefer).****
>
> In this case it doesn't actually matter who does the assessment - the IaaS
> provider or a CA,****
>
> since the assessment criteria are the unsolved issue.****
>
>  ****
>
> The use case we're examining here is when a certain IaaS provider is
> contracted to supply****
>
> IaaS to a client with "special requirements", let's call it C. That would
> mean, e.g:****
>
> 1. Potentially not all hosts would be used to deploy VMs for C****
>
> 2. Potentially patches and versioning might go through a separate upgrade
> flow for those hosts****
>
>  ****
>
> To summarize and address your concerns here:****
>
> * imo once a client  is concerned enough to require "trusted hosts", the
> use of using external assessment case becomes valid****
>
> (and assessment by the IaaS provider becomes useless)****
>
> * wrt to variation of the software stack, the big issue is the assessment
> criteria rather than the assessing party.****
>
>  ****
>
>  ****
>
> Cheers, ****
>
> /Nico.****
>
>  ****
>
>  ****
>
> On 14 November 2012 04:27, Tian, Kevin <kevin.tian at intel.com> wrote:****
>
> I would see the major blocking issue on this:****
>
>  ****
>
> “However, imo an IaaS provider that claims to offer trusted hosts but
> hesitates to reveal the software stack of it's hosts to an external auditor
> (CA in this case) would have issues with credibility”****
>
>  ****
>
> every IaaS provide has its own software stack, picking different
> components, with different versions, possibly adding different patches. The
> stack can be changed frequently. Rackspace says they can publish a build in
> less than 1hrs to deploy a new stack. Having an external CA to hold
> credentials for such large uncertain combos is almost a mission impossible.
> J****
>
>  ****
>
> Thanks****
>
> Kevin****
>
>  ****
>
>  ****
>
> *From:* Nicolae Paladi [mailto:n.paladi at gmail.com]
> *Sent:* Tuesday, November 13, 2012 11:46 PM
> *To:* Dugger, Donald D
> *Cc:* openstack; Tian, Kevin; Li, Susie; Wei, Gang; Maliszewski, Richard L
> ****
>
>
> *Subject:* Re: [Openstack] Plans for Trusted Computing in OpenStack****
>
>  ****
>
> Hi, ****
>
>  ****
>
> I agree that the use case of a trusted IaaS provider (with possibly
> compromised nodes) is a valid one and should have support in the openstack
> codebase, although it seems rather dicey to trust the IaaS provider which
> does not trust it's own hosts.****
>
> And your understanding is correct, the idea is to add a 3rd party 'CA'
> with the aim to assess the integrity of the hosts based on the data
> produced by the TPM.****
>
>  ****
>
> What I am advocating here is the scenario where the IaaS can not be
> trusted.  ****
>
> In this case the CA would only gain information about the software stack
> of the IaaS provider's hosts, necessary to perform the attestation.
> However, imo an IaaS provider that claims to offer trusted hosts but
> hesitates to reveal the software stack of it's hosts to an external auditor
> (CA in this case) would have issues with credibility.****
>
>  ****
>
> Wrt complexity, this would require:****
>
>  ****
>
> * sending the attestation information externally to the 'CA' and taking a
> launch/not launch decision based on the result of the attestation. Even if
> the untrusted IaaS launches the VM, the client can easily detect the fraud.
> ****
>
>  ****
>
> * on the compute host, decrypting the nonce provided by the client (and
> _sealed_ by the CA to the trusted configuration of the host). That will add
> up to the codebase but is rather trivial (involves mostly interacting with
> the TPM).****
>
>  ****
>
> Now, there are some design choices to be made, e.g. whether the host
> communicates its attestation credentials directly to the CA in an https
> session or the scheduler does that. However, it does not change the
> important point that the client can verify that the VM was started on a
> trusted host, without having to rely on the IaaS provider.****
>
>  ****
>
> A common topic to both models (trusted or untrusted IaaS provider) is the
> question of "security profiles" for the hosts -- are you considering binary
> values (trusted/untrusted) or some finer-grained scale?****
>
>  ****
>
> Happy to hear your opinions and continue the discussion;****
>
>  ****
>
> cheers, ****
>
> /Nico.****
>
>  ****
>
>  ****
>
> On 12 November 2012 21:23, Dugger, Donald D <donald.d.dugger at intel.com>
> wrote:****
>
> Nicolae-****
>
>  ****
>
> We’ve been working under the assumption you have trust the IaaS provider
> (individual nodes might have been compromised somehow but you trust the
> provider itself).  I think what you are looking at is adding a 3rd party
> CA which is significantly increasing the complexity of the solution and
> potentially exposing the IaaS’s infrastructure to a 3rd party, probably
> not desirable to the IaaS provider.****
>
>  ****
>
> I’ve added some others to the thread who can chime in with their opinions.
> ****
>
>  ****
>
> --****
>
> Don Dugger****
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale****
>
> Ph: 303/443-3786****
>
>  ****
>
> *From:* Nicolae Paladi [mailto:n.paladi at gmail.com]
> *Sent:* Wednesday, November 07, 2012 7:42 AM
> *To:* Dugger, Donald D
> *Cc:* openstack
> *Subject:* Re: [Openstack] Plans for Trusted Computing in OpenStack****
>
>  ****
>
> Hi, ****
>
>  ****
>
> so basically my questions/thoughts about support for TC in OpenStack are
> based on a****
>
> somewhat different attack model where the IaaS is actually not trusted.***
> *
>
>  ****
>
> That is in contrast with the Trusted Compute Pools, where the
> scheduler/trusted_filter****
>
> is assumed to reject the host as a candidate for running the VM if it does
> not have a ****
>
> corresponding "trust value". However, nothing prevents a really evil IaaS
> deployment****
>
> to ignore this trust value and go ahead, launch the VM and return it to
> the client. So****
>
> there's an improvement suggestion focusing on that part.****
>
>  ****
>
> The model that I have in mind assumes both no trust in the IaaS
> setup/provider.****
>
>  ****
>
> So the gist is that:****
>
>  ****
>
> 1. Client could upload a secret encrypted with the public key of the
> authentication service ****
>
> (possible to include in the extra_specs)****
>
>  ****
>
> 2. The Attestation Service, after verifying the compute host could bind
> the secret to the****
>
> hosts trusted configuration, so that the host can inject the secret into
> the VM****
>
>  ****
>
> With this approach, a malicious IaaS provider can still launch the VM on
> an untrusted host, but****
>
> now he client can verify that the VM has been started on a 'trusted' host.
> ****
>
>  ****
>
> So the questions around this are -- ****
>
> 1. Is the scenario of an untrusted IaaS deployment considered for Trusted
> Compute Pools?****
>
>  ****
>
> 2. Is there any work ongoing to extend Trusted Compute Polls for storage
> as well? Or otherwise****
>
> put, what about the storage, is the solution to encrypt all data on the
> compute host prior to****
>
> storing it in the object store?****
>
>  ****
>
> 3. Is there any work ongoing on the evaluation side, namely the evaluation
> of the trust attributes****
>
> obtained from the host -- and do Trusted Compute Pools consider a binary
> value (trusted/untrusted)****
>
> or a scale of security profiles?****
>
>  ****
>
> Cheers, ****
>
> /Nico.****
>
>  ****
>
>  ****
>
> On 6 November 2012 19:07, Dugger, Donald D <donald.d.dugger at intel.com>
> wrote:****
>
> Nico-****
>
>  ****
>
> This is the appropriate place for discussions about Trusted Compute Pools
> under OpenStack.  Feel free to send out any ideas you have, I know I and
> others would be very interested in what you have.****
>
>  ****
>
> --****
>
> Don Dugger****
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale****
>
> Ph: 303/443-3786****
>
>  ****
>
> *From:* openstack-bounces+donald.d.dugger=intel.com at lists.launchpad.net[mailto:
> openstack-bounces+donald.d.dugger=intel.com at lists.launchpad.net] *On
> Behalf Of *Nicolae Paladi
> *Sent:* Tuesday, November 06, 2012 8:35 AM
> *To:* openstack
> *Subject:* [Openstack] Plans for Trusted Computing in OpenStack****
>
>  ****
>
> Hi, ****
>
>  ****
>
> I am involved in a project that aims to use TPM modules to ensure that****
>
> the compute nodes run a 'trusted' software stack in a public IaaS
> deployment.****
>
>  ****
>
> I've read about trusted computing pools (
> http://wiki.openstack.org/TrustedComputingPools)****
>
> checked out the OpenAttestation project and seen a presentation from the
> OpenStack****
>
> summit (Putting Trust in OpenStack<http://www.openstack.org/summit/san-diego-2012/openstack-summit-sessions/presentation/putting-trust-in-openstack>)
> in order to get a better understading of where****
>
> OpenStack is heading towards wrt TPM support.****
>
>  ****
>
> Are there any more resources, discussions, mailing lists that I could
> check out and****
>
> where I could potentially bounce ideas?****
>
>  ****
>
> Cheers, ****
>
> /Nico.****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121121/245cb4ed/attachment.html>