And I'm sure that none of this will be used to leverage an existing monopoly, crush competition, and other alternative OSs will be fully supported, right?

You have good points, but you've been in scoble's koolaid lately, so.....

:)

Nothing to do with Koolaid. Besides, this would need to include vodka with the koolaid to give me any kind of buzz. Scoble is clueless when it comes to this sort of thing. (No offense Robert :) )

The fact remains.. the idea behind the NGSCB is sound. Its the implimentation that we need to watch for. As an example... locking down movies and music is pretty useless unless you actually have NGSCB aware sound and video drivers... which you can get around. :)

I liked the though though of vendors like Seagate getting involved. Imagine a NGSCB aware harddisk that can protect/encrypt the data in the hardware bypassing threats exposed by the OS? There is some real potential here.

I only hope other communities like Linux, BSD and Apple see the potential here and start building support for it in future versions.

We will have to wait and see.

I still see it as a "thinly veiled attempt at shifting some of the security-onus from the OS to the hardware with the blessing of Microsoft along with the side "benefit" of Digital Rights Management." (quote from /. discussion) that I couldn't have said better myself (and probably didn't! :)

I think Alan squarely hit the main issue. A lot of people were really scared that MS would abuse this ability, by enforcing whether certain "music files" are playable or not.

Your defense of NGSCB / Trusted Computing fails for the exact same reason as all the others. There is nothing wrong with "new hardware". However the CENTRAL DESIGN CRITERIA for Trusted Computing is that the owner of the computer is forbidden to know his own master key (the PrivEK and/or SRK).

Consider an identical computer with identical hardware. It has identical capabilities and is just as effective at protecting you, the owner. The only difference being that you get a printed copy of your keys. Perhaps you put that printed copy of the keys in your bank saftey deposit box. You still get all of the protection against trojans and keyloggers as you discuss. All of your data is just as secure against hackers.

There is absolutely no legitimate justification to forbid the owner to know his own key. It is purely malicious.

The only thing that forbidding the owner to know his own key accomplishes is to lock the owner out of control of his own computer and files, and to enforce monopoly lock in. If the owner were to know his key he'd be able to unlock his own files if he chose to, avoiding lock-in and lock-out. He can have full control of his computer - if he chooses to.

Letting the owner know his own key preserves every benefit he gets from having such a machine, while simultaneously eliminating EVERY legitimate criticism. Go ahead and advocate "new hardware" if you like, but you have failed to defend/justify trusted Computing. Its central design requirement is purely malicious.

Alsee,

I don't think anyone here will disagree with you. Nor did anyone say you SHOULDN'T have your key. I agree that having the key (properly stored of course), is a good thing(c).

BTW, with the current implimentation you can tap the bus and get the key if you want it as its decrypted there before use.

Ah good. I'm glad you understand the issue about having your keys.

However you are mistaken about tapping the bus to get at these keys. The Trusted Computing Group's tech specs are quite specific that the SRK and PrivEK are forbidden to ever leave the chip. Any encryption/decryption using these keys is required to be done inside the Trusted Platform Module (TMP) itself. The TPMs are also designed to self-destruct / wipe the key if the owner attempts to "tamper" with it in an attempt to get at his keys.

If you have seen the recent IBM ThinkPad commercials you've probebly even seen them advertize that very fact. The one where a government agent-type warns that a hacker can steal your data in a matter of seconds. The owner says his computer is protected with a chip. The agent says chips can be removed. The owner says the chip self-destructs.

It's also in the tech specs of Atmel and the other TPM chip manufacturers, mutiple forms of tamper resistance and tamper detection.

Its not actually the keys at issue but the op codes. OP codes are plaintext on the bus. As such, they can easily be microprobed off the bus. The latest specs do indeed look at encrypting CPU instruction sets, but it's (a) not widely used (b) not widely accepted in manufacturing YET. The next generation TPM CPU should be using this more, but until TPM chip manufacturers look at more resilient tamper resistant mechanisms... this is a sad state of the technology. I can't comment on the ThinkPad, but I am not suprised that its using the new system.... they seem to always be first to adopt it.

If you go looking around, there are two different DefCon presentations where demos of how to probe the bus and get at this were shown. I quite enjoyed the one presented by Lucky Green at DefCon X.

Tapping busses or even feeding falsified data onto busses gets you a lot, but it's not really a complete and satisfactory defeat of the system. The TPM effectively has a low power CPU inside. Actual encryption/decryption occurs inside the TPM itself. All the TPM instructions (including encryptions/decryptions) can be logged within the TPM itself. (Specificly a running hash in a PCR). Communication into and out of the TPM can be encrypted to that log using a key that never leaves the TPM. The contents of that communication never appear ouside the TPM. No matter how much you tap any bus you cannot tamper with those instructions or with that log without voiding remote attestation and without losing the ability to decrypt anything encrypted with keys bound to that log state.

There is no bus to tap there other than ripping the TPM itself open, and that point you may as well just read out the RSK and PrivEK.

Bus tapping external to the TPM may let you clone cleartext out of the Trust system and strip DRM, but all remote communications and all additional decryptions are still forced to go through the properly fuctioning TPM and only using the authorized sequence of commands. You've still got a pretty substantial noose hanging around your neck.

You also wind up pretty much toast once they move the TPM inside the CPU package and start encrypting data to and from RAM.