Hi Dave
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).
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.
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).
> One of the biggest obstacles in the smartcard industry today is the lack
> of standardization between different cards, readers, and even the platform
> in which they are used. Back in the early days of the internet many
> different standards existed like token ring, Dec Net, and others making
> the existance of a single infrastructure in which anyone could plug into
> difficult. Eventually the players began to see the light and one standard
> emerged as the godfather of all internet connectivity standards: ethernet
> and TCP/IP.
But without the Internet as the killer application, TCP/IP would not be the
de-facto standard today. Just think back a little while, when IPX looked like a
strong candidate.
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.
> Now anyone can plug into the internet and connect with nearly
> everyone else in a simple and seamless manner. It is no wonder why
> companies such as Cisco are doing as well as they are. Do you think that
> these companies would be doing as well if many networking standards still
> existed today ? The Internet would not be growing as quickly if not a
> single standard emerged from the struggle because users need a seamless
> way of connectivity. The same must exist for smartcards. Although
> magnetic stripe cards are of a much simpler nature, it is still possible
> for myself to travel to France and use an Automatic Teller Machine to gain
> access to money. I can even use my VISA card in almost every terminal
> that exists. Do you think that these cards would be as useful if every
> bank issued their own proprietary location of information on the magnetic
> stripe ?
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.
> Smartcards must also develop such standards to make communication to them
> in a seamless manner. The following is a list of what I consider to be
> necessary for the smartcard industry:
>
> 1) One communication protocol should be used. Currently there are
> several: T=0, T=1, Synchronous, and others. My personal feeling is that
> all cards should communicate in the T=1 block protocol. It is much more
> efficient, and gives the card a way of communicating back to the reader to
> establish resynchronization or to communicate the need for more waiting
> time. T=0 does this through the ATR so if the card needs more time it has
> to change the ATR to notify the host of this. I feel this is a poor way
> of doing this.
Most modern cards do that today, unfortunately some French companies do not
really like T=1 for historic reasons. Quite often these cards even support both
protocols with PPS.
> 2) The ATR should be used as a means for card identification. It is
> ridiculous that much of the ATR can be changed except the protocol
> information. I think the ATR should have 6 historical bytes reserved for
> identification. 2 for manufacturer id, 2 for manufacturer mask, and 2 for
> user definition. That makes 65,000 manufacturers, 65,000 masks and 65,000
> user defines. The user can only change their 2 bytes. Thus the card can
> still be identified by it's core OS 2 bytes manufactuer/2 bytes mask.
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.
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.
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.
> 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.
Andreas
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***************************************************************
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
***************************************************************
