Martin,
I found your note very interesting, I think this detail of OCF is worth
some discussion. Does your company have a CardTerminal implementation that
behaves in the way you mentioned ?
The current situation is that OCF does not define whether CardTerminals
must handle T=0 Case 4 etc. It would be very interesting to know how
CardTerminal implementations of other terminal behave in this regard and
why they behave the way they do.
>The statment by Thomas Schaeck is clearly not representing what
>ISO is defining as an APDU (He refers clearly only to the
>transport layer).
In section 7.1 of ISO/IEC 7816-4, the "GET RESPONSE command APDU" and the
"GET RESPONSE response APDU" are mentioned and in Annex A ISO/IEC 7816-4
says "GET RESPONSE command TPDU", so ISO allows for two interpretations. It
seems I chose the one that was more appealing to me.
>To our understanding the Card Terminal driver must hide this
>implementation totaly from the Card Service.
I assume you mean the protocol implementation on the card, i.e. T=0, T=1 or
some kind of T=14. Hiding the card protocol completely would be nice for
card service programmers. Going this direction would require that ALL
CardTerminal implementations behave the same way, that means all
implementations which simply return the "61XX" or "6CXX" as Jon Barber
mentioned would need to be changed.
>It is anyhow unclear who is talking in T=0 to whom. The
>communication between card and terminal may be in T=0 but the
>Terminal will talk with the Host in T=1 (in this case the
>Terminal may already handle the 61 XX by itself) or viceversa.
I was assuming a scenario where the card talks T=0 to the reader. I was
making no assumtions about the protocol that the terminal uses to talk to
the host. It may be T=1 or TLP or something else.
>The statement by Schaeck that this behaviour is needed to handle
>wrongly programmed T=1 cards is totally ununderstandable. The
>Terminal Driver should know in which protocol he is talking to the
>Terminal and behaive accordingly (Ignore 61 XX in case of T=1).
That was a bad example that I wrote in a hurry, obviously you are right,
the terminal can surely tell when to ignore the 61XX.
>Also we feel that the OpenCard Framework should be a user
>interface to talk to SmartCards from JAVA and is not needed nor
>usable as a debug tool to develop and test transport protocol
>implementations on SmartCards.
I agree that OCF should be - and I think it is - a user interface to
comfortably use smart cards from Java applications. Applications would most
likely use CardServices for this purpose. I also agree that OCF is not
appropriate for testing transport protocol implementations on a low level.
However, I think it can be used to test the APDUs of a smart card for
correct behavior. You can easily write a test program that uses the
PassThruCardService to send long sequences of command APDUs to a card and
check whether it returns the expected response APDUs. It would be good, if
the correct bahaviour of the GET RESPONSE command could also be tested by
such a test program. If the GET RESPONSE command is sent implicitly by all
terminals after otaining 61XX from a T=0 card, this would not be possible.
Best Regards,
Thomas Schaeck
IBM Pervasive Computing Division - Smart Card Solutions
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] on 14.04.99 15:10:17
Please respond to [EMAIL PROTECTED]
To: Thomas Schaeck/Germany/IBM, [EMAIL PROTECTED]
cc:
Subject: Betr.:: Re: [OCF] Card Terminal behaviour when SW1=0x6c
The statment by Thomas Schaeck is clearly not representing what ISO is
defining as an APDU (He refers clearly only to the transport layer).
To our understanding the Card Terminal driver must hide this
implementation totaly from the Card Service. It is anyhow unclear who
is talking in T=0 to whom. The communication between card and terminal
may be in T=0 but the Terminal will talk with the Host in T=1 (in this
case the Terminal may already handle the 61 XX by itself) or
viceversa.
The nice feature of the OpenCard Framework is that you can write Card
Services which will work without having to deal with implementatiomn
details. The APDUs (C-APDU and R-APDU) are protocol independent and
the mapping of TPDUs to APDUs for T=0 is defined in ISO/IEC 7816-3 and
7816-4:
To our understanding a good card terminal driver should also perform
the re-issuing of commands in T=0 case 2 when the card responds with
6C xx. This is not mandatory as of ISO but should be for OpenCard to
quarantee protocol independence.
The statement by Schaeck that this behaviour is needed to handle
wrongly programmed T=1 cards is totally ununderstandable. The Terminal
Driver should know in which protocol he is talking to the Terminal and
behaive accordingly (Ignore 61 XX in case of T=1).
Also we feel that the OpenCard Framework should be a user interface to
talk to SmartCards from JAVA and is not needed nor usable as a debug
tool to develop and test transport protocol implementations on
SmartCards.
If the philosophy of OpenCard is not to be a transparent API layer for
communication with a SmartCard we feel that it is unusable and should
be replaced.
Regards
Dr. Martin Merck
Giesecke & Devrient GmbH
____________________________ Antwort-Abtrennung
________________________________
Betreff: Re: [OCF] Card Terminal behaviour when SW1=0x6c
Autor: MIME:[EMAIL PROTECTED] bei INTERNET
Datum: 14.04.99 10:12
Recently, there was some discussion about how to handle the T=0 protocol in
OpenCard, or to be more exact, how to handle T=0 Case 4. This is the case
where the card indicates that its result has to be obtained by sending a
subsequent GetResponse command. The return code indicating this case is
0x61 XX, where XX is the length of the response to be retreived.
When designing the OpenCard Framework, we defined the card terminal layer
role in communication with cards as follows: The card terminal layer
transparently sends command APDUs to smart cards and returns the response
APDUs. It does not interpret or modify the transmitted APDUs in any way.
It is important to have such a transparent communication path. Only some
examples: How would a card applet programmer be able to test how a T=0 card
reacts if a wrong GetResponse command is sent to the card after obtaining
61 XX if the card terminal driver handles this automatically ? What if
someone wrote an Applet for a T=1 JavaCard that returns 61 XX due to a
programming error ?
All interpretation of APDUs is the task of the card service layer. Card
services have the responsibility of handling the application protocol
required by the card - even if the application protocol has a special case
due to the missing support for two way flow in T=0.
Best Regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division - Smart Card Solutions
E-mail: [EMAIL PROTECTED] Tel.: ++49-7031-16-3479 Fax.:
++49-7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
[EMAIL PROTECTED] on 14.04.99 05:24:43
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Thomas Schaeck/Germany/IBM)
Subject: Re: [OCF] Card Terminal behaviour when SW1=0x6c
In einer eMail vom 13.04.99 17:15:10 MEZ, schreiben Sie:
<< Thema: [OCF] Card Terminal behaviour when SW1=0x6c >>
Hi,
in my eyes, the transport layer of the CardTerminal implementation
- i.e. the clases that manage the exchange of APDUs according to an
ISO-7816 protocol T=x - is responsible for handling the '0x6C 0xLe' case,
where 0xLe gives the correct number of bytes generated by a card command.
A CardServivce (running somewhere between OSI presentation and application
layer) should be isolated as much as possible from protocol specific tasks.
In general, it must work with every card 'understanding' the command APDUs
transmitted, whether speaking T=0 or T=1.
Best regards.
----------------------------------------------------------------------
Markus A. Stulle - Schlei�heimer Stra�e 70 [EMAIL PROTECTED]
D-80797 Muenchen - Germany
Tel./FAX: (+89) 520 59 001, GSM: (+171) 213 - 70 84
GSM-FAX: (+171) 214 - 84 74, GSM-Data: - 86 74
AOL-FAX: (+40) 36 03 - 02 00 16
'Java Madman' Current Java version is: Java 2
Available at: http://java.sun.com/products/jdk/1.2
-----------+===+-----------------------------------------------------
-
> press |ESC| key once to abort program or twice to continue! <
-----------+===+-----------------------------------------------------
-
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
---------------------------------------------------------------------------
--
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of
the
message.
Rich Text Format
