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 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.
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
A locked down platform is very useful for some things.
One thing TCPA provides that many alternatives do not is a system of sealed storage. In this scheme, an application run under the TCPA feature set can access storage that is guaranteed by hardware to be only accessible by that one application, and no others. This storage is protected by hardware encryption, and cannot be accessed directly, even by the OS. If the application itself or any component is tampered with the sealed storage is inaccessible, since the Nexus, or hardware security manager, recognizes the binary itself as the key to the sealed storage. If that binary is modified, it can no longer access the sealed storage.
Sealed storage like this is useful in a lot of ways. Combined with a strongly encrypted internet communications a highly secure messaging system could be devised where the encryption was physically end-to-end. Since TCPA provides encryption from the keyboard, to the memory, to the Nexus to the CPU and every point in between, the plain text is only exposed when it is physically being typed - it never exisits in unecrypted digital form.
If Gentoo wants to add a TCPA compatibility module, have fun. But absolutely do NOT call it "Trusted Gentoo" when its actual meaning is "Gentoo that doesn't trust YOU".
Gentoo's public communications guy needs to read some George Lakoff. It's a wonderful life, folks. Every time you use their words, a devil gets his pitchfork.
From your post, I belive you don't understand what trusted computing is, or what the TCG specifications imply. Trusted Computing is based in the assumption that there is a Core Root of Trust. This CRT is trusted, and should be verifiable (not the current state, but maybe in the future we will have an open source BIOS). This CRT will measure the next entity (bootlader, whatever) and will hash the reult into a repository (the Trusted Platform Module). Then the bootloader will do the same with the OS, and so on. Of course, this is an over simplification, but there is no signatures here. Later, a program wil want to attest the software you are running, and will ask for this integrity measuraments. Also note that this (attestation, measuraments) is only a tiny part of the TCg specifications I dont see any trouble with this and linux.
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.
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.
This is one of the most commonly asked questions about the TPM. The answer is that the TPM implements what is called a "secure boot" sequence.
The first thing that happens in a TPM enabled computer is that the BIOS, on startup time, sends a hash of itself to the TPM. Then, when the BIOS goes to load the OS, it sends a hash of the boot loader (grub, in the case of Linux) to the TPM. The boot loader will be modified (see the Trusted Grub project) to take a hash of the OS kernel and send that to the TPM. And the OS itself will be modified (a la tcgLinux to take a hash of the various OS components, startup scripts, and programs as the computer boots.
The net result is that the TPM has a record of what OS was booted and what the software configuration is that is running. This allows it to distinguish between a "real" boot and an emulated one, because in the latter case it sees a hash of the emulator being loaded.
Software which runs in un-emulated mode and uses the TPM features can distinguish that case from when it is running emulated. If it locked some data using the TPM in the first mode, it won't be accessible in the second mode.
Once remote attestation is possible, networked applications will be able to report their software configuration to each other. This will be unforgeable because the TPM will sign an attestation of the software configuration, and the TPM itself will have a certificate from the manufacturer attesting that it is a legit TPM. Your emulator will not have a certified TPM key (those stay on the chip) and so it won't be able to come up with a credible forged attestation. Programs running on emulators won't be able to take part in network security applications that use these features.
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.
This is total garbage. Where did you get this nonsense?
TC does not require binaries to be signed with a key. TC will not refuse to execute unsigned binaries. And end users can do whatever they want.
Now for the facts, in case you're interested. TC implements a secure boot. This allows the TPM chip to store a hash or fingerprint of your software configuration: the BIOS, the boot loader, the OS, and if desired, the applications that are running.
The TPM and OS can basically do two things with this information. They can implement "sealed storage" which means that a program can lock its encrypted data to the current software configuration. This means that if you boot a different OS, or if the program gets modified (either of which might happen due to virus infection), the fingerprint changes and the data will no longer be available. Likewise if another program tries to access the first program's sealed data, it won't be able to get access to it.
The second feature of the TPM is "remote attestation". This allows a program to request the TPM to issue a cryptographically signed statement about what the current software fingerprint is that is running. This signed attestation cannot be forged because the TPM generated an on-chip key at manufacture time, and the manufacturer issued a certificate on that key which the chip can use to prove to anyone that it is a legitimate TPM.
Remote attestation allows network applications to determine what software configuration the peers are running, and, if they choose, to disallow participation by software which is not running a specified set of configurations. This is the closest you will come to the idea that users can't change their own software. If they want to run a program which relies on this feature, and that program doesn't accommodate the changes the user wants to make, they would be shut out. But in practice, open source programs will probably be flexible in this regard as they will want to have as many people as possible participate. There are a number of technical measures which can be adopted to allow for considerable user flexibility.
But certainly none of this would violate the GPL or any other legal prohibitions. Everything is entirely voluntary, and Trusted Computing does not prevent you from doing what you want with your computer. You don't even have to turn it on if you don't want to!
RMS has written a nice article about it: see http://www.gnu.org/philosophy/can-you-trust.html
LOSE...not loose. You can lose money...you can turn a dog loose. Two different words...two entirely different meanings.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
This means that the entire security of the boot process hangs on whatever data the CPU feels like sending to the chip for hashing. I could as well make a patch for GRUB that sends the "secure" version of GRUB down the SMbus and actually executes whatever nastiness I have in store.
That's a clever idea, but it doesn't work. The secret is that the trusted boot process uses a concept of "trust extension". We start off with the BIOS. That takes a hash of itself and sends it to the TPM. Then the BIOS will load and run the boot loader. But - and here is the key - before running GRUB, the BIOS take a hash of GRUB and sends it to the TPM. Then it runs GRUB.
The next step is that GRUB - or at least the TPM enabled version, performs a similar process for the OS kernel. It first takes a hash of the kernel and sends it to the TPM; then it runs the kernel. And the kernel can repeat the process with the various startup scripts and other programs that loads, a la tcgLinux or the Enforcer.
The key point is that before each component is loaded, it is "measured" (i.e. its hash is reported to the TPM). So you can create a bogus GRUB or a bad kernel, but this fact will show up in the TPM's configuration registers because your bad component got its hash reported before it ran.
The one exception is the BIOS, but TPM systems are supposed to have restricted BIOS flash capabilities so you can't re-flash the part of the BIOS which does the initial hash of itself. This is part of what they call the Core Root of Trust for Measurement (CRTM) and it is supposed to be inviolable.
You can also use TCPA to turn your Linux box into a hardware-reinforced installation of your choice.
If you have the technical brainpower to use TCPA + Linux to build yourself a secure hardware platform, you could also more easily build an equally secure all-software Linux platform.
The only advantage the TCPA gets from using hardware is it's a big barrier-to-entry for reverse engineers with physical access to the machine: they can't just load it up into an emulator/debugger, they also have to dissect the CPU under an electron microscope.
TCPA, at its core, is a way for you to prove to remote companies that you haven't modified the behavior of your own computer. It accomplishes this with a combination of cryptography and tamper-resistant chips.
if Intel steps up and builds TCPA support into the CPU itself
From the Inquirer:
Improved architecture for Prescott [CPU] includes better pre-fetcher branch prediction, advanced power management, improvements to hyperthreading technology, the PNI above, La Grande support, better imul latency and additional WC buffers. La Grande is the security feature Intel told us about at the last IDF, and includes protection in the CPU, at the platform level, and with software.
And this story:
Addressing growing security concerns in the PC market, Intel last week also gave a glimpse of La Grande, an on-die technology that will interface with Microsoft's Palladium and other upcoming security software. "We're going to take hardware security up a notch and work with future software developers" to implement the new system, Otellini said. "La Grande is not a Pentium 4 product. It will be a next-generation architecture."
And if you'd like a look at the Trust Chip embedded inside the existing Prescott CPU itself, look to the Micrograph at the bottom of this page. The Trust system eats up about 20% of the CPU die with an entire second CPU and Trust architecture to watch the main CPU.
AMD, Transmeta, and the other CPU makers all have projects to embed the Trust system inside the CPU itself. Oh, and as the recent Slashdot story on the uber-powerful Cell Processor pointed out, it too will have on-chip DRM system. That "DRM system" is doubtless none other than Trusted Computing.
I wouldn't be supprised if motherboard-based Trust chips are pretty much obsolete by the time Microsoft's Longhorn rolls out. (Longhorn a.k.a. Palladium)
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.