RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

Stefan,

        I replied to much of this earlier, so I'll skip those parts.

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison         cme@xxxxxxx      http://theworld.com/~cme |
|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
+---Officer, arrest that man. He's whistling a copyrighted song.---+ 

> -----Original Message-----
> From: owner-cryptography@xxxxxxxxxxxx 
> [mailto:owner-cryptography@xxxxxxxxxxxx] On Behalf Of Stefan Lucks
> Sent: Tuesday, December 16, 2003 1:02 AM
> To: Carl Ellison
> Cc: cryptography@xxxxxxxxxxxx
> Subject: RE: Difference between TCPA-Hardware and a smart 
> card (was: example: secure computing kernel needed)
> 
> On Mon, 15 Dec 2003, Carl Ellison wrote:


> The point is that Your system is not supposed to prevent You 
> from doing
> anything I want you not to do! TCPA is supposed to lock You 
> out of some
> parts of Your system.

This has nothing to do with the TCPA / TPM hardware. This is a political
argument about the unclean origins of TCPA (as an attempt to woo Hollywood).

I, meanwhile, never did buy the remote attestation argument for high price
content.  It doesn't work.  So, I looked at this as an engineer.  "OK, I've
got this hardware. If remote attestation is worthless, then I can and should
block that (e.g., with a personal firewall).  Now, if I do that, do I have
anything of value left?"  My answer was that I did - as long as I could
attest about the state of the software to myself, the machine owner.

This required putting the origins of the project out of my head while I
thought about the engineering.  That took effort, but paid off (to me).

> 
> 
> [...]
> > If it were my machine, I would never do remote attestation. 
>  With that
> > one choice, I get to reap the personal advantages of the TPM while
> > disabling its behaviors that you find objectionable 
> (serving the outside
> > master).
> 
> I am not sure, whether I fully understand you. If you mean that TCPA
> comes with the option to run a secure kernel where you (as 
> the owner and
> physical holder of the machine running) have full control 
> over what the
> system is doing and isn't doing -- ok, that is a nice thing. 
> On the other
> hand, we would not need a monster such as TCPA for this.

What we need is some agent of mine - a chip - that:
1) has access to the machine guts, so it can verify S/W state
2) has a cryptographic channel to me, so it can report that result to me
and
3) has its own S/W in a place where no attacker could get to it, even if
that attacker had complete control over the OS.

The TCPA/TPM can be used that way.  Meanwhile, the TPM has no channel to the
outside world, so it is not capable of doing remote attestation by itself.
You need to volunteer to allow such communications to go through. If you
don't like them, then block them.  Problem solved.  This reminds me of the
abortion debate bumper sticker.  "If you're against abortion, don't have
one."

 - Carl

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@xxxxxxxxxxxx