Apparently, the TCPA folks keep the list of companies involved private which is why I had never really heard of anyone aside from IBM involved in this alliance.
Good to see??? umm... I hope your joking, cause otherwise, you have NO FUCKING CLUE WHAT YOU'RE TALKING ABOUT!!!
I'm honestly not sure what you mean here, but from your.sig link to notcpa.org, I guess you're not a supporter of the TCPA.
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.
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.
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.
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.
If the goal is protecting the integrity of processes, wasn't this what we were supposed to expect from any halfway-decent hardware and OS combination?
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.
Before people get too confused and start to complain (quite reasonably) about the RIAA, MPAA, etc: this chip is not designed to facilitate DRM. In their "why TCPA" article, they explain why it's not even particularly well suited for such systems.
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.
"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."
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?
"it's primarily about protecting a user's private keys...",
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.
this chip is not designed to facilitate DRM. In their "why TCPA" article, they explain why it's not even particularly well suited for such systems.
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?
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?
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.
How does "the end user does not have control over his own computer"? The chip only does what the OS tells it to do, and the user uses whatever OS he wants.
Let's stop thinking about Windows for a second, seeing as IBM has presented a bunch of GPL drivers for Linux. On my Linux box, I choose how to use this chip. Instead of running ssh-keygen I run a client program and tell the chip to generate my keys. Then when I want something encrypted with the private key that it has generated I just send it the data and it encrypts it for me. I'm completely in control.
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?
You are right that the chip could be used for these purposes. I have no problem with that. I don't want to see it automatically installed on end users machines because the majority will not be using it for ssh-keygen. The only reason for this on regular machines (not business users or power users) is for DRM. Intel has admitted this is why they are involved with TCPA. IBM is also interested in DRM. TCPA will be a part of this. If power users and business users want TCPA then it should be an add-on card and not ubiquitous. Normal users do not need it.
Don't just shove TCPA in with Palladium. If you actually did some background reading you would understand the problems that TCPA is trying to solve. Alternatively, you could just listen to what rational people say and think. There are full specifications that tell you exactly what the chip does, go read em. Form your own opinion, and be reasonable.
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".
From an interview with Jim Ward of IBM (one of the authors of the TCPA spec)
"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.
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?
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.
But it doesn't facilitate DRM at all; the private key never leaves the chip, and it isn't set until the user sets it. This makes it useless to anyone *except* the user; the MPAA doesn't have the key or even the chip. The user, at least, has the chip.
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.
But it doesn't facilitate DRM at all; the private key never leaves the chip, and it isn't set until the user sets it. This makes it useless to anyone *except* the user; the MPAA doesn't have the key or even the chip. The user, at least, has the chip.
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.
But what if I want to take my personal private key to work so that I can decrypt messages sent to my home email address while I'm there? (Which I do now.)
This is all about DRM and you are spreading FUD. The rebuttal to Ross Anderson's FAQ is similarly a bunch of FUD.
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.
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!
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:
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.html
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_weinbe rger102502.asp?p=0 EFF: http://www.eff.org/Legal/active_legal.html Ross Anderson: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
A HW accelerated encryption engine would give us snappy remote xsessions out of the box with ssh->ssl->kernel hw calls. I'd love this, imagine running fwbuilder on your remote fw from home. It's a must for teleworking.
Any modern processor will deal with a well designed crypto alogrithm easily. I don't think your xssessions/teleworking are going to get noticably faster. I 'scp' large stuff over 100BT LAN all the time and my Celly 567 CPU usage is less than 2% (128 bit Blowfish). Similar results with VPN-ing. While it is true that TCPA chip can be used to speed up the encryption even further I highly doubtdon't think that was the motivation behind it.
I view TCPA as more of a security enhancer then for drm. I trust IBM more then Microsoft to make sure Linux will run with it and it has alot of cool features.
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.
Hardware SSL encryption engines are already available as PCI expansion cards. They've been available for years. I'm not a buff on TCPA by any means, but TCPA really seems to look like just another integrated peripheral that is probably better off being an expansion card. (Kind of like integrated AGP video. Mmmmm....S3VirgE MX! lol)
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.
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?
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.
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.
No, it is not DRM, but that is what it will be used for!
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.
by Anonymous Coward writes:
on Friday January 24, 2003 @10:23PM (#5154905)
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.
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.
It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased.
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).
All the hardware companies are pulling this tactic. "Oh we are just putting TCPA capabaility" its that evil Palladium/DRM that is going to be the problem. You heard the same thing from AMI. I think that does represent IBM's position.
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.
actually, the reason for that statement is to disclaim any bias the author may have against DRM.
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/. crowd specifically), so his including that tries to show early on that this is not a pro-DRM issue. His intent is to show that TCPA is NOT DRM, and he further implies that if it were he wouldn't be pushing for TCPA (by showing his dislike for DRM).
My response was probably more long-winded than it needed to be... but hopefully it makes sense:)
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?
Well the good news is that you can turn it off. The bad news is that the email from grandma may require palladium and not TCPA. TCPA is different [trustedpc.org]then Palladium and has been in use since 99 on almost all IBM systems. Ask any ThinkPad owner. Also there are only 2 chips in the motherboard that make up the TCPA as well as a special bios.
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.
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.
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.
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?
I can easily envision them integrating it into their WMP 9 technology and preventing all those without TCPA access to the media.
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.
As far as I can tell, it wouldn't be difficult to build systems running say, Win XP, with the hashes marking the trusted OS keeping any other OS from being loaded and successfully booted on the machine. Of course this is more like with a Palladium based machine. But this spec also allows it from what I got out of the paper.
Also, regardless of the author's opinion, a chip that enables DRM even sub-optimally is not the friend of the people.
But this spec also allows it from what I got out of the paper.
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.
The bottom line is that TCPA and Palladium are two different projects. The TCPA hardware provides only a subset of the full Palladium functionality, which includes significant additional hardware and software elements. Only TCPA already has a freely downloadable detailed specification, and a tested port of all driver and library level software to Linux.
Don't get completely up in arms about this is what is trying to say. Then he has an even better quote later:
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. To condemn TCPA for the ability to run a bad application is absurd. This argument is exactly like the arguments of governments in their attempts to ban encryption, under the rationale that encryption can be used by terrorists to hide their messages.
I've read that FAQ and it does not change that fact that TCPA _is_ about DRM. It is security for the publisher not for the end user. Regular ordinary users have no use for TCPA other than as a key for big media to take away Fair Use rights. Have a look at the Electronic Frontier Foundation for some clear thinking on this.
I'm not sure why there seems to be such a mixed reaction to this news. From the talk that Lucky Green gave at Defcon X this past summer, I saw nothing but heaping stacks of badness to come from the TCPA. To quote the talk description from the Defcon website:
"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."
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.
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.
1) IBM doesn't care about DRM. In fact, this chip is completely unsuitable for DRM (and the white paper author was kind enough to explain why... protects you from SOFTWARE attacks, not hardware.)
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.
It does not 'protect' the end user from anything. It protects the publisher from the end user. It does not matter if the specs are open and a GPL demonstration has been written. The _use_ of this technology is for DRM and claims to the contrary are dishonest.
It can be used to boot a secure OS, yes. But it won't prevent you from doing it if you want to (especially since you get to define which OS is valid; this is an advertised feature) 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.
From reading their discussion paper, they claim TCPA can be used to (amongst other things):
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...:)
Personally, I'm more concerned about doing things like moving keys from one computer to another. I mean, if you use the TCPA chip to sign an email, then all it does is prove that someone using your computer sent it. On the other hand, if it's possible to move the generated key to another box, then doesn't that present a security risk?
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.
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.
I'd have to say that my opinion of IBM went up. They seem to be making an honest effort to show exactly what TCPA is. I admit I have not read the documentation, (my mind has shut down for the night). But it seems like many of the companies, (IBM and AMI for instance), are working to let people know that TCPA is nothing more than a tool available to people who want to secure their computers and not a tool meant to secure other people's content on your computer.
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.
If people want to have something like this just put the private key on a USB dongle. I can remove the damn thing this way if I wish, my decision. This is no different than the hardware dongles software manufacturers sometimes use only this on is permanatly attached and cannot be removed.
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:
The "trusted boot function provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence. Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal with fail, thus protecting the data.
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:
The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would be a nightmare for content providers to manage. Any change to the BIOS, the operating system, or the application would change the reported values. How could content providers recognize which reported PCR values were good, given the myriad platforms, operating system versions, and frequenent software patches?
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.
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.
I've always been amused at the claims of how hardware can solve security problems. The suggestion of how to protect authentication using TCPA and, indeed, all other "smartcard" based solutions, is to make sure the private key never leaves the hardware. The idea being that the attacker cannot access a server from any other machine than the one containing the hardware. This is clearly not the case. Suppose you use SSH to access your server at work and, for added protection, you use TCPA to keep your private key. An attacker hacks your client attempting to access to the server at work. All he/she has to do is use your hardware to access the server. At this point the attacker can bypass the authentication by:
Installing a new key;
Installing a back door; or just
Taking what they want
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.
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?
By itself, a security coprocessor is no different than using the PIII's serial number to create a unique hash and processing encryption on the main CPU.
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.
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!"
Okay, so TCPA is not evil, as I had been led to believe. I have a nagging question about it, though, that I need answered before I consider it a Good Thing.
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!
If it is feasible for a user, who has physical access to the machine at boot time,
to install a software emulator for TCPA in a manner that it is completely indistinguishable from real TCPA hardware, from the point of view of application software, then I'll believe this is benign.
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.
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).
"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.
"I can sit at any (Windows) computer in my office and log in using my username and password"
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.
"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.
Exactly why do I _want_ these chip[s] on my new mainboards? 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.;o) I think I meant plethora of whoring bullcrap.
Any code what-so-ever will run on a trusted system it just runs in untrusted mode. Any TCPA system can run an OS, at worst it won't be able to certify any applications as trusted.
Pure fud! Look here [trustedcomputing.org]for more info. Microsoft's pallidium project was started as a way to controll there bytes on someone elses computer according to one of the founders of the project. My guess is to cut down on piracy. Bill Gates said he wanted the asian market "hooked" on piracy and then during the next decade find a way to get them to pay for it. Well they found it. Palladium can also provide security as well so its not totally evil.
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.
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?
Mod parent troll. Read the article, it's actually about (think of it as something like hardware level password encryption, though that's an oversimplification.) A lot of other comments do better than this one anyway.
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.;)
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:
TCPA is not Palladium
TCPA is not DRM. DRM is just one possible application of a trust computer. Criticize DRM all you want.
TCPA does not:
control execution
block executition based on signatures, or revocation lists, or approved lists
TCPA does:
provide protection of a user's private keys and encrypted data
protect sensitive data from many software attacks, including viruses, worms and trojans
Perhaps you'd care to let me know whether you've read the papers or you think he's a liar. I'll wait.
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.
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...
I read that white paper and it does not change a thing. The availability of GPL drivers does not change the fact that this is an enabling technology for DRM and not much else.
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.
"What I need is the ability to read and change the endorsement key so that I can falsely endorse my system to be something that it is not"
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.
Operating systems that have pretensions to being secure implement a bit of code called a security reference monitor or SRM. This module checks access requests and audits events accorind to system policy. By putting the security functions into one place, a system, becomes much easier to check, as usually the SRM is pretty tight.
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.
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)
- 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... :)
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.