Slashdot Mirror
IBM Trials TCPA Chip Under Linux
keihin writes "From IBM: IBM's Global Security Analysis Lab (GSAL) has done extensive analysis of the Trusted Computing Platform Alliance (TCPA) chip available on some IBM systems. We have the chip running under Linux, and have studied it extensively. In order to clarify a lot of misunderstanding about the chip, we are making available some helpful white papers and open source device drivers for Linux, so that interested people can test and use the chip in an open environment."
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!
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
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.
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.
Black holes are where the Matrix raised SIGFPE
Good to see??? umm... I hope your joking, cause otherwise, you have NO FUCKING CLUE WHAT YOU'RE TALKING ABOUT!!!
.sig link to notcpa.org, I guess you're not a supporter of the TCPA.
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.
NGWave - Fast Sound Editor for Windows
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.
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.
---
DRM is like antifreeze, to the MPAA/RIAA it's sweet, to the consumers it's poison.
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.
IBM's whole arguement on TCPA and privacy hinges on the assumption that software wont simply require an endorsement key, presumable from consumer pressure.
... I say they are just naive, and the engineers who are giving software companies the tools to abuse them are selling their soul (if they have one to begin with).
The moment you need to expose the endorsement key to be able to run the latest version of windows privacy goes right out the window for a great number of users. One might say that those users are stupid for letting it happen
If TCPA did not have endorsement keys everything would be hunky dory, as long as it does have them suggesting you can "simply" turn access off is a misleading arguement.
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.
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.
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.
The Trusted Platform Module (TPM) checks the kernel's signature. When a trusted application launches, it authenticates itself with the TPM. If you aren't running a trusted kernel, the TPM won't sign off on it, and it won't decrypt any data.
Part of what IBM seems to be marketing is a prioritary encryption key generator, but I think we have already learned from the seed prediction of the SSL for Netscape v2 that prioritary encryption key generators tend to weaken the strength of the encryption. No where in the entire page does it explain who was permitted to audit the firmware. While the driver is GPL, there is still a great deal of trust that the user must put in the closed source firmware when using the driver.