sorry guys, I realize I know a lot less than I should know about all
these subjects, so as a result I'm still very confused.
the start of my discussion with chaskiel was this
> the scmscr3320 and hp-keyboard appear to have dwMaxCCIDMessageLength
> less than 271 bytes. They therefore fail to process the GET RESPONSE
> command (c0 c0 00 00 00) that is sent after the signature operation
> succeeds. It is possible that the card supports GET RESPONSE
chaining, > and that if opensc sent a GET RESPONSE with le <= 0xF0, that
the reply > would include 240 bytes of signature followed by SW 61 10
(allowing
> the rest to be fetched in a second GET RESPONSE)
I had a look at CCID spec 1.10 and - not sure - it seems this is no
longer valid, dwMaxCCIDMessagelength has to be at least 271 bytes
(and max 65544+10 bytes). but that doesn't help, it would be nice
to get the hardware to work.
also I guess the communication (from opensc to the card - a cryptoflex
32k) is using T=0 protocol, because with T=1 the TPDU could be small
enough and both card and host would use segmentation and reassembly,
so there wouldn't be an issue.
not sure if cryptoflex allowes get response chanining, but I think it
does ( le can be 00 for 256 bytes or a part, so I guess you can use
several get response to get the response part by part).
> > hmm. do I need to change this in opensc, or can the driver in openct
> > enforce smaller blocks to transfer?
>
> I don't think openct can do this by itself. it requires that the
APDUs > sent not involve data transfers that are too large. opensc's
> driver->max_send_size and max_recv_size already do this for the
> sc_*_binary operations.
>
> It looks like iso7816_get_response assumes that chained get_response
> is possible. It (or do_single_transmit) could be modified to truncate
> the get response le value to max_recv_size.
> (cryptoflex_compute_signature should also break things up into
> max_send_size chunks, but that's only relevant for the winbond (128
> bytes) reader)
>
> Of course, there would also need to be a way for opensc to learn the
> max_recv_size.
> There are complications (not relevant to GET RESPONSE) here: for T=1
> and a TPDU reader, the APDU size is _not_ restricted by
> dwMaxCCIDMessageLength, only the T=1 IFSD/IFSC are so restricted (and
> an APDU can be split into an arbitrary number of TPDUs). For T=0 or
> APDU readers, the dwMaxCCIDMessageLength does affect the APDU size.
so we only have a T=0 problem. the cryptoflex card can do both T=0
and T=1, so if we switched to T=1 by default, we wouldn't have the
issue at all? IIRC we prefer T=1 for reader-pcsc, and pcsc tries
to switch to T=1 if possible?
> Signing functions need to do it where supported by the card
> (cryptoflex allows you to break up the data to be signed. many cards,
> including those that use 'perform security operation' for signatures,
> do not. in those cases, you have to fail the signature operation). The
> other place that needs to check this is sc_transmit_apdu, in the case
> where it calls get_response. it needs to cap the le value at max_recv,
> be prepared for get_respnse to return a 61 sw, and call get_response
> as many times as is needed.
hmm, to sum up:
- if we are using t=1, we are fine.
- if we are using t=0, we need to let opensc know what the limits
for max_send/recv_size are (the driver knows, but we currently have
no way to let reader-openct know)
- we currently have code in read-* functions to deal with
max_send/recv_size, but at least some cards can also handle that
when signing. we should implement that.
still we need to let our users know:
- if you use a card that can do only t=0
- and your cards signing APDU don't allow to send / recv in several
parts
- and you want to sign e.g. 2048 bit rsa (= 256 bytes)
- and you use a reader that is limited to allow only transfers of less
than that
then you are screwed, it won't work. currently ignore the first line,
as we don't select t=1 for cards that can do it, and thus run into
problems.
did I understand the situation so far correctly? does my summary of
what we could do fit the situation? sorry, I'm still learning all the
fine details (and it shows I haven't read specs like ccid), so every
help is very welcome!
is this a good direction to take? or other ways we should go to fix the
current problem (2048 bit rsa signatures not working on some ccid readers)?
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
