Oops forgot the attachment...

This patch may break the PIV card, because it changed the
line 1792: card->max_send_size = 0xffff;


The PIV card does not directly support read/write binary,
but get/put_data commands which transfer the whole object
using adpu chaining using 255 and 256. Its not using extended
apdu either.

To emulate the read/write binary it sets the card_max_* sizes
to 0xffff to allow the caller to read/write the whole object
rather then 255 byte chunks or records.

So the max_*_size values are used in two different ways,
for read/write and for apdu lengths.

Since there is no "close" command there is no way to know when
the last write_binary is done. Using the 0xffff a write is done
all in one operation.

The attached patch might work, would would needs to be tested.
(I am on vacation starting today till after the first, so this
is not a good time to make a change.)

The piv_general_io routine that does the sc_transmit_apdu
is also used for a number of other operations, so a lot of testing
will be needed.




Andreas Jellinghaus wrote:
Mats here has a fix for apdu chaining / the default
send size is too big. I don't know much about this
topic, so could you please review this change?

Regards, Andreas

----------  Weitergeleitete Nachricht  ----------

Betreff: Re: [opensc-devel] OpenSC 0.11.12-rc1 release candidate available
Datum: Donnerstag 17 Dezember 2009
Von: Mats Andersson <ma...@checkpoint.com>
An: Andreas Jellinghaus <a...@dungeon.inka.de>, Martin Paljak <mar...@paljak.pri.ee>


Hi again,

Here is the udiff. I think the patch is safe. However, by itself maybe this patch is not worth much, it only solves half of the problem that this is now hard-coded in opensc (I just did this for keeping copying to a minimum when I did support for a vasco-card).

If cards support extended APDU's they don't need chaining typically (this patch will only affect sc_transmit_apdu() when SC_APDU_FLAGS_CHAINING is set). Anyway, as I said, it would be even more "generic" if one has a flag/option on card-level which indicates that the card supports chaining (I think it's a discoverable capability of the card according to iso7816, I think through ATR inspection). Then change the code so that it will "auto-chain" if a larger than max_send_size APDU is to be sent (i.e. when extended APDUs are supported the max_send_size is set to the max that can be sent with extended APDUs, hence no chaining will take place there typically).

I can have a go at such a patch if there is interest. What is the official way to provide patches/help out with testing/development?

Cheers,

/Mats

On 12/17/09 5:34 PM, "Andreas Jellinghaus" <a...@dungeon.inka.de> wrote:

Hi Mats,

thanks for your patch, I was not aware we had a problem there.

could you resend your patch in unified diff format ("diff -u")?
that is much easier to review.

I think however the solution is not as simple as this patch -
some cards support large APDU commands ("extended" are they
called I think), so I need to check with the development
team to make sure we don't fix one and break other cards.

so this patch won't go into 0.11.12, but if we can verify
it fixes a problem and rule out breaking other cards, we
can have another 0.11.* release for it.

Regards, Andreas

Scanned by Check Point Total Security Gateway.


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


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

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

--

  Douglas E. Engert  <deeng...@anl.gov>
  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


--- ,card-piv.c	Wed Oct 21 09:24:20 2009
+++ card-piv.c	Fri Dec 18 09:39:34 2009
@@ -282,6 +282,7 @@
 
 	/* TODO if read_binary is fixed, this is not needed */
 	card->max_recv_size = priv->max_recv_size;
+	card->max_send_size = priv->max_send_size;
 
 	sc_debug(card->ctx,"calling sc_transmit_apdu flags=%x le=%d, resplen=%d, resp=%p", 
 		apdu.flags, apdu.le, apdu.resplen, apdu.resp);
@@ -290,6 +291,7 @@
 	r = sc_transmit_apdu(card, &apdu);
 	/* TODO if read_binary is fixed, this is not needed */
 	card->max_recv_size = 0xffff;
+	card->max_send_size = 0xffff;
 
 	sc_debug(card->ctx,"DEE r=%d apdu.resplen=%d sw1=%02x sw2=%02x", 
 			r, apdu.resplen, apdu.sw1, apdu.sw2);
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to