From: Peter Tomlinson (pwtiosis.co.uk)
Date: Sun Apr 10 2005 - 13:09:51 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Peter Williams wrote:

> Ok. So lets get political! Given someone mentioned ISO, and the contribution
> of an NSA work product to an international forum.
>

Those who want to cross-reference my comments here to Peter W's text and
my previous contribution can go back to the earlier posts.

I mentioned Scott Guthery. He's a mobile device man, steeped in SIMs and
their attempt to grow into true multi-app smart cards - that I think is
the decisive factor in WG4 TF9 staying with, well, not always 9600 bps
but not a lot faster (say around 50K in the mobile device) for 24727
used with traditional contact cards. Of course ISO/IEC 14443 can run at
up to 424K (848 is in the spec, but not easy for chips and terminals to
attain), and ISO/IEC 7816 has just allowed a USB interface to be put on
the two spare contacts on the 8-contact 'stamp'.

Another note about 24727: it incorporates the on-card 'card manager'
concept, such as is found in Visa Open Platform and now in Global
Platform, and has for years been built into Multos (but without its own
AID, although I believe they have added a dummy AID now).

Since Peter W and I met up in Birmingham (UK, not USA) last autumn,
quite a lot of interesting but unsatisfactory things have happened here
in Europe. We cannot put any significant effort into 24727. We don't try
to use the relevant parts of GSC-IS. And the big data containers in
GSC-IS with their flat structure do not suit citizen service cards,
which is where the European interest is.

The scene changes:

1. CEN TC224 WG15 [1] is trying to develop a standard for interoperable
citizen service cards. The best that it can do so far for a personal
data and security structure is the passport LDS (Logical Data Structure)
- but the concept of the passport (and its companion the pan-Europen
travel document) is a long way away from the concept of a citizen
service card that is actually useful to the citizen, and the citizen
service card in turn is very different from the compulsory ID card -
although there is a need for strong authentication when using the
citizen service card on-line. Go look at eURI, which is CEN/ISSS CWA
13987:2003, defining a data structure that the citizen controls [2] -
but it doesn't address the authentication problem.

But that is an aside (since I wrote the technical spec part of eURI, but
using a long strand of earlier material). The EU citizen card is meant
to be interoperable across many security domains (see the modelling
exercise in OSCIE GIF [3]), and that is where the end-to-end secure
channels ought to come in and the insecurity of the PC begins to be
coped with. Big smart card systems business wants to sell what it has
got in Europe and not develop end-to-end security and interoperability
between security domains. Off stage left the European Commission is
upset but doesn't know what to do.

With end-to-end security comes the need for the secure sub-terminal: a
card reader with integral display and keypad and maybe more, all
clustered round a router which stops interference with the card or with
the activities of the user when authorising something. FINREAD shows the
way (but the the FINREAD spec demands EMV compliance, a problem which I
had hoped Global Platform people would deal with). Wave Systems in the
USA showed the way some 6 years ago as well. To make all this work the
card software has to be different: it is the card that authorises a
transaction, not the software in the PC. The certificates go in the
card. The user and card communicate with each other at the sub-terminal.
The user communicates with the remote server through the PC. Off stage
right the banking community is not amused.

2. Another scene: a loose association of local authorities across Europe
has taken the title Smart Cities Interest Group and wants to promote its
concepts in the direction of European standardisation, and the goal is
interoperable citizen service cards [4]. Since CEN TC224 WG15 is going
to define a technical standard, SCIG (or just SIG) is using the CEN/ISSS
route to set out a common set of operational guidelines in the MMUSST
Workshop - it can use a lot of the same sort of material from eURI. What
happens when we disagree with TC224 WG15 and its industry vested
interests? (I will know soon, because I'm on the MMUSST project team.)

So where next?

- So far in the 24727 material I have not seen end-to-end security
methods needed to protect the card holder (but the job is not yet finished).
- As I noted earlier, the card reader and the driver in its host are not
being addressed in 24727.
- Secure end-to-end methodology needs the material about the terminal
that has been produced by the FINREAD and STIP crowd, by Wave Systems,
and more recently the work that GP has been trying to do, to be brought
together into a coherent whole.
- The banking community has to be challenged to accept that secure
on-line methods are needed, and needed soon. They have or are installing
the hardware in ATMs (and so its a software job - and I know that its a
big software job because their software has tended to develop in an ad
hoc way), but they have not moved an inch to develop secure on-line methods.

Get political!

Peter T

[1] CEN is the European Standards Organisation, which tends to restrict
itself to application areas when getting involved in smart cards.

[2] eURI CWA 13987:2003 is found at www.cenorm.be/isss. Try
http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/cwa/euri.asp,
but the exact URL tends to change every few months.

[3] OSCIE GIF was at www.eeurope-smartcards.org, but the contract to
support that has run out and I don't know where it has gone. I can
supply it if necessary, as can Henry Ryan to whom this post is copied,
and I will try to find a new link to it.

[4] But some people want to use 4K Mifare memory cards! Cheap, easy to
set up the memory map, but totally unsuitable for interoperable schemes.

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]