On Tue, 2011-10-25 at 11:26 +0300, Martin Paljak wrote:
> Hello,
>
> On Tue, Oct 25, 2011 at 02:22, Andy Walls <[email protected]> wrote:
> > If the offer here still stands:
> >
> > http://www.opensc-project.org/pipermail/opensc-devel/2008-August/011252.html
> > http://www.opensc-project.org/opensc/wiki/RainbowIkeyFour
>
> The best bet is to contact them again, maybe they have changed their
> mind. You might want to try in parallel to get in contact with their
> support interface (it is often a lengthy process and getting to
> technically minded people who can and want to comment on anything
> might take some time)
I haven't contacted them yet, but I will soon.
> > I seem to have the iKey 4000 variant that is *not* USB CCID v1.10
> > compliant:
> That's a sad fact.
>
> > Since there is an IFD for the iKey2032 in OpenCT, maybe that can be used
> > as a starting point for an IFD for the iKey 4000.
> Probably.
After examination of the USB traces I have found that the iKey 4000 USB
protocol is almost identical to the iKey 3000, assuming OpenCT's
ifd-ikey3k.c code is correct.
The vendor protocol on the default control pipe seems to only have 4
values for "bRequest" in USB packets.
bmRequestType: 0x41 (Host to Device, Vendor, Interface)
bRequest: 0x16
wValue: varies
wIndex: 0x0000
Used for commanding what appear to be token and/or embedded
"reader" related functions. For example, wValue = 0x2 causes
the device to
respond with a PTS sequence: 0xff 0x11 0x11 0xff (PTSS PTS0 PTS1
PTSCK).
bmRequestType: 0x41 (Host to Device, Vendor, Interface)
bRequest: 0x17
wValue: varies
wIndex: varies
Used for sending APDUs to the embedded SafeNet/Datakey DK400
"SmartCard". wValue and wIndex appear to contain part of the
APDU, and the transfer payload contains the rest of the APDU.
bmRequestType: 0xc1 (Device to Host, Vendor, Interface)
bRequest: 0x01
wValue: 0x0000
wIndex: 0x0000
Used to fetch responses to the above request types
bmRequestType: 0xc1 (Device to Host, Vendor, Interface)
bRequest: 0x00
wValue: 0x0000
wIndex: 0x0000
Used to request some sort of firmware(?) information from the
device.
The wValue, wIndex, and transfer payload are covered by a simple
bytewise XOR-sum for bRequest = 0x17 commands and for the bRequest = 0x1
response to such commands.
> While at it, you can look at how to integrate OpenCT
> ifdhandler into pcsc-lite by default.
I'm not quite sure I understand what you would like here, but it seems
out of scope of my current objective.
I initially was going to write an IFDHandler for PC/SC-lite and modify
the CoolKey library to provide the PKCS-11 functions and provide a NSS
interface to FireFox, etc.
However, since OpenCT already had some iKey support, I decided to start
with OpenCT.
> You could also snoop the USB layer, maybe the card inside works with
> some existing driver with no or just a few modifications (or maybe
> just needs a custom profile)
The few APDU's I have examined, SELECT_FILE and READ_BINARY I think,
look like they match the StarCos cards to some degree.
The embedded "SmartCard" implementation is a DK400 according to the
Historical bytes in the ATR. I also observed in the USB snoop that the
OS is SafeNet's SCCOS v3.0 (likely an evolution of DKCCOS v2.0).
Anyway, slowly moving forward....
Regards,
Andy
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
