openstack team mailing list archive

[Nicolae Paladi <n.paladi@xxxxxxxxx>]

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@xxxxxxxxx>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@xxxxxxxxx]
> *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@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx[mailto:
> openstack-bounces+donald.d.dugger=intel.com@xxxxxxxxxxxxxxxxxxx] *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.****
>
> ** **
>