On Sun, 16 Apr 2006, Justin Karneges wrote:
But what about drivers? Does the same SafeSign driver installation work for
all 5 devices? This might mean that even though there are varying firmwares,
they probably operate very similarly if one driver can manage all of them.
There are 2 "driver" components. One is a "reader" driver, that talks to
the usb device (this one is common. euci5.sys on windows). The other is a
"card" driver that understands the card operating system and the
filesystem layout (this one is not common. eutron sent me 3 windows cd's.
One with safesign (for the FIPS and ITSEC-P, one with 'cryptkit' (for the
5 & 2048) and one with some siemens software (for the ITSEC-I). Each
package includes a pkcs11 module, a CSP, and some card management tools.
I don't think I was getting EOVERFLOW with my FIPS, though I'm not sure how to
check...
I think you are. Your earlier messages included something like this:
It then attempts to get a response, I think. The first read returns 0
(no data?) then a second read returns -5 (IFD_ERROR_COMM_ERROR). This
error comes from sys-linux.c as a result of the ioctl(). I don't know
why we'd be getting a subsystem error here.
....which matches my experience with the default card driver and the 5.
Yes, already initialized with SafeSign. How else would I test it? Is OpenSC
only intended for use with cards initialized by OpenSC?
OpenSC is intended for use with pkcs15 filesystems, which so far, has
meant only with cards initialized by OpenSC. Safesign should be an
exception, and I think I know what the problem is:
pkcs15 is an "application" wrt some chapter of 7816. There are 2 ways that
"application selection" is allowed to work. One is through the use of a
DIR file (3f00:2f00) which maps application ids onto paths. This is what
opensc uses. The other is called direct application selection and involves
the application's id being passed directly to the select file operation
(0xA4). If safesign does not create the DIR, then it is unlikely that
opensc will work out of the box. Once I get my tokens to a
closer-to-working state, I will probably try to make opensc support direct
selection.
Well, this is silly and stupid, yet unsurprising. I guess what we really want
is OpenSC support for the devices and then we can wipe our cards and throw
SafeSign out the window.
except for the small problem that it appears that the ITSEC-P doesn't
support the 'erase card' operation that card-starcos.c knows about, and
starcos doesn't support deleting individual EFs or DFs at all.
Ok. So, at this time, the ITSEC-I is the only model of the five that is known
to work in OpenSC.
We could have told you that weeks ago. I will by trying to get the ITSEC-P
and FIPS into a working state, but it's not a sure thing. the 5 & 2048 are
a much longer shot since their COS isn't supported by any free software. I
will be looking into writing a card driver for them based on usb traces,
but that will probably take more time than I'll be motivated to spend, and
I've already identified a pitfal: They do pin verification using EXTERNAL
AUTHENTICATE, so their crypto has to be derived (it's probably based on
7816-4, treating the pin as a des key, but if it isn't, it will be painful
and possibly impossible to reverse-engineer).
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
