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:
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:
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 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:
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:
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:
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:
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:
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:
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:
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
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);
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
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.
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
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
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:
with CLK=3.5712MHz
in CLK cycles
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
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
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
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
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
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
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
Hi Angus,
thanks for your support.
I'll try this example as soon as possible.
thanks again
Alex
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?
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
Hi Angus,
I do not rush, so take all the time you need
thanks again
Regards
Alex
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