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: Bas Wijnen
Subject: Re: Confinement (even with TPMs) and DRM are not mutually exclusive
Date: Thu, 8 Jun 2006 15:29:10 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Wed, Jun 07, 2006 at 04:01:03PM -0400, Jonathan S. Shapiro wrote:
> > > Similarly, a server cannot tell if the user is actually logged in at a
> > > terminal at all -- it can only tell that it has received input from a
> > > connection that appears to constitute an authentication sequence.
> > 
> > The assumption is that only the user can authenticate.  If this assumption
> > is not true, then there is something wrong with the authentication
> > mechanism, which should be fixed.
> 
> Nonsense. The assumption is universally false. The computer *never*
> knows whether the user has authenticated. What the computer knows is
> that characters have been sent from a device. The assumption that these
> characters originated from a user is just that -- an assumption. This is
> not a question of bugs. It is a consequence of the absence of an
> end-to-end trusted path.

What I'm saying is that if you design an authentication mechanism and it gives
false positives (that is, people can pass the mechanism even though they
aren't the right person), then it's broken.  I agree with you that
authentication mechanisms which are not even a little bit broken are
impossible.  However, I think there should be mechanisms which are good
enough.  For software purposes, it is absolutely needed to have an
authentication mechanism, so even if it wasn't good enough, we'd still have to
use it.  But I think it's, as you say it, good enough in practice that we can
get useful work done.

> > > Your original statement was that the system could trust the terminal. In
> > > many circumstances this is "true enough" in practice that we can get
> > > useful work done, but it definitely is NOT true if we are dealing with
> > > anything sensitive.
> > 
> > Well, it depends on what machines we're talking about.  For desktop
> > computers, which are inside the home of the owner, it is very reasonable
> > to let the owner be responsible for the hardware security (that is, that
> > no hardware sniffers are installed).
> 
> If you believe this, you have not been reading the US newspapers.

Indeed I have not.  They are hard to come by here in the Netherlands and for
what I've heard of them I'm not missing a lot. ;-)

> It is quite amazing how many keyboard sniffers are getting installed
> (amazing and, I might add, depressing).

You mean hardware sniffers?  I thought that was usually done in software.
Anyway, I didn't expect it to happen in home situations (except remotely, by
trojans, but that's definitely in software).

Well, I suppose there's work to do in the hardware field to prevent those
things then.

> > > In particular, it is not true for credit transactions.
> > 
> > You mean money machines?  No, in that case the terminal design is very
> > hard, I can imagine.  However, as I said, that's not a software problem.
> > :-)
> 
> No, I simply meant credit transactions on the web from a home computer.

Ah.  Well, it's not a software problem there either (ok, at the moment it is,
but we're solving that).

> Yes. ATM terminals are hard to design well. Banks accept a very high
> rate of loss per ATM as a cost of doing business. Sadly, this rate of
> loss remains lower than the cost of paying humans to work at the bank.

So all do your bit for society and break those machines to increase their
costs. :-)

(Since there're US people reading this: The above is not meant seriously.)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

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