l4-hurd
[Top][All Lists]
Advanced

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

Re: Confinement (even with TPMs) and DRM are not mutually exclusive


From: Jonathan S. Shapiro
Subject: Re: Confinement (even with TPMs) and DRM are not mutually exclusive
Date: Wed, 07 Jun 2006 01:27:52 -0400

On Tue, 2006-06-06 at 23:13 +0200, Bas Wijnen wrote:
> On Tue, Jun 06, 2006 at 11:13:55AM -0400, Eric Northup wrote:
> > I have been very concerned to see the discussions leaning towards
> > abandoning the security benefits associated with the design patterns
> > from KeyKOS and its descendants.
> 
> The security you speak of, as far as I understand (but I agree with Marcus
> it's better to be specific, so I will be) is the security of programs against
> users owning them (where owning means the program received all its
> capabilities and the initial code image from that user).  This will never
> work.

Bas:

>From a purely technical perspective, this statement appears (to me) to
be wrong. It is very clearly possible to technically achieve DRM. Not in
an absolute sense, but in the sense that the cost to break it is too
high to be practical. This is the only sense in which *anything* is
*ever* secure, and it is a sufficient basis for commerce.

If you perceive a technical reason why what you say is true, I would be
interested to know it.

> The sole reason this program exists is the user.  It shouldn't have
> protection against her.

This is an example of "post hoc, propter hoc" reasoning. You are
reasoning backwards from conclusions. The conclusion (a value judgment)
is that "the sole reason the program exists is the user". This
conclusion is highly questionable.

If you would qualify this by saying "In the architectural/design
philosophy of the Hurd, the sole reason that a program exists is to
server its user" then I have no objection to the statement. I simply
want it to be clear that this is a declaration of philosophy with
technical implications, and should not be confused with a statement of
technical fact or feasibility.


> So the user knows if the device is "direct".  The program doesn't need to
> know.

Um. No. Anybody who has looked at the trusted path issues in electronic
voting can explain at great length that it is *extremely* difficult for
either the user or the computer to know this, and that all currently
feasible mechanisms for this rely on some form of very carefully
implemented DRM that permits end-to-end authentication of a closed
device at the user end.

What you assume here certainly isn't as simple as you make it, and is
actually false in the absence of extremely careful design (that does not
exist in *any* current commodity product).


> >       -Some devices may offer limited guarantees of exclusivity.  For
> >        example, that while printing a contract, no other program can
> >        insert the word "not".
> 
> I'd say that invoking a capability to a printer should send a whole document,
> not only a part.  No need for exclusivity in that case.

What you describe is technically referred to as "exclusivity".




shap





reply via email to

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