On Don, 09 Mär 2000, you wrote:
> Hello,
> The following command came from IFD_TEST.EXE on Windows.
> Does anyone know what the following command does on the Bull PC/SC test card ?
>
> bc c4 00
This clearly violates ISO7816/4. It is either a test to very the handling of
invalid APDUs, or is a proprietary Bull command.
> bc a0 00 00
Case 1 command APDU, but otherwise probably Bull proprietary.
>
> These are only 3 and 4 byte commands. Any clues ????
>
> On the IBM card test there are these commands ....
>
> a4 a4 00
Maybe just test to verify handling of invalid APDUs ?
> a4 a4 00 00
SELECT command with secure messaging, but should return error from the card as
file id is missing.
> b6 42 00 40
IBM internal case 1 command ?
>
> On the Schlumberger there is
>
> 00 d6 00 00 - Is this a special case of update binary ?
Could be, but I assume it is a negative test.
>
> Any clues what each of these command is supposed to do and how PC/SC is
> supposed to handle them since they are under 5 bytes ?
ISO7816/4 defines command and response APDUs to be used between the application
and the card. This APDU format is independent of the transmission protocol, it
works for T=0 and T=1:
Case 1: CLA INS P1 P2
SW1 SW2
Case 2: CLA INS P1 P2 Lc <Data>
SW1 SW2
Case 3: CLA INS P1 P2 Le
<Data> SW1 SW2
Case 4: CLA INS P1 P2 Lc <Data> Le
<Data> SW1 SW2
Using this format, an application can be independent of the transmission
protocol used. Still any intermediate layer in the protocol can determine from
the length of the APDU and the Lc/Le field the format of the command.
The transmission protocol must map the command APDU to a command
TPDU and convert a received response TPDU to a response APDU. For T=1 this is
trivial, as both formats are identical. Exception to the rule is a case 1
command, where a P3=00 needs to be added. For T=0 this is a little bit more
complicated:
First T=0 is not capable of handling Case 4 APDU's directly, instead the
command is send as a Case 2 command, whereby a subsequent GET RESPONSE
command will fetch the result from the card. In an ideal world, this would be
done by the protocol stack in the IFD directly. Unfortunately, there are some
cards around, that have problems with this automatic GET REPONSE mode, so it
should at least be possible to disable such a feature.
T=0 defines the TPDU to be
Case 1: CLA INS P1 P2 P3=00
SW1 SW2
Case 2: CLA INS P1 P2 P3=Lc <Data>
SW1 SW2
Case 3: CLA INS P1 P2 P3=Le
<Data> SW1 SW2
as said before a Case 4 command would be handled like
Case 4: CLA INS P1 P2 P3=Lc <Data>
SW1 SW2
CLA INS='C0' P1='00' P2='00' P3=Le
<Data> SW1 SW2
Things get even more complicated with the extended length fields, but I haven't
seen a card with T=0 that uses extended length fields. For T=1 it work O.K.
So, PC/SC should do nothing with these APDU's expect to pass them to the
IFD handler. The IFD handler needs to do the mapping and shall return an error
if he is not successfull.
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
***************************************************************
