Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

IBM Trials TCPA Chip Under Linux 442

Posted by michael from the trial-by-fire dept.
keihin writes "From IBM: IBM's Global Security Analysis Lab (GSAL) has done extensive analysis of the Trusted Computing Platform Alliance (TCPA) chip available on some IBM systems. We have the chip running under Linux, and have studied it extensively. In order to clarify a lot of misunderstanding about the chip, we are making available some helpful white papers and open source device drivers for Linux, so that interested people can test and use the chip in an open environment."
This discussion has been archived. No new comments can be posted.

IBM Trials TCPA Chip Under Linux More

IBM Trials TCPA Chip Under Linux

Comments Filter:

  • Great news (Score:2, Flamebait)

    by Amsterdam Vallon ( 639622 )
    I had previously thought that only Intel was involved in the TCP Alliance, but it's good to see that IBM is on-board as well.

    Check out *nix.org [qhcf.net], a dynamic, informative, and fun portal for fans of BSD, Linux, OS X, & Solaris!
    • Apparently, the TCPA folks keep the list of companies involved private which is why I had never really heard of anyone aside from IBM involved in this alliance.

      However, there's a full list here [notcpa.org].

      Check out *nix.org [qhcf.net], a dynamic, informative, and fun portal for fans of BSD, Linux, OS X, & Solaris!

  • just remember.... (Score:4, Interesting)

    by Anonymous Coward on Friday January 24, 2003 @10:13PM (#5154857)
    Real World TCPA != DRM

    Microsoft's TCPA == DRM

  • This is NOT about digital rights management (Score:5, Informative)

    by metamathica ( 607019 ) on Friday January 24, 2003 @10:14PM (#5154863)
    Before people get too confused and start to complain (quite reasonably) about the RIAA, MPAA, etc: this chip is not designed to facilitate DRM. In their "why TCPA" article, they explain why it's not even particularly well suited for such systems.

    Rather, it's primarily about protecting a user's private keys and facilitating (through hardware acceleration) a serious increase in the use of encryption to promote security and privacy.

    • Re:This is NOT about digital rights management-II (Score:2, Interesting)

      by Anonymous Coward
      "Rather, it's primarily about protecting a user's private keys and facilitating (through hardware acceleration) a serious increase in the use of encryption to promote security and privacy."

      In other words. It's no different than buying an add-on board with a crypto processor. Has anyone found out how much this will all cost?
      • Please stop saying,
        • "it's primarily about protecting a user's private keys...",

        The keys in TCPA hardware are not "your" keys at all. When you talk about "somebody's keys" you should mean their personal keys which they use to identify themselves, e.g., to sign their email, to login, etc.

        The keys you are talking about are the keys inside and belonging to the TCPA-enabled PC, settop box, or other electronic device. These keys are used to control functions specific to that particular piece of hardware.

        If the keys in TCPA hardware were really "your" keys, you could copy them whenever you like and take them with you to whichever device you happened to be sitting in front of. But you couldn't do that with TCPA because you're not allowed to. TCPA means parts of your PC can get locked down permanently.

        With TCPA you are no longer free to upgrade your PC when you like, how you like. You lose your existing privileges.

        TCPA really means lockdown enabler.

    • this chip is not designed to facilitate DRM. In their "why TCPA" article, they explain why it's not even particularly well suited for such systems.

      Whenever anyone claims this always ask the following question: does the owner of the chip (i.e. the owner of the computer in which the chip resides) have full access to all keys embedded within the chip? If not, why not, if not to facilitate DRM?

      • Re:This is NOT about digital rights management (Score:4, Informative)

        by Wesley Felter ( 138342 ) <wesley@felter.org> on Friday January 24, 2003 @11:43PM (#5155127) Homepage
        does the owner of the chip (i.e. the owner of the computer in which the chip resides) have full access to all keys embedded within the chip?

        From reading the PDF, the answer is sorta. You can ask the chip to generate a new key pair, and then you can later enable/disable/delete that key pair whenever you want. But the private keys don't ever leave the chip.

        • Re:This is NOT about digital rights management (Score:4, Insightful)

          by manyoso ( 260664 ) on Friday January 24, 2003 @11:44PM (#5155135) Homepage
          Exactly. Without access to the actual key pair then the end user does not have control over his own computer. This facilitates DRM and not much else.
          • How does "the end user does not have control over his own computer"? The chip only does what the OS tells it to do, and the user uses whatever OS he wants.

          • Re:This is NOT about digital rights management (Score:5, Interesting)

            by iabervon ( 1971 ) on Saturday January 25, 2003 @12:35AM (#5155285) Homepage Journal
            But it doesn't facilitate DRM at all; the private key never leaves the chip, and it isn't set until the user sets it. This makes it useless to anyone *except* the user; the MPAA doesn't have the key or even the chip. The user, at least, has the chip.

            Public key cryptography works best if the user can apply the key, but cannot leak the key no matter what.

            It would be rather different if the private key on the device was known to some content provider, but this setup couldn't be used for DRM even if you tried to. The closest thing would be a content provider giving you a file that only you could read; but you can still do whatever you want with it once you read it.

            • Private / Public key (Score:3, Informative)

              by jbolden ( 176878 )
              But it doesn't facilitate DRM at all; the private key never leaves the chip, and it isn't set until the user sets it. This makes it useless to anyone *except* the user; the MPAA doesn't have the key or even the chip. The user, at least, has the chip.

              They don't need your private key; they need your public key. All they need to know is that the private key is unique to your machine. Here is why:

              1) I give you a file encrypted using the public key from a trusted application running under a trusted nub/tor on your machine using a valid TCPA.

              2) because the tor/nub key is based on your TCPA key its only usable on your machine's trusted environment and not anyone else's even if they have exactly the same software

              3) because the tor/nub key is based on the tor/nub its only usable when running under the same tor/nub which means I can confirm that the OS isn't running on a virtual machine. That means I can trust the OS.

              4) Because of the trusted OS I can control what applications have the last part of the key and those can confirm with the OS that they are running in a trusted mode.

              That's how DRM works. You bootstrap trust. As long as you the CPU won't let emulate a call to the TCPA chip and the TCPA chip generates the keys for the tor/nub you have a signed hardware/software environment.

            • But what if I want to take my personal private key to work so that I can decrypt messages sent to my home email address while I'm there? (Which I do now.)
    • This is all about DRM and you are spreading FUD. The rebuttal to Ross Anderson's FAQ is similarly a bunch of FUD.

      IBM is very involved in the fight to restrict consumers rights and TCPA is the bridge technology they wish to use for DRM. Just because IBM has been good to the linux community is not a good enough rational for letting them off the hook when it comes to TCPA and DRM.

      For all of you who don't get this then understand that when IBM and Microsoft talk about 'Security' they are talking about security for the publisher and *not* the owner of the computer.

  • DRM, DRM run for the hills! (Score:4, Funny)

    by briancnorton ( 586947 ) on Friday January 24, 2003 @10:18PM (#5154881) Homepage
    Well that's the last straw, I'm switching to

    Aw hell, I might as well stick to windows.

  • I much much rather have TCPA then pallidium (Score:5, Interesting)

    by Billly Gates ( 198444 ) on Friday January 24, 2003 @10:20PM (#5154890) Journal
    I view TCPA as more of a security enhancer then for drm. I trust IBM more then Microsoft to make sure Linux will run with it and it has alot of cool features.

    I like the extra random number generator chip as well as the encyption chip. I can imagine it would help e-commerce greatly and can be used for programs that require random number generation. Also hardware does not need to be modified. Only the motherboard. Microsoft wants each component to trust each and have it encyrpt everything. Its scary because its so proprietary. In the Xbox even the intel pentiumIII chip encyrpts and decypts data. Infact it will not run any assembly code unsigned. Spooky.

    I hope IBM horries up and convinces other OEM's to use TCPA before they decide on using pallidium. Also IBM has been selling TCPA systems for close to 2 years now. SO yes they are not a threat to freedom or a drm sollution backed by hollwood.

    • Re:I much much rather have TCPA then pallidium (Score:4, Interesting)

      by Arethan ( 223197 ) on Friday January 24, 2003 @11:12PM (#5155044) Journal
      Hardware SSL encryption engines are already available as PCI expansion cards. They've been available for years. I'm not a buff on TCPA by any means, but TCPA really seems to look like just another integrated peripheral that is probably better off being an expansion card. (Kind of like integrated AGP video. Mmmmm....S3VirgE MX! lol)

      Honestly, how many applications are going to use SSL encryption so often that the CPU is incapable of performing the additional grunt work? Even if every website on the Internet was SSL encrypted, your old 233Mhz Pentium still has a shitload of spare cycles to throw at en/decoding the data streams. The only systems that really benefit from the hardware encoder/decoder are secure webservers. The ability to offload that little bit of processing gives them the ability to handle a few more requests per second.

      As for the secure storage of SSL keys. I can't wait until my mainboard dies, and I can't get my keys off the damn chip. I suppose you could buy another identical board and attempt to swap the chips, but I'll warn you right now that surface mount soldering by hand is an extreme bitch.

      And it really isn't like you're going to get that much extra security out of the deal. So your keys aren't on the harddrive anymore. So now people can't get your keys by stealing your tape backups anymore. What happens when you have a fire? Hope you have a really good memory and a nice hex editor to retype the keys with. And what is to stop any processes at all from reading all the keys out and emailing them to a hotmail account? Only allow priviledged processes to access the chip? How do you define with process is priviledged?

      Sorry, but I'll stick to the expansion cards. At least if something bad happens I can replace those relatively cheaply and easily.
      • And what is to stop any processes at all from reading all the keys out and emailing them to a hotmail account? Only allow priviledged processes to access the chip? How do you define with process is priviledged?

        The key never leaves the chip. No process at all ever has access to the key. The chip does the decryption itself as a black box.

        • The key never leaves the chip. No process at all ever has access to the key. The chip does the decryption itself as a black box.

          Well, I'll state the obvious and say that I consider it an essential feature to be able to copy out (securely) any and all keys the chip has generated, and if the chip does not have that feature then I certainly must question the motives of the designer. There, I said it would be obvious.

  • At least read some of it before commenting... (Score:5, Insightful)

    by 26199 ( 577806 ) on Friday January 24, 2003 @10:22PM (#5154897) Homepage

    The white paper explains why it would be easy to circumvent this chip if you have physical access to it.

    DRM it is not.

    They've released full GPL source code.

    Looks like it could be useful.../p>

    • No, it is not DRM, but that is what it will be used for!

      IBM is being dishonest when they suggest that TCPA is security for the end user. It is not and they are actively working with the big media companies to come up with DRM. TCPA is part and parcel of this effort. Any suggestion otherwise is just putting your head in the sand.

  • Whitepaper biased (Score:3, Insightful)

    by Anonymous Coward on Friday January 24, 2003 @10:23PM (#5154905)
    It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased. If you read the author's section on DRM in the TCPA rebuttal you get a feeling like you're reading a post on slashdot.

    Comments like: "I have no problem with people arguing against DRM; I agree completely." should not be there. It's ok to agree/disagree with DRM, but not in public documents with your employers name on them.

    Just my $.02 CAN.

    Jason

    • OTOH perhaps it's good to be unusually open about it in this case... at least *some* of the well-rounded and intelligent people who hear about it will read that far, and discover it's not about DRM.

    • It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased.

      I agree that the whitepapers seemed to use the phraze "I personally" a bit too much (one calls DRM "stupid"!) -- but to me it seems like they wanted to quickly put something together to help inform the Linux community (and possibly the Slashdot community in particular) of what TCPA is all about.

      I'm glad they released something to help curb all the negative FUD that I keep seeing. It still doesn't seem to be helping much, since over half the comments here are anti-TCPA FUD themselves (and most of the "facts" I'm seeing in this story's comments are in fact addressed in the rebuttal document linked in the story).

    • The tactic (Score:3, Interesting)

      by jbolden ( 176878 )
      All the hardware companies are pulling this tactic. "Oh we are just putting TCPA capabaility" its that evil Palladium/DRM that is going to be the problem. You heard the same thing from AMI. I think that does represent IBM's position.

      1) Hardware companies "just provide" TCPA
      2) OS companies "just provide" the capacity for trusted apps
      3) Trusted ap makes "just provide" the ability for people to send you data securely
      4) Digital content companies are just taking advantage of existing technology to prevent unauthorized redistribution
      5) Fair usage doesn't exist anymore in practice

      The fact that 1 enables 2 enables 3 enables 4 enables 5 is supposed to escape the public. So when we have a world were fair use has been completely repealed there isn't going to be anyone to blame.

  • Passing the blame. (Score:4, Insightful)

    by Phoenix823 ( 448446 ) on Friday January 24, 2003 @10:29PM (#5154921)
    While perhaps technically inaccurate as to the difference between TCPA and Palladium, I think the spirit of the attacks made against the platform are valid. While yes, perhaps TCPA doesn't directly enable all the horrible things we Slashbots complain about, but the paper is just passing the blame.

    IBM says "this has nothing to do with DRM. In fact, it doesn't protect it from owner-tampering so it's not any great DRM replacement." Of course, they don't mention that it's more than likely that in the near future, a version of Windows will take advantage of it. Maybe the OS will encode all recorded music with your public key so it's unplayable on any other machine? Who knows, the possibilites really are limitless.

    I wonder how many TCPA computers will be running Windows with Palladium enabled. Neither paper seemed to be catering to a very tech-head audience, so why make needlessly complicated distinctions between TCPA, Palladium, databuses, etc?

    • Re:Passing the blame. (Score:5, Insightful)

      by Billly Gates ( 198444 ) on Friday January 24, 2003 @10:41PM (#5154975) Journal
      Well the good news is that you can turn it off. The bad news is that the email from grandma may require palladium and not TCPA. TCPA is different [trustedpc.org]then Palladium and has been in use since 99 on almost all IBM systems. Ask any ThinkPad owner. Also there are only 2 chips in the motherboard that make up the TCPA as well as a special bios.

      In palladium each component must be certified and it uses a trust relationship to prevent tampering. To me palladium sounds like a way for Microsoft to make sure you can not upgrade more then afew components at a time without paying the piper but who knows. It sounds more stict and anti-user. Also rumours have it that Bill Gates wants to use palladium as a way to stomp out piracy in asia and they also view OOS as the bigggest competitor since os/2. Scary.

      TCPA was formed to secure and enhance e-commerce as well as secure corporate desktops. In this day and age the security is greatly needed.

      If hollywood wines and complains and the hollings bill passes, I prefer TCPA anyday and its a more open and industry standard solution. Linux will be supported since any thid party can sign it and no company is the "official" gatekeeper. Think SSL. The gatekeeper argument is the scariest and as long as it stays open then its not a problem. IBM has invested billions in Linux and wants it to susceed.

    • Maybe the OS will encode all recorded music with your public key so it's unplayable on any other machine? Who knows, the possibilites really are limitless.

      Why does an OS need TCPA to do this? In fact, IIRC Windows Media Player does something like this now, by default even. TCPA doesn't enable this (or more correctly, absense of TCPA doesn't make this impossible).

      TCPA is basically this:

      - Generates key pairs (a fast DSP)
      - Stores key pairs
      - Performs encryption/decryption, only if everything is okay

      The "everything is okay" part simply means that the BIOS hasn't been messed with, and the OS is in a known state. Yes, this will prevent (say) using Linux to decrypt data that you encrypted while in Windows -- but it also goes the other way (data encrypted under Linux can't be decrypted under Windows). That's the beauty of it; an attacker can't just pop a boot disk in and try to read your data.

      I think the confusion is that the term "Trusted Computing" sounds a lot like what we all heard about Palladium -- but it is NOT the same thing. Palladium asks for a lot more than TCPA, and at the present Palladium isn't designed for TCPA. They want (and have patents on) their own hardware implemented, as well as CPU hacks, and other junk.

      TCPA isn't even a part of the Palladium picture.
  • We all know that TCPA is meant to be trusted computing but i also see many issues with it. For ex, the integration of DRM into the whole equation by microsoft. I can easily envision them integrating it into their WMP 9 technology and preventing all those without TCPA access to the media. Next is the whole issue of what is "trusted". Is Open Source software trusted? What about compiling a custom kernel. Will that jeopardize the trustedness. Another issue i have is with a possible encrypted hard disk. Will criminals and terrorists sabotage their OS rendering the hdd unreadable?
    • I can easily envision them integrating it into their WMP 9 technology and preventing all those without TCPA access to the media.

      TCPA isn't needed for this, and in fact doesn't really do much to help this type of DRM. How can you encode files on your machine, that require a chip on my motherboard -- well, to do what, exactly?

      ---

      Imagine a cracker breaks into your machine one way or another. He can currently find your PGP key, your SSH keys, etc, very easily.

      Now imagine if those keys were instead generated and stored on a special chip on the motherboard. The chip itself handles the decryption, so the key never needs to leave the chip. Even further, if something changed in the environment (specific things that might indicate a virus, worm, or other breach), the chip will not decrypt the data.

      Wouldn't that be pretty damned secure? Well, basically that is TCPA.

      TCPA is not particularly well suited to DRM applications, as this was not its intent.

  • what about the OS securing features (Score:4, Interesting)

    by samantha ( 68231 ) on Friday January 24, 2003 @10:29PM (#5154924) Homepage
    As far as I can tell, it wouldn't be difficult to build systems running say, Win XP, with the hashes marking the trusted OS keeping any other OS from being loaded and successfully booted on the machine. Of course this is more like with a Palladium based machine. But this spec also allows it from what I got out of the paper.

    Also, regardless of the author's opinion, a chip that enables DRM even sub-optimally is not the friend of the people.
    • But this spec also allows it from what I got out of the paper.

      Funny, I got this from the paper:

      The TCPA chip does not and cannot control execution!

      Which means it will NOT prevent any operating system from booting. It will prevent an operating system environment from decrypting data with the chip if it's not the OS that was used when the data was encrypted -- but that works in both (all) directions.

      Plus, of course the features offered by the chip can be disabled in the BIOS.

  • Some nice quotes from the misinfo rebuttal (Score:5, Insightful)

    by pridkett ( 2666 ) on Friday January 24, 2003 @10:30PM (#5154929) Homepage Journal
    For those of you who didn't read the stuff:


    The bottom line is that TCPA and Palladium are two different projects. The TCPA hardware provides only a subset of the full Palladium functionality, which includes significant additional hardware and software elements. Only TCPA already has a freely downloadable detailed specification, and a tested port of all driver and library level software to Linux.


    Don't get completely up in arms about this is what is trying to say. Then he has an even better quote later:


    My personal opinion (not speaking for IBM) is that DRM is stupid, because it can never be effective[6,7], and it takes away existing rights of the consumer. But this is not the place for that debate. To condemn TCPA for the ability to run a bad application is absurd. This argument is exactly like the arguments of governments in their attempts to ban encryption, under the rationale that encryption can be used by terrorists to hide their messages.


    Ahh...it's great to take stuff outta context.
    • I've read that FAQ and it does not change that fact that TCPA _is_ about DRM. It is security for the publisher not for the end user. Regular ordinary users have no use for TCPA other than as a key for big media to take away Fair Use rights. Have a look at the Electronic Frontier Foundation for some clear thinking on this.

  • TCPA talk at Defcon X (Score:2, Interesting)

    by 968134 ( 454238 )
    I'm not sure why there seems to be such a mixed reaction to this news. From the talk that Lucky Green gave at Defcon X this past summer, I saw nothing but heaping stacks of badness to come from the TCPA. To quote the talk description from the Defcon website:

    "This tamper-resistant Trusted Platform Module (TPM) will enable operating system and application vendors to ensure that the owner of the motherboard will never again be able to copy data which the media corporations or members of the TCPA don't wish to see copied, or to utilize the TCPA's software applications without pay."

    Sounds like DRM to me.

    • Re:TCPA talk at Defcon X (Score:2, Insightful)

      by Anonymous Coward
      read the f-ing article's whitepapers, damnit! It refutes what Lucky Green was saying at Defcon - he (Lucky) gets TCPA confused with Paladam & DRM - making it out to be the boogieman it isn't.
    • Is complete unsustantiated bs according to the second white paper, with a detailed analysis showing how much of it is pure fiction
    • There are 3 ACs all saying "read" the paper. The paper does not refute the points in the defcon talk lets take the first example from the paper. This "refutation" relies on shifting the topic away from the import part.

      The terms copy protection and DRM do not appear anywhere on www.trustedpc.org. They were not the main business objectives, and the resultant chip is not
      particularly suited to DRM, being poorly defended against owner tampering. The main goals are
      to secure the user's private keys and encrypted data against external software attack.

      He is absolutely correct nowhere in the TCPA specification is DRM mentioned. Neither however is his "main goal". Further he obscures the issue by focusing on the wrong part of the spec. Good quality encryption is not what makes DRM possible; good quality encryption combined with verifying the status of the machine at boot OTOH does. That is what makes DRM possible is the fact the OS can tell whether its running inside a VM or not so the trusted component of the OS (the tor/nub) can then confidentally tell applications that they are running in a secure environment. Without this Microsoft could have all the DRM they wanted; you just run the OS inside a debugger and pull the license keys right out of the application's memory space.

      Further he even agrees with this, he mentions this in a positive light as "preventing viruses from getting sensitive information" but it can just as easily prevent any other "unauthorized" applications getting their hands on sensitive information.

      He does refute the tamper resistant but in terms of DRM that's irrelevent.

  • Quick notes for spastic no-read replies: (Score:5, Informative)

    by moogla ( 118134 ) on Friday January 24, 2003 @10:39PM (#5154970) Homepage Journal
    1) IBM doesn't care about DRM. In fact, this chip is completely unsuitable for DRM (and the white paper author was kind enough to explain why... protects you from SOFTWARE attacks, not hardware.)

    2) The specs are open. There is a gratis GPLd demonstration driver/API for linux.

    3) (My impression) is that it helps solve certain security chicken and egg problemswhen you want to do things like mount an encrypted hard disk, but not want to store the decryption key in memory.

    4) Primary advertised use: for signing and verifying your OWN code, i.e. to protect yourself from root kits.
    • Primary advertised use: for signing and verifying your OWN code, i.e. to protect yourself from root kits.

      Gunna be a big score for Gentoo!
    • It does not 'protect' the end user from anything. It protects the publisher from the end user. It does not matter if the specs are open and a GPL demonstration has been written. The _use_ of this technology is for DRM and claims to the contrary are dishonest.
      • It can be used to boot a secure OS, yes. But it won't prevent you from doing it if you want to (especially since you get to define which OS is valid; this is an advertised feature)
        It also provides a way to do things like verification hashes or cert checking outside the CPU. You can stick a private certificate in it and sign/encrypt stuff all the live long day without worry that your system gets rooted and your private key or ipsec.secerts compromised.
        The hacker would have to come into the server room and remove the chip, at which point they have a slim chance of opening it up and getting the key out (...its not hardened). But if they can do that, then you're screwed anyway. (See the previous article on AT&T and tumbler lock vulnerabilities)
        Thats basically what it does. Also, a builtin RNG in case you don't have an i810 chipset.

  • Even with TCPA... (Score:4, Funny)

    by WetCat ( 558132 ) on Friday January 24, 2003 @10:51PM (#5155001)
    I can run UNIX inside JavaScript [junix.kzn.ru], and be fine...
    (in russian - documentation - use babelfish to
    read - at http://junix.kzn.ru/)

  • Big claims... (Score:4, Insightful)

    by Goonie ( 8651 ) <robert.merkel@b[ ... g ['ena' in gap]> on Friday January 24, 2003 @11:02PM (#5155024) Homepage
    From reading their discussion paper, they claim TCPA can be used to (amongst other things):
    • Generate a public/private key pair, the private part never leaves the TCPA chip.. That's kinda nifty, because even if the bad guys get a root compromise on your system they still can't get your private key. They could however use the TCPA system to decrypt messages USING your private key though, until the root compromise was discovered and removed. So, kinda nice, but not a panacea.
    • Put critical data (eg the encryption key for an encrypted FS) in a secure register that can't be accessed if "the operating system environment" is changed. I would need to spend some time reading the TCPA specification to understand exactly how they intend for this to work, but I'm dubious about this example. Once this data gets out of the secure environment, it's vulnerable to compromise, so in this case I don't see what this adds over keeping the key in the user's head, for instance.
    Additionally, I'd be interested to see how the system copes with software upgrades. It seems like an impossible task to build a system that allows easy software installation but isn't itself vulnerable to accepting a trojan - and because the system's hardware the protocol can't be easily modified to deal with flaws.

    Presumably IBM has smart people who've considered this and think their solution is workable. In my copious free time maybe I'll download the spec and have a look... :)

    • Re:Big claims... (Score:2, Insightful)

      by rasteri ( 634956 )
      Personally, I'm more concerned about doing things like moving keys from one computer to another. I mean, if you use the TCPA chip to sign an email, then all it does is prove that someone using your computer sent it. On the other hand, if it's possible to move the generated key to another box, then doesn't that present a security risk?

  • Moronic knee-jerk reactions... (Score:4, Insightful)

    by Theovon ( 109752 ) on Friday January 24, 2003 @11:09PM (#5155038)
    Reading the IBM paper and some of the propoganda against TCPA, I have to express my distaste for those who constantly insist on crying "boycott this", "ban that" whenever something like this is developed without bothering to actually find out what it is. First, there was DRM, which is bad, then Microsoft comes out with Palladium, and all these idiots ASSUME that it's Microsoft rolling over for Hollywood. Well, I don't like Microsoft anymore than the next geek, but Microsoft isn't about to do anything they think would cost them money, and so it appears that Palladium isn't any more of a threat to our freedom than TCPA. Besides, MS just joined an anti-DRM coalition! SO... then we learn about TCPA, and OF COURSE, people immediately begin yapping about how it's another form of DRM and making up "facts" out of whole cloth and doing nothing but confusing the issue.

    Activism is a good thing when it HELPS something, but everything is clouded for no good end when people leap to totally uninformed conclusions and then make every activist look like morons along with them. The anti-TCPA people should be ASHAMED of themselves.

    • Re:Moronic knee-jerk reactions... (Score:4, Interesting)

      by geekoid ( 135745 ) <dadinportlandNO@SPAMyahoo.com> on Saturday January 25, 2003 @04:29AM (#5155821) Homepage Journal
      "MS just joined an anti-DRM coalition!"

      Only because the the way DRM is being pushed, puts them out of control. MS wants you to have a house full of computers, all of which are connected to them. It is part of the 1000 year vision.
      In 95 or 96 Bill Gates was at a smartcard conference.
      At that time he said he wanted a smart card reader in every computer, and for it to be verified by MS before allowing any purchases. The only problem was there was no was to verify what system is was coming from.
      Sure, on paper, TCPA is a good thing, with many practical uses. However, look at how any industry that makes money doing something digital(whether it is CDs or OS) blames all there woes on piracy.
      That is the leverage/excuse MS will use to "embrace and extend" the TCPA technology.
      MS is not rolling over for hollywood, and nevcer will. What they will do is utilize Palladium, with TCPA, so they can charge the entertainment companies for a "verification" service. Of course any OS they can't "trust" will be excluded.
      The question is, will the backlash be great enough for it to fail? If it was put into place right now, the backlash would be minimal, because the number of non MS desktops user is very small, and they don't make much money from those users anyways.

      It is the mission of almost every corporation to make as much of a market as possible.

      You should be ASHAMED for not learning from history, and not using you imagination on how this can be used against you.

      TCPA is to DRM as Bullets are to a Gun, neccessary.
  • I'd have to say that my opinion of IBM went up. They seem to be making an honest effort to show exactly what TCPA is. I admit I have not read the documentation, (my mind has shut down for the night). But it seems like many of the companies, (IBM and AMI for instance), are working to let people know that TCPA is nothing more than a tool available to people who want to secure their computers and not a tool meant to secure other people's content on your computer.

    • Re:IBM (Score:3, Insightful)

      by jbolden ( 176878 )
      The problem is they aren't being honest here. Guns may be a tool to let you shoot deer and not people but that doesn't mean they work perfectly well for either purpose. Similarly TCPA works perfectly well to either secure data for the user or to secure data from the user.

  • People please remember (Score:5, Funny)

    by codepunk ( 167897 ) on Friday January 24, 2003 @11:26PM (#5155081)
    Microsoft to Dell: could you please ship our new paladium board in your computers.

    Dell to Microsoft: Fuck off if word gets out that you cannot copy stuff on one of our machines we are certainly ruined.

    Microsoft to Dell: Do it or else

    Dell to Microsoft: Fuck you we are shipping Lindows

  • If people want to have something like this just put the private key on a USB dongle. I can remove the damn thing this way if I wish, my decision. This is no different than the hardware dongles software manufacturers sometimes use only this on is permanatly attached and cannot be removed.

  • Need clarifications (Score:2, Insightful)

    by IkeTo ( 27776 )

    The page is really helpful in understanding what TCPA is. However, there is one point that I don't quite understand. The Why TCPA document says:



    The "trusted boot function 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 with fail, thus protecting the data.


    Fine, I can have data for my Linux partition that is unreadable even if my naughty sister boot a Windows XP on it. Seems something that I might want. Then later in the article, it says:



    The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would be a nightmare for content providers to manage. Any change to the BIOS, the operating system, or the application would change the reported values. How could content providers recognize which reported PCR values were good, given the myriad platforms, operating system versions, and frequenent software patches?


    I really don't understand the "trusted boot" functionality is immune to exactly the same argument. You can seal important data under a PCR. But if you upgrade your kernel, you must unseal all such data, upgrade your kernel, seal it all again. If somehow you forget to do this critical step, or if a hacker succeed in modify a single bit of your OS boot image, your data is lost forever. Is this what the function really supposed to do (the data is so important that losing it forever is better than having somebody else getting hold of it), or that I have some seriously misunderstanding of that portion of the paper?

  • Wake up! (Score:3, Insightful)

    by Kevitt ( 640555 ) on Friday January 24, 2003 @11:51PM (#5155154)
    Have all of you gone insane?
    TCPA...DRM...Palladium? What the hell's the difference in the end? I cannot believe that anyone is supporting ANYTHING even remotely resembling any type of DRM or trusted computing scheme.

    Have we really lost so much focus that we are willing to give up our RIGHT to do whatever we please with the data that resides on our drives? Even if it's a small concession, the road to hell is walked one small step at a time.

  • Hardware protection of private keys (Score:4, Interesting)

    by QuantumG ( 50515 ) <qg@biodome.org> on Friday January 24, 2003 @11:57PM (#5155169) Homepage Journal
    I've always been amused at the claims of how hardware can solve security problems. The suggestion of how to protect authentication using TCPA and, indeed, all other "smartcard" based solutions, is to make sure the private key never leaves the hardware. The idea being that the attacker cannot access a server from any other machine than the one containing the hardware. This is clearly not the case. Suppose you use SSH to access your server at work and, for added protection, you use TCPA to keep your private key. An attacker hacks your client attempting to access to the server at work. All he/she has to do is use your hardware to access the server. At this point the attacker can bypass the authentication by:

    1. Installing a new key;
    2. Installing a back door; or just
    3. Taking what they want

    A proposed solution to this problem is to encode the private key with a passphrase. Unfortunately, almost all the systems that do this use software to read and check the passphrase, making it simple to intercept.

    • All he/she has to do is use your hardware to access the server.

      For most people, all he/she has to do right now is use your software. For all except for the very paranoid, keychains are hanging out there right on the hard drive, open to every Tom, Dick and Harry that bothers to walk by.

      But even then, what does access to the private key really give you? SSH does nothing as far as actually authenticating you on the server - it only encrypts the data as it passes to and from the system. The remote server does the actual challenge / response. Somebody might be able to pretend that they are you, but without the password, they are up the proverbial creek.

      Really, this chip is no less resistant to physical acess than the software solution. Computer security isn't just about a password. You wouldn't leave your server room unlocked would you? Why would you treat your workstation any differently?

  • TCPA only a single component of Palladium (Score:3, Informative)

    by Powercntrl ( 458442 ) on Saturday January 25, 2003 @12:08AM (#5155202) Homepage
    By itself, a security coprocessor is no different than using the PIII's serial number to create a unique hash and processing encryption on the main CPU.

    Imagine you already have this TCPA processor on your board. You download the newest RIAA-approved secure media player and start downloading tons of songs. The media player wants to use your TCPA processor to encrypt the songs while you're downloading them so only your PC can play them. Evil, yes, but it can be done TODAY on a PC without a dedicated TCPA processor.

    The application is happily encrypting its audio, however, in the background you're running an application that acts as a virtual soundcard and you're capturing open, unencrypted audio and saving THAT to your hard drive as well. So much for TCPA.

    This is where Palladium comes in, it would not allow you to run a virtual sound card driver. Palladium is about a trusted secure enviorment, which requires the cooperation of the BIOS (ensure the OS that is about to be booted is trusted, and possibly in the future BLOCK booting of non-trusted OSes entirely), the OS, the main processor (for secure memory protection) and the video and sound cards. It is highly likely implementations of Palladium systems will not even HAVE a dedicated TCPA chip that can be easily attacked and disabled - the features will be built right into the main CPU.

  • While you were watching my empty left hand... (Score:3, Insightful)

    by Erik Fish ( 106896 ) on Saturday January 25, 2003 @12:40AM (#5155299) Journal
    Let me get this straight:

    IBM and the hardware manufacturers are saying: "TCPA is just a gun! It can be used for good or evil purposes!"

    Microsoft is saying "Palladium is just a bullet! It can be used for good or evil purposes and it stops piracy which is illegal! Do not look behind the curtain marked 'this machine kills linux'!"

    The content industries are saying "DRM is another kind of bullet! It can be used for good or evil purposes and it stops piracy which is illegal! What is this 'fair use' you speak of?"

    The whole bunch of them are saying "We are forming a club. All club members will communicate with secret decoder rings which you are perfectly free not to use however don't expect to be able to join the club without using them!"

  • Question (Score:3, Interesting)

    by PetWolverine ( 638111 ) on Saturday January 25, 2003 @01:09AM (#5155369) Journal
    Okay, so TCPA is not evil, as I had been led to believe. I have a nagging question about it, though, that I need answered before I consider it a Good Thing.

    Let's say I'm sitting and twiddling my thumbs, or serving rather a lot of MP3's [dhs.org] to the Internet at large, or something, and my computer crashes. Uh-oh, the hard drive can't be read. Looks like I need to boot from another drive to fix it. Trouble is, when I try to do so, TCPA interrupts and tells me I'm trying to boot from a different system, which isn't allowed. How do I repair my drive?

    Of course, as a Mac user, I guess I don't have to worry about this much anyway (Apple still hasn't signed up for TCPA, right?). Besides, maybe in the Wintel/*nix-other-than-OS-X world I know so little about, there's a simple way to overcome this. But wouldn't a simple way to overcome it involve using software to make the switch? It's either that or jumpers on the motherboard, right? So the question stands.

    Somebody fill the void in my brain! I long to know!

  • Is software emulation feasible? (Score:3, Insightful)

    by Sloppy ( 14984 ) on Saturday January 25, 2003 @02:30AM (#5155574) Homepage Journal
    If it is feasible for a user, who has physical access to the machine at boot time, to install a software emulator for TCPA in a manner that it is completely indistinguishable from real TCPA hardware, from the point of view of application software, then I'll believe this is benign.

    If there is any possible way for application software to be able to determine with certainty, that an actual hardware TCPA chip is present instead of software emulation, then I smell a rat.

  • Dongle (Score:3, Insightful)

    by dusanv ( 256645 ) on Saturday January 25, 2003 @04:28AM (#5155818)
    TCPA chips sure looks like a bloody dongle. Identical functionality. I simply do not see any legitimate use other than DRM/licensing (and spare me the encryption speedups).

  • A place to store your password? NO (Score:3, Insightful)

    by NigelJohnstone ( 242811 ) on Saturday January 25, 2003 @06:30AM (#5156018)
    From the whitepaper:

    "Protection of sensitive authentication data, such as passwords will become critical for
    electronic business to succeed."

    Passwords are *user* specific things, not machine specific things.
    Storing them in a vault on a single machine means they are stored in the wrong place.

    This is a lie.

  • Misdirection (Score:3, Insightful)

    by NigelJohnstone ( 242811 ) on Saturday January 25, 2003 @06:36AM (#5156024)
    From the rebuttal whitepaper
    -----------

    "When you boot up your PC, Fritz [the TCPA chip] takes charge. He checks that the
    boot ROM is as expected, executes it, measures the state of the machine; then checks
    the first part of the operating system, loads and executes it, checks the state of the
    machine; and so on."

    This is completely false. The TCPA chip doesn't execute anything. It accepts request data, and replies with response data. In the IBM version,
    TCPA sits on the LPC bus, using I/O mapped registers. The TCPA chip does not and
    cannot control execution!

    -------

    This is a misdirection, the original comment was about the TCPA system in its entirity, the response talks only about the chip part of the TCPA.

  • More misdirections (Score:4, Insightful)

    by NigelJohnstone ( 242811 ) on Saturday January 25, 2003 @06:46AM (#5156045)
    Here's another misdirection, again he is rebutting a valid comment.

    -------
    The comment he is rebutting:

    "You might prefer not to have to worry about viruses, but neither TCPA nor
    Palladium will fix that: viruses exploit the way software applications (such as
    Microsoft Office and Outlook) use scripting."

    His rebuttal:

    While TCPA cannot prevent stupidity
    in software applications, it definitely can control the resulting damage. In particular,
    no virus can steal a TCPA protected private key.
    How can it, if the private key is
    generated in the chip, stored on the chip, and never leaves the chip?

    Again the comment he is rebutting:

    " Seen in these terms, TCPA and Palladium do not so much provide security for the
    user as for the PC vendor, the software supplier, and the content industry. They do
    not add value for the user, but destroy it."

    And his rebuttal of this:

    Personally, I find the ability to protect my
    private keys, and to protect my encrypted data very important and very valuable.

    -------

    The misdirection here is in the last paragraph. The keys he is talking about are not *your* keys. They are not specific to *you* you do not carry them around from PC to PC and you do not have access to them.
    Your keys (things like your passwords and PGP keyring files) can be stolen when they are entered in the computer just as before.

  • Again the confusion between *me* and *my computer* (Score:4, Insightful)

    by NigelJohnstone ( 242811 ) on Saturday January 25, 2003 @07:10AM (#5156087)
    From the whitepaper, again there is the confusion between *me* and *my computer*:

    ------
    "Protection of user authentication keys
    Given the large number of vulnerabilities in client system, and the trend of hackers to
    target client machines looking for passwords, it is vital to provide some way to protect
    sensitive authentication information such as passwords and private keys. TCPA provides
    exactly this protection.
    A user can generate an RSA public/private key pair on the TCPA chip. The private key
    can be configured never to leave the chip."...

    -----
    Right, stop right there. If my private key never leaves the chip what use is it to me? It identifies my computer not me.
    Whoever is at my computer, if they intercepted my login has all *my* private keys and for all purposes *is* me.

    I meanwhile can move from computer to computer, but I cannot identify myself, because those private keys are on my home computer and can never move.

  • Why I don't think the paper tells the whole truth (Score:4, Insightful)

    by Kjella ( 173770 ) on Saturday January 25, 2003 @08:37AM (#5156222) Homepage
    IBM is doing pretty much what every other business does, downplaying the bad and promoting the good sides of their product.

    Soon, you will have TCPA/Media Center PCs. I'm pretty damn sure they *will* contain an endorsement key (that Microsoft will have, probably in the licencing agreement for making them), that you can not gain access to (except for a hardware hack), and that you can not emulate. This key will verify your BIOS, your Windows Palladium Media Center, and your DRM-crippled Windows Media Player. Or maybe they'll stage a few "licenced" players to create the illusion of choice.

    And in the next level, I've heard that TCPA will be internal to the processor. Goodbye even to the hardware hack.

    Saying the TCPA of the IBM machines doesn't have an endorsement key is saying, "yes, we're pointing this assault rifle at your consumer rights, but we haven't loaded it yet". Then when people "have to" have an endorsement key to get programs working, they can blame it on consumer demand.

    Kjella

  • Call Me Stupid . But . . . (Score:3, Insightful)

    by GnuPengwyn ( 629868 ) on Saturday January 25, 2003 @09:45AM (#5156437) Homepage
    Exactly why do I _want_ these chip[s] on my new mainboards?
    It sucks case-space, and waste's Juice. (v/r=i)
    I _want_ to add chip[s] to my mainboards that have things like
    a TB of memory, or say a "Spare CPU slot (tm)" (sic)
    In fact why not just add another CPU?!

    If the white paper's _intentions_ are to be believed as stated,
    this eFFing "Kradical new Chipp0r"(tm) does not need to BE
    physically soldered onto the "eFFing mainboard" (tm)
    They can make it a self contained appliance that plugs into the wall,
    and plugs into the box (via serial, parallel, or usb)
    Then when *I* _want_ to do some eCommerce or some 31134
    crypto to my friends then I can plug the little bugger in,
    do my Biz, then disconnect0r the SOB!

    But noooooooooooooo!? that's not the True Evil Intentions.
    They *HAVE* to put this BOFH on the MB's now,
    cause they know folks do not take change easilly,
    So they desensitize you to this crap now.
    IBM, test away, research away,
    hopefully someone will break it in the research lab
    *BEFORE* they roll the crap out the door.
    Maybe the Genius's at SuSE or United Linux
    can smoke-check that lil-bugger and prove that it's flawed.

    But I digress, what a whoring plethora of bullcrap TCPA is. ;o)
    I think I meant plethora of whoring bullcrap.

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close