On Tue, 2011-10-25 at 11:26 +0300, Martin Paljak wrote:
> Hello,
> 
> On Tue, Oct 25, 2011 at 02:22, Andy Walls <awa...@md.metrocast.net> 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
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to