Re: OpenSC support for iKey4000?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Andy Walls-3
Anthony Foiani <[hidden email]> wrote:

>Greetings!
>
>I found your message from last fall on the OpenSC devel list:
>
>http://www.opensc-project.org/pipermail/opensc-devel/2011-October/017307.html
>
>Have you been able to make any progress with this token?
>
>I'm in a similar situation, if not more extreme: I would like to
>support
>this on an embedded non-x86 target (PowerPC32).  So I get to deal with
>big
>vs. little endian, on top of everything else.
>
>Anyway.  If you've made any progress, I'd be very interested to hear
>about
>it.
>
>Best regards,
>Anthony Foiani


I added basic support for the embedded "card reader" but did nothing for the actual embedded "smart card".  I got very busy and didn't have time to pursue it.

I will post a patch to the list in a day or so.

Regards,
Andy
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Anthony Foiani
Andy --

On Sun, Feb 26, 2012 at 5:15 PM, Andy Walls <[hidden email]> wrote:
>
> I added basic support for the embedded "card reader" but did nothing for the actual embedded "smart card".  I got very busy and didn't have time to pursue it.

Understood.  Thanks for the update!

> I will post a patch to the list in a day or so.

Great, thank you!

I did find someone else who seems to have made some progress:

http://blog.go-lan.net/openct-ikey-4000-driver/

Although it looks like the iKey4000 comes in two flavors, one that is
CCID-compliant, and one that isn't?

04B9:1206 - no CCID, not supported
04B9:1400 - CCID, supported by libccid?

(This is from http://wiki.debian.org/Smartcards )

There also seems to be one commercial outfit that offers such a
driver, but I wasn't able to read their web page very well (I don't
speak Czech, and the Google translate version is only somewhat
helpful):

http://www.dignita.cz/produkty/linux-driver-pro-ikey4000

Anyway.  Thanks again for any help you can offer.

Best regards,
Anthony Foiani
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Ludovic Rousseau
Le 27 février 2012 01:54, Anthony Foiani <[hidden email]> a écrit :
> Although it looks like the iKey4000 comes in two flavors, one that is
> CCID-compliant, and one that isn't?
>
> 04B9:1206 - no CCID, not supported
> 04B9:1400 - CCID, supported by libccid?
>
> (This is from http://wiki.debian.org/Smartcards )

The second one is listed in the "Should work but untested by me" CCID list
http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400

So it should work out of the box with my CCID driver.

Bye

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Anthony Foiani
Ludovic --

On Mon, Feb 27, 2012 at 12:49 AM, Ludovic Rousseau
<[hidden email]> wrote:
> The second one [04B9:1400] is listed in the "Should work but untested by me" CCID list
> http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400
>
> So it should work out of the box with my CCID driver.

That's fantastic.

Now to see if there's an easy way to tell the difference between these
two types of iKey4000...

Thanks again!

Best regards,
Anthony Foiani
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Andy Walls-3
Anthony Foiani <[hidden email]> wrote:

>Ludovic --
>
>On Mon, Feb 27, 2012 at 12:49 AM, Ludovic Rousseau
><[hidden email]> wrote:
>> The second one [04B9:1400] is listed in the "Should work but untested
>by me" CCID list
>> http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400
>>
>> So it should work out of the box with my CCID driver.
>
>That's fantastic.
>
>Now to see if there's an easy way to tell the difference between these
>two types of iKey4000...
>
>Thanks again!
>
>Best regards,
>Anthony Foiani

The output of lsusb -v should tell you, IIRC.  If it is the CCID variant, lsusb should be able to tell you it is CCID.

Regards,
Andy



_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Ludovic Rousseau
In reply to this post by Anthony Foiani
Le 27 février 2012 18:46, Anthony Foiani <[hidden email]> a écrit :

> Ludovic --
>
> On Mon, Feb 27, 2012 at 12:49 AM, Ludovic Rousseau
> <[hidden email]> wrote:
>> The second one [04B9:1400] is listed in the "Should work but untested by me" CCID list
>> http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x04B90x1400
>>
>> So it should work out of the box with my CCID driver.
>
> That's fantastic.

Thanks :-)

> Now to see if there's an easy way to tell the difference between these
> two types of iKey4000...

You can use the "lsusb" command on GNU/Linux to display the USB Vendor
ID and Product ID.
But you need to _have_ the device first. So not really helpful if you
want to by one, unless you are allowed to bring it back and get your
money.

Bye

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Anthony Foiani
Andy, Ludovic --

On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau
<[hidden email]> wrote:
> Le 27 février 2012 18:46, Anthony Foiani <[hidden email]> a écrit :
>> Now to see if there's an easy way to tell the difference between these
>> two types of iKey4000...
>
> You can use the "lsusb" command on GNU/Linux to display the USB Vendor
> ID and Product ID.
> But you need to _have_ the device first. So not really helpful if you
> want to by one, unless you are allowed to bring it back and get your
> money.

The situation is actually a bit worse.  I'm working with an
organization that has already standardized on the iKey4000 and has
already issued them and integrated them into other parts of their
infrastructure.  I do have a handful of samples, but if both types are
already out in the field, then I need a solution that can accomodate
both.  :(

I read that SafeNet was open to providing the necessary documentation
under NDA; that might be one route.  Someone else also mentioned that
they have been able to communicate with an iKey4000, but it's not
clear which variety they are using.

Thanks very much for the help so far; I'll see what else I can find out.

Best regards,
Anthony Foiani
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Andreas Kroehnert-2
Hi Anthony,

I think its more beneficial to respond to this list, rather than just your comment you left on the blog.

The little OpenCT patch I've done was originally done for the "standard" ikey 4000 (04b9:1206). But should also work for the "non-standard" one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000)

Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid.

While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected.

It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now.

So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card.

I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days.

Kind Regards
Andreas

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Anthony Foiani
Andreas, greetings --

On Mon, Feb 27, 2012 at 12:54 PM, Andreas Kroehnert
<[hidden email]> wrote:
> Hi Anthony,
>
> I think its more beneficial to respond to this list, rather than just your comment you left on the blog.

Of course.  Thank you for replying so quickly and so thoroughly!

> The little OpenCT patch I've done was originally done for the "standard" ikey 4000 (04b9:1206). But should also work for the "non-standard" one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000)

Yes, it's a mess.

It seems that SafeNet has sold a few different combinations of
reader+smartcard all under the "iKey4000" name.  Their NDA
requirements might even be driven by the variety of suppliers...

I just went through and checked my 6 samples: they're all 0x1206 variants.

> Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid.
>
> While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected.
>
> It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now.

Hm.  Maybe these are enough hints for me to do some digging on my own.

I won't be able to look at it in detail for a few weeks yet; I was
sending out emails to try to get a sense of where the community stands
regarding support for this token.

> So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card.

Right.  I'm looking forward to seeing your code, when you get the
opportunity to rebuild that RAID...

> I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days.

Ouch, sorry to hear about that.  That never happens at a convenient
time, does it...

Thanks once again for your help!

Best regards,
Anthony Foiani
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Douglas E. Engert
In reply to this post by Andreas Kroehnert-2


On 2/27/2012 1:54 PM, Andreas Kroehnert wrote:

> Hi Anthony,
>
> I think its more beneficial to respond to this list, rather than just your comment you left on the blog.
>
> The little OpenCT patch I've done was originally done for the "standard" ikey 4000 (04b9:1206). But should also work for the "non-standard" one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000)
>
> Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid.
>
> While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected.
>
> It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now.

PIV? Really?  If so it should respond to the NIST 800-73 part 2
SELECT Card Command with the AID of the PIV application.
You can try this opensc-tool command to see if it responds
with a PIV application on the device:


opensc-tool -s 00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00

What does it return?

If their goal is to have this device as a PIV and usable on Windows,
I would expect to be CCID as well.

>
> So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card.
>
> I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days.
>
> Kind Regards
> Andreas
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Douglas E. Engert

This document found by Google, and located at NIST, has some interesting
information:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp943.pdf

It looks like it defines many of the additional provisioning commands
(But does not list the actual APDUs for these) that would allow the iKey400
to act like a PIV card after it had been provisioned.


On 2/27/2012 3:55 PM, Douglas E. Engert wrote:

>
>
> On 2/27/2012 1:54 PM, Andreas Kroehnert wrote:
>> Hi Anthony,
>>
>> I think its more beneficial to respond to this list, rather than just your comment you left on the blog.
>>
>> The little OpenCT patch I've done was originally done for the "standard" ikey 4000 (04b9:1206). But should also work for the "non-standard" one (04b9:1400). I am not sure what to order at SafeNet to get the 1400 one, could be the old CIP initialised, kinda old-school version, but I am not sure. However all 4k tokens I've collected over the years, even the latest, come with a PID of 1206. (Which actually should be an ikey 2k series PID. To mess it up even more SafeNet now renamed/rebranded the ikey 4000 to eToken 5000)
>>
>> Back to topic: In general its claimed that regardless of the PID, the ikey4000 / SC400 is a CCID compliant device, but I never got it to work using libccid.
>>
>> While developing the first attempt of the patch I was confused why the ATR from the card contains a trailing byte before it continues with 0x3B... Might be that this is messing up the CCID compatibility. For the moment I've just chopped that first byte off and the card mostly responds as expected.
>>
>> It's also said that once the ATR has been sent the card shall behave according to PIV for most commands. I wasn't able to confirm that either as of now.
>
> PIV? Really?  If so it should respond to the NIST 800-73 part 2
> SELECT Card Command with the AID of the PIV application.
> You can try this opensc-tool command to see if it responds
> with a PIV application on the device:
>
>
> opensc-tool -s 00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00
>
> What does it return?
>
> If their goal is to have this device as a PIV and usable on Windows,
> I would expect to be CCID as well.
>
>>
>> So far I got some new commercial assignments, so I didn't have a chance to continue with the development. The next stage (as said in the blog) is to get OpenSC patched to support the card.
>>
>> I am happy to provide the code I've done so far, unfortunately I've done it on a VM that is now on a crashed RAID, which I switched off to wait for replacement disks before I make any recovery attempts. Which should hopefully in the next few days.
>>
>> Kind Regards
>> Andreas
>>
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>
>>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Andy Walls-3
In reply to this post by Anthony Foiani
On Mon, 2012-02-27 at 12:23 -0700, Anthony Foiani wrote:

> Andy, Ludovic --
>
> On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau
> <[hidden email]> wrote:
> > Le 27 février 2012 18:46, Anthony Foiani <[hidden email]> a écrit :
> >> Now to see if there's an easy way to tell the difference between these
> >> two types of iKey4000...
> >
> > You can use the "lsusb" command on GNU/Linux to display the USB Vendor
> > ID and Product ID.
> > But you need to _have_ the device first. So not really helpful if you
> > want to by one, unless you are allowed to bring it back and get your
> > money.
>
> The situation is actually a bit worse.  I'm working with an
> organization that has already standardized on the iKey4000 and has
> already issued them and integrated them into other parts of their
> infrastructure.  I do have a handful of samples, but if both types are
> already out in the field, then I need a solution that can accomodate
> both.  :(

Well, you'll have to build a solution that proerly layers and abstracts
the "reader" from the "smart card" that will be difficult.

The CCID version (which I don't have) likely follows the USB CCID
specification:

http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf


The non-CCID version certainly does not.

From analysis of USB snoops in Windows, the non-CCID iKey4000 uses a
verdor proprietary protocol.  All transfers occur on the USB control
pipe with only a 1 or 2 transactions not using a USB vendor proprietary
protocol.  The end part of a control packet from USB host to device in
the protocol are used to specify the command to the device and indicates
if a command is for:

1. the device itself (neither reader nor smartcard from what I can
guess)
2. the reader
3. the smart-card (PDUs encapsulated in T=1 transport IIRC)

Manipulating the reader and device itself isn't all that interesting.

The Transport PDU encapsulation and some of the APDUs are clearly
following the ISO standards.  However, there are a number of what appear
to be vendor proprietary APDUs.

I personally think implementing support for the iKey4000 "smart card" is
hopeless without documentation from SafeNet.

If this is really for a business, contact SafeNet and ask if they have a
solutions partner that can develop a Linux solution for your
organization.  It will likely be money well spent, compared to the labor
hours you will burn through trying to implement something with no
documentation.  If Open Source is important to you for long term
supportability in house, maybe you can inquire about the cost of the
solutions partner implementing an open source solution for you.

Regards,
Andy





_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Andy Walls-3
On Tue, 2012-02-28 at 06:33 -0500, Andy Walls wrote:
> On Mon, 2012-02-27 at 12:23 -0700, Anthony Foiani wrote:
> > Andy, Ludovic --
> >
> > On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau
> > <[hidden email]> wrote:
> > > Le 27 février 2012 18:46, Anthony Foiani <[hidden email]> a écrit :

> >
> > The situation is actually a bit worse.  I'm working with an
> > organization that has already standardized on the iKey4000 and has
> > already issued them and integrated them into other parts of their
> > infrastructure.  I do have a handful of samples, but if both types are
> > already out in the field, then I need a solution that can accomodate
> > both.  :(
>
> Well, you'll have to build a solution that proerly layers and abstracts
> the "reader" from the "smart card" that will be difficult.

Sorry, I meant to type:

'You'll have to build a solution that properly layers and abstracts
the "reader" from the "smart card"'.


Regards,
Andy

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Anders Rundgren
On 2012-02-28 12:53, Andy Walls wrote:

> On Tue, 2012-02-28 at 06:33 -0500, Andy Walls wrote:
>> On Mon, 2012-02-27 at 12:23 -0700, Anthony Foiani wrote:
>>> Andy, Ludovic --
>>>
>>> On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau
>>> <[hidden email]> wrote:
>>>> Le 27 février 2012 18:46, Anthony Foiani <[hidden email]> a écrit :
>
>>>
>>> The situation is actually a bit worse.  I'm working with an
>>> organization that has already standardized on the iKey4000 and has
>>> already issued them and integrated them into other parts of their
>>> infrastructure.  I do have a handful of samples, but if both types are
>>> already out in the field, then I need a solution that can accomodate
>>> both.  :(
>>
>> Well, you'll have to build a solution that proerly layers and abstracts
>> the "reader" from the "smart card" that will be difficult.
>
> Sorry, I meant to type:
>
> 'You'll have to build a solution that properly layers and abstracts
> the "reader" from the "smart card"'.

Or convert it to PIV as Douglas indicated is supported.
Then you get built-in support from at least Apple and Microsoft.

Regards,
Anders

>
>
> Regards,
> Andy
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Douglas E. Engert


On 2/28/2012 8:47 AM, Anders Rundgren wrote:

> On 2012-02-28 12:53, Andy Walls wrote:
>> On Tue, 2012-02-28 at 06:33 -0500, Andy Walls wrote:
>>> On Mon, 2012-02-27 at 12:23 -0700, Anthony Foiani wrote:
>>>> Andy, Ludovic --
>>>>
>>>> On Mon, Feb 27, 2012 at 11:15 AM, Ludovic Rousseau
>>>> <[hidden email]>  wrote:
>>>>> Le 27 février 2012 18:46, Anthony Foiani<[hidden email]>  a écrit :
>>
>>>>
>>>> The situation is actually a bit worse.  I'm working with an
>>>> organization that has already standardized on the iKey4000 and has
>>>> already issued them and integrated them into other parts of their
>>>> infrastructure.  I do have a handful of samples, but if both types are
>>>> already out in the field, then I need a solution that can accomodate
>>>> both.  :(
>>>
>>> Well, you'll have to build a solution that proerly layers and abstracts
>>> the "reader" from the "smart card" that will be difficult.
>>
>> Sorry, I meant to type:
>>
>> 'You'll have to build a solution that properly layers and abstracts
>> the "reader" from the "smart card"'.
>
> Or convert it to PIV as Douglas indicated is supported.
> Then you get built-in support from at least Apple and Microsoft.

Its not just convert it to PIV, as PIV standards cover the card,
not the reader.

http://fips201ep.cio.gov/apl.php

Lists "Rransparent Reader" which AFAIK does not a requirement
CCID, allowing vendor to provide reader drivers.)  (I don't see
the iKey4000 on the list yet.)

There is still the issue that some of these tokens appear to be CCID
compliant, and some are not and you can not tell until you buy the
token.

The vendor could provide the Windows or Mac "reader" driver for
the non-CCID tokens and still use the Microsoft or Apple PIV
"card driver". (I am just speculating on this...)
There are other readers vendors that provide drivers for their
readers that are not CCID so why not this vendor.



>
> Regards,
> Anders
>
>>
>>
>> Regards,
>> Andy
>>
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

[PATCH] OpenCT: IFD for non-CCID iKey4000

Andy Walls-3
In reply to this post by Andy Walls-3
On Sun, 2012-02-26 at 19:15 -0500, Andy Walls wrote:

> Anthony Foiani <[hidden email]> wrote:
>
> >Greetings!
> >
> >I found your message from last fall on the OpenSC devel list:
> >
> >http://www.opensc-project.org/pipermail/opensc-devel/2011-October/017307.html
> >
> >Have you been able to make any progress with this token?
> >
> >I'm in a similar situation, if not more extreme: I would like to
> >support
> >this on an embedded non-x86 target (PowerPC32).  So I get to deal with
> >big
> >vs. little endian, on top of everything else.
> >
> >Anyway.  If you've made any progress, I'd be very interested to hear
> >about
> >it.
> >
> >Best regards,
> >Anthony Foiani
>
>
> I added basic support for the embedded "card reader" but did nothing
> for the actual embedded "smart card".  I got very busy and didn't have
> time to pursue it.
>
> I will post a patch to the list in a day or so.
>
> Regards,
> Andy

As promised here is the patch to OpenCT.  It is a simple modified copy
of an OpenCT IFD for another iKey token.

This IFD does just enough to recognize the token and get it initialized.
It also has routines for sending and receiving payloads that should be
T=1 TPDUs  (Control Pipe transactions with URBs that perfrom Vendor
Writes with bRequest = 23 (0x17) and Vendor Reads with bRequest = 1
(0x1)).  It doesn't do anything fancy like control the LED or actively
reset the reader/device (URBs with Vendor Write and bRequest = 22
(0x16)).

I also have some decoded USB snoops with notes added which may help with
development.  I'll clean those up and post them it someone needs them.

Regards,
Andy

--- openct-0.6.18/src/ifd/internal.h.orig 2011-10-30 14:56:04.296516475 -0400
+++ openct-0.6.18/src/ifd/internal.h 2011-10-30 14:56:20.494978740 -0400
@@ -129,6 +129,7 @@ extern void ifd_eutron_register(void);
 extern void ifd_gempc_register(void);
 extern void ifd_ikey2k_register(void);
 extern void ifd_ikey3k_register(void);
+extern void ifd_ikey4k_register(void);
 extern void ifd_kaan_register(void);
 extern void ifd_pertosmart_ac1030_register(void);
 extern void ifd_pertosmart_ac1038_register(void);
--- openct-0.6.18/src/ifd/init.c.orig 2011-10-30 14:55:21.480516407 -0400
+++ openct-0.6.18/src/ifd/init.c 2011-10-30 14:55:38.277391367 -0400
@@ -34,6 +34,7 @@ int ifd_init(void)
  ifd_gempc_register();
  ifd_ikey2k_register();
  ifd_ikey3k_register();
+ ifd_ikey4k_register();
  ifd_kaan_register();
  ifd_pertosmart_ac1030_register();
  ifd_pertosmart_ac1038_register();
--- openct-0.6.18/src/ifd/Makefile.am.orig 2011-10-30 14:46:42.989393044 -0400
+++ openct-0.6.18/src/ifd/Makefile.am 2011-10-30 14:48:32.921052120 -0400
@@ -13,7 +13,7 @@ libifd_la_SOURCES = \
  ifd-etoken.c ifd-etoken64.c ifd-eutron.c ifd-gempc.c ifd-ikey2k.c \
  ifd-ikey3k.c ifd-kaan.c ifd-pertosmart1030.c ifd-pertosmart1038.c \
  ifd-smartboard.c ifd-smph.c ifd-starkey.c ifd-towitoko.c cardman.h \
- ifd-cyberjack.c ifd-rutoken.c ifd-epass3k.c \
+ ifd-cyberjack.c ifd-rutoken.c ifd-epass3k.c ifd-ikey4k.c \
  \
  proto-gbp.c proto-sync.c proto-t0.c proto-t1.c \
  proto-trans.c proto-escape.c \
--- openct-0.6.18/src/ifd/Makefile.in.orig 2011-10-30 14:46:51.866517905 -0400
+++ openct-0.6.18/src/ifd/Makefile.in 2011-10-30 14:52:14.350540529 -0400
@@ -71,6 +71,7 @@ am_libifd_la_OBJECTS = libifd_la-apdu.lo
  libifd_la-ifd-smph.lo libifd_la-ifd-starkey.lo \
  libifd_la-ifd-towitoko.lo libifd_la-ifd-cyberjack.lo \
  libifd_la-ifd-rutoken.lo libifd_la-ifd-epass3k.lo \
+ libifd_la-ifd-ikey4k.lo \
  libifd_la-proto-gbp.lo libifd_la-proto-sync.lo \
  libifd_la-proto-t0.lo libifd_la-proto-t1.lo \
  libifd_la-proto-trans.lo libifd_la-proto-escape.lo \
@@ -272,7 +273,7 @@ libifd_la_SOURCES = \
  ifd-etoken.c ifd-etoken64.c ifd-eutron.c ifd-gempc.c ifd-ikey2k.c \
  ifd-ikey3k.c ifd-kaan.c ifd-pertosmart1030.c ifd-pertosmart1038.c \
  ifd-smartboard.c ifd-smph.c ifd-starkey.c ifd-towitoko.c cardman.h \
- ifd-cyberjack.c ifd-rutoken.c ifd-epass3k.c \
+ ifd-cyberjack.c ifd-rutoken.c ifd-epass3k.c ifd-ikey4k.c \
  \
  proto-gbp.c proto-sync.c proto-t0.c proto-t1.c \
  proto-trans.c proto-escape.c \
@@ -409,6 +410,7 @@ distclean-compile:
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libifd_la-ifd-gempc.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libifd_la-ifd-ikey2k.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libifd_la-ifd-ikey3k.Plo@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libifd_la-ifd-ikey4k.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libifd_la-ifd-kaan.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libifd_la-ifd-pertosmart1030.Plo@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libifd_la-ifd-pertosmart1038.Plo@am__quote@
@@ -682,6 +684,13 @@ libifd_la-ifd-ikey3k.lo: ifd-ikey3k.c
 @AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
 @am__fastdepCC_FALSE@ $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libifd_la_CFLAGS) $(CFLAGS) -c -o libifd_la-ifd-ikey3k.lo `test -f 'ifd-ikey3k.c' || echo '$(srcdir)/'`ifd-ikey3k.c
 
+libifd_la-ifd-ikey4k.lo: ifd-ikey4k.c
+@am__fastdepCC_TRUE@ $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libifd_la_CFLAGS) $(CFLAGS) -MT libifd_la-ifd-ikey4k.lo -MD -MP -MF $(DEPDIR)/libifd_la-ifd-ikey4k.Tpo -c -o libifd_la-ifd-ikey4k.lo `test -f 'ifd-ikey4k.c' || echo '$(srcdir)/'`ifd-ikey4k.c
+@am__fastdepCC_TRUE@ mv -f $(DEPDIR)/libifd_la-ifd-ikey4k.Tpo $(DEPDIR)/libifd_la-ifd-ikey4k.Plo
+@AMDEP_TRUE@@am__fastdepCC_FALSE@ source='ifd-ikey4k.c' object='libifd_la-ifd-ikey4k.lo' libtool=yes @AMDEPBACKSLASH@
+@AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@am__fastdepCC_FALSE@ $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libifd_la_CFLAGS) $(CFLAGS) -c -o libifd_la-ifd-ikey4k.lo `test -f 'ifd-ikey4k.c' || echo '$(srcdir)/'`ifd-ikey4k.c
+
 libifd_la-ifd-kaan.lo: ifd-kaan.c
 @am__fastdepCC_TRUE@ $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libifd_la_CFLAGS) $(CFLAGS) -MT libifd_la-ifd-kaan.lo -MD -MP -MF $(DEPDIR)/libifd_la-ifd-kaan.Tpo -c -o libifd_la-ifd-kaan.lo `test -f 'ifd-kaan.c' || echo '$(srcdir)/'`ifd-kaan.c
 @am__fastdepCC_TRUE@ mv -f $(DEPDIR)/libifd_la-ifd-kaan.Tpo $(DEPDIR)/libifd_la-ifd-kaan.Plo
--- openct-0.6.18/src/ifd/ifd-ikey4k.c.orig 2011-10-30 14:46:21.127394309 -0400
+++ openct-0.6.18/src/ifd/ifd-ikey4k.c 2011-10-30 14:43:58.298393989 -0400
@@ -0,0 +1,181 @@
+/*
+ * driver for SafeNet iKey 4000 devices
+ *
+ * Copyright (C) 2003, Andreas Jellinghaus <[hidden email]>
+ * Copyright (C) 2003, Olaf Kirch <[hidden email]>
+ * Copyright (C) 2011, Andy Walls <[hidden email]>
+ */
+
+#include "internal.h"
+#include <stdlib.h>
+#include <string.h>
+
+/*
+ * Initialize the device
+ */
+static int ikey4k_open(ifd_reader_t * reader, const char *device_name)
+{
+ ifd_device_t *dev;
+ ifd_device_params_t params;
+
+ reader->name = "SafeNet iKey 4000";
+ reader->nslots = 1;
+ if (!(dev = ifd_device_open(device_name)))
+ return -1;
+ if (ifd_device_type(dev) != IFD_DEVICE_TYPE_USB) {
+ ct_error("ikey4k: device %s is not a USB device", device_name);
+ ifd_device_close(dev);
+ return -1;
+ }
+
+ params = dev->settings;
+ params.usb.interface = 0;
+ if (ifd_device_set_parameters(dev, &params) < 0) {
+ ct_error("ikey4k: setting parameters failed", device_name);
+ ifd_device_close(dev);
+ return -1;
+ }
+
+ reader->device = dev;
+
+ return 0;
+}
+
+/*
+ * Power up the reader
+ */
+static int ikey4k_activate(ifd_reader_t * reader)
+{
+ return 0;
+}
+
+static int ikey4k_deactivate(ifd_reader_t * reader)
+{
+ return -1;
+}
+
+/*
+ * Card status - always present
+ */
+static int ikey4k_card_status(ifd_reader_t * reader, int slot, int *status)
+{
+ *status = IFD_CARD_PRESENT;
+ return 0;
+}
+
+/*
+ * Reset - nothing to be done?
+ * We should do something to make it come back with all state zapped
+ */
+static int ikey4k_card_reset(ifd_reader_t * reader, int slot, void *atr,
+     size_t size)
+{
+ ifd_device_t *dev = reader->device;
+ unsigned char buffer[256];
+ int rc, n, atrlen;
+
+ unsigned char expect5[] =
+    { 0x13, 0x68, 0x01, 0x10, 0x2d, 0x2d, 0xc0, 0x81, 0x84, 0x60 };
+ unsigned char expect11[] = { 0xff, 0x11, 0x11, 0xff };
+
+ if (ifd_usb_control(dev, 0xc1, 0x00, 0, 0, buffer, 0x40, -1) != 0x40
+    || memcmp(buffer, expect5, sizeof(expect5)) != 0
+    || ifd_usb_control(dev, 0x41, 0x16, 0, 0, buffer, 00, -1) != 0
+    || ifd_usb_control(dev, 0xc1, 0x01, 0, 0, buffer, 02, -1) != 1
+    || buffer[0] != 00)
+ goto failed;
+
+ rc = ifd_usb_control(dev, 0x41, 0x16, 0x2005, 0, buffer, 0, 1000);
+ if (rc < 0)
+ goto failed;
+
+ rc = ifd_usb_control(dev, 0xc1, 0x01, 0, 0, buffer, 0x20, 1000);
+ if (rc <= 0)
+ goto failed;
+
+ n = buffer[0];
+ if (n + 1 > rc)
+ goto failed;
+ if (n > IFD_MAX_ATR_LEN)
+ goto failed;
+
+ if (n > size)
+ n = size;
+ atrlen = n;
+ memcpy(atr, buffer + 1, atrlen);
+
+ if (ifd_usb_control(dev, 0x41, 0x16, 0x0002, 0, buffer, 0, -1) != 0
+    || ifd_usb_control(dev, 0xc1, 0x01, 0, 0, buffer, 04, -1) != 4
+    || memcmp(buffer, expect11, sizeof(expect11)) != 0)
+ goto failed;
+
+ return atrlen;
+
+      failed:
+ ct_error("ikey4k: failed to activate token");
+ return -1;
+}
+
+/*
+ * Select a protocol. We override this function to be able to set the T=1 IFSC
+ */
+static int ikey4k_set_protocol(ifd_reader_t * reader, int nslot, int proto)
+{
+ ifd_slot_t *slot = &reader->slot[nslot];
+ int r;
+
+ if (!(slot->proto = ifd_protocol_new(proto, reader, slot->dad)))
+ return -1;
+
+ if (proto == IFD_PROTOCOL_T1) {
+ r = ifd_protocol_set_parameter(slot->proto,
+       IFD_PROTOCOL_T1_IFSC, 256);
+ if (r < 0)
+ return r;
+ }
+
+ return 0;
+}
+
+/*
+ * Send/receive routines
+ */
+static int ikey4k_send(ifd_reader_t * reader, unsigned int dad,
+       const unsigned char *buffer, size_t len)
+{
+ int value, idx;
+ value = buffer[1] << 8 | buffer[0];
+ idx = buffer[3] << 8 | buffer[2];
+
+ return ifd_usb_control(reader->device, 0x41, 0x17, value, idx,
+       (void *)&buffer[4], len - 4, -1);
+}
+
+static int ikey4k_recv(ifd_reader_t * reader, unsigned int dad,
+       unsigned char *buffer, size_t len, long timeout)
+{
+ return ifd_usb_control(reader->device, 0xc1, 0x01, 0, 0,
+       buffer, 255, timeout);
+}
+
+/*
+ * Driver operations
+ */
+static struct ifd_driver_ops ikey4k_driver;
+
+/*
+ * Initialize this module
+ */
+void ifd_ikey4k_register(void)
+{
+ ikey4k_driver.open = ikey4k_open;
+ ikey4k_driver.activate = ikey4k_activate;
+ ikey4k_driver.deactivate = ikey4k_deactivate;
+ ikey4k_driver.card_status = ikey4k_card_status;
+ ikey4k_driver.card_reset = ikey4k_card_reset;
+ ikey4k_driver.set_protocol = ikey4k_set_protocol;
+ ikey4k_driver.send = ikey4k_send;
+ ikey4k_driver.recv = ikey4k_recv;
+
+ ifd_driver_register("ikey4k", &ikey4k_driver);
+}
--- openct-0.6.18/solaris/openct.conf-dist.orig 2011-10-30 15:21:39.992516476 -0400
+++ openct-0.6.18/solaris/openct.conf-dist 2011-10-30 15:24:04.737518540 -0400
@@ -52,6 +52,11 @@ driver ikey3k {
  usb:04b9/1300,
  };
 };
+driver ikey4k {
+ ids = {
+ usb:04b9/1206,
+ };
+};
 driver cardman {
  ids = {
  usb:076b/0596, # OMNIKEY CardMan 2020
--- openct-0.6.18/etc/openct.usermap.orig 2011-10-30 15:26:00.430391387 -0400
+++ openct-0.6.18/etc/openct.usermap 2011-10-30 15:29:38.238391017 -0400
@@ -18,6 +18,8 @@ openct     0x0003      0x073d   0x0005
 openct     0x0003      0x04b9   0x1200    0x0000       0x0000       0x00         0x00            0x00            0x00            0x00               0x00               0x00000000
 # ikey3k
 openct     0x0003      0x04b9   0x1300    0x0000       0x0000       0x00         0x00            0x00            0x00            0x00               0x00               0x00000000
+# ikey4k
+openct     0x0003      0x04b9   0x1206    0x0000       0x0000       0x00         0x00            0x00            0x00            0x00               0x00               0x00000000
 # starkey
 openct     0x0003      0x096e   0x0005    0x0000       0x0000       0x00         0x00            0x00            0x00            0x00               0x00               0x00000000
 # cardman
--- openct-0.6.18/etc/openct.udev.in.orig 2011-10-30 15:25:38.213391328 -0400
+++ openct-0.6.18/etc/openct.udev.in 2011-10-30 15:27:44.555394434 -0400
@@ -38,6 +38,8 @@ SYSFS{idVendor}=="073d", SYSFS{idProduct
 SYSFS{idVendor}=="04b9", SYSFS{idProduct}=="1200", RUN+="@udevdir@/openct_usb"
 # ikey3k
 SYSFS{idVendor}=="04b9", SYSFS{idProduct}=="1300", RUN+="@udevdir@/openct_usb"
+# ikey4k
+SYSFS{idVendor}=="04b9", SYSFS{idProduct}=="1206", RUN+="@udevdir@/openct_usb"
 # starkey
 SYSFS{idVendor}=="096e", SYSFS{idProduct}=="0005", RUN+="@udevdir@/openct_usb"
 # cardman
--- openct-0.6.18/etc/openct.conf.in.orig 2011-10-30 15:25:26.162516480 -0400
+++ openct-0.6.18/etc/openct.conf.in 2011-10-30 15:26:49.781540842 -0400
@@ -98,6 +98,11 @@ driver ikey3k {
  usb:04b9/1300,
  };
 };
+driver ikey4k {
+ ids = {
+ usb:04b9/1206,
+ };
+};
 driver starkey {
  ids = {
  usb:096e/0005,
--- openct-0.6.18/etc/openct.udev.modalias.in.orig 2011-10-30 15:25:52.214391522 -0400
+++ openct-0.6.18/etc/openct.udev.modalias.in 2011-10-30 15:28:23.123428697 -0400
@@ -27,6 +27,8 @@ ENV{MODALIAS}=="usb:v073Dp0005*", RUN+="
 ENV{MODALIAS}=="usb:v04B9p1200*", RUN+="@udevdir@/openct_usb"
 # ikey3k
 ENV{MODALIAS}=="usb:v04B9p1300*", RUN+="@udevdir@/openct_usb"
+# ikey4k
+ENV{MODALIAS}=="usb:v04B9p1206*", RUN+="@udevdir@/openct_usb"
 # starkey
 ENV{MODALIAS}=="usb:v096Ep0005*", RUN+="@udevdir@/openct_usb"
 # cardman


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenSC support for iKey4000?

Andy Walls-3
In reply to this post by Andreas Kroehnert-2
On Mon, 2012-02-27 at 20:54 +0100, Andreas Kroehnert wrote:
> Hi Anthony,
>
> ( To mess it up even more SafeNet now renamed/rebranded the ikey 4000
> to eToken 5000)

FWIW, SafeNet bought DataKey and the DataKey Card Operating System
(DKCOS) (which RainBow had licensed from DataKey BTW) and SafeNet
renamed DKCOS to SafeNet Cryptographic Card Operating System (SCCOS).


> Back to topic: In general its claimed that regardless of the PID, the
> ikey4000 / SC400 is a CCID compliant device, but I never got it to
> work using libccid.

The two iKey4000 tokens I had worked with certainly are not CCID
compliant.  The USB descriptors for CCID device don't exist on them.
They also only use the USB control pipe AFAICT.


> While developing the first attempt of the patch I was confused why the
> ATR from the card contains a trailing byte before it continues with
> 0x3B...

FWIW that extra byte is the length of the ATR and Historical bytes that
follow:

URB[14-15]
  ControlTransfer
    bRequestType: 0x41 (Write-Vendor-Interface)
    bRequest: 22          ---> 0x16 (22): command for reader (usually)
    wValue: 8197 (0x2005) ---> 0x05: Get ATR?   0x20: Fetch only 32 (0x20) bytes
    wIndex: 0 (0x0000)
    wLength: 0

URB[16-17]
struct AnswerToReset
{
        u8 length;         /* 0x19 = 25 meaningful bytes follow */
        u8 atr[9];         /* Defined in ISO std for smartcards: TS - TD */
        u8 historical[16]; /* historical bytes: Type, Key-Len Val, Key-Len Val and XORsum */
        u8 crud[6];
};
  ControlTransfer
    data:
     0000: 19 3b ff 18 00 00 81 31 fe 4d 80 25 a0 00 00 00 |  ;     1 M %     |
     0010: 56 57 44 4b 34 30 30 06 00 dd c8 40 02 01 a0 00 | VWDK400    @     |
    bRequestType: 0xc1 (Read-Vendor-Interface)
    bRequest: 1
    wValue: 0 (0x0000)
    wIndex: 0 (0x0000)
    wLength: 32

The "smart card" is internally a DataKey 400 (DK400).  Sending that ATR
through the online ATR parser yields the following:


Parsing ATR: 3B FF 18 00 00 81 31 FE 4D 80 25 A0 00 00 00 56 57 44 4B 34 30 30 06 00 DD
TS = 0x3B Direct Convention
T0 = 0xFF Y(1): b1111, K: 15 (historical bytes)
TA(1) = 0x18 Fi=372, Di=12, 31 cycles/ETU (129032 bits/s at 4.00 MHz, 161290 bits/s for fMax=5 MHz)
TB(1) = 0x00 VPP is not electrically connected
TC(1) = 0x00 Extra guard time: 0
TD(1) = 0x81 Y(i+1) = b1000, Protocol T=1
----
TD(2) = 0x31 Y(i+1) = b0011, Protocol T=1
----
TA(3) = 0xFE IFSC: 254
TB(3) = 0x4D Block Waiting Integer: 4 - Character Waiting Integer: 13
----
Historical bytes 80 25 A0 00 00 00 56 57 44 4B 34 30 30 06 00
Category indicator byte: 0x80
 (compact TLV data object)
    Tag: 2, Len: 5 (issuer identification number, ISO 7812-1)
      Issuer identification number: A0 00 00 00 56    Tag: 5, Len: 7 (card issuer's data)
      Card issuer data: 44 4B 34 30 30 06 00
TCK = 0xDD (correct checksum)


Regards,
Andy

> Kind Regards
> Andreas


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel