Smartcard Lib for Arduino compat. boards / Discussion / General Discussion: Problem while sending apdu command

alexdr75 - 2013-10-02

Hello,
i'm trying to sending apdu commmand to a ISO7816 smartcard, but i don't receive the correct data.

The apdu command are:
1. 00 A4, 08 00 04 11 00 11 02 00 (select file from 1100 to 1102)
command.cla = 0x00;
command.ins = 0xA4;
command.p1 = 0x08;
command.p2 = 0x00;
command.data_buf = data;
command.data_size = 6;
command.resp_size = 0x02;

data[0] = 0x04;
data[1] = 0x11;
data[2] = 0x00;
data[3] = 0x11;
data[4] = 0x02;
data[5] = 0x00;

result = sc.sendAPDU(&command,true);

00 B0 00 00 FF (read 255 bytes of that file)
command.cla = 0x00;
command.ins = 0xB0;
command.p1 = 0x00;
command.p2 = 0x00;
command.data_buf = data;
command.data_size = 1;
command.resp_size = 0xFF;

data[0] = 0xFF;

result = sc.sendAPDU(&command, false);

The problem is that the first command takes a long time to be performed, while the second returns 0 bytes.
What am I doing wrong?

I'm using a Arduindo Mega rev 3 with a sparkfun smartcard adapter.
The setting in my code are

define SC_C2_RST 7

define SC_C1_VCC 22

define SC_C7_IO 10

define SC_C2_CLK 11

define SC_SWITCH_CARD_PRESENT 8

thanks a lot
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- angus71 - 2013-10-06
  
  Hi Alex,
  
  Sorry for the late answer, but I wasn’t able to read any mail for the last few days ;-.).
  
  To get to the problem I’ve some questions.
  
  You based your code on the apdu_t0_communication example and received a valid ATR?
  
  Can you please provide the ATR you received from the Smart Card?
  
  Did you change the frequency used in the activate process from the CLK_1MHZ to a higher value (CLK_4MHZ leads to problem with some cards)?
  
  I’ve seen this kind of problems. The main reason for this might be a problem with the wiring, but currently of this looks okay (I didn’t do a deep check, as the defines you gave look okay) or the card itself does request’s a different timing with the ATR. Currently no timing adaption based on the received ATR is implemented, but it can be achieved by tweaking some of the defines ;-.).
  I’ve also seen cards, which didn’t implement the required heartbeat function, if a command takes longer than the timeout, mostly JavaCards, which do "heavy" computation stuff (Signing etc.)
  
  Hope we can get your project up and running
  
  Angus71
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

alexdr75 - 2013-10-15

Hi Angus,
even I can not check email every day.
I have not tried to change the clock frequency (where can I change it?)
The atr received is the correct one (I did a comparison with that received from a pcsc reader in windows), although I had to insert a delay of 100 ms before the instruction request it.

Thanks a lot
Alex

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

alexdr75 - 2013-10-17

Hi Angus,
I found the card specifications and in the section "communication protocols" is indicated:

The card has to support the protocol T = 1. Also it may support T = 0, but
T = 1 protocol has to be used During the use phase.
The ISO standard PPS procedures described in [1] Applies, with T = 1 as first
proposed protocol.
Supported communication speeds are at least:

bps
with CLK=3.5712MHz F D PPS1 ETU dur.
in CLK cycles

9600 372 1 01h or 11h 372

115200 372 12 08h or 18h 31

The maximum communication speed (115200bps @ 3.5712MHz) should be
used during the use phase to allow optimal performances.

Can you replicate this in your code?
I attach the pdf of the card specifications

Thanks
Alex

Last edit: alexdr75 2013-10-17

CNS Functional Specification 1.1.6_02042011.pdf

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- angus71 - 2013-10-17
  
  Hi Alex,
  
  Thanks for sharing the data, I will check if I can manage to update the code accordingly ;-.) ... I've will try to update this during the weekend.
  
  As you've asked in the previous post .. You can change the communication speed during the activate process. See activate() in SCLib.h. The third parameter changes the clk frequency (CLK_1MHZ, CLK_2MHZ, CLK_2DOT5MHZ and CLK_4MHZ), but be careful using 4MHz as this might lead to communication problems. For 4MHz to work in a "secure" fashion, I need to change the communication to assembler or Hardware support is needed ;-.)
  
  Regards
  
  Angus
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- angus71 - 2013-10-23
  
  Hi Alex,
  
  While reading the provided document I stumbled upon two things ...
  
  First the spec. request the user to actually do a PPS procedure. Did you actually did this to activate the T1 protocol required for the actual communication?
  I've made some test with a OpenPGP card, which only talks to me after I've selected the required protocol via PSS.
  
  Next point, if no PPS procedure is actually required and the used protocol is T1, than the sendAPDU(...) command won't help you, as a card in T1 expects the APDU in a different format.
  
  I think the communication is up and running, but the card expects commands in different format. The T1 commands are currently not supported, but can be send via the sendBytes(..)/receiveBytes(..) functions. If you need some condensed information regarding the PPS and T1 protocol you can google the Application Note AN1370A from Microchip "AN1370 Microchip" (I'm not sure if I can put the Application note here as an attachment, but you should be able to find it right away ;-.) ).
  
  Can you try to send T1 protocol packages to the card and see how it reacts?
  
  Regards
  
  Angus
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

alexdr75 - 2013-10-24

Hi Angus,
thanks for your support.
Actually i don't know if my pcsc reader send a PPS procedure to the card.
I will try via the sendBytes/receiveBytes

Regards
Alex

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

alexdr75 - 2013-10-24

Hi Angus,
i tried with sendBytes and receiveBytes, but i don't get a correct answer (bytes received = 0). Have you an example of how to send the command apdu through this functions with T=1 protocol?

Thanks a lot
Alex

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

angus71 - 2013-10-24

Hi Alex,

Okay. I check if I can generate a basic example from former openpgp card tests. This might take at least a day or two as my daytime job currently is a little bit stressy ;-.) but if nothing bad happens I will get back to you during the weekend.

Did you put you APDU commands into a T1 Information Block, when you tried to send via sendBytes(..)?

Regards
Angus

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

angus71 - 2013-10-26

Hi Alex,

As promised you can find an experimental support of the T1 protocol in the current trunk version in the SVN (r27). There is also example code provided. This is more of a documentation release, as I'm currently not so happy with the design of the T1 API. There might be changes in the future, but for testing with your setup it should be usable ...
At least the changeIFS(..) function should work with your card. Can you please test the code from the SVN with your setup?

Regards

Angus

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

alexdr75 - 2013-10-31

Hi Angus,
thanks for your support.
I'll try this example as soon as possible.

thanks again
Alex

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

alexdr75 - 2013-10-31

Hi Angus,
I did a test and it seems to work. The function changeIFS returns the value "OKAY (Set to 0x20)", however any command apdu sending (using the sendInformationBlock method as in your example) returns the dump 00 | 00 C3 01 02 C0

is that correct?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- angus71 - 2013-10-31
  
  Hi Alex,
  
  Yes this looks correct as the card is actually requesting a wait time extension, which means that it is needing a little bit more time for completing the request ...
  
  The received data is a System Block
  00 - Node Address
  C3 - PCB Field "Request waiting time extension - (only from smart card)"
  01 - Length Field (One Byte)
  02 - Data
  C0 - EDC (Checksum)
  
  Currently no T1 protocol handling takes place, this means that all protocol realted stuff needs to be implemented via. receiveBytes(...) etc.
  
  I'm currently working on a more complete T1 stack, so that the user just sends APDU requests and gets the requested data, but this might take a little as the T1 protocol is a lot more complex than the T0.
  
  Do you have tight schedule on your project?
  
  Regards
  
  Angus
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

alexdr75 - 2013-11-04

Hi Angus,
I do not rush, so take all the time you need

thanks again
Regards

Alex

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

alexdr75 - 2013-11-07

Hi Angus,
I have other information that may interest: I ran a test on linux environment (using raspberry) and the result of the function pcsc_scan is as follows

TThu Nov 7 09:57:28 2013
Reader 0: AseIIIeUSB 00 00
Card state: Card inserted,
ATR: 3B DF 18 00 81 31 FE 7D 00 6B 15 0C 01 81 01 11 01 43 4E 53 10 31 80 E8

ATR: 3B DF 18 00 81 31 FE 7D 00 6B 15 0C 01 81 01 11 01 43 4E 53 10 31 80 E8
+ TS = 3B --> Direct Convention
+ T0 = DF, Y(1): 1101, K: 15 (historical bytes)
TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
TC(1) = 00 --> Extra guard time: 0
TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1
TA(3) = FE --> IFSC: 254
TB(3) = 7D --> Block Waiting Integer: 7 - Character Waiting Integer: 13
+ Historical bytes: 00 6B 15 0C 01 81 01 11 01 43 4E 53 10 31 80
Category indicator byte: 00 (compact TLV data object)
Tag: 6, len: B (pre-issuing data)
Data: 15 0C 01 81 01 11 01 43 4E 53
Mandatory status indicator (3 last bytes)
LCS (life card cycle): 10 (Proprietary)
SW: 3180 (Error not defined by ISO 7816)
+ TCK = E8 (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B DF 18 00 81 31 FE 7D 00 6B 15 0C 01 81 01 11 01 43 4E 53 10 31 80 E8
Italian healtcare card (TS) National Service Card (CNS)
Carta Regionale dei Servizi - Regione Lombardia
Tuscany TS-CNS http://www.regione.toscana.it/cartasanitaria

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Fatih GÜNGÖR - 2018-06-15

Post awaiting moderation.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Problem while sending apdu command

Smartcard access lib for Arduino based boards

Forums

Help

Problem while sending apdu command

define SC_C2_RST 7

define SC_C1_VCC 22

define SC_C7_IO 10

define SC_C2_CLK 11

define SC_SWITCH_CARD_PRESENT 8

bps with CLK=3.5712MHz	F	D	PPS1	ETU dur. in CLK cycles
9600	372	1	01h or 11h	372
115200	372	12	08h or 18h	31

Problem while sending apdu command

Smartcard access lib for Arduino based boards

Forums

Help

Problem while sending apdu command document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

define SC_C2_RST 7

define SC_C1_VCC 22

define SC_C7_IO 10

define SC_C2_CLK 11

define SC_SWITCH_CARD_PRESENT 8

Problem while sending apdu command