On Tue, 2003-02-04 at 12:36, Trei, Peter wrote: > Dave: > > Adam is correct - I was responding to him. > > 'secure remote attestation that the boot > sequence was followed' > > seems to imply that a net connection back > to Hollywood would be required to boot.
That's simply not true. TCPA and Palladium are dangerous [1], but they're not that stupid [2]. Here's a brief outline of the TCPA trusted boot and attestation process. Some details have been left out because I forgot them. If you see a cryptographic or protocol flaw with this system, don't assume it's a flaw in TCPA -- read the spec first: PCR, I think, stands for Platform Configuration Register. They are initially in some known state, and the only way to update them is: new value = SHA1 (old value || input). 1. First boot stage is measured, result goes to PCR0. BIOS runs first boot stage. 2. First boot stage measures second boot stage, result goes to PCR1. First boot stage runs second boot stage. 3. Repeat until OS is loaded. So, no net connection is required for trusted boot. A net connection *is* required for remote attestation (but see below) -- because a net connection is required for remote *anything*! Remote attestation works like this: 1. Remote computer requests platform state, sends nonce (to show that the authentication is online) 2. TPM signs (nonce || PCRs || various certs) with some identity key. TPM's public key is signed by a CA which vouches for the state of the platform when the identity key was created, and the various certs certify that various pieces of the base platform (i.e. the hardware and low-level software bits) will behave as expected. 3. Local machine sends this to remote computer (if desired). The remote computer can then "seal" information to this platform. The idea of sealing is that data is encrypted with a symmetric key, and this symmetric key, along with a list of PCR values is encrypted with a public key. The private key to that public key is stored within (or, more likely, encrypted by a key, which is encrypted by a key, ...) the tamper-resistant TPM, The TPM will refuse to decrypt the symmetric key unless the PCRs stored with it match the current PCRs. So, if you attest that your platform is in a certain state, you're sent data sealed to that platform. If you then change your platform configuration, you'll not be able to read the sealed data. So, while you will need to be online to download these new music, movies, or software, you won't need to be online to play them later. [1] It's beyond the scope of this message to discuss the potential evils of TCPA, Palladium, etc, to fair use, individual rights, societal openness, Free Software, competition in the software market, etc. But the risk is great. [2] I'm always tempted to underestimate the intelligence of those I disagree with, and I suspect others are as well. Often, when I discuss the political problems with TCPA, I'm told that people will always simply crack the system. This comes in part from experience with pure software systems, which of course can't actually work, and in part from wishful thinking. Ultimately, it seems to be a species of the same fallacy discussed in Lessig's book, _Code and Other Laws of Cyberspace_. It's true that, for instance, instrumented RAM will probably make it easy to get content out of the first generation of TCPA systems. But the next generation will stick some measurement of the RAM into a PCR. That will be cracked too, but the cost of a break will keep going up (just as the cost of modchips has increased between psx and ps2 or xbox). And the legal risks to modchip makers have also increased -- recently, several makers of modchips have been shut down. -- -Dave Turner Stalk Me: 617 441 0668 "On matters of style, swim with the current, on matters of principle, stand like a rock." -Thomas Jefferson --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]