[Top][All Lists]
[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: |
Fri, 01 Sep 2006 00:49:58 +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 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
- Re: Separate trusted computing designs, (continued)
- Re: Separate trusted computing designs, Marcus Brinkmann, 2006/08/17
- Re: Separate trusted computing designs, Christian Stüble, 2006/08/29
- When to Deploy, Neal H. Walfield, 2006/08/30
- Re: Separate trusted computing designs, Marcus Brinkmann, 2006/08/30
- Re: Separate trusted computing designs, Christian Stüble, 2006/08/30
- Re: Separate trusted computing designs, Michal Suchanek, 2006/08/30
- Re: Separate trusted computing designs, Christian Stüble, 2006/08/30
- Re: Separate trusted computing designs, Michal Suchanek, 2006/08/31
- Re: Separate trusted computing designs, Marcus Brinkmann, 2006/08/31
- Re: Separate trusted computing designs, Christian Stüble, 2006/08/31
- Re: Separate trusted computing designs,
Marcus Brinkmann <=
- Re: Separate trusted computing designs, Marcus Brinkmann, 2006/08/31
- Re: Separate trusted computing designs, Christian Stüble, 2006/08/31
- Re: Separate trusted computing designs, Tom Bachmann, 2006/08/31
- Re: Separate trusted computing designs, Marcus Brinkmann, 2006/08/31
- Re: Separate trusted computing designs, Jonathan S. Shapiro, 2006/08/31
- Re: Separate trusted computing designs, Jonathan S. Shapiro, 2006/08/30
- Re: Separate trusted computing designs, Jonathan S. Shapiro, 2006/08/30
- Re: Separate trusted computing designs, Michal Suchanek, 2006/08/30
- Re: Separate trusted computing designs, Jonathan S. Shapiro, 2006/08/30
- Re: Separate trusted computing designs, Marcus Brinkmann, 2006/08/31