Slashdot Mirror

← Back to Stories (view on slashdot.org)

IBM On Trusted Computing, Linux

Posted by timothy on from the trust-us-it's-linux dept.

An anonymous reader writes "A number of IBM's computers have been available with an "embedded security subsystem (ESS)" for some time now. This site lists three research papers regarding the new TCPA (Trusted Computing Platform Initiative) security chip developed by IBM, including the full GPL-ed source code to a Linux driver for this chip. In particular, the 'Why TCPA?' paper claims that IBM's TCPA chip is in fact of extremely limited use for DRM, as it contains no tamper resistance; the chip is designed to fend off software attacks, not physical attacks. An interesting take from a company with very solid products."

6 of 36 comments (clear)

  1. DRM == no sale. by Anonymous Coward · · Score: 1, Interesting
    It's that simple.

    ~~~

    1. Re:DRM == no sale. by brianjcain · · Score: 5, Interesting
      Apparently not...(Did you RTFA?) I had always been against TCPA, but here's an excerpt:
      What TCPA is Not Some of the papers critical of TCPA claim that TCPA is primarily intended to support Digital Rights Management (DRM), such as the copy protection of music or video data, on behalf of the content owners. They argue that TCPA would take away user rights on their own machines, preventing backup, time and space shifting of legally purchased content. Debating the merits of DRM is a complex, controversial topic, and won't be covered here. ... (Personally, I do not believe it is possible do provide effective copy protection at all, but that's another paper).

      The TCPA chip is not particularly suited to DRM. ...
      If you ask me, I would think Linux, et al could leverage whatever benefit provided by well-documented TCPA chips (if any), and ignore the others. You probably already didn't like Microsoft's software anyways, so why waste time worrying how they'll utilize TCPA?


      (Now gov't mandating of TCPA hw/sw is some seriously dangerous shit. Let's keep way away from there).
  2. Absolutely Terrific Articles by stanwirth · · Score: 3, Interesting

    These are absolutely terrific articles. Their distribution of an open source TCPA linux module satisfies a lot of concerns and questions many of us had about TCPA in a concrete and specific manner.

    One concern still exists: that DRM and Palladium will be used to create a "mainstream" set of M$ applications which give people the illusion of security, while concentrating most of the information and control in the hands of the few.

    The most important step people in the open source community can take next are to get a system with a TCPA chip and start developing drivers, firewall systems, proxies and applications that make good solid use of the technology: tsshd, tsquid, tsftp, thttpsd, tbsd, toggd, tnamed, texim, tkonq...

    1. Re:Absolutely Terrific Articles by Gerry+Gleason · · Score: 3, Interesting
      The most interesting part is that TCPA isn't designed for DRM, but isn't that what Palladium is based on? Of course, the DMCA makes it illegal to snoop your own machine ... So it will be easy enough to break any DRM keys and encryption, but it will be against the law. Hmmm, I wonder what people will do, I'll just keep using Linux.

      And yes, it will be important to use the TCPA hardware as intended to help with client security. Open/Free Source implementations of secure tools and protocols might even support profitable services based on quality reference implementations.

  3. The big question by spitzak · · Score: 4, Interesting
    The paper seems to skip around the huge unanswered question:
    Is there a private key that third parties know that it is impossible for the owner of the computer to know?

    The paper makes it sound like all key pairs are either randomly generated or that the chip can be fed a public key. However it is a bit vague, and I suspect the answer is that there are also non-random pairs in there, where third parties know the private key but you don't. They skirt around this by saying "Bios startup is quite complex" but I think the real answer is that there unless hashes have matched up to a point these secret public keys are inaccessible.

    This system is absolutely useless for security as all exploits actually cause supposedly correct programs to follow the wrong instructions. This is like claiming current systems are secure because you cannot change the microcode and invent new machine instructions. It's purpose is so that it is impossible to get any kind of modified or different operating system in there, and still be able to run DRM programs, which could decode information using the secret key.

    The fact that IBM and everybody else has refused to answer this question (I think the answer here was skirted around with some bullshit about the "BIOS startup being quite complex") makes me think they are lying.

    The fact that having a high-speed encryption chip is quite useful is being used to hide the real purpose. Do you really think the same people who think Winmodems are a good idea are that interested in adding hardware just to speed up a function that can be done in software?

    They also make a point about the random key generation, which is interesting, because it keeps the private key completely in the hardware where no program can see it and thus be fooled to reveal it. However I am curious if this is actually a defense against any real exploits. I have not heard of exploits that involve revealing the private key of a previously-negotiated pair, most involve fooling the system into doing something unwanted through an already opened and legitimate channel, or fooling it into using another public key that the attacker already knows the private one for. Can any experts find any real exploits where a temporary and untransmitted private key was revealed? If not then I would also suspect this is a smoke-screen, attempting to turn the fact that the chip has secret keys into a benefit. I would also think that 99% of the benifit, if any, could be achieved by loading the chip with a random pair and then making sure the program has eradicated all knowledge of the pair. There have been expoits in weak random number generators, and in this case the random number generator is in hardware and no longer easily fixed.

    and even the fact that you can generate key pairs

    1. Re:The big question by jareds · · Score: 4, Interesting

      The paper seems to skip around the huge unanswered question: Is there a private key that third parties know that it is impossible for the owner of the computer to know?

      The second paper on the page answers that question in the affirmative (sort of). The private part of the endorsement key is stored on the chip, the manufacturer may record the public part. The paper states that IBM does not currently and has never recorded endorsement keys. (Note that technically the answer to your question is "no": there would be a private key that the user does not know, but no third party would know it either. You misunderstand public key cryptography. However, your general point is well-taken, because the endorsement key could be used to implement DRM, subject to the obvious caveat the author brings up, that it would be vulnerable to local hardware attacks.)