Andreas Schwier wrote in reply to Dave's posting (and my responses are embedded
in the text below):
> I fully agree with your statements, but it's not that terrible. I've been
> working in the industry for 14 years now and as a former member of the German
> standardisation body (NI17.4) I've been involved in the work that gave us
> ISO7816-3,4 and 5.
>
> Industry standards are always a tradeoff. They usually reflect the interest of
> companies that send people to these standardisation groups. It's
> quite expensive to do this kind of work, so it does not surprise that
> companies only invest that money, if they see some benefit (which is surely not
> interoperability).
Interoperabiliy is now a mandatory requirement for the public sector in
Europe, and the eEurope Initiative aims, with its Smart Card Charter, to
bring about interoperability in transactions between the citizen and
business. The user-centric goals are one contact reader slot spec or
standard to take all the cards that the citizen may wish to use in
transactions with government, banks, and business, and for all single
and multi-app cards issued for this purpose to be always accepted in
that slot. On top of this, there is a competition requirement: the public
sector must not be tied into single supplier relationships in this area.
Please look at the UK Framework for Smart Cards in Government on
the www.iagchampions.gov.uk web site - there is a similar push for a
common PKI infrastructure introduced in another document on that
web site. eEurope covers the same topics: cards, terminals, PKI
infrastructure.
I was yesterday at a meeting to discuss the UK specifications for
public transport ticketing. On the bus, the card interface has to be
contactless. At other times (e.g. purchasing the ticket over the
internet), the card interface can be contact. Over the next month, some
of us hope to study the drafts of 14443 up to part 3 (parts 2 and 3 have
just been completed, ready for the FDIS stage) in order to assess
whether they are good enough to build interoperable systems for both
microprocessor cards and Mifare cards.
>
> The other problem with standards, is that they only contain the results of very
> long disussions that were held in these groups. Reading the standard
> does not tell you why things are done in a certain way. You only see in a very
> compressed document, what everyone finally agreed on.
And the reasons should be documented and published, because they
would help designers to understand the often impenetrable text of the
standard.
There is another problem with standards: patents (but that is a long
story, and someone else has explained part of it).
>
> Now other people take these standards and try to implement them. And because
> developers don't really like reading standards and because they don't have the
> background information, things gets out of hand. A good example is the chaining
> mechanism in T=1. Soon after the first drafts of T=1 were written, people
> started implementing T=1, but they left out chaining and claimed that it is
> optional. If you look at the standard it's clearly not and you see that T=1
> without chaining doesn't make any sense.
>
> Standards take very long to develop and it would not work, if companies did not
> try to implement proprietary system, just to find the best solution for a
> standard. But because of this, standard often need to embrace even these poor
> first time shots, because they suddenly got successfull in the marketplace and
> defined the common standard (I can think of better ways to exchange documents
> than in Word format, but it's there and won't go away soon).
There is no excuse for standards developers not doing a professional
job, i.e. getting the standard right. The problem is basically finance.
Many companies and countries want the standard, and they want it to
be correct and complete, but they will not finance the work - so the
developers are frequently not allowed to do the job properly.
An ISO editor tells me that ISO has moved to pdf format, and we still
have problems, as was evident at the UK contactless technical panel
recently when we were comparing documents that we had each
porinted off.
>
>
> PC/SC is a good global specification to start with. I guess the combination of
> PC/SC with the CT-API / CT-BCS approach in M.U.S.C.L.E will work quite well. I
> don't see companies writing terminal drivers for OCF, and IMHO OCF will always
> be used as a layer on top of PC/SC.
When you look at the low levels of PC/SC (electrical, data comms,
ATR processing), and providing that you have knowledge of both
ISO 7816 and EMV, you quickly realise that PC/SC is a mess down
there. Its is a muddled mixture of ISO and EMV, and it says that, if the
reader can't cope with the ATR that the card sends, the reader should
carry on and hope that soemthing works.
That is not a professional way to do things. I jave asked PC/SC (and
Microsoft) to sort this out, but nothing has been done.
>
>
> Just take your MasterCard, VISA or Amex with an EMV application on the chip and
> you can stick it into any EMV terminal around the world. The standards for that
> are here, but it's not yet a business case for the banks to invest into chip.
And EMV is not ISO compliant, which causes problems making
terminals (and also when trying to configure multiapplication cards).
Scheme developers outside of banking do not want to use EMV.
>
>
> Most modern cards do that [T=1] today, unfortunately some French companies do not
> really like T=1 for historic reasons. Quite often these cards even support both
> protocols with PPS.
First, ISO and EMV versions of T=1 are different, and both have
problems in the error recovery area (developing a state diagram from
the text shows this error handling problem). This was communicated
to EMV in 1998.
Second, the committee draft of ISO's 14443 (Proximity cards) part 4 has
recently been sent to reviewers for comment. It specifies a protocol
very like T=1, but is that protocol correctly defined? We don't know.
There is no state diagram. There is no money to prove the correctness.
14443 stops at part 4, because that part is intended to be a bridge
across to 7816 part 4 (the project I mentioned above does not include
part 4, as the text is not yet finalised).
>
> And who is going to register and maintain these identifier ? And why would I
> need the ATR to identify the card ? What I need is a mechanism to identify the
> application on the card and I can do that using the AID stored in EF_DIR. PC/SC
> introducted the concept of identifying the card with the ATR and as you can
> see, that doesn't really work well. Why do I want Microsoft Plug and Play with
> a SmartCard ? In most cases I know what I want to do with the card before I
> insert it into the reader.
Here is the error in all the 7816 and 14443 work: it is wrong to assume
that you know what you are going to do with the card before the card
is entered into the reader. ISO has always failed to treat the card and
reader together as a system. You MAY know what you WANT to do
with the card, or you may be in the position where the cardholder or
the equipment operator has not yet decided what to do.
There is another problem here: some schemes want their application to
have priority. That means it is implicitly selected when the card is
powered on. That means it takes over the ATR historical bytes in
order to announce its own information. That means that app can be
executed very quickly. When EMV and Mondex and a transport ticket
app all want to be top of the heap, what do we do?
>
> The ATR is for the pure purpose of defining the interface characteristics for
> communication between the card and the terminal. Everything else is
> application. The historical bytes shall be used to offer some proprietary
> information about the chip, that can be used for diagnostic purposes.
>
But in a multi-app card, different apps may want the comms to work in
different ways. And EMV (quite correctly for interoperability) wants
the card to detect that it has been sent a warm reset (drop the reset
line but leave power and clock on the card) and respond with a basic
ATR (of which there are 2 versions, one saying T=0 and the other
saying T=1).
> ISO7816-4 contains all thats needed in sections 8 - Historical bytes and 9 -
> Application independent card services. It's up to the application developer to
> make use of that.
>
> > 3) ISO-7816 should include a command for the creation of a
> > transparent file and a command for the listing of files.
>
> ISO7816 Part 9 - Additional interindustry commands and security attributes
> does that.
>
> > 4) Card manufacturers need to be ISO compliant. Class instructions
> > should be standardized to either 00 or C0 or whatever. I should be able
> > to list the directory of files on the card in 1 way on any card.
>
> Just pick a card that implements the latest standards that.
Once again, EMV is not ISO compliant. EMV, however, has defined an
application selection mechanism in order to make it easier to know
what is on the card.
EMV and ISO need to come together, because EMV has answers to
some of the problems.
>
> > 5) There must be a standard for putting the keys on the card. If RSA is
> > used then do pq... whatever but in the same order on each card. Also,
> > cards should have the same endianness. This is crazy that people haven't
> > learned their lessons on this one yet.
>
> That's a little bit more tricky, as the keys are usually stored in specific
> areas in the card. This would clearly be the job of a card service provide in
> PC/SC. On top of that a PKCS#11 layer will do the rest.
#PKCS15 is aimed at unifying PKI token storage in cards.
>
There's an old rhyme: Oh what a tangled web we weave, when first we
practice to deceive. I accept that very nearly all of the people involved
in these standards have no intention to deceive, but the complete lack
of transparency in ISO deliberations on these card standards has
resulted in an extremely frustrating muddle. CEN is working in a much
more transparent manner, running Workshops to publicise the work of
those standards groups which have some public money in them. The
UK is running supplier forums for contactless cards used in transport
ticketing (it was one of those that I attended yesterday), and at long
last we have public money assisting the work, and the UK supporting
CEN work in the area of public transport applications on cards.
Peter Tomlinson
Iosis, 34 Strathmore Road, Bristol BS7 9QJ, UK
Phone & fax +44 (0)117 951 4755
Email [EMAIL PROTECTED] or [EMAIL PROTECTED]
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
