Slashdot Mirror

This is obviously going to be the vehicle with which the Trusted Computing Group (TCG) will impose its trusted computing standard onto the PC market. I just think it's very suspicious that this is not even mentioned in this article. As major players in the TCG, Microsoft and Intel will be quietly pushing these standards into PCs because of their contraversial nature. For more info check out Ross Anderson's trusted computing FAQ

An AC above pointed out that Intel are part of the Trusted Computing group. This all reminds me of Ken Thompsons compiler trojan. (where he hacked a c compiler to add a backdoor whenever it is compiling "login".)

So, what might icc add to the security functions of glibc? to gnupg, sshd, lsh?

You're reaching pretty far with this argument. Intel is a damned large company with a lot of groups working on things and a lot of different opinions and people. They don't have to have a secret, nasty, ulterior motive, even if one group is working on something you don't like.

You want to be paranoid about Intel? Give up -- they control the CPU. They could trojan you much more easily via the proecessor -- no reason to dick around with the compiler.

Plus, look at the Trusted Computing Group membership list. Do you distrust all products from all of these companies?

Let's see:

* ARM is on there. You better avoid any embedded devices. They might be trojaned. Or using any devices in your system (drives, add-in cards) that have ARMs onboard.

* ATI and NVidia are on there. Video cards are clearly out -- there are numerous standards that will let video cards push code to the processor, plus cards tend to have pretty much unstopped access to memory.

* Fujitsu is on there. You want a trojan, a hard disk controller is a damned sweet place to put it.

* Philips is on there. I hope you don't rely on CDs for anything. Who knows what they put in their reference CD drive controller code?

* RSA is in there. A damned large number of companies license their prewritten libraries (and binary copies of the thing, as well). I hope you've never run Netscape Navigator 4.x, because if you did, RSA could be controlling your system, modifying binaries, etc.

* Phoenix is on there. Boy, I hope you don't trust your BIOS for anything. You *are* using LinuxBIOS on a *completely* open-spec'd motherboard, right?

Point is, trying to distrust huge companies because one small component of the company does something you dislike is simply a futile task. Maybe one day you can use all open-source and viewable software, but it isn't going to be in the next decade -- keep in mind all that controller hardware with unbounded privileges to all the goodies on your computer.

Don't get me wrong. I like open source. I write open source. However, being irrationally fanatical about it is both stupid and counterproductive, and doesn't do diddly for the open source movement.

I know that most Slashdot readers rarely care for ACCURATE info, instead preferring to read incredibly biased editorials like the one linked above...

But, just in case anyone really does want the real info about TCG, here is a link to v.1.1b of the TCG specification, straight from the horses mouth so to speak.

Warning: this is a 300+ page technical document, might take a while to get through it!

Trusted Computing home page includes a list of documents.

Direct link to the specs. It is a Zipped PDF. Seriously heavy reading.

I just found two other spec documents on that page. I just downloaded them, but haven't looked at them yet.

-

What TCPA does is sign a hash of the OS that is loaded with an "endorsement key", embedded in the TCPA by the vendor and unaccessible to the user.

This is incorrect; I don't have time to explain what a TCPA-compliant TPM does, but you can find out all you'd like to know here (look at the section entitled Documents"). In particular, this document.

However, although your description of the mechanism is incorrect, your explanation of the potential effect is right. Among other things, the TCPA makes it possible for a user to generate a public/private key pair whose private key is only usable by the system when it's running a particular set of software (BIOS/OS and selected applications), and is never accessible at all. Given that capability, it is therefore possible to get the public key certified by some third party and then to use the private key to authenticate the boot configuration.

After that has been done, it is then possible for someone to send you data that is only decryptable when you have booted into a certified configuration.

But who would do the certification? And how would they know what the system is running when they certify it? Keep in mind that it's not possible for, say, MS to "certify Windows 2005", the certification is specific to each and every machine. There's really only one way for the scenario you described to work on a large scale, and that's for the hardware vendors who pre-install software to have the TPM generate a key pair and certify it for use by third parties, like web sites.

TCPA is a very useful security tool, but it is possible for it to be abused, given collusion between manufacturers, operating system vendors and content providers.

What we need to avoid all of this is strong digital consumer legislation that requires that every digital rights management system include escape hatches to allow for Fair Use, format shifting, platform shifting and copyright expiration. That would prevent the abuse of the technology without taking away the usefulness of TCPA.

Fat chance.

as for that guy posting under the name Alsee, who said you're just plain wrong, ignore him.

Either you don't know what you're talking about, or you are astroturfing. If you think I'm wrong then try giving a reason. You are the one who "doesnt get it" if you think saying ignore someone is a valid argument.

You will find that the sort of people who read slashdot tend to focus on facts more than the average public. And my facts are in the Trusted Computing Group's own design specification.

Page 261: Exporting the PRIVKEY from the TMP must not occur

It also has specifications for other keys and data that MUST NOT be exposed outside the TPM.

The fact is that the TCPA system is SPECIFICLY designed to deny the owner of the machine access to his own keys and data. Exactly the design specification needed for DRM.

-

TCPA is a (possibly) good thing. Palladium/DRM, that's the real evil (from the consumer and OSS viewpoints, anyways).

No, that's totally mistaken. TCPA (recently renamed TCG) is essentially identical to Palladium/NGSCB in its basic security goals. TCPA provides for exactly the same kind of features, including the "secure attestation" which is the core requirement for DRM.

This is the feature whereby the TCPA chip (called the TPM) computes a cryptographic hash of the software that loads, and then reports this hash to a remote server. The server can use this to decide if you have loaded software that it will trust, and decide on that basis whether to download content to you. This is precisely how DRM is implemented and facilitated by trusted computing designs, and it is fully documented in the TCPA spec.

The idea that TCPA=good and Palladium=bad is a myth. The systems are fundamentally the same, and they are becoming closer, in that TCPA V2 is probably going to basically be Palladium.

Was TCG formed to specify Digital Rights Management technologies?
No. The focus of TCG is on protecting user data and secrets (keys, passwords, certificates, etc.) from external software attack and theft. This greatly reduces the risk of identity and data theft. It is not TCG's intention to address DRM requirements. As a result, the specifications do not include provisions to prevent owner tampering.

They keep saying this isn't DRM, but it's most of the building blocks you need for DRM. And most of the applications they mention are possible without hardware support via an encrypted filesystem. All you need for Palladium is an OS which refuses to boot without the right user, computer, and boot parameters.

The other thing to note is that they keep stressing RAND (Reasonable And Non-Discriminatory) licenses. Non-discriminatory means every organization pays patent licenses on the same formula. If the formula doesn't contain provisions to allow for open source software, then open source software can't use the standard.