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

[Ian Grigg]

Stefan Lucks wrote:
> 
> On Mon, 15 Dec 2003, Jerrold Leichter wrote:
> 
> > | This is quite an advantage of smart cards.
> > However, this advantage is there only because there are so few smart cards,
> > and so few smart card enabled applications, around.
> 
> Strangely enough, Carl Ellison assumed that you would have at most one
> smart card, anyway. I'd rather think you are right, here.


In the late nineties, the smart card world
worked out that each smart card was so expensive,
it would only work if the issuer could do multiple
apps on each card.  That is, if they could share
the cost with different uses (or users).

This resulted in a big shift to multi-application
cards, and a lot of expensive reworking and a lot
of hype. All the smart card people were rushing
to present their own architecture;  all the user
banks were rushing to port their apps back into
these environments, and scratching their heads
to come up with App #2 (access control, loyalty...)

But what they seemed to miss was the stellar mental
gap between the smart card and the PC.  On the PC,
a user can install an app if she so choses.  On
the smart card, it was a proprietary system, and
no smart card provider (the institution was the
real owner) was going to let anybody else play.

But, they believed and behaved as if others could
play.

As many suggest, the starting point is "who owns
the card/trusted module."  From that point, you
can predict what will happen.  If it is not the
end user, then a lot of expensive spinning will
eventually be thrown out.  Using an institutional
model, and today's understanding of PCs, it is
fairly easy to predict that TCPA hardware will
fail unless you can find someone to pay for the
entire rollout, and use it for one purpose with
which they are happy with.  And, it won't take
over the market unless you can solve the issue
of un-TCPA'd hardware.

The cost of the barriers created is daunting, and
generally outweighs any security gained.  There
is a reason why the PC slayed the mainframe -
transaction costs.

Dragging this back to crypto.  Sun recently set up
their Java crypto environment ("JCE") with special
"signed providers."  They then added International
Policy Files.  Even though Sun (for free and
without complaint) gives away sigs on signing
keys and allows anyone to download and install
the International Policy Files, the process has
slowed to a crawl.  The Number 1 Bug in Java
crypto is the lack of the Sun Policy Files [2].
And, the resultant effect will of course be more
and more insecure apps...

Exerting control has huge costs.  There had
better be a huge reason [3].  This is rarely
the case;  and almost all security concerns can
be done by being more careful in software, or by
fudged by bypassing the weaknesses with external
tokens.

iang

[1] We looked at putting gold currencies alongside
national currencies on smart cards in 1999 or so,
and found that not only could we not do this, we
could not even get access to the development kits,
the people, nor the smart cards.  It was an
institutional brick wall.  Part of the brick wall
was the doorway that permitted only institutional-
sized players through.  Nowadays, the gold currencies
do more transactions in a day than many smart card
monies did in a year.

[2] I don't blame Sun for this.  I blame us
cryptoplumbers for not recognising the bait
and switch.  At some point we'll ditch the
Sun architecture and get back to free crypto.

[3] Other examples of institutional plays that
stumbled over the transaction costs issue:
cellular phone apps that can now be installed
by the users, and CA-PKI model / HTTPS servers,
where some nominal security was available if
you paid for a cert.

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