Re: MUSCLE Bull PC/SC Test Card

2000-03-11 Thread David Corcoran 

Hi,

After looking through the winscard portion of pcsc-lite I realized that I
was just passing a suggested return size to the IFD_HANDLER.  When the
Transmit function returns in the IFD_HANDLER PC/SC actually returns back to
the application whatever receive length that the IFD_HANDLER gets from the
card.  So, it if there are issues in 4 byte commands or Case 4 commands
this is probably in the IFD_HANDLER for a particular driver.

My guess is that if there are problems with Case 4 APDU's then it is
probably that the IFD HANDLER is using the suggested receive size from pcsc
instead of calculating it's own return length.  So the way it should work
is that the IFD Handler should be  adding the extra 0x00 on Case 1 commands
for T=0 and it should be handling the Case 4 commands.  I won't have to
make any changes to pcsc-lite since it just passes a suggested length to
receive but then uses whatever is received from the IFD HANDLER.

I'm going to work on a better IFD HANDLER skeleton and post it on the site
next week that will take care of this.

Best Regards,
Dave


***
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
***

MUSCLE Bull PC/SC Test Card

2000-03-09 Thread David Corcoran 

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
bc a0 00 00

These are only 3 and 4 byte commands.  Any clues 

On the IBM card test there are these commands 

a4 a4 00
a4 a4 00 00
b6 42 00 40

On the Schlumberger there is

00 d6 00 00 - Is this a special case of update binary ?

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 ?

Dave


***
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
***

MUSCLE Bull PC/SC Test Card

2000-03-09 Thread Matthias Bruestle 

Mahlzeit


Dunno about the 3 byte command, but 4 bytes is the "normal" form
for Case 1 commands. They are transmittet in this form by T=1.
For T=0 the must be filled by a zero byte to 5 bytes.


Mahlzeit

endergone Zwiebeltuete

***
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
***

Re: MUSCLE Bull PC/SC Test Card

2000-03-09 Thread Andreas Schwier 

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
***