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

16 of 501 comments (clear)

  1. Finally ready for the main stream by kaustik · · Score: 4, Funny

    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

    1. Re:Finally ready for the main stream by yason · · Score: 4, Interesting
      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.

      It has been my understanding that trusted computing equals not DRM automatically. Trusted computing is initially neutral technology: the barriers are built up only after the chip gets to choose a side. You can let Microsoft turn your PC into a DRM environment using TCPA's technology but that's the Microsoftish / {MP,RI,??}AA'ish approach. You can also use TCPA to turn your Linux box into a hardware-reinforced installation of your choice. If TCPA was widespread, you could for example control how the bastard big co. digitally uses, views and copies personal information when you buy something on their website.

  2. Tee hee... published before editing was finished by PornMaster · · Score: 4, Funny

    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
  3. Do we really need it ? by CineK · · Score: 5, Insightful

    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]sb31350717901017685 42287578439snlbxq'|dc
    1. 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.

  4. Linus Torvalds himself has blessed DRM by Xpilot · · Score: 5, Insightful

    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
  5. Lacking One Thing by SpottedKuh · · Score: 5, Interesting

    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.

    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/ind ex.html

  6. Re:If you can't beat 'em, join 'em. by SpottedKuh · · Score: 5, Funny

    Trusted Windows

    Wait, wait...you lost me on that one.

  7. Wouldn't that be... by GbrDead · · Score: 4, Funny

    Treacherous Gentoo?

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

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

    1. Re:As sad as it is by cayenne8 · · Score: 4, Insightful
      " This is not flamebait. I hope someone with a brain mods you up...If anything, the original parent was the flamebait..."

      In general...sure...TCPA could have some positive effects on the computing community. However, it also has great potential to be slipped in...and eventually, by law, it must be used to lock things down. Only a few things at first...but, eventually could mandate a great deal of limitations as to what you can legally do with a computer. As much as the corporate entities are beginning to use the govt. to legislate things...and they really don't like the fair use we do have...it is easily possible to forsee this as a means to that end.

      Taken long enough...it could happen, which is why you need to take things like this slowly and with a great deal of skepticism early on.

      I heard it said before that "What one generations tolerates....the next generation embraces"

      Think of it this way...the article the other day on /. about how many US kids don't understand what the 1st amendment really means...they haven't been taught about it...and we're tolerating loss of freedoms. When they are grown and we're not around...they won't even know they existed in the old form...

      --
      Light travels faster than sound. This is why some people appear bright until you hear them speak.........
  10. Re:what is it good for? by vadim_t · · Score: 4, Insightful

    Well, it could be useful for a seriously locked down server.

    Imagine that you're an admin at some big company, with a hundred Linux boxes. You have this stuff on every of those boxes, and a computer for administration somewhere safe. When you install software you first check it, then sign it, then push updates to your servers.

    If somebody gets in, they'll have things quite difficult. Anything unsigned simply won't run at all. Rootkit modules, exploits, etc, will all simply not be able to run at all. This would take out a quite big part of the exploits an attacker could use. Remote ones would hopefully avoided by NX.

    This wouldn't protect against things like races, but it certainly could help quite a lot.

    The situation above is something I wouldn't have any problems with. If an admin wants to have an uber-locked down system where anything not signed by his key that's only present in a computer with no network connection in a secure room with an armored door doesn't run at all, then sure, why not. I'm fairly sure this can mostly be accomplished without hardware support at all, though.

    Now, it's when software publishers want to make it impossible for me to control my computer when I have problems with it. But if the user has full control of it, I think it could come quite handy in some cases.

  11. Here comes the flood?? by Reziac · · Score: 4, Interesting
    From TF WhitePaper [PDF] on IBM's site:

    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?
    1. Re:Here comes the flood?? by Greger47 · · Score: 5, Interesting
      This is the thing that I don't get. The supposedly secure boot process seems to be broken from start to finish.
      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.
      The whitepaper also mentions that in IBMs implementation the chip is connected to the SMbus.

      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.

      In the case of DRM this lets me run whatever OS I want. The only thing I have to do is to feed a copy of whatever OS Hollywood trusts to the chip and voila the chip will say I'm legit and Hollywood will give me access to their movies for me to pirate at my leisure. :)

      As I see it, the only way to get this to work for real is if Intel steps up and builds TCPA support into the CPU itself such that the PCR register is continuously updated as each instruction is executed. And all existing external chips have to be blacklisted, ofcourse.

      Or does the TCPA system have some other trick up their sleeve that makes this work even though it's implemented externally to the CPU?

      /greger

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