Eugen Leitl writes:
On Sat, 3 Aug 2002, AARG! Anonymous wrote:
But you won't now say that TCPA is OK, will you? You just learned some information which objectively should make you feel less bad about it, and yet you either don't feel that way, or you won't admit it. I am coming to doubt that people's feelings and beliefs about TCPA are based on facts at all. No matter how much I correct negative misconceptions about these systems, no one will admit to having any more positive feelings about it.
Whoa there. Hold the horses. You're completely inverting the burden of proof here. You're *trusting* a preliminary spec fielded by *whom* again? Were you on the design team? Are you on implementers' team? Have you reverse engineered the function from tracing the structures on the die? Will you continue doing this, sampling every batch being shipped?
I am judging the proposal on the basis of the spec. I think that is the correct way to do the analysis. Then, you can extend your analysis on the basis of ways you think the spec might change. But surely the spec ought to be a starting point for any judgement. Otherwise there is no factual basis for the analysis. Yet no one here has said that now that they understand the spec better, they don't think TCPA as specified would be as bad as they thought. Some people, like James Donald and Ryan Lackey, have said that they don't think TCPA would be all that bad if it weren't for government, copyright laws, etc. But no one has suggested that my many postings have changed their opinion about TCPA in and of itself.
Consider the source. It is bogged down with enough bad mana to last for centuries.
The Alliance consists of Compaq, Intel, IBM, HP, and Microsoft. (Since then HP has bought Compaq.) Even if you hate Microsoft, you probably don't hate all of these companies, do you?
Consider the motivations. They're certainly not there to enhance end user's privacy and anonymitity. In fact, one of the design specs must have been minimizing the latter as long as it not hurts the prime design incentives. These are all facts you won't find in the specs.
I think the spec directly contradicts this claim! If they cared so little about user privacy, why would they use an elaborate system with a Privacy CA to make sure no user-identifiable information leaks onto the net? Surely the simpler approach would be what James Donald suggested, to send out the TPM's public key and let people use that. But it is a per-user identifier and so they went to great lengths to conceal it. Furthermore, if their motivations were so bad, wouldn't it have been better for them for TCPA to work the way most people assume, to only load software which has been signed by some authority? Instead they are careful to let any software load, and to report its status to third parties, so the third parties can make their own judgements about what to trust. Why do you think they did it like this, if they were so determined to minimize the control of the end user?
It boggles my mind I have to explain this, especially to a member of this particular community. Are you really sure you're not a TCPA troll?
Who cares what I am? It's facts that count! I could be Satan Incarnate and it wouldn't matter. I am giving you facts about TCPA based on my personal investment of time to study the system. Tell me this: if you care about this standard, why not get it and learn it yourself? Not one person here has done this! Everyone prefers to believe falsehoods than to learn the truth for themself. Do you think that is a good strategy for survival in a potentially hostile and dangerous world?
If they manage to slip that particular toad into high volume production, hackers will of course use it, inasmuch possible thwarting the original intent. But you seem to ask for blanket endorsement based merely on spec, which is a rather tall order.
All I am really asking for is someone to acknowledge that I have provided information to them which makes them see TCPA as less dangerous and damaging than they had thought based on the false information which has been circulating. I don't see how anyone can deny this. The caricature of TCPA that most people believe is very bad. The truth is not so bad. Logically, you *have* to believe that TCPA is not as bad as you thought, when you are provided with the truth. Let me ask you, Eugen: isn't a TCPA which is open, which will run all software, which does not prevent any software from running, better than a TCPA which will only run signed software? I know you are a person who is willing to think for himself and defy the conventional wisdom. Please respond to this message and explain to me how this logic strikes you.
On Sun, 4 Aug 2002, AARG! Anonymous wrote:
Eugen Leitl writes:
On Sat, 3 Aug 2002, AARG! Anonymous wrote:
But you won't now say that TCPA is OK, will you? You just learned some information which objectively should make you feel less bad about it, and yet you either don't feel that way, or you won't admit it. I am coming to doubt that people's feelings and beliefs about TCPA are based on facts at all. No matter how much I correct negative misconceptions about these systems, no one will admit to having any more positive feelings about it.
Whoa there. Hold the horses. You're completely inverting the burden of proof here. You're *trusting* a preliminary spec fielded by *whom* again? Were you on the design team? Are you on implementers' team? Have you reverse engineered the function from tracing the structures on the die? Will you continue doing this, sampling every batch being shipped?
Whoa there is right! Yes, you are definitly educating me. Thank you. I am now totally confused on a lot of issues. So far, you have moved me from thinking TCPA seems like it might be useful to thinking that it's pretty monstrous. If you want to be a good teacher, you will have some patience. If you are a troll, you will get frustrated and leave soon.
I am judging the proposal on the basis of the spec. I think that is the correct way to do the analysis. Then, you can extend your analysis on the basis of ways you think the spec might change. But surely the spec ought to be a starting point for any judgement. Otherwise there is no factual basis for the analysis.
Agreed.
Yet no one here has said that now that they understand the spec better, they don't think TCPA as specified would be as bad as they thought. Some people, like James Donald and Ryan Lackey, have said that they don't think TCPA would be all that bad if it weren't for government, copyright laws, etc. But no one has suggested that my many postings have changed their opinion about TCPA in and of itself.
Maybe that's because I'm not convinced yet. I've got a thick skull :-)
The Alliance consists of Compaq, Intel, IBM, HP, and Microsoft. (Since then HP has bought Compaq.) Even if you hate Microsoft, you probably don't hate all of these companies, do you?
Hate is too strong a word. They aren't evil because they want to be, but because they have to be. They won't survive if they don't optimize society to their advantage.
I think the spec directly contradicts this claim! If they cared so little about user privacy, why would they use an elaborate system with a Privacy CA to make sure no user-identifiable information leaks onto the net? Surely the simpler approach would be what James Donald suggested, to send out the TPM's public key and let people use that. But it is a per-user identifier and so they went to great lengths to conceal it.
It creates a single point of attack. It reminds me of key escrow. Once you get to the chewy center, you can control everything. More questions below.
Furthermore, if their motivations were so bad, wouldn't it have been better for them for TCPA to work the way most people assume, to only load software which has been signed by some authority? Instead they are careful to let any software load, and to report its status to third parties, so the third parties can make their own judgements about what to trust. Why do you think they did it like this, if they were so determined to minimize the control of the end user?
Because it's hard to think about everything. Maybe they didn't finish thinking all the ramifications through. I would hope we'll be able to ask enough questions that you'll have a hard time quoting the spec.
Who cares what I am? It's facts that count! I could be Satan Incarnate and it wouldn't matter. I am giving you facts about TCPA based on my personal investment of time to study the system. Tell me this: if you care about this standard, why not get it and learn it yourself? Not one person here has done this! Everyone prefers to believe falsehoods than to learn the truth for themself. Do you think that is a good strategy for survival in a potentially hostile and dangerous world?
Not in a democracy. All laws are based on belief. They have nothing to do with facts. Facts get in the way and are far too confusing for a majority of humans. While understanding the facts is useful to anyone who wants real power, you can still accomplish a lot in the short run with a good lie. But I would like to understand TCPA enough that I can tell which newspaper article is the lie and which isn't.
All I am really asking for is someone to acknowledge that I have provided information to them which makes them see TCPA as less dangerous and damaging than they had thought based on the false information which has been circulating. I don't see how anyone can deny this. The caricature of TCPA that most people believe is very bad. The truth is not so bad. Logically, you *have* to believe that TCPA is not as bad as you thought, when you are provided with the truth.
Well I deny it. So far, I am still confused and amazed at how powerful a device you have described.
From a different message- :Date: Sat, 3 Aug 2002 23:50:24 -0700 :From: AARG! Anonymous <remailer@aarg.net> :To: cypherpunks@lne.com :Subject: Re: Other uses of TCPA : :Mike Rosing wrote: :> Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. : :PRIVEK, the TPM's private key, is generated on-chip. It never leaves :the chip. No one ever learns its value. Given this fact, who would :you say owns and controls it?
OK, so why can't any joe hacker create their own PRIVEK? _nobody_ knows it's value? Then how can anyone know if a chip is "real" or "imitation". What happens when the motherboard dies again? PRIVEK was copied out of the chip to some "fob" right? I thought you said the manufacturer put the keys in at the factory. I'm confused dude, straighten me out. Patience, persistence, truth, Dr. mike
I haven't read the TCPA detailed spec yet (next on TCPA/Palladium list of reading material), but this bit I can infer I think:
:Mike Rosing wrote: :> Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. : :PRIVEK, the TPM's private key, is generated on-chip. It never leaves :the chip. No one ever learns its value. Given this fact, who would :you say owns and controls it?
OK, so why can't any joe hacker create their own PRIVEK? _nobody_ knows it's value? Then how can anyone know if a chip is "real" or "imitation". What happens when the motherboard dies again? PRIVEK was copied out of the chip to some "fob" right? I thought you said the manufacturer put the keys in at the factory.
The corresponding public key is certified by the secure hardware manufacturer, I think. Then they have this privacy CA which accepts requests signed by the platform's signature key, and gives in return a certified pseudonym of the users choice. They claim this gives privacy, which it only does if you trusted the "privacy CA" -- the privacy CA can link all of your anonymous and pseudonymous credentials. (Anonymous may want to straighten out the different keys names -- I think there are some encryption, some signature, some sealing keys derived from other secret keys and the checksum of the application and OS / firmware etc.) Brands digital credentials could be used to fix this sub-problem I think. They put in the privacy CA thing as a defense against the PR problems Intel had with the pentium serial number. The FAQs at www.trustedpc.org talk about this arguing how this is better than pentium serial number at avoiding linkability. The documentation problem I find is there isn't much documentation available which is technical except for the 330 page spec which drops right down to implementation details in RFC standards style. Adam -- http://www.cypherspace.org/adam/
On Mon, 5 Aug 2002, Adam Back wrote:
I haven't read the TCPA detailed spec yet (next on TCPA/Palladium list of reading material), but this bit I can infer I think:
I don't have time to read it, but I do appreciate the effort you've put into this so far!
The corresponding public key is certified by the secure hardware manufacturer, I think.
Are all the keys certified? Are any copied outright?
Then they have this privacy CA which accepts requests signed by the platform's signature key, and gives in return a certified pseudonym of the users choice. They claim this gives privacy, which it only does if you trusted the "privacy CA" -- the privacy CA can link all of your anonymous and pseudonymous credentials. (Anonymous may want to straighten out the different keys names -- I think there are some encryption, some signature, some sealing keys derived from other secret keys and the checksum of the application and OS / firmware etc.)
Brands digital credentials could be used to fix this sub-problem I think.
One key for encryption, one key for signature, one key for checksums, and one key to rule them all!! :-)
They put in the privacy CA thing as a defense against the PR problems Intel had with the pentium serial number. The FAQs at www.trustedpc.org talk about this arguing how this is better than pentium serial number at avoiding linkability.
The documentation problem I find is there isn't much documentation available which is technical except for the 330 page spec which drops right down to implementation details in RFC standards style.
I think that explaining it in a mathematical or technical abstract way would give competitors an advantage. Seems like the consortium that's building it can keep these details proprietary and just sell the thing on the market to whoever wants to buy it - no need for all this FAQ stuff anyway. They only need publicity to get past the congress or MP's. I guess I don't see why the spec is public if the purpose is to create a platform that's just a toy. But I'm confused, so keep at it and maybe I'll figure something out! Patience, persistence, truth, Dr. mike
On Mon, Aug 05, 2002 at 07:42:45AM -0700, Mike Rosing wrote:
On Mon, 5 Aug 2002, Adam Back wrote:
The corresponding public key is certified by the secure hardware manufacturer, I think.
Are all the keys certified? Are any copied outright?
Note there is one key that is endorsed, so per machine there is one key, singular. On the other interpretation of your question: do we trust that the manufacturer didn't take a copy of the key while certifying it? Good quesion. The scenario is analogous to the pre-generated private key on a smart card. Do you trust what the hardware vendor did with it? Did they generate the private key it off chip and keep a copy? Did they generate the private key on chip but export it at the time of certifying the public key? Except in this case the smart card is attached to your motherboard, mediates control of the platform and is called the "TPM" Trusted Platform Module. While there are approaches to having third party audits of the process, publishing the source code, etc; it's still typically not a very transparent affair as it's in tamper resistant hardware, plus vulnerable to plausibly deniable snafus, and undetectable backdooring even if it is generated on TPM.
But I'm confused, so keep at it and maybe I'll figure something out!
Effectively I think the best succinct description of the platforms motivation and function is that: "TCPA/Palladium is an extensible, general purpose programmable dongle soldered to your mother board with centralised points belonging to Microsoft/IBM/Intel/". It seems to me there is both strong possibility for it becoming a focus for future government attempts at policy malware and legislated technology implementation, and a focus RIAA/MPAA/WIPO polices imposing futher expansionist and monopoly propping legislation and legislated technology implementation to enforce the worst excesses of DMCA. The technology components are very interesting. The implications of what can be done with sealing, secure boot-strapping and remote attestation are a departure from what people were thinking was possible with general purpose computing. As anonymous points out it makes possible all kinds of applications and changes the nature of what can be cryptographically assured. With current non-TCPA platforms the limit of what can be cryptographically assured is for example what can be encrypted with password, or other cryptographic mechanism. Cryptographic assurance is also known as "data separation" -- the concept that the crytography is able to completely cover the applications policy restrictions without leaving "trusted" software components necessary to enforce policies too complex to implement with encryption / data separation. With TCPA you can build general purpose policy code which does not exhibit cryptographic assurance, and yet due to the TCPA platform assures similar levels of security assurance. That's a huge change in world view in the domain of security applications. In slightly more detail, you can either build applications rooted in the remote attestation, sealing and secure boot-strapping functions I described in an earlier post. Or you can add your own custom policy and even applications inside a hardware assured code compartment which the user can not access or tamper with. One aspect of the implications is the implementation and security possibilities it lends to DRM applications. Personally I don't find this aspect a good thing because I think current copyright law has reached a state of being a net negative for society and freedom, and that it's time to rescind them and start-over. I think we should try analyse as William Arbaugh suggested in [7] what is desirable, what is safe to implement, and ways to change the platform to remove the negative aspects.
From my current understanding, the worst problem is the centralised control of this platform. If it were completely open, and possible to fix it's potential dangers, it would bring about a new framework of secured computing and could be a net positive. In it's current form with centralised control and other problems it could be a big net negative.
Adam [7] "The TCPA; What's wrong; What's right and what to do about", William Arbaugh, 20 Jul 2002 http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html
-- On 4 Aug 2002 at 14:30, AARG! Anonymous wrote:
All I am really asking for is someone to acknowledge that I have provided information to them which makes them see TCPA as less dangerous and damaging than they had thought based on the false information which has been circulating. I don't see how anyone can deny this. The caricature of TCPA that most people believe is very bad. The truth is not so bad. Logically, you *have* to believe that TCPA is not as bad as you thought, when you are provided with the truth.
Your account of TCPA is that smooth and reassuring account given in the TCPA FAQ http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf When I read the more technical account http://www.trustedcomputing.org/docs/main%20v1_1b.pdf , and http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100 .pdf , I do not see anything so reassuring. I see scary phrases like "root of trust". These more technical specs give lots of irrelevant detail, and very little detail that is actually informative. We get a mixture of smooth sales talk, and blind-em-with-bafflegab technical vagueness. Some of the details in the technical spec seem inconsistent with the smooth and reassuring account. For example: : : "The replacement of code in the platform must be : : performed by a platform manufacturer approved method : : or agent. This allows the manufacturer to establish : : an upgrade method ...." This seems to the say that the TPM has non read write storage containing non volatile code that is privileged, and can be changed, but not however by the user. This would imply that the TPM could be used to enforce any policy whatever, and not necessarily a policy so benevolent as that promised in the sales talk versions of the white papers. You have told us that the TPM is turned off by default, but "off" is merely an off flag, not a full physical off. According to the technical spec : : "The core root of trust measurement (CRTM) MUST be an : : immutable feature of the platform's initialization : : code that executes on platform reset." This is not what most people mean by "off". It provides the physical capability to prohibit unauthorized software from running, even if the nice salesman tells us that capability will never be used. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG AxOIYHF+xyLE0spg6FCaankLLpAULiyK8SWbS3TD 2C/pKtcxdtkar26efao8o6HyGD6ilcST8O9G1KpB0
-- On 4 Aug 2002 at 14:30, AARG! Anonymous wrote:
All I am really asking for is someone to acknowledge that I have provided information to them which makes them see TCPA as less dangerous and damaging than they had thought based on the false information which has been circulating. I don't see how anyone can deny this. The caricature of TCPA that most people believe is very bad. The truth is not so bad. Logically, you *have* to believe that TCPA is not as bad as you thought, when you are provided with the truth.
The spec is OK. The fact that it appeared at the same time as extraordinarily overreaching IP law is damning. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG rwdGfQyOtFA6WkAqxu91fMbC8sahZDn51gg6yvCS 21B3dZ6Ah+eyjxj5hj98h+8bNcUWAprErYOtDB1kH
participants (4)
-
AARG! Anonymous -
Adam Back -
James A. Donald -
Mike Rosing