opensc-devel — discussion of developement of OpenSC and related projects

Re: [Opensc-devel] opensc-pkcs11 in FireFox conflicting with closed-source PKCS11 provider

[Alex S. <ml...@os...>]

On 08/03/2013 11:14 AM, Ludovic Rousseau wrote:
> It may be bug in OpenSC that do not free some PC/SC resources.
>
> Can you use PC/SC spy and generate a logfile file as documented in [1]
> and send it?
> To configure the spy with OpenSC you may have to edit /etc/opensc.conf and set:
> provider_library = /usr/lib/libpcscspy.so
This is now fixed in trunk, by recent commit. Problem was that default 
driver was trying to detect card and it was busy. PKCS11 plugin from 
non-OpenSC comptatible card was not trying to open card if it was with 
"IN USE" flag.

Solution was to ignore unknown card in OpenSC with some exceptions. 
Commit 1a9729 works for me.

Re: [Opensc-devel] opensc-explorer, PIN length 10 / sequel

[Ludovic R. <lud...@gm...>]

2013/7/26 Johannes Becker <Joh...@hr...>:
> Hello,
>
>
>
> finally I found time to produce log files for the following problem:
>
>
>
> chipcard CardOS V4.3B
>
> OpenSC 0.13.0
>
>
>
> opensc-explorer fails to verify the PIN:
>
>
>
> $ opensc-explorer
>
> OpenSC Explorer version 0.13.0
>
> Using reader with a card: Dell Dell Smart Card Reader Keyboard 00 00
>
> OpenSC [3F00]> cd 5015
>
> OpenSC [3F00/5015]> verify CHV129 32:33:34:35:36:37:FF:FF:FF:FF
>
> Unable to verify PIN code: Invalid arguments
>
> OpenSC [3F00/5015]> verify CHV129 32:33:34:35:36:37:FF:FF
>
> Incorrect code.
>
> OpenSC [3F00/5015]> exit

>From your log:

0x7f43e335d700 13:28:27.211 [opensc-explorer]
reader-pcsc.c:182:pcsc_internal_transmit: called
0x7f43e335d700 13:28:27.240 [opensc-explorer] apdu.c:185:sc_apdu_log:
Incoming APDU data [   49 bytes] =====================================
6F 2D 81 02 02 00 82 06 38 B5 00 FE 00 07 83 02 o-......8.......
50 15 84 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 P.......cPKCS-15
85 03 00 2A 6C 86 08 00 05 05 FF FF 73 FF 05 90 ...*l.......s...
00                                              .
======================================================================
0x7f43e335d700 13:28:27.240 [opensc-explorer]
apdu.c:524:sc_single_transmit: returning with: 0 (Success)
0x7f43e335d700 13:28:27.240 [opensc-explorer] apdu.c:676:sc_transmit:
returning with: 0 (Success)
0x7f43e335d700 13:28:27.240 [opensc-explorer] card.c:353:sc_unlock: called
0x7f43e335d700 13:28:27.240 [opensc-explorer]
iso7816.c:321:iso7816_process_fci: processing FCI bytes
0x7f43e335d700 13:28:27.240 [opensc-explorer]
iso7816.c:325:iso7816_process_fci:   file identifier: 0x5015
0x7f43e335d700 13:28:27.240 [opensc-explorer]
iso7816.c:338:iso7816_process_fci:   bytes in file: 512
0x7f43e335d700 13:28:27.240 [opensc-explorer]
iso7816.c:349:iso7816_process_fci:   shareable: no
0x7f43e335d700 13:28:27.240 [opensc-explorer]
iso7816.c:368:iso7816_process_fci:   type: DF
0x7f43e335d700 13:28:27.240 [opensc-explorer]
iso7816.c:369:iso7816_process_fci:   EF structure: 0
0x7f43e335d700 13:28:27.240 [opensc-explorer]
iso7816.c:379:iso7816_process_fci:   File name: A0 00 00 00 63 50 4B
43 53 2D 31 35 ....cPKCS-15
0x7f43e335d700 13:28:27.240 [opensc-explorer]
card-cardos.c:443:cardos_select_file: returning with: 0 (Success)
0x7f43e335d700 13:28:27.240 [opensc-explorer]
card.c:638:sc_select_file: returning with: 0 (Success)
0x7f43e335d700 13:28:35.587 [opensc-explorer] sec.c:157:sc_pin_cmd: called
0x7f43e335d700 13:28:35.587 [opensc-explorer] sec.c:204:sc_pin_cmd:
returning with: -1300 (Invalid arguments)

The 10-bytes long PIN is rejected by OpenSC, not by the card.
Unfortunately we do not have more details.

0x7f43e335d700 13:28:42.835 [opensc-explorer] sec.c:157:sc_pin_cmd: called
0x7f43e335d700 13:28:42.835 [opensc-explorer]
apdu.c:687:sc_transmit_apdu: called
0x7f43e335d700 13:28:42.835 [opensc-explorer] card.c:315:sc_lock: called
0x7f43e335d700 13:28:42.835 [opensc-explorer] apdu.c:654:sc_transmit: called
0x7f43e335d700 13:28:42.835 [opensc-explorer]
apdu.c:509:sc_single_transmit: called
0x7f43e335d700 13:28:42.835 [opensc-explorer]
apdu.c:514:sc_single_transmit: CLA:0, INS:20, P1:0, P2:81, data(8)
0x7fffd3933c60
0x7f43e335d700 13:28:42.835 [opensc-explorer]
reader-pcsc.c:249:pcsc_transmit: reader 'Dell Dell Smart Card Reader
Keyboard 00 00'
0x7f43e335d700 13:28:42.835 [opensc-explorer] apdu.c:185:sc_apdu_log:
Outgoing APDU data [   13 bytes] =====================================
00 20 00 81 08 32 33 34 35 36 37 FF FF . ...234567..
======================================================================
0x7f43e335d700 13:28:42.835 [opensc-explorer]
reader-pcsc.c:182:pcsc_internal_transmit: called
0x7f43e335d700 13:28:42.875 [opensc-explorer] apdu.c:185:sc_apdu_log:
Incoming APDU data [    2 bytes] =====================================
63 00 c.
======================================================================

The 8-bytes long PIN is correctly sent to the card.


You will have to debug from sc_pin_cmd() in sec.c to find why the
"long" PIN is rejected.

Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] opensc-pkcs11 in FireFox conflicting with closed-source PKCS11 provider

[Ludovic R. <lud...@gm...>]

Hello,

2013/7/17 Alex Samorukov <ml...@os...>:
> On 07/17/2013 11:31 AM, Mat Arge wrote:
>> I am using /usr/lib/opensc-pkcs11.so  which i added to NSS using FF
>> configuration, so yes, of course i am sure. Problem is that when firefox
>> is running it preventing other, proprietary PKCS11 driver to access
>> card, and this specific card is not supported by OpenSC anyway, so i
>> have no idea why it is blocked.
>> But you said before, that your card is not supported by opensc. Or are you
>> talking about two different smartcards?
>
> Yes, i have a lot of cards. Most of them are supported by OpenSC and
> thats why i need this OpenSC-PKCS11 driver in the browser. But also i do
> have a card which is not supported by opensc and using own PKCS11
> library. Problem is that if FF is running i am unable to use this
> driver. I posted dump of the falied session (using  OpenSC PKCS#11 spy)
> to the http://pastebin.com/8s9ErZJ1 . It starts to work very slowly on
> C_Initialize and finally dying on C_OpenSession. If FF is closed
> everything works well. So i assume that for some reason opensc-pkcs11.so
> with FF is locking this card and want to fix that.

It may be bug in OpenSC that do not free some PC/SC resources.

Can you use PC/SC spy and generate a logfile file as documented in [1]
and send it?
To configure the spy with OpenSC you may have to edit /etc/opensc.conf and set:
provider_library = /usr/lib/libpcscspy.so

Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] OpenSC 0.13 and FireFox

[Jean-Michel P. - G. <jm...@go...>]

Le mardi 23 juillet 2013 à 11:31 +0200, Alex Samorukov a écrit :
> Done, in https://github.com/OpenSC/OpenSC/pull/174/files. I tested
> this 
> patch and it works for me. I don`t think that we need to add all keys 
> like before because it does looks to be good. This workaround
> addressing 
> only this specific issue.

Thanks for this patch. 
I will try and report.

Kind regards,
-- 
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

Re: [Opensc-devel] crucial issue (for me): slot ID vs index in engine_pkcs11 / libp11

[<op...@se...>]

>
> Here is the hack that works for me, in engine_pkcs11.c
>
[...]
>>
>> Slot id is not fixed in PKCS#11 to allow plug and play. What I suggest
>> is using token serial number instead to consistent behavior.
>
> This is a very good idea, the point is that libp11, at least the version
> that I have, must expose some more slot information in the first place.
> The "_private" structure is unknown to the caller.
> [...]

I'd just point out that the function PKCS11_enumerate_slots should not
acquire the token serials: that should be on demand (and possibly
per-token), as the PKCS11_enumerate_slots only performs PKCS#11 functions
up to C_GetSlotInfo and is not intended for accessing the tokens, just the
slots.

  Ubi

Re: [Opensc-devel] crucial issue (for me): slot ID vs index in engine_pkcs11 / libp11

[<op...@se...>]

Here is the hack that works for me, in engine_pkcs11.c
Of course it is not a solution to the general issue and yes, it is a bit
verbose.
Sorry for I cannot provide a proper patch but I am editing code which is
not the original: I already changed it some time ago to fix an issue with
key ID string parsing (that fix I submitted to the list some time ago, the
official code took the fix into account but in a later version).

// Ubi: 20130730: I need ths for my hack. This struct is not exposed by
libp11.
// Also, I am not using CK_SLOT_ID, etc. which are not known at this level

typedef struct pkcs11_slot_private {
  void *parent;
  unsigned char haveSession, loggedIn;
  unsigned long id;
  unsigned long session;
} PKCS11_SLOT_private;

[...] this is what I put just before the "if (slot_nr == -1) ..."

// Ubi: 20130730: now convert the slot_nr, which is a slot ID for me,
// into the slot array index, which is what the code here expects
#if 1
if (slot_nr >= 0)
{
  int slotapos; // position in array
  unsigned long curr_slot_ID;
  PKCS11_SLOT_private *slidata;
  int found;
  found = 0;
  for (slotapos = 0; slotapos < count; slotapos++)
  {
    slot = slot_list + slotapos;
    slidata = slot->_private;
    curr_slot_ID = slidata->id;
    if (curr_slot_ID == slot_nr)
    {
      slot_nr = slotapos;
      found = 1;
      break;
    }
  }
  if (!found)
  {
    fprintf(stderr, "Ubi: slot ID %d to idx failed\n", slot_nr);
    PKCS11_release_all_slots(ctx, slot_list, count);
    return NULL;
  }
  else
  {
    fprintf(stderr, "Ubi: performed conversion slot ID to idx %d\n",
slot_nr);
  }
}
#endif


> Hi,
>
> Slot id is not fixed in PKCS#11 to allow plug and play. What I suggest
> is using token serial number instead to consistent behavior.

This is a very good idea, the point is that libp11, at least the version
that I have, must expose some more slot information in the first place.
The "_private" structure is unknown to the caller.
It can stay hidden, but functions to query about a slot ID and token
serial (for the given slot) would be useful.
Also, the string slot_<slot ID>-... must be redefined first to allow for
passing the token serial, and I am not the person who can decide about
that.
Personally, I would also like to hava available:
tkserial_<token serial>-id_<key ID>
and
tklabel_<token label>-id_<key ID>

Thanks everybody

   Umberto Rustichelli aka Ubi

> Alon
>
> On Wed, Jul 31, 2013 at 9:35 AM,  <op...@se...> wrote:
>>
>> Douglas, Anthony, thank you very much for your enlighting replies.
>> My name is Umberto Rustichelli (aka Ubi).
>> For the moment, I'm going to try a quick-and-dirty hack in
>> engine_pkcs11.c
>> (version is 0.1.5, I know it's old but I'm tied to that by a number of
>> dependencies in an old environment), see more lines later.
>> Then, I'd like to do something about libp11 but it's not smart to work
>> on
>> old code... also: I don't want to break applications that rely on the
>> fact
>> that the array index is used
>>
>>> Greetings.
>>>
>>> (Note, I find it a bit easier to reply if there's a human name there
>>> somewhere.  :)
>>>
>>> On Tue, Jul 30, 2013 at 9:49 AM, <op...@se...> wrote:
>>>> The point is that the slot ID (as numbered by the PKCS#11 drver) has
>>>> nothing to do with the index of the slots array generated by libp11,
>>>> only accidentally they match when [...]
>>>> Now, I suspect that the original intention is to put the slot ID, not
>>>> the slot array index [...]
>>
>>> A patch would be interesting, especially if it is obvious that any
>>> large number is intended as slot id, not array index -- that could
>>> minimize compatibility headaches.
>>
>> In functions pkcs11_load_key and pkcs11_load_cert I plan to insert this
>> code (not compiled yet, some errors may occur):
>>
[... removed, it was broken]
>>
>> just before the existing part that rejects the slot ID:
>>
>> if (slot_nr == -1) {
>>   if (!(slot = PKCS11_find_token(ctx, slot_list, count)))
>>     fail("didn't find any tokens\n");
>> } else if (slot_nr >= 0 && slot_nr < count)
>>   slot = slot_list + slot_nr;
>>   else {
>>     fprintf(stderr, "Invalid slot number: %d\n", slot_nr);
>>     PKCS11_release_all_slots(ctx, slot_list, count);
>>     return NULL;
>> }
>>
>>> [...] If you can use a token label, does that work for your cases?
>>> libp11 allows access via "label_...." if I remember correctly.
>>
>> I think the label is for the key label only, not for the slot label.
>>
>>> Failing that, can you enumerate the slots via libp11 and get a
>>> (presumably valid) handle that way?
>>
>> I can, but I rely on engine_pkcs11 so I will first change the code
>> there.
>> In my opinion, libp11 shoould provide functions that work on the array
>> index, for backward compatibility, but also expose the slot ID in the
>> first place.
>> Putting together pkcs11_load_key and pkcs11_load_cert is not a bad idea,
>> too, they have so much code in common...
>>
>> Bye
>>
>>    Ubi

Re: [Opensc-devel] crucial issue (for me): slot ID vs index in engine_pkcs11 / libp11

[Alon Bar-L. <alo...@gm...>]

Hi,

Slot id is not fixed in PKCS#11 to allow plug and play. What I suggest
is using token serial number instead to consistent behavior.

Alon

On Wed, Jul 31, 2013 at 9:35 AM,  <op...@se...> wrote:
>
> Douglas, Anthony, thank you very much for your enlighting replies.
> My name is Umberto Rustichelli (aka Ubi).
> For the moment, I'm going to try a quick-and-dirty hack in engine_pkcs11.c
> (version is 0.1.5, I know it's old but I'm tied to that by a number of
> dependencies in an old environment), see more lines later.
> Then, I'd like to do something about libp11 but it's not smart to work on
> old code... also: I don't want to break applications that rely on the fact
> that the array index is used
>
>> Greetings.
>>
>> (Note, I find it a bit easier to reply if there's a human name there
>> somewhere.  :)
>>
>> On Tue, Jul 30, 2013 at 9:49 AM, <op...@se...> wrote:
>>> The point is that the slot ID (as numbered by the PKCS#11 drver) has
>>> nothing to do with the index of the slots array generated by libp11,
>>> only accidentally they match when [...]
>>> Now, I suspect that the original intention is to put the slot ID, not
>>> the slot array index [...]
>
>> A patch would be interesting, especially if it is obvious that any
>> large number is intended as slot id, not array index -- that could
>> minimize compatibility headaches.
>
> In functions pkcs11_load_key and pkcs11_load_cert I plan to insert this
> code (not compiled yet, some errors may occur):
>
> // Ubi: 20130730: now convert the slot_nr, which is a slot ID for me,
> // into the slot array index, which is what the code here expects
> #if 1
>   if (slot_nr >= 0)
>   {
>     int slotapos; // position in array
>     unsigned long curr_slot_ID;
>     int found;
>     found = 0;
>     for (slotapos = 0; slotapos < count; slotapos++)
>     {
>        curr_slot_ID = slot_list[slotapos]->priv->id;
>        if (curr_slot_ID == slot_nr)
>        {
>          slot_nr = slotapos;
>          found = 1;
>          break;
>        }
>     }
>     if (!found)
>     {
>       fprintf(stderr, "Ubi: slot ID %d to idx failed\n", slot_nr);
>       PKCS11_release_all_slots(ctx, slot_list, count);
>       return NULL;
>     }
>     else
>     {
>       fprintf(stderr,
>         "Ubi: performed conversion slot ID to idx %d\n", slot_nr);
>     }
>         }
> #endif
>
> just before the existing part that rejects the slot ID:
>
> if (slot_nr == -1) {
>   if (!(slot = PKCS11_find_token(ctx, slot_list, count)))
>     fail("didn't find any tokens\n");
> } else if (slot_nr >= 0 && slot_nr < count)
>   slot = slot_list + slot_nr;
>   else {
>     fprintf(stderr, "Invalid slot number: %d\n", slot_nr);
>     PKCS11_release_all_slots(ctx, slot_list, count);
>     return NULL;
> }
>
>> [...] If you can use a token label, does that work for your cases?
>> libp11 allows access via "label_...." if I remember correctly.
>
> I think the label is for the key label only, not for the slot label.
>
>> Failing that, can you enumerate the slots via libp11 and get a
>> (presumably valid) handle that way?
>
> I can, but I rely on engine_pkcs11 so I will first change the code there.
> In my opinion, libp11 shoould provide functions that work on the array
> index, for backward compatibility, but also expose the slot ID in the
> first place.
> Putting together pkcs11_load_key and pkcs11_load_cert is not a bad idea,
> too, they have so much code in common...
>
> Bye
>
>    Ubi
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel

Re: [Opensc-devel] crucial issue (for me): slot ID vs index in engine_pkcs11 / libp11

[<op...@se...>]

Douglas, Anthony, thank you very much for your enlighting replies.
My name is Umberto Rustichelli (aka Ubi).
For the moment, I'm going to try a quick-and-dirty hack in engine_pkcs11.c
(version is 0.1.5, I know it's old but I'm tied to that by a number of
dependencies in an old environment), see more lines later.
Then, I'd like to do something about libp11 but it's not smart to work on
old code... also: I don't want to break applications that rely on the fact
that the array index is used

> Greetings.
>
> (Note, I find it a bit easier to reply if there's a human name there
> somewhere.  :)
>
> On Tue, Jul 30, 2013 at 9:49 AM, <op...@se...> wrote:
>> The point is that the slot ID (as numbered by the PKCS#11 drver) has
>> nothing to do with the index of the slots array generated by libp11,
>> only accidentally they match when [...]
>> Now, I suspect that the original intention is to put the slot ID, not
>> the slot array index [...]

> A patch would be interesting, especially if it is obvious that any
> large number is intended as slot id, not array index -- that could
> minimize compatibility headaches.

In functions pkcs11_load_key and pkcs11_load_cert I plan to insert this
code (not compiled yet, some errors may occur):

// Ubi: 20130730: now convert the slot_nr, which is a slot ID for me,
// into the slot array index, which is what the code here expects
#if 1
  if (slot_nr >= 0)
  {
    int slotapos; // position in array
    unsigned long curr_slot_ID;
    int found;
    found = 0;
    for (slotapos = 0; slotapos < count; slotapos++)
    {
       curr_slot_ID = slot_list[slotapos]->priv->id;
       if (curr_slot_ID == slot_nr)
       {
         slot_nr = slotapos;
         found = 1;
         break;
       }
    }
    if (!found)
    {
      fprintf(stderr, "Ubi: slot ID %d to idx failed\n", slot_nr);
      PKCS11_release_all_slots(ctx, slot_list, count);
      return NULL;
    }
    else
    {
      fprintf(stderr,
        "Ubi: performed conversion slot ID to idx %d\n", slot_nr);
    }
	}
#endif

just before the existing part that rejects the slot ID:

if (slot_nr == -1) {
  if (!(slot = PKCS11_find_token(ctx, slot_list, count)))
    fail("didn't find any tokens\n");
} else if (slot_nr >= 0 && slot_nr < count)
  slot = slot_list + slot_nr;
  else {
    fprintf(stderr, "Invalid slot number: %d\n", slot_nr);
    PKCS11_release_all_slots(ctx, slot_list, count);
    return NULL;
}

> [...] If you can use a token label, does that work for your cases?
> libp11 allows access via "label_...." if I remember correctly.

I think the label is for the key label only, not for the slot label.

> Failing that, can you enumerate the slots via libp11 and get a
> (presumably valid) handle that way?

I can, but I rely on engine_pkcs11 so I will first change the code there.
In my opinion, libp11 shoould provide functions that work on the array
index, for backward compatibility, but also expose the slot ID in the
first place.
Putting together pkcs11_load_key and pkcs11_load_cert is not a bad idea,
too, they have so much code in common...

Bye

   Ubi

Re: [Opensc-devel] crucial issue (for me): slot ID vs index in engine_pkcs11 / libp11

[Anthony F. <ant...@gm...>]

Greetings.

(Note, I find it a bit easier to reply if there's a human name there
somewhere.  :)

On Tue, Jul 30, 2013 at 9:49 AM, <op...@se...> wrote:
> The point is that the slot ID (as numbered by the PKCS#11 drver) has
> nothing to do with the index of the slots array generated by libp11, only
> accidentally they match when you're using one driver only.
>
> If you identify a key with, for instance, the name
> "slot_761406623-id_1307301149164400" (reporting the slot ID), it will
> miserably fail (and it is a good thing, at least it is not trying to
> access the wrong slot with a bad PIN) because it finds out that  761406623
> is not good. The message is "Invalid slot number: 761406623" even if the
> slot ID is exactly that.
>
> Now, I suspect that the original intention is to put the slot ID, not the
> slot array index, in the string... is my observation correct?
> Or did I make any mistake in my analysis of the code?

A patch would be interesting, especially if it is obvious that any
large number is intended as slot id, not array index -- that could
minimize compatibility headaches.

> If I am right, I am likely going to work on my old version and change the
> code for my purpose even if the intention was not to indicate the slot
> ID...: do you have some important advice regarding my attempt?

If you can use a token label, does that work for your cases?  libp11
allows access via "label_...." if I remember correctly.

Failing that, can you enumerate the slots via libp11 and get a
(presumably valid) handle that way?

Good luck.

Best regards,
Anthony Foiani

Re: [Opensc-devel] crucial issue (for me): slot ID vs index in engine_pkcs11 / libp11

[Douglas E. E. <dee...@an...>]

On 7/30/2013 10:49 AM, op...@se... wrote:
> Dear all, I find myself working with an old version of engine_pkcs11 /
> libp11 libraries, that served me well for years.
> The issue almost certainly apply to the most recent release (NOTICE: the
> libp11 dowload link on the page
> https://www.opensc-project.org/opensc/wiki/libp11 is broken).

OpenSC is now using GitHub.
https://github.com/OpenSC

The old www.opensc-project.org should reflect that GitHub is the source.


https://github.com/OpenSC
>
> It is not uncommon to have slot ID which are quite high, for instance
> 761406623 with an HSM (my case).
> It almost always happens when using multiple PKCS#11 drivers, that is how
> I found out about the problem...
>
> The point is that the slot ID (as numbered by the PKCS#11 drver) has
> nothing to do with the index of the slots array generated by libp11, only
> accidentally they match when you're using one driver only.

There was a change like this for OpenSC, pkcs11.
Sounds like a change is needed in libp11.

>
> If you identify a key with, for instance, the name
> "slot_761406623-id_1307301149164400" (reporting the slot ID), it will
> miserably fail (and it is a good thing, at least it is not trying to
> access the wrong slot with a bad PIN) because it finds out that  761406623
> is not good. The message is "Invalid slot number: 761406623" even if the
> slot ID is exactly that.
>
> Now, I suspect that the original intention is to put the slot ID, not the
> slot array index, in the string... is my observation correct?

Yes, the slot is  not an index, but more of a handle.

> Or did I make any mistake in my analysis of the code?


The pkcs11-tool  has options:
   -L, --list-slots              List available slots
   -T, --list-token-slots        List slots with tokens

  --slot <arg>              Specify the ID of the slot to use
  --slot-description <arg>  Specify the description of the slot to use
  --slot-index <arg>        Specify the index of the slot to use

Maybe the engine_pkcs11 and libp11 need to support one of these
methods to find a slot.

>
> If I am right, I am likely going to work on my old version and change the
> code for my purpose even if the intention was not to indicate the slot
> ID...: do you have some important advice regarding my attempt?
>
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@an...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

[Opensc-devel] (no subject)

[<op...@se...>]

Dear all, I find myself working with an old version of engine_pkcs11 /
libp11 libraries, that served me well for years.
The issue almost certainly apply to the most recent release (NOTICE: the
libp11 dowload link on the page
https://www.opensc-project.org/opensc/wiki/libp11 is broken).

It is not uncommon to have slot ID which are quite high, for instance
761406623 with an HSM (my case).
It almost always happens when using multiple PKCS#11 drivers, that is how
I found out about the problem...

The point is that the slot ID (as numbered by the PKCS#11 drver) has
nothing to do with the index of the slots array generated by libp11, only
accidentally they match when you're using one driver only.

If you identify a key with, for instance, the name
"slot_761406623-id_1307301149164400" (reporting the slot ID), it will
miserably fail (and it is a good thing, at least it is not trying to
access the wrong slot with a bad PIN) because it finds out that  761406623
is not good. The message is "Invalid slot number: 761406623" even if the
slot ID is exactly that.

Now, I suspect that the original intention is to put the slot ID, not the
slot array index, in the string... is my observation correct?
Or did I make any mistake in my analysis of the code?

If I am right, I am likely going to work on my old version and change the
code for my purpose even if the intention was not to indicate the slot
ID...: do you have some important advice regarding my attempt?

[Opensc-devel] crucial issue (for me): slot ID vs index in engine_pkcs11 / libp11

[<op...@se...>]

Dear all, I find myself working with an old version of engine_pkcs11 /
libp11 libraries, that served me well for years.
The issue almost certainly apply to the most recent release (NOTICE: the
libp11 dowload link on the page
https://www.opensc-project.org/opensc/wiki/libp11 is broken).

It is not uncommon to have slot ID which are quite high, for instance
761406623 with an HSM (my case).
It almost always happens when using multiple PKCS#11 drivers, that is how
I found out about the problem...

The point is that the slot ID (as numbered by the PKCS#11 drver) has
nothing to do with the index of the slots array generated by libp11, only
accidentally they match when you're using one driver only.

If you identify a key with, for instance, the name
"slot_761406623-id_1307301149164400" (reporting the slot ID), it will
miserably fail (and it is a good thing, at least it is not trying to
access the wrong slot with a bad PIN) because it finds out that  761406623
is not good. The message is "Invalid slot number: 761406623" even if the
slot ID is exactly that.

Now, I suspect that the original intention is to put the slot ID, not the
slot array index, in the string... is my observation correct?
Or did I make any mistake in my analysis of the code?

If I am right, I am likely going to work on my old version and change the
code for my purpose even if the intention was not to indicate the slot
ID...: do you have some important advice regarding my attempt?

Re: [Opensc-devel] Failed to connect to card: Card is invalid or cannot be handled

[Ondrej M. <ond...@ni...>]

On 07/25/2013 01:48 PM, Tomáš Lavický wrote:
> Our company started to use HID Crescendo iCLASS Px G8H cards and HID Global’s
> ActivID® CMS Appliance for user logons. Since ActivClient middleware has x86
> Linux version only I'm trying to use OpenSC on my KUbuntu 12.04 box to access
> certificates stored on the card.

It's very probable that the HID iCLASS card with ActivID application won't have
PKCS#15 structure, but some other proprietary one. Thus you probably won't be
able to easily dump certificates. If they provided you with a pkcs11 library for
the card, you could try "pkcs11-tool" (see --module option).

> I can see ATR via pcsc_scan but not via opensc-tool:

I have a card that behaves in a similar way when accessed through NFC interface
- ACS ACOS5 card. The reason for this is that "opensc-tool -a" also tries to
send an APDU which fails:

00000012 APDU: 00 C0 00 00 00
00000294 SW:
00000037 ifdwrapper.c:520:IFDTransmit() Card not transacted: 612
00000032 winscard.c:1564:SCardTransmit() Card not transacted: 0x80100016

My guess would be that both your Crescendo iCLASS and the ACOS5 NFC interface
don't support ISO-7816 APDUs (ACOS5 card can be still dumped via libnfc).

Ondrej

[Opensc-devel] OpenSc - Minidriver - Internal functions

[evalues e. <eva...@gm...>]

Hi all,

I'm trying to compile the opensc-minidriver, for this I've linked
opensc.dll. However I've had some problems with internal functions as
_sc_match_atr_block. Has opensc.dll some equivalent function? Is there a
document with this information? Somehow I can link these functions ?

Thanks for all.

[Opensc-devel] OpenSC 0.13 memory corruption (was: opensc 0.11.13 and openssl 1.0 oddity)

[Markus K. <ko...@rr...>]

Hello list,

basically I refer to the thread
"opensc 0.11.13 and openssl 1.0 oddity" 2010-04-15
http://thread.gmane.org/gmane.comp.encryption.opensc.devel/10038
which ended in these changes
https://github.com/OpenSC/OpenSC/commit/46def8b86cae98791049fd648128ad091ffec172
https://github.com/OpenSC/OpenSC/commit/7f3f6dec6b3b092214813ff1a1da86bb26cbda49

having current code look like this:
https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/openssl.c#L154

The problem with this approach is as simple as this:
	ENGINE_set_default(e, ENGINE_METHOD_ALL);
	ENGINE_free(e);
The gost engine is set as default, and free'd.

Not really valid, breaks OpenSSL hard.
ENGINE references are slightly more complicated:
http://www.openssl.org/docs/crypto/engine.html#Reference_counting_and_handles

I had it segfault in/beyond SSL_CTX_new.

To reproduce, ...
My setup is simple, I got two readers, two cards.
One card is used to authenticate to the SOAP API of a CA, thats the RA 
card, second card is written to, the user card.

To issue a certificate, I need to
  * create a key on the USER card
  * sign a CSR with the key on the USER card (using engine_pkcs11)
  * submit the request to the SOAP API
  * approve the request
    * authenticate to the SOAP api using the RA cards cert/key pair 
(engine_pkcs11)
    * sign the approval with the RA cards cert/key pair (engine_pkcs11)


As both cards are interfaced with opensc, loading an engine for both did 
not work for me as I rely on the PIN parameter for the engine_pkcs11.
So I had to serialize access to the openssl engine, which allows 
reproducing the problems with a single reader/card.
Have a single ENGINE running, finish it when not required, init a new 
engine when required.

After loading the Engine to sign the CSR, the engine gets finished, and 
removed, including all ENGINE_unregister_*.
When connecting to the SOAP service, OpenSSL would segfault ~12 frames 
beyond SSL_CTX_new() as internal data structure was corrupted by the 
ENGINE_free() introduced in OpenSC in the cited gost patchset.
It even segfaults when calling SSL_CTX_new while the pkcs11 engine is 
loaded, the data corruption takes its toll.


My fix is simple, do not load gost. [no_free.diff]
It's radical, but I do not have access to gost enabled cards, and 
therefore can't verify this ever worked correctly, in case it is not, 
keeping a global reference to the engine and finishing it when done 
might be better.


libp11 had similar problems, it is used in engine_pkcs11, and registers 
it's ERR strings, but does not provide API to unregister them as well.
Unloading the engine resulted in the ERR strings getting unmapped as 
well, loading the engine again crashed OpenSSL due to access to unmapped 
memory.
Extending libp11 to allow unregistering the ERR strings 
[add_ERR_unload_PKCS11_strings.diff] and making use of it in 
engine_pkcs11 [unload_errstrings.diff] was required therefore.

Also attached is a testcase [testcase.py], written in python using M2Crypto.
run as
testcase.py <slot> <pin> <objid>
e.g.
gdb -ex r --args python /tmp/testcase.py 1 123456 
46a808cfd5beafa5e60aefee867bf92025dc2849

You may have to adjust _PATH in the script accordingly to match your 
settings.

This testcase segfaults in SSL_CTX_new due to the gost engine ENGINE_free.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7259f56 in look_str_cb (arg=<optimized out>, 
sk=<optimized out>, nid=<optimized out>,
     def=<optimized out>) at tb_asnmth.c:216
#2  look_str_cb (nid=815, sk=0xbb0790, def=<optimized out>, 
arg=0x7fffffffcf90) at tb_asnmth.c:206
#3  0x00007ffff7266ddf in doall_util_fn (arg=0x7fffffffcf70,
     func_arg=0x7ffff7258220 <int_cb_LHASH_DOALL_ARG>, func=0, 
use_arg=1, lh=0xbb0490) at lhash.c:292
#4  lh_doall_arg (lh=0xbb0490, func=0x7ffff7258220 
<int_cb_LHASH_DOALL_ARG>, arg=0x7fffffffcf70)
     at lhash.c:307
#5  0x00007ffff725871c in engine_table_doall (table=<optimized out>, 
cb=<optimized out>,
     arg=<optimized out>) at eng_table.c:349
#6  0x00007ffff725a313 in ENGINE_pkey_asn1_find_str (pe=0x7fffffffcfc8, 
str=<optimized out>,
     len=<optimized out>) at tb_asnmth.c:236
#7  0x00007ffff728c7c5 in EVP_PKEY_asn1_find_str (pe=0x7fffffffd010, 
str=0x7ffff75a0377 "gost94", len=6)
     at ameth_lib.c:213
#8  0x00007ffff75952e4 in get_optional_pkey_id (pkey_name=<optimized 
out>) at ssl_ciph.c:356
#9  0x00007ffff759641f in ssl_cipher_get_disabled (ssl=<synthetic 
pointer>, mac=<synthetic pointer>,
     enc=<synthetic pointer>, auth=<synthetic pointer>, mkey=<synthetic 
pointer>) at ssl_ciph.c:733
#10 ssl_create_cipher_list (ssl_method=0x7ffff77ade80, 
cipher_list=0xbadbb8, cipher_list_by_id=
     0xbadbc0, rule_str=0x7ffff759ffac "ALL:!aNULL:!eNULL:!SSLv2") at 
ssl_ciph.c:1371
#11 0x00007ffff758fd30 in SSL_CTX_new (meth=0x7ffff77ade80) at 
ssl_lib.c:1762


Re-setting the PIN parameter for the engine, depending on the card to 
use is possible, and allows using multiple cards without ENGINE_finish, 
avoiding the libp11 ERR strings issue, but the corruption caused by the 
gost engine free persists, and faults.



MfG
Markus Kötter

[Opensc-devel] libp11 requires successful logout before successful login

[Anthony F. <ant...@gm...>]

Greetings.

I found an interesting buglet in my particular combination of raw
libp11 + openssl / engine_pkcs11 / libp11, all on top of opensc /
pcsc-lite.

First, a bit of background: I'm implementing a data recorder which
uses a USB crypto token to sign log files as they are acquired.  The
user interface allows for a "stored PIN" (which is persistent across
reboots and removal/insert cycles) or "one-time PIN" (which, as the
name applied, is used only the one time it is submitted, and not
stored.

In the process of experimenting with different one-time PINs, and
seeing how it reacted when an invalid PIN was entered followed by a
valid PIN, I discovered that I only ever got one successful login per
insertion cycle.

After a bit of debugging, it turns out that my patches to reduce
memory leakage when using keys through engine_pkcs11 [1] had a rather
nasty side-effect: when one frees the key, it invalidates all sessions
on that token.  (The list of sessions is kept in a static variable in
the opensc-pkcs11.so shared library, so if a single application uses
the library through two different paths, it still shares that list of
sessions -- at least on Linux.)

Then, when I go to log in through "raw" libp11 again, it complains
because my session is invalid.  To make a long story short(er), the
critical code is in PKCS11_login:
https://github.com/OpenSC/libp11/blob/libp11-0.2.8/src/p11_slot.c#L140

Which calls PKCS11_logout.  The actual error I encountered is from line 181:
https://github.com/OpenSC/libp11/blob/libp11-0.2.8/src/p11_slot.c#L181

But the final failure is due to the fact that
https://github.com/OpenSC/libp11/blob/libp11-0.2.8/src/p11_slot.c#L145
doesn't know that the underlying session got clobbered (through engine_pkcs11).

After that point, my session is invalid, and the call at
https://github.com/OpenSC/libp11/blob/libp11-0.2.8/src/p11_slot.c#L152

Fails, as does my entire login attempt.

I can work around this in client code by mucking with the private
per-slot state like so:

        pkcs11_slot_private * priv =
          static_cast< pkcs11_slot_private * >( m_pUsedSlot->_private );

        if ( priv->haveSession )
        {
            priv->loggedIn = 0;
            priv->haveSession = 0;
        }

But that's *horrible*.

I suspect the correct answer is to update libp11 to make the logout
failure non-fatal, or to otherwise uncouple the login attempt from a
(possibly stale) state.

engine_pkcs11 already acknowledges a related problem; its comments on
logged-in state and PINs is:

/* Login successful, PIN retained in case further logins are
  required. This will occur on subsequent calls to the
  pkcs11_load_key function. Subsequent login calls should be
  relatively fast (the token should maintain its own login
  state), although there may still be a slight performance
  penalty. We could maintain state noting that successful
  login has been performed, but this state may not be updated
  if the token is removed and reinserted between calls. It
  seems safer to retain the PIN and peform a login on each
  call to pkcs11_load_key, even if this may not be strictly
  necessary. */
-- https://github.com/OpenSC/engine_pkcs11/blob/master/src/engine_pkcs11.c#L726

If I get a chance to make a patch, I'll try to do so.  If I don't,
however, I wanted to post this report so that we have a record of the
difficulty.

(An alternate approach would be to remove the need for raw libp11
access; in my case, that would require some way of obtaining a list of
certificates and keys on the device through the engine_pkcs11
interface.  The engine_pkcs11 code traverses all the certificates, but
there is no method published for getting that list through the openssl
engine interface.)

Best regards,
Anthony Foiani

[1] https://github.com/OpenSC/engine_pkcs11/pull/3

Re: [Opensc-devel] Connecting to a specific USB device

[Anthony F. <ant...@gm...>]

Ludovic, greetings --

On Fri, Jul 26, 2013 at 8:08 AM, Ludovic Rousseau
<lud...@gm...> wrote:
> 2013/7/17 Anthony Foiani <ant...@gm...>:
>> But I don't see any place where [the saved device name/path] can be accessed.
>
> Exact. And that PC/SC information needs to come from the PKCS#11 layer.
...
>> The cleanest way might be a vendor-specified attribute, but as the
>> comment at the top of p11_attr.c says: "The number of layers we stack
>> on top of each other here is frightening."

Might it be as simple as defining some CKA_OPENSC_DEVICE_PATH, and
returning the recorded device name/path info when queried for that
attribute?  (Or am I missing a layer?)

> If once attached to a VM the USB token is no more available for the
> host then pcsc on the host will not see it anymore. And then OpenSC
> will not see the token either.
>
> So a new PKCS#11 token detected by OpenSC will only be a newly
> connected USB token.
>
> You would not be able to connect a new token until the previous one is
> attached to a VM.

Nice!  Very elegant, other than the "at most one unbound token at any
given time" limitation.

> Maybe your USB tokens have different USB serial numbers so you can
> differentiate them?

The original poster mentioned serial numbers as an option:

>> On Tue, Jul 16, 2013 at 8:30 AM, Mat Arge <arg...@gm...> wrote:
>>> I am tracking the connection of USB tokens via udev and want to do some
>>> specific stuff with them (pass them through to certain virtual machines). For
>>> that, I would like to get some token specifics (like the serial number or the
>>> PKCS#11 label).

But it would be nice to be able to get physical location / connection
data at the PKCS11 layer, especially since we already record it.

The whole point of a label is to allow the use of meaningful names;
allowing only serial numbers means that users now need to track
numbers-to-meaning in some other way.

Ah, and I didn't even catch "*USB* serial numbers".  For what it's
worth, the tokens that I'm using in my current project do not support
USB serial numbers, only PKCS11 serial numbers.

> pcscd should be fast to boot. On an ARM9 CPU I measured 0.3 second. See [1].
> Maybe you are using a smart card reader that is slow to boot.

Apologies for the misinformation.  It is indeed quite fast on my fast
hardware (modern x86-64 desktop).  Not sure where I got the "slow"
from -- maybe on my 266MHz PPC32 embedded box that is busy doing other
stuff in other threads as it tries to run pcscd as well...

I was wrong.  Again, apologies.

Best regards,
Anthony Foiani

Re: [Opensc-devel] Connecting to a specific USB device

[Ludovic R. <lud...@gm...>]

2013/7/17 Anthony Foiani <ant...@gm...>:
> Mat --
>
> On Tue, Jul 16, 2013 at 8:30 AM, Mat Arge <arg...@gm...> wrote:
>> Hello!
>>
>> I am tracking the connection of USB tokens via udev and want to do some
>> specific stuff with them (pass them through to certain virtual machines). For
>> that, I would like to get some token specifics (like the serial number or the
>> PKCS#11 label). So what I need is a connection (preferably with PKCS#11) to
>> the just inserted token. The problem is, that at the udev level where I am, I
>> only know the USB BUS Id, the vendor ID and such stuff. Is there some way to
>> get a PKCS#11 or pc/sc connection to the correct token?
>
> A quick look through the pcsc-lite stuff is discouraging; it seems
> that a string describing the specific port is indeed stored in the
> reader context structure, but there doesn't seem to be any existing
> way to get it out.
>
> See line 213 of:
> http://anonscm.debian.org/viewvc/pcsclite/trunk/PCSC/src/readerfactory.c?revision=6668&view=markup
>
> For lilbusb, that "device" value is ultimately generated around line 516 of:
> http://anonscm.debian.org/viewvc/pcsclite/trunk/PCSC/src/hotplug_libusb.c?revision=6557&view=markup
>
> But I don't see any place where that value can be accessed.

Exact. And that PC/SC information needs to come from the PKCS#11 layer.

> (But I'm certainly not an expert on this; I've just hacked a few
> things onto the source as I needed them -- see next point.)
>
> The cleanest way might be a vendor-specified attribute, but as the
> comment at the top of p11_attr.c says: "The number of layers we stack
> on top of each other here is frightening."
>
>> Or the other way round: Is there some way to find out for an existing
>> pcsc/pkcs11 connection which hardware address it is leading to?
>
> It's not exactly what you're looking for, but I did propose a patch to
> pcscd that restricted it to a particular USB port:
>
> http://opensc.1086184.n5.nabble.com/FYI-PATCH-restrict-pcscd-to-a-single-USB-port-path-td13800.html
>
> Worst case, your udev script could:
> 1. if it looks like a crypto token ...
> 2. spawn a pcscd that looks only at that port...
> 3. then query that specific pcscd to get label etc...
> 4. kill the pcscd...
> 5. bind the port to the VM appropriately.

If once attached to a VM the USB token is no more available for the
host then pcsc on the host will not see it anymore. And then OpenSC
will not see the token either.
So a new PKCS#11 token detected by OpenSC will only be a newly
connected USB token.

You would not be able to connect a new token until the previous one is
attached to a VM.

Maybe your USB tokens have different USB serial numbers so you can
differentiate them?

> Not pretty, and not fast (pcscd takes a few seconds to come up even on
> my fast hardware, but maybe I just don't know how to strip out
> unnecessary bits).

pcscd should be fast to boot. On an ARM9 CPU I measured 0.3 second. See [1].
Maybe you are using a smart card reader that is slow to boot.

Bye

[1] http://ludovicrousseau.blogspot.fr/2010/08/ram-and-cpu-improvements-in-pcsc-lite.html

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] opensc-explorer, PIN length 10 / sequel

[Johannes B. <Joh...@hr...>]

Hello,

 finally I found time to produce log files for the following problem:

chipcard  CardOS V4.3B 
OpenSC  0.13.0

opensc-explorer fails to verify the PIN:

$ opensc-explorer
OpenSC Explorer version 0.13.0
Using reader with a card: Dell Dell Smart Card Reader Keyboard 00 00
OpenSC [3F00]> cd 5015
OpenSC [3F00/5015]> verify CHV129 32:33:34:35:36:37:FF:FF:FF:FF
Unable to verify PIN code: Invalid arguments
OpenSC [3F00/5015]> verify CHV129 32:33:34:35:36:37:FF:FF
Incorrect code.
OpenSC [3F00/5015]> exit

On the other hand pkcs15-tool has no problems with the command
pkcs15-tool --change-pin --pin 234567  --new-pin 234567

The log files are
http://www.uni-giessen.de/~g013/opensc/opensc-explorer.log
http://www.uni-giessen.de/~g013/opensc/pkcs15-tool.log

Below the output of pkcs15-tool --dump

Regards
  Johannes



 pkcs15-tool --dump
Using reader with a card: Dell Dell Smart Card Reader Keyboard 00 00
PKCS#15 Card [Test Card]:
        Version        : 0
        Serial number  : 7BFF203BF6052E35
        Manufacturer ID: cv cryptovision gmbh (c) v1.0n
        Flags          : Login required, PRN generation, EID compliant

PIN [User Pin]
        Object Flags   : [0x3], private, modifiable
        Auth ID        : 02
        ID             : 01
        Flags          : [0x133], case-sensitive, local, initialized, needs-padding, disable_allowed
        Length         : min_len:4, max_len:10, stored_len:10
        Pad char       : 0xFF
        Reference      : 129 (0x81)
        Type           : ascii-numeric
        Path           : 3f005015

PIN [SO Pin]
        Object Flags   : [0x3], private, modifiable
        ID             : 02
        Flags          : [0x1BB], case-sensitive, local, unblock-disabled, initialized, needs-
padding, soPin, disable_allowed
        Length         : min_len:4, max_len:10, stored_len:10
        Pad char       : 0xFF
        Reference      : 130 (0x82)
        Type           : ascii-numeric
        Path           : 3f005015

AuthKey [Challenge Response Key]
        Object Flags   : [0x3], private, modifiable
        ID             : 02
        Derived        : 1
        SecretKeyID    : 01

Private RSA Key [JLUSIGNCERT]
        Object Flags   : [0x3], private, modifiable
        Usage          : [0x6], decrypt, sign
        Access Flags   : [0x9], sensitive, neverExtract
        ModLength      : 2048
        Key ref        : 1 (0x1)
        Native         : yes
        Path           : 3f00501550724b21
        Auth ID        : 01
        ID             : 45
        GUID           : {6c9dc6ad-b7fa-c10c-0ff7-c385ad72d3f0}

Private RSA Key [JLUAUTHCERT]
        Object Flags   : [0x3], private, modifiable
        Usage          : [0x6], decrypt, sign
        Access Flags   : [0x9], sensitive, neverExtract
        ModLength      : 2048
        Key ref        : 1 (0x1)
        Native         : yes
        Path           : 3f00501550724b22
        Auth ID        : 01
        ID             : 46
        GUID           : {d9fe0a11-3ec7-eda5-ac52-9a721aff8e70}

Public RSA Key [JLUSIGNCERT]
        Object Flags   : [0x2], modifiable
        Usage          : [0x41], encrypt, verify
        Access Flags   : [0x0]
        ModLength      : 2048
        Key ref        : 1 (0x1)
        Native         : no
        Path           : 3f00501550754b21
        ID             : 45
        DirectValue    : <absent>

Public RSA Key [JLUAUTHCERT]
        Object Flags   : [0x2], modifiable
        Usage          : [0x41], encrypt, verify
        Access Flags   : [0x0]
        ModLength      : 2048
        Key ref        : 1 (0x1)
        Native         : no
        Path           : 3f00501550754b22
        ID             : 46
        DirectValue    : <absent>

X.509 Certificate [JLUSIGNCERT]
        Object Flags   : [0x2], modifiable
        Authority      : no
        Path           : 3f00501543044301
        ID             : 45
        GUID           : {6c9dc6ad-b7fa-c10c-0ff7-c385ad72d3f0}
        Encoded serial : 02 07 1599ED6129A5C1
X.509 Certificate [JLUAUTHCERT]
        Object Flags   : [0x2], modifiable
        Authority      : no
        Path           : 3f00501543044302
        ID             : 46
        GUID           : {d9fe0a11-3ec7-eda5-ac52-9a721aff8e70}
        Encoded serial : 02 07 1599ED65D8554B
X.509 Certificate [Deutsche Telekom Root CA 2]
        Object Flags   : [0x2], modifiable
        Authority      : no
        Path           : 3f00501543044303
        ID             : 50
        GUID           : {6f74f832-4ebb-257d-0ae1-97ad6b19b2ae}
        Encoded serial : 02 01 26
X.509 Certificate [DFN-Verein PCA Global - G01]
        Object Flags   : [0x2], modifiable
        Authority      : no
        Path           : 3f00501543044304
        ID             : 50
        GUID           : {6f74f832-4ebb-257d-0ae1-97ad6b19b2ae}
        Encoded serial : 02 02 00C7
X.509 Certificate [JLUCACERT]
        Object Flags   : [0x2], modifiable
        Authority      : no
        Path           : 3f00501543044305
        ID             : 50
        GUID           : {6f74f832-4ebb-257d-0ae1-97ad6b19b2ae}
        Encoded serial : 02 04 109C4834
Data object 'cardid'
        applicationName: cvmd
        Path:            3f0050156377
        Data (16 bytes): 36ED3BC2D4AF7D41A4632F4026C27D6F
Data object 'cardcf'
        applicationName: cvmd
        Path:            3f0050156378
        Data (6 bytes): 010109000A00
Data object 'cardapps'
        applicationName: cvmd
        Path:            3f00501544444401
        Data (8 bytes): 6D73637000000000
Data object 'mscp\'
        applicationName: cvmd
        Path:            3f00501544444402
        Data (0 bytes): 
Data object 'mscp\cmapfile'
        applicationName: cvmd
        Path:            3f00501544444403
        Data (0 bytes): 
Data object 'CARDVERSION'
        applicationName: 
        Path:            3f00501544444404
        Data (3 bytes): 322E30

[Opensc-devel] Minidriver development environment

[evalues e. <eva...@gm...>]

Hi all,

I'm Fernando Cortés. After developing a minidriver based on OpenSC 0.12
for Windows XP, I would like to update the minidriver based on OpenSC
0.13 for Windows 7. I want to mount a Windows development environment
with NetBeans (or Visual Studio 2010), along with MinGW, Windows SDK
7.0A and Windows CNG for Windows 7. However, when I tried to compile
opensc, I had various problems with MinGW headers, cardmod and WinSCard.
I would like to ask about the best way to mount a stable development
environment on Windows 7 to compile the OpenSC 0.13 source.

Thank you.

Re: [Opensc-devel] opensc-pkcs11 in FireFox conflicting with closed-source PKCS11 provider

[Alex S. <ml...@os...>]

On 07/17/2013 06:28 PM, Douglas E. Engert wrote:
> ccess to the card.
>
> Your suggestion of a list of ATRs to ignore is an excellent idea.
> It could solve your problem, as well as allow NSS to use of a vendor's PKCS#11
> even if the card is supported by OpenSC.
This bug was affecting and annoying me, so i decided to write a patch 
[1]. Could you please take a look and commit if possible?
This works for me, at least.

[1] https://github.com/OpenSC/OpenSC/pull/175

Re: [Opensc-devel] OpenSC 0.13 and FireFox

[Douglas E. E. <dee...@an...>]

OK, your mod looks better. I will let others continue the review
and update process.


On 7/23/2013 4:31 AM, Alex Samorukov wrote:
> On 07/22/2013 11:27 PM, Douglas E. Engert wrote:
>>
>>>> When you run the test on 0.12, do the AuthID show up as
>>>> two different lengths?
>>> Yes, it is. Only difference in .12 is that code logic will add all
>>> keys anyway (and this code was removed in .13). But this check will
>>> fail as well.
>>>
>>
>> So the change should be to add all the keys back in, and try and
>> accommodate the
>> difference for the Fetian card?
> Done, in https://github.com/OpenSC/OpenSC/pull/174/files. I tested this
> patch and it works for me. I don`t think that we need to add all keys
> like before because it does looks to be good. This workaround addressing
> only this specific issue.
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@an...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

Re: [Opensc-devel] OpenSC 0.13 and FireFox

[Alex S. <ml...@os...>]

On 07/22/2013 11:27 PM, Douglas E. Engert wrote:
>
>>> When you run the test on 0.12, do the AuthID show up as
>>> two different lengths?
>> Yes, it is. Only difference in .12 is that code logic will add all
>> keys anyway (and this code was removed in .13). But this check will
>> fail as well.
>>
>
> So the change should be to add all the keys back in, and try and
> accommodate the
> difference for the Fetian card?
Done, in https://github.com/OpenSC/OpenSC/pull/174/files. I tested this 
patch and it works for me. I don`t think that we need to add all keys 
like before because it does looks to be good. This workaround addressing 
only this specific issue.

Re: [Opensc-devel] OpenSC 0.13 and FireFox

[Douglas E. E. <dee...@an...>]

On 7/22/2013 12:53 PM, Alex Samorukov wrote:
> On 07/22/2013 04:26 PM, Douglas E. Engert wrote:
>>> Hi,
>>>
>>> After upgrading to OpenSC 0.13 i found that pkcs11 auth in FF is not
>>> working anymore. I was able to find and fix the reason, could someone
>>> from developers please take a look on this?
>>>
>>> https://github.com/OpenSC/OpenSC/issues/173
>> This sounds more like a problem with your card, or the way your
>> card was initialized.
>>
>> Your fix does not fix the basic problem, of why when the card
>> was initialized, the two Auth IDs are different.
>>
>> Have you looked at how your card was initialization was done?
>>
>> Can you find where the two authIDs are created?
>>
>> Why are they different lengths?
>>
>>
> This card was formatted by official windows software for Fetian and it works correctly with it. I cant reformat the card with OpenSC now but i will ask for dumps in the official forum.
>

So should this fix be in the Fetian drive only?

The problem I have with your patch is it applies to all cards
but the problem appears to be in the Fetian card or maybe
in the driver.

When you run the test on 0.12, do the AuthID show up as
two different lengths?





-- 

  Douglas E. Engert  <DEE...@an...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

Re: [Opensc-devel] OpenSC 0.13 and FireFox

[Alex S. <ml...@os...>]

On 07/22/2013 04:26 PM, Douglas E. Engert wrote:
>> Hi,
>>
>> After upgrading to OpenSC 0.13 i found that pkcs11 auth in FF is not
>> working anymore. I was able to find and fix the reason, could someone
>> from developers please take a look on this?
>>
>> https://github.com/OpenSC/OpenSC/issues/173
> This sounds more like a problem with your card, or the way your
> card was initialized.
>
> Your fix does not fix the basic problem, of why when the card
> was initialized, the two Auth IDs are different.
>
> Have you looked at how your card was initialization was done?
>
> Can you find where the two authIDs are created?
>
> Why are they different lengths?
>
>
This card was formatted by official windows software for Fetian and it 
works correctly with it. I cant reformat the card with OpenSC now but i 
will ask for dumps in the official forum.