TCPA Support in Linux 501
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."
TCPA is a DRM smokescreen (Score:5, Informative)
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 [eff.org] 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.
Apparently this is not the first time... (Score:3, Informative)
Go to the Linux Journal search function [linuxjournal.com] 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.
As sad as it is (Score:5, Informative)
TCPA - TCG (Score:4, Informative)
TPM emulator (Score:2, Informative)
Comment removed (Score:5, Informative)
Newspeak Framing at its finest (Score:2, Informative)
Gentoo's public communications guy needs to read some George Lakoff [gracecathedral.org]. It's a wonderful life, folks. Every time you use their words, a devil gets his pitchfork.
Re:Trusted Linux is ILLEGAL (Score:2, Informative)
TCG and Linux make sense (Score:3, Informative)
It's kind of ironic, because Ross Anderson's lying Anti-TCPA [cam.ac.uk] 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 [ibm.com], Trusted GRUB and Secure GUI [prosec.rub.de], tcgLinux [ibm.com], TCPA Open Source Platforms [crazylinux.net], Enforcer [sourceforge.net], 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.
Re:Software DRM (Score:4, Informative)
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 [prosec.rub.de] 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 [ibm.com] 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.
Re:Trusted Linux is ILLEGAL (Score:4, Informative)
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's writing about "trusted" computing (Score:4, Informative)
Re:what is it good for? (Score:3, Informative)
LOSE...not loose. You can lose money...you can turn a dog loose. Two different words...two entirely different meanings.
Re:TCPA is a DRM smokescreen (Score:4, Informative)
And casinos likewise operate without any oversight or auditing whatsoever. Millions of people play these games every day. Adding security can only benefit them.
No, adding a sense of false security does not make things better. People who play on online casinos today do not expect there to be software controling that the game is fair: to the extent they care they go by reputation and testing just like I suggested. TCP adds nothing - absolutely nothing - to make this more secure. The same thing goes for voting.
You're the one who's got to be kidding! Have you not heard of the many new forms of malware which are going after banking account numbers and infiltrating themselves into secure banking transactions? TC can stop these cold via sealed storage and remote attestation. Again, you are arguing that we should deny users access to these technologies purely for political reasons because you don't like the technology.
If the TCPA application of your bank were intended to stop malware, then it would have no problem with the EFF's proposed owner override. So once again with the lies!
I won't go through the rest of your "analysis" because it's the same kind of bullshit.
LOL. "I won't even begin to counter your arguments that the world is round because it is such bullshit."
My guess is that you are worried that TC will make it harder for you to pirate your favorate songs and movies.
No, no, try harder: what I actually care about is abudcting and sexually abusing small children. And strangling puppies. And helping the turrists!
TCPA is a technology designed from the ground up for exclusion. The fundamental question of the next century, as with the previous ones, is whether we wish to build and open society or a closed one, and TCPA is ultimate tool for those who wish to close our networks. The goal of TCPA is facilitate the handing over of control of our communication devices to others, so that our computers can decide what we cannot and cannot do with them, can and cannot run with them (if we still wish to access our data and the Internet), and ultimately dictate the parameters of all networked communication. Anyone who accepts TCPA accepts that he should live in digital prison, that his doors should be locked from the outside, that a priori restraint should be placed on his ability talk to others, and that not only the Internet, but all computing and all our data should be placed in the hands of a centralized few.
You, sir, disgust me.
Re:Here comes the flood?? (Score:5, Informative)
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 [prosec.rub.de], 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 [ibm.com] or the Enforcer [sourceforge.net].
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.
Re:Finally ready for the main stream (Score:3, Informative)
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.
Re:Here comes the flood?? (Score:3, Informative)
From the Inquirer: [theinquirer.net]
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: [my-esm.com]
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. [chip-architect.com] 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)
-