l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Separate trusted computing designs


From: Marcus Brinkmann
Subject: Re: Separate trusted computing designs
Date: Thu, 31 Aug 2006 16:31:25 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 31 Aug 2006 02:26:44 +0200,
Christian Stüble <address@hidden> wrote:
> > b) I want to buy a service, and the provider requests that it runs on
> > certain hardware/OS/PC color/whatever. Today I have the choice to
> > access the service in any way I want. TPM would forbid it.
> I do not see where I confuse cases. I was not talking about attestation
> like in case a). My "Privacy Agent" is case b), but in this case I am the 
> provider and I request that the underying OS provides strong isolation
> such that the platform owner (nor any other user) can access the state of my 
> agent. Today I have the only choice to give my personal data not to another 
> party, or to trust it. TPM allows to enforce certain properties. Yes. And in 
> my use case, this is what I want.

You still rely on ("trust") the TPM provider.  There is no change in
that regard, you still "trust" somebody, it's just a different party.

I realize that there is a practical difference, but the difference is
only that the party which potentially is in control of the key is a
separate party from the one using it.  This means that you now have
two parties to worry about instead of one.

It is not clear to me that this is better: The concentration of power
and the single point of failure that constitutes the TPM manufacturer
is a grave security threat as well.

In the "hosted server as virtual machine" example, I don't think it
makes much sense.  If your operations are so critical that you require
a high demand of privacy, you will inevitably consider any
implementation running on a virtual machine on a colocation a grave
risk.  Thus, you will better spend the money on a real machine, which
is owned exclusively by you, and you will probably host it in your own
data center.  This is more expensive, but we are talking about very
sensitive data, so you will probably do the calculation on a
worst-case-scenario, and decide that it is too risky to colocate it
even on XenTC++ running on Coyotos 2010 complete with mathematical
correctness proof.  Try to convince your upper management that this is
a safer choice than running the darn thing yourself!

Now, let's say your operation is not that critical, and you are
running your service on a colocated machine together with 10 other
customers.  Now, a bug or missing feature is detected in the operating
system, and it needs to be upgraded.  You really think it is
cost-effective for the service provider to get the upgrade certified
by 10 other customers with equally sensitive data?  I don't buy this
whole scenario.  They would be much better off buying 10 machines, and
not having to worry about it anymore.  This is after all why service
providers use virtual machines in the first place: Because they can
stop worry about the operating system, and leave it to their
customers.  Make them worry about the operating system again, and it
is back to individual hardware machines.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]