Re: Separate trusted computing designs

[Christian Stüble]

Am Donnerstag, 31. August 2006 16:31 schrieb Marcus Brinkmann:
> 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.
Of course. This is a basic assumption of the TCG. When I buy a PC, I have the 
chance to decide which TPM has to be inside. Without such a free choice,
the TPM is useless from a security standpoint.

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

> 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.
This is true. But the same holds for a security kernel. If you can reduce
the security of a complex thing to a smaller one, the complexity of the
TCB decreases. But in parallel, a weakness in the TCB becomes more critical.
That is IMO a more dangerous problem than all the discussion about DRM and 
TPM.

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

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

> 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.
This is the main motivation behind teh OTC project. They do worry about the
VMM.

Regards,
Chris