Subject: Re: A challenge

From: [email-masked]
Date: Wed, 12 Feb 2003 13:47:08 -0700

I assert that the traditional smartcards are somewhat like dinosours ...
the signal just hasn't reached the brain yet.

I assert that the basic smartcard design point was during the '80s for a
portable computing device .... that predated the availability of portable
input/output capability. Basically you carried all the computing around in
the 7816 smartcard form factor and used it at generic input/output
stations.  However, that market niche had disappeared sometime in the early
90s with the advent of portable input/output capability in the form of
cellphones and PDAs. I would guess that up to that point there had been
tens of billions of dollars in the technology that all had to be written
off. To some extent the smartcard continues on with a little bit life of
its own .... in part the investment has totally been written off .... and
with zero-sum budgetting .... even if you only could leverage the earlier
investment at a few cents on the dollar ... the technology continues to
linger around.

So one of the places to leverage essentially the 7816 investment was
supporting transferrable personality for cellphones. However, in the past
year or two there have been articles on the incremental cost that providing
such a reader represents in cellphone manufactor. Furthermore, this
transferrable personality implementation still has several gaps .... the
phone can be lost/stolen, there can be physical/electronic failure in the
smartcard, and even the contact interface represents additional points of
failure for the cellphone. The story line went something like an online
backup/restore of the personality subsumes all the function of the
smartcard as well as addresses all the additional shortcomings .... while
negating the need for having the additional cost of the smartcard interface
(as well as eliminating a point of failure in the cellphone). The issue is
that even with only needing a few cents on the dollar (compared to the
original 7816 investment) .... the smartcard in the cellphone still can't
address all the requirements .... and the online back/restore which does
address all the requirements then, obsoletes the necessity for the
smartcard. And, as per the cellphone business discussions, cellphone
manufactors can save some additional pennies on the cellphone manufactor as
well as eliminating a point-of-failure (the contact infrastructure for
sliding the card in/out).

There is a requirement to possibly uniquely identify the use of the
cellphone. In the digital signature world ... that somewhat maps to a
hardware token with an on-chip generated key-pair .... and the private key
never leaves the device. This can be built into the cellphone .... either
as ROM in an existing chip .... or as a separate chip somewhat like the
TCPA strategy.

So a scenario is that as part of online restore into a new cellphone ....
either a previous key-pair is backed-up and restored .... or that the
device unique key is then re-registered in all the places that the previous
cell phone had been registered.  And as per my previous post in the thread
... the registration/binding business process is actually independent of
whether or not a certificate is issued ... aka the original certificate
design point (from somewhat the same '80s era as original smartcard) was a
way of representing the registration/binding business process for an
offline environment (which had no direct access to the authoritative
registry).
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)

One problem is that even if the smartcard was purely restricted to the
protection and digital signature use of a private key .... there still is
the whole unresolved issue of lost/stolen devices ... and any moving parts
(even just slipping card in/out past contacts) are more prone to failure
than purely electronic operation. Note this is also given as one of the
reasons for the migration to ISO 14443 and away from ISO 7816 is because of
the mechanical failure issues ... especially in high-traffic areas. This
brings up the whole issue of possible competing contactless technologies
coming to bear .... 14443, 802.11, bluetooth, cellphone, etc.

some tcpa related discussions
http://www.garlic.com/~lynn/2002i.html#71 TCPA
http://www.garlic.com/~lynn/2002j.html#55 AADS, ECDSA, and even some TCPA
http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national
ID card?

also
http://www.garlic.com/~lynn/index.html#aads

has URL to a talk on assurance that i  gave at the TCPA track at past intel
developer's conference.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Torsten Hentschel <[email-masked]> on 2/12/2003 1:31 am wrote

Hi Anders,

... snip ...

> ============================================
> But frankly I see no future in smart cards of the type Germany
> is investing in.  A mobile phone is such a tremendously
> more powerful "container" that allows users to do things
> that smart card owners cannot even _dream_ about.  Since
> mobile phones are on-line by definition, static key and
> certificate schemes then become rather irrelevant.
> ============================================

Well, mobile phones contain smart cards, don't they?
I do absolutely not see the dead end here.

Kind regards,

   Torsten

--
Torsten Hentschel
[The positions of mine as outlined above are not neccessarily

---

From: Al Arsenault <[email-masked]>
Date: Thu, 13 Feb 2003 07:43:48 -0500

Lynn,

    Interesting message from you, as always.  Fascinating predictions on the
future.  Only a few issues need to be raised, IMHO.  :-)

    One of those issues relates to the whole "secure backup and restore" or
"secure download" of credentials. That's currently an unsolved problem.
Fortunately, IETF has a working group - SACRED - addressing that issue.
While SACRED started out a couple of years ago with a lot of interest and
enthusiasm, interest seems to have waned.  There are only a few people
actively participating, and the group is about to wrap up with its solution.
While I am others hope that the proposed solution will succeed and solve
parts of the problem, it's not a complete solution (e.g., it addresses only
device - credential server interactions; it doesn't support device - device
operation).  So consider this message a plea for others interested in this
area to get involved in this work.

    Until SACRED or some similar solution becomes widely implemented,
smartcards - e.g., SIMs or WIMs in phones - aren't going away.  The business
model in many parts of the world relies on a large number of customers
replacing their handsets frequently.  In many areas I'm familiar with, it's
common for a large set of people to replace their handsets every few months,
so that they always have the latest, smallest, most colorful, "coolest"
device.  The whole notion of a smart card supports this model, by allowing
the user to get a new handset and dispose of the old one while maintaining
the same service WITHOUT INTERACTING with the mobile operator, because those
interactions with the carbon-based life forms who staff the operator outlets
represent one of the highest costs in the system. With a SIM/Smart card that
can be moved from one handset to another, there's no need to involve any
other carbon-based life form. Since there's now no way to securely move the
credentials electronically that's widely interoperable (lots of us have our
own, somewhat proprietary schemes), for most mobile operators/service
providers the smart card remains the method of choice.

    An automated - read as "efficient and low cost" way to securely register
new devices into the system is also a requirement, and it's also currently
an unsolved problem.  Oh, there are other standards groups working on it,
but I'm not sure they're going to have good solutions any time soon.

    So it's nice to sit here and make statements that "this technology was
just wrong, and 20 years from now everyone will acknowledge that it's
obvious", but tell me Lynn, how many statements about ISO vs. TCP/IP did you
make in 1983?

        Al Arsenault
        Diversinet Corp.