| David Wagner writes: | | > To see why, let's go back to the beginning, and look at the threat | > model. If multiple people are doing shared development on a central | > machine, that machine must have an owner -- let's call him Linus. Now | > ask yourself: Do those developers trust Linus? | > | > If the developers don't trust Linus, they're screwed. It doesn't how | > much attestation you throw at the problem, Linus can always violate their | > security model. As always, you've got to trust "root" (the system | > administrator); nothing new here. | > | > Consequently, it seems to me we only need to consider a threat model | > where the developers trust Linus. (Linus need not be infallible, but the | > developers should believe Linus won't intentionally try to violate their | > security goals.) In this case, owner-directed attestation suffices. | > Do you see why? Linus's machine will produce an attestation, signed | > by Linus's key, of what software is running. Since the developers trust | > Linus, they can then verify this attestation. Note that the developers | > don't need to trust each other, but they do need to trust the owner/admin | > of the shared box. So, it seems to me we can get by without third-party | > attestation. | | You could conceivably have a PC where the developers don't trust | Linus, but instead trust the PC manufacturer. The PC manufacturer | could have made it extremely expensive for Linus to tamper with the PC | in order to "violate [the developers'] security model". (It isn't | logically impossible, it's just extremely expensive. Perhaps it costs | millions of dollars, or something.) Precisely - though see below.
| There are computers like that today. At least, there are devices that can | run software, that are highly tamper-resistant, and that can do attestations. Smart cards are intended to work this way, too. | (Now there is an important question about what the cost to do a hardware | attack against those devices would be.) It seems to me to be a good thing | that the ordinary PC is not such a device. (Ryan Lackey, in a talk | about security for colocated machines, described using devices like | these for colocation where it's not appropriate or desirable to rely on | the physical security of the colocated machine. Of course, strictly | speaking, all security always relies on physical security.) This kind of thing goes *way* back. In the '70's, there was a company - I think the name was BASIC 4 - that sold a machine with two privileged levels. The OS ran at level 1 (user code at unprivileged level 2, of course). There were some things - like, probably, accounting - that ran at level 0. Even with physical access to the machine, it was supposed to be difficult to do anything to level 0 - unless you had a (physical) key to use in the lock on the front panel. The machine was intended as a replacement for the then- prevalent time-sharing model: An application developer would buy machines from the manufacturer, load them with application environments, and sell application services. Users of the machines could use the applications with fast local acceess, even do development - but could not modify the basic configuration. I know the company vanished well before networks got fast enough, and PC's cheap enough, the the business model stopped making any sense; but I know nothing of the details. | I don't know how the key management works in these devices. If the | keys used to sign attestations are loaded by (or known to) the device | owner, it wouldn't help with the case where the device owner is | untrusted. If the keys are loaded by the manufacturer, it might | support a model where the owner is untrusted and the manufacturer is | trusted. There's no more reason that the manufacturer has to be trusted than that the manufacturer of a safe has to be trusted (at least in the sense that neither needs to know the keys/combination on any particular machine/safe). If machines like this are to be built, they should require some special physical override to allow the keys to be configured. A key lock is still good technology for this purpose: It's a very well-understood technology, and its simplicity is a big advantage. A combination lock might be easier to integrate securely, for the same basic reason that combination locks became the standard for bank vaults: No need for an open passageway from the outside to the inside. (In the bank vault case, this passageway was a great way to get nitroglycerin inside the locking mechanism.) In either case, you could (like a bank) use a form of secret sharing, so that only a trusted group of people - with multiple keys, or multiple parts of the combination - could access the key setup mode. Given this, there is no reason why a machine fresh from the manufacturer need have any embedded keys. Will machines like this be built? Probably not, except for special purposes. The TCPA machines will likely require you (and the people who want to do DRM on them) to trust the manufacturer. The manufacturers will be "trustworthy" to Disney and friends because of licensing agreements and such. You would have to trust them because you would not be given the choice. BTW, David Wagner's comment - that you ultimately have to trust root - is a sentiment echoed in some Microsoft quote about how your security is only as good as your administrator. This illustrates the primitive approach to security that we've all been forced to live with. Bank vaults are designed so that even the manufacturer's representative doesn't have to be trusted (much). ATM's are designed so that neither the people who regularly load or unload them, nor the repairmen, nor even the programmers who develop the applications that talk to them, have to be trusted. (The degree to which they meet such goals is another question, of course. People do break into bank vaults, even today - there's no such thing as perfection in the real world.) Separation of responsibilities is the basic technique - but for some reason we don't seem to apply it to our computers. Mainframe environments *do* try to apply this principle - you can divide things so that operators, system programmers, and security officers have separate domains of control, and no one of them can subvert everything. Again, how well this works is subject to debate - I have no first-hand knowledge, but suspect we'll hear from the Wheelers. A great example of how little understood this idea: VMS has for years allowed you to have two passwords on an account. You need to provide both to log in. Virtually everyone who sees this thinks it's just a way to have longer passwords. A few people will comment that it makes password guessing harder - since you are always prompted for the second password, you can't guess the two sequentially. Almost no one seems to understand that this has to do with separation of responsibilities: You can give one password to each of two people, and know that both have to be present for the account to be used. The Unix "root can do anything" philosophy on one side, with the "it's a *personal* computer, the owner/administrator can do anything" philosophy on the other, has really warped our thinking on security. (Example: Does the guy who minds backup tapes need to be trusted? On virtually all systems, yes - what's to stop him from duplicating or just stealing a tape? On a securely designed system, no: His account runs a captive backup procedure. It, not he individually, has access to all files on the system. It, no he, securely provides an encryption key that cannot - without significant cost - be extracted. The tapes are written encrytpted, They can be duplicated or stolen - but the information on them will be secure. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]