Slashdot Mirror

← Back to Stories (view on slashdot.org)

TCPA Support in Linux

Posted by CmdrTaco on from the trust-no-1-or-something dept.

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

9 of 501 comments (clear)

  1. TCPA is a DRM smokescreen by Hobbex · · Score: 4, Informative

    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.

    1. Re:TCPA is a DRM smokescreen by Hobbex · · Score: 3, Informative

      The tenacity of your attempts to replace logic with rhetoric would be impressive if it wasn't so braindead.

      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.

  2. As sad as it is by Anonymous Coward · · Score: 5, Informative

    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.

  3. TCPA - TCG by SiliconEntity · · Score: 3, Informative

    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.

  4. Re:Do we really need it ? by danheskett · · Score: 4, Informative

    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.

  5. Re:Software DRM by SiliconEntity · · Score: 3, Informative

    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.

  6. Re:Trusted Linux is ILLEGAL by SiliconEntity · · Score: 3, Informative

    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!

  7. RMS's writing about "trusted" computing by latroM · · Score: 3, Informative

    RMS has written a nice article about it: see http://www.gnu.org/philosophy/can-you-trust.html

  8. Re:Here comes the flood?? by SiliconEntity · · Score: 4, Informative

    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.