Extended APDUs and T=0/1 communication protocols

Question

I have a JCOP V2.4.2 R3 java card that it is mentioned in its datasheet "The card support both T=1 and T=0 communication protocols"

I have also an ACR38 smart card reader that it support both T=0 and T=1 protocols. (I have T=0 communication with one card successfully and T=1 communication with this card successfully.)

I wrote the below program and upload it on the card to send and receive extended APDUs:

package extAPDU;

import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.ISOException;
import javacardx.apdu.ExtendedLength;

public class ExAPDU extends Applet implements ExtendedLength {

    private ExAPDU() {
    }


    public static void install(byte bArray[], short bOffset, byte bLength)
            throws ISOException {
        new ExAPDU().register();
    }

    public void process(APDU arg0) throws ISOException {
        short number = arg0.setIncomingAndReceive();
        arg0.setOutgoingAndSend((short)0, (short)(number+7));
    }

}

In the CAD-side I used python scripts to send different APDUs to card. The questions is:

1- Why I can't start communication with T=0 protocol(While it is mentioned that the card support this protocol):

The python script:

from smartcard.scard import *
import smartcard.util
from smartcard.System import readers
from smartcard.CardConnection import CardConnection

r=readers()
print r
connection =r[0].createConnection()
connection.connect(CardConnection.T0_protocol)

normalCommand=[0x00,0xa4,0x04,0x00,0x06,0x01,0x02,0x03,0x04,0x05,0x06]
data,sw1,sw2=connection.transmit(normalCommand)
print "SW for Normal Command:"
print data,hex(sw1),hex(sw2)

Output:

>>> ================================ RESTART ================================
>>> 
['ACS CCID USB Reader 0']

Traceback (most recent call last):
  File "C:\extAPDU.py", line 13, in <module>
    connection.connect(CardConnection.T0_protocol)
  File "D:\PythonX\Lib\site-packages\smartcard\CardConnectionDecorator.py", line 54, in connect
    self.component.connect(protocol, mode, disposition)
  File "D:\PythonX\Lib\site-packages\smartcard\pcsc\PCSCCardConnection.py", line 118, in connect
    raise CardConnectionException('Unable to connect with protocol: ' + dictProtocol[pcscprotocol] + '. ' + SCardGetErrorMessage(hresult))
CardConnectionException: Unable to connect with protocol: T0. The requested protocols are incompatible with the protocol currently in use with the smart card. 
>>> 

2- Why the card doesn't work fine with the Select APDU commands in the extended form on the T=1 protocol :

The python script:

from smartcard.scard import *
import smartcard.util
from smartcard.CardConnection import CardConnection
from smartcard.System import readers

r=readers()
print r
connection =r[0].createConnection()
connection.connect(CardConnection.T1_protocol)

normalCommand=[0x00,0xa4,0x04,0x00,0x00,0x00,0x06,0x01,0x02,0x03,0x04,0x05,0x06]
data,sw1,sw2=connection.transmit(normalCommand)
print "SW for Normal Command:"
print data,hex(sw1),hex(sw2)

Output :

>>> ================================ RESTART ================================
>>> 
['ACS CCID USB Reader 0']
SW for Normal Command:
[] 0x67 0x0
>>> 

I think I misunderstood this concept and I mixed up Extended APDUs with T=1 and T=0 protocols!

Every T=1 compatible smart card, can send and receive Extended APDUs? and we can't send and receive extended APDUs over T=0 protocols? If we want to send Extended SELECT APDU commands to the Security Domain, the SD must implement ExtendedLength interface?

For an Extended APDU transmission what are the requirements?

1. A T=1 compatible card reader
2. A T=1 compatible smart card
3. An applet that implemented ExtendedLength interface

Is it right?

I am really confused about Extended compatibility and T=0/1 compatibility in smart cards. Any light will appreciated.

Note that, I can successfully send Extended APDUs to the above applet with T=1 protocol!

Answer 1

Q1: Changing Protocol is possible. Information which protocols are supported by hte card is transceived via ATR/ATS. The terminal then can decide which one to use. So it is dependend from your Terminal shell if protocols are selectable or not. For JCOP Shell this is /change-protocol. However is do not recommend T=0 in general.

Q2: If you start the card via sending ATR/ATS the Card Manager is active which only supports Global Platform commands. Global Platform does not support Extended Length what so ever. By sending a Select command(which must be simple length because of that) the applet gets selected and that actual Select commands is also forwarded into your Applet's process() method (and can be detected by the selectingApplet() method). Now that you are in your Applet you can send as many Extended Length commands as you want. You can bypass the initial Non-Extended-Length-Select by installing your applet as default selected.

Answer 2

Java Card itself already handles the T=0 specific commands, so a T=0/T=1 APDU will look pretty much the same to a programmer. There are of course differences, but those are pretty well explained in the APDU class.

T=0 is a byte based protocol while T=1 uses frames underneath. Most cards with T=0 don't support extended length. Note that to get extended length functionality that the javacardx.apdu.ExtendedLength tagging interface needs to be implemented.

JCOP cards can be configured to use T=0/T=1/T=CL and others. You need however to have access to the card (and probably the user manual) to configure the cards. The Java Card API doesn't contain any commands to change the support for protocols or the transport protocol parameters within the cold or warm ATR.

You are correct with regards to the requirements for extended length. Note that card readers not capable of T=1 will probably be hard to find by now. T=0 is an old protocol, T=1 should be preferred.

Answer 3

It is not the case that every ISO-compatible card can send and receive extended APDUs. It is very much an optional feature. What version of JCOP does your card implement?

As for T=0 vs T=1: when a card indicates support for both protocols, it is the card reader that decides which one to use. If it's a PC/SC card reader, there is not much you can do about this.

Updated to add: Now you say that you can successfully send extended APDUs to the above applet. So it appears that the card does support extended APDUs. But perhaps the built-in SELECT command doesn't allow them if Le is absent, because there is no use case for them.