On Fri, 17 Mar 2006, Justin Karneges wrote:
I'd like to make ifd-eutron do the same thing, although I'm not sure of the
best approach. My "guess" is that SafeSign determines that the first
response is wrong, and then rerequests the ATR, but I don't know how this
wrongness would be detected, especially since the whole ATR string would need
to be read (and how do you determine the end of it if the data is wrong?).
The first byte of the atr must be 0x3B or 0x3F.
you can presumably detect the end of the sequence by waiting for the
device to stop sending data. (in this case, for the loop to exit with
c>=20. you would not treat that as an error though)
One idea I have is to just ignore a leading zero byte in the first response,
in which case I wouldn't even need to rerequest it. But this surely differs
from SafeSign's algorithm. What do you think?
It seem safe enough, for now. It's likely that if eutron intrduces a
device where that wouldn't work, other changes would have to be made to
the driver anyway.
Can you explain the "control bits" in the PCB, or refer me to some
documentation on it? The exchange I'm unsure about is this one:
I don't believe I have ever found documentation. src/ifd/proto-t1.c is a
good enough reference to answer this question, though.
send: 00 c1 01 fe 3e
recv: 00 e1 01 fe 1e
The 0x40 bit is set in here, but of course there are others too. I'd also
like to find out what the meaning of the content is as well (0xfe), to
determine whether or not this exchange belong in eutron_init.
It appears that the bits are not actually independent. 0x40 is only the
sequence bit in I-Blocks, which do not have bit 0x80 set.
this is a T1_S_BLOCK + T1_S_IFS request. safesign is negotiating a higher
T=1 block size with the device (and it succeeds).
eutron_init/eutron_card_reset should not do this, since openct's T=1 state
machine would not be prepared for it.
However, the SafeSign PTS sequence doesn't gain us anything more than
the ifd-eutron PTS sequence, because the card rejects the "parameters"
in either case, so for compatibility purposes we should leave the
ifd-eutron PTS alone.
makes sense to me.
Now, what I don't understand is why not sending PTS, and assuming T=0
protocol, fails to work. The card doesn't seem to default to T=1 either
It is unlikely that the card actually implements real T=0 framing when in
T=0 mode. In T=0, you send the first 5 bytes of the APDU, and then read an
ack byte. depending on its value, you either send data, recieve data, or
recieve status words. When dealing with slow serial devices, this saved
time. with usb devices, it costs time, and so they don't do it.
Try the attached patch. It introduces eutron_set_protocol. The only
functional change is that it tells T=0 that the device is "block
oriented", so it doesn't try to do it's own chunking.
eutron_set_protocol could be enhanced further to perform the PTS exchange
Index: src/ifd/ifd-eutron.c
===================================================================
--- src/ifd/ifd-eutron.c (revision 815)
+++ src/ifd/ifd-eutron.c (working copy)
@@ -171,6 +171,31 @@
return -1;
}
+static int
+eutron_set_protocol(ifd_reader_t *reader, int nslot, int proto)
+{
+ ifd_slot_t *slot;
+ slot = &reader->slot[nslot];
+
+ if (proto != IFD_PROTOCOL_T0 && proto != IFD_PROTOCOL_T1) {
+ ct_error("%s: protocol not supported", reader->name);
+ return -1;
+ }
+
+ slot->proto = ifd_protocol_new(proto, reader, slot->dad);
+ if (slot->proto == NULL) {
+ ct_error("%s: internal error", reader->name);
+ return -1;
+ }
+
+ /* Tell the protocol handler that we will do the framing */
+ if (proto == IFD_PROTOCOL_T0)
+ ifd_protocol_set_parameter(slot->proto,
+ IFD_PROTOCOL_BLOCK_ORIENTED, 1);
+
+ return 0;
+}
+
/*
* Driver operations
*/
@@ -189,6 +214,7 @@
eutron_driver.card_reset = eutron_card_reset;
eutron_driver.send = eutron_send;
eutron_driver.recv = eutron_recv;
+ eutron_driver.set_protocol = eutron_set_protocol;
ifd_driver_register("eutron", &eutron_driver);
}
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
