On 2002-08-01, AARG!Anonymous uttered to ptrei@rsasecurity.com,...:
It does this by taking hashes of the software before transferring control to it, and storing those hashes in its internal secure registers.
So, is there some sort of guarantee that the transfer of control won't be stopped by a check against cryptographic signature within the executable itself, in the future? That sort of thing would be trivial to enforce via licencing terms, after all, and would allow for the introduction of a strictly limited set of operating systems to which control would be transferred. I'm having a lot of trouble seeing the benefit in TCPA without such extra measures, given that open source software would likely evolve which circumvented any protection offered by the more open ended architecture you now describe. Such a development would simply mean that Peter's concern would be transferred a level up, without losing its relevance. I'd also contend that this extra level of diversion is precisely what TCPA, with its purported policy of "no trusted keys" aims at.
Then, when the data is decrypted and "unsealed", the hash is compared to that which is in the TPM registers now. This can make it so that data which is encrypted when software system X boots can only be decrypted when that same software boots.
Again, such values would be RE'd and reported by any sane open source OS to the circuitry, giving access to whatever data there is. If this is prevented, one can bootstrap an absolutely secure platform where whatever the content provider says is the Law, including a one where every piece of runnable OS software actually enforces the kind of control over permissible signatures Peter is so worried about. Where's the guarantee that this won't happen, one day?
In answer to your question, then, for most purposes, there is no signing key that your TPM chip trusts, so the issue is moot.
At the hardware level, yes. At the software one, it probably won't be, even in the presence of the above considerations. After you install your next Windows version, you will be tightly locked in with whatever M$ throws at you in their DLL's, and as I pointed out, there's absolutely no guarantee Linux et al. might well be shut out by extra features, in the future. In the end what we get is an architecture, which may not embody Peter's concerns right now, but which is built from the ground up to bring them into being, later. More generally, as long as we have computers which allow data to be addressed as code and vice versa, the ability to control use of data will necessarily entail ability to control use of code. So, either we will get systems where circumventing copyright controls is trivial or ones where you cannot compile your own code. All the rest is just meaningless syntax. In that light I bet you can guess why people are worried about TCPA and its ilk. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com