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.
-- 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
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.
participants (3)
-
Eugen Leitl -
James A. Donald -
Nomen Nescio