Michael Bender wrote:
> Is it possible (or to the spec) to have a card that can only do T=1
> and not T=0? One of our customers claims to have such a card (more
details
> later as I get them) and it is failing in one of our readers that only
> supports T=0.
The response from Sylvain gave the basics of the answer, but the more
general problem that this brings up is the problem facing the developer of
a card reader/writer (terminal): ISO 7816 only describes cards. It is clear
that the card only needs to implement the parts of ISO 7816 that the card
designer wants to implement - such a card can claim to be ISO compliant.
Thus a microprocessor card can be T=0 only, or can be T=1 only, or both.
EMV recognises this when it extends the ISO model to mandate that a card
must be able to provide a "basic ATR" (invoked immediately after first ATR
transmission by sending a warm reset to the card - drop the reset line for
a while but keep power and clock on the card) in which it offers one and
only one protocol, and that protocol can be T=0 or T= 1 (except that EMV's
T=1 is different from ISO's T=1, as I noted previously).
ISO 7816 asumes that the card designer and terminal designer are working
together, so that the terminal designer ensures that the terminal
implements everything needed to handle the card. But, as so many
contributors to this forum have found, we buy our terminal from one source
and our card from another, and expect them to work together. This is
becoming worse and worse as multi-application cards are used, and as
governments quite rightly start to say that every card issued to the public
should be usable in all the terminals offering services that can use the
card - and, at the same time, merchants say that they want to have only one
card rader/writer slot in their tills.
For compliance with ISO 7816, the terminal therefore has to implement
everything in the standard - and such a reader/writer can then handle cards
which offer T=1only, of course - but such a terminal also has to implement
the new security-related industry standard card commands. What we need (but
will never get in a strictly open, competitive market) is clear and
detailed specs of both cards and terminals, showing exactly what they do
implement....
One of the serious requests put by the retail community here in the UK to
EMV was for them to include in EMV 2000 a new system architecture model
which recognises the need for the retail community to have the maximum
control (by software) of the functions and features of the card terminals
in their store POS (till) systems. This means that the card accepting
device (CAD; read/write slot) must be handled by a microcontroller which
hosts only the minimum functions, these being mainly the real-time features
of the interface to the card (basically the 7816-3:1997 stuff), and that
the CAD must FULLY implement those functions. EMV took no notice, and that
is profoundly disappointing. EMV continues to insist on effectively having
a stand-alone expensive high security EMV compliant (and therefore not ISO
compliant) terminal inserted into every retail till position.
Yes, ISO 7816-3 is not without its problems, as someone who tries to do
what I suggested above soon finds out. Therefore the discussion needs to be
widened, and will be, here in Europe, as the eEurope work plan takes shape:
we need to overlay 7816-3 with a compatibility spec and to extend it to
higher data rates, and incorporate some of the EMV ideas (e.g. warm reset
forcing the card to issue a basic ATR). Only then can the card industry
(and a universal PKI industry) mature.
I'm working at present in the contactless card area (e.g. the drafts of ISO
14443), and the same problems occur. ISO's 7816 committee (JTC1/SC17) has
been discussing adding terminal characteristics to their scope of work, and
indeed they have had to try to define some of the terminal functionality in
14443.
And a last note: this standards work is so necessary for the industry, yet
the major players in the industry fail to fund the work. Every time I hear
someone complain that the standards are either incomplete (as is the case
with 14443) or inadequate, I ask that person if his or her company has
funded any of the work. Nearly always the answer is 'No'. Those trying to
implement interoperable systems (citizens cards, transport cards) here in
the UK cannot understand why the industry is not providing the products
that they want and that public procurement policies are increasingly
insisting they must use.
Peter Tomlinson
Iosis, Bristol, UK
---
> 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.
