Slashdot Mirror
Trusted Computing Group Formed
An anonymous reader writes "How does it come that the formation of the Trusted Computing Group goes unnoticed at /.? On Wednesday, heise had the story. At last, we will get `easily-accessible specifications for trusted computing standards that will ultimately let people work, conduct transactions, and use computing devices with a new level of confidence' ..."
I hope that's mean't to be a joke, mate.
Apple is buying the record company - not the other way round.
Promoters
* AMD
* Hewlett-Packard
* IBM
* Intel Corporation
* Microsoft
Contributors
* Atmel
* Infineon
* National Semiconductor
* Nokia
* Philips
* Phoenix
* Sony
* STMicroelectronics
* VeriSign, Inc.
* Wave Systems
Adopters
List available shortly.
ie, when there are any
Mandatory babelfish translation
Or a zdnet article
.ACMD setaloiv siht gnidaeR
I would have just modded you down, but I'm tired of this kind of ignorance. There are multiple forms of trusted computing, some innocent, others questionable. Since 2000 IBM has offered an (optional) ESS (Electronic Security Subsystem) in their Thinkpads and Netvistas. All it is is an embedded smart card with a keypair and some crypto functions. It's a passive device...if you feal like encrypting something then you have a convenient mechanism with which to do it. Before that, in 1998, SISTex offered the Assure EC networking device that merely served as a secure interface between an IBM compatible workstation software, local resources, and the network.
TCPA specifies a similar device (the Trusted Platform Module), only it also has a few registers used to store and report security integrity metrics as well. Again, a totally passive device. From what I gather, the idea is that the BIOS and/or OS will use these registers to store the version of software, virus checkers, etc. Another system can query these registers to see if you have what they're looking for in the way of security (I wouldn't want to accept E-mail from a server that, say, wasn't patched for Code Red).
So there's a key stored in your TPM. Worried about privacy? Don't be. That key is never used except to sign other keys, alias IDs, that you use temporarily to conduct transactions. Like getting an alias for your credit card number when buying something online.
All of these are passive devices that you, the operating system, or third party apps may or may not use. None of these technologies have functions that allow the conditional execution of code based on security metrics. That is an abuse that must be built into the OS, which can be done today in software.
Then there's Palladium, which is *not* TCPA. It's not even based on the TCPA. It's similar, but it consists of both hardware and software components (Windows) and is potentially much more sinister. Palladium's only member is Microsoft, and I don't really trust that. But I don't have to, because there are now ubiquitous, open standards (TCPA) that will likely take favor.
We need trusted computing. It's coming. You can help yourselves by at least being informed:
"The Need for TCPA" (David Safford, IBM)
"Clarifying Misinformation on the TCPA" (David Safford, IBM)
It's just the standard usage of the word "trusted" in the security community, and the same usage it has been for decades. No need for the tinfoil hats.
A "trusted" system is, ironically, the one that can violate your security policy. It's "trusted" only because it has to be. If that component couldn't violate your policies, you wouldn't have to trust it, and thus it wouldn't be called a "trusted system", now would it?
From a security point of view, you don't want to be forced to trust any more components that you must, because every one is a potential failure point. The ideally secure system is one in which there's no trust necessary, because security is guaranteed. Some people like to portray this as some sort of Orwellian doublespeak, but if you stop to think about it, you'll see that the definition of this bit of jargon makes perfect sense, even if -- like a lot of jargon -- the meaning of the word isn't quite what you might think from the non-jargon meaning.
Trust works both ways. Slashdot being what it is, you'll only ever read about the potential abuses of evil corporations controlling your very own dearer-than-life computer against your will. However, the very same mechanism is the one that you need to keep the evil corporations off your computer. A "trusted computing platform" enables the ability to trust, and, like all technology, is neutral in that ability.
The question that needs to be asked is "who is trusting whom to do what?". And there are multiple answers to that question.
TC is useful to the RIAAs of the world, because they don't trust you the user not to violate their copyright on their IP. So they want a system where they don't _have_ to trust the user not to do so. Right now, they have to trust the users -- and the users, as a group, are not trustworthy. (That point is amply demonstrated by the wide availability of warez and MP3s that exist in violation of copyright. It doesn't matter whether you think it ought to be that way or not, or whether or not you think any real harm is being done; that's simply the way that it currently is, by simple observation.) So, if you can't trust the users and aren't willing to suffer the consequences of them being untrustworthy, then you need to move your boundary of trust at least one step further back -- to the computer. You can then have a paranoid MP3 file that can be decrypted because it's sure it's only in the presence of software that won't copy it.
TC is also useful to the users and system owners of the world. It would be nice to have a system where you could trust some code built into a website not to steal all your passwords. This is the flip side of the question, because now it's you, the user, who doesn't trust the evil corporation running that web site not to plunder your secret personal information if you let them onto your computer. Currently, you have to trust them, and currently, they aren't all trustworthy. So, just as with the RIAA, you can either live with the consequences (having your privacy invaded, your passwords stolen, whatever), or you can try to solve the problem by moving the boundary of trust on notch back. If your password-storage software refuses to decrypt any passwords in the presence of any untrusted code -- like that secret plundering function in that web site you don't know about --
then you've got a safe wall behind which to hide. You can then have a paranoid password-storage system that only decrypts passwords because it's sure its in the presense of software that won't copy them.
Or to consider another currently faddish example, consider grid computing. People have this vision of using all those wasted cycles on the 'Net to good effect. Let's say such a system really got built, and, since it's supposed to be more than a toy, you get paid for making your computer cycles available. There's some incentive for you to join the grid that way. However, before Lawrence Livermore starts running nuclear weapons simulations on the Grid or the ban
I would have just modded you down, but I'm tired of this kind of ignorance...
"The Need for TCPA" (David Safford, IBM) [ibm.com]
"Clarifying Misinformation on the TCPA" (David Safford, IBM)
I have read both of those documents by David Safford. They certianly do counter many false arguments against TCPA, but they do NOT in fact counter valid criticism of TCPA! His defence of TCPA completely fails. The last two paragraphs of my second E-mail exactly why.
I actually had a brief E-mail correspondence with David Safford. He replied to my first E-mail, and failed to respond to my second E-mail. Here is the exchange:
----------
ME: TCPA - simple solution to eliminating opposition
I just finished reading "Why TCPA" and "TCPA Misinformation Rebuttal". There is a simple way to eliminate virtually all of the opposition to TCPA.
None of the benefits of "Why TCPA" rely on security against the owner of the machine. The "TCPA Misinformation Rebuttal" claims that TCPA is not designed to to be secure against physical access. Every criticism of TCPA that I know of is based on fact that the owner of the machine is DENIED access to contents of the TCPA chip.
The solution should be obvious, include a physical switch to enable access to the contents of the TCPA chip. Perhaps a button that needs to be held down during power-up. This gives the critics everything they want and it in no way interferes with the claimed purposes of TCPA - it's not supposed to be secure against physical access anyway!
Any resistance to including such a switch can only be proof that the critics are right. Maybe I'm cynical, but I don't think the TCPA alliance will ever approve it. I believe the driving force behind TCPA is to make computers "secure" AGAINST their owners and so corporations can make PC's "trustworthy" tools against the "untrusted" owners.
I'd love to be proven wrong. If TCPA comes with an "owner override switch" I'll be the first person to run out and buy it.
----------
Savid Spafford's reply:
It is not intended to be secure against owner authorized physical access (ie access from someone who knows the pin for a given TCPA protected key.) We certainly do want to defend against theft of a laptop. We don't want to had over your encrypted filesystem master key to someone who has stolen your machine.
TCPA does have a TPM_TAKE_OWNERSHIP command, which, given physical access to the machine, resets the chip, deleting all user level keys.
Thus the physical owner of the machine can take full control, but cannot see any secrets from any prior owner.
dave safford
----------
Me:
Thanks for your reply.
"We certainly do want to defend against theft of a laptop."
Contradiction.
Your TCPA Rebuttal said "TCPA chips have not been designed to resist local hardware attack". If it can protect a stolen laptop then tamper resistance is not "pure speculation", it's already here. It voids the claim "show[ing] that TCPA was not designed for DRM" and instead shows that TCPA "requires...you don't trust the owner".
It is not intended to be secure against owner authorized physical access (ie access from someone who knows the pin for a given TCPA protected key.)
Great! If you think my idea for a mere switch to enable access was too simplistic then feel free to require the owner to supply a PIN to enable the export of the unencrypted keys. Of course, the owner needs to be able to know the PIN and to hand it to the TPM at will. A repeat TAKE_OWNERSHIP would still wipe out old keys.
And it can still be secure against thieves because they don't have the owner PIN.
Your TCPA rebuttal was informative and dispelled some false criticisms, but it did not address the real source of the criticisms. Between your email and "Why TCPA" and the TCPA website I still haven't seen a single justification to deny an owner access to his keys. To
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.