Adam Back writes:
- Palladium is a proposed OS feature-set based on the TCPA hardware (Microsoft)
Actually there seem to be some hardware differences between TCPA and Palladium. TCPA relies on a TPM, while Palladium uses some kind of new CPU mode. Palladium also includes some secure memory, a concept which does not exist in TCPA.
The main 4 features proposed in the TCPA/palladium scheme are:
1. secure bootstrap -- checksums of BIOS, firmware, privileged OS code are used to ensure the machine knows whether it is running certified software or not. This is rooted in hardware, so you can't by pass it by using virtualization, only by hardware hacking (*).
2. software attestation -- the hardware supports attesting to a third party whether a call comes from a certified software component as assured by the hardware described in feature 1.
More generally, the hardware can attest to many aspects of the current machine state, including the cumulative hash of the software which has booted so far.
3. hardware assisted compartmentalization -- CPU can run privileged software, and RAM can contain information that you can not examine, and can not modify. (Optionally the software source can be published, but that is not necessary, and if it's not you won't be able to reverse-engineer it as it can be encrypted for the CPU).
TCPA does not get into this part, only the Palladium white paper mentions this. However it does seem to be a logical component for effective trusted computing.
4. sealing -- applications can store data that can only be read by that application. This works based on more hardware -- the software state checksums developed in feature 1 are used by hardware to generate encryption keys. The hardware will refuse to generate the key unless the same software state is running.
Right. This plus the attestation are what allow an application to create a "closed world". See my earlier message for examples of how this could be used to enhance privacy and anonymity. What better example of a closed world than your own secrets?
It's interesting to see that one of the author's of [6] has said that TCPA as curently formed is a bad thing and is trying to influence TCPA to make it more open, to exhibit stronger privacy properties read his comments at [7].
I don't think his comments make that much sense. I'd be curious to read your take on them. What is he talking about with the non-malleable root of trusted storage? Trusted storage seems like one of the least objectionable aspects. Is he confusing this with the endorsement key, used to make the remote attestations? Or is this related to the idea that you won't be able to boot your OS of choice?
There are a lot of potential negative implications of this technology, it represents a major shift in the balance of power comparable in magnitude to the clipper chip:
1. Potentially cedes control of the platform -- while the palladium docs talk about being able to boot the hardware with TCPA turned off, there exists possibility that with minor configuration change the hardware / firmware ensemble that forms palladium/TCPA could be configured to allow only certified OSes to boot, period. It's intereseting to note, if I read correctly, that the X-box (based on celeron processor and TCPA / TCPA-like features) does employ this feature. See for example: [8].
This is of course one of the biggest criticisms of TCPA - that it could be changed so that you will only be able to boot certified OS's. Don't you think that would have to be done by law, rather than as a preemptive act by the technologists (for antitrust reasons if nothing else)? Why would such a law be passed? IMO the social changes necessary to even begin to imagine such a drastic step are so huge that the technological implementation seems minor in comparison. I don't think it is fair to criticize this proposal for such a far-fetched possibility.
The documents talk about there being no barrier to certifying TCPA aware extensions to open-source OSes. However I'm having trouble figuring out how this would work. Perhaps IBM with it's linux support would build a TCPA extension for linux. Think about it -- the extension runs in privileged mode, and presumably won't be certified unless it passes some audit enforcing TCPA policies. (Such as keeping the owner of the machine from reading sealed documents, or reading the contents of DRM policy controlled documents without meeting the requirements for the DRM policy.)
TCPA doesn't currently cover certifying operating systems. They talk about certifying TPMs, about certifying PC hardware designs and implementations. Possibly in the next version they will get into issues like this. In the mean time, supposedly HP is going forward with an OS that can use TCPA features.
2. DSS over-again -- a big aspect of the DSS reverse-engineering was to allow DVDs to be played in software on linux. The TCPA platform seems to have the primary goal of making a framework within which it is possible to build extensions to implement hardware tamper resistant DRM. (The DRM implementation would run in a hardware assisted code compartment as described in feature 3 above). So now where does that put open source platforms? Will they be able to read such DRM protected content? It seems likely that in the longer term the DRM platform will include video cards without access to video memory, perhaps encryption of the video signal out to the monitor, and of audio out to the speakers. (There are other existing schemes to do these things which dovetail into the likely TCPA DRM framework.)
With the secure boot strap described in feature 1, the video card and so on are also part of the boot strap process, so the DRM system would have ready support from the platform for robustly refusing to play except on certain types of hardware. Similarly the application software which plays these DRM policy protected files and talks to the DRM policy module in the hardware assisted code compartment will itself be an application which uses the security boot-strapping features. So it won't be possible to write an application on for example linux to play these files without an audit and license etc from various content, DRM and OS cartels. This will lead to exactly the kind of thing Richard Stallman talked about in his prescient paper on the coming platform and right to develop competing software control wars [9].
I think this analysis is largely correct, except that it won't be as monolithic as you make it sound. There won't be just one content supplier who judges all software, that's obviously impossible. Rather, each different supplier will make its own determination of which software you can trust. And likewise for non-DRM applications. Banks will decide which banking software to trust. Game networks will decide which game clients to trust, etc.
3. Privacy support is broken -- the "privacy" features while clearly attempts to defuse a re-run at the pentium serial number debacle, have not really fixed it's problems. You have to trust the "Trusted Third Party" privacy CA not to track you and not to collude with other CAs and software vendors. There are known solutions to this particular sub-problem, for example Stefan Brands digital credentials [10], which can be used to build a cryptographically assured privacy preserving PKI avoiding the linking problems arising from identity based and attribute certificates.
I agree that it would be nice to see more flexibility there. The Chaum blinding patent expires in 2005, so maybe around then we can start seeing privacy CA's that use blind signatures, which solves that problem. The spec is obviously trying hard to protect privacy, it's just that the mechanisms to do it right are extremely complex compared to the straightforward way.
4. Strong enforcement for DMCA DRM excesses -- the types of DRM system which the platform enables stand a fair chance of providing high levels of enforcement for things which though strictly legally mandated (copyright licensing restrictions, limited number of plays of CDs / DVDs other disadvantageous schemes; inflexible and usurious software licensing), if enforced strictly would have deleterious effects on society and freedom. Copyright violation is widely practiced to a greater or less extent by just about all individuals. It is widely viewed as acceptable behavior. These social realities and personal freedoms are not taken into account or represented in the lobbying schemes which lead to the media cartels obtaining legal support for the erosion of users rights and expansionist power grabs in DMCA, WIPO etc.
Some of these issues might be not so bad except for the track records, and obvious monopolistic tendencies and economic pressures on the entities who will have the root keys to the worlds computers. There will be no effect choice or competition due to existing near monopolies, or cartelisation in the hardware, operating system, and content distribution conglomerates.
Nobody's putting a gun to your head and making you download content. If you can't agree to the conditions, go do something else. There are much worse things that can happen in the world than that copyright becomes enforceable. Why not give the market a chance? Company A provides the data with Draconian DRM restrictions; company B gives you more flexibility in what you do. All else being equal, people will prefer company B. So they can charge more. In this way a balance will be reached depending on how much people really value this kind of flexibility and how much they are willing to pay for it. You and I don't get to decide, the people who are making the decisions about what content to buy will decide. And nobody's got the root key to my computer. You make this claim in many places in the document. What exactly is this "root key" in TCPA terms? The endorsement key? It's private part is generated on-chip and never leaves the chip!
5. Strong enforcement for the software renting model -- the types of software licensing policy enforcement that can be built with the platform will also start to strongly enable the software and object rental ideas. Again potentially these models have some merit except that they will be sabotaged by API lock out, where the root key owners will be able to charge monopoly rents for access to APIs.
I don't follow this. What root key owners? What APIs? Could you say more about how TCPA will help with software rental?
6. Audits and certification become vastly more prevalent. Having had some involvement with software certification (FIPS 140-1 / CC) I can attest that this can be expensive exercises. It is unlikely that the open source community will be able to get software certified due to cost (the software is free, there is no business entity to claim ownership of the certification rights, and so no way to recuperate the costs). While certification where competition is able to function is a good thing, providing users with a transparency and needed assurance, the danger with tying audits to TCPA is that it will be another barrier to entry for small businesses, and for open source particularly.
This is a good point, but again it depends on the specific content realm. There are not just one or two - there are thousands of kinds of content, or even more. Not everyone is going to require FIPS 140 levels of certification! But possibly Disney and Sony will. My guess is that if there ever is a Linux program that will play their movies, it will be because those companies contracted to get it written. You may see this in many contexts - software applications don't get certified, rather they are supplied by the vendors, or the vendors arrange to get them done.
7. Untrusted, unauditable software will be able to run without scrutiny inside the hardware assisted code compartments. Some of the documentation talks about open sourcing some aspects. While this may come to pass, but that sounded like the TOR (Trusted Operating Root); other extension modules also running in unauditable compartments will not be so published.
This part I don't understand too much; it's not a TCPA concept, and there is little known about Palladium. Supposedly the idea is that this is a place that code can run without being touched by debuggers or viruses. I don't know what happens if a virus gets itself loaded into this area, if that is even possible. Maybe all the different compartments are isolated from each other. Does this seem like a bad feature to you?
8. Gives away root control of your machine -- providing potentially universal remote control of users machines to any government agencies with access to the TCPA certification master keys, or policies allowing them to demand certifications on hostile code on demand. Central authorities are likely to be the only, or the default controllers of the firmware/software upgrade mechanism which comes as part of the secure bootstrap feature.
Now you're starting to go paranoid. All the TCPA certification master keys do is to certify that a system is TCPA compliant. They don't have a remote control over your machine! They are more analogous to Verisign in the X.509 world. Last I checked they hadn't taken over my box. As far as the field upgrade, it has to be authorized by the owner. I'm disappointed to see this kind of fantasizing in what has been a well grounded document until now. If you're going to make this kind of charge, that TCPA gives a universal remote control to government, you need to back it up in detail.
9. Provides a dangerously tempting target for government power-grabs -- governments will be very interested to be able to abuse the power provided by the platform, to gain access to it's keys to be able to insert remote backdoors, and/or to try to mandate government policy enforcement modules once such a platform is built. Think this is unrealistic? Recall clipper? The TCPA is a generic extensible policy enforcement architecture which can be configured to robustly enforce policies against the interests of the machine owner. Clipper, key-escrow the whole multi-year fight, at some point in the near future if some of the more egregious TCPA/Palladium framework features and configuration possibilities becomes widely deployed could be implemented after the fact, as a TCPA/Palladium policy extentsion which runs in the hardware assisted code compartment and is authenticated up to the hardware boot by the secure bootstrapping process.
I don't agree with your characterization that TCPA enforces policies against the owner's interests. He has to voluntarily agree to everything, from turning on TCPA, to booting a TCPA compliant program, to running an application which some third party will trust, to accepting data from that third party under agreed-upon conditions. If at any step he didn't feel that what he was doing was in his interests, he can stop and do something else. When you walk into a store and pay money for food, is that store enforcing policies against your interests? Only from the most shallow perspective, for if such policies were not widely enforced, you and I and everyone else would starve. We all participate voluntarily in these institutions. Each payment we make is in our interests. And the same thing is true if you receive some data with conditions on how it is manipulated. As far as the concern about changes, I think the smart thing to do is to fight the bad and promote the good. Definitely we should oppose any proposal to make TCPA non-voluntary, to force people to boot a certain OS, to limit what they can do on their computers. But presently none of those features are in TCPA. Rather than saying TCPA is bad because someone could make all these hypothetical changes, it makes more sense to judge TCPA on its own, as a system that emphasizes user choice. Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, we should fight proposals to make it involuntary.
So what I've read so far, I think people's gut reactions are right -- that it's an aggressive and abmitious power grab by the evil empire -- the 3 cartels / monopolies surrounding PC hardware, Operating systems and Content Distribution. The operating system near monoply will doubtless find creative ways to use and expand the increased control to control application interoperability (with the sealing function), to control with hardware assistance the access to undocumented APIs (no more reverse engineering, or using the APIs even if you do / could reverse engineer).
I think you are looking at it far too narrowly. Yes, this will provide many opportunities for Microsoft to write new kinds of software. But the same is true for every other software company! Financial software, web services, security software, accounting - anything that involves trust and security can benefit from TCPA. Look at the example I gave earlier for a TCPA based anonymous comm network. Multiply that a thousand fold. It's stupid to just look at what one company can do with this, without considering what a whole world of creative people can accomplish. Yes, it can make reverse engineering much more difficult. But I'd rather see people put their creative efforts into creating new products rather than copying and piggybacking off someone else's success.
So some of the already applications are immediately objectionable. The scope for them to become more so with limited recourse or technical counter-measures possible on the part of the user community is huge. Probably the worst aspect is the central control -- it really effectively does give remote root control to your machine to people you don't want to trust. Also the control _will_ be abused for monopolistic rent seeking and exclusionary policies to lock-out competition. Don't forget the fact that microsoft views linux as a major enemy as revealed by documents uncovered some the anti-trust discovery process.
Again, you need to justify this remote root control notion. I don't see it at all. Go back to your four functions of TCPA/Palladium - they were pretty accurate. Where was the remote root control in there?
In fact I'd say this is the biggest coming risk to personal freedom since the days during the onset of the clipper chip / key escrow looked like they stood some chance of becoming reality.
I'd say that it is a powerful technology with an almost infinite number of potential applications. Being able to trust software running on a remote system is something that has never been possible before on the Internet. We can only begin to see what will be possible with this capability.
On Mon, 5 Aug 2002, AARG! Anonymous wrote:
Adam Back writes:
2. DSS over-again -- a big aspect of the DSS reverse-engineering was to allow DVDs to be played in software on linux. The TCPA platform seems to have the primary goal of making a framework within which it is possible to build extensions to implement hardware tamper resistant DRM. (The DRM implementation would run in a hardware assisted code compartment as described in feature 3 above). So now where does that put open source platforms? Will they be able to read such DRM protected content? It seems likely that in the longer term the DRM platform will include video cards without access to video memory, perhaps encryption of the video signal out to the monitor, and of audio out to the speakers. (There are other existing schemes to do these things which dovetail into the likely TCPA DRM framework.)
With the secure boot strap described in feature 1, the video card and so on are also part of the boot strap process, so the DRM system would have ready support from the platform for robustly refusing to play except on certain types of hardware. Similarly the application software which plays these DRM policy protected files and talks to the DRM policy module in the hardware assisted code compartment will itself be an application which uses the security boot-strapping features. So it won't be possible to write an application on for example linux to play these files without an audit and license etc from various content, DRM and OS cartels. This will lead to exactly the kind of thing Richard Stallman talked about in his prescient paper on the coming platform and right to develop competing software control wars [9].
I think this analysis is largely correct, except that it won't be as monolithic as you make it sound. There won't be just one content supplier who judges all software, that's obviously impossible. Rather, each different supplier will make its own determination of which software you can trust. And likewise for non-DRM applications. Banks will decide which banking software to trust. Game networks will decide which game clients to trust, etc.
3. Privacy support is broken -- the "privacy" features while clearly attempts to defuse a re-run at the pentium serial number debacle, have not really fixed it's problems. You have to trust the "Trusted Third Party" privacy CA not to track you and not to collude with other CAs and software vendors. There are known solutions to this particular sub-problem, for example Stefan Brands digital credentials [10], which can be used to build a cryptographically assured privacy preserving PKI avoiding the linking problems arising from identity based and attribute certificates.
I agree that it would be nice to see more flexibility there. The Chaum blinding patent expires in 2005, so maybe around then we can start seeing privacy CA's that use blind signatures, which solves that problem. The spec is obviously trying hard to protect privacy, it's just that the mechanisms to do it right are extremely complex compared to the straightforward way.
4. Strong enforcement for DMCA DRM excesses -- the types of DRM system which the platform enables stand a fair chance of providing high levels of enforcement for things which though strictly legally mandated (copyright licensing restrictions, limited number of plays of CDs / DVDs other disadvantageous schemes; inflexible and usurious software licensing), if enforced strictly would have deleterious effects on society and freedom. Copyright violation is widely practiced to a greater or less extent by just about all individuals. It is widely viewed as acceptable behavior. These social realities and personal freedoms are not taken into account or represented in the lobbying schemes which lead to the media cartels obtaining legal support for the erosion of users rights and expansionist power grabs in DMCA, WIPO etc.
Some of these issues might be not so bad except for the track records, and obvious monopolistic tendencies and economic pressures on the entities who will have the root keys to the worlds computers. There will be no effect choice or competition due to existing near monopolies, or cartelisation in the hardware, operating system, and content distribution conglomerates.
Nobody's putting a gun to your head and making you download content. If you can't agree to the conditions, go do something else. There are much worse things that can happen in the world than that copyright becomes enforceable.
Why not give the market a chance? Company A provides the data with Draconian DRM restrictions; company B gives you more flexibility in what you do. All else being equal, people will prefer company B. So they can charge more. In this way a balance will be reached depending on how much people really value this kind of flexibility and how much they are willing to pay for it. You and I don't get to decide, the people who are making the decisions about what content to buy will decide.
And nobody's got the root key to my computer. You make this claim in many places in the document. What exactly is this "root key" in TCPA terms? The endorsement key? It's private part is generated on-chip and never leaves the chip!
I agree that the market can have the chance!! Just don't make it anything to do with the law! If people want to buy platforms with TCPA built in they should be allowed to, and those who don't should be free to choose that way. You now claim there are at least 2 keys that don't leave the chip, but if you are going to recover anything encrypted by those keys you had better have them off chip when the chip dies.
7. Untrusted, unauditable software will be able to run without scrutiny inside the hardware assisted code compartments. Some of the documentation talks about open sourcing some aspects. While this may come to pass, but that sounded like the TOR (Trusted Operating Root); other extension modules also running in unauditable compartments will not be so published.
This part I don't understand too much; it's not a TCPA concept, and there is little known about Palladium. Supposedly the idea is that this is a place that code can run without being touched by debuggers or viruses. I don't know what happens if a virus gets itself loaded into this area, if that is even possible. Maybe all the different compartments are isolated from each other.
Does this seem like a bad feature to you?
D'oh!! Obviously it's a bad feature - it gives my computer to some unknown entity. In fact, it gives the entire network of computers to one entity - it creates a huge monster of unequal power. I can sure see why a government like Iraq would love to have this feature. Or China. Or the US. You could run a special program that nobody can stop or find or know about. That's *POWER*. It is difficult to understate how bad that is.
8. Gives away root control of your machine -- providing potentially universal remote control of users machines to any government agencies with access to the TCPA certification master keys, or policies allowing them to demand certifications on hostile code on demand. Central authorities are likely to be the only, or the default controllers of the firmware/software upgrade mechanism which comes as part of the secure bootstrap feature.
Now you're starting to go paranoid. All the TCPA certification master keys do is to certify that a system is TCPA compliant. They don't have a remote control over your machine! They are more analogous to Verisign in the X.509 world. Last I checked they hadn't taken over my box. As far as the field upgrade, it has to be authorized by the owner.
I'm disappointed to see this kind of fantasizing in what has been a well grounded document until now. If you're going to make this kind of charge, that TCPA gives a universal remote control to government, you need to back it up in detail.
Look, if there can be a section of code that only the manufacturer has access to, then that section of code could have an internet download section that sucks "evil intent" from someplace the manufacturer (or someone who's broken into them) has designated. It's not that we're saying it'd be done on purpose up front, but somebody some day will figure it out and all the tools are there to make it happen. Sometimes a good imagination can save you from having to be paranoid.
9. Provides a dangerously tempting target for government power-grabs -- governments will be very interested to be able to abuse the power provided by the platform, to gain access to it's keys to be able to insert remote backdoors, and/or to try to mandate government policy enforcement modules once such a platform is built. Think this is unrealistic? Recall clipper? The TCPA is a generic extensible policy enforcement architecture which can be configured to robustly enforce policies against the interests of the machine owner. Clipper, key-escrow the whole multi-year fight, at some point in the near future if some of the more egregious TCPA/Palladium framework features and configuration possibilities becomes widely deployed could be implemented after the fact, as a TCPA/Palladium policy extentsion which runs in the hardware assisted code compartment and is authenticated up to the hardware boot by the secure bootstrapping process.
I don't agree with your characterization that TCPA enforces policies against the owner's interests. He has to voluntarily agree to everything, from turning on TCPA, to booting a TCPA compliant program, to running an application which some third party will trust, to accepting data from that third party under agreed-upon conditions. If at any step he didn't feel that what he was doing was in his interests, he can stop and do something else.
When you walk into a store and pay money for food, is that store enforcing policies against your interests? Only from the most shallow perspective, for if such policies were not widely enforced, you and I and everyone else would starve. We all participate voluntarily in these institutions. Each payment we make is in our interests. And the same thing is true if you receive some data with conditions on how it is manipulated.
As far as the concern about changes, I think the smart thing to do is to fight the bad and promote the good. Definitely we should oppose any proposal to make TCPA non-voluntary, to force people to boot a certain OS, to limit what they can do on their computers. But presently none of those features are in TCPA. Rather than saying TCPA is bad because someone could make all these hypothetical changes, it makes more sense to judge TCPA on its own, as a system that emphasizes user choice.
Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, we should fight proposals to make it involuntary.
Then we agree completely! So long as no laws are passed around TCPA, and it is not linked to any copyright laws, or mandated in any way, then there's no problem! IF TCPA gives people something they want, and they understand how it works, I don't see anything wrong with it. I do see a problem in it being written into any laws because the potential for abuse is huge.
So what I've read so far, I think people's gut reactions are right -- that it's an aggressive and abmitious power grab by the evil empire -- the 3 cartels / monopolies surrounding PC hardware, Operating systems and Content Distribution. The operating system near monoply will doubtless find creative ways to use and expand the increased control to control application interoperability (with the sealing function), to control with hardware assistance the access to undocumented APIs (no more reverse engineering, or using the APIs even if you do / could reverse engineer).
I think you are looking at it far too narrowly. Yes, this will provide many opportunities for Microsoft to write new kinds of software. But the same is true for every other software company! Financial software, web services, security software, accounting - anything that involves trust and security can benefit from TCPA. Look at the example I gave earlier for a TCPA based anonymous comm network. Multiply that a thousand fold. It's stupid to just look at what one company can do with this, without considering what a whole world of creative people can accomplish.
Yes, it can make reverse engineering much more difficult. But I'd rather see people put their creative efforts into creating new products rather than copying and piggybacking off someone else's success.
It will also make backups really expensive.
So some of the already applications are immediately objectionable. The scope for them to become more so with limited recourse or technical counter-measures possible on the part of the user community is huge. Probably the worst aspect is the central control -- it really effectively does give remote root control to your machine to people you don't want to trust. Also the control _will_ be abused for monopolistic rent seeking and exclusionary policies to lock-out competition. Don't forget the fact that microsoft views linux as a major enemy as revealed by documents uncovered some the anti-trust discovery process.
Again, you need to justify this remote root control notion. I don't see it at all. Go back to your four functions of TCPA/Palladium - they were pretty accurate. Where was the remote root control in there?
The only way it works is if there can be code the user doesn't control the loading of. That means somebody else controls the machine. It's pretty basic.
In fact I'd say this is the biggest coming risk to personal freedom since the days during the onset of the clipper chip / key escrow looked like they stood some chance of becoming reality.
I'd say that it is a powerful technology with an almost infinite number of potential applications. Being able to trust software running on a remote system is something that has never been possible before on the Internet. We can only begin to see what will be possible with this capability.
Horsepucky. I can run trusted software right now. *I* wrote it, that's why I trust it! I don't need a dongle on the motherboard to ship trusted software. An external dongle works just fine. And I can check the signature of source code I compile to be sure the author has sent me the correct code - I trust it will do what it's supposed to because the encrypted hash matches the source hash. going back to the key stuff - you've changed the names, but what it boils down to is that *somebody* has to have a copy of the internal keys used to encrypt data by the TPM. If it's not the user, who is it? That's the person who owns the data, because they own the keys. I'd say Adam did a nice job nailing TCPA to the wall. Now let's see if it dies slowly or quickly. Patience, persistence, truth, Dr. mike
What good is this TCPA stuff anyway? I haven't read anything, pro or con or ambivilent that shows me some clear advandage. It isn't going to fix anything near as I can tell, and with all other technology which has a primary purpose of restricting access, it will undoubtably cause some trouble. So, what's the point? Seems like a grand waste of effort to me.
On Mon, 5 Aug 2002, AARG!Anonymous wrote: < ... />
Why not give the market a chance? Company A provides the data with Draconian DRM restrictions; company B gives you more flexibility in what you do. All else being equal, people will prefer company B. So they can charge more. In this way a balance will be reached depending on how much people really value this kind of flexibility and how much they are willing to pay for it. You and I don't get to decide, the people who are making the decisions about what content to buy will decide.
I am much in sympathy with the "Give the market a chance." slogan. But TCPA/Palladium/DRM and Jack Valenti are not. Nor are you. Phillips could make and sell a device, even the sort of trammeled computer that Jack Valenti wishes to be universally imposed by law, within one year from today. Indeed, IBM, Sun, Apple, Dell, Sony, and any number of other companies could have sold such a device any day they wished over the past fifteen years. Yet they have not. So the market has decided, by your standard. The decision is clear: No DRM.
And nobody's got the root key to my computer. You make this claim in many places in the document. What exactly is this "root key" in TCPA terms? The endorsement key? It's private part is generated on-chip and never leaves the chip!
Of course, the minimal demand of the pro-DRM forces is to have root on every machine in the world, with evasion of their root control a felony. You support DRM lock stock and barrel, no matter your demonstrably inaccurate claims that 1. You are all for the market. 2. Well, DRM is not so bad, see, RIAA-MPAA-AAP will give us all root on their machines, so it is all equal! 3. Why, your computer will be exactly the same under DRM as it is today, except better!
5. Strong enforcement for the software renting model -- the types of software licensing policy enforcement that can be built with the platform will also start to strongly enable the software and object rental ideas. Again potentially these models have some merit except that they will be sabotaged by API lock out, where the root key owners will be able to charge monopoly rents for access to APIs.
I don't follow this. What root key owners? What APIs? Could you say more about how TCPA will help with software rental?
Today Microsoft and its script children have root on many machines, yet there is no single root password for them. Rather there is a system, which includes 1. agreements with Dell, IBM, etc., to only offer for sale hardware with Microsoft OSes loaded 2. hardware that only runs right with a Microsoft OS 3. extortionate forced "license agreements" with end-users 4. hypnotic control of the mass media, which always claim that "After all, you will have to run only Microsoft OSes forever." 5. hypnotic control of the managers who "decide" which OS to run, which managers always claim that "After all, we have to run only Microsoft OSes forever." Of course, this hypnosis is mainly self-hypnosis, with only trim-tab level direction by Microsoft, Dell, IBM, Sun, Apple, etc.. oo--JS.
6. Audits and certification become vastly more prevalent. Having had some involvement with software certification (FIPS 140-1 / CC) I can attest that this can be expensive exercises. It is unlikely that the open source community will be able to get software certified due to cost (the software is free, there is no business entity to claim ownership of the certification rights, and so no way to recuperate the costs). While certification where competition is able to function is a good thing, providing users with a transparency and needed assurance, the danger with tying audits to TCPA is that it will be another barrier to entry for small businesses, and for open source particularly.
This is a good point, but again it depends on the specific content realm. There are not just one or two - there are thousands of kinds of content, or even more. Not everyone is going to require FIPS 140 levels of certification!
But possibly Disney and Sony will. My guess is that if there ever is a Linux program that will play their movies, it will be because those companies contracted to get it written. You may see this in many contexts - software applications don't get certified, rather they are supplied by the vendors, or the vendors arrange to get them done.
7. Untrusted, unauditable software will be able to run without scrutiny inside the hardware assisted code compartments. Some of the documentation talks about open sourcing some aspects. While this may come to pass, but that sounded like the TOR (Trusted Operating Root); other extension modules also running in unauditable compartments will not be so published.
This part I don't understand too much; it's not a TCPA concept, and there is little known about Palladium. Supposedly the idea is that this is a place that code can run without being touched by debuggers or viruses. I don't know what happens if a virus gets itself loaded into this area, if that is even possible. Maybe all the different compartments are isolated from each other.
Does this seem like a bad feature to you?
8. Gives away root control of your machine -- providing potentially universal remote control of users machines to any government agencies with access to the TCPA certification master keys, or policies allowing them to demand certifications on hostile code on demand. Central authorities are likely to be the only, or the default controllers of the firmware/software upgrade mechanism which comes as part of the secure bootstrap feature.
Now you're starting to go paranoid. All the TCPA certification master keys do is to certify that a system is TCPA compliant. They don't have a remote control over your machine! They are more analogous to Verisign in the X.509 world. Last I checked they hadn't taken over my box. As far as the field upgrade, it has to be authorized by the owner.
I'm disappointed to see this kind of fantasizing in what has been a well grounded document until now. If you're going to make this kind of charge, that TCPA gives a universal remote control to government, you need to back it up in detail.
9. Provides a dangerously tempting target for government power-grabs -- governments will be very interested to be able to abuse the power provided by the platform, to gain access to it's keys to be able to insert remote backdoors, and/or to try to mandate government policy enforcement modules once such a platform is built. Think this is unrealistic? Recall clipper? The TCPA is a generic extensible policy enforcement architecture which can be configured to robustly enforce policies against the interests of the machine owner. Clipper, key-escrow the whole multi-year fight, at some point in the near future if some of the more egregious TCPA/Palladium framework features and configuration possibilities becomes widely deployed could be implemented after the fact, as a TCPA/Palladium policy extentsion which runs in the hardware assisted code compartment and is authenticated up to the hardware boot by the secure bootstrapping process.
I don't agree with your characterization that TCPA enforces policies against the owner's interests. He has to voluntarily agree to everything, from turning on TCPA, to booting a TCPA compliant program, to running an application which some third party will trust, to accepting data from that third party under agreed-upon conditions. If at any step he didn't feel that what he was doing was in his interests, he can stop and do something else.
When you walk into a store and pay money for food, is that store enforcing policies against your interests? Only from the most shallow perspective, for if such policies were not widely enforced, you and I and everyone else would starve. We all participate voluntarily in these institutions. Each payment we make is in our interests. And the same thing is true if you receive some data with conditions on how it is manipulated.
As far as the concern about changes, I think the smart thing to do is to fight the bad and promote the good. Definitely we should oppose any proposal to make TCPA non-voluntary, to force people to boot a certain OS, to limit what they can do on their computers. But presently none of those features are in TCPA. Rather than saying TCPA is bad because someone could make all these hypothetical changes, it makes more sense to judge TCPA on its own, as a system that emphasizes user choice.
Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, we should fight proposals to make it involuntary.
So what I've read so far, I think people's gut reactions are right -- that it's an aggressive and abmitious power grab by the evil empire -- the 3 cartels / monopolies surrounding PC hardware, Operating systems and Content Distribution. The operating system near monoply will doubtless find creative ways to use and expand the increased control to control application interoperability (with the sealing function), to control with hardware assistance the access to undocumented APIs (no more reverse engineering, or using the APIs even if you do / could reverse engineer).
I think you are looking at it far too narrowly. Yes, this will provide many opportunities for Microsoft to write new kinds of software. But the same is true for every other software company! Financial software, web services, security software, accounting - anything that involves trust and security can benefit from TCPA. Look at the example I gave earlier for a TCPA based anonymous comm network. Multiply that a thousand fold. It's stupid to just look at what one company can do with this, without considering what a whole world of creative people can accomplish.
Yes, it can make reverse engineering much more difficult. But I'd rather see people put their creative efforts into creating new products rather than copying and piggybacking off someone else's success.
So some of the already applications are immediately objectionable. The scope for them to become more so with limited recourse or technical counter-measures possible on the part of the user community is huge. Probably the worst aspect is the central control -- it really effectively does give remote root control to your machine to people you don't want to trust. Also the control _will_ be abused for monopolistic rent seeking and exclusionary policies to lock-out competition. Don't forget the fact that microsoft views linux as a major enemy as revealed by documents uncovered some the anti-trust discovery process.
Again, you need to justify this remote root control notion. I don't see it at all. Go back to your four functions of TCPA/Palladium - they were pretty accurate. Where was the remote root control in there?
In fact I'd say this is the biggest coming risk to personal freedom since the days during the onset of the clipper chip / key escrow looked like they stood some chance of becoming reality.
I'd say that it is a powerful technology with an almost infinite number of potential applications. Being able to trust software running on a remote system is something that has never been possible before on the Internet. We can only begin to see what will be possible with this capability.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
Some comments on selected parts of anonymous post: 1) about claimed "complexity" of cryptographically assured privacy, rather than the current "trust me" privacy via the privacy CA "TTP": Anonymous writes:
Adam Back wrote:
3. Privacy support is broken -- the "privacy" features while clearly attempts to defuse a re-run at the pentium serial number debacle, have not really fixed it's problems. You have to trust the "Trusted Third Party" privacy CA not to track you and not to collude with other CAs and software vendors. There are known solutions to this particular sub-problem, for example Stefan Brands digital credentials [10], which can be used to build a cryptographically assured privacy preserving PKI avoiding the linking problems arising from identity based and attribute certificates.
I agree that it would be nice to see more flexibility there. The Chaum blinding patent expires in 2005, so maybe around then we can start seeing privacy CA's that use blind signatures, which solves that problem. The spec is obviously trying hard to protect privacy, it's just that the mechanisms to do it right are extremely complex compared to the straightforward way.
To address privacy with for example Brands digital credentials, the underlying cryptography may be harder to understand, or at least less familiar, but I don't think using a toolkit based on Brands digital credentials would be significantly harder than using an identity or attribute based PKI toolkit. Similar for Chaum's credentials or other approach. Also I notice you imply patents are a problem. However, the TCPA itself has patents and will of course charge for the hardware. Patents it doesn't seem would present a problem for this application, where there is non-zero reproduction cost hardware involved. 2) about the "root key" / potential for malicious remote control claim that I make (and Ross Anderson I think also makes):
And nobody's got the root key to my computer. You make this claim in many places in the document. What exactly is this "root key" in TCPA terms? The endorsement key? It's private part is generated on-chip and never leaves the chip!
The "root key" to your computing environment is the private key of the CA that signs the software updates. You'll recall that in the secure boot-strapping process if you choose to boot in the TCPA mode, if there are deviations or updates these are fetched and are only accepted if certified by the layer owner. (I presume different layers would have updates and certification managed by different vendors Eg. hardware vendor / TPM vendor for firmware, OS manufactturer for OS, application manufacturer for application software etc, and that the secure bootstrap process would accordingly transfer control to the respective next layers certification keys in case of need for software update.) The closer to the hardware a software update is the more pervasive the control a malicious update could exert. For example there are apparently plans for TPM mediated direct path to input devices (esp. keyboard), a malicious update close enough to the hardware could subvert this protection. and more on the "root key" problem:
8. Gives away root control of your machine -- providing potentially universal remote control of users machines to any government agencies with access to the TCPA certification master keys
[...] All the TCPA certification master keys do is to certify that a system is TCPA compliant. They don't have a remote control over your machine! They are more analogous to Verisign in the X.509 world. Last I checked they hadn't taken over my box. As far as the field upgrade, it has to be authorized by the owner.
The root key is not the endorsement master keys -- that one just allows the TPM vendor to extract rent from the hardware manufacturers -- I mean the update certification keys which will I presume be part of the software update features described in the secure boot-strapping. You said somewhere in this thread that the user must approve software and firmware updates. However: - the user will not see the source code for the updates - the user is not in a position to evaluate the update - there will be lots of updates (daily, weekly -- look at microsofts security bug fix rate), to the extent that the user will blindly click ok. - there is nothing the user can do to determine whether the update he gets is also the same one other users of the OS get, vs a key board sniffer the FBI or NSA request is inserted, or have copies of the software update root keys to insert themselves. The problem is the centralised control. The user must at minimum be able to choose his own software update certification agents. We need transparency, distributed control, and openness to allow people to use third party auditors they trust and have reason to trust to audit and endorse updates. 3) about my claim that TCPA is a platform for enforcing policies against the users interests:
9. Provides a dangerously tempting target for government power-grabs -- governments will be very interested to be able to abuse the power provided by the platform, to gain access to it's keys to be able to insert remote backdoors, and/or to try to mandate government policy enforcement modules once such a platform is built. Think this is unrealistic? Recall clipper? The TCPA is a generic extensible policy enforcement architecture which can be configured to robustly enforce policies against the interests of the machine owner. Clipper, key-escrow the whole multi-year fight, at some point in the near future if some of the more egregious TCPA/Palladium framework features and configuration possibilities becomes widely deployed could be implemented after the fact, as a TCPA/Palladium policy extentsion which runs in the hardware assisted code compartment and is authenticated up to the hardware boot by the secure bootstrapping process.
I don't agree with your characterization that TCPA enforces policies against the owner's interests. He has to voluntarily agree to everything, from turning on TCPA, to booting a TCPA compliant program, to running an application which some third party will trust, to accepting data from that third party under agreed-upon conditions. If at any step he didn't feel that what he was doing was in his interests, he can stop and do something else.
He has no choice due to architectural design decisions, probably motivated by economic profit motives in retaining monopoly control of the TCPA consortium members. The control is ceded at the root of the secure boot-strapping framework. After that all user choice is gone, all he can do is turn TCPA off. I'm assuming that over time increasing amounts of the OS and applications will simply not function without being in TCPA mode, so turning TCPA off will increasingly become a non-choice. Specifically, you will be able to "choose" not to use the only tools that will read formats used by 90+% of the world, and which are only available for the Windows platform, and only when in TCPA mode, to allow the platform to meet copyright tracking, IP ownership tracking or other policy features implemented with the document format. The danger once we get to this scenario is that as I described above TCPA itself becomes "a generic extensible policy enforcement architecture which can be configured to robustly enforce policies against the interests of the machine owner." This could be used for all kinds of malware policies which would run in the secure code compartments, for example: - clipper / US key escrow implementation as a TCPA policy module - big brotherish policies for regimes interested in censoring and imposing policies on users such as China, Iraq etc While it may be possible technically to boot in non TCPA mode, or to boot an open source OS without the malware, most users will not have the technical ability to know when they are at risk and when not and what to do to avoid having the government policies enforced upon them. All kinds of dubious laws in western countries could start to see stricter enforcement. Fair use rights erosion, data retention laws, and on; I really think full enforcement of current and soon coming laws will make things very unpleasant and greatly erode individual rights. 4) about likely future directions for TCPA / Palladium upon which some of the complaints are based:
As far as the concern about changes, I think the smart thing to do is to fight the bad and promote the good. Definitely we should oppose any proposal to make TCPA non-voluntary, to force people to boot a certain OS, to limit what they can do on their computers. But presently none of those features are in TCPA. Rather than saying TCPA is bad because someone could make all these hypothetical changes, it makes more sense to judge TCPA on its own, as a system that emphasizes user choice.
A number of the features which are "not in TCPA" are obvious design motivators. For example online content DRM. Others are obvious things that Microsoft has been aggressively trying to do for years. I'm not sure why you suppose they will stop persuing tricks such as format compatibility lock-out, hidden changing APIs, using every trick in the book. Similarly I'm not sure why you presume governments will have no interest in exerting control on the platform. Governments are certainly not technology leaders, but they sure were persistent in trying to persue the whole crypto-tech export legislation, clipper/key-escrow and so on. Also this platform will be used world wide. There are more repressive regimes with much more intrusive plans. 5) about voluntary vs involuntary TCPA
Involuntary TCPA is bad, voluntary is good. So we should not fight TCPA, we should fight proposals to make it involuntary.
Initial claims of "voluntary" is the standard trick for reducing resistant to deployment. Look at history of various technologies relating to privacy and security, or just politics in general. First it's voluntary, then it becomes voluntary in name only (you can choose not to, put the "choice" is marginalized to become almost meaningless), and finally the last step is to not even pretend it's voluntary. I think it's interesting to explore what can be fixed about TCPA. It's putative voluntary / mandatory status is one aspect, true, but more interesting ones are to ensure it is open, has distributed user configurable control, open access to APIs and non-discriminatory licensing with no policy strings attached. Adam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
Why not give the market a chance? Company A provides the data with Draconian DRM restrictions; company B gives you more flexibility in what you do. All else being equal, people will prefer company B. So they can charge more. In this way a balance will be reached depending on how much people really value this kind of flexibility and how much they are willing to pay for it. You and I don't get to decide, the people who are making the decisions about what content to buy will decide. That assumes there is a competitive market. Supposing you need Microsoft Office. you probably don't actually care
On Mon, 5 Aug 2002, AARG!Anonymous wrote: that much if you use MS Office, Sun Staroffice, Ability write or whatever - but you need to interoperate with companies that *do* use Microsoft Office. If you don't like the Microsoft version of Microsoft Office because of its draconian insistance on running *only* on a Trusted machine with a Trusted Operating System, how do you proceed? particularly as it would be trivial to make reverse-engineered interoperable office suites illegal under the DMCA? Music, video, text, computer programs - all are governed by legally-enforced monopoly rights of patent and/or copyright, the latter continually extended to prevent micky mouse ever becoming public domain - and all meaning there is but a single source you can obtain whatever it is you need or want from, so you either have to take whatever restrictions are imposed (fair use being invalid in a DMCA world) or do without.
AARG!Anonymous wrote:
Adam Back writes:
- Palladium is a proposed OS feature-set based on the TCPA hardware (Microsoft)
Actually there seem to be some hardware differences between TCPA and Palladium. TCPA relies on a TPM, while Palladium uses some kind of new CPU mode. Palladium also includes some secure memory, a concept which does not exist in TCPA.
This is correct. Palladium has "ring -1", and memory that is only accessible to ring -1 (or I/O initiated by ring -1). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
participants (7)
-
AARG! Anonymous -
Adam Back -
Ben Laurie -
cubic-dog -
Dave Howe -
Jay Sulzberger -
Mike Rosing