Trusted Computing Best Practices, the TNC spec, and Microsoft’s involvement – hypocritcal?

Below are excerpts from Bruce Schneier’s “Schneier on Security” blog, asserting that Microsoft is making an effort to prevent the TCG’s software-only spec for TPM apply to Windows Vista before its release:

In May, the Trusted Computing Group published a best practices document: “Design, Implementation, and Usage Principles for TPM-Based Platforms.” Written for users and implementers of TCG technology, the document tries to draw a line between good uses and bad uses of this technology.


Meanwhile, the TCG built a purely software version of the specification: Trusted Network Connect (TNC). Basically, it’s a TCG system without a TPM.

The best practices document doesn’t apply to TNC, because Microsoft (as a member of the TCG board of directors) blocked it. The excuse is that the document hadn’t been written with software-only applications in mind, so it shouldn’t apply to software-only TCG systems.

This is absurd. The document outlines best practices for how the system is used. There’s nothing in it about how the system works internally. There’s nothing unique to hardware-based systems, nothing that would be different for software-only systems. You can go through the document yourself and replace all references to “TPM” or “hardware” with “software” (or, better yet, “hardware or software”) in five minutes. There are about a dozen changes, and none of them make any meaningful difference.

If true, this feels to me like some form of hypocrisy, at least at a company level. Microsoft took a decidedly different stance on the use of the “no execute” (NX) feature of the latest generation of CPUs from Intel and AMD, and in an ideal world I’d expect them to do the same here.

In the release of Windows XP’s Service Pack 2 (SP2), they implemented changes to the OS that would enable it to assert the “no execute” flag on any and all processes running on the system – if a process attempted to execute a “page” that was previously considered a data page (i.e. non-executable code), then the OS could immediately halt the program and alert the user. The intent is to prevent things like “buffer overruns” from being able to successfully circumvent a program’s intended purpose and ultimately cause the program to do something the attacker wishes (usually a malicious attack on the OS, its programs, or the user’s data). Worms and viruses have had a field day with this kind of attack for years, and Microsoft and the CPU vendors finally got around to implementing an idea that had kicked around the security community for quite a while.

So far so good. However, while this feature was intended to work with the cooperation of software and hardware, it left most of the existing base of XP users (those without NX-capable CPUs) up the creek. So Microsoft decided to implement a subset of those ideas on any computer running Windows XP SP2. This is a software-only implementation of NX – not perfect, not foolproof, and definitely not as strong as the hardware-backed NX you get with the NX-capable CPUs, but a major leap forward from the “buffer overrun friendly” versions of Windows that have preceded it.

And actually, it seems to work pretty well. I’ve enabled the NX feature on all the computers I touch, and seen it catch a number of programs that were (in most cases accidently) caught doing the very things that NX is set to trap. It doesn’t interfere with the stable, mature applications I’m running, and it hasn’t yet prevented me from doing anything really important. Mostly, it’s trapped this behaviour in the third-party “shareware” type apps that are nice to have. [Hopefully I’ve been able to help the developers of these apps by sending them the crash dumps from these apps. When I am notified by XP SP2 that an app was caught by NX, I’ll trace through the dialogs that tell me where the dump files are located – indicated as the “technical information” that would be submitted to Microsoft through the Error Reporting feature – I’ll find the dump folder, Zip up a copy, and email that Zip file to the ISV who developed the app. Microsoft probably does this as well for apps that often show up in their error reporting queues, but I figure it can’t hurt to make sure anyway. Hint: I don’t have one on my system right now – the folder is deleted once it’s uploaded to Microsoft’s error reporting site – but the crash dump files will be written to your %temp% folder, with a folder name conaining “WER”, and the major files will have the extension “.hdmp” and “.mdmp”. The files compress quite well.]

So here’s my concern: if Microsoft’s Windows division was comfortable with taking a hardware-assisted feature like NX and implementing it as a “software-only” feature, wouldn’t it seem hypocritical to resist applying a software-only spec for TPM to the premier OS next on the horizon? I know I’m being naive here, but it seems like Microsoft would be in a near-ideal position to apply TNC to Vista. They’ve been working on the formerly code-named “Palladium” technology for ages now – or at least talking about it in the press. As well, they’ve apparently been involved with the TCG and the development of these documents for quite a while now, and presumably had at least some level of influence over their content (though probably not a dominant hand in them, given the number of other players with just as much at stake here).

So I wonder aloud: what possible benefit does Microsoft gain from Vista “escaping” the confines of the TNC spec? I would guess it’s because, at this late stage in the development of Windows Vista (they just passed Beta 1), there aren’t a lot of fundamental changes to the OS that could be introduced – without significant risk of delaying the release of Vista AGAIN. [How many scheduling delays now, and how many valuable features REMOVED to keep the schedule from slipping further?]

Perhaps there are other just as innocent explanations as well, e.g.:

  • They’ve been trying to get the TNC spec worked into Vista all along, but at the same time as they decided to pull the “Palladium” features out of Vista, they also had to decide whether to further delay Vista (and continue to stabilize the TNC components) or take the TNC components out of Vista and stabilize the Vista ship schedule.
  • The TNC spec may have taken a late change that drastically altered the requirements for Vista, and the Vista team couldn’t add the major code change without resetting the Vista development milestones.
  • There are plans to add TNC into Vista post-RTM – not unlike the way that many significant features were added to XP via SP2.

It would certainly help quell a potential firestorm of controversy if Microsoft got out ahead of Schneier’s allegations and discussed their plans for TNC implementation in Windows, and what prevents them from incorporating the spec in Vista before it ships. Despite the nefarious personality that some would like to attribute to every action from Microsoft, I’ve found that the people I’ve met and with whom I’ve worked there really do have the best of intentions at heart.