l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Part 1: Ownership and Contracts


From: Jonathan S. Shapiro
Subject: Re: Part 1: Ownership and Contracts
Date: Mon, 08 May 2006 14:15:44 -0400

On Fri, 2006-05-05 at 15:26 -0700, Michal Suchanek wrote:

> I do not think that this is very hypothetical. The manufacturer of the
> TPM chips is in a position where their components cannot be verified
> (because their function requires that) yet the chips are the central
> part that guarantees the security and reliability of a DRM system (or
> any system using the TPM chip).

Actually, this is not the case.

The functionality of the chips definitely *can* be verified, and this
presents no security hazard. There is an intellectual property hazard to
the manufacturer, but this issue can be managed through contracts and so
forth.

There are a small number of pieces that cannot be verified:

  1. The bits of the manufacturer's master origin key cannot
     be directly examined. However, it is possible to imagine
     circumstances in which the examiner would write a program
     that gives a yes/no answer, and this program could be
     given access to the bits of the master key.

  2. The quality of the random number generator cannot be
     easily verified. This is actually much simpler, since
     we have pretty robust sources of random noise in the world.

Stipulating that these two things cannot be verified, it isn't really
important. The question is not "can these things be verified?" The
question is "Can information vendors establish sufficient confidence in
these things that they are willing to rely on the chip vendors to supply
the underpinnings of their economy?"

When the question is framed this way, it becomes very easy to see that
this question can be turned into an economics question concerning
"acceptable risk". It is not actually necessary for the chip to be
verified to this level of confidence.

shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]