Re: Separate trusted computing designs

[Marcus Brinkmann]

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.
 
> > 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.
 
> > 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.

Thanks,
Marcus