Windows Vista’s Full Volume Encryption & TPM, part 6: more oddball TPM 1.2 links

Semi-random links to information I’ve used as reference for some of my rambling thoughts…

Whew! Now back to your regularly scheduled surfing.

Windows Vista FVE in the news

The enterprise edition of Vista will have a feature called “BitLocker” that can encrypt systems that have an optional security chip.

The feature debuted Monday on a test version of Vista that Microsoft released to get feedback from software developers and customers.

“So essentially if a machine is lost … it renders it useless to whoever steals it or takes it from them,” said Shanen Boettcher, a senior director in the Windows group.

Commentary: This further supports the idea that FVE will only be available to those customers who license the Enterprise edition of Windows Vista. Will this be available to the consumer? I would suspect not, based on Microsoft’s history and its planned set of SKU’s:

  • the Enterprise editions of Windows (2000, 2003) in the past haven’t shown up on the shelves of retail stores
  • What with plans for SKUs such as Windows Vista Home Basic, Windows Vista Home Premium and Windows Vista Ultimate – all presumably oriented for the consumer market – I personally doubt there’ll be room in the OEM lineups for a fourth SKU directed at their consumer market.
  • Previous rumours indicated that the Vista Enterprise edition will only be available to Microsoft customers who have signed up for (the not inexpensive) Software Assurance plan, which is definitely not something consumers (or even small/medium-sized businesses) can usually afford.

However, I feel obligated to point out that the (obviously out-of-context) quote from Shanen Boettcher seems pretty misleading/overreaching in its current form. If I’m interpreting correctly, the “BitLocker” feature is nothing more than Secure Startup (SSU)/Full Volume Encryption (FVE).

While SSU does make it more difficult to discover on-disk secrets and sensitive data files, its mere presence or default configuration hardly makes the machine or its data “useless to whoever steals it”. So long as the disk contents remain undisturbed, the simple configuration of SSU will allow Windows to boot up and allow an attacker to attempt to access its data (e.g. via console logon, network logon, shares access, unpatched vulnerabilities, previously-installed malware, or other as-yet-unimagined attack techniques).

Seems it’s time to discuss the Full Volume Encryption technical whitepaper that’s available for download – make sure we’re all understanding it the same way (or not), and raise the obvious questions worth asking.

Windows Vista’s Full Volume Encryption & TPM part 5: does FVE require a TPM or not?

Tonight I stumbled on a rant that quoted a Microsoft web site around various Vista features including Full Volume Encryption (FVE). The stunning thing for me was the following quote (emphasis mine):

“Windows Vista supports full-volume encryption to prevent disk access to files by other operating systems. It also stores encryption keys in a Trusted Platform Model (TPM) v1.2 chip. The entire system partition is encrypted-both the hibernation file and the user data. It also stores encryption keys in a Trusted Platform Model (TPM) v1.2 chip, if one is available on the PC.”

Did I read that right? Does this mean that FVE can actually encrypt the entire system partition whether there’s a TPM 1.2 chip on the system or not? Presumably if this is true, the key to encrypt the volume is stored in the 50 MB partition that is required to store the pre-boot partition that supports FVE. That is, the key is stored in software.

So how does this improve upon what’s available in Windows XP? Frankly I don’t know right now, but I can take a couple of educated guesses. Presumably the Secure Startup sequence requires a user-supplied password before it can decrypt the Vista system partition, so this means there’s yet another password for an attacker to have to brute-force.

However, I gotta wonder whether a software-based Secure Startup boot password is any different from a SYSKEY boot password – no complexity requirements, never needs to be changed, and impossible to manage [pretty much by design] over a large population – how do you archive and recover such a boot password? If so, then this is a just as dangerous/difficult to manage a security control as SYSKEY is.

OK, so I got excited there for a sec, but on further reflection, maybe this isn’t any better than we had before. In fact, it’s even scarier: what if I forgot my Secure Startup boot password, and its encryption key was stored in software? What do I do then? Presumably ALL my data is encrypted with that key (now irretrievable); whereas with SYSKEY I lost the OS but presumably could recover my data, now I’ve lost both the OS and my data. Ugh, sounds pretty gross to me.

I think I read about some capability to archive the encryption key used by Full Volume Encryption, but I’ll have to dig around to confirm (a) if it’s true, and (b) how it works. Until then, consider this entire sub-rant one man’s opinion, no more.

TPM 1.2 hardware news: integrated chipset launched for AMD K8 systems

Note that ULi had desktop motherboard vendors lined up at the launch event, but not PC system OEMs for desktops or notebooks. Between this and the fact that the chipset is aimed at AMD (not Intel, which still appears to be the CPU vendor used most of the time by most OEMs) I don’t believe this will have a major impact on the business market. However, it’ll definitely help get the next-gen TPM hardware into the hands of many consumers and small organizations.

That’s just a good thing, no matter whether the TPM technology helps secure PCs via Linux, Windows-based third-party TSS apps or via the Windows Vista Secure Startup feature. Personally I’m just happy to see increased uptake of the TPM hardware by PC technology vendors.

Categories TPM

Dell licensed TSS from Wave Systems – soon shipping TPM-enabled notebooks?

Not often we get a public hint of upcoming release plans from the computer vendors like this, but it looks like Dell has made a stronger commitment to the TPM wave that is catching fire with most major computer vendors.

Dell has added TPM chips to a couple of desktops, but has consipicuously been missing anything on their portables. I’m hoping we’ll see a notebook (and maybe a Tablet?) come out from Dell real soon now that has a TPM chip. Even better, since Dell has delayed all this time, perhaps they’ve been holding out for a production-ready TPM 1.2 chip…?

Gateway stole a leadership position from Dell by releasing their 14″ widescreen Tablet before Dell had a chance to reach that market. Of interest to me was their forward-thinking inclusion of a TPM 1.2 chip as well. Let’s hope Dell is readying a catch-up response to this, and that they’ll blow us away with TPM 1.2 chips across all their new systems from here on out!

Categories TPM

Windows Vista’s Full Volume Encryption & TPM, part 4: available PCs that include TPM 1.2 chip

[Edit: corrected the Broadcom adapter model #, and removed the listing for the Dell Precision 380 Workstation, which turns out to only have a TPM 1.1b chip via the Broadcom BCM5751 chip.]

Since I only talked about Tablet PCs in part 2, I figure I owe it to the community to collect together a listing of any and all shipping PCs that include a v1.2 TPM chip.

What follows are all Servers, desktops, notebooks and Tablets that I could confirm currently include a TPM 1.2 chip:

none to date

Desktops & Workstations
Dell Optiplex GX620
Gateway FX400XL (via Broadcom NIC referenced here)
Gateway FX400S (via Broadcom NIC referenced here)
Gateway FX400X (via Broadcom NIC referenced here)
Gateway E-6500D SB (via Broadcom NIC referenced here)
HP Compaq Business Desktop DC7600 (via Broadcom NIC)
Vector GZ desktop

Gateway M250 Series
Gateway M460 Series
Gateway M680 Series

** HP TC4200 [THEORY: the TPM is an orderable part (Part #383545-001, $42.00 list price), which implies that it’s a removable/replaceable part (and thus that a TPM 1.2 chip could be swapped in later), but this is only an unconfirmed theory on my part] **

Gateway M280 Series

Bonus 1: Add-on Components
Broadcom BCM5752 & BCM5752M network controller chips (which has an integrated TPM 1.2 chip)

Bonus 2: Linux drivers
Linux driver with support for Infineon’s TPM v1.2 chip

And again, don’t forget to check Tony McFadden’s TPM Matrix. NOTE: I only used Tony’s TPM Matrix to start my search – I haven’t copied any entries without external confirmation, so there may be disagreements between our pages. When in doubt, remember that unless I could confirm a TPM 1.2 chip was included in a PC system, I did not list that system here. Tony’s page is meant to be more comprehensive, so he lists both PC systems with TPM 1.1 chips as well as those with unknown chips or which haven’t been confirmed to include a TPM chip.

P.S. Do you know of any other PC systems shipping a TPM 1.2 chip? If so, add your comment below!

P.P.S. What have I learned in my searches for TPM 1.2-integrated PC systems? Here’s a couple of tips that may be helpful if and when you off on your own search:

  1. If the spec sheet only mentions non-version-specific phrases such as “TPM chip”, “TPM Embedded Security Chip” or “the TCG standard” [emphasis mine], you can and should assume that the chip is a TPM 1.1 chip. Anytime I was able to confirm a TPM 1.2 chip, the PC system vendor made specific and repeated mention of the 1.2 version number. [Apparently this is a big differentiator, though few if any references on the Internet have clarified why.]
  2. If you are looking into a PC that was shipped before Summer 2005, you can rest assured that it did NOT ship with a TPM 1.2 chip, since the TPM chip vendors didn’t have production chips on the market until at least mid-summer of 2005.

Windows Vista’s Full Volume Encryption & TPM, part 3: links & background reading

Paul Thurrott indicates that FVE will appear in Enterprise & Ultimate editions of Vista:

Bart DeSmet digs in deep on EFS, TPM, Secure Startup and more:

David Berlind speculates on possible incompatibility between Vista/TPM & virtual machine technology:

George Ou shines light on a potential key export “backdoor” for FVE, and his ideas on why smartcards would be an ideal FVE key storage mechanism:

William Knight vaguely alludes to some proprietary algorithms used in FVE that could lead to “a possibility of in-memory attacks for keys.”

David Berlind speculates again on a possible use of the TPM by Windows Product Activation (totally unconfirmed at this point):

An out-of-date but still “best there is” collection of TPM-related hardware, software and integration information:

And last but not least, Microsoft’s Technical Overview of FVE:

Windows Vista’s Full Volume Encryption & TPM, part 2: FVE on Tablet PC?

OK, so where was I when I last left the TPM topic? Oh yeah

Frankly I don’t know what to think about the state of TPM-backed data encryption. I really *want* to be able to say “yeah baby – your best bet for securing data on a laptop will be Vista’s FVE” (or any other OS-level TPM-backed file encryption option). For a few hours, I actually believed it could be true – not just for an individual, but for any really big organization as well.

However, the past couple of months’ effort has me pretty much convinced otherwise. I’m not exactly optimistic for the prospect of widespread TPM-secured data protection in the near future.

It looks to me like Full Volume Encryption (FVE) in Windows Vista won’t be a viable option for anyone who isn’t prepared to drop a bundle on new computing hardware at the same time. That’s because there’s almost no computers – especially mobile computers – on the market that have a v1.2 TPM.

While I realize that there are other IHV- and ISV-supplied TSS packages to support TPM-backed file encryption, I am mostly focused on Vista FVE for a couple of reasons:

  1. Until a service is provide in-the-box with the OS, my experience with customers is that integrating vendor-specific security software is a huge hassle, and not supportable at scale over shorter periods of time (e.g. 2-3 years).
  2. There’ll often be more than one TPM-enabled package to support – generally, it looks like an organization will have multiple packages, one for every desktop/notebook/tablet/server vendor that integrates a different TPM module.
  3. It’s not clear at this time how the TSS packages are licensed, but I’ll take a SWAG and assume that you’re only licensed to use the TSS package on the system with which it was shipped, and that you’ll have to pay extra to use that package on PCs that were shipped with a different TSS package.
  4. An organization could scrap the bundled software packages entirely and just license a third-party product across the board (e.g. Wave), but the choices are pretty limited from what I’ve seen, and personally (without having had any hands-on experience to support my gut feeling) I don’t know how much confidence I’d have locking my organization’s most prized data up under this – e.g. what’s the enterprise management (archival & recovery, configuration management, identity management) story like?
  5. [Disclosure: I’m a former Microsoft employee, security consultant and spent most of my tenure consulting on EFS, RMS and other security technologies.]

I’ve been in the market for a new laptop for a while, and one of the reasons for my recent obsession with TPM is that (a) any purchase I make now will have to last well beyond the release data of Vista, (b) since I intend to continue to leverage my Windows security expertise, I should really get a computer that supports FVE so I get first-hand knowledge of how it works, and (c) you generally can’t add a TPM chip to a computer after you’ve purchased it (with at least one known exception).

Oh, and I’ve committed myself to the Tablet PC variant, since I am a committed “whiteboard zealot” and I expect to use the freehand drawing capability quite a bit.

So my mission is to find a Tablet PC that meets my “requirements”:

  • TPM v1.2 chip
  • max RAM > 1 GB
  • dedicated video RAM > 32 MB (to support the lunatic Vista graphical improvements)
  • can run from battery for at least three hours a day (e.g. bus rides to and from work, meetings away from my desk)
  • won’t break my wrist if I use it standing up (e.g. weight under 5 lbs)
  • will withstand dropping it once in a while – I’m more than a bit clumsy

I have spent countless hours scouring the Internet for TPM-enabled Tablets. After my intial survey of the PC vendors’ offerings, I figured there’d be at least a couple of options from which to choose. However, the longer I looked, the more bleak it became. Of the major vendors of Tablet PCs (Acer, Fujitsu, Gateway, HP, Lenovo, Motion and Toshiba), I have so far found exactly ONE Tablet on the market with a v1.2 TPM chip.


And not exactly the industry standard for large enterprise deployment – Gateway!

Did I mention that Windows Vista will require the v1.2 chip to support Secure Startup and Full Volume Encryption?

Oh, and did you hear that Microsoft is trying like h*** to get Tablet PCs in the hands of as many users as possible?

Geez Louise, I even went so far as to contact Fujitsu (who have a really fantastic Tablet with a v1.1 TPM chip) to see if they were sitting on any about-to-be-released v1.2-enabled Tablets, asking them the following:

Could you give me some idea of the following:
– whether Fujitsu is committed to integrating v1.2 TPM chips in their computing products?
– when we can expect to see Tablet PCs with v1.2 TPM chips integrated into them?
– Any planned model or series of Tablets that the v1.2 TPM chips will be used in e.g. Lifebook 4000 series, Slate vs. Convertible, etc.?

And this is the response I got:

We fully intend to continue our support of TPM and transition to v1.2.

However, at this time we can not provide a date as to when this will be available. Fujitsu company policy and NDA agreements with suppliers do not allow us to publicly disclose future plans prior to product launch.

So what’s a guy to think? Right now we’ve got exactly one FVE-ready Tablet on the market, and according to this guy, the big wave of computer upgrades in the business sector may already be passing by. [Let me ignore the fact that I haven’t looked into notebooks yet, and assume that TPM v1.2-equipped notebooks are just as scarce. I’ll check into this further and report back.]

Between now and the shipment of Vista (perhaps October 2006, if you can believe these rumours), less than a year away, am I to believe that hordes of TPM v1.2-equipped PCs will show up on people’s desks? If so, then perhaps there might be a minority of organizations who would consider testing the Vista FVE technology (though I doubt they’d be ready to standardize on it, assuming – rightly – that they’ll have less than a majority of Vista FVE-ready PCs in their organization).

But even if TPM v1.2-equipped PCs were to quickly dominate these organizations, would I feel comfortable urging such organizations to adopt Vista to enable use of FVE to protect their data? I honestly don’t know – I don’t feel a resounding “YES” coming on, but neither do I feel a “NO” building in my gut. Perhaps it’s because I feel like this question won’t be practical for a number of years yet.

By requiring the v1.2 TPM chip for FVE & Secure Startup, I believe that:

  • Third-party TSS packages will get a lot of leeway to take the “organizational standard” position – especially for those TSS packages that also support v1.2 TPM chips
  • Most mid-sized to large organizations won’t be in a position to adopt FVE & SS as their data protection standard until say 2008 or later.

This leaves me wondering what data will be left to protect by then? Given the fact that most organizations are being forced through one regulation or another to encrypt customer-sensitive data, I believe that the next couple of years will be the final window for unencrypted user data to reside on client PCs.

Put another way: if you’re the InfoSec officer in charge of recommended strategies for regulatory compliance & avoiding liability, wouldn’t you rather just encrypt every disk on every “physically insecure” PC throughout the organization? That’s one sure-fire way to know that users haven’t accidentally stored a sensitive file in an unencrypted volume, folder or file. Only then would the organization be able to claim that a lost or stolen PC did not contain unencrypted customer data.

[Now, sure, in 3-5 years there’ll be room to re-evaluate the technology used to maintain protected data on hard drives, and it’s quite possible that by then Vista’s SS & FVE will get the nod from many organizations. Migrating from one highly-technical solution to another is never easy in large orgs, and is pretty scary for small outfits or self-supporting end users, but I’m leaving the door open for the landscape to change beyond my wildest imaginings in the 3-5 year timeframe…]

Does anyone see things differently? Does Vista FVE look like it’ll capture a significant portion of the “data protection” market? I’d really like to be wrong about this – it would suck if the best “free” on-disk data protection technology to come out of Microsoft won’t be practical for the majority until long after they had to commit to another on-disk encryption solution.

EFS + SYSKEY followup, NTBackup and EFS-TPM integration

A colleague recently asked me about a previous post of mine:

“Mike, in your blog you mentioned you must use Syskey for real protection of EFS protected data. You said if you didn’t use Syskey, it was relatively easy to get to EFS files. So 3 questions that I haven’t been able to find an answer:

  1. Are there any public attacks documented or tools to get to EFS protected data, other than cracking the user desktop login password? If yes, please link. I guess this would be cracking the DPAPI secure store.
  2. What NTBackup options are required to keep the data encrypted in the .bkf file? If there isn’t a way, how can data files in incremental backups be safely encrypted?
  3. Dell is now shipping TPMv1.1 chips in their Inspiron & Latitude laptops. Can EFS private keys be stored there? How can you know that the private key is actually stored in the TPM chip?”

First I should clear up the misunderstanding I may have created regarding SYSKEY and EFS. What I meant to assert is that EFS files are relatively easy to get at (for educated attackers) unless you use either:
(a) SYSKEY boot floppy or SYSKEY boot password, or
(b) domain logon accounts (and a relatively decent password/passphrase).

I don’t generally recommend SYSKEY in a domain environment; instead I recommend domain accounts and strong passwords or passphrases for reasonable security against brute force attacks.

As for the direct questions I *was* asked:

  1. There are no cryptographic “backdoors” to attack EFS data – the cryptography behind EFS, combined with the reliance on multiple layers of protection of the encryption keys, follows the usual best practices for software-based data encryption. I have faith in DPAPI to do what it sets out to do, and to be as secure as any software-based encryption implementation can be. However, there are a number of potential attacks on EFS’d data – none of them “magic”, but really just predictable consequences of both (a) the ways that keys must be stored on disk and (b) the integration of EFS with the Windows logon infrastructure.
  2. No parameters or configuration are necessary for NTBackup to be able to backup encrypted files – its default behaviour can natively backup EFS encrypted files. NTBackup is one of a class of applications that use the RAW APIs. Applications that call these APIs are requesting that NTFS give them the “raw” file along with the EFS alternate data streams, all in a single binary stream. This means that NTBackup gets a copy of the encrypted file and its keys, so that the backup files contain everything that’s needed to decrypt the files later. When NTBackup restores such files to an NTFS filesystem, you get back the encrypted file intact with its encryption keys. So you can backup any files you like with NTBackup – full, incremental, whatever – and rest assured that the backups are no more vulnerable than the original files. While some backup solutions end up with plaintext copies of the files, those backup apps that use the RAW APIs never expose the unencrypted file contents to later attack.
  3. All currently released versions of Windows are hard coded to ONLY use the native software CSPs for EFS (specifically, the Base or Enhanced CSPs) – they can’t use any other CSPs for EFS, even the oft-requested smart cards (nor the TPM-enabled CSPs). I have no idea whether there will be support for TPM storage of EFS private keys in Windows Vista, though they have announced plans to include EFS-private-key-on-smartcard support. They also mention support for a “full volume encryption” feature (AFAIK, unrelated to EFS) that would work on systems with TPM v1.2 chips. I assume the TPM software dictates how keys are managed, but until there’s any information on whether non-smartcard CSPs are supported, I can only speculate how “enforcing” TPM storage could possibly work. At this point, I believe the “enforce smartcard” option in Windows Vista EFS is a simple checkbox, so it’s probably hard-coded to look for smartcard CSPs only.

I had a quick look around the Internet for current details on leveraging a TPM (Trusted Platform Module) chip for encrypting files on disk – here’s what I learned on my first pass:

  • There’s very little mention of which version of the TPM spec is supported on most PCs in the market today – or at least, that information is not easy to uncover. So far the only mention I’ve found on Dell & Toshiba’s sites is “v1.2” for certain Optiplex models, and v1.1 Infineon chips in the Toshiba Tecra M4 & Latitude systems you mentioned.
  • So far I don’t know if there are any significant differences between v1.1 & v1.2 TPM chips in terms of support from the CSPs, and what application scenarios are/are not supported by each version. Maybe the differences are negligible, maybe there’s an order of magnitude more possibilities once you have v1.2. [Or maybe that just happens to be what the “full volume encryption” team was willing to test, even if v1.1 would have been just as good for this scenario.]
  • Seems like every PC vendor has some models shipping with TPM chips – IBM/Lenovo (Atmel), Toshiba (Infineon), HP, Dell. Good news for us.
  • Seems like there’s only a small number of application + CSP suites out there so far that enable TPM in XP:
  • Some suites leverage particular application APIs that require third party plug-ins (e.g. Dell/Wave)
  • Others (e.g. Toshiba’s suite) “support” EFS features – I don’t know what this means, as the documentation I’ve seen is too vague to be sure:
    • Does it merely leverage the DRA public key to provide a recovery path for the Personal Secure Drive (encrypted virtual drive)?
    • Does it encrypt the contents of the user’s profile with keys protected by the TPM?
    • Does it somehow provide a redirection layer so that the RSA files in the user’s profile are actually encrypted by TPM-protected keys before the Windows CSPs drop the files on disk?

This is fascinating, and a lot more than I expected to turn up. It seems that TPM has finally started to catch on with the PC vendors – I was shocked to see that pretty much all the major PC vendors had TPM-enabled PCs. It’s not that I didn’t expect this to happen, but that since I hadn’t heard any of my customers asking me about this so far, I assumed it was still “on the horizon” (like “the year of the PKI” is still just a year or two away, for the tenth year in a row).

I’m going to devote some serious research into the state of TPM-enabled data encryption, and over the next few posts I’ll be putting up my findings and opinions on where I think TPM-enabled encryption fits into the kinds of solutions I normally recommend.

Watch for it.

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.