IBM Trials TCPA Chip Under Linux

keihin writes "From IBM: IBM's Global Security Analysis Lab (GSAL) has done extensive analysis of the Trusted Computing Platform Alliance (TCPA) chip available on some IBM systems. We have the chip running under Linux, and have studied it extensively. In order to clarify a lot of misunderstanding about the chip, we are making available some helpful white papers and open source device drivers for Linux, so that interested people can test and use the chip in an open environment."

Comments

Why I didn't know IBM was involved

[Amsterdam Vallon]

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.

However, there's a full list here.

Check out *nix.org , a dynamic, informative, and fun portal for fans of BSD, Linux, OS X, & Solaris!

just remember....

[Anonymous Coward]

Real World TCPA != DRM

Microsoft's TCPA == DRM

Re:just remember....

[Waffle Iron]

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.

This is NOT about digital rights management

[metamathica]

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.

Re:This is NOT about digital rights management

[curious.corn]

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.

Re:This is NOT about digital rights management

[Wesley Felter]

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.

Re:This is NOT about digital rights management

[manyoso]

Exactly. Without access to the actual key pair then the end user does not have control over his own computer. This facilitates DRM and not much else.

Re:This is NOT about digital rights management

[manyoso]

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!

Re:This is NOT about digital rights management

[manyoso]

Sure, no problem:

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

Re:This is NOT about digital rights management

[iabervon]

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.

Re:This is NOT about digital rights management

[manyoso]

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:

http://www.counterpane.com/crypto-gram-0208.html
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

Re:This is NOT about digital rights management

[dusanv]

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.

Re:This is NOT about digital rights management

[Dunkirk]

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.)

I much much rather have TCPA then pallidium

[Billly Gates]

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.

Re:I much much rather have TCPA then pallidium

[Arethan]

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.

Re:I much much rather have TCPA then pallidium

[jbolden]

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.

Re:I much much rather have TCPA then pallidium

[Daniel Phillips]

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.

At least read some of it before commenting...

[26199]

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>

Whitepaper biased

[Anonymous Coward]

It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased. If you read the author's section on DRM in the TCPA rebuttal you get a feeling like you're reading a post on slashdot.

Comments like: "I have no problem with people arguing against DRM; I agree completely." should not be there. It's ok to agree/disagree with DRM, but not in public documents with your employers name on them.

Just my $.02 CAN.

Jason

Re:Whitepaper biased

[sfe_software]

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).

Passing the blame.

[Phoenix823]

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?

Re:Passing the blame.

[Billly Gates]

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 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.

Other Possible Issues ~ Misuse

[Goalie_Ca]

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?

what about the OS securing features

[samantha]

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.

Some nice quotes from the misinfo rebuttal

[pridkett]

For those of you who didn't read the stuff:

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.

Ahh...it's great to take stuff outta context.

TCPA talk at Defcon X

[968134]

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."

Sounds like DRM to me.

Re:TCPA talk at Defcon X

[Anonymous Coward]

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.

Re:TCPA talk at Defcon X

[jbolden]

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.

Re:This is NOT about digital rights management-II

[Anonymous Coward]

"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?

Quick notes for spastic no-read replies:

[moogla]

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.

Big claims...

[Goonie]

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... :)

Re:Big claims...

[rasteri]

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?

Moronic knee-jerk reactions...

[Theovon]

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.

Re:Moronic knee-jerk reactions...

[geekoid]

"MS just joined an anti-DRM coalition!"

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.

Re:Great news

[sfe_software]

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.

Re:Just Answer Me One Question...

[geekee]

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.

People please remember

[codepunk]

Microsoft to Dell: could you please ship our new paladium board in your computers.

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

Need clarifications

[IkeTo]

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?

Wake up!

[Kevitt]

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.

Hardware protection of private keys

[QuantumG]

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:

1. Installing a new key;
   
2. Installing a back door; or just
   
3. 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.

Re:Hardware protection of private keys

[JordoCrouse]

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?

TCPA only a single component of Palladium

[Powercntrl]

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.

Smart Cards

[Anonymous Coward]

Why cant we just use smart card technology instead? That way you get the benefits of TCPA without having to get a new PC, and its not perminant enough to make it work for DRM.

You dont make sense

[QuantumG]

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?

Re:You dont make sense

[manyoso]

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.

Re:You dont make sense

[jbolden]

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.

While you were watching my empty left hand...

[Erik Fish]

Let me get this straight:

IBM and the hardware manufacturers are saying: "TCPA is just a gun! It can be used for good or evil purposes!"

Microsoft is saying "Palladium is just a bullet! It can be used for good or evil purposes and it stops piracy which is illegal! Do not look behind the curtain marked 'this machine kills linux'!"

The content industries are saying "DRM is another kind of bullet! It can be used for good or evil purposes and it stops piracy which is illegal! What is this 'fair use' you speak of?"

The whole bunch of them are saying "We are forming a club. All club members will communicate with secret decoder rings which you are perfectly free not to use however don't expect to be able to join the club without using them!"

Re:Great news

[BeBoxer]

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 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.

The tactic

[jbolden]

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.

Re:normal users of Linux?

[QuantumG]

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".

Question

[PetWolverine]

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 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!

Re:IBM

[jbolden]

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.

Re:normal users of Linux?

[manyoso]

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.

Re:Linux vs. Linux users

[Arandir]

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.

Finally ...

[SalesEngineer]

I'm glad to see IBM directly address TCPA issues. Their explaination of how TCPA works is better than what I had for the AMI/Slashdot interview.

I'm also happy to see a TCPA/TPM driver for Linux (was wondering when sopmebody would get around to that).

Brian Richardson - AMI

Is software emulation feasible?

[Sloppy]

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.

Private / Public key

[jbolden]

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.

Protecting the SRM

[anonymous cupboard]

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.

Dongle

[dusanv]

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).

moderators on crack warning!

[Xtifr]

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.

A place to store your password? NO

[NigelJohnstone]

From the whitepaper:

"Protection of sensitive authentication data, such as passwords will become critical for
electronic business to succeed."

Passwords are *user* specific things, not machine specific things.
Storing them in a vault on a single machine means they are stored in the wrong place.

This is a lie.

Re:A place to store your password? NO

[NigelJohnstone]

"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.

Misdirection

[NigelJohnstone]

From the rebuttal whitepaper
-----------

"When you boot up your PC, Fritz [the TCPA chip] takes charge. He checks that the
boot ROM is as expected, executes it, measures the state of the machine; then checks
the first part of the operating system, loads and executes it, checks the state of the
machine; and so on."

This is completely false. The TCPA chip doesn't execute anything. It accepts request data, and replies with response data. In the IBM version,
TCPA sits on the LPC bus, using I/O mapped registers. The TCPA chip does not and
cannot control execution!

-------

This is a misdirection, the original comment was about the TCPA system in its entirity, the response talks only about the chip part of the TCPA.

More misdirections

[NigelJohnstone]

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.

Again the confusion between *me* and *my computer*

[NigelJohnstone]

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.

Why I don't think the paper tells the whole truth

[Kjella]

IBM is doing pretty much what every other business does, downplaying the bad and promoting the good sides of their product.

Soon, you will have TCPA/Media Center PCs. I'm pretty damn sure they *will* contain an endorsement key (that Microsoft will have, probably in the licencing agreement for making them), that you can not gain access to (except for a hardware hack), and that you can not emulate. This key will verify your BIOS, your Windows Palladium Media Center, and your DRM-crippled Windows Media Player. Or maybe they'll stage a few "licenced" players to create the illusion of choice.

And in the next level, I've heard that TCPA will be internal to the processor. Goodbye even to the hardware hack.

Saying the TCPA of the IBM machines doesn't have an endorsement key is saying, "yes, we're pointing this assault rifle at your consumer rights, but we haven't loaded it yet". Then when people "have to" have an endorsement key to get programs working, they can blame it on consumer demand.

Kjella

Call Me Stupid . But . . .

[GnuPengwyn]

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.

TCPA is: LOCK-down, LOCK-out, LOCK-up restrictions

[FeatureBug]

Please stop saying,

• "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.

TCPA really means lockdown enabler.