I’ve spent a couple weeks now grokking the appropriate body of research and getting the feel of the problem I wanted to address. I have discovered that:

• The Trusted Computing Group (TCG) are a bunch of schmucks who enjoy giving potentially dangerous toys to OEMs with a poor understanding of how (and where) it ought to be used. Even Microsoft has failed to deliver after all its posturing on TC (assuming they ever meant to deliver NGSCB in some form useful to anyone else).
• As a result of their incompetence and of members’ many and fractious proprietary implementations of the spec, there are no systems that implement the full spec on mainstream hardware. Operating system support for the TC hardware shipping in most current laptop, desktop and server machines is not an easy proposition.
• However, to the extent that it does run, it’ll run best and most completely on open-source software (irony of ironies), with proprietary UNIXes (ex. Mac OS) coming in second and Microsoft pretty much dead last. To me this suggests interesting possibilities for fun and profit.

To understand why, consider first the four primitives which together comprise Trusted Computing functionality:

1. Attestation, the assurance to some remote entity of proper system state and code identity as a precondition for obtaining temporary access to secured data (typically a key–see item 2).
2. Sealed storage, the ability to secure arbitrary data before writing it to disk, using a symmetric cipher and a key bound to a specific hardware & software configuration of the local machine.
3. Curtained memory–the ability of processes to reserve some space within their allotted physical memory that is guaranteed protection against attempts at access by all other parties. Strong curtaining achieves this directly by isolating individual processes, whereas weak curtaining specifies a single barrier between the trusted processes (who abide by an Honor Code) and everyone else.
4. Secure I/O, in which trusted processes on the CPU communicate privately with trusted hardware peripherals, presumably via a Diffie-Hellman key exchange.
5. An additional primitive that is assumed in the above but not typically listed is platform identity quantization. For measurements of platform identity and code identity to be meaningful, they must be updated every step up the way–first the system BIOS, then the boot stages and operating system kernel, and the identities of all programs loaded by the operating system, must be measured to obtain a meaningful code and platform identity.

The Trusted Platform Module (TPM), TCG’s snake in the primeval garden of mainstream computer hardware, is built primarily to assist in functions 1, 2 and 5–its internal hardware consists of little more than some register banks, symmetric and asymmetric crypto and the hashing function. To fully implement 3 and 4, and thus complete the basic hardware for a trusted computer that is general-purpose and easy to program for, hardware manufacturers would have to move their own fat asses to the beat of TCG’s drum, and they have been loath to do so.

This is why TC cannot be retrofitted to XP through Windows Update, and why even Vista’s implementation is bastardized and crippled. Serves them right for ignoring academia’s work on the subject.

Six years after Stanford unveiled the concept of execute-only memory (a misleading and silly-sounding name for an elegant, cryptographically-assured architecture that is efficiently implements memory curtaining), everybody’s favorite piece of badly architected silicon the x86 remains an untenable choice of hardware for trusted computing. Ignoring for now that without secure I/O channels even a working trusted computer remains critically vulnerable at the hardware level, the x86 simply doesn’t do enough to enable memory security in consumer operating systems. And Windows, whether it says home or professional on the box, is the textbook definition of a consumer OS. For them to drop all security-by-obscurity features and move to pure-TC-ready would have meant too much of a design rethink.

Linux is a different story. In Linux, all you need to do is beef up enforcement, deny root arbitrary access to protected memory areas, and add code identity logging to the boot sequence. Most of what’s needed is already part of the SELinux extensions + the Enforcer kernel module. This has led more than one person to point out that open source and trusted computing need not be mortal enemies just because the people behind TC are evil. In fact, in a country where the courts have repeatedly demonstrated their inability to enforce accountability on the corporate monoliths, it doesn’t make a whole lot of sense to “trust” any trusted system whose code is not available for public scrutiny–who knows what kind of arbitrary incursions into your rights as owner they’ll try to pull?

Hence, the origins of OpenTrustNet, my hazy concept for a trusted application suite that is of, by and for the open culture movement.