Use of SC_APDU_*_EXT with newer cards

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Use of SC_APDU_*_EXT with newer cards

Douglas E. Engert
While trying to use a new card that can use extended APDUs,
it appears that the code in card.c is only half implemented.
Here is a patch that I believe will allow for the use
of the SC_APDU_*_EXT flags.

This is not completly tested, so please look it over first.


Index: card.c
===================================================================
--- card.c (revision 2478)
+++ card.c (working copy)
@@ -38,11 +38,15 @@

  static int sc_check_apdu(sc_context_t *ctx, const sc_apdu_t *apdu)
  {
- if (apdu->le > 256) {
+ if (apdu->le > 256
+ && (apdu->cse == SC_APDU_CASE_2_SHORT
+  || apdu->cse == SC_APDU_CASE_4_SHORT)) {
  sc_error(ctx, "Value of Le too big (maximum 256 bytes)\n");
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
- if (apdu->lc > 255) {
+ if (apdu->lc > 255
+ && (apdu->cse == SC_APDU_CASE_3_SHORT
+  || apdu->cse == SC_APDU_CASE_4_SHORT)) {
  sc_error(ctx, "Value of Lc too big (maximum 255 bytes)\n");
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
@@ -54,6 +58,7 @@
  }
  break;
  case SC_APDU_CASE_2_SHORT:
+ case SC_APDU_CASE_2_EXT:
  if (apdu->datalen > 0) {
  sc_error(ctx, "Case 2 APDU with data supplied\n");
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
@@ -68,12 +73,14 @@
  }
  break;
  case SC_APDU_CASE_3_SHORT:
+ case SC_APDU_CASE_3_EXT:
  if (apdu->datalen == 0 || apdu->data == NULL) {
  sc_error(ctx, "Case 3 APDU with no data supplied\n");
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
  break;
  case SC_APDU_CASE_4_SHORT:
+ case SC_APDU_CASE_4_EXT:
  if (apdu->datalen == 0 || apdu->data == NULL) {
  sc_error(ctx, "Case 4 APDU with no data supplied\n");
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
@@ -87,11 +94,6 @@
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
  break;
- case SC_APDU_CASE_2_EXT:
- case SC_APDU_CASE_3_EXT:
- case SC_APDU_CASE_4_EXT:
- sc_error(ctx, "Invalid APDU case %d\n", apdu->cse);
- SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
  return 0;
  }
@@ -163,22 +165,38 @@
  case SC_APDU_CASE_1:
  break;
  case SC_APDU_CASE_2_SHORT:
- *data++ = (u8) apdu->le;
- break;
  case SC_APDU_CASE_2_EXT:
- *data++ = (u8) 0;
- *data++ = (u8) (apdu->le >> 8);
- *data++ = (u8) (apdu->le & 0xFF);
+ if (apdu->le < 256) {
+ *data++ = (u8) apdu->le;
+ } else {
+ *data++ = (u8) 0;
+ *data++ = (u8) (apdu->le >> 8);
+ *data++ = (u8) (apdu->le & 0xFF);
+ }
  break;
  case SC_APDU_CASE_3_SHORT:
- *data++ = (u8) apdu->lc;
+ case SC_APDU_CASE_3_EXT:
+ if (apdu->lc < 256) {
+ *data++ = (u8) apdu->lc;
+ } else {
+ *data++ = (u8) 0;
+ *data++ = (u8) (apdu->lc >> 8);
+ *data++ = (u8) (apdu->lc & 0xFF);
+ }
  if (apdu->datalen != data_bytes)
  return SC_ERROR_INVALID_ARGUMENTS;
  memcpy(data, apdu->data, data_bytes);
  data += data_bytes;
  break;
  case SC_APDU_CASE_4_SHORT:
- *data++ = (u8) apdu->lc;
+ case SC_APDU_CASE_4_EXT:
+ if (apdu->lc < 256) {
+ *data++ = (u8) apdu->lc;
+ } else {
+ *data++ = (u8) 0;
+ *data++ = (u8) (apdu->lc >> 8);
+ *data++ = (u8) (apdu->lc & 0xFF);
+ }
  if (apdu->datalen != data_bytes)
  return SC_ERROR_INVALID_ARGUMENTS;
  memcpy(data, apdu->data, data_bytes);
@@ -187,8 +205,13 @@
  if (card->slot->active_protocol == SC_PROTO_T1) {
  if (apdu->le == 256)
  *data++ = 0x00;
- else
+ else if (apdu->le < 255) {
  *data++ = (u8) apdu->le;
+ }else {
+ *data++ = 0x00;
+ *data++ = (u8) (apdu->le >> 8);
+ *data++ = (u8) (apdu->le & 0xFF);
+ }
  }
  break;
  }


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Nils Larsch
Douglas E. Engert wrote:
> While trying to use a new card that can use extended APDUs,
> it appears that the code in card.c is only half implemented.
> Here is a patch that I believe will allow for the use
> of the SC_APDU_*_EXT flags.
>
> This is not completly tested, so please look it over first.

Could you test the attached patch. Note: in case your card
wants to use T0 it can't work as we need the envelope command
for this (and to implement it some further changes are needed).

Cheers,
Nils

Index: src/libopensc/card.c
===================================================================
--- src/libopensc/card.c (Revision 2534)
+++ src/libopensc/card.c (Arbeitskopie)
@@ -36,14 +36,21 @@
  return card->ops->check_sw(card, sw1, sw2);
 }
 
+#define SC_IS_SHORT_APDU(a) ((a)->cse >= SC_APDU_CASE_1 && (a)->cse <= SC_APDU_CASE_4_SHORT)
+#define SC_IS_EXT_APDU(a) ((a)->cse >= SC_APDU_CASE_2_EXT && (a)->cse <= SC_APDU_CASE_4_EXT)
+
 static int sc_check_apdu(sc_context_t *ctx, const sc_apdu_t *apdu)
 {
- if (apdu->le > 256) {
- sc_error(ctx, "Value of Le too big (maximum 256 bytes)\n");
+ if ((apdu->le > 256 && SC_IS_SHORT_APDU(apdu)) ||
+    (apdu->le > 65536 && SC_IS_EXT_APDU(apdu))) {
+ sc_error(ctx, "Value of Le too big '%lu' (maximum %d bytes)\n",
+ apdu->le, SC_IS_EXT_APDU(apdu) ? 65536 : 256);
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
- if (apdu->lc > 255) {
- sc_error(ctx, "Value of Lc too big (maximum 255 bytes)\n");
+ if ((apdu->lc > 255 && SC_IS_SHORT_APDU(apdu)) ||
+    (apdu->lc > 65535 && SC_IS_EXT_APDU(apdu))){
+ sc_error(ctx, "Value of Lc too big '%lu' (maximum %d bytes)\n",
+ apdu->lc, SC_IS_EXT_APDU(apdu) ? 65535 : 255);
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
  switch (apdu->cse) {
@@ -54,6 +61,7 @@
  }
  break;
  case SC_APDU_CASE_2_SHORT:
+ case SC_APDU_CASE_2_EXT:
  if (apdu->datalen > 0) {
  sc_error(ctx, "Case 2 APDU with data supplied\n");
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
@@ -68,12 +76,14 @@
  }
  break;
  case SC_APDU_CASE_3_SHORT:
+ case SC_APDU_CASE_3_EXT:
  if (apdu->datalen == 0 || apdu->data == NULL) {
  sc_error(ctx, "Case 3 APDU with no data supplied\n");
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
  break;
  case SC_APDU_CASE_4_SHORT:
+ case SC_APDU_CASE_4_EXT:
  if (apdu->datalen == 0 || apdu->data == NULL) {
  sc_error(ctx, "Case 4 APDU with no data supplied\n");
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
@@ -87,9 +97,7 @@
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
  break;
- case SC_APDU_CASE_2_EXT:
- case SC_APDU_CASE_3_EXT:
- case SC_APDU_CASE_4_EXT:
+ default:
  sc_error(ctx, "Invalid APDU case %d\n", apdu->cse);
  SC_FUNC_RETURN(ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
@@ -129,6 +137,7 @@
  return 0;
 }
 
+/* build the TPDU and transmit it to the reader */
 static int sc_transceive(sc_card_t *card, sc_apdu_t *apdu)
 {
  u8 sbuf[SC_MAX_APDU_BUFFER_SIZE];
@@ -138,14 +147,6 @@
  size_t data_bytes = apdu->lc;
  int r;
 
-#if 0
- if (card->ctx->debug >= 6)
- sc_debug(card->ctx, "masq=%x, max_send=%u, max_recv=%u",
- card->reader->driver->apdu_masquerade,
- card->max_recv_size,
- card->max_send_size);
-#endif
-
  if (card->reader->ops->transmit == NULL)
  return SC_ERROR_NOT_SUPPORTED;
 
@@ -166,9 +167,17 @@
  *data++ = (u8) apdu->le;
  break;
  case SC_APDU_CASE_2_EXT:
- *data++ = (u8) 0;
- *data++ = (u8) (apdu->le >> 8);
- *data++ = (u8) (apdu->le & 0xFF);
+ if (card->slot->active_protocol == SC_PROTO_T1) {
+ *data++ = (u8) 0;
+ *data++ = (u8) apdu->le >> 8;
+ *data++ = (u8) apdu->le & 0xff;
+ } else {
+ /* T0 protocol */
+ if (apdu->le < 256)
+ *data++ = (u8)apdu->le;
+ else
+ *data++ = (u8)0;
+ }
  break;
  case SC_APDU_CASE_3_SHORT:
  *data++ = (u8) apdu->lc;
@@ -177,6 +186,18 @@
  memcpy(data, apdu->data, data_bytes);
  data += data_bytes;
  break;
+ case SC_APDU_CASE_3_EXT:
+ if (card->slot->active_protocol == SC_PROTO_T1) {
+ *data++ = (u8)  0;
+ *data++ = (u8) apdu->lc >> 8;
+ *data++ = (u8) apdu->lc & 0xff;
+ if (apdu->datalen != data_bytes)
+ return SC_ERROR_INVALID_ARGUMENTS;
+ memcpy(data, apdu->data, data_bytes);
+ data += data_bytes;
+ } else
+ return SC_ERROR_NOT_SUPPORTED;
+ break;
  case SC_APDU_CASE_4_SHORT:
  *data++ = (u8) apdu->lc;
  if (apdu->datalen != data_bytes)
@@ -191,6 +212,23 @@
  *data++ = (u8) apdu->le;
  }
  break;
+ case SC_APDU_CASE_4_EXT:
+ if (card->slot->active_protocol == SC_PROTO_T1) {
+ *data++ = (u8)  0;
+ *data++ = (u8) apdu->lc >> 8;
+ *data++ = (u8) apdu->lc & 0xff;
+ if (apdu->datalen != data_bytes)
+ return SC_ERROR_INVALID_ARGUMENTS;
+ memcpy(data, apdu->data, data_bytes);
+ data += data_bytes;
+ *data++ = (u8) apdu->le >> 8;
+ *data++ = (u8) apdu->le & 0xff;
+ } else
+ return SC_ERROR_NOT_SUPPORTED;
+ break;
+ default:
+ sc_error(card->ctx, "Invalid APDU case %d\n", apdu->cse);
+ SC_FUNC_RETURN(card->ctx, 4, SC_ERROR_INVALID_ARGUMENTS);
  }
  sendsize = data - sbuf;
 #if 0
@@ -226,7 +264,10 @@
  memset(sbuf, 0, sendsize);
  SC_TEST_RET(card->ctx, r, "Unable to transmit");
 
- assert(recvsize >= 2);
+ if (recvsize < 2) {
+ sc_error(card->ctx, "Invalid response\n");
+ return SC_ERROR_WRONG_LENGTH;
+ }
  apdu->sw1 = (unsigned int) rbuf[recvsize-2];
  apdu->sw2 = (unsigned int) rbuf[recvsize-1];
  if (apdu->sensitive)

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Douglas E. Engert
In reply to this post by Douglas E. Engert


Nils Larsch wrote:

> Hi Douglas,
>
> could you please test the patch I've send you ? Currently I don't
> havea a card that supports extended APDUs and hence cannot test it.

Sorry about the delay in getting back to you.

Well, it turns out that I can't and don't need to use the extended cases.
Correct me if I am wrong on this, but it looks like the extended cases
are only usable if the reader can support data buffers > 255.

The NIST SP800-73 standard for PIV-II cards:
http://csrc.nist.gov/publications/nistpubs/800-73/SP800-73-Final.pdf
defines GET DATA and PUT DATA commands that appear to be designed to
allow for extended lengths. But they can also support a chaining mode if
the data can not be read/written with one command.

One of my test systems appears to only do T0, and the other can do T0
or T1. They both appear to force the card->max_send_size and max_recv_size
to <= 256. And OpenSC appears to limit the size as well by the use
of SC_MAX_APDU_BUFFER_SIZE = 258 in a number of places like in
sc_transceive.

So even though the card might handle it, I can't use the extended modes.

I did try your patch, and it does appear to work, but since the patch was
meant to address extended modes, I can't really test it.

I have gone back to the original unmodified card.c, and it works in my
situation.

Sorry about the confusion.

But for future reference, it is not clear why the caller to the
sc_format_apdu needs to specify _SHORT or _EXT, as if the length
is > 256 then the extended form needs to be used.  It would appear
that the sc_check_apdu could check the lengths, and some attribute
of the card, to flag if the length was too long for the card or reader.



>
> Douglas E. Engert wrote:
>
>> While trying to use a new card that can use extended APDUs,
>> it appears that the code in card.c is only half implemented.
>> Here is a patch that I believe will allow for the use
>> of the SC_APDU_*_EXT flags.
>>
>> This is not completly tested, so please look it over first.
>
> ...
>
>> @@ -163,22 +165,38 @@
>>      case SC_APDU_CASE_1:
>>          break;
>>      case SC_APDU_CASE_2_SHORT:
>> -        *data++ = (u8) apdu->le;
>> -        break;
>>      case SC_APDU_CASE_2_EXT:
>> -        *data++ = (u8) 0;
>> -        *data++ = (u8) (apdu->le >> 8);
>> -        *data++ = (u8) (apdu->le & 0xFF);
>> +        if (apdu->le < 256) {
>> +            *data++ = (u8) apdu->le;
>> +        } else {
>> +            *data++ = (u8) 0;
>> +            *data++ = (u8) (apdu->le >> 8);
>> +            *data++ = (u8) (apdu->le & 0xFF);
>> +        }
>>          break;
>>      case SC_APDU_CASE_3_SHORT:
>> -        *data++ = (u8) apdu->lc;
>> +    case SC_APDU_CASE_3_EXT:
>> +        if (apdu->lc < 256) {
>> +            *data++ = (u8) apdu->lc;
>> +        } else {
>> +            *data++ = (u8) 0;
>> +            *data++ = (u8) (apdu->lc >> 8);
>> +            *data++ = (u8) (apdu->lc & 0xFF);
>> +        }
>
>
> I don't think this is correct. According to my version of
> iso 7816-4 the TPDU in case of T1 always uses 3 length bytes.
>
>>          if (apdu->datalen != data_bytes)
>>              return SC_ERROR_INVALID_ARGUMENTS;
>>          memcpy(data, apdu->data, data_bytes);
>>          data += data_bytes;
>>          break;
>>      case SC_APDU_CASE_4_SHORT:
>> -        *data++ = (u8) apdu->lc;
>> +    case SC_APDU_CASE_4_EXT:
>> +        if (apdu->lc < 256) {
>> +            *data++ = (u8) apdu->lc;
>> +        } else {
>> +            *data++ = (u8) 0;
>> +            *data++ = (u8) (apdu->lc >> 8);
>> +            *data++ = (u8) (apdu->lc & 0xFF);
>> +        }
>>          if (apdu->datalen != data_bytes)
>>              return SC_ERROR_INVALID_ARGUMENTS;
>>          memcpy(data, apdu->data, data_bytes);
>> @@ -187,8 +205,13 @@
>>          if (card->slot->active_protocol == SC_PROTO_T1) {
>>              if (apdu->le == 256)
>>                  *data++ = 0x00;
>> -            else
>> +            else if (apdu->le < 255) {
>>                  *data++ = (u8) apdu->le;
>> +            }else {
>> +                *data++ = 0x00;
>> +                *data++ = (u8) (apdu->le >> 8);
>> +                *data++ = (u8) (apdu->le & 0xFF);
>
>
> afaik only two bytes are used for Le
>
> Cheers,
> Nils
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Nils Larsch
Douglas E. Engert wrote:

>
>
> Nils Larsch wrote:
>
>> Hi Douglas,
>>
>> could you please test the patch I've send you ? Currently I don't
>> havea a card that supports extended APDUs and hence cannot test it.
>
>
> Sorry about the delay in getting back to you.
>
> Well, it turns out that I can't and don't need to use the extended cases.
> Correct me if I am wrong on this, but it looks like the extended cases
> are only usable if the reader can support data buffers > 255.

well you could use extended APDUs for data lengths < 255 but it doesn't
make much sense in this case. And of course the reader needs to have a
sufficiently large buffer

>
> The NIST SP800-73 standard for PIV-II cards:
> http://csrc.nist.gov/publications/nistpubs/800-73/SP800-73-Final.pdf
> defines GET DATA and PUT DATA commands that appear to be designed to
> allow for extended lengths. But they can also support a chaining mode if
> the data can not be read/written with one command.

funny, I'm currently looking the PIV stuff as well

>
> One of my test systems appears to only do T0, and the other can do T0
> or T1. They both appear to force the card->max_send_size and max_recv_size
> to <= 256. And OpenSC appears to limit the size as well by the use
> of SC_MAX_APDU_BUFFER_SIZE = 258 in a number of places like in

yep, but this constant could be changed to 2^16

> sc_transceive.
>
> So even though the card might handle it, I can't use the extended modes.
>
> I did try your patch, and it does appear to work, but since the patch was
> meant to address extended modes, I can't really test it.
>
> I have gone back to the original unmodified card.c, and it works in my
> situation.

ok, I will put the patch in my archive and look at it again as soon
as there's real need for it

>
> Sorry about the confusion.
>
> But for future reference, it is not clear why the caller to the
> sc_format_apdu needs to specify _SHORT or _EXT, as if the length
> is > 256 then the extended form needs to be used.  It would appear
> that the sc_check_apdu could check the lengths, and some attribute
> of the card, to flag if the length was too long for the card or reader.

sounds logical, will think about it (is it possible that a card only
support extended APDUs for specific command ?)

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Douglas E. Engert


Nils Larsch wrote:

> Douglas E. Engert wrote:
>
>>
>>
>> Nils Larsch wrote:
>>
>>> Hi Douglas,
[...]
>> The NIST SP800-73 standard for PIV-II cards:
>> http://csrc.nist.gov/publications/nistpubs/800-73/SP800-73-Final.pdf
>> defines GET DATA and PUT DATA commands that appear to be designed to
>> allow for extended lengths. But they can also support a chaining mode if
>> the data can not be read/written with one command.
>
>
> funny, I'm currently looking the PIV stuff as well

Well, I have a beta card from a manufacture, and have got as far as using
the certificate and key with a Mozilla plugin to access our internal
web servers. I have reported back problems to them and am waiting
for new beta release of their cards.

As a first cut I am interested in only using the "X.509 Certificate for
PIV Authentication" for SSL and Kerberos PKINIT, especially on Unix.
To do this required adding a card-piv.c and pkcs15-piv.c to the library
and a piv-tool. I would hope to submit these in the near future. I just
got them working yesterday.

The piv-tool was needed to initialize the card and will use the
GENERAL AUTHENTICATE and GENERATE ASYMMETRIC KEY PAIR via the
a ctrl call into card-piv.c. It will save the public key and can be used
to load the certificate. I will be testing to see if I can do this
using the pkcs11 instead.

One of the issues I have run in to include the PKCS15 routines try and use
sc_select_file and sc_read_binary where as the PIV card may not
have these. So the card-piv.c is using GET DATA to simulate these.

>
>>
>> One of my test systems appears to only do T0, and the other can do T0
>> or T1. They both appear to force the card->max_send_size and
>> max_recv_size
>> to <= 256. And OpenSC appears to limit the size as well by the use
>> of SC_MAX_APDU_BUFFER_SIZE = 258 in a number of places like in
>
>
> yep, but this constant could be changed to 2^16

OK, I am also trying to use the Solaris Blade built in card reader,
using pcsc-lite to the Solaris SCF code. It looks like this combination it only
supports T0. On Unix to a GemPC twin it supports T1. I have not tried to
enlarge the buffer.

I expect the next beta card to work with T0.

>
>>
>> Sorry about the confusion.
>>
>> But for future reference, it is not clear why the caller to the
>> sc_format_apdu needs to specify _SHORT or _EXT, as if the length
>> is > 256 then the extended form needs to be used.  It would appear
>> that the sc_check_apdu could check the lengths, and some attribute
>> of the card, to flag if the length was too long for the card or reader.
>
>
> sounds logical, will think about it (is it possible that a card only
> support extended APDUs for specific command ?)

Not the beta cards I have, but the NIST SP800-73 GET_DATA implies it
was designed to do the operation in one command and the largest data object
could be 12704 bytes long. The cards I have can use get response to get
aditional buffers of data. Although it is not clear if this is as per the
SP800-73 standard.


>
> Cheers,
> Nils
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Nils Larsch
Douglas E. Engert wrote:
...

>> funny, I'm currently looking the PIV stuff as well
>
>
> Well, I have a beta card from a manufacture, and have got as far as using
> the certificate and key with a Mozilla plugin to access our internal
> web servers. I have reported back problems to them and am waiting
> for new beta release of their cards.
>
> As a first cut I am interested in only using the "X.509 Certificate for
> PIV Authentication" for SSL and Kerberos PKINIT, especially on Unix.
> To do this required adding a card-piv.c and pkcs15-piv.c to the library
> and a piv-tool. I would hope to submit these in the near future. I just
> got them working yesterday.

cool, I wanted to write the same as well (but as I don't have test
samples I didn't start so far). Actually I'm planning to implement
a piv api in opensc (and a pkcs11 on top of it) so that a pkcs15-piv.c
shouldn't be necessary.

>
> The piv-tool was needed to initialize the card and will use the
> GENERAL AUTHENTICATE and GENERATE ASYMMETRIC KEY PAIR via the
> a ctrl call into card-piv.c. It will save the public key and can be used
> to load the certificate. I will be testing to see if I can do this
> using the pkcs11 instead.

I've no problem with an additional tool

>
> One of the issues I have run in to include the PKCS15 routines try and use
> sc_select_file and sc_read_binary where as the PIV card may not
> have these. So the card-piv.c is using GET DATA to simulate these.

yep, the current pkcs15 implementation doesn't work nicely with
object based cards

>
>>
>>>
>>> One of my test systems appears to only do T0, and the other can do T0
>>> or T1. They both appear to force the card->max_send_size and
>>> max_recv_size
>>> to <= 256. And OpenSC appears to limit the size as well by the use
>>> of SC_MAX_APDU_BUFFER_SIZE = 258 in a number of places like in
>>
>>
>>
>> yep, but this constant could be changed to 2^16
>
>
> OK, I am also trying to use the Solaris Blade built in card reader,
> using pcsc-lite to the Solaris SCF code. It looks like this combination
> it only
> supports T0. On Unix to a GemPC twin it supports T1. I have not tried to
> enlarge the buffer.
>
> I expect the next beta card to work with T0.

as I already wrote: to support extended APDUs in the T0 protocol would
afaik require that we implement the ENVELOPE command, hence this
would requires a bit more work.

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Bud P. Bruegger
At 00.37 14/09/2005 +0200, Nils Larsch wrote:
>>To do this required adding a card-piv.c and pkcs15-piv.c to the library
>>and a piv-tool. I would hope to submit these in the near future. I just
>>got them working yesterday.
>
>cool, I wanted to write the same as well (but as I don't have test
>samples I didn't start so far). Actually I'm planning to implement
>a piv api in opensc (and a pkcs11 on top of it) so that a pkcs15-piv.c
>shouldn't be necessary.

Hi Doug and Nils,

I join in the cheering to having a card-piv.c and pkcs15-piv.c.  Very
cool!   Thanks, Doug!  Also, I'll meet with Jim Dray of NIST next week and
he'll be very happy to hear about this too.

Since I don't have test cards, I wanted to use the PIV software
emulator.   From an earlier discussion with Nils it seems this would
require a relatively simple reader driver in OpenCT.  Did you happen to
look into this by any chance?

best cheers
-b




-------------------------------------------------------------------------------------------------
Ing. Bud P. Bruegger, Ph.D.                 +39-0564-488577
(voice),  -21139 (fax)
Servizio Elaborazione Dati                    e-mail:  [hidden email]
Comune di
Grosseto                            http://www.comune.grosseto.it/cie/
Via Ginori,
43                                      http://OpenPortalGuard.sf.net
58100 Grosseto (Tuscany, Italy)           jabber:  [hidden email]

Free Software in Public Administration:  not just a good idea, but a necessity

Perfection is attained, not when there is nothing more to be added, but
when there is nothing more to be taken away -- Antoine de Saint-Exupery

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Douglas E. Engert
In reply to this post by Nils Larsch


Nils Larsch wrote:

> Douglas E. Engert wrote:
> ...
>
>>> funny, I'm currently looking the PIV stuff as well
>>
>>
>>
>> Well, I have a beta card from a manufacture, and have got as far as using
>> the certificate and key with a Mozilla plugin to access our internal
>> web servers. I have reported back problems to them and am waiting
>> for new beta release of their cards.
>>
>> As a first cut I am interested in only using the "X.509 Certificate for
>> PIV Authentication" for SSL and Kerberos PKINIT, especially on Unix.
>> To do this required adding a card-piv.c and pkcs15-piv.c to the library
>> and a piv-tool. I would hope to submit these in the near future. I just
>> got them working yesterday.
>
>
> cool, I wanted to write the same as well (but as I don't have test
> samples I didn't start so far). Actually I'm planning to implement
> a piv api in opensc (and a pkcs11 on top of it) so that a pkcs15-piv.c
> shouldn't be necessary.

Cool. I was not even going to touch the API.

I expect there will be many card vendors with Windows applications, and we
will use these for Windows as well as to administer the cards. My main
interest is in making sure the cards can be used for Unix login on open
source systems, as it looks like we will have to do this next year. Doing
this via pkcs11 on top of pkcs15 was a simple way to do it. pkcs11 on top
of a piv api would be better.

When you say implement a pkcs11 on top of the API, I have a concern
that we may have to use some PIV cards, as well as other cards for login.
I would hope that the application can load only one libpkcs11.so and it
could work with current cards, as well as piv cards through your new
pkcs11 on top of the piv api.

>
>>
>> The piv-tool was needed to initialize the card and will use the
>> GENERAL AUTHENTICATE and GENERATE ASYMMETRIC KEY PAIR via the
>> a ctrl call into card-piv.c. It will save the public key and can be used
>> to load the certificate. I will be testing to see if I can do this
>> using the pkcs11 instead.
>
>
> I've no problem with an additional tool

This was done so I could administer the card for testing. I only add
the minimal functions needed.

>
>>
>> One of the issues I have run in to include the PKCS15 routines try and
>> use
>> sc_select_file and sc_read_binary where as the PIV card may not
>> have these. So the card-piv.c is using GET DATA to simulate these.
>
>
> yep, the current pkcs15 implementation doesn't work nicely with
> object based cards

One problem with the SP800-73 is it defines the objects, but you
don't know if they are present untill you try and read them.
With pkcs15 emulation, you need to define all the objects, that may
be present, but to keep the overhead down, I don't test until an
attempt by pkcs15 is made to read the object.

>
>>
>>>
>>>>
>>>> One of my test systems appears to only do T0, and the other can do T0
>>>> or T1. They both appear to force the card->max_send_size and
>>>> max_recv_size
>>>> to <= 256. And OpenSC appears to limit the size as well by the use
>>>> of SC_MAX_APDU_BUFFER_SIZE = 258 in a number of places like in
>>>
>>>
>>>
>>>
>>> yep, but this constant could be changed to 2^16
>>
>>
>>
>> OK, I am also trying to use the Solaris Blade built in card reader,
>> using pcsc-lite to the Solaris SCF code. It looks like this
>> combination it only
>> supports T0. On Unix to a GemPC twin it supports T1. I have not tried to
>> enlarge the buffer.
>>
>> I expect the next beta card to work with T0.
>
>
> as I already wrote: to support extended APDUs in the T0 protocol would
> afaik require that we implement the ENVELOPE command, hence this
> would requires a bit more work.

I understand. But I don't know if the SP800-73 requires envelope, or
if all manufactures will implement it anyway.

>
> Cheers,
> Nils
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Douglas E. Engert
In reply to this post by Bud P. Bruegger


Bud P. Bruegger wrote:

> At 00.37 14/09/2005 +0200, Nils Larsch wrote:
>
>>> To do this required adding a card-piv.c and pkcs15-piv.c to the library
>>> and a piv-tool. I would hope to submit these in the near future. I just
>>> got them working yesterday.
>>
>>
>> cool, I wanted to write the same as well (but as I don't have test
>> samples I didn't start so far). Actually I'm planning to implement
>> a piv api in opensc (and a pkcs11 on top of it) so that a pkcs15-piv.c
>> shouldn't be necessary.
>
>
> Hi Doug and Nils,
>
> I join in the cheering to having a card-piv.c and pkcs15-piv.c.  Very
> cool!   Thanks, Doug!  Also, I'll meet with Jim Dray of NIST next week
> and he'll be very happy to hear about this too.

I need to drop NIST a note a s well. After implementing this code,
I see some issues with SP800-73.

>
> Since I don't have test cards, I wanted to use the PIV software
> emulator.   From an earlier discussion with Nils it seems this would
> require a relatively simple reader driver in OpenCT.  Did you happen to
> look into this by any chance?
>

I have not looked at that at all.

> best cheers
> -b
>
>
>
>
> -------------------------------------------------------------------------------------------------
>
> Ing. Bud P. Bruegger, Ph.D.                 +39-0564-488577 (voice),  
> -21139 (fax)
> Servizio Elaborazione Dati                    e-mail:  
> [hidden email]
> Comune di Grosseto                            
> http://www.comune.grosseto.it/cie/
> Via Ginori, 43                                      
> http://OpenPortalGuard.sf.net
> 58100 Grosseto (Tuscany, Italy)           jabber:  [hidden email]
>
> Free Software in Public Administration:  not just a good idea, but a
> necessity
>
> Perfection is attained, not when there is nothing more to be added, but
> when there is nothing more to be taken away -- Antoine de Saint-Exupery
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

Nils Larsch
In reply to this post by Douglas E. Engert
Douglas E. Engert wrote:
...

> Cool. I was not even going to touch the API.
>
> I expect there will be many card vendors with Windows applications, and we
> will use these for Windows as well as to administer the cards. My main
> interest is in making sure the cards can be used for Unix login on open
> source systems, as it looks like we will have to do this next year. Doing
> this via pkcs11 on top of pkcs15 was a simple way to do it. pkcs11 on top
> of a piv api would be better.
>
> When you say implement a pkcs11 on top of the API, I have a concern
> that we may have to use some PIV cards, as well as other cards for login.

I'm planning something like a piv card emulation as well (so that you
can access other id cards with the piv api)

> I would hope that the application can load only one libpkcs11.so and it
> could work with current cards, as well as piv cards through your new
> pkcs11 on top of the piv api.

of course

...

>>> One of the issues I have run in to include the PKCS15 routines try
>>> and use
>>> sc_select_file and sc_read_binary where as the PIV card may not
>>> have these. So the card-piv.c is using GET DATA to simulate these.
>>
>>
>>
>> yep, the current pkcs15 implementation doesn't work nicely with
>> object based cards
>
>
> One problem with the SP800-73 is it defines the objects, but you
> don't know if they are present untill you try and read them.
> With pkcs15 emulation, you need to define all the objects, that may
> be present, but to keep the overhead down, I don't test until an
> attempt by pkcs15 is made to read the object.

understand, perhaps it's an acceptable solution to say that an object
is there but it might be empty ;-) ... well I need to thing about this

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of SC_APDU_*_EXT with newer cards

David Corcoran
Yes, PIV does not go far enough to do anything with object discovery  
although early in the
process of creating the standard, there was a simple PKCS#15 subset  
which ended up getting removed.
Perhaps people will see that discovery must be there and it will work  
its way into future revisions : )

There is the CCC in there but it really only has a role in PIV  
transitional.

Thanks,
Dave




On Sep 14, 2005, at 11:49 AM, Nils Larsch wrote:

> Douglas E. Engert wrote:
> ...
>
>> Cool. I was not even going to touch the API.
>> I expect there will be many card vendors with Windows  
>> applications, and we
>> will use these for Windows as well as to administer the cards. My  
>> main
>> interest is in making sure the cards can be used for Unix login on  
>> open
>> source systems, as it looks like we will have to do this next  
>> year. Doing
>> this via pkcs11 on top of pkcs15 was a simple way to do it. pkcs11  
>> on top
>> of a piv api would be better.
>> When you say implement a pkcs11 on top of the API, I have a concern
>> that we may have to use some PIV cards, as well as other cards for  
>> login.
>>
>
> I'm planning something like a piv card emulation as well (so that you
> can access other id cards with the piv api)
>
>
>> I would hope that the application can load only one libpkcs11.so  
>> and it
>> could work with current cards, as well as piv cards through your new
>> pkcs11 on top of the piv api.
>>
>
> of course
>
> ...
>
>>>> One of the issues I have run in to include the PKCS15 routines  
>>>> try and use
>>>> sc_select_file and sc_read_binary where as the PIV card may not
>>>> have these. So the card-piv.c is using GET DATA to simulate these.
>>>>
>>>
>>>
>>>
>>> yep, the current pkcs15 implementation doesn't work nicely with
>>> object based cards
>>>
>> One problem with the SP800-73 is it defines the objects, but you
>> don't know if they are present untill you try and read them.
>> With pkcs15 emulation, you need to define all the objects, that may
>> be present, but to keep the overhead down, I don't test until an
>> attempt by pkcs15 is made to read the object.
>>
>
> understand, perhaps it's an acceptable solution to say that an object
> is there but it might be empty ;-) ... well I need to thing about this
>
> Cheers,
> Nils
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>
>



------------------------------------------------------------------------
------------
David Corcoran        [hidden email]
   Identity Alliance        http://www.identityalliance.com
   phone: 260-488-3099   fax: 260-488-2455

   Smart Cards, Biometrics, Training, Identity Management
------------------------------------------------------------------------
-------------


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel