At Thu, 31 Aug 2006 18:37:40 +0200, Christian Stüble <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
