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

[Bas Wijnen]

On Wed, Jun 07, 2006 at 01:29:37PM -0400, Jonathan S. Shapiro wrote:
> > This surprises me.  If the system holds a capability to the keyboard, and
> > passes it to one user session at a time, revoking it again at logout, why
> > is it hard to keep track of it?
> 
> The problem is that the system never held a capability to the keyboard.
> What it held was a capability to the PS/2 (or USB) keyboard port. It has
> no idea what is actually connected out there. For example, it has no
> idea whether a keyboard sniffer has been attached or whether this may be
> a radio keyboard.

For things the system cannot detect, there are two options: either they are
told to the system by the person who connects the hardware (usually the
administrator, but it may also be the user in case of a usb keyboard), or they
are unknown (in case it wasn't the intention of the installer of the device to
have them, such as with hardware sniffers).  There is nothing the system can
do against the second category.  These attacks must be solved differently,
using things like physical locks and large pieces of metal.  I was ignoring
these issues, because that part is for other people to solve. :-)

> 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.  This is the realm of software, but it's about bugs.
When talking about what the system can do, I'm assuming that the bugs have
been fixed.

> In order to build an end-to-end trusted path, the computer must be able
> to authenticate that the terminal device is in fact an authentic
> terminal device. It must establish an end to end encrypted session to
> preclude tampering in the middle of the connection, and it must then
> assume that the user is taking responsibility for physical security
> (which, in the voting scenario, is not that unreasonable).

Right.  The encryption is of course only needed if the path between the
terminal and the machine is partly on untrusted terrain.  This is for example
not the case within a voting machine (if someone can insert a sniffer, they
will be able to insert it before the encryption takes place).

> 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).  In that case, the system can indeed trust the terminal.  I'm
assuming again that the system doesn't actually want to defend against the
owner, by the way.

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

> Keyboard stuffing attacks are not hypothetical. They have been a joy of
> hackers for years.

Sure.  And I totally agree that it's something which should be solved.  But
it's not our problem to solve.

As far as software is concerned, the system can trust a local terminal as much
as the installer of the terminal told it to.  How much that is probably
depends on what kind of terminal it is (in particular if it's wired or not).

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

signature.asc
Description: Digital signature