Re: Challenge to David Wagner on TCPA
Eric Murray writes:
TCPA (when it isn't turned off) WILL restrict the software that you can run. Software that has an invalid or missing signature won't be able to access "sensitive data"[1]. Meaning that unapproved software won't work.
[1] TCPAmain_20v1_1a.pdf, section 2.2
We need to look at the text of this in more detail. This is from version 1.1b of the spec: : This section introduces the architectural aspects of a Trusted Platform : that enable the collection and reporting of integrity metrics. : : Among other things, a Trusted Platform enables an entity to determine : the state of the software environment in that platform and to SEAL data : to a particular software environment in that platform. : : The entity deduces whether the state of the computing environment in : that platform is acceptable and performs some transaction with that : platform. If that transaction involves sensitive data that must be : stored on the platform, the entity can ensure that that data is held in : a confidential format unless the state of the computing environment in : that platform is acceptable to the entity. : : To enable this, a Trusted Platform provides information to enable the : entity to deduce the software environment in a Trusted Platform. That : information is reliably measured and reported to the entity. At the same : time, a Trusted Platform provides a means to encrypt cryptographic keys : and to state the software environment that must be in place before the : keys can be decrypted. What this means is that a remote system can query the local TPM and find out what software has been loaded, in order to decide whether to send it some data. It's not that unapproved software "won't work", it's that the remote guy can decide whether to trust it. Also, as stated earlier, data can be sealed such that it can only be unsealed when the same environment is booted. This is the part above about encrypting cryptographic keys and making sure the right software environment is in place when they are decrypted.
Ok, technically it will run but can't access the data, but that it a very fine hair to split, and depending on the nature of the data that it can't access, it may not be able to run in truth.
If TCPA allows all software to run, it defeats its purpose. Therefore Wagner's statement is logically correct.
But no, the TCPA does allow all software to run. Just because a remote system can decide whether to send it some data doesn't mean that software can't run. And just because some data may be inaccessible because it was sealed when another OS was booted, also doesnt mean that software can't run. I think we agree on the facts, here. All software can run, but the TCPA allows software to prove its hash to remote parties, and to encrypt data such that it can't be decrypted by other software. Would you agree that this is an accurate summary of the functionality, and not misleading? If so, I don't see how you can get from this to saying that some software won't run. You might as well say that encryption means that software can't run, because if I encrypt my files then some other programs may not be able to read them. Most people, as you may have seen, interpret this part about "software can't run" much more literally. They think it means that software needs a signature in order to be loaded and run. I have been going over and over this on sci.crypt. IMO the facts as stated two paragraphs up are completely different from such a model.
Yes, the spec says that it can be turned off. At that point you can run anything that doesn't need any of the protected data or other TCPA services. But, why would a software vendor that wants the protection that TCPA provides allow his software to run without TCPA as well, abandoning those protections?
That's true; in fact if you ran it earlier under TCPA and sealed some data, you will have to run under TCPA to unseal it later. The question is whether the advantages of running under TCPA (potentially greater security) outweigh the disadvantages (greater potential for loss of data, less flexibility, etc.).
I doubt many would do so, the majority of TCPA-enabled software will be TCPA-only. Perhaps not at first, but eventually when there are enough TCPA machines out there. More likely, spiffy new content and features will be enabled if one has TCPA and is properly authenticated, disabled otherwise. But as we have seen time after time, today's spiffy new content is tomorrows virtual standard.
Right, the strongest case will probably be for DRM. You might be able to download all kinds of content if you are running an OS and application that the server (content provider) trusts. People will have a choice of using TCPA and getting this data legally, or avoiding TCPA and trying to find pirated copies as they do today.
This will require the majority of people to run with TCPA turned on if they want the content. TCPA doesn't need to be required by law, the market will require it. At some point, running without TCPA will be as difficult as avoiding MS software in an otherwise all-MS office.... theoretically possible, but difficult in practice.
I am inclined to agree; in fact I have made many postings (anonymously of course) in recent weeks arguing that these systems will be entirely voluntary. If the functionality is useful, people will use it. Software vendors who use TCPA will compete with those who don't. The market will decide. I am not as certain as you that TCPA will win, but if it does, it will mean that TCPA is a good technology that solves real problems for people.
"TCPA could be required" by the government or MS or <insert evil company here> is, I agree, a red herring. It is not outside the realm of possibility, in fact I'd bet that someone at MS has seriously thought through the implications. But to my mind the "requirement by defacto standard" scenerio I outline above is much more likely, in fact it is certain to happen if TCPA gets in more than say 50% of computers.
The points I made earlier were that TCPA is unlikely to be mandated, because it doesn't need to be; that TCPA should compete in the free market with other solutions; and that this approach actually expands the set of choices available to the participants. More choice is always good.
I worked for a short while on a very early version of TCPA with Geoff Strongin from AMD. We were both concerned that TCPA not be able to be used to restrict user's freedom, and at the time I thought that "you can always turn it off" was good enough. Now I'm not so sure. If someday all the stuff that you do with your computer touches data that can only be operated on by TCPA-enabled software, what are you going to do?
Well, you would use TCPA. But you have to look at how you got into that situation. The way it would have happened was by people voluntarily adopting TCPA before it became a de facto standard, simply because it was useful.
BTW, what's your credentials? You seem familiar with the TCPA spec, which is no mean feat considering that it seems to have been written to make it as difficult to understand as possible (or perhaps someone hired an out-of-work ISO standards writer). I think that Peter's guess is spot on. Of course having you participate as a nym is much preferable to not having you participate at all, so don't feel as though you have to out yourself or stop posting.
I have no credentials in this area other than a general knowledge of crypto; I am just someone who was willing to devote some hours of his free time to educating himself on this technology. I agree that the spec is written very poorly. But let me put you on the spot: as someone who has a good understanding of TCPA, what do you think of Ross Anderson's TCPA FAQ at http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html? For example, how about his claim in answer 2, "Pirate software can be detected and deleted remotely." I must have missed that page of the TCPA spec. And then he builds on this a couple of paragraphs later: "There will be remote censorship: the mechanisms designed to delete pirated music under remote control may be used to delete documents that a court (or a software company) has decided are offensive...." He further builds on this later to claim (answer 11) that with TCPA, programs can be made to ignore documents created by pirated versions of Word, etc. All this has so little to do with anything related to TCPA that it boggles my mind. And then in answer 12 we're back to the claim that TCPA can stop computers from booting. Saddam better not buy a TCPA computer or the U.S. will render it inoperative, using a "serial number revocation list", according to the FAQ. Are you aware of any such capability in TCPA? I didn't see any such data structure. Ross Anderson means well, and so does David Wagner. But in the long run it hurts the credibility of critics when they make exaggerated and unfounded claims. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
-- In an anarchist society, or in a world where government had given up on copyright and intellectual property, TCPA/Palladium would be a great thing, a really good substitute for law, much more effectual, much cheaper, and much less dangerous than law. In a world where we have anticircumvention laws and ever growing patent and copyright silliness, it seems a dangerously powerful addition to law. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 6FaJusAR8fMsVvaFm9l3vbuyiQwio/YrBFLpyT6c 2Db/Fk0MeNi3mjdoDTo2IGzHeelYts0/xqiEjUFmA --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
On Thu, 1 Aug 2002, AARG!Anonymous wrote:
Eric Murray writes:
TCPA (when it isn't turned off) WILL restrict the software that you can run. Software that has an invalid or missing signature won't be able to access "sensitive data"[1]. Meaning that unapproved software won't work.
[1] TCPAmain_20v1_1a.pdf, section 2.2
We need to look at the text of this in more detail. This is from version 1.1b of the spec:
: This section introduces the architectural aspects of a Trusted Platform : that enable the collection and reporting of integrity metrics. : : Among other things, a Trusted Platform enables an entity to determine : the state of the software environment in that platform and to SEAL data : to a particular software environment in that platform.
Claimed advantage to me here?
: : The entity deduces whether the state of the computing environment in : that platform is acceptable and performs some transaction with that : platform. If that transaction involves sensitive data that must be : stored on the platform, the entity can ensure that that data is held in : a confidential format unless the state of the computing environment in : that platform is acceptable to the entity.
Claimed advantage to me here?
: : To enable this, a Trusted Platform provides information to enable the : entity to deduce the software environment in a Trusted Platform. That : information is reliably measured and reported to the entity. At the same : time, a Trusted Platform provides a means to encrypt cryptographic keys : and to state the software environment that must be in place before the : keys can be decrypted.
What this means is that a remote system can query the local TPM and find out what software has been loaded, in order to decide whether to send it some data. It's not that unapproved software "won't work", it's that the remote guy can decide whether to trust it.
Claimed advantage to me here?
Also, as stated earlier, data can be sealed such that it can only be unsealed when the same environment is booted. This is the part above about encrypting cryptographic keys and making sure the right software environment is in place when they are decrypted.
Claimed advantage to me here?
Ok, technically it will run but can't access the data, but that it a very fine hair to split, and depending on the nature of the data that it can't access, it may not be able to run in truth.
If TCPA allows all software to run, it defeats its purpose. Therefore Wagner's statement is logically correct.
But no, the TCPA does allow all software to run. Just because a remote system can decide whether to send it some data doesn't mean that software can't run. And just because some data may be inaccessible because it was sealed when another OS was booted, also doesnt mean that software can't run.
Claimed advantage to me here?
I think we agree on the facts, here. All software can run, but the TCPA allows software to prove its hash to remote parties, and to encrypt data such that it can't be decrypted by other software. Would you agree that this is an accurate summary of the functionality, and not misleading?
Of course we do not agree. Under the DRM/TCPA regime I cannot legally do the following thing: Spoof your handshake and then run my cracker on the encrypted data you send me. So some software will not legally run under DRM/TCPA.
If so, I don't see how you can get from this to saying that some software won't run. You might as well say that encryption means that software can't run, because if I encrypt my files then some other programs may not be able to read them.
See above. Please be precise in your response.
Most people, as you may have seen, interpret this part about "software can't run" much more literally. They think it means that software needs a signature in order to be loaded and run. I have been going over and over this on sci.crypt. IMO the facts as stated two paragraphs up are completely different from such a model.
No. They are exactly "software needs to be signed to run". Otherwise why cannot I run cp on the movie that Time-Warner-AOL sends me?
Yes, the spec says that it can be turned off. At that point you can run anything that doesn't need any of the protected data or other TCPA services. But, why would a software vendor that wants the protection that TCPA provides allow his software to run without TCPA as well, abandoning those protections?
That's true; in fact if you ran it earlier under TCPA and sealed some data, you will have to run under TCPA to unseal it later. The question is whether the advantages of running under TCPA (potentially greater security) outweigh the disadvantages (greater potential for loss of data, less flexibility, etc.).
Ah, so much for your claim that all software that now runs will run under DRM/TCPA. You admit that software I may now run cannot be run under DRM/TCPA.
I doubt many would do so, the majority of TCPA-enabled software will be TCPA-only. Perhaps not at first, but eventually when there are enough TCPA machines out there. More likely, spiffy new content and features will be enabled if one has TCPA and is properly authenticated, disabled otherwise. But as we have seen time after time, today's spiffy new content is tomorrows virtual standard.
Right, the strongest case will probably be for DRM. You might be able to download all kinds of content if you are running an OS and application that the server (content provider) trusts. People will have a choice of using TCPA and getting this data legally, or avoiding TCPA and trying to find pirated copies as they do today.
No. Under DRM every "hole" must be plugged. Else what is the bleating about the "analogue hole"? So obviously no non-DRM computer may be allowed to be sold to the general public under DRM. Demonstration by formal admission of pro-DRM forces: Section 4.12 of the Final Report of the Broadcast Protection Discussion Group, found in the main body of the report at http://www.eff.org/IP/Video/HDTV/bpdg-report
This will require the majority of people to run with TCPA turned on if they want the content. TCPA doesn't need to be required by law, the market will require it. At some point, running without TCPA will be as difficult as avoiding MS software in an otherwise all-MS office.... theoretically possible, but difficult in practice.
I am inclined to agree; in fact I have made many postings (anonymously of course) in recent weeks arguing that these systems will be entirely voluntary. If the functionality is useful, people will use it. Software vendors who use TCPA will compete with those who don't. The market will decide. I am not as certain as you that TCPA will win, but if it does, it will mean that TCPA is a good technology that solves real problems for people.
Ah, now you have fallen off the high line of the long troll. This is simply beneath the level of your game. What you should do is claim that even if DRM is enforced all over the world, that this must be, from a higher and more encompassing viewpoint, a triumph of "the market" and the will of the people.
"TCPA could be required" by the government or MS or <insert evil company here> is, I agree, a red herring. It is not outside the realm of possibility, in fact I'd bet that someone at MS has seriously thought through the implications. But to my mind the "requirement by defacto standard" scenerio I outline above is much more likely, in fact it is certain to happen if TCPA gets in more than say 50% of computers.
The points I made earlier were that TCPA is unlikely to be mandated, because it doesn't need to be; that TCPA should compete in the free market with other solutions; and that this approach actually expands the set of choices available to the participants. More choice is always good.
Good grief! Please retuen to a less hopelessly ridiculous line. If TCPA is so good, and it "might win in the market", well, let 10,000 TCPA implementations bloom!
I worked for a short while on a very early version of TCPA with Geoff Strongin from AMD. We were both concerned that TCPA not be able to be used to restrict user's freedom, and at the time I thought that "you can always turn it off" was good enough. Now I'm not so sure. If someday all the stuff that you do with your computer touches data that can only be operated on by TCPA-enabled software, what are you going to do?
Well, you would use TCPA. But you have to look at how you got into that situation. The way it would have happened was by people voluntarily adopting TCPA before it became a de facto standard, simply because it was useful.
BTW, what's your credentials? You seem familiar with the TCPA spec, which is no mean feat considering that it seems to have been written to make it as difficult to understand as possible (or perhaps someone hired an out-of-work ISO standards writer). I think that Peter's guess is spot on. Of course having you participate as a nym is much preferable to not having you participate at all, so don't feel as though you have to out yourself or stop posting.
I have no credentials in this area other than a general knowledge of crypto; I am just someone who was willing to devote some hours of his free time to educating himself on this technology. I agree that the spec is written very poorly.
But let me put you on the spot: as someone who has a good understanding of TCPA, what do you think of Ross Anderson's TCPA FAQ at http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html? For example, how about his claim in answer 2, "Pirate software can be detected and deleted remotely." I must have missed that page of the TCPA spec. And then he builds on this a couple of paragraphs later: "There will be remote censorship: the mechanisms designed to delete pirated music under remote control may be used to delete documents that a court (or a software company) has decided are offensive...." He further builds on this later to claim (answer 11) that with TCPA, programs can be made to ignore documents created by pirated versions of Word, etc. All this has so little to do with anything related to TCPA that it boggles my mind.
And then in answer 12 we're back to the claim that TCPA can stop computers from booting. Saddam better not buy a TCPA computer or the U.S. will render it inoperative, using a "serial number revocation list", according to the FAQ. Are you aware of any such capability in TCPA? I didn't see any such data structure.
Ross Anderson means well, and so does David Wagner. But in the long run it hurts the credibility of critics when they make exaggerated and unfounded claims.
I have demonstrated, by example, and by official statements of your own side, that your claims are incorrect.. I recommend a broader. looser, and more amusing approach to the defense of DRM. I like the old Hegelian standard: "THE OVERMIND NEEDS DRM NOW SO AS TO BE BORN WITHOUT RIPPING ALL HUMAN HISTORY INTO NON-EXISTENCE BY BACK-REACTION." oo--JS.
participants (3)
-
AARG!Anonymous -
James A. Donald -
Jay Sulzberger