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

[Carl Ellison]

Stefan,

	I have to disagree on most of these points.

	See below.

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison         cme at acm.org      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 at metzdowd.com 
> [mailto:owner-cryptography at metzdowd.com] On Behalf Of Stefan Lucks
> Sent: Monday, December 15, 2003 9:34 AM
> To: Jerrold Leichter
> Cc: Ian Grigg; Paul A.S. Ward; cryptography at metzdowd.com
> Subject: Difference between TCPA-Hardware and a smart card 
> (was: example: secure computing kernel needed)
> 
> On Sun, 14 Dec 2003, Jerrold Leichter wrote:
> 
> > Which brings up the interesting question:  Just why are the 
> reactions to
> > TCPA so strong?  Is it because MS - who no one wants to trust - is
> > involved?  Is it just the pervasiveness:  Not everyone has 
> a smart card,
> > but if TCPA wins out, everyone will have this lump inside of their
> > machine.
> 
> There are two differences between TCPA-hardware and a smart card.
> 
> The first difference is obvious. You can plug in and later 
> remove a smart
> card at your will, at the point of your choice. Thus, for 
> home banking with
> bank X, you may use a smart card, for home banking with bank Y you
> disconnect the smart card for X and use another one, and before online
> gambling you make sure that none of your banking smart cards 
> is connected
> to your PC. With TCPA, you have much less control over the 
> kind of stuff
> you are using.
> 
> This is quite an advantage of smart cards.

It is an advantage for a TCPA-equipped platform, IMHO.  Smart cards cost
money. Therefore, I am likely to have at most 1.  TCPA acts like my hardware
crypto module and in that one hardware module, I am able to create and
maintain as many private keys as I want.  (The keys are wrapped by the TPM
but stored on the disk - even backed up - so there's no storage limit.)

Granted, you have to make sure that the S/W that switches among (selects)
private keys for particular uses does so in a way you can trust.  The
smartcard has the advantage of being a physical object. However, if you
can't trust your system S/W, then how do you know that the system S/W was
using a private key on the smart card you so happily plugged in rather than
one of its own (the same one all the time)?

> 
> The second point is perhaps less obvious, but may be more important.
> Usually, *your* PC hard- and software is supposed to protect *your*
> assets and satisfy *your* security requirements. The 
> "trusted" hardware
> add-on in TCPA is supposed to protect an *outsider's* assets 
> and satisfy
> the *outsider's* security needs -- from you.
> 
> A TCPA-"enhanced" PC is thus the servant of two masters -- 
> your servant
> and the outsider's. Since your hardware connects to the 
> outsider directly,
> you can never be sure whether it works *against* you by giving the
> outsider more information about you than it should (from your point if
> view).

TCPA includes two different things: wrapping or "sealing" of secrets -
something in service to you (and the thing I invoked in the previous
disagreement) - and remote attestation.  You do not need to do remote
attestation to take advantage of the TPM.  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).

Of course, you're throwing out a significant baby with that bath water.
What if it's your secrets you want protected on my machine?  It doesn't have
to be the RIAA's secrets.  Do you object just as much when it's your
secrets?

> 
> There is nothing wrong with the idea of a trusted kernel, but 
> "trusted"
> means that some entity is supposed to "trust" the kernel 
> (what else?). If
> two entities, who do not completely trust each other, are 
> supposed to both
> "trust" such a kernel, something very very fishy is going on.
> 
> 
> Can we do better?
> 
> More than ten years ago, Chaum and Pedersen presented a great 
> idea how to
> do such things without potentially compromising your 
> security. Bringing
> their ideas into the context of TCPA, things should look like in the
> following picture
> 
>    +---------------+         +---------+         +---------------+
>    | Outside World | <-----> | Your PC | <-----> | TCPA-Observer |
>    +---------------+         +---------+         +---------------+
> 
> So you can trust "your PC" (possibly with a trusted kernel 
> ... trusted by
> you). And an outsider can trust the observer.
> 
> The point is, the outside world does not directly talk to the 
> observer!
> 
> Chaum and Pedersen (and some more recent authors) defined protocols to
> satisfy the outsider's security needs without giving the outsider any
> chance to learn more about you and the data stored in your PC than you
> want her to learn.
> 
> TCPA mixes "Your PC" and the "observer" into one "trusted 
> kernel" and is
> thus open to abuse.

I haven't read that paper - will have to.  Thanks for the reference.
However, when I do read it, what I will look for is the non-network channel
between the observer and the PC.  Somehow, the observer needs to know that
the PC has not been tampered with and needs to know, securely (through
physical security) the state of that PC and its S/W.  How does the observer
do that?

If you tell me how the observer does that, then that observer is even better
used telling me the PC owner the state of my PC.  Forget about the outside
world.  They can take my word for it, if I have this wonderful oracle
telling me the truth about my PC.

Where can I get one of those observers?  I want one now.

 - Carl

 
> Reference:
> 
>   D. Chaum and T. Pedersen. Wallet databases with observers.
>   In Crypto '92, LNCS 740, pp. 89-105.
> 
> 
> 
> -- 
> Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 
> Mannheim, Germany
>             e-mail: lucks at th.informatik.uni-mannheim.de
>             home: http://th.informatik.uni-mannheim.de/people/lucks/
> ------  I  love  the  smell  of  Cryptanalysis  in  the  
> morning!  ------
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com