Simon Eisenmann wrote:
This would mean that this reader does not support 2048 bit keys at all?
Schlumberger cards with 2048 bit keys work fine with this reader.

 apdu.c now supports chaining:

   532      if ((apdu->flags & SC_APDU_FLAGS_CHAINING) != 0) {
   533          /* divide et impera: transmit APDU in chunks with Lc < 255
   534           * bytes using command chaining */
   ...
   554                  tapdu.cla    |= 0x10;

The card-piv.c uses this.

Looks like the Schlumberger driver: card-flex.c cyberflex_compute_signature()
knows how to do its own "chaining" by sending the date in two chunks:

1042 /* This works around a problem with some PC/SC IFD drivers that don't grok
  1043       * lc=00 (Chaskiel M Grundman <[EMAIL PROTECTED]>) */
  1044      if (data_len == 256) {
  1045          apdu.cla=0x10;
  1046          apdu.cse= SC_APDU_CASE_3_SHORT;
  1047          apdu.lc=10;
  1048          apdu.datalen=10;
  1049          apdu.data = sbuf;
  1050          for (i2 = 0; i2 < 10; i2++)
  1051              sbuf[i2]=data[data_len-1-i2];
  1052          r = sc_transmit_apdu(card, &apdu);
  1053          SC_TEST_RET(card->ctx, r, "APDU transmit failed");
  1054          r = sc_check_sw(card, apdu.sw1, apdu.sw2);
  1055          SC_TEST_RET(card->ctx, r, "Card returned error");
  1056          data_len -= 10;
1057 sc_format_apdu(card, &apdu, SC_APDU_CASE_4_SHORT, 0x88, 0x00, prv->rsa_key_re
f);
  1058          apdu.cla=0x0;
  1059      }

But it could use the newer apdu.c chaining code to do this.
(I would expect to to compare the max vs card->max_send_size, and
not just 255.)

Maybe the card-cardos.c needs to do chaining too, if the card
supports it. Does anyone have the manual?



In the meantime i tried this with SCM SPR 532, SCM SCR 335 and SCM SCR
333. All give the same result.

Cheers,
Simon

Am Mittwoch, den 14.03.2007, 15:26 +0100 schrieb Ludovic Rousseau:
On 14/03/07, Douglas E. Engert <[EMAIL PROTECTED]> wrote:
I wonder if this is one of the cards/readers that can not handle
the default max_send_size/max_recv_size = 256.
It looks like he is using the SCM SPR 532 [1]. This reader is limited
to an APDU of 260 bytes [2] (dwMaxCCIDMessageLength - 10) so only 255
bytes of data.
It is 1 byte less than the maximum.

You should only be able to get a 2040-bits length key with this reader. Too bad!

Bye

[1] http://www.opensc-project.org/pipermail/opensc-devel/2007-March/009623.html
[2] 
http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/readers/SPR532.txt?op=file&rev=0&sc=0


------------------------------------------------------------------------

_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

--

 Douglas E. Engert  <[EMAIL PROTECTED]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to