Hi,

Case 4 APDU is broken in 2 TPDUs as in this case card receives as well as
well as sends out in a single command.

As there is no way as per ISO 7816 to tell the card how many bytes are being
sent in and how many bytes are expected back (remember this is in single
apdu). APDU can not have both the Lc and Le fields. Therefore it has to be
resolved at card reader end. In a case 4 APDU, card receives the APDU with
incoming data and processes the command. It then notifies to the reader ot
host, the number of bytes available as the response  (as per ISO and EMV
61xx). This response is then retrived usinga Get Response command.

Now comes the real issue. There is no standard way that all readers handle
this situation. Some of the readers automatically issue the Get Response
command upon receiving 61xx from card. On the other hand, some readers
simply pass on this SW1SW2 to the external applications and it is duty of
external application to issue a Get Response command.

Therefore it is advisable to have built the logic in the application to
decide whether to issue a Get Response or not based on the SW1SW2.

There are tools to see the serial in/out activity but the one I have is
proprietary.


Thanks,
Amitabh

----- Original Message ----- 
From: "Klauss Kirkegard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 30, 2004 10:58 AM
Subject: [OCF] TPDU/APDU


>
>   Hello
>
>   I'm currently trying to understand the difference
> between the TPDU and APDU protocols
>
>    I have read some ISO materials, and I understood
> that mainly the APDU 4-th case (when data are incoming
> and data are outgoiong) is not mapped directly onto
> the TPDU protocol.
>   As I have understood, the 4-th case is mapped into
> two TPDUs, one normal Command APDU with no LE byte,
> only the LC and the incoming data, and after this one
> , a GET RESPONSE Command APDU with the LE as P3.
>
>    I don't understand why this case can't be mapped
> onto a singel TPDU, why the JCRE(for example) cannot
> read all the incoming bytes of and 4-th case APDU,
> including the LE, do you know? Because with a case 2
> command it has no problem, the APDU are mapped
> directly onto the TPDU.
>      I managed to get the JCardManager of my Gemplus
> toolkit working, and I managed to authenticate and
> send some commands to the card, as the GET STATUS
> command.
>     I want to ask you how can I see the TPDUs that are
> sent from the host to the reader? because I assume
> that this level of transforming the APDU into TPDU(or
> more than one TPDU if is neccesary) is not done into
> the reader, I assume that this is done on the host
> side. Can you tell me where this translation is taking
> place? I haven't had a chance to write my own host
> side application yet. And on the card side as well,
> the incoming messages are TPDUs, so it's the
> responsability of the JCRE to translate them into
> APDUs?
>
>   Do you know any serial line sniffer(on linux or
> Windows), or any way that I can see this incoming and
> outgoing TPDUs, for me to fully understand the way the
> card , the reader and the host side communicate.
>
>    Thank you very much!
>
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends.  Fun.  Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
>
>
> ---
> > Visit the OpenCard web site at http://www.opencard.org/ for more
> > information on OpenCard---binaries, source code, documents.
> > This list is being archived at http://www.opencard.org/archive/opencard/
>
> ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
> ! to
> !                           [EMAIL PROTECTED]
> ! containing the word
> !                           unsubscribe
> ! in the body.
>
>
>



---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/

! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
!                           [EMAIL PROTECTED]
! containing the word
!                           unsubscribe 
! in the body.

Reply via email to