On Sam, 04 Mär 2000, you wrote:
> hi ho :-)
>
> i want to use the eco5000 reader, to use memory cards, but i have a
> difficult problem. if im using the following function i get back the
> errorcode 273. what does it mean ? and the pcsc server wrote :
The ECO5000 driver currently supports 2-Wire (SLE4432/4442 and PCB 2032/2042)
bus protocol and will in an upcoming release support 3-Wire (SLE4418/4428) and
I2C bus protocols. The support has been implemented using the "Interindustry
command set for synchronous cards" from the MCT 0.9 specification part 5 - 7.
With this implementation a synchronous card (or memory card) is seen by the
application as a simple processor card implementing a very basic set of ISO7816
command APDU's. The main memory of a synchronous card is mapped to the MF file
identifier 3F00.
An application that wants to read the complete memory of a SLE 4432 memory
chipcard would need to issue the commands
SELECT FILE (FID=3F00)
CLA INS P1 P2 Lc Data
00 A4 00 00 02 3F 00
READ BINARY (Offset=0)
CLA INS P1 P2 Le
00 B0 00 00 00
The very same sequence would work for a 3 Wire bus card and an I2C bus card.
The commands would return a maximum of 256 bytes each.
An application that needs to write some area in the chip would use
UPDATE BINARY
CLA INS P1 P2 Lc Data
00 D6 00 20 04 "TEST"
but it would require a
VERIFY
CLA INS P1 P2 Lc Data
00 20 00 00 03 FF FF FF
to enable write access to a SLE4442 with protection code FFFFFF first.
For cards with more that 256 bytes memory, the Lc and Le fields would be
coded in the extended format from ISO7816-4. In such a case, writing 512 bytes
to the main memory of a SLE 4418 would require a command APDU of
UPDATE BINARY
CLA INS P1 P2 Lc (ext) Data
00 D6 00 20 00 02 00 "ABC.....xyz" (512 bytes)
The specification also defines some additional files, which require a certain
memory layout organized in TLV objects. These additional files are
2F01 for the ATR file, that is the data object at offset 4
2F00 for the DIR file, that is the data object containing the Application
Identifier (AID)
or the AID of the application on the card itself, which will select the area of
memory that contain application specific data.
Some files have been dropped from the specification, but they were included in
previous versions of the specs:
2FF0 the protection memory (4 bytes for SLE4432/4442 and 128 for SLE4418/28)
2FF1 the security memory (1 byte containing the error counter in a SLE4442
or SLE4428)
>From reading the white paper for PCSC Version 2.0 available at
www.pcscworkgroup.com I have the strong impression, that the next version of
PCSC will define support for synchronous cards implemented as in the MCT
specifications. In such a case, any synchronous card supported
by the reader would have a special piece of code in the IFD Handler that would
translate some of the ISO7816-4 command APDUs into specific card commands for
memory cards.
The benefit is obvious: An application (like for example SKAM) would be able to
support any kind of card, just by using the appropriate command APDU.
Furthermore a generic SSP for memory cards would enable easy access and
integration into the PC/SC architecture.
Any comments welcome....
Andreas
P.S. I will try to connect the proprietary IFD Handler extensions to the CT-API
interface in the ECO driver to enable access to memory cards using the
functions defined by Dave, but I recommend an extension to PCSC lite to
integrate support for synchronous cards in the SCardTransmit() function call.
--
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
***************************************************************
