On Friday 17 March 2006 00:40, you wrote:
> > Could you briefly explain what each phase of this function is? There
> > seems to be a lot of calls to ifd_usb_control() in chunks or in loops.
>
> card_reset does exactly the same commands I saw in a lot. they
> worked. no changes at all. then there is a loop to receive the atr,
> which can come in several parts.
>
> we send some more magic packets back and forth, and the card seems
> to be initialized well.
Thank you for all the tips.
Also, see my other posts to the mailing list. I've managed to duplicate the
initialization sequence just like from the usb snoop log, and I can get the
ATR with openct now.
I put the ATR into the starcos table in opensc. However, when I run
opensc-tool, things go bad. Here's a more verbose output than what I mailed
earlier:
# opensc-tool -vvvvvvv --atr
sc.c:140:sc_detect_card_presence: called
reader-openct.c:208:openct_reader_detect_card_presence: called
sc.c:145:sc_detect_card_presence: returning with: 1
Connecting to card in reader Eutron CryptoIdentity ITSEC-P/FIPS...
card.c:372:sc_connect_card: called
reader-openct.c:232:openct_reader_connect: called
card.c:402:sc_connect_card: matching configured ATRs
card.c:447:sc_connect_card: matching built-in ATRs
[...snip lots of ATR matching debug lines...]
card.c:453:sc_connect_card: trying driver: starcos
card.c:961:match_atr_table: ATR :
3b:b7:18:00:c0:3e:31:fe:65:53:50:4b:32:34:90:00:25
card.c:969:match_atr_table: ATR try :
3B:B7:94:00:c0:24:31:fe:65:53:50:4b:32:33:90:00:b4
card.c:969:match_atr_table: ATR try :
3B:B7:94:00:81:31:fe:65:53:50:4b:32:33:90:00:d1
card.c:969:match_atr_table: ATR try :
3B:B7:18:00:C0:3E:31:FE:65:53:50:4B:32:34:90:00:25
card.c:459:sc_connect_card: matched: STARCOS SPK 2.3
card.c:487:sc_connect_card: card info: STARCOS SPK 2.3, 7001, 0x0
card.c:488:sc_connect_card: returning with: 0
Using card driver STARCOS SPK 2.3.
card.c:525:sc_lock: called
reader-openct.c:388:openct_reader_lock: called
Card ATR:
3B B7 18 00 C0 3E 31 FE 65 53 50 4B 32 34 90 00 ;....>1.eSPK24..
25 %
card.c:545:sc_unlock: called
card.c:550:sc_unlock: Calling card logout function
card.c:254:sc_transmit_apdu: called
card.c:221:sc_transceive: Sending 7 bytes (resp. 258 bytes):
00 A4 00 0C 02 3F 00 .....?.
card.c:228:sc_transceive: Unable to transmit: Generic reader error
card.c:263:sc_transmit_apdu: transceive() failed: Generic reader error
card-starcos.c:1341:starcos_logout: APDU re-transmit failed: Generic reader
error
reader-openct.c:415:openct_reader_unlock: called
card.c:500:sc_disconnect_card: called
reader-openct.c:281:openct_reader_disconnect: called
card.c:515:sc_disconnect_card: returning with: 0
ctx.c:716:sc_release_context: called
reader-openct.c:181:openct_reader_release: called
reader-openct.c:181:openct_reader_release: called
reader-openct.c:181:openct_reader_release: called
reader-openct.c:181:openct_reader_release: called
reader-openct.c:181:openct_reader_release: called
reader-openct.c:166:openct_reader_finish: called
From my own debugging in openct, I noticed that eutron_send is called for 5
bytes: 00 a4 00 0c 02. However, the opensc-tool output above looks like it
is trying to send 7 bytes. I don't know if this is the problem.
Maybe the card is still not initialized properly.
The usbsnoop log has more data exchanges, but I don't know what counts as
initialization and what counts as normal operations.
I've extracted the exchanges from the snoop log here:
ctrl: 42 a2
ctrl: 42 0a
ctrl: 42 09
ctrl: 42 09
recv: 3b b7 18 00 c0 3e 31 fe 65 53 50 4b 32 34 90 00
25 (;....>1.eSPK24..%)
send: ff 11 14 fa
recv: ff 01 fe
ctrl: 42 65 01
send: 00 c1 01 fe 3e
recv: 00 e1 01 fe 1e
send: 00 00 05 00 70 00 00 01 74
recv: 00 00 03 01 90 00 92
send: 00 40 05 00 70 00 00 01 34
recv: 00 40 03 02 90 00 d1
send: 00 00 07 01 a4 00 0c 02 50 31 cd
recv: 00 00 02 6a 82 ea
send: 00 40 11 01 a4 04 00 0c a0 00 00 00 63 50 4b 43
53 2d 31 35 1d ([EMAIL PROTECTED])
recv: 00 40 02 62 84 a4
send: 00 00 05 81 f6 00 01 0a 79
recv: 00 00 0c
recv: c2 08 24 84 0d 03 01 03 03 00 90 00 f9
send: 00 40 05 81 f6 00 00 08 3a
recv: 00 40 0a 04 90 50
recv: 55 00 18 2b 1d 90 00 65
send: 00 00 07 01 a4 00 0c 02 3f 00 93
recv: 00
recv: 00 02 90 00 92
send: 00 40 07 02 a4 00 0c 02 50 31 8e
recv: 00 40 02 6a 82 aa
Do these bytes make sense to anyone? The only thing notable to me is that the
2nd line from the last, as well as the 5th, contain similar data as what
opensc wants to send.
I've not yet put this in the code because surely this is much more than just
the initialization. The openct eutron init is 2 exchanges, and this log
shows 10 already. I hope you can make sense of this data and tell me where
the boundary is.
-Justin
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
