IBM Trials TCPA Chip Under Linux 442
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."
Great news (Score:2, Flamebait)
Check out *nix.org [qhcf.net], a dynamic, informative, and fun portal for fans of BSD, Linux, OS X, & Solaris!
Why I didn't know IBM was involved (Score:5, Informative)
However, there's a full list here [notcpa.org].
Check out *nix.org [qhcf.net], a dynamic, informative, and fun portal for fans of BSD, Linux, OS X, & Solaris!
Re:Great news (Score:5, Informative)
I'm honestly not sure what you mean here, but from your
So tell me -- did you read the whitepapers mentioned in the article? Or are you simply going by the FUD presented at notcpa.org?
Seriously, whether you are for or against the TCPA, read the white-papers IBM put together. Note that it has nothing to do with DRM or Palladium, and the author of one of the papers says "DRM is stupid, but that's another paper".
Or go read the specifications yourself.
In short:
1) The TCPA is NOT Palladium
2) It does NOT protect against physical tampering (thus not being well suited for DRM usage)
3) It doesn't use any cert authority or "code signing" or anything like that. This again is not Palladium, and this is not the XBox.
It really is about helping to protect you against crackers or viruses/worms from obtaining your private keys (be it SSH, SSL, PGP, or whatever future application comes up).
And IMO it is good to see IBM on-board. They've already written GPL drivers for Linux, and are showing massive support from the very beginning -- something you rarely see with *any* new specification or proposed standards. Any Linux user should be glad IBM is on-board as well.
Re:Great news (Score:3, Interesting)
Damn right. I assume you saw the articles earlier this week that IBM is claiming I think $1.5 billion in Linux based revenue, and HP is claiming $2.0 billion? Linux Brings In Big Bucks [com.com] That kind of money can support some pretty serious development. It's not hard to imagine that Linux will end up with the premier set of software tools which does useful things with TCPA. Sure, maybe RedHat isn't bringing in the revenue they might like, but it sounds like free software as a whole is doing pretty damn well.
Re:Linux vs. Linux users (Score:5, Insightful)
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.
just remember.... (Score:4, Interesting)
Microsoft's TCPA == DRM
Re:just remember.... (Score:3, Interesting)
Indeed, the vast majority of exploits don't break the existing hardware or kernel security directly. They take over some other application via a hole in its internal logic, and then use its (possibly very high) privileges. This does not require breaking even the existing OS/CPU security model, much less some new layer.
Granted, TCPA and/or Palladium will support some kind of "tripwire on steroids" feature to scan all of your critical system files. I would imagine, however, that the bad guys would just shift strategy. Rather than overwriting the system files, they could stick to memory resident things. To cover reboots, they could just embed a macro somewhere in the user files that re-hacks the system the same way they got in the first time.
This is NOT about digital rights management (Score:5, Informative)
Rather, it's primarily about protecting a user's private keys and facilitating (through hardware acceleration) a serious increase in the use of encryption to promote security and privacy.
Re:This is NOT about digital rights management-II (Score:2, Interesting)
In other words. It's no different than buying an add-on board with a crypto processor. Has anyone found out how much this will all cost?
TCPA is: LOCK-down, LOCK-out, LOCK-up restrictions (Score:3, Insightful)
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.
Re:This is NOT about digital rights management (Score:2)
Whenever anyone claims this always ask the following question: does the owner of the chip (i.e. the owner of the computer in which the chip resides) have full access to all keys embedded within the chip? If not, why not, if not to facilitate DRM?
Re:This is NOT about digital rights management (Score:4, Informative)
From reading the PDF, the answer is sorta. You can ask the chip to generate a new key pair, and then you can later enable/disable/delete that key pair whenever you want. But the private keys don't ever leave the chip.
Re:This is NOT about digital rights management (Score:4, Insightful)
Re:This is NOT about digital rights management (Score:2)
You dont make sense (Score:5, Insightful)
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?
Re:You dont make sense (Score:3, Insightful)
Re:normal users of Linux? (Score:3, Interesting)
I take offense to your statement that no-one should ever make hardware that targets the Linux market because the "majority of users don't need it".
Re:normal users of Linux? (Score:4, Informative)
"The TCPA specifications center on two main areas: trusted reporting and public key infrastructure (PKI). The TCPA reporting guidelines create profiles of a machine's security settings as the machine boots. Ward says content providers such as Bloomberg or Hoover's may take advantage of this feature to ensure users do not redistribute content."
I have read enough about TCPA and Palladium to know that these are DRM enabling technologies. I also know that members of the TCPA and BSA are very interested in providing DRM. This is obvious and if you'd read around you would see the same thing.
Re:You dont make sense (Score:5, Informative)
Yes you would do it exactly the same way you do it under windows.
Sony has a nub (say a version of the Linux kernel) which they trust. You can download these kernels from Sony and full compliance with the GPL Sony release full source. Any change to the kernel changes the signature of the nub and thus makes it untrusted by Sony. So in other words Sony can now sign off on your OS kernel.
Because of the TCPA public key they can also lock stuff to your machine. And they can combine these, that is they can give you content which can only be used on your machine running and only when running particular kernel.
But they can go even further than this. The kernel supports trust and they can release a media player which will ask the kernel if the application is running inside a virtual environment or directly against the trusted kernel. Since the kernel supports trust it tells the truth, since the you can't change the kernel without changing the signature on the nub you can't make a kernel that lies.
That's DRM.
And everything I've mentioned can be 100% open source GPL and it will work exactly the same.
Re:This is NOT about digital rights management (Score:5, Interesting)
Public key cryptography works best if the user can apply the key, but cannot leak the key no matter what.
It would be rather different if the private key on the device was known to some content provider, but this setup couldn't be used for DRM even if you tried to. The closest thing would be a content provider giving you a file that only you could read; but you can still do whatever you want with it once you read it.
Private / Public key (Score:3, Informative)
They don't need your private key; they need your public key. All they need to know is that the private key is unique to your machine. Here is why:
1) I give you a file encrypted using the public key from a trusted application running under a trusted nub/tor on your machine using a valid TCPA.
2) because the tor/nub key is based on your TCPA key its only usable on your machine's trusted environment and not anyone else's even if they have exactly the same software
3) because the tor/nub key is based on the tor/nub its only usable when running under the same tor/nub which means I can confirm that the OS isn't running on a virtual machine. That means I can trust the OS.
4) Because of the trusted OS I can control what applications have the last part of the key and those can confirm with the OS that they are running in a trusted mode.
That's how DRM works. You bootstrap trust. As long as you the CPU won't let emulate a call to the TCPA chip and the TCPA chip generates the keys for the tor/nub you have a signed hardware/software environment.
Re:This is NOT about digital rights management (Score:3, Interesting)
Re:This is NOT about digital rights management (Score:2)
IBM is very involved in the fight to restrict consumers rights and TCPA is the bridge technology they wish to use for DRM. Just because IBM has been good to the linux community is not a good enough rational for letting them off the hook when it comes to TCPA and DRM.
For all of you who don't get this then understand that when IBM and Microsoft talk about 'Security' they are talking about security for the publisher and *not* the owner of the computer.
Re:This is NOT about digital rights management (Score:3, Insightful)
Re:This is NOT about digital rights management (Score:3, Insightful)
http://www.counterpane.com/crypto-gram-0208.htm
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
Re:This is NOT about digital rights management (Score:3, Insightful)
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
Re:This is NOT about digital rights management (Score:5, Informative)
Re:This is NOT about digital rights management (Score:4, Informative)
DRM, DRM run for the hills! (Score:4, Funny)
Aw hell, I might as well stick to windows.
I much much rather have TCPA then pallidium (Score:5, Interesting)
I like the extra random number generator chip as well as the encyption chip. I can imagine it would help e-commerce greatly and can be used for programs that require random number generation. Also hardware does not need to be modified. Only the motherboard. Microsoft wants each component to trust each and have it encyrpt everything. Its scary because its so proprietary. In the Xbox even the intel pentiumIII chip encyrpts and decypts data. Infact it will not run any assembly code unsigned. Spooky.
I hope IBM horries up and convinces other OEM's to use TCPA before they decide on using pallidium. Also IBM has been selling TCPA systems for close to 2 years now. SO yes they are not a threat to freedom or a drm sollution backed by hollwood.
Re:I much much rather have TCPA then pallidium (Score:4, Interesting)
Honestly, how many applications are going to use SSL encryption so often that the CPU is incapable of performing the additional grunt work? Even if every website on the Internet was SSL encrypted, your old 233Mhz Pentium still has a shitload of spare cycles to throw at en/decoding the data streams. The only systems that really benefit from the hardware encoder/decoder are secure webservers. The ability to offload that little bit of processing gives them the ability to handle a few more requests per second.
As for the secure storage of SSL keys. I can't wait until my mainboard dies, and I can't get my keys off the damn chip. I suppose you could buy another identical board and attempt to swap the chips, but I'll warn you right now that surface mount soldering by hand is an extreme bitch.
And it really isn't like you're going to get that much extra security out of the deal. So your keys aren't on the harddrive anymore. So now people can't get your keys by stealing your tape backups anymore. What happens when you have a fire? Hope you have a really good memory and a nice hex editor to retype the keys with. And what is to stop any processes at all from reading all the keys out and emailing them to a hotmail account? Only allow priviledged processes to access the chip? How do you define with process is priviledged?
Sorry, but I'll stick to the expansion cards. At least if something bad happens I can replace those relatively cheaply and easily.
Re:I much much rather have TCPA then pallidium (Score:3, Informative)
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.
Re:I much much rather have TCPA then pallidium (Score:3, Insightful)
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.
At least read some of it before commenting... (Score:5, Insightful)
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>
Re:At least read some of it before commenting... (Score:2)
IBM is being dishonest when they suggest that TCPA is security for the end user. It is not and they are actively working with the big media companies to come up with DRM. TCPA is part and parcel of this effort. Any suggestion otherwise is just putting your head in the sand.
Whitepaper biased (Score:3, Insightful)
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
Re:Whitepaper biased (Score:2)
OTOH perhaps it's good to be unusually open about it in this case... at least *some* of the well-rounded and intelligent people who hear about it will read that far, and discover it's not about DRM.
Re:Whitepaper biased (Score:3, Insightful)
I agree that the whitepapers seemed to use the phraze "I personally" a bit too much (one calls DRM "stupid"!) -- but to me it seems like they wanted to quickly put something together to help inform the Linux community (and possibly the Slashdot community in particular) of what TCPA is all about.
I'm glad they released something to help curb all the negative FUD that I keep seeing. It still doesn't seem to be helping much, since over half the comments here are anti-TCPA FUD themselves (and most of the "facts" I'm seeing in this story's comments are in fact addressed in the rebuttal document linked in the story).
The tactic (Score:3, Interesting)
1) Hardware companies "just provide" TCPA
2) OS companies "just provide" the capacity for trusted apps
3) Trusted ap makes "just provide" the ability for people to send you data securely
4) Digital content companies are just taking advantage of existing technology to prevent unauthorized redistribution
5) Fair usage doesn't exist anymore in practice
The fact that 1 enables 2 enables 3 enables 4 enables 5 is supposed to escape the public. So when we have a world were fair use has been completely repealed there isn't going to be anyone to blame.
Re:Whitepaper biased (Score:2)
I have to disagree. We seem to have taken two different interpretations, but the author in fact did state that he is against DRM, and in one of the papers he specifically says:
My personal opinion (not speaking for IBM) is that
DRM is stupid, because it can never be effective[6,7], and it takes away existing rights of the consumer. But
this is not the place for that debate.
But I believe this document was targeted at the Linux community (perhaps even the
My response was probably more long-winded than it needed to be... but hopefully it makes sense
Passing the blame. (Score:4, Insightful)
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?
Re:Passing the blame. (Score:5, Insightful)
In palladium each component must be certified and it uses a trust relationship to prevent tampering. To me palladium sounds like a way for Microsoft to make sure you can not upgrade more then afew components at a time without paying the piper but who knows. It sounds more stict and anti-user. Also rumours have it that Bill Gates wants to use palladium as a way to stomp out piracy in asia and they also view OOS as the bigggest competitor since os/2. Scary.
TCPA was formed to secure and enhance e-commerce as well as secure corporate desktops. In this day and age the security is greatly needed.
If hollywood wines and complains and the hollings bill passes, I prefer TCPA anyday and its a more open and industry standard solution. Linux will be supported since any thid party can sign it and no company is the "official" gatekeeper. Think SSL. The gatekeeper argument is the scariest and as long as it stays open then its not a problem. IBM has invested billions in Linux and wants it to susceed.
Re:Passing the blame. (Score:2)
Why does an OS need TCPA to do this? In fact, IIRC Windows Media Player does something like this now, by default even. TCPA doesn't enable this (or more correctly, absense of TCPA doesn't make this impossible).
TCPA is basically this:
- Generates key pairs (a fast DSP)
- Stores key pairs
- Performs encryption/decryption, only if everything is okay
The "everything is okay" part simply means that the BIOS hasn't been messed with, and the OS is in a known state. Yes, this will prevent (say) using Linux to decrypt data that you encrypted while in Windows -- but it also goes the other way (data encrypted under Linux can't be decrypted under Windows). That's the beauty of it; an attacker can't just pop a boot disk in and try to read your data.
I think the confusion is that the term "Trusted Computing" sounds a lot like what we all heard about Palladium -- but it is NOT the same thing. Palladium asks for a lot more than TCPA, and at the present Palladium isn't designed for TCPA. They want (and have patents on) their own hardware implemented, as well as CPU hacks, and other junk.
TCPA isn't even a part of the Palladium picture.
Other Possible Issues ~ Misuse (Score:2, Insightful)
Re:Other Possible Issues ~ Misuse (Score:2)
TCPA isn't needed for this, and in fact doesn't really do much to help this type of DRM. How can you encode files on your machine, that require a chip on my motherboard -- well, to do what, exactly?
---
Imagine a cracker breaks into your machine one way or another. He can currently find your PGP key, your SSH keys, etc, very easily.
Now imagine if those keys were instead generated and stored on a special chip on the motherboard. The chip itself handles the decryption, so the key never needs to leave the chip. Even further, if something changed in the environment (specific things that might indicate a virus, worm, or other breach), the chip will not decrypt the data.
Wouldn't that be pretty damned secure? Well, basically that is TCPA.
TCPA is not particularly well suited to DRM applications, as this was not its intent.
what about the OS securing features (Score:4, Interesting)
Also, regardless of the author's opinion, a chip that enables DRM even sub-optimally is not the friend of the people.
Re:what about the OS securing features (Score:2)
Funny, I got this from the paper:
The TCPA chip does not and cannot control execution!
Which means it will NOT prevent any operating system from booting. It will prevent an operating system environment from decrypting data with the chip if it's not the OS that was used when the data was encrypted -- but that works in both (all) directions.
Plus, of course the features offered by the chip can be disabled in the BIOS.
Some nice quotes from the misinfo rebuttal (Score:5, Insightful)
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.
Re:Some nice quotes from the misinfo rebuttal (Score:2)
TCPA talk at Defcon X (Score:2, Interesting)
"This tamper-resistant Trusted Platform Module (TPM) will enable operating system and application vendors to ensure that the owner of the motherboard will never again be able to copy data which the media corporations or members of the TCPA don't wish to see copied, or to utilize the TCPA's software applications without pay."
Sounds like DRM to me.
Re:TCPA talk at Defcon X (Score:2, Insightful)
TCPA talk at Defcon X (Score:2)
Re:TCPA talk at Defcon X (Score:3, Insightful)
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.
Quick notes for spastic no-read replies: (Score:5, Informative)
2) The specs are open. There is a gratis GPLd demonstration driver/API for linux.
3) (My impression) is that it helps solve certain security chicken and egg problemswhen you want to do things like mount an encrypted hard disk, but not want to store the decryption key in memory.
4) Primary advertised use: for signing and verifying your OWN code, i.e. to protect yourself from root kits.
Re:Quick notes for spastic no-read replies: (Score:2)
Gunna be a big score for Gentoo!
Re:Quick notes for spastic no-read replies: (Score:2)
... tsk (Score:2)
It also provides a way to do things like verification hashes or cert checking outside the CPU. You can stick a private certificate in it and sign/encrypt stuff all the live long day without worry that your system gets rooted and your private key or ipsec.secerts compromised.
The hacker would have to come into the server room and remove the chip, at which point they have a slim chance of opening it up and getting the key out (...its not hardened). But if they can do that, then you're screwed anyway. (See the previous article on AT&T and tumbler lock vulnerabilities)
Thats basically what it does. Also, a builtin RNG in case you don't have an i810 chipset.
Even with TCPA... (Score:4, Funny)
(in russian - documentation - use babelfish to
read - at http://junix.kzn.ru/)
Big claims... (Score:4, Insightful)
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... :)
Re:Big claims... (Score:2, Insightful)
Moronic knee-jerk reactions... (Score:4, Insightful)
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.
Re:Moronic knee-jerk reactions... (Score:4, Interesting)
Only because the the way DRM is being pushed, puts them out of control. MS wants you to have a house full of computers, all of which are connected to them. It is part of the 1000 year vision.
In 95 or 96 Bill Gates was at a smartcard conference.
At that time he said he wanted a smart card reader in every computer, and for it to be verified by MS before allowing any purchases. The only problem was there was no was to verify what system is was coming from.
Sure, on paper, TCPA is a good thing, with many practical uses. However, look at how any industry that makes money doing something digital(whether it is CDs or OS) blames all there woes on piracy.
That is the leverage/excuse MS will use to "embrace and extend" the TCPA technology.
MS is not rolling over for hollywood, and nevcer will. What they will do is utilize Palladium, with TCPA, so they can charge the entertainment companies for a "verification" service. Of course any OS they can't "trust" will be excluded.
The question is, will the backlash be great enough for it to fail? If it was put into place right now, the backlash would be minimal, because the number of non MS desktops user is very small, and they don't make much money from those users anyways.
It is the mission of almost every corporation to make as much of a market as possible.
You should be ASHAMED for not learning from history, and not using you imagination on how this can be used against you.
TCPA is to DRM as Bullets are to a Gun, neccessary.
IBM (Score:2)
Re:IBM (Score:3, Insightful)
People please remember (Score:5, Funny)
Dell to Microsoft: Fuck off if word gets out that you cannot copy stuff on one of our machines we are certainly ruined.
Microsoft to Dell: Do it or else
Dell to Microsoft: Fuck you we are shipping Lindows
Better Yet (Score:2)
Need clarifications (Score:2, Insightful)
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?
Wake up! (Score:3, Insightful)
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.
moderators on crack warning! (Score:3, Insightful)
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.
Hardware protection of private keys (Score:4, Interesting)
A proposed solution to this problem is to encode the private key with a passphrase. Unfortunately, almost all the systems that do this use software to read and check the passphrase, making it simple to intercept.
Re:Hardware protection of private keys (Score:3, Insightful)
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?
TCPA only a single component of Palladium (Score:3, Informative)
Imagine you already have this TCPA processor on your board. You download the newest RIAA-approved secure media player and start downloading tons of songs. The media player wants to use your TCPA processor to encrypt the songs while you're downloading them so only your PC can play them. Evil, yes, but it can be done TODAY on a PC without a dedicated TCPA processor.
The application is happily encrypting its audio, however, in the background you're running an application that acts as a virtual soundcard and you're capturing open, unencrypted audio and saving THAT to your hard drive as well. So much for TCPA.
This is where Palladium comes in, it would not allow you to run a virtual sound card driver. Palladium is about a trusted secure enviorment, which requires the cooperation of the BIOS (ensure the OS that is about to be booted is trusted, and possibly in the future BLOCK booting of non-trusted OSes entirely), the OS, the main processor (for secure memory protection) and the video and sound cards. It is highly likely implementations of Palladium systems will not even HAVE a dedicated TCPA chip that can be easily attacked and disabled - the features will be built right into the main CPU.
While you were watching my empty left hand... (Score:3, Insightful)
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!"
Question (Score:3, Interesting)
Let's say I'm sitting and twiddling my thumbs, or serving rather a lot of MP3's [dhs.org] to the Internet at large, or something, and my computer crashes. Uh-oh, the hard drive can't be read. Looks like I need to boot from another drive to fix it. Trouble is, when I try to do so, TCPA interrupts and tells me I'm trying to boot from a different system, which isn't allowed. How do I repair my drive?
Of course, as a Mac user, I guess I don't have to worry about this much anyway (Apple still hasn't signed up for TCPA, right?). Besides, maybe in the Wintel/*nix-other-than-OS-X world I know so little about, there's a simple way to overcome this. But wouldn't a simple way to overcome it involve using software to make the switch? It's either that or jumpers on the motherboard, right? So the question stands.
Somebody fill the void in my brain! I long to know!
Is software emulation feasible? (Score:3, Insightful)
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.
Dongle (Score:3, Insightful)
A place to store your password? NO (Score:3, Insightful)
"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.
Re:A place to store your password? NO (Score:3, Insightful)
That user name and password are what identifies you.
Those the the *you* specific things, any privates keys etc held on an authentification server are irrelevent. If I have your user and password I *am* you as far as the computer is concerned.
In one breath he talks about protecting "HIS" keys and data, but in the next he says it protects data because the key never leaves the machine.
I, however, *do* leave my computer and work elsewhere, those protected keys can never be useful for *me*. It is not *my* key it is protecting.
Misdirection (Score:3, Insightful)
-----------
"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.
More misdirections (Score:4, Insightful)
-------
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.
Again the confusion between *me* and *my computer* (Score:4, Insightful)
------
"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.
Why I don't think the paper tells the whole truth (Score:4, Insightful)
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
Call Me Stupid . But . . . (Score:3, Insightful)
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.
Re:Fuck the TCPA, God damnit (Score:3, Informative)
Read the papers and understand what they say about TCPA != DRM != Microsoft. Idiot...
Re:Fuck the TCPA, God damnit (Score:4, Informative)
Re:Fuck the TCPA, God damnit (Score:5, Funny)
Thanks.
Re:Fuck the TCPA, God damnit (Score:5, Insightful)
Re:Fuck the TCPA, God damnit (Score:3, Informative)
TCPA was founded to enhance security. Infact IBM has been selling TCPA computers for years and no one has even noticed nor have they used it as a drm solution. IBM wants e-commerce to take off and security has been a major problem. Any third party and not just IBM or Microsoft can verify if the source is trusted. Also no more viruses. ITs a great technology and is needed in this day and age of buffer overflow attacks and code red.
Re:Fuck the TCPA, God damnit (Score:3, Insightful)
Show me where it says that.
I'm not claiming to be informed on this topic, but I would bet the $5 sitting in my wallet right now that there's no way they'd intentionally make a processor that Linux wouldn't run on. Remember those little things called servers that IBM rakes in the cash for?
Re:Fuck the TCPA, God damnit (Score:2, Insightful)
I'd really be surprised if this wasn't a troll though.. And I bet if I look at the poster's past posts they'll be trolls too.
Re:Fuck the TCPA, God damnit (Score:5, Informative)
The bottom line is that TCPA and Palladium are two different projects....My personal opinion (not speaking for IBM) is that DRM is stupid, because it can never be effective, and it takes away existing rights of the consumer....I have no problem with people arguing against DRM; I agree completely.
Summary:
Perhaps you'd care to let me know whether you've read the papers or you think he's a liar. I'll wait.
Re:Fuck the TCPA, God damnit (Score:4, Informative)
Then why did they provide an open source Linux driver [ibm.com] for the TCPA chip? Not much point in making a driver for an OS you can't install, is there? Systems with TCPA are already running Linux.
Re:[cough] (Score:2)
Re:[cough] (Score:2)
Re:whitepaper summary (Score:2)
I'm not entirely sure if this is sarcastic, serious, or what, but in any case, could you elaborate? Do you have an actual opinion on this, or is that all you wanted to say?
If you mean it seriously, and you mean to imply that the TCPA is inherently a bad thing, you obviously didn't read the whitepaper (and thus aren't well suited to present us with a "summary"). I think with IBM on board with this, we (Linux users specifically, other "alternate OS" users as well) should feel a lot better about this. Hell, we already have GPL drivers for Linux TCPA applications...
Re:whitepaper summary (Score:2)
Yes =]
Re:whitepaper summary (Score:2)
Re:Just Answer Me One Question... (Score:3, Insightful)
Re:Here is the devil (Score:2)
You mean to bypass the licensing scheme for software or view DRM content that you didn't pay for. If the software you're want to run requires this feature, why not find different software. But don't tell me I can't have TCPA because you don't want it.
Protecting the SRM (Score:3, Informative)
OTOH, if you patch just two bytes in the SRM for Win2K , you can take over the machine. TCPA isn't about encrypting the operating system, it is about protecting code, whether Linux or Win, or whatever.
The public-private key pair thing is addressing the problem of ensuring that the private key never gets where it might be read. For example, a private key on a passive dongle must be read and used by the processor, so it may be intercepted by an eavesdropper It is harder if the key is only seen by a dedicated processor (GSM SIM cards work a little like that but the encyption is shit).
Of course, a hardware protected SRM may be used for a number of different things, validating the OS, encrypted file systems and SSL but unfortunately also DRM.