Adam Back writes:
some definitions:
hw layer -- SCP which I think provides crypto key store, crypto co-processor for sealing, remote attesation
ring 0 -- new layer which controls memory management unit and secured code compartments
supervisor mode -- normal supervisor mode, which can now only read user space, but not trusted agents running in code compartments
user mode -- legacy user level apps under complete control of supervisor mode
and some ASCII art:
+---------------+------------+ | trusted-agent | user mode | | space | app space | | (code +------------+ | compartment) | supervisor | | | mode | +---------------+------------+ | ring-0 / Memory mgmt unit | +----------------------------+ | hardware / SCP key manager | +----------------------------+
each layer below can decide policy and information disclosure through APIs to the layer above.
I don't think this is right, as Peter said that the Palladium stuff could load many days after boot. So I don't think the "ring-0" mode underlies normal supervisor mode as you have shown it. Instead I think they are relatively orthogonal. I'm not sure how to draw it, but I would envision the TOR as a device driver which controls two devices: the trusted execution space, which is some special memory (on the cpu?), and the SCP, the crypto processor. Let us suppose that there is a special instruction to load a block of code into the trusted execution space and give it a new process ID. At the same time this causes the SCP to hash it so that it can attest to it later. Let us also suppose that the ring-0 mode is used only when running code out of the trusted execution space (TE space). What is special about ring-0? Two things: first, it can see the code in the TE space so that it can execute it. And second, it doesn't trap into supervisor mode for things like debugger single-stepping. I'm not familiar with the details of the Pentium family but on most CPUs the debugger single-steps things by setting a flag and returning into the code. The code executes one instruction and then automatically traps into supervisor mode, which hands off to the debugger. This process must be suppressed in ring-0 mode, and likewise for any other features which can force a ring-0 process to trap involuntarily into supervisor mode, which exposes the registers and such. The TOR would then manage the various processes running in the TE space, and their interactions with ordinary code, and possibly the interactions of both with the SCP. I'm not sure if the TOR runs in ring-0 mode and in the TE space; probably it does, as the SCP can attest to it, and we wouldn't want non-Palladium processes to debug it. So really the whole TOR/SCP/TE-space/trusted-agents stuff is relatively orthogonal to the rest of windows. It's almost like you had a fully functional 2nd CPU in there that you could load code into and have it run; that CPU's memory is the TE space, its mode is the ring-0, it has access to the SCP, and it runs the TOR and trusted agents. But Palladium has to use the regular CPU for this so they firewall it off with the ring-0 mode which locks it into this restrictive mode. That's just a guess, probably wrong in many details, but consistent with what I understand so far. Mostly I am hoping to encourage Peter to come forward and correct our misconceptions.
The implications of which are:
- the SCP can implement sealing with data separation against ring-0 (ring-0 can't bypass sealing data separation)
I have this as well; loading a user agent into TE space creates the hash "fingerprint" which will be used for sealing and attestation; other ring-0 agents will have their own fingerprints and won't be able to unseal what this agent does. The SCP compares fingerprints at unseal time to what it was at seal time and (optionally) won't unseal if they don't match. (This is one of multiple sealing options.)
- ring-0 can read all superviser, user, and trusted agent space, but
I don't think so; not necessary in my model, would require significant re-architecting of Windows which won't happen, and inconsistent with the claim that Palladium can load days after boot.
- ring-0 and MMU can compartmentalize trusted agents so they can't tamper with each other, and
Must be true. Some questions: how big is the TE space? How many agents can live there at once? Do they swap in/out? Does data go there, or just code?
- ring-0 and MMU can exclude supervisor mode from trusted agent space and ring-0 space; supervisor mode is itself just another compartmentalized trusted-agent level space. Therefore ring-0 can restrict what supervisor mode (where the normal OS is located) can do.
But ring-0 cannot make arbitrary restrictions on sup. mode. Remember they can't afford to re-architect either the entire CPU nor the entire OS for this. The simplest is that in ring-0 mode you disable certain functions that could trap you into supervisor mode thereby losing control of the CPU, and this ring-0 mode gains you access to the TE space.
whereas the normal protected CPU architecture is just:
+------------+ | user mode | | app space | +------------+ | supervisor | | mode | +------------+
I'm not much of artist but I would put the new stuff off to the side of this in its own tower. Ring-0 mode at the bottom, running the TOR which is shown above it, which manages the user agents which would be on top. The SCP is further off to the side, perhaps managed by the TOR.
- from these assumptions it appears an OS could be implemented so that all OS calls pass through ring-0 APIs and mediation to get to supervisor mode OS. In this case the OS could observe system calls the trusted agent makes, but not in general read, debug, modify virtualize or modify trusted-agent code. The non-virtualization presumes encrypted trusted-agent code, which Peter said is not done, so this can't be how it works.
I'm not sure what you mean by the OS observing system calls. By definition, system calls go into the OS. So I don't think that will ever stop happening. But it does mean that when a ring-0 trusted agent makes a system call, we change to normal supervisor mode which makes the trusted space invisible. The point we are dancing around is this. How does it protect the data, along the whole path from the remote machine, through where it is processed locally, until it is sealed on the local disk? It seems that it must be in the clear for a while on the local machine. Where is that - in regular memory, or TE space? It's not that big a deal to be unable to read TE *code*. From what Peter says, that is typically not encrypted on the disk. So the code is no secret. What we must be unable to read are the data being handled by this code: the registers, the contents of memory that are sensitive. And by the registers I include the PC, since that would leak information about the data. We can't single-step it, we can't put breakpoints into it, we can't change it while it is running.
I would be interested to hear what model takes for Palladium mapping the interactions and restrictions between Trusted Agents, user space, OS kernel, TOR to the hardware. We need this kind of detail to reason about limits of the Palladium and make distinctions between what is possible with Palladium implementation choices vs what other types of OSes could be built from the hardware features.
I am curious about this from the technical perspective. I think this is one of the most interesting developments in many years on the security front. But frankly I don't think it will do them much good to tell you and most other cypherpunks about it, because whatever they say, you and others will twist it and lie if necessary a la Lucky to turn it into some horrible perversion. Even if the design were totally benign, that doesn't mean Microsoft/Intel couldn't change it someday, right? They could put a machine gun into every PC aimed at the user, and a camera over his head. That's the level of reasoning in Lucky's Defcon presentation, except that he says that they've already done it. I applaud Peter's patience but pity him for his naive belief that he is engaging in a good faith exchange where he will get a fair hearing.
One idea I think would be interest is as follows:
- the TOR (which lives in ring-0) _could_ be used together with the OS to force all trusted-agent in-flows and out-flows (network traffic) to go through code under supervisor mode control.
I think this is pretty likely, but with the data encrypted by the time the supervisor mode sees it.
I don't think this is likely in the current design; but this change would be an improvement:
- it would at least allow user audit and control of in-flows and out-flows;
If the data is in the clear, it would undermine the security guarantees! Look at my online poker game - if the dealer can tap into the data going out, he will learn what everyone else's hands are. Look at the anonymous network - an eavesdropper can learn where all the data is and how it is flowing. The data must not be made available in the clear anywhere the user can get at it, to provide the proper security.
- the user could block suspicious phone-home information out-flows,
Well, he *does* know at least the address the data is going to. There's no way to hide that (short of anonymous message forwarding).
- the user could read out-flows and demand un-encrypted documented formats, or if encrypted, encrypted with keys the supervisor mode gets copies of.
There are some applications which will still work if all the users can *see* all of the data, but just not modify it. Maybe my digital cash example would fall into that category. You can see how much you're spending, but you can't manipulate your wallet. But there are many others, such as those above, where being able to hide even information disclosure from network participants adds tremendous power. You remember the Eternity network, how one concept had files being shared across multiple nodes such that no one knew which files were on his own computer. That was crucially important for non-repudiation and censorship-resistance. This was done with cryptography, but the point is the same: hiding information from network participants can greatly increase security. With TCPA/Palladium you can get some of the same security properties with much simpler ode (with admittedly lower levels of security until hardware improves). Skipping down...
And of course remote attestation will not work either, if the app has been meddled with.
Remote attestation, which is not itself general -- just a remote dongle thing -- if not tied to remote dongle controlled sealing which is necessary for the main application function could be nopped out.
I am assuming that you are attesting to the remote system, and you only can control your local one. You want to get something from the remote, and it will only give it if you are running "clean" on real hardware. So you can't virtualize and still attest, since ultimately you don't have a TPM endorsement key (or Palladium equivalent) with a nice TPME endorsement certificate issued on it. Of course if you have control of the server machine, you can ignore attestation. But that just says that the operator of the remote machine can choose for himself which apps to run. He can run an app that checks remote client integrity or he can run one which doesn't care.
So in the general case it seems that remote attestation is also effectively virtualizable, modifiable and debuggable by first nopping out remote attestation checks. (This is not strictly virtualizable as the remote dongle call nopping modification makes it no longer the same application, but as I said unless this is necessary for the application it doesn't otherwise change it's behavior, so it's effectively virtualizable).
I'm not sure I follow this, but it sounds like you are talking about manipulating the server machine doing the checks, while in most cases you can only manipulate the client machine making the request.