Two back-to-back runs, different results

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

Two back-to-back runs, different results

Scott Michel-4
I am trying to debug an issue with the SCM 311 reader and Oberthur ID One card in order to better support Macs and smart card-enabled sites. I've been using pkcs15-tool to list certificates on the card. The result is that on the first run with the card inserted for the first time, certificates are listed. On the next, second run, no certificates are listed; pkcs15-tool reports no certificates.

Turning up the debugging volume, I get the following unified diff output (/tmp/run-11 is the first run, /tmp/run-22 is the second run, timestamps stripped). On the first run, the card is detected as a T0 protocol card. On the second run, the card is detected as a T1 protocol card. I'm fairly certain this is a problem (listing certificates requires APDU messages, not TPDU messages, no?), but not sure where to go look in the code to propose a patch. (*)

--- /tmp/run-11 2012-09-05 10:12:04.000000000 -0700
+++ /tmp/run-22 2012-09-05 10:12:08.000000000 -0700
@@ -21,7 +21,7 @@
reader-pcsc.c:325:refresh_attributes: current state: 0x00000120
reader-pcsc.c:326:refresh_attributes: previous state: 0x00000120
reader-pcsc.c:380:refresh_attributes: card present
-reader-pcsc.c:497:pcsc_connect: Initial protocol: T0 protocol
+reader-pcsc.c:497:pcsc_connect: Initial protocol: T1 protocol
card.c:868:match_atr_table: ATR : 3b:db:96:00:80:1f:03:00:31:c0:64:b0:f3:10:00:07:90:00:80
card.c:879:match_atr_table: ATR try : 3B:DD:18:00:81:31:FE:45:80:F9:A0:00:00:00:77:01:00:70:0A:90:00:8B
card.c:882:match_atr_table: ignored - wrong length

Leading up to this difference, both files have the same lines (again, timestamps stripped):

sc.c:195:sc_detect_card_presence: called
reader-pcsc.c:388:pcsc_detect_card_presence: called
reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check
reader-pcsc.c:325:refresh_attributes: current state: 0x00000120
reader-pcsc.c:326:refresh_attributes: previous state: 0x00000122
reader-pcsc.c:380:refresh_attributes: card present
reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5
sc.c:200:sc_detect_card_presence: returning with: 5
Using reader with a card: SCM SCR 331 00 00
sc.c:195:sc_detect_card_presence: called
reader-pcsc.c:388:pcsc_detect_card_presence: called
reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check
reader-pcsc.c:325:refresh_attributes: current state: 0x00000120
reader-pcsc.c:326:refresh_attributes: previous state: 0x00000120
reader-pcsc.c:380:refresh_attributes: card present
reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5
sc.c:200:sc_detect_card_presence: returning with: 5
card.c:125:sc_connect_card: called
reader-pcsc.c:468:pcsc_connect: called
reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check

Any clues?


-scooter

(*) Would it be permissible to mark unused parameters in static functions as unused? Really. It gets in the way of tracking down interesting problems, like signed/unsigned conversions, integer length issues, ... If the code has to compile with -Wall, then the code could be selective with respect to which are really important warnings, no?
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Two back-to-back runs, different results

Douglas E. Engert


On 9/5/2012 12:48 PM, Scott Michel wrote:

> I am trying to debug an issue with the SCM 311 reader and Oberthur ID One card in order to better support Macs and smart card-enabled sites. I've been using pkcs15-tool to list certificates on the card. The result is that on the first run with the card inserted for the first time, certificates are listed. On the next, second run, no certificates are listed; pkcs15-tool reports no certificates.
>
> Turning up the debugging volume, I get the following unified diff output (/tmp/run-11 is the first run, /tmp/run-22 is the second run, timestamps stripped). On the first run, the card is detected as a T0 protocol card. On the second run, the card is detected as a T1 protocol card. I'm fairly certain this is a problem (listing certificates requires APDU messages, not TPDU messages, no?), but not sure where to go look in the code to propose a patch. (*)
>
> --- /tmp/run-11 2012-09-05 10:12:04.000000000 -0700
> +++ /tmp/run-22 2012-09-05 10:12:08.000000000 -0700
> @@ -21,7 +21,7 @@
> reader-pcsc.c:325:refresh_attributes: current state: 0x00000120
> reader-pcsc.c:326:refresh_attributes: previous state: 0x00000120
> reader-pcsc.c:380:refresh_attributes: card present
> -reader-pcsc.c:497:pcsc_connect: Initial protocol: T0 protocol
> +reader-pcsc.c:497:pcsc_connect: Initial protocol: T1 protocol
> card.c:868:match_atr_table: ATR : 3b:db:96:00:80:1f:03:00:31:c0:64:b0:f3:10:00:07:90:00:80

That looks like a DoD CAC, Oberthur ID One 128 v5.5 Dual

and the ATR says the protocol is T0. But the card and reader may try
and negotiate T1. In a number of Oberthur documents it talks about ISO 7816-3
from 2006 supporting higher baud rates, and the card reader needs to be up to data.
It one it talks about a card appearing to be mute.

A pcscd debug trace might show something too.

Try a newer reader?

Is this a dual CAC and PIV card? (Does not look like it as the ATR for PIV has the
application.)

OpenSC only supports PIV or dual PIV and CAC.

You could also try coolkey that supports CAC.

> card.c:879:match_atr_table: ATR try : 3B:DD:18:00:81:31:FE:45:80:F9:A0:00:00:00:77:01:00:70:0A:90:00:8B
> card.c:882:match_atr_table: ignored - wrong length
>
> Leading up to this difference, both files have the same lines (again, timestamps stripped):
>
> sc.c:195:sc_detect_card_presence: called
> reader-pcsc.c:388:pcsc_detect_card_presence: called
> reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check
> reader-pcsc.c:325:refresh_attributes: current state: 0x00000120
> reader-pcsc.c:326:refresh_attributes: previous state: 0x00000122
> reader-pcsc.c:380:refresh_attributes: card present
> reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5
> sc.c:200:sc_detect_card_presence: returning with: 5
> Using reader with a card: SCM SCR 331 00 00
> sc.c:195:sc_detect_card_presence: called
> reader-pcsc.c:388:pcsc_detect_card_presence: called
> reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check
> reader-pcsc.c:325:refresh_attributes: current state: 0x00000120
> reader-pcsc.c:326:refresh_attributes: previous state: 0x00000120
> reader-pcsc.c:380:refresh_attributes: card present
> reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5
> sc.c:200:sc_detect_card_presence: returning with: 5
> card.c:125:sc_connect_card: called
> reader-pcsc.c:468:pcsc_connect: called
> reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check
>
> Any clues?

Try a different reader?

>
>
> -scooter
>
> (*) Would it be permissible to mark unused parameters in static functions as unused? Really. It gets in the way of tracking down interesting problems, like signed/unsigned conversions, integer length issues, ... If the code has to compile with -Wall, then the code could be selective with respect to which are really important warnings, no?
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  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-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Two back-to-back runs, different results

Douglas E. Engert
On 9/6/2012 9:54 PM, B. Scott Michel wrote:

> On 9/6/2012 1:38 PM, Douglas E. Engert wrote:
>>
>>
>> On 9/6/2012 11:39 AM, B. Scott Michel wrote:
>>> Tried another reader, the Cherry ST-1044U. pkcs15-tool identifies the
>>> card using card-piv.c's code using the T0 protocol and will correctly
>>> print the card's certificates -- the first time. Second run, though,
>>> same problem: card is subsequently identified as a T1 card, can't find
>>> certificates.
>>
>> What version of OpenSC and pcsc-lite are you running and on what
>> platform?
>> This sounds like an old problem.
>
> I'm tracking github and building from source - 0.13. I do an uninstall
> followed by an install from the resulting disk image (dmg).
Looking a the reader-pcsc.c code, it is not clear if the
reader->active_protocol is being set correctly.  The one piece of info you
sent in your initial note indicated it was changing from T0 to T1.

It looks like your card can only do T0, thus pcsc should not be saying
it is doing T1.

Attached is a patch based on the git repository from 0.13.0-pr1
that adds some additional debugging of the processing of the protocol
processing.

I suspect that the values of reader->active_protocol is not
1, 2, or 1000 as defined by SC_PROTO_* and may be 0, which should
not happen.

It may be that the version of pcsc on the MAC you have is not returning
a valid value for active_proto. That should be 1, 2 or 4. as defined by
SCARD_PROTOCOL_*
The output of a trace with this patch should
show if this is true or not.

>
>> It should not be changing from T=0 to T=1 after the card was working
>> with T=0 the first time.
>
> I figured as much, hence, my motivation to debug and potentially hack
> source code. Directors of Computer Systems Research Departments are
> expected to keep hacking skills in excellent shape (Aerospace is the
> "space" FFRDC in El Segundo, CA, if you're not familiar with us.)
>
>> pkcs15-tool -v -v -v -v -v -v -c
>>
>> then send the full output, from both the first and second times.
>
> Will do.
>
>> I have some older test cards that may be T=0, I will try them.
>> But I am gone till Monday.
>>
>> Something else to try, is to edit the opensc.conf. you can add
>> debug_file = somefilename;
>> debug = 9;
>>
>> This would cut out interference from other drivers:
>>
>>    force_card_driver = "piv";
>>
>> also try:
>>    force_protocol = "t0";
>>
>> (I have not tried the force_* options.)
> Will do.
>
>
> -scooter
>
>
--

  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-project.org/mailman/listinfo/opensc-devel

reader-pcsc.protocol.diff (1K) Download Attachment