On Tue, 23 May 2000, Andreas Schwier wrote:
> Hi Dave
>
> >
> > 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.
Well.... You have to define a first protocol, then find you can enhance
it, etc.... That's why you have so many communication protocols... You're
looking at your first smart card and maybe think it's been invented 2
years ago.... That's not true...
> 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.
Beside that, it would be difficult to be able to change the whole ATR,
including the protocole type, the endianess, .... Smartcard manufacturers
still have to deal with lack of physical space, small memory footprint,
and low cost... That makes integration of "bells'n whistles" difficult to
do...
I also agree with Andreas, in the sense that a well written application
should not rely on a specific ATR to identify an application. The ATR
should be here only to identify the specific chip type and revision. With
multiapplication smartcards, it's not possible to modify the ATR to
reflect all the applications loaded in the card. I would prefer to use
another mechanism: just specify a function with specific CLA/INS
combination that returns a known value depending of the presence of an
application... That way you could have several applications loaded in the
card and test wether they're activated or not. Doing so consumes a small
amount of precious EEPROM bytes, but ...
> 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.
Yeah, that's already the case... Some commands regarding file operations
are ISO defined...
> > 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.
Storing the crypto objects in a standard way in a smart card is the goal
of PKCS#15... But this PKCS doesn't address the commands used to make use
of these crypto objects... I heard of a ISO-7816-8 that addressed
this...
In fact, it depends on the level of standardization you need... Do you
want to be able to use the crypto functions of any card, only by changing
the card and a library? Then you should look at PKCS#11. If you want to be
able to use any smartcard with a standard set of API to access it, then
you're already looking at PC/SC (yes, there existed a lot of proprietary
libraries before PC/SC). If you want to be able to use the same PKCS#11
library with any smartcard, then the smartcard and PKCS#11 lib should be
compliant with PKCS#15 and whatI called "ISO-7816-8" or whatever it's real
name...
--
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -
***************************************************************
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
***************************************************************
