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

 


Forgot your password?
Close
typodupeerror
×
Security Software Linux Technology

Dartmouth Project Combines Linux With TCPA 227

Posted by timothy from the smoosh dept.
SiliconEntity writes "A new project from Dartmouth College demonstrates significant advances in combining Linux with TCPA. The software turns a Linux PC into a 'virtual secure coprocessor', which is able to check that none of its software is compromised and even (in a future version) prove its integrity to a remote system. Full GPL source code is available for the 2.4 kernel. This work is separate from the earlier IBM research which also combined Linux with TCPA, with the new project apparently more complete and with a road map towards a very functional Linux based trusted computing system. This could be an important technology for Linux to challenge Microsoft as it pushes forward with NGSCB (aka Palladium)."
This discussion has been archived. No new comments can be posted.

Dartmouth Project Combines Linux With TCPA More

Dartmouth Project Combines Linux With TCPA

Comments Filter:

  • The source code (Score:4, Funny)

    by OpenSourcerer ( 515213 ) <hashim@hNETBSDaafiz.org minus bsd> on Wednesday September 10, 2003 @03:41AM (#6919246) Homepage
    >Full GPL source code is available for the 2.4 kernel

    Please make sure that all the efforts are undertaken to remove any references to the construct 'main()' as it will infringe on SCO copyrights

    • Re:The source code (Score:5, Informative)

      by kasperd ( 592156 ) on Wednesday September 10, 2003 @04:21AM (#6919355) Homepage Journal
      main() as it will infringe on SCO copyrights

      Luckily no important part of Linux uses that construct. It is mentioned a few times in the documentation and comments, but we can remove that without breaking anything. (Hint: Linux is a kernel, not a program.)

      • Re:The source code (Score:4, Informative)

        by sholden ( 12227 ) on Wednesday September 10, 2003 @05:11AM (#6919476) Homepage
        Does it takes lots of efforts to be that stupid?

        $ find linux-2.6.0-test5 -name '*.c' | xargs grep '^int main('
        linux-2.6.0-test5/drivers/scsi/aic7xxx/aic asm/aica sm.c:int main(int argc, char *argv[]);
        linux-2.6.0-test5/drivers/atm/fore200e_ mkfirm.c:in t main(int argc, char** argv)
        linux-2.6.0-test5/arch/i386/boot98/tools/bu ild.c:i nt main(int argc, char ** argv)
        linux-2.6.0-test5/arch/i386/boot/tools/buil d.c:int main(int argc, char ** argv)
        linux-2.6.0-test5/arch/sparc/boot/piggyback .c:int main(int argc,char **argv)
        linux-2.6.0-test5/arch/sparc/boot/btfixup prep.c:in t main(int argc,char **argv)
        linux-2.6.0-test5/arch/sparc64/boot/piggy back.c:in t main(int argc,char **argv)
        linux-2.6.0-test5/arch/um/kernel/skas/uti l/mk_ptre gs.c:int main(int argc, char **argv)
        linux-2.6.0-test5/arch/um/sys-i386/util/m k_thread_ kern.c:int main(int argc, char **argv)
        linux-2.6.0-test5/arch/um/sys-i386/util/m k_sc.c:in t main(int argc, char **argv)
        linux-2.6.0-test5/arch/um/util/mk_constan ts_kern.c :int main(int argc, char **argv)
        linux-2.6.0-test5/arch/um/util/mk_task_ke rn.c:int main(int argc, char **argv)
        linux-2.6.0-test5/arch/um/main.c:int main(int argc, char **argv, char **envp)
        linux-2.6.0-test5/arch/mips/boot/elf2ecof f.c:int main(int argc, char *argv[])
        linux-2.6.0-test5/arch/cris/arch-v10/ker nel/asm-of fsets.c:int main(void)
        linux-2.6.0-test5/arch/cris/arch-v10/b oot/tools/bu ild.c:int main(int argc, char ** argv)
        linux-2.6.0-test5/arch/m68knommu/kernel/asm -offset s.c:int main(void)
        linux-2.6.0-test5/arch/arm26/boot/comp ressed/misc. c:int main()
        linux-2.6.0-test5/arch/arm26/kernel/asm-of fsets.c: int main(void)
        linux-2.6.0-test5/arch/m68k/kernel/m68 k_defs.c:int main(void)
        linux-2.6.0-test5/arch/m68k/tools/amig a/dmesg.c:in t main(int argc, char *argv[])
        linux-2.6.0-test5/arch/ppc/boot/prep/dum my.c:int main(void)
        linux-2.6.0-test5/arch/ppc/boot/openfi rmware/dummy .c:int main(void)
        linux-2.6.0-test5/arch/ppc/boot/simple /dummy.c:int main(void)
        linux-2.6.0-test5/arch/ppc/boot/utils/ addSystemMap .c:int main(int argc, char **argv)
        linux-2.6.0-test5/arch/ppc/boot/utils/add RamDisk.c :int main(int argc, char **argv)
        linux-2.6.0-test5/arch/ppc/boot/utils/mkb ugboot.c: int main(int argc, char *argv[])
        linux-2.6.0-test5/arch/ppc/boot/utils/mk prep.c:int main(int argc, char *argv[])
        linux-2.6.0-test5/arch/ppc/boot/utils/mk tree.c:int main(int argc, char *argv[])
        linux-2.6.0-test5/arch/ppc/boot/utils/ad dnote.c:in t main(int ac, char **av)
        linux-2.6.0-test5/arch/ppc/boot/utils/mknot e.c:int main(void)
        linux-2.6.0-test5/arch/ppc/kernel/find _name.c:int main(int argc, char **argv)
        linux-2.6.0-test5/arch/ppc64/kernel/asm-o ffsets.c: int main(void)
        linux-2.6.0-test5/arch/ppc64/boot/pigg yback.c:int main(int argc, char *argv[])
        linux-2.6.0-test5/arch/ppc64/boot/addSys temMap.c:i nt main(int argc, char **argv)
        linux-2.6.0-test5/arch/ppc64/boot/addRamD isk.c:int main(int argc, char **argv)
        linux-2.6.0-test5/arch/ppc64/boot/mknote. c:int main(void)
        linux-2.6.0-test5/arch/arm/kernel/asm- offsets.c:in t main(void)
        linux-2.6.0-test5/arch/arm/boot/compre ssed/misc.c: int main()
        linux-2.6.0-test5/arch/parisc/kernel/asm-o ffsets.c
        • That's ok, 'cos their ANSI syntax, not K&R.


          Parameterless function calls/definitions (eg: main()) may be either, but SCO's lawyers have #defined all of K&R's work to be theirs.

    • main(), in K&R syntax, is trademarked, copyrighted and patented by SCO. In fact, everything either K or R did is trademarked, copyrighted and patened by SCO, including all descendents, cell division, breathing, etc.

  • Not compatible with eachother ? (Score:5, Interesting)

    by MoonFog ( 586818 ) on Wednesday September 10, 2003 @03:44AM (#6919252)
    From the PDF :
    The exact relation between TCPA and the former Palladium is not clear; one suspects that at some point in the TCPA design process, Microsoft decided to withdraw and build their own variant.
    This probably means the two technologies will not be compatible with eachother, files created under one will not be able to be opened under the other.

  • Oooh! Verifiable integrity and an encrypted FS. (Score:4, Funny)

    by Read Icculus ( 606527 ) on Wednesday September 10, 2003 @03:58AM (#6919292)
    Sounds like just the thing I need. That hacked together script that I currently use to md5sum all my important system binaries + files and verify them against the Known Goods database every 2 minutes is going out the window along with chkrootkit just as soon as I can go over every LOC with an STM and run this fine piece of software. Thanks be to you my fellow linux-users, I have finally found people who wear more layers of foil on their heads than I.

  • Difference between Palladium and TCPA (Score:5, Informative)

    by kompiluj ( 677438 ) on Wednesday September 10, 2003 @04:02AM (#6919306)
    The difference between Palladium and TCPA (Trusted Computing Platform Architecture) may be not obvious at the technological level but it is very simple - TCPA aims at integrity of kernel and system components - to assure you that your system can be trusted. It is easy to achieve with open software, because the system must defend itself from attacs from outside. Palladium, on the other hand, uses similar technology to make sure that the user does not do anything else than what is allowed by content owners. In that case software openness is impossible - otherwise you could do some harm to their system - attacking from inside...

    So similar architecture from technical point of view - but different aims yield different results.

    • Re:Difference between Palladium and TCPA (Score:5, Insightful)

      by hanssprudel ( 323035 ) on Wednesday September 10, 2003 @04:14AM (#6919333)
      Not true at all. DRM and other user control systems only need to be closed when they are software based, because otherwise people can change the programs to remove the user hostile code.

      The difference between Palladium and TCPA is really that while Palladium is a whole system for a building user hostile computers, TCPA is just an enabler.

      What TCPA does is sign a hash of the OS that is loaded with an "endorsement key", embedded in the TCPA by the vendor and unaccessible to the user. Thus the TCPA chip is a able to do two things: it can verify to an outside source (that trusts the vendor) that the machine is a running a specific operating system (ie one that supports DRM and thus can be "trusted"), and it can encrypt data from one operating system so that another operating system cannot decrypt it.

      TCPA provides everything that is needed at the hardware level to write any user hostile system on top of it, because the successive verification of signatures prevents any tampering with the code (even if the OS is open sourced). Palladium could be implemented with TCPA as it's only hardware aspect.

      Thus, the argument that is sometimes seen here that TCPA would prevent the computer from booting Linux or any other operating system is false (incorrect scare tactics against these systems are unfortunate, they do more harm then good). What TCPA will do, is enable sites on the Internet to not allow you to read the data they give out, unless you are running an operating system that is user hostile and DRM friendly (and not in the "this site doesn't support mozilla" fashion, which can always be hacked around, but in a cryptologically safe fashion).

      • Re:Difference between Palladium and TCPA (Score:5, Interesting)

        by sjames ( 1099 ) on Wednesday September 10, 2003 @07:08AM (#6919846) Homepage Journal

        Like many things, TCPA is a neutral technology. If the TCPA just sits on the board unused, you'd never know it's there at all. With Palladium, your system will be actively user hostile and RIAA/MPAA/MS friendly.

        TCPA in itself won't prevent booting Linux. The fear is that a BIOS could then be written that won't load an OS that isn't signed by Bill Gates. TCPA merely enables that non-functionality. In addition, it is entirely possible to have a CPU come up in crippled mode until it validates the BIOS against the TCPA so that an unsigned BIOS won't run either. That is the fear, a total lock-down.

        On the other hand, if the user has the signing key (I say user, since in reality, whoever has the signing key is the owner), TCPA permits (but does not assure) user friendly, outsider hostile strong system security.

        The problem is that we are all aware that certain corporations in the U.S. would happily torture all of their customers to death if it was shown that after all of the lawsuits are settled, they make an extra $0.10 over the next 5 years than they would otherwise. They will be more than happy to build a user hostile system and lease it to their customers if they can find a way to kill off the competition.

        Even if the lease is called a sale, I maintain that it's in reality a lifetime lease since, as I said, whoever has the signing key is the real owner of the system.

        One possible roadblock to that would be to get the above paragraph enshrined in law. Not only would that force vendors to be more honest in their sales of Palladium enabled systems, it would place a nice large tax burden on a corporate holder of the signing key since they would be forced to acknowledge that they actually own all that hardware out there. More likely, it would kill the whole thing since under that law, hardware vendors would have to treat the transaction as a gift to MS and themselves as a lease broker for MS.

        • Like many things, TCPA is a neutral technology. If the TCPA just sits on the board unused, you'd never know it's there at all. With Palladium, your system will be actively user hostile and RIAA/MPAA/MS friendly.

          That's a false distinction. You can leave Palladium turned off as well. It just means that you won't be able to run applications that require Palladium. But it's the same with TCPA, you can leave it off but then you won't be able to run applications that require that technology.

          And Palladium is
      • What TCPA will do, is enable sites on the Internet to not allow you to read the data they give out, unless you are running an operating system that is user hostile and DRM friendly (and not in the "this site doesn't support mozilla" fashion, which can always be hacked around, but in a cryptologically safe fashion).

        I don't think this is right, from what I know.

        I think the issue is simply "known identity". These initiatives will (finally) provide a standardized, painless, secure mechanism for user/compute

      • What TCPA does is sign a hash of the OS that is loaded with an "endorsement key", embedded in the TCPA by the vendor and unaccessible to the user.

        This is incorrect; I don't have time to explain what a TCPA-compliant TPM does, but you can find out all you'd like to know here [trustedcomputing.org] (look at the section entitled Documents"). In particular, this document [trustedcom...ggroup.org].

        However, although your description of the mechanism is incorrect, your explanation of the potential effect is right. Among other things, the TCPA makes it pos

        • What we need to avoid all of this is strong digital consumer legislation that requires that every digital rights management system include escape hatches to allow for Fair Use, format shifting, platform shifting and copyright expiration. That would prevent the abuse of the technology without taking away the usefulness of TCPA.

          It's a sad, but yes, legislation to protect fair use is very necessary. Previously, fair use was a defense against a copyright infringement suit, and nobody worried about it being

    • Except of course, you yourself cannot declare a kernel as safe, only one of the big companies can.
    • Palladium, on the other hand, uses similar technology to make sure that the user does not do anything else than what is allowed by content owners. In that case software openness is impossible - otherwise you could do some harm to their system - attacking from inside...

      Then why does Microsoft say, in their FAQ [microsoft.com]:

      Q:How can anyone be sure that the nexus and related components do exactly what you claim they do?

      A:Microsoft will make widely available for review the source code of the trusted computing base so i

  • Not the right idea... (Score:5, Insightful)

    by hanssprudel ( 323035 ) on Wednesday September 10, 2003 @04:03AM (#6919309)
    We want to fight Palladium by fighting acceptance of the idea that the computer should control the user and how he can access the data on his own machine, NOT by developing something functionally equivalent that happens to run under Linux.

    Building a DRM system of our own, even if it is open and standards based, just strengthens the paradigm that will leed to an Internet where no data can be accessed as plaintext, applications that are allowed read data have to be accepted and certified by the media industry, and computers exist no longer to enable, but to control, their users.

    Please protest against Palladium, TCPA, and all the other DRM proposals by refusing to have anything to do with them: not by strengthening their hand.

    (And before somebody replies that TCPA isn't about DRM: Bullshit! Look up what an "endorsement key" is in the TCPA vocabulary.)

    • Re:Not the right idea... (Score:5, Insightful)

      by amcguinn ( 549297 ) on Wednesday September 10, 2003 @04:16AM (#6919337) Journal

      Unfortunately, this kind of thing is valuable in some specialised areas. For high security systems, you want to know that only certain approved code can run.

      What we care about is the preservation of general-purpose computers controlled by the user. If we aim to ensure that all computers are controlled only by the user, we will fail, and fail badly, because having, say, a firewall that cannot run introduced code is something so useful that we will not be able to prevent it.

      I have hope: firstly, the overhead of trying to deploy this over a large office PC system (the main buyer of general-purpose PCs), will be too high for the benefits.

      Secondly, the value of a general-purpose computer that will easily run new software is so high even for the ordinary home user that they will not be entirely replaced by DRM-enabled home entertainment consoles.

      It is possible (but unlikely) that this infrastructure will eventually reach the **AA goal of preventing copying of their products. I can live with that provided that our ability to write software for our own computers isn't collateral damage.

      • Re:Not the right idea... (Score:5, Insightful)

        by hanssprudel ( 323035 ) on Wednesday September 10, 2003 @04:43AM (#6919408)
        The specialized areas thing just doesn't hold up. I have yet to see a single example of this that couldn't be solved by current hardware. A lot of people talk about company employees: but few employees have root on their computers anyways, so what is the point with the TCPA chip?

        I'm at work right now, and since my local workstation is a Sun Ray I don't even have physical access data in ways that the operating system and application will not allow me (since they all run on a server somewhere). Why would TCPA be necessary to control what I did with my employers documents, instead of just software?

        Even IBM admits that TCPA chips can be circumvented by hardware hacks (expect modchips to start appearing), so it can not be used to secure valuable information. The only logical purpose for this technology is to use it on home users, where access to mod chips is limited by laws like the DMCA.

        It is possible (but unlikely) that this infrastructure will eventually reach the **AA goal of preventing copying of their products. I can live with that provided that our ability to write software for our own computers isn't collateral damage.

        It is not the ability to write our own software that we will be sacrificing, it is the ability to use that software to communicate with the world. Once the TCPA infrastructure is there, the temptation to use it will be to strong to resist:

        - eBay will be able to lock out all but some verified list of applications from accessing auction data, so that application to raise bids at the last minute can't be used.

        - Microsoft recently kicked off other application from their IM system for "security reasons". As it stands now, this can be hacked around, do you think they'll hestitate to use TCPA to make that impossible? You think AOL are any different.

        - Websites will be able to lock out browsers that can block pop-up ads, or that allow cookies to be cleared, or that lie about themselves in the User-Agent string.

        - Games will be able to lock out modified versions.

        - Given the common confusion that TCPA is about "security", how long do think it will be until your bank starts requiring it?

        I could go on and on. The acceptance of TCPA spells the end of the open Internet, and the beginning of a closed network, where all but a few applications are locked out.

        I know what I'll do. Whatever it comes to, I will not have a part of this, and I will simply refuse to accept having a computer that is hostile toward me. The reason I argue this so vehemently is because I hope it won't be lonely out here...

        • Re:Not the right idea... (Score:4, Insightful)

          by amcguinn ( 549297 ) on Wednesday September 10, 2003 @05:02AM (#6919448) Journal

          The specialized areas thing just doesn't hold up. I have yet to see a single example of this that couldn't be solved by current hardware. A lot of people talk about company employees: but few employees have root on their computers anyways, so what is the point with the TCPA chip?

          I don't have root on my win2k PC right now, but I've got a tomsrtbt floppy in my jacket pocket which works just fine.

          Now, if the company was prepared to make the large investment in setting up a full TCPA-style architecture to stop me doing that, it would be prepared to make the much smaller investment in ripping the floppy drive out of my PC. As I say, I don't think the ordinary office desktop is a useful area for this.

          I think real uses for this are very rare, just as PCs which are configured by their adminstrators to really lock down what the users can do are currently very rare. But they exist.

          I know what I'll do. Whatever it comes to, I will not have a part of this, and I will simply refuse to accept having a computer that is hostile toward me.

          Me too. But I think most of the world will be with us, not because they agree with our principles, but because the immediate, practical benefits of being able to run any piece of software on their PC without it being approved by any third party are far too great to sacrifice for the miniscule benefits (in normal circumstances) of "Trusted Computing".

          • Now, if the company was prepared to make the large investment in setting up a full TCPA-style architecture to stop me doing that

            It won't be a large investment. Or at least, it won't look like a big investment until we're several years down the path and in too deep to back out.

            The initial capital to deploy DRM will be supplied by corporations with a long-term interest. This means *AA somewhat, but more directly computer corps like Intel and especially Microsoft(tm).

            Primarily, Microsoft and Intel will w

        • I could go on and on. The acceptance of TCPA spells the end of the open Internet, and the beginning of a closed network, where all but a few applications are locked out.

          I know what I'll do. Whatever it comes to, I will not have a part of this, and I will simply refuse to accept having a computer that is hostile toward me. The reason I argue this so vehemently is because I hope it won't be lonely out here...

          I don't believe we (for i'm entirely with you) will be in the least lonely. The open Internet

        • - eBay will be able to lock out all but some verified list of applications from accessing auction data, so that application to raise bids at the last minute can't be used.

          This is somehow bad? If this happens, auctions will work the way they are intended to (and the way they work best). Fairer prices for all.

          - Microsoft recently kicked off other application from their IM system for "security reasons". As it stands now, this can be hacked around, do you think they'll hestitate to use TCPA to make that impo

          • My point was exactly that a lot of people (including you apparently) would find these applications favorable. So once TCPA is in place, we can expect the Internet to begin moving toward a closed system where all these things are possible.

            So what will this mean?

            It will means that innovation will be strangled, that new program features will be decided by lawyers on a comittee. Remember the RIAA's stated model regarding P2P software: you cannot write it without our permission. Welcome to that world.

            It means
          • This is a good thing - content owners can choose to send away potential visitors who would not see pop-up ads. In time, sites which do not use popup ads will become more common and more succesful.

            Imagine the mess that would cause. There are already far too many "professionally" designed web sites that refuse to work without Internet Explorer, such as Amano's World [amanosworld.com]. Can you imagine the nightmare for users of other browsers [freezope.org] if IE became actually required? What about proxy servers? I currently use bfilter, wh

      • Why this may or may not be a worthy cause I don't believe it's got a fundamental weakness. While each application relies on and uses the data it receives it may still take actions that weren't intended by the designer of the system.

        Most "office" type applications execute the data directly (e.g. macros, vbscript, etc) and it would be a large step backwards to disable this even for the increase in security it would bring. We could turn it all off today (java, jscript, vbscript, macros etc) and we're still vu
        • Tricking "signed" applications to doing things they aren't supposed to do was demonstrated to great effect with the XBox hack.

          That's a temporary effect- you cannot rely on that kind of weakness continuing to work.

          Current and near-future implementations of hardware DRM will have a weakness in that if an unsafe application is accidently signed, it becomes a permanently exploitable hole on that platform. This has already been demonstrated with a buffer-overrun in a certain James Bond game.

          However, highspe
      • Ok, you want it to run your programs as trusted ? You can't, which is the whole problem with palladium.

        • Indeed. And it's the reason why user-hostile terminals will never be able to replace general purpose computers.

          In the large financial company I work for, a proportion of the software on the desktop is in-house developed. Will the corporate IT department accept a windows upgrade that would mean every new release had to be submitted to MS for signing? Will they accept an office upgrade that would mean they can no longer exchange data between standard and in-house applications? The PC has got to where

          • a proportion of the software on the desktop is in-house developed. Will the corporate IT department accept a windows upgrade that would mean every new release had to be submitted to MS for signing? Will they accept an office upgrade that would mean they can no longer exchange data between standard and in-house applications?

            That's no obstacle to user-hostile DRM. (Read my other comments in this thread for more explanation).

            The heart of "hard DRM" is that the hardware, OS, and application all form a chai
          • In the large financial company I work for, a proportion of the software on the desktop is in-house developed. Will the corporate IT department accept a windows upgrade that would mean every new release had to be submitted to MS for signing?

            Christ, how long will it be before this lie is put to bed?

            Palladium does not require Microsoft to sign applications! Read the Microsoft technical FAQ [microsoft.com]: "Anyone can write an application to take advantage of new APIs that call to the nexus and related components without
      • Secondly, the value of a general-purpose computer that will easily run new software is so high even for the ordinary home user that they will not be entirely replaced by DRM-enabled home entertainment consoles.

        The ability to quickly download and run a new program is valuable. However, DRM can be implemented in a way which is mostly compatible with that ability. This unfortunately means that we cannot depend on market pressure to protect us from the spread of hard DRM.

        It is already a recommended softwar
        • The ability to quickly download and run a new program is valuable. However, DRM can be implemented in a way which is mostly compatible with that ability. This unfortunately means that we cannot depend on market pressure to protect us from the spread of hard DRM.

          Your statement is right but your implementation is all wrong. The way it actually works is that each program is able to encrypt its data so that only that program, or other programs signed with a per-program key, can access that data. And likew
          • Your statement is right but your implementation is all wrong

            I was describing a possible extension to the normal DRM scheme which could solve some of the problems amcguinn cited as to why DRM will never succeed in the marketplace. DRM-implementors don't have to do it my way- but if they don't, they'll lose some customers (maybe not enough for them to care)

            But your software won't be able to access your Quicken billpaying database, because that is encrypted using a key that only Quicken-signed software ca

      • Re:Not the right idea... (Score:4, Insightful)

        by riptalon ( 595997 ) on Wednesday September 10, 2003 @03:50PM (#6924783)

        a firewall that cannot run introduced code is something so useful that we will not be able to prevent it

        This is true but you don't need TPCA to do this. Putting this functionality at the firmware level is sufficient to achieve what you suggest. In fact I would be suprized if it wasn't done already by specialized vendors. There is a difference between not trusting the computer user and the owner. An organisation can have firewalls with secure firmware such that no one can load any old software on to them without the right codes or keys (without pulling the battery on the CMOS, which is good enough, especially if you have a lock on the case). Putting the functionality in hardware is only useful for stopping the owner of the computer from using it anyway they want.

        There is no valid security reason for TPCA. All security problems to do with stopping users from doing stuff the owner of the computer doesn't want done can be handled at the firmware and OS level. This sort of hardware solution is only necessary for DRM where even the owner of the computer isn't trusted. TPCA/Palladium is likely enough to spread through the installed base, leveraged by Microsoft's market share, without any help from the free software community. If it succeeds then free software is dead in the long term, so any cooperation with it is akin to attempted suicide.

    • Think about this for a moment before you call me a troll, mark this post as flamebait, or bash me for being a MS supporter on the issue. It's not funny, it's serious.

      Palladium/TCPA is a security measure, not just a DRM platform. Enabling DRM is impossible in the sense that DRM doesn't cover the analog hole. As long as people have the ability to reproduce video and audio, DRM will only prevent people who do not have other recording mechanisms from copying raw data. Digital cameras get cheaper each day. Mult

      • There are two reasons for wanting this in hardware, as opposed to just in the software:

        1. To enforce rules that the user can't break ("hostile computing").
        2. To prevent the boot loader from being corrupted by malware.

        The second reason is a tiny capstone on a pyramid of security that most people haven't built to anywhere near the height where it would be useful. It can be practically disregarded.

        All the other things you list can be done without hardware support, and the only catch is that the end user can

      • But if you don't want to run a particular program (such as a worm), don't run it. There is no need for all this signature stuff, except to prevent the user from running software of his own choosing.

        If you did decide to run only code signed by a trusted key, the only reasonable system would be for the owner of the PC to posess that key. (This could be the company IT department, or the individual user for home systems.)
      • There is so much wrong with this post I don't even know where to start. Please, tell me you were just trolling.
      • I don't think you're a troll. But I do think that you're remarkably short sighted. Or that you have a naive degree of trust in the beneficence of large corporations.

        MS apps are insecure in ways that don't bother MS. Frequently they even use the insecurities as sales points (for the next version ... which they *claim* will fix the problem). It's not insecure in ways that bother MS. Or if it is, those get fixed quickly. Palladium will not be used for the benefit of end users except incidentally. It wi
      • Enabling DRM is impossible in the sense that DRM doesn't cover the analog hole.

        The technologies being used to enable DRM hardware create user-hostile computers and are a step along the way to plugging the "analog hole". You mention that digital cameras (still or video) are getting cheaper and better all the time. But digital watermarking already exists, and digital shape-recognition is getting better and better. Long-term, the advances in software will overwhelm hardware improvements. Hardware may op

      • Your analog hole arguement is flawed because in the future there will be no analog devices. They exist now but soon they will stop making them and the existing ones will all break in time. The whole point of DRM is that it has to be pervasive. You will not be able to record a video off your computer screen using a digital video camera because the camera will have DRM in it as well. Everything will. There will be a black rectangle where your screen is on the video because the camera will recognise that it i

    • Re:Not the right idea... (Score:5, Insightful)

      by bruthasj ( 175228 ) <bruthasj@yaho[ ]om ['o.c' in gap]> on Wednesday September 10, 2003 @06:03AM (#6919592) Homepage Journal
      Question: Do you currently protest GPG signatures and encryption algorithms? Where do you draw the line between what *you* want to encrypt/control and what *you* want *others* to encrypt/control? Or do you want to pull an RMS and have no passwords to protect your systems, no security to lock your documents that you created and no rights to control stuff that you created? Shouldn't we let people have the right to handle guns and the right to handle encryption/document rights/system verification in anyway shape or form they please? Whether that be individuals, groups, churches, cults, governments, corporations, criminals, gangs, ACLU, EPA, Green Peace or whoever else!

      Everything has an avenue of abuse, but that does not mean scrapping the whole thing because it's got a hole for possible misuse. I mean, look at another case in point: P2P networks. Do we sue the thing out of existence? Or do we fix the violators? What are the definitions of violators?

      It's all nice and rosy to flat out and protest something that's "unknown", but the fact is the technology is here and big players are pushing for its existence. Unbelievers in the technology will always be a small ragtag of protestors holding up placards in front of large corporation buildings towering the skies of Redmond, WA.

      Don't get me wrong, I hate Windows and I'm a Linux zealot, but I just cannot take your protest position at this time. Sorry.
      • I'm not sure that the sane folks are saying "DEATH TO SECURED COMPUTING" as it has a practical application in locking down very specific systems, but YOU need to be AFRAID of this thing getting into your box. Companies like IE, HP, IBM and the like have the power to put this stuff in there, and as long as most users are happy (believe me, these companies will try to keep it that way), this stuff will roll out without much of a fuss.

        Then they can slowly tweak their usage of this technology. Turn the heat

  • Great business plan! (Score:3, Funny)

    by Anonymous Coward on Wednesday September 10, 2003 @04:13AM (#6919331)
    Who will be the first to start selling mod chips for pc computers?
  • as part of their plan to seize the internet and digital stuff in general, they get to hitch Linux up like a draft horse to do it.

    Something that was supposed to set computers free is being used to help lock them down.

  • Trustworthy computing (Score:5, Funny)

    by sneakybilly ( 537969 ) on Wednesday September 10, 2003 @04:50AM (#6919424)
    I love this bit from the microsoft ngscb pagen [microsoft.com] "Data can be protected with a secure pathway from the keyboard through the computer to the monitor screen, preventing it from being secretly intercepted or spied on" Yeah like this is a major security problem with current day computing. I've always wondered if my information is secure between my keyboard and the monitor :)
    • It's not meant for you, none of this technology has anything to do with _your_ security. These products are intended to protect people from you, specifically, in this case, the movie industry who don't want you re-recording movies from the monitor cable.
    • "Data can be protected with a secure pathway from the keyboard through the computer to the monitor screen, preventing it from being secretly intercepted or spied on" Yeah like this is a major security problem with current day computing. I've always wondered if my information is secure between my keyboard and the monitor :)

      It's not funny. Ever heard of a keystroke logger? What if you're typing a password for your online bill payment service, wouldn't you like to have a secure path from the keyboard to
    • > I've always wondered if my information is secure between my keyboard and the monitor

      Considering it takes a trip through the potentially keystroke-logger-ridden virus-infested operating system in order to do so, perhaps you should wonder...

  • Start Song.. (Score:4, Funny)

    by instanto ( 513362 ) <tabarth@on[ ]e.no ['lin' in gap]> on Wednesday September 10, 2003 @05:20AM (#6919498) Homepage Journal
    Its the end of the world as we know it...

    (I could have typed more, but then I would probably owe RIAA 150.000$ per slashdot user who read this)
    (all 5 of them since I have a bad karma)

  • The owner of the PC does NOT own the master keys (Score:5, Interesting)

    by NZheretic ( 23872 ) on Wednesday September 10, 2003 @05:57AM (#6919572) Homepage Journal
    The long term problem with IBM's model of the TCPA is exactly the same with that of clipper chip encryption [epic.org], the owner of the PC does NOT control the attestation master keys. This leads to the same escrow agent model which is far to open to exploitation by The New American Corporate Soviet [slashdot.org].
    • The long term problem with IBM's model of the TCPA is exactly the same with that of clipper chip encryption, the owner of the PC does NOT control the attestation master keys.

      [ Disclaimer, I'm one of the primary developers. ]

      That is blatantly not true. Whoever does the "Take Ownership" command of the TPM controls the master key. In the case of the Enforcer, the admin is the one that owns the TPM.

      Omen

  • I'm sorry but totally avoid TCPA (Score:5, Informative)

    by FeatureBug ( 158235 ) on Wednesday September 10, 2003 @06:06AM (#6919604)

    You cannot copy the keys inside TCPA hardware. I'll explain what this means (if you don't like reading about technicalities, just skip to the final paragraph)

    Every time you buy a new PC with TCPA you will not be able to copy the old TCPA keys on your old PC to your new PC. This means you will completely lose access to your videos and your music which you legally purchased and used on your old PC. Effectively you have to buy another set of keys to regain access to your videos and your music collections.

    TCPA and other DRM technologies are being pushed by the publishing industry and hardware manufacturers like IBM who want to sell more of their hardware equipped with DRM to make it attractive to commercial content locked-down publications.

    TCPA means LOCK-down, LOCK-out, LOCK-up enabler. Avoid getting anything with TCPA.

    • >Every time you buy a new PC with TCPA you will not be able to copy the old TCPA keys on your old PC to your new PC.

      This is a complete showstopper, I agree.

    • TCPA means LOCK-down, LOCK-out, LOCK-up enabler. Avoid getting anything with TCPA.

      [ Disclaimer, I'm one of the primary developers. ]

      Score: -3 Mis-informative

      You are assuming that TCPA is being used to enforce DRM, and that that is the only valid use of TCPA. Have you looked at what we have done? We are using TCPA, but not for DRM. We are providing a way for the admin to use TCPA to help secure their computer against outside attack. Again, check out the IBM white papers: http://www.research.ibm.com [ibm.com]

      • Yes, I've read your group's papers - of solid academic interest. Yes, I believe as do most truly independent observers outside TCPA that TCPA will be used to enforce DRM and in its current for that's going to hurt ordinary people using home computers. Ordinary people can be educated about the true long-term out-of-pocket costs and threats posed by TCPA. No, I didn't say or even assume DRM enforcement is the only valid use of TCPA but unless TCPA is modified to guarantee the endorsement key(s) can always b

        • I have also read those papers. Very carefully. Everything that is in there could be achieved with a chip that lets you read the keys. In fact it would be totally secure even if the remote attacker knew all the keys (thats how PK works).

          The fact that you cannot read the key, and thus cannot simulate the TCPA machine on a different piece of hardware or with a software emulator, is only for DRM. I challenge you to come up with a single reason for this that is not equivalent to DRM.

          IBM may be the "nice guys"
      • Sorry, but TCPA pretty much can only be used for evil. The "killer app" for TCPA is DRM. The way TCPA enables -enforceable- DRM have been posted and written-about ad nauseum.

        TCPA probably wasn't devised with DRM in mind; it resembles the old "compartmented workstation" idea, and I imagine that's where its roots lie. But DRM is certainly the blazingly obvious use for it, and unlike other DRM schemes, TCPA-based schemes can actually work on general-purpose hardware.
      • Have you looked at what we have done?

        Aside from DRM and denying people control over their own computers, I defy you to name a single thing you have done that you couldn't have done just as well with an identical system where people were NOT denied access to their own keys.

        -
  • Couldn't this be defeated by running a Pentium-with-palladium emulator. It would implment all the normal instructions (like add, jmp, etc) properly, it would handle the authentication instructions by always saying yes, and it would handle encryption and decryption opcods with noops. For the icing on the cake, it could log all keys sent to it to /var/www/html/keys.txt.

    You would start with a freshly formatted harddrive (prefferably non-DRM crippled, but as long as it can run Linux and your emulator, it's fin
    • Yes, but you need a root key that is signed by some authority (the kind of keys that are embedded in the chips).

      If you can get ahold of one of these keys, then you can simulate running a "trusted" system and cheat the DRM. They won't be easy to get ahold of though. Modchips will probably prove a better avenue.
    • Couldn't this be defeated by running a Pentium-with-palladium emulator.

      An assumption that DRM-proponents sometimes forget to mention is that the system will require government cooperation to work at all.

      Specifically, anyone who cracks open DRM hardware to read keys that could be used to make an emulator must be treated as the highest class of terrorist. To protect the American way, corporate property must be respected!

      DRM technology is really only there to make the process of circumventing or emulatin
      • An assumption that DRM-proponents sometimes forget to mention is that the system will require government cooperation to work at all. Specifically, anyone who cracks open DRM hardware to read keys that could be used to make an emulator must be treated as the highest class of terrorist. To protect the American way, corporate property must be respected!

        Probably the DMCA is enough. Cracking open a Trusted Computing chip will count as circumventing copyright protection technology, which is criminalized by th
  • ...able to check that none of its software is compromised and even (in a future version) prove its integrity to a remote system.

    How do you do that? I mean, how do you prove that the system is secure and not just pretending to be secure by doing *almost* all of the things that would be needed to be secure?

    I could understand how a system could (eg) verify a signature on a kernel in order to boot it up, but this is a Linux system, therefore:

    1. Its open source. You must (by requirements of the GPL) be
    • 2. Has the kernel module loading facility been disabled?

      No, but it verifies that any modules have also been signed before loading them. (Alternatively, the superuser could force an untrusted module to be loaded, but this will taint the whole kernel and it will lose the ability to open protected files until you reboot)

      1. Its open source. You must (by requirements of the GPL) be given everything you need to compile a derivitive work of this.

      The currently prevaling legal interpretation (shared by Linus
      • Suppose you buy a Playstation5 from Sony and request the kernel code under GPL. If you compile the kernel without having the key, you've got a working kernel. The hardware you own won't load it, but that's not Sony's problem....

        I would rather that this legal interpretation doesn't hold, as it perverts the intent of GNU "Free Software", but it hasn't been seriously challenged yet.

        It makes a lot of sense to me. Otherwise, under your preferred interpration, I could sign your GNU software, and set up a ma
        • I could sign your GNU software, and set up a machine that will only run the signed version.

          The argument I would hope to make (possibly needing a modified GPL license version to explicitly require this) is that by signing the software (which is my copyright), you have created a derivative work, which is illegal. The only way I'll permit you to distribute it is if you agree to supply the recipients with anything needed to create the binary they got. This means the source code, the compilers (if they're h
  • The TPM is a hardware component that implements the security model. It so happens that this exists on a bunch of modern IBM laptops. It is disabled by default.

    Background: The TPM contains a number of PCRs. These are (roughly) hashes of bits of code -- the BIOS, the bootloader, the kernel, etc. The TPM also contains a private/public key pair which is generated when you reinitialize the TPM (i.e. the private key is not known to anybody).

    The TPM can be used to encrypt a blob of data using the private key. It

  • There's a lot of talk (Score:2, Interesting)

    by Kickasso ( 210195 )
    about how TCPA will kill open source. This outcome is very probable. But they can also work fine together. There is a solution, and open source people would do good by pursuing it instead of blindly fighting the inevitable.

    TCPA needs an agreed-upon, standard microkernel around which different OSes could be built. A whole bunch of new open source OSes and, yes, new Microsoft OSes. This microkernel would be developed by an independent body and signed by DRM-loving vendors. Because it would be very small, and

Slashdot Top Deals

Single tasking: Just Say No.

Close