Re: Separate trusted computing designs

[Christian Stüble]

Am Freitag, 1. September 2006 00:49 schrieben Sie:
> At Thu, 31 Aug 2006 18:37:40 +0200,
>
> Christian Stüble <address@hidden> wrote:
> > Am Donnerstag, 31. August 2006 16:31 schrieb Marcus Brinkmann:
> > > 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.
> >
> > Here we have to exactly define the meaning of "control". In the context
> > of TCG, there are a lot of misunderstandings becuase of this.
> >
> > If "in control of the key" means to control who is allowed to use the
> > keys, then the answer is the TPM owner and thus my at my laptop.
> >
> > If "in control of the key" means (according to your ownership definition)
> > access to every bit, the answer is nobody.
>
> Which poses serious questions about liability.
>
> > According to the basic TPM spec,
> > only the TPM itself has access to the key bits. Not the user, not the
> > owner, and not the TPM vendor. Maintenance and CMK makes this a little
> > bit more complicated, but basically the answer is the same.
>
> But you don't know that the vendor does not keep a copy, you only have
> their word for it.
First, this problem is solved by the assumption that you trust the
TPM vendor (and maybe the evaluators). If you trust the remote party
more than the TPM vendor, you do not need a TPM.

Second, the TPM vendor cannot keep a copy, since you can generate
the key locally (you lose the vendor certificate, but that can be solved by
a local PKI or so). Thus the TPM vendor can only apply a backdoor such
that it can read out the key. 

> > > 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!
> >
> > Sorry I am a little confused. Are you talking about the Privacy Agent use
> > case, or another one?
>
> I think I am talking about the privacy agent use case.
But then the problem is different. Lets say your privacy agent calculates
a result y := f( p, s ) on your secret input p and the servie provider's 
secret input s. If both parties do not trust each other, they need a TTP
to calculate the result. This is expensive and inefficient. Alternatively,
they can use a TTP within their system, with all the consequences discusses
above.

Using a dedicated machine does not solve the problem. It remains the question
who should control that machine, and whether it has installed an appropriate
OS. 

>
> > > 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?
> >
> > In practice, one would sign a contract with the service provider about
> > the properties provided by the OS then it can update the OS whenever
> > neccessary.
>
> Well, you just increased the cost of deploying such a solution by an
> order of magnitude (or two) by dragging the legal departments on *both
> sides* into the decision process.  I am pretty bad at economics, but
> even the little I know lets me predict instant death to such a
> solution.  It doesn't sound very competitive to me.
This is, what is actually done in the large computing centers of IBM, HP, etc.
And it seems to be a good business model, else they would not focus on
virtualization. You can still have a dedicated machine for high-security 
applications, but this is more expensive than a virtual machine. But 
currently, the customers have to trust the service provider...

Regards,
Chris
>
> Thanks,
> Marcus