Re: Other uses of TCPA
-- On Sat, 3 Aug 2002, Nomen Nescio wrote: As an exercise, try thinking of ways you could use TCPA to promote good guy applications. What could you do in a P2P network if you could trust that all participants were running approved software? And if you I can only see one application for voluntary TCPA, and that is the application it was designed to perform: Make it possible run software or content which is encrypted so that it will only run on one computer for one time period. All the other proposed uses, both good and evil, seem improbably cumbersome, or easier to do in some other fashion. There are quite a few extremely evil uses it would be good for, but they would only be feasible if enforced by legislation -- otherwise people would turn the chip off, or tear it out. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Hzs0OpVc+bwQiFEZnMNE2zMLAXiYjMNrOWpH9WIb 2vvlvOjPeQH/ua0E9NnfeVaLvRGnxGuIvKZGcMZdN
Re: Other uses of TCPA
James Donald writes: I can only see one application for voluntary TCPA, and that is the application it was designed to perform: Make it possible run software or content which is encrypted so that it will only run on one computer for one time period. You've said this a few times, and while it is a plausible goal of the designers, I don't actually see this specific capability in the TCPA spec, nor is it mentioned in the Palladium white paper. For TCPA, you'd have to have the software as a blob which is encrypted to some key that is locked in the TPM. But the problem is that the endorsement key is never leaked except to the Privacy CA, so the content provider can't encrypt to that key. Then there are Identity keys which are short-term generated keys that get signed by the Privacy CA, but these are primarily used to prove that you are running a TCPA system. I'm not even sure if they are decryption keys. In any case they are supposed to be relatively transient. You get a new one each time you go online so that your web activities are not linkable. So I don't think Identity keys would be very suitable for locking software too, either. I admit that it would be unlikely for Microsoft to go to all the trouble of creating Palladium, without using it to solve its own severe software piracy problems. So I certainly wouldn't be surprised to see some way of achieving what you are talking about. But it is not mentioned in the white paper, and TCPA doesn't seem to support it very well. If it was, as you say, the application it was designed to perform, this fact is far from apparent in the design documents.
Re: Other uses of TCPA
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? Consider the source. It is bogged down with enough bad mana to last for centuries. 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. 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? 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.
Re: Other uses of TCPA
On Saturday, August 3, 2002, at 09:10 AM, James A. Donald wrote: -- On Sat, 3 Aug 2002, Nomen Nescio wrote: As an exercise, try thinking of ways you could use TCPA to promote good guy applications. What could you do in a P2P network if you could trust that all participants were running approved software? And if you I can only see one application for voluntary TCPA, and that is the application it was designed to perform: Make it possible run software or content which is encrypted so that it will only run on one computer for one time period. All the other proposed uses, both good and evil, seem improbably cumbersome, or easier to do in some other fashion. There are quite a few extremely evil uses it would be good for, but they would only be feasible if enforced by legislation -- otherwise people would turn the chip off, or tear it out. The VSPA (Video Surveillance Protection Architecture) is a completely voluntary arrangement whereby video cameras must be installed by 2003 in all new and remodeled homes, apartments, places of business, libraries, and other such places. These cameras and microphones can be used voluntarily by parents and other concerned persons to monitor children, pets, and domestic workers. Under the VSPA, the video feed will be sent to a centralized location where homeowners and parents may then access the feed, strictly voluntarily. While installation of VSPA will be mandated by law in all new and remodeled homes, the use of VSPA features is strictly on an opt-in basis, except as authorized by law (*). * Note that VSPA features may be accessed by court order, by presidential emergency order, by authorization of an employee of the Justice, Defense, Interior, or HomeSec departments who is above the grade level GS-7. During periods of Domestic Emergency, the President or the HomeSec Commissar may enable the VSPA on a regional or state or national basis. Additionally, Child Protective Services, the Environmental Protection Agency, and other selected agencies may be granted access, all subject to strict oversight by government officials. Remember, VSPA is a completely voluntary system. The installation of the VSPA cameras and microphones will assist us all. The legitimate needs of law enforcement will be subject to careful oversight. Best of all, a substantial tax credit will be granted to those who voluntarily install the VSPA system prior to the mandatory phase-in time. To pay for the voluntary VSPA system, taxes will be raised for those who fail to volunteer. --Tim May As my father told me long ago, the objective is not to convince someone with your arguments but to provide the arguments with which he later convinces himself. -- David Friedman
Re: Other uses of TCPA
James Donald writes: James Donald writes: I can only see one application for voluntary TCPA, and that is the application it was designed to perform: Make it possible run software or content which is encrypted so that it will only run on one computer for one time period. On 3 Aug 2002 at 20:10, Nomen Nescio wrote: For TCPA, you'd have to have the software as a blob which is encrypted to some key that is locked in the TPM. But the problem is that the endorsement key is never leaked except to the Privacy CA (Lots of similarly untintellible stuff deleted) You have lost me, I have no idea why you think what you are talking about might be relevant to my assertion. I'm sorry, I'm just using the language and data structures from TCPA to try to understand how your assertion could relate to it. If you are making a claim about TCPA, perhaps you could express it in terms of those specific features which are supported by TCPA. The TPM has its own secret key, it makes the corresponding public key widely available to everyone, and its own internal good known time. No, the TPM public key is not widely available to everyone. In fact, believe it or not, it is a relatively closely held secret. This is because the public key is in effect a unique identifier like the Intel processor ID number, and we all know what a firestorm that caused. Intel is paranoid about being burned again, so they have created a very elaborate system in which the TPM's public key is exposed only as narrowly as possible. The TPM public key is called the Endorsement key - this is the key which is signed by the manufacturer and which proves that the TPM is a valid implementation of TCPA. Here is what section 9.2 of the TCPA spec says about it: : A TPM only has one asymmetric endorsement key pair. Due to the nature of : this key pair, both the public and private parts of the key have privacy : and security concerns. : : Exporting the PRIVEK from the TPM must not occur. This is for security : reasons. The PRIVEK is a decryption key and never performs any signature : operations. : : Exporting the public PUBEK from the TPM under controlled circumstances : is allowable. Access to the PUBEK must be restricted to entities that : have a need to know. This is for privacy reasons. The PUBEK is the public part of the TPM key and is not supposed to be widely available. It is only for those who have a need to know, which definitely does not include everyone who would like to send some software to the system. In fact, it is only sent to Privacy CAs, which use it to encrypt a cert on a transient key that will be widely exposed. But I'm sorry, I'm going unintelligible again, aren't I? Also, nothing in the TCPA standard refers to securely knowing the time. Section 10.7 says There is no requirement for a clock function in the TPM, so the date/time info comes from the normal, insecure hardware clock. So when your customer's payment goes through, you then send him a copy of your stuff encrypted to his TPM, a copy which only his TPM can make use of. Your code, which the TPM decrypts and executes, looks at the known good time, and if the user is out of time, refuses to play. Well, without using any jargon, I will only say that TCPA doesn't work like this, and if you don't believe me, you will have to read the spec and verify it for yourself.
Re: Other uses of TCPA
On Sat, 3 Aug 2002, James A. Donald wrote: The TPM has its own secret key, it makes the corresponding public key widely available to everyone, and its own internal good known time. So when your customer's payment goes through, you then Trusted time is a useful concept. I presume the time is set by the manufacturer. Given current clock accuracy and limited lifetime of backup power I presume it is possible to adjust the time via trusted timeservers. Do they mention anything like this in the specs? send him a copy of your stuff encrypted to his TPM, a copy which only his TPM can make use of. Your code, which the TPM decrypts and executes, looks at the known good time, and if the user is out of time, refuses to play. Is there any reason to believe the implementers are telling us everything, and will implement the specs as advertised? I mean, consider the source. Sometimes it makes sense to look a gift horse in the mouth, especially if it's made from wood.
Re: Other uses of TCPA
-- James Donald writes: I can only see one application for voluntary TCPA, and that is the application it was designed to perform: Make it possible run software or content which is encrypted so that it will only run on one computer for one time period. On 3 Aug 2002 at 20:10, Nomen Nescio wrote: You've said this a few times, and while it is a plausible goal of the designers, I don't actually see this specific capability in the TCPA spec, nor is it mentioned in the Palladium white paper. Think about it. For TCPA, you'd have to have the software as a blob which is encrypted to some key that is locked in the TPM. But the problem is that the endorsement key is never leaked except to the Privacy CA (Lots of similarly untintellible stuff deleted) You have lost me, I have no idea why you think what you are talking about might be relevant to my assertion. The TPM has its own secret key, it makes the corresponding public key widely available to everyone, and its own internal good known time. So when your customer's payment goes through, you then send him a copy of your stuff encrypted to his TPM, a copy which only his TPM can make use of. Your code, which the TPM decrypts and executes, looks at the known good time, and if the user is out of time, refuses to play. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 8QGEo4ptd7TD5d7duyz9XkOw+th0YEG9sllM8ix 2P2uZVncMpARxQd6P5V9cXLh97ZLpgi0tHH7LyVfB
