This system of separate components all loosely connected still seems fundamentally flawed. It’s similar to the “link encryption” approach of trying to do hop-by-hop encryption of audio/video between media components. By building it into the existing PC architecture, it also requires much more complicated software. For example, each compartment will be running a kernel instance, probably Linux. So that adds to the compartment setup/teardown time.

I think the purposes of DRM and intrusion resistance should and will be separated. Graphics chips will have their own decryption/decoding logic so that video will be completely processed there. Compartments could then be simplified and the TPM eliminated.

I’m certain DRM will evolve this way. The only question is whether the extraneous features of trusted computing are left in or are deprecated once the DRM use case is eliminated.

People here are very critical about remote attestation, saying it will be unmanageable. The problem is that most people are talking about TPM 1.1 remote attestation. I agree that would be unmanageable for most applications, particularly DRM on regular PC’s. How in the world are movie studios going to have a list of hashes of all trusted device drivers (even mouse drivers etc.) that run in ring 0. That would be required for RA to work. This was acknowledged sometimes during the development of 1.1 and TPM 1.2 can be seen as an “admission” of this. In TPM 1.2 you can start a secure session within an untrusted context. You only need to “trust” the images loaded in the secure context – not the o/s loading the context. A movie company could insist on you using a special signed secure context for watching your movies, and they could verify that you are using it etc. In practice I think we will have one core open-source root (maybe written by Intel/AMD) that can then load and authenticate agents for the particular application and provide separate storage for these agents. Hence, the movie company would only have to verify the root and their agent.

All decryption etc. for watching movies could be done in this secure context with memory curtaining etc. I think this would be feasible. Interestingly, TPM 1.2 spec could be much simpler than it is. In the context just described the chip is only used for authenticating the CPU image, establishing a session with the trusted root and for delivering the grant master key used to unlock the “trusted-context-only” secrets which may be stored in a file in the harddrive. There probably should be more than 1 grant master key so you can have multiple trusted roots etc. A few commands that could be described in 10 pages. It would definitely be feasible to integrate this system in the chipset or even the CPU itself. Oh well, now we’re stuck with the umpteen pages TPM spec.

This is related to the lack of symmetrical encryption mentioned: There’s no reason for having sym. enc. in the chip in the context of 1.2. The chip is only used for one authentication and basic key storage. Especially with SENTER/SKINIT all the chip has to do is to be the giant gatekeeper ensuring only trusted roots can get access to the keys (and the trusted root then has the responsibility of ensuring only trusted agents running in the trusted root context gets the keys they are allowed to etc.). Then these agents can do all the encryption they need on the regular CPU in a secure fashion (unless the system is broken via a hardware attack like memory snooping etc. I suspect that would be a quite difficult attack to carry out with ultra-fast memory etc.).