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

Stefan Lucks lucks at th.informatik.uni-mannheim.de
Tue Dec 16 04:02:11 EST 2003


On Mon, 15 Dec 2003, Carl Ellison wrote:

[I wrote]
> > 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.

Strange! Currently, I have three smart cards in my wallet, which I did not
want to own and which I did never pay for. I never used any of them. They
are packaged with some ATM cards (using conventional magnetic-stripe
technoloby) and implement a "Geldkarte".  (Since a couple of years, German
banks try to push their customers into using the "Geldkarte" for
electronig money, by packaging the smart cards together with ATM cards.
For me, there ares still too few dealers accepting the "Geldkarte", so I
never use it.)

OK, the banks are paying for the smart cards they give to their customers
for free. But they would not do so, if these cards where expensive.

BTW, even if you have only one, a smart card has the advantage that you
can physically remove it.

> 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.)

A smart card can do the same.

> 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.

Exact!

> 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 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.


[...]
> 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.


> 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?

Feel free to buy an overpriced second-hand car from me. I promise, I won't
object! ;-)

But seriously, with or without remote attestation, I would not consider my
secrets safe on your machine. If you can read (or play, in the case of
multimedia stuff) my secrets on your machine, I can't prevent you from
copying. TCPA (and remote attestation) can make copying less convenient
for you (and the RIAA is probably pleased with this), but can't stop a
determined adversary.

In other words, I don't think it will be too difficult to tamper with the
TCPA hardware, and to circumwent remote attestation.

Winning against the laws of information theory is not simpler than winning
against the laws of thermodynamics -- both are impossible!

> > Chaum and Pedersen  [...]

> > TCPA mixes "Your PC" and the "observer" into one "trusted kernel" and
> > is thus open to abuse.

Let me stress:

  -- Good security design means to separate duties.

  -- TCPA does exactly the opposite: It deliberately mixes duties.

> 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.

It doesn't need to know, and it can't know anyway. All it needs to know
whether itself has been tampered with. Well, ... hm ... it more or less
assumes itself has not been tampered with (but so does the TCPA hardware).

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

You get them at the same place where you get TCPA hardware: In a possible
future. ;-)


-- 
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



More information about the cryptography mailing list