Thank you Amitabh
In the ISO7816-4 the 4-th case is split in two parts
as you said. The first part the command APDU , and
after this a GETRESPONSE. The first command APDU is
followed by an answer from the card, the answer can be
SW=90 00 or SW=61 XX.
I don't really understand, based on which factors
the JCRE responds to the host side with one status
word or the other.
I'm thinking about the Javacard APIs, for example
the suite: SetOutgoing (returns the number of bytes
that the host side expects from the card),
SetOutgoingLength(sets the length that the card wants
to send to the reader), and SendBytes.
So basically , and please correct me if I'm wrong,
in the 4-th case.
First the incoming data are all read. The card, only
when the applet developer calls the SetOutgoing
function, or when the process method terminates
without any call to a Outgoing function, at this
moment the card sends back the SW 90 00.
After this, the host side, or the reader sends an
apropiate GET RESPONSE command, and when the applet
developer calls the SetOutgoingLength, then the card
responds with a TPDU containing a SW 61 XX. After this
the host side again sends an TPDU with another GET
RESPONSE and in the 5-th byte of this GET RESPONSE the
host side sets the XX received in the second status
byte from the card.
After this second GET RESPONSE, the card starts
sending out the real bytes.
Again in the 4-th case, if the card calls first
the SetOutgoingandSend method, with no call to the
SetOutgoing, SetOutgoingLength, SendBytes, then the
card answers ( this is the first answer from the card
after it has received all the incoming bytes) with a
status word like SW 61 XX, and the host side replyes
with a GET RESPONSE with the 5-th bute set to XX, and
after this the card starts sending out the data.
Please correct me if I'm wrong.
Do you know any place on the internet, or any book,
where I could find information like this that I'm
talking about in this email.
Thank you!
--- Amitabh Pastore <[EMAIL PROTECTED]>
wrote:
> 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.
> >
> >
> >
>
>
__________________________________
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.
