Slashdot Mirror
IBM Trials TCPA Chip Under Linux
keihin writes "From IBM: IBM's Global Security Analysis Lab (GSAL) has done extensive analysis of the Trusted Computing Platform Alliance (TCPA) chip available on some IBM systems. We have the chip running under Linux, and have studied it extensively. In order to clarify a lot of misunderstanding about the chip, we are making available some helpful white papers and open source device drivers for Linux, so that interested people can test and use the chip in an open environment."
The white paper explains why it would be easy to circumvent this chip if you have physical access to it.
DRM it is not.
They've released full GPL source code.
Looks like it could be useful.../p>
It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased. If you read the author's section on DRM in the TCPA rebuttal you get a feeling like you're reading a post on slashdot.
Comments like: "I have no problem with people arguing against DRM; I agree completely." should not be there. It's ok to agree/disagree with DRM, but not in public documents with your employers name on them.
Just my $.02 CAN.
Jason
While perhaps technically inaccurate as to the difference between TCPA and Palladium, I think the spirit of the attacks made against the platform are valid. While yes, perhaps TCPA doesn't directly enable all the horrible things we Slashbots complain about, but the paper is just passing the blame.
IBM says "this has nothing to do with DRM. In fact, it doesn't protect it from owner-tampering so it's not any great DRM replacement." Of course, they don't mention that it's more than likely that in the near future, a version of Windows will take advantage of it. Maybe the OS will encode all recorded music with your public key so it's unplayable on any other machine? Who knows, the possibilites really are limitless.
I wonder how many TCPA computers will be running Windows with Palladium enabled. Neither paper seemed to be catering to a very tech-head audience, so why make needlessly complicated distinctions between TCPA, Palladium, databuses, etc?
We all know that TCPA is meant to be trusted computing but i also see many issues with it. For ex, the integration of DRM into the whole equation by microsoft. I can easily envision them integrating it into their WMP 9 technology and preventing all those without TCPA access to the media. Next is the whole issue of what is "trusted". Is Open Source software trusted? What about compiling a custom kernel. Will that jeopardize the trustedness. Another issue i have is with a possible encrypted hard disk. Will criminals and terrorists sabotage their OS rendering the hdd unreadable?
----
Go canucks, habs, and sens!
Don't get completely up in arms about this is what is trying to say. Then he has an even better quote later:
Ahh...it's great to take stuff outta context.
My Slashdot account is old enough to drink...
read the f-ing article's whitepapers, damnit! It refutes what Lucky Green was saying at Defcon - he (Lucky) gets TCPA confused with Paladam & DRM - making it out to be the boogieman it isn't.
This guy seems so concerned that the TCPA architecture does not *have* to be used for DRM, that he's ignoring the fact that it effectively can be. He talks about how easy it is to circumvent the chip (illegally, thank you DMCA, but moving on) since you have physical access to it. So its 'easy' to circumvent the chip if you have physical access? How easy? Do we need to solder our own computers to retain control of them? What happens when the TCPA architecture is absorbed into the CPU?
The fact remains that the average user has little need of the security features the TCPA is built for. Corporations, governments, organizations with information to keep confidential--sure, why not. But why implement it into consumer level PCs?
- Generate a public/private key pair, the private part never leaves the TCPA chip.. That's kinda nifty, because even if the bad guys get a root compromise on your system they still can't get your private key. They could however use the TCPA system to decrypt messages USING your private key though, until the root compromise was discovered and removed. So, kinda nice, but not a panacea.
- Put critical data (eg the encryption key for an encrypted FS) in a secure register that can't be accessed if "the operating system environment" is changed. I would need to spend some time reading the TCPA specification to understand exactly how they intend for this to work, but I'm dubious about this example. Once this data gets out of the secure environment, it's vulnerable to compromise, so in this case I don't see what this adds over keeping the key in the user's head, for instance.
Additionally, I'd be interested to see how the system copes with software upgrades. It seems like an impossible task to build a system that allows easy software installation but isn't itself vulnerable to accepting a trojan - and because the system's hardware the protocol can't be easily modified to deal with flaws.Presumably IBM has smart people who've considered this and think their solution is workable. In my copious free time maybe I'll download the spec and have a look... :)
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Reading the IBM paper and some of the propoganda against TCPA, I have to express my distaste for those who constantly insist on crying "boycott this", "ban that" whenever something like this is developed without bothering to actually find out what it is. First, there was DRM, which is bad, then Microsoft comes out with Palladium, and all these idiots ASSUME that it's Microsoft rolling over for Hollywood. Well, I don't like Microsoft anymore than the next geek, but Microsoft isn't about to do anything they think would cost them money, and so it appears that Palladium isn't any more of a threat to our freedom than TCPA. Besides, MS just joined an anti-DRM coalition! SO... then we learn about TCPA, and OF COURSE, people immediately begin yapping about how it's another form of DRM and making up "facts" out of whole cloth and doing nothing but confusing the issue.
Activism is a good thing when it HELPS something, but everything is clouded for no good end when people leap to totally uninformed conclusions and then make every activist look like morons along with them. The anti-TCPA people should be ASHAMED of themselves.
The point is, if you can have the private key electronically, then so can any hacker. Maybe they'll put it on a sticker on the chip though. That would be cool.
Vote for Pedro
Exactly. Without access to the actual key pair then the end user does not have control over his own computer. This facilitates DRM and not much else.
Can you show me Palladium that doesn't need TCPA?
Can you show me any great customer demand for TCPA other than Palladium? Are there not other technologies that would solve customers needs without being TCPA? I would think that a card with random number generator and an a cpu dedicated to encryption would solve give you everything TCPA would give to Linux.
My understanding of TCPA is basically that you
can have many people do the digitial signatures. The way I read it is that even if your software
was signed and trusted by the God if a media
company doesn't have God's software on their approved list then you will not be allowed to view their movies or music.
--JayR
The page is really helpful in understanding what TCPA is. However, there is one point that I don't quite understand. The Why TCPA document says:
Fine, I can have data for my Linux partition that is unreadable even if my naughty sister boot a Windows XP on it. Seems something that I might want. Then later in the article, it says:
I really don't understand the "trusted boot" functionality is immune to exactly the same argument. You can seal important data under a PCR. But if you upgrade your kernel, you must unseal all such data, upgrade your kernel, seal it all again. If somehow you forget to do this critical step, or if a hacker succeed in modify a single bit of your OS boot image, your data is lost forever. Is this what the function really supposed to do (the data is so important that losing it forever is better than having somebody else getting hold of it), or that I have some seriously misunderstanding of that portion of the paper?
Have all of you gone insane?
TCPA...DRM...Palladium? What the hell's the difference in the end? I cannot believe that anyone is supporting ANYTHING even remotely resembling any type of DRM or trusted computing scheme.
Have we really lost so much focus that we are willing to give up our RIGHT to do whatever we please with the data that resides on our drives? Even if it's a small concession, the road to hell is walked one small step at a time.
NO. TCPA is bad because the *primary* use for this technology will be DRM. That is the purpose and reason for the 'Trusted Computing Alliance' and for TCPA. Claims to the contrary are dishonest. While David Safford might use TCPA to 'encrypt senstive data' the major business case for this product is DRM. The average consumer of a PC does not encrypt anything and this is unlikely to change with DRM. The fact that the end user is not allowed to know his/her private keys should clue you in!
Sure, no problem:
l
e rger102502.asp?p=0
From Bruce Schneier, " 1. A "trusted" computer does not mean a computer that is trustworthy." and "2. When you think about a secure computer, the first question you should ask is: "Secure for whom?"
http://www.counterpane.com/crypto-gram-0208.htm
While the aforementioned is dealing with Pd and not TCPA they are both implementations of 'Trusted Computing' which is a dishonest term. Basically, the major use case for TCPA is DRM. This fact is readily apparent if you ask yourself a simple question: will the end user have access to his/her private key. The answer with TCPA (as with Pd) is a definitive no!
Also see:
MIT: http://www.technologyreview.com/articles/wo_weinb
EFF: http://www.eff.org/Legal/active_legal.html
Ross Anderson: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
The most obvious use is to authorize my connection to a remote server. If the private key is safely locked away on the chip then I can be assured that only my machine can connect to the remote server with that identity.
Another use would be to sign emails. Again, I can be assured that any email that is signed with a key that is safely locked on the chip could only have been signed by someone using my machine.
In fact, I'm hard pressed to come up with a way that this chip could be used to do DRM under Linux. Can you?
How we know is more important than what we know.
Let me get this straight:
IBM and the hardware manufacturers are saying: "TCPA is just a gun! It can be used for good or evil purposes!"
Microsoft is saying "Palladium is just a bullet! It can be used for good or evil purposes and it stops piracy which is illegal! Do not look behind the curtain marked 'this machine kills linux'!"
The content industries are saying "DRM is another kind of bullet! It can be used for good or evil purposes and it stops piracy which is illegal! What is this 'fair use' you speak of?"
The whole bunch of them are saying "We are forming a club. All club members will communicate with secret decoder rings which you are perfectly free not to use however don't expect to be able to join the club without using them!"
I can already authenticate with SSL and secure encryption. TCPA will not change this. TCPA will not prevent trojans/virus. Read the FAQ. As for whom do you trust I am far from the only person who has a problem with TCPA/Pd/DRM:
l
http://www.counterpane.com/crypto-gram-0208.htm
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
There are 3 ACs all saying "read" the paper. The paper does not refute the points in the defcon talk lets take the first example from the paper. This "refutation" relies on shifting the topic away from the import part.
The terms copy protection and DRM do not appear anywhere on www.trustedpc.org. They were not the main business objectives, and the resultant chip is not
particularly suited to DRM, being poorly defended against owner tampering. The main goals are
to secure the user's private keys and encrypted data against external software attack.
He is absolutely correct nowhere in the TCPA specification is DRM mentioned. Neither however is his "main goal". Further he obscures the issue by focusing on the wrong part of the spec. Good quality encryption is not what makes DRM possible; good quality encryption combined with verifying the status of the machine at boot OTOH does. That is what makes DRM possible is the fact the OS can tell whether its running inside a VM or not so the trusted component of the OS (the tor/nub) can then confidentally tell applications that they are running in a secure environment. Without this Microsoft could have all the DRM they wanted; you just run the OS inside a debugger and pull the license keys right out of the application's memory space.
Further he even agrees with this, he mentions this in a positive light as "preventing viruses from getting sensitive information" but it can just as easily prevent any other "unauthorized" applications getting their hands on sensitive information.
He does refute the tamper resistant but in terms of DRM that's irrelevent.
The problem is they aren't being honest here. Guns may be a tool to let you shoot deer and not people but that doesn't mean they work perfectly well for either purpose. Similarly TCPA works perfectly well to either secure data for the user or to secure data from the user.
All he/she has to do is use your hardware to access the server.
For most people, all he/she has to do right now is use your software. For all except for the very paranoid, keychains are hanging out there right on the hard drive, open to every Tom, Dick and Harry that bothers to walk by.
But even then, what does access to the private key really give you? SSH does nothing as far as actually authenticating you on the server - it only encrypts the data as it passes to and from the system. The remote server does the actual challenge / response. Somebody might be able to pretend that they are you, but without the password, they are up the proverbial creek.
Really, this chip is no less resistant to physical acess than the software solution. Computer security isn't just about a password. You wouldn't leave your server room unlocked would you? Why would you treat your workstation any differently?
Do you have Linux and a DotPal? Click here now!
That is it was designed to encourage the free sharing of information in a communal fashion.
Thomas Jefferson (paraphrased): "If men were angels there would be no need for government, but since they aren't, there is."
It would be really nice if people didn't steal. But they do. Therefore I fully support the right of anyone to aquire and use the strongest locks possible. The only way I know of preventing people from stealing my financial, medical and personal information from my computer is to lock it up. If TCPA make this easy to do without giving up rights to third parties, then the prudent will use it.
A Government Is a Body of People, Usually Notably Ungoverned
If there is any possible way for application software to be able to determine with certainty, that an actual hardware TCPA chip is present instead of software emulation, then I smell a rat.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
TCPA chips sure looks like a bloody dongle. Identical functionality. I simply do not see any legitimate use other than DRM/licensing (and spare me the encryption speedups).
Geeze, I may have risen to the bait of a troll, but that hardly makes me a troll.
Let's review: an article is posted pointing to white papers explaining what TCPA is, and detailing how it's clearly useless for DRM. Kevitt responds, "TCPA...DRM...Palladium? What the hell's the difference in the end?" If he'd read the white papers, he'd know the answer to that question, but somehow, he gets modded "insightful". I point out one of the key reasons that TCPA will be all-but-useless for DRM, quoting one of the white papers, and I get modded as a troll. Sheesh!
Let me just say, as a member of the Debian project, I'm sure that Debian will have support for IBM's TCPA-enabled systems before long. Not because we want to prevent you from doing whatever you want with your system, but because we want to allow others to prevent you from doing what you want with their systems.
The key never leaves the chip. No process at all ever has access to the key. The chip does the decryption itself as a black box.
Well, I'll state the obvious and say that I consider it an essential feature to be able to copy out (securely) any and all keys the chip has generated, and if the chip does not have that feature then I certainly must question the motives of the designer. There, I said it would be obvious.
Have you got your LWN subscription yet?
From the whitepaper:
"Protection of sensitive authentication data, such as passwords will become critical for
electronic business to succeed."
Passwords are *user* specific things, not machine specific things.
Storing them in a vault on a single machine means they are stored in the wrong place.
This is a lie.
From the rebuttal whitepaper
-----------
"When you boot up your PC, Fritz [the TCPA chip] takes charge. He checks that the
boot ROM is as expected, executes it, measures the state of the machine; then checks
the first part of the operating system, loads and executes it, checks the state of the
machine; and so on."
This is completely false. The TCPA chip doesn't execute anything. It accepts request data, and replies with response data. In the IBM version,
TCPA sits on the LPC bus, using I/O mapped registers. The TCPA chip does not and
cannot control execution!
-------
This is a misdirection, the original comment was about the TCPA system in its entirity, the response talks only about the chip part of the TCPA.
Here's another misdirection, again he is rebutting a valid comment.
-------
The comment he is rebutting:
"You might prefer not to have to worry about viruses, but neither TCPA nor
Palladium will fix that: viruses exploit the way software applications (such as
Microsoft Office and Outlook) use scripting."
His rebuttal:
While TCPA cannot prevent stupidity
in software applications, it definitely can control the resulting damage. In particular,
no virus can steal a TCPA protected private key.
How can it, if the private key is
generated in the chip, stored on the chip, and never leaves the chip?
Again the comment he is rebutting:
" Seen in these terms, TCPA and Palladium do not so much provide security for the
user as for the PC vendor, the software supplier, and the content industry. They do
not add value for the user, but destroy it."
And his rebuttal of this:
Personally, I find the ability to protect my
private keys, and to protect my encrypted data very important and very valuable.
-------
The misdirection here is in the last paragraph. The keys he is talking about are not *your* keys. They are not specific to *you* you do not carry them around from PC to PC and you do not have access to them.
Your keys (things like your passwords and PGP keyring files) can be stolen when they are entered in the computer just as before.
From the whitepaper, again there is the confusion between *me* and *my computer*:
------
"Protection of user authentication keys
Given the large number of vulnerabilities in client system, and the trend of hackers to
target client machines looking for passwords, it is vital to provide some way to protect
sensitive authentication information such as passwords and private keys. TCPA provides
exactly this protection.
A user can generate an RSA public/private key pair on the TCPA chip. The private key
can be configured never to leave the chip."...
-----
Right, stop right there. If my private key never leaves the chip what use is it to me? It identifies my computer not me.
Whoever is at my computer, if they intercepted my login has all *my* private keys and for all purposes *is* me.
I meanwhile can move from computer to computer, but I cannot identify myself, because those private keys are on my home computer and can never move.
IBM is doing pretty much what every other business does, downplaying the bad and promoting the good sides of their product.
Soon, you will have TCPA/Media Center PCs. I'm pretty damn sure they *will* contain an endorsement key (that Microsoft will have, probably in the licencing agreement for making them), that you can not gain access to (except for a hardware hack), and that you can not emulate. This key will verify your BIOS, your Windows Palladium Media Center, and your DRM-crippled Windows Media Player. Or maybe they'll stage a few "licenced" players to create the illusion of choice.
And in the next level, I've heard that TCPA will be internal to the processor. Goodbye even to the hardware hack.
Saying the TCPA of the IBM machines doesn't have an endorsement key is saying, "yes, we're pointing this assault rifle at your consumer rights, but we haven't loaded it yet". Then when people "have to" have an endorsement key to get programs working, they can blame it on consumer demand.
Kjella
Live today, because you never know what tomorrow brings
Exactly why do I _want_ these chip[s] on my new mainboards?
;o)
It sucks case-space, and waste's Juice. (v/r=i)
I _want_ to add chip[s] to my mainboards that have things like
a TB of memory, or say a "Spare CPU slot (tm)" (sic)
In fact why not just add another CPU?!
If the white paper's _intentions_ are to be believed as stated,
this eFFing "Kradical new Chipp0r"(tm) does not need to BE
physically soldered onto the "eFFing mainboard" (tm)
They can make it a self contained appliance that plugs into the wall,
and plugs into the box (via serial, parallel, or usb)
Then when *I* _want_ to do some eCommerce or some 31134
crypto to my friends then I can plug the little bugger in,
do my Biz, then disconnect0r the SOB!
But noooooooooooooo!? that's not the True Evil Intentions.
They *HAVE* to put this BOFH on the MB's now,
cause they know folks do not take change easilly,
So they desensitize you to this crap now.
IBM, test away, research away,
hopefully someone will break it in the research lab
*BEFORE* they roll the crap out the door.
Maybe the Genius's at SuSE or United Linux
can smoke-check that lil-bugger and prove that it's flawed.
But I digress, what a whoring plethora of bullcrap TCPA is.
I think I meant plethora of whoring bullcrap.
Love Music? Got a Band? Are you a Label? http://garageradio.com
The keys in TCPA hardware are not "your" keys at all. When you talk about "somebody's keys" you should mean their personal keys which they use to identify themselves, e.g., to sign their email, to login, etc.
The keys you are talking about are the keys inside and belonging to the TCPA-enabled PC, settop box, or other electronic device. These keys are used to control functions specific to that particular piece of hardware.
If the keys in TCPA hardware were really "your" keys, you could copy them whenever you like and take them with you to whichever device you happened to be sitting in front of. But you couldn't do that with TCPA because you're not allowed to. TCPA means parts of your PC can get locked down permanently.
With TCPA you are no longer free to upgrade your PC when you like, how you like. You lose your existing privileges.
TCPA really means lockdown enabler.
Why oil price increase equals economic trouble (Score: Interesti