Menu

Problem while sending apdu command

alexdr75
2013-10-02
2013-11-07
  • alexdr75

    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);

    1. 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

     
    • angus71

      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.

      1. You based your code on the apdu_t0_communication example and received a valid ATR?
      2. Can you please provide the ATR you received from the Smart Card?
      3. 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

       
  • alexdr75

    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

     
  • alexdr75

    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
    FDPPS1ETU dur.
    in CLK cycles
    9600372101h or 11h372
    1152003721208h or 18h31

    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
    • angus71

      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

       
    • angus71

      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

       
  • alexdr75

    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

     
  • alexdr75

    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

     
  • angus71

    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

     
  • angus71

    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

     
  • alexdr75

    alexdr75 - 2013-10-31

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

    thanks again
    Alex

     
  • alexdr75

    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?

     
    • angus71

      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

       
  • alexdr75

    alexdr75 - 2013-11-04

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

    thanks again
    Regards

    Alex

     
  • alexdr75

    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

     
  • Fatih GÜNGÖR

    Fatih GÜNGÖR - 2018-06-15
    Post awaiting moderation.

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.