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.
On Sat, 3 Aug 2002, AARG! Anonymous wrote:
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.
And in another message: I said: => In other words, the manufacturer has access to all your data because => they have the master storage key. => => Why would everyone want to give one manufacturer that much power? AARGH! said:
It's not quite that bad. I mentioned the blinding. What happens is that before the master storage key is encrypted, it is XOR'd with a random value, which is also output by the TPM along with the encrypted recovery blob. You save them both, but only the encrypted blob gets sent to the manufacturer. So when the manufacturer decrypts the data, he doesn't learn your secrets.
The system is cumbersome, but not an obvious security leak.
Who owns PRIVEK? Who controls PRIVEK? That's who own's TCPA. And then there was this comment in yet another message:
In addition, we assume that programs are able to run "unmolested"; that is, that other software and even the user cannot peek into the program's memory and manipulate it or learn its secrets. Palladium has a feature called "trusted space" which is supposed to be some special memory that is immune from being compromised. We also assume that all data sent between computers is encrypted using something like SSL, with the secret keys being held securely by the client software (hence unavailable to anyone else, including the users).
Just how "immune" is this program space? Does the operator/owner of the machine control it, or does the owner of PRIVEK control it? So the owner of PRIVEK can send a trojan into my machine and take it over anytime they want. Cool, kind of like the movie "Collosis" where a super computer takes over the world. The more I learn about TCPA, the more I don't like it. Patience, persistence, truth, Dr. mike
participants (2)
-
AARG! Anonymous -
Mike Rosing