31/3/00
In an OCF message, I read yesterday that introducing a card with a
different ATR requires a routine in OCF to be rewritten - Card Factory, if
I remember correctly. If this is true as written, it is a fundamental
misunderstanding of the function of the ATR and of the way in which the
terminal should process it.
The idea of the ATR and of the associated (but incomplete) PPS procedure
defined in ISO is to allow a card and terminal to adjust so that they can
communicate in the optimum manner. Therefore ATR processing is, in
principle, independent from application processing or application
selection. In practice, we know that many card schemes have been developed
in a manner which means they are critically dependent either on the card's
ATR always being constant, or on the ATR supplying information vital to the
APPLICATION, or on the ATR offering only a very restricted subset of the
possibilities defined in ISO 7816. Mondex, for example, sought to make it
possible in the early trial days for an extremely cheap but also fast
operating money value balance reader to be manufactured - they did this by
reporting the card balance and currency type in the historical bytes of the
ATR (as I noted yesterday in a response to another post).
In an ideal world, it might appear that the original policy of the ISO
Working Group was that every terminal would always be capable of
understanding and accepting all possible ATR parameter byte values. Later
they understood that this was not a realistic scenario, and introduced the
PPS procedure for the terminal to negotiate with the card - except that
they have never fully developed that procedure.
With the present ISO documents, it seems that a terminal that cannot accept
the ATR from the card, and cannot use the rudimentary PPS procedure to
solve the problem, must reject the card.
Then matters moved in two directions:
1. You must also remember that a card is not required by ISO to send the
same ATR every time. EMV turned this to their advantage when developing a
means for global interoperability: they defined a procedure under which the
terminal looks at the ATR, and then, if it decides it cannot do what the
card demands, it sends a warm reset to the card (drop the reset line for a
short time without removing card clock or power). At the end of the warm
reset, the card MUST then send one of two possible global interoperability
ATRs. In these ATRs, EMV mandates that the card must announce that it is
prepared to operate with parameter values very close to those used during
the ATR, and it announces either that it wants the T=0 comms protocol to be
used or that it wants the T=1 protocol (EMV version - except that the
terminal can't work that out) to be used. The terminal must then accept
this ATR and behave accordingly. Note that ISO has done no work on terminal
standards, and thus this EMV methodology is currently a private arrangement
for the EMV community - it needs to be brought into ISO, but there is no
effort available to do this sort of commonsense and very necessary work.
2. PC/SC decided to ignore the problems of incomplete implementations of
ATR processing in the terminal, and just instruct the terminal developer to
ignore ATR parameters and parameter values that it does not implement. So
the terminal developer is told to carry on and hope that the card will
work....
The onus is therefore on the terminal developer to ensure that the project
has a clear and complete specification for the ATR formats and parameter
values and historical bytes structures that the 'terminal' must accept and
process. The onus is therefore on library and device driver designers (such
as OCF) to make the library and device drivers transparent to the incoming
ATR, allowing the host system application developer to process it in a
special ATR processing module - there's a secondary problem here, of
course, because the card reader/writer may not be able to cope with some
ATR parameters and parameter values, so the ATR processing module needs to
have access to a reader/writer properties table which is loaded with the
reader/writer device driver and/or obtained from the reader/writer. But
there are no standards for reader/writers, and so the whole mess keeps on
going round and round and round....
Now we have the eEurope Initiative under way, with a Smart Card Summit in
10 days time, and a Smart Card Charter being drafted as I write this.
Looking through the summary of comments received by the EC team working on
this, the same old theme is there: complete failure by many practitioners
in the field to understand that the interoperability problems of smart
cards go right down to the bedrock. THE ONLY AGREEMENT ON CONTACT CARDS
WITHIN THE INDUSTRY IS THAT THEY ARE ID-1 SIZE AND SHAPE (and even there we
have tolerancing problems because a whole range of different materials are
now used to make cards).
So what should we do?
First, accept that the voluntary methodology of ISO has not worked in this
technology field.
Second, accept that the split of responsibilities between ISO and CEN, in
which ISO tackles the global matters and thus all the low level technology
items, has to be modified. There are checks and balances in the standards
system in order to correct imbalance between standards and the needs of the
real world, and we should use them to develop, within Europe,
interoperability specifications for contact cards and for contactless
cards, and then submit these specs to ISO for global standardisation.
Third, set (in the eEurope work) a target that all card terminals for use
by the public must be acceptable to all card schemes. This means that all
the individual scheme specifications must surrender their private
specifications right up to application selection level, and there must be a
quality assessment scheme for the terminal products and for
multi-application card platforms.
A last note: I'm not including security schemes in the scope of this note,
because the need to create a public authentication and identification
infrastructure has at long last been understood - because, if the security
scheme rules are not satisfied, a card application will not work. However,
I am aware that others who post to OCF have run up against the problem of
not being able to make the security schemes operate without writing their
own software, and I would urge the OCF movers and shakers to get involved
in the European work in this area.
Peter Tomlinson
Iosis, Bristol, UK.
Please reply to office email: [EMAIL PROTECTED]
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
