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

[Anne & Lynn Wheeler]

On Fri, 2003-12-19 at 12:40, Ernst Lippe wrote:
> It is not really true that there are so few smartcards. Almost every
> mobile phone contains one (the SIM module is a smartcard).
> 
> Also the situation in Europe is quite different from the USA.
> Electronic purses on smart cards are pretty common here, especially in
> France and the Netherlands, where most adults have at least one.
> 
> But it is true that there are only very few smart card enabled
> applications.  I have worked on several projects for multifunctional
> use of these smart cards and almost all of them were complete failures.

one can claim that the SIM module isn't a smartcard as per the 
original design point .... it is a mobile phone that happens
to leverage the smartcard manufactoring process.

my assertion is that the original smartcard design point was
as a portable computing infrastructure that didn't have 
portable input/output technology. a huge investment went into
standards (so that these cards could be carried around and
still interoperate with various input/output stations) and
volume manufactoring faclities.  Just because they are the
same physical components doesn't mean that they are the same
business.

my observation has been that the stored-value smartcards 
were an economic trade-off .... supposedly because of either
1) extremely high telco fees and/or 2) availability problems
with telco connectivity .... giving everybody smartcards 
and all merchants "offline" (aka smartcard) point-of-sale 
terminals  ... was less expensive than an online paradigm.

in the US .... with ubiquitous and inexpensive telco 
availability ... it was less expensive to go with the
standard online POS terminals and stored-value using
the traditional magstripe interface (aka it was difficult
to justify the increased chip expense based on any 
possible savings in telco &/or online transaction costs).

my contention in the AADS chip strawman scenario ... 
http://www.garlic.com/~lynn/index.html#aads
that with aggresive focus on compelling business use of hardware
token (regardless of form factor) as an authentication device,
it should be possible to justify the hardware token just
based on fraud mitigation. with reasonable assumption about online
connectivity becoming universal and inexpensive .... it
is difficult to see any business justification for anything
other than fraud mitigation. If the only business justification
is authentication (for fraud mitigation), it isn't necessary
to have multi-function features supported in the hardware token.

If there is no function/feature needed in a hardware token
(other than authentication for an online environment), the
the provisioning for hardware tokens (regardless of form
factor) is significantly simplified ... aka KISS.

The current provisioning convention for magstripe cards
is there because the magstripe carries effectively shared-secrets
for authentication ... which by simple security 101 rules
says that there has to be a unique shared secret per 
security domain (and every financial institution is their
own security domain).

To some extent the provisioning of financial smartcards 
just continues to utilize the magstripe model. In addition,
given offline transaction scenario and possible use of the
card for non-authentication purposes, additional provisioning
of the chip is required to load business rules so that
its use is aligned with the financial institution issuing
the card.

The assertion then is that in the scenario where the 
hardware token is purely an authentication device, most
of the additional provisioning is eliminated (and becomes
superfluous).

There is typically one additional argument used for
institutional delivered hardware tokens (smartcards), even
if there is no provisioning required ... which is that they
tightly control the process so that the chip eventually
delivered to the end-user can be assumed to meet some specified
trust level.

So a person shows up at the doorstep with their own hardware
token and wants to use it as their authentication device
(whether it is a financial institution for electronic financial
transactions, an employer for door badge access, or a gov.
agency) .... the institution will frequently respond something
about "how can they trust the token?"

So what might convince institutions to accept a consumer
presented hardware token for authentication ... as opposed
to mandating that the only hardware token that they will
trust are the ones provided by the institution.

-- 
Anne & Lynn Wheeler -  http://www.garlic.com/~lynn/ 

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