1

I want to re-develop new desktop application to read information from EMV smart card and I have logs from previous (working) application.

Assume, there is an app with AID = 44 44 44 44 44 44 44 44 (DDDDDDDD) in the EMV smart card.

I am sending APDU command: 00 A4 04 00 08 44 44 44 44 44 44 44 44 00 and getting timeout exception (timeout = 60s).

I tried to send APDU command: 00 A4 04 00 08 44 44 44 44 44 44 44 44 and got response code = 61 37.

I tried to select file 1PAY.SYS.DDF01, immediately got response = 6a82 (it is right).

SparX
  • 271
  • 2
  • 6
  • 15

2 Answers2

5

Error code 61XX means you will receive your data after calling Get Response command with Le=XX:

Example:

--> 00 A4 04 00 08 44 44 44 44 44 44 44 44
<-- 61 37
--> 00 C0 00 00 37
<-- some data of length 0x37 and status code 90 00.

Related question: About Get Response command in javacard

Docs by Oracle:

There may be several APDU connections open at the same time using different logical channels with the same card. However, since APDU protocol is synchronous, there can be no interleaving of command and their response APDUs across logical channels. Between the receipt of the command APDU and the sending of the response APDU to that command, only one logical channel is active. For T=0 protocol, for case 4 and case 2 command APDUs the card may respond with '61 XX' or '6C XX'. These special cases MUST be handled by the implementation in the following manner:

'61 XX': The implementation MUST send GET RESPONSE to the card to get the response data before any other command is sent. '6C XX': The implementation MUST resend the command after setting Le equal to XX received from the card before any other command is sent.

In both the cases discussed above, the implementation MUST make sure that between sending the command APDU, receiving status word '61 XX' or '6C XX', and sending GET RESPONSE or resending the command APDU with Le set to XX respectively, there MUST not be any other APDU exchange on any logical channel with the card. In case the status word '61 XX' is received multiple times successively from the card, the implementation must accumulate all the response data received from the card before returning it to the J2ME application. J2ME applications MUST remain oblivious of the exchanges mentioned above and should only get the response received as a result of the above operations.

Community
  • 1
  • 1
vojta
  • 5,591
  • 2
  • 24
  • 64
  • 1
    Or very terse: This is T=0 protocol, you must explicitly fetch the card response, with the length indicated. – guidot Jul 02 '15 at 09:27
  • @guidot Could you give more details? – SparX Jul 02 '15 at 12:57
  • @vojta I tried your example, but I am getting timeout exception after 00 C0 00 00 37. – SparX Jul 02 '15 at 13:00
  • @SparX Hmm, so it is a more complicated issue... Could you try it with another reader? – vojta Jul 02 '15 at 13:02
  • 1
    Half-duplex is no difference to T=1; the most important distinction is character-oriented (T=0) vs. block-oriented (T=1). The Get Response looks okay (see ISO 7816-3 for T=0 protocol, and part 4 for the Get Response command). Timeout instead of a error status surely indicates, that something is wrong on very low level. – guidot Jul 02 '15 at 13:35
  • @guidot Let me give you some more information. I am using ICT 3k5 card reader. On Ubuntu platform using Java8 via RXTXserial.jar+RXTXserial.so. I have logs from Windows with this card reader. That old application sends 00 A4 04 00 08 44 44 44 44 44 44 44 44 **00** command once and gets response with data. – SparX Jul 02 '15 at 14:00
  • 1
    Don't know the reader; if you are using Java: one possible pitfall is, that you code the LC byte (*08* before 44..44) yourself. Java computes and adds this itself from the byte array for the command data field. – guidot Jul 02 '15 at 14:22
1

I changed library from RXTXserial to JSSC and it solved my problem. Now I get responses without GET RESPONSE request. Thank you guys.

SparX
  • 271
  • 2
  • 6
  • 15