A talk on Intellectual Property and National Defense

[David Turner]

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 majordomo at wasabisystems.com