Owner override and the meaning of trust
My owner override idea was meant as a thought experiment to raise the question of whether trusted computing can be implemented in a way which makes it useful to allow you to trust your own computer and doesn't facilitate having your computer perform functions you don't want it to.
As security experts point out, "trust" has a different connotation in security than it does in everyday language. In Ross Anderson's FAQ:
Or take a civilian example: suppose you trust your doctor to keep your medical records private. This means that he has access to your records, so he could leak them to the press if he were careless or malicious. You don't trust me to keep your medical records, because I don't have them; regardless of whether I like you or hate you, I can't do anything to affect your policy that your medical records should be confidential. Your doctor can, though; and the fact that he is in a position to harm you is really what is meant (at a system level) when you say that you trust him. You may have a warm feeling about him, or you may just have to trust him because he is the only doctor on the island where you live; no matter, the DoD definition strips away these fuzzy, emotional aspects of `trust' (that can confuse people).
(Emphasis added.)
So, to be more precise, I should say that the thought experiment asks whether you can have a trusted computing system which helps make your computer more worthy of your trust, without allowing your computer to do things you don't want it to do. In the more technical sense, you already trust your own computer all the time, which doesn't have anything to do with whether your computer is secure. (If you trust an insecure computer -- for example, by typing a passphrase on a machine with a keylogger installed -- you might suffer some adverse consequence.)
The owner override idea is directed toward one part of that question, but the other part is also interesting. Is it reasonable to trust a computer which hasn't been under your physical control at all times? (At the airports, they've stopped asking whether your bags have been under your control at all times since you packed them.) Is it reasonable to trust a computer which is owned and regularly physically controlled by another person? People constantly do trust computer equipment which isn't theirs; by doing so, though, they expose themselves to certain risks. Can those risks be eliminated?
Here's another example: you go to a random terminal, and you want to use it to connect to your own computer. You will have to trust that the terminal will let you use services on your machine in a way which respects your privacy.
With something like Palladium, the machine can show you a user interface which suggests that it's trusted to be running a particular platform. (In our second Microsoft meeting, we talked a little more about the user interface question.) But if that user interface is widely known and standardized, it can presumably be faked -- and if a machine normally lights a LED or something to show that it's in a certain mode or running certain software, that LED can be faked, too. (It's easy enough to find the LED's leads and connect them to a power supply instead of to the pins on the motherboard which are supposed to be indicating something about the current CPU or chipset operating mode!) In some scenarios, the user interface can share a secret with the end-user, but that doesn't seem to help much if the end-user is currently using a physically different machine from his or her own home box! (Sharing a secret with the user interface is helpful only when the user interface is provided by a device which knows the secret, which is not the case in the remote login situation.)
However, there is a possibility which was suggested at one point by Microsoft: your machine can make a cryptographic challenge to try to determine some characteristics of the device from which you're trying to connect (so that, if you don't get a connection, you know something is up, and in any case access won't be granted). The terminal could still steal your password, but the use of one-time passwords (with trusted password-calculating devices) or other trusted authentication hardware, like smart cards, can prevent your password from being taken in this way.
In addition, Palladium is going to provide a secure I/O feature, so the client software on the terminal you're trying to use (which can prove its identity to your server) can read your keystrokes and your server can know (when it grants you access) that you're accessing it using a hardware and software combination which sends your keystrokes only to your server, and your server's responses only to your eyes. That sounds pretty good, and your server can enforce this policy by forbidding connections entirely from systems which fail the relevant challenges (which can't prove that they are running certain software in a certain mode with certain capabilities). So far, so good.
However, we already know that secure I/O can be defeated by hardware attacks. If a recording device is placed in hardware between the keyboard and the motherboard, or inside the keyboard itself, the fact that the motherboard and software haven't been modified won't protect you! So your server can correctly authenticate the hardware and software platform of the terminal you're using to connect, while knowing nothing of the hardware bug which has been placed inside the keyboard you're using to talk to the terminal.
So it might be that there is no ultimately reliable way to trust someone else's hardware (or, "don't make a phone call on someone else's embassy's telephone, even if it's a secure phone").
The idea of a world in which the end-user's PC is irrelevant, yet the user still has strong security assurances, seems implausible to me. Some of the trusted computing advocates who have come to talk to us have imagined that world, and suggested that you could use essentially any device to access essentially any service -- the individual computer would become more fungible. But because of the new platform authentication capabilities which would become available, the security properties of the resulting interactions would be verifiable, and verifiably what end users would want them to be.
But that doesn't make sense if people can and will modify hardware -- keyboards and monitors -- to subvert Palladium or LaGrande secure I/O! A device like KeyGhost will be really cheap soon. (In fact, the basic version is already under $100.) KeyGhost even sells entire keyboards with the monitoring hardware built into the keyboard -- and tries to make their keyboards look indistinguishable from any other keyboard. So in some sense it is really not going to be ultimately safe to trust someone else's equipment.
I say this realizing that the status quo is not any better, and is probably worse. I used ssh to connect during my trip to Portland and Walla Walla, so I can claim that my communications were "secure". I even memorized part of the ssh host key fingerprint for the machine I was connecting to. But I connected from at least five machines whose software configurations I had no way to verify at all and which could all easily have been running keyloggers or screen grabbers.
Trusted computing systems could raise the bar slightly. For example, they could require the use of a hardware keylogger instead of a software keylogger, which would then cost $89 instead of $0. But attackers can be fairly determined, and Bunnie argued that hardware attacks do not imply a fundamentally greater sophistication or skill, only an incrementally higher cost (for physical fabrication of a device, whereas the marginal cost to duplicate software approaches zero). I'm not sure that trusting hardware instead of software, when the hardware is owned by someone else and remains outside of your physical control or supervision, is going to be any better in the long run.
A better solution is probably to have a minimal amount of physically small hardware which you trust, with both input and output capabilities which you also trust -- something like a PDA or a laptop -- and an untrusted network to which it's always easy to attach that device.
This isn't always going to be practical.
