T1 support

[Fab19]

Hi Angus,
first thanks for your work, it allowed me to start interacting with a 7816 SC.
I have some troubles with T1 protocol. I tried to follow other discussions and implement the suggestions there to exchange data with the card but still with no complete success. Did you had time to implement some additional feature of that protocol?
thanks

[angus71]

Hi Fab19,

As you might have seen there is a basic set of T1 functions available (Like calcEDC() and sendAPDU(), just activate the APDU_SUPPORT define) so more or less you should be able to create the basic T1 packets and communicate with a T1 card.

But as the "complete" T1 communication more or less requires a "communication stack" on the software side (Block Tranfer etc), it might be quite hard to do a complete communication.

What are the problems you are facing?

With kind regards

Angus

[Fab19]

Hi Angus, thanks for your response. I hope you're willing to read everything below ...

I did the following things:
1. I parsed the ATR I'm getting from the card. I'm getting a TA1 value of 0x18 and TA3 of 0xfe.
2. I added code to send a PTS to the card. The PTS message is echoed successfully; form now on I'm using _etu = 31, and modify calculations for _wwt and _max_wwt using a value of 12 for D (this is also due to TA1). Also, IFSI should be 0xfe.
3. Doing this the ChangeIFS() method fails; the card does not respond to it.
4. Trying a "Select file" request to the card, I'm getting those bytes in response:
0x00 0x41 0x00 0x41
-> this look like a S-Block with a PCB saying "Request Change to Information Field Size" (from Microchip AN1370). But this is also saying that a block transfer is ongoing. But even echoing the message again there (your code contains a static variable, this should already take care of block re-sending), I don't see any answers to my initial command. And I also was not able to change the IFS (point 3).
5. I also tried a second way: change PTS using PTS1 value of 0x11 (default).
6. changeIFS is ok then.
7. Response to the command is 0x00 0xC3 0x01 0x02 0xC3 . This is already described in another thread of this discussion, but I didn't understood what to do exactly once I get this answer.

My idea is that I'm not changing correctly the communications parameters after ATR, in "scenario1-4"; but I can't understand how to do that.

What do you think on my issues? Any suggestion?
Again, thanks for your attention

Fabrizio

[angus71]

Hi Fabrizio,

As you mention the changeIFS(), did you use the latest trunk version of the code as it contains a test implementation from some T1 functions?
(To be enabled with the "T1_SUPPORT" define)

Can you give me feedback about the sources you've used, with that information, I can dig deeper into the informations you provided ..

Maybe you can check if the following sniplet might give you a working setup, as it worked for me. After I changed the IFS with this code, I was able to communication with the card ...

  int received = 0;

  Serial.println("Waiting for Smartcard");

  while (!sc.cardInserted())
  ;

  Serial.println("Smartcard found");

  uint8_t data[256];

  // Just try to activate card
  received = sc.activate(data, 256);
  if ( received > 0) {
    //toggleDebugPin();
    dumpHEX(data, received);

    Serial.println();
    Serial.print("ETU : ");
    Serial.println(sc.getCurrentETU());

    delay(100);

    if ((data[0] & 0xF0) == 0x60) {
      // This is T0
      Serial.println("Protocol used T0");

    } else {
      // This is T1
      Serial.println("Protocol used T1");

      Serial.print("Sending IFSD ... ");

      // Create initial IFS command
      if (sc.changeIFS(0x00, 0xFE)) {
        Serial.println("OKAY");
      } else {
        Serial.println("FAILED");
      }

      delay(100);

      // Your code for further communication should be inserted
      // here ... (E.g sc.sendInformationRequest(...) etc

    }
  } else {
    Serial.println("Unable to identify card ... Please remove");
  }
  delay(2000);

  sc.deactivate();

  while (sc.cardInserted())
  ;

I've noticed, that without a proper IFS setup, I wasn't able to do any communication with the card I used. Also if your card is a JavaCard based one, it might be also problematic to setup a communication, as people reported problems with this kind of cards ..

With kind regards

Angus

[Fab19]

Hi Angus,
yes I used the latest revision, I confirm your code is ok: the changeIFS is successful. I'm connecting the Arduino board to the card without any other external hw (I mean, just using the schematic given here in the main section), btw. Using the code you just posted is ok (you just need to add the class name, sc befor DumpHEX is used). Taking from another one of your examples, but similarly to what I obtained before, if I try to go on adding this part:

// Your code for further communication should be inserted
// here ... (E.g sc.sendInformationRequest(...) etc
uint8_t data[255];
uint8_t bytes_received = 0;
uint8_t b = 0;
/*AID*/
data[b++] = 0x00; //b=1
data[b++] = 0xA4; //b=2
data[b++] = 0x04; //b=3
data[b++] = 0x00; //b=4
data[b++] = 0x06; //b=5
data[b++] = 0xD2; //b=6
data[b++] = 0x76; //b=7
data[b++] = 0x00; //b=8
data[b++] = 0x01; //b=9
data[b++] = 0x24; //b=10
data[b++] = 0x01; //b=11
data[b++] = 0x00; //b=12

Serial.print("Selecting AID D2 76 00 01 24 01 (OpenPGP) ... ");
sc.sendInformationBlock(0x00, data, b);

for(int i=0; i < 100; i++) {
  bytes_received = sc.receiveBytes(data, 255);
  if (bytes_received > 0) {
    break;
  }
  Serial.print(".");
}
Serial.println();
if (bytes_received > 0) {
    sc.dumpHEX(data, bytes_received);
}

And this is the putput obtained (from start):

Waiting for Smartcard
Smartcard found
00|3B DF 18 00 81 31 FE 7D 00 6B 15 0C 01 81 01 11 ';....1.}.k......'
10|01 43 4E 53 10 31 80 E8                         '.CNS.1..........'

ETU : 374
Protocol used T1
Sending IFSD ... OKAY
Selecting AID D2 76 00 01 24 01 (OpenPGP) ... 
00|00 C3 01 02 C0                                  '................'

at this point I'm thinking about the following two possibilities:
1.after reading ATR, sending a PTS request and then change communications parameter (_maxwwt, _etu ...), with ones obtained from ATR. Did you ever tried this?
2. another way: not sending any PTS, managing the "waiting time extension request" I'm getting here. I tried acknolwedging it. But the card is not responsive after that command.

thanks again
Fabrizio

thanks
Fabrizio

[angus71]

Hi Fabrizio,

I think the most promising way would be your second approach ..

Who did you try to aknowledge the "waiting time extension"?

Did you try to use one of the following code sniplets?

data[0] = 0x02;
sc.sendSupervisoryBlock( 0x00, true, (sblock_code_t)0x23, data, 1);

or

sc.sendSupervisoryBlock( 0x00, true, (sblock_code_t)0x23);

As I don't know if you have to answer with the "requested waiting time" I have given both forms (First with waiting time included, second without).

As I currently have no card, which actually requests "a waiting time extension" I can't check this myself, but I will try to check it also ...

I will extend the sblock_code_t enum to contain also the missing Supervisory block types. At least 0x23 for the waiting time extension response ..

I hope this helps in any way ...

With kind regards

Angus

Update: I had a little typo in the code and updated it. The id of the "watingtime extension response" is 0x23 and not 0x43 .. Sorry

[Fab19]

Hi Angus,
your last update solved the issue; using the correct code for the "watingtime extension response" the card response is actually acknoledged. From that point on I was able to use your current code to manage the commands I needed to correctly retrieve informations from the card. I'm leaving the office now, but if it's fine for you I have a couple of (small) observations that can help you in further improving your library. Once again, thanks for your work and support!

Fabrizio

[angus71]

Hi Fabrizio,

Thats good to hear :-) I'm just curious, do you have to send back the "actual" waiting time or is it an empty "waiting time extension response" package?

If you want to share any "observations", just drop me a mail via the user profile "Send Message" function.

Angus