Slashdot Mirror
TCPA Support in Linux
kempokaraterulz writes "Linux Journal is reporting that "The Trusted Computing Platform Alliance has published open specifications for a security chip and related software interfaces.". In the latest Gentoo Newsletter they talk about a possible 'Trusted Gentoo', and possible uses for hardware level security."
It really makes me happy to see that Linux distributers are finally seeing the light and providing the community with things we need in an Operating System. Hopefully this will lead to other advances in the wonderful world of DRM.
sigh
From a programmer's perspective, the IBM version of the TPM (or TCPA chip) looks like Figure 1. Garrick, please crop the caption out of the figure itself.
Garrick? Garrick? McFly? McFlyyyyyyyyyy?
500GB of disk, 5TB of transfer, $5.95/mo
I mean - there are a lot of hardware security modules that can be used for building trusted systems right now.
Isn't the only purpose of pushing things like TCPA locking the platform down ?
-- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768
From the Fine Article:
-theGreater.
The only benefits I can see is increased security for encrypted communication or hard drive encryption. I am really trying to think hard of any other beneficial applications but can't come up with anything.
to hang myself.
Instruction: How to restrict your Linux box from yourself.
Life is not for the lazy.
Linus himself said DRM is ok, as long as it's used in the interests of the user. This is a good thing, think about it; EvilCorp(tm) wants to use DRM to cripple computers, but the PR guy will say "it's for the user". Of course their intent is nothing of the sort, but the Linux folks are the only ones who will actually implement something that *is* in the interest of the user. Then EvilCorp won't be able to lobby making Linux illegal, since Linux also uses DRM which does what EvilCorp claims it's doing "for the users". Well, hopefully.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Better yet, lead 'em. It would be ridiculously funny if Trusted $FREENIX were released before Trusted Windows or Trusted MacOS.
Though the specifications detailed in the article are definately a Good Thing, they lack (at least as far as I could tell) any way of preventing unauthorized physical access to the chip.
d ex.html
Physical access to machines is always a big issue in security, and one that is often overlooked. And while it's probably not a big deal for your home machine, consider large companies whose machines could conceivably be targetting for a physical attack to recover the keys directly from the TPM (Trusted Platform Module).
Stajano's "Ubiquitous Computing" book has excellent coverage of the rationale, issues, and complexity of attempting to prevent physical access to chips and devices which store sensitive information. It's an easy read, and well worth it: http://www-lce.eng.cam.ac.uk/~fms27/secubicomp/in
This is indeed good news! Security that is solely-based on software is far easier to compromise than hardware-based (provided that the hardware can't be tampered with by malicious software). Far better to have the security co-ordinated between both. I'd be interested to see how widely accepted this open specification will be.
Treacherous Gentoo?
It has been said a million times, yet apparently it bairs repeating. The "security" aspects of TCPA are redundant, unnecessary, and at best useful but could be made a lot better if the chip was designed for security rather than DRM. The whole system really exists only for one purpose: as a trojan horse to implement something called "remote attestation" in PCs.
What is remote attestation? Basically, it means that the TCPA chip, which you cannot control, can read what operating system you have loaded, and send a reponse proving that you are running a certain operating system to others on the Internet. The purpose of this, of course, is so that the operating system can be verified not to have it's DRM functions cracked, so that the RIAA and MPAA can send you data and make sure that they get to decide what you do with it.
The people pushing TCPA will claim that it is not for DRM, but that is a smokescreen and only a smokescreen. While TCPA does not do DRM itself, it is the enabling component that is needed so that software can implement DRM without being circumventable.
What does this mean for a "trusted Linux"? It means that while it is completely possible to have a Linux system working with TCPA, once you change anything in the system, the TCPA chip will notice you are running a modified system, and nolonger let your data. So while the software may nominally remain under the GPL, it will be the death of the free software model, because users who wish to tinker with their systems will be locked off the Internet (Cisco is already talking about systems to have ISPs demand remote attestation when TCPA is in place). TCPA and Linux can be combined in theory, but only in theory - in reality they cannot ever coexist.
Those who do not believe me (or those who are inclined to believe the MS shills who will respond saying that I am wrong), should read EFFs analysis of TCPA where they give a simple way that the chip could be changed to allow all uses except remote attestation intended to force people to use certain operating systems and enforce DRM over the user. It has been completely ignored by the manufacturers of TCPA.
It's very simple:
1. Linux is distributed under the GPL (and other licenses).
2. To comply with the GPL, end-users must be able to acquire the source code (which means everything they need to reproduce the binary executble, with or without modifications).
3. If you don't comply with the GPL, you are committing copyright infringement, a federal offense.
But from the other direction:
4. Trusted computing means that all binaries are signed with a secret key.
5. The Trusted CPU will not execute binaries that weren't signed with that key.
6. In this way, it is impossible for end-users to create modified binaries to add/remove features from the software.
The GPL is too much in conflict with Trusted Computing to ever allow them to work correctly together. To obey the GPL, end-users must have access to everything needed to rebuild working binaries- which includes the secret key. But for Trusted Computing to work, it must be impossible for end-users to get the key- otherwise there's no point.
So, Linux or Trusted Computing. Choose one, because you can't have both.
Since the source is available for Linux, what would stop someone from sandboxing 'trusted' software by having the OS validate code before it's executed (slow, though a bit faster than emulation and without all the bugs), and then implenting the DRM hardware (or BIOS) instructions in software in a way that stores the keys (or plaintext information, if that is not doable) and allows access to any software to get the info.
The software DRM implementation would be 100% transparent to the application and noone would be the wiser.
It should also be workable with a x86 emulator running a closed source 'trusted' application along with its closed source OS, with the emulator doing the DRM instructions a little differently than normal.
Go to the Linux Journal search function and search for 'garrick'. You should get eleven hits. I didn't read all of them, but using ctrl+f to search the pages revealed notes to Garrick re: font selection and the like. D'oh.
I want to drag this out as long as possible. Bring me my protractor.
To have to burst your bubble of uninformed zealotry, there are plenty of good uses for trusted computing and DRM that do no interfere with your quest to get 'fr33 musicz 4 life' or whatever. Not all of this technology is for companies like the RIAA to protect copyrights, despite what Slashbots would have everyone think.
It hasn't been called the Trusted Computing Platform Alliance, TCPA, for a couple of years now. It's now the Trusted Computing Group, TCG. Same technology, just a new name.
If you want to test the IBM API, but you don't have a Trusted Platform Module, you can try using the kernel module emulator at http://tpm-emulator.berlios.de/index.html
Comment removed based on user account deletion
Trusted Computing Group (TCG) technology makes sense in the context of Linux. Microsoft refuses to implement it. They had their own conception, which was Palladium, then NGSCB, then was dropped. So if TCG is going to go forward at all, it has to be with Linux.
It's kind of ironic, because Ross Anderson's lying Anti-TCPA FAQ tries to claim that TC exists to kill Linux. And yet it is turning out that Linux is the salvation of Trusted Computing.
There are a number of research projects in TC on Linux, including TPM Device Driver, Trusted GRUB and Secure GUI, tcgLinux, TCPA Open Source Platforms, Enforcer, and more. All Linux based.
Don't believe the FUD about TC. When implemented in Linux using Open Source software, TC gives you new options for securing and expanding the capabilities of your computer.
The "trusted" boot functions 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 will fail, thus protecting the data.
At the very least, that sounds like "bye-bye multi-boot systems".
IBM also has a rebuttal to TCPA's detractors [PDF]. This one talks more about how the TCPA chip as currently designed "not been designed to resist local hardware attack, such as power analysis, RF analysis, or timing analysis." That's all well and good for the moment, and while the chip is (per the PDF) mounted on a presumably-removeable daughterboard, but how about the future? Is this how TCPA will stay, or is it the beginning of our worst fears??
At least these two whitepapers agree with most of us here on one thing -- DRM itself is stupid, for a variety of reasons.
~REZ~ #43301. Who'd fake being me anyway?
In Soviet Union, your GPL'd software doesn't trust YOU!
Hmmm. This puts the whole concept of so-called "Trusted Computing" into a realistic, and sad, perspective.
From a practical standpoint, TCPA is incompatible with the Linux philosophy of open-source modifications
IMO this is not exactly correct - is it against Linux philosophy of open-source modifications to secure my Linux box so nobody except me can make modifications to it?
TCPA used in such way (i.e. in interest of user, not supplier, not government, ...) is quite in line with Linux philosophy of "you're in control" :) .
But, as with all weapons, it has two edges. So, beware! :)
hany
RMS has written a nice article about it: see http://www.gnu.org/philosophy/can-you-trust.html
Garrick, please don't forget to remove my inline comments to you before you post this article.
Proud neuron in the Slashdot hivemind since 2002.
You should read the TCPA FAQ if you have not already. It explains why this is a bad thing.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
I want to try to correct one of the most common and universal misconceptions about Trusted Computing: that it will only allow signed code to run. This is causing enormous confusion here, with people arguing about how that works with the GPL, who would get to sign the code, would users get to sign their own code, etc., etc.
The truth is that the TCG spec says nothing about signed code. There are no limitations in TCG that keep you from running unsigned code. There is no distinction between "secure" and "insecure" code. You can run anything you like. Signing is a complete red herring in this discussion.
I am not trying to gloss over problems or paint a false picture. The truth is that TCG does have features whose effects are somewhat like what people are worried about with signed code. The result is that TCG could be helpful for DRM, and it might make it impossible to download music from an online store without running a special application, for example. But this would not be because "you can only run signed code". Rather, it is the server that decides whether it wants to talk to you, not your computer deciding what you can and cannot run.
What's the difference? Well, if your main concern is being able to run hacked clients that will allow you to violate your user agreements, then there is no difference. You would be right to oppose Trusted Computing. It will make it harder to lie and pretend to honor an agreement, then break your word and go back on your promise.
But if your main concern is about the GPL and what software you run, there is a big difference. There are no limits on the software you can run. You can hack your Linux kernel to do whatever you want. You can disable "secure" features in the software you run. These privileges don't go away when there is a TPM chip. That should put to rest the concerns about the GPL and hopefully end the discussion about who signs what code.
If you're wondering how these two points of view can be compatible, you need to learn more about the TCG spec and the TPM chip. In a nutshell, the TPM chip, with the cooperation of the BIOS and OS software, takes a hash or fingerprint of the software configuration as the computer boots. It can then report this fingerprint to remote servers, if client software requests it. These reports are signed with an on-chip TPM key that never leaves the chip; and this chip has a certificate from the computer manufacturer, so no emulator can fake these reports (called remote attestations).
That's how it works. It's a lot more complicated than refusing to run unsigned code. What it comes down to is that software can report its configuration in a believable and, yes, trustable way. That's the real reason this is called Trusted Computing, not the lie made up by Ross Anderson. It's Trusted because you can Trust the reports from a remote system about what software it is running, and therefore what it will do.
Answer: Nobody said anything about a central authority. You can tell TCPA to trust any private key you want, just like any public key system, you just need the public key. You can create a keypair yourself and tell the system to trust anything signed by it (which is pretty much the only way I can see gentoo users doing it).
The problem comes in when we start talking about remote attestation. How can I tell every service I connect to to trust software signed by my personal private key. That will never scale.
Not to mention that you can expect RIAA and MPAA services to only trust client software signed by MS or other trusted parties.
Finkployd
Probably an easier way is to have a hacked memory module that lets you change the contents with some kind of hardware interface.
If the memory and all buses in the computer are encrypted, then you're out of luck, but this is not currently in the spec.