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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
