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

Re: [Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

[David W. <dw...@in...>]

On Tue, 2015-05-05 at 23:15 +0100, David Woodhouse wrote:
> 
> Here's a test case. I've verified that it fails with OpenSC with both 
> a PIV device (Yubikey NEO) and a Feitian ePass PKI token:

And this "fixes" it, although obviously it's more of a proof of
concept than something we could apply as-is:

Are our file descriptors all opened with O_CLOEXEC, btw?

diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
index aa50758..c304825 100644
--- a/src/pkcs11/pkcs11-global.c
+++ b/src/pkcs11/pkcs11-global.c
@@ -204,8 +204,29 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
 
        /* Handle fork() exception */
 #if !defined(_WIN32)
-       if (current_pid != initialized_pid) {
-               C_Finalize(NULL_PTR);
+       if (context != NULL && current_pid != initialized_pid) {
+               void *p;
+               sc_pkcs11_slot_t *slot;
+
+               rv = sc_pkcs11_lock();
+               if (rv != CKR_OK)
+                       return rv;
+
+               /* We cannot touch the PC/SC context since it
+                * belongs to the parent process. FIXME: For now
+                * just leak it */
+               context = NULL;
+
+               while ((p = list_fetch(&sessions)))
+                       free(p);
+               list_destroy(&sessions);
+
+               while ((slot = list_fetch(&virtual_slots))) {
+                       list_destroy(&slot->objects);
+                       free(slot);
+               }
+               list_destroy(&virtual_slots);
+               sc_pkcs11_free_lock();
        }
        initialized_pid = current_pid;
        in_finalize = 0;

-- 
David Woodhouse                            Open Source Technology Centre
Dav...@in...                              Intel Corporation

Re: [Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

[David W. <dw...@in...>]

On Sat, 2015-05-02 at 00:51 +0100, David Woodhouse wrote:
> So the problem here is either in OpenSC or PC/SC. Probably the former 
> — perhaps OpenSC should be discarding (closing?) any existing file 
> handles on getting the new C_Initialize() call?

Here's a test case. I've verified that it fails with OpenSC with both 
a PIV device (Yubikey NEO) and a Feitian ePass PKI token:

$   PKCS11SPY=/usr/lib64/pkcs11/opensc-pkcs11.so ./p11fork


*************** OpenSC PKCS#11 spy *****************
Loaded: "/usr/lib64/pkcs11/opensc-pkcs11.so"

0: C_GetFunctionList
2015-05-05 23:12:52.608
Returned:  0 CKR_OK

1: C_Initialize
2015-05-05 23:12:52.609
[in] pInitArgs = (nil)
Returned:  0 CKR_OK

2: C_GetSlotList
2015-05-05 23:12:53.134
[in] tokenPresent = 0x0
[out] pSlotList: 
Slot 0
Slot 1
[out] *pulCount = 0x2
Returned:  0 CKR_OK

3: C_GetSlotInfo
2015-05-05 23:12:54.723
[in] slotID = 0x0
[out] pInfo: 
      slotDescription:        'Virtual hotplug slot            '
                              '                                '
      manufacturerID:         'OpenSC (www.opensc-project.org) '
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      flags:                   6
        CKF_REMOVABLE_DEVICE             
        CKF_HW_SLOT                      
Returned:  0 CKR_OK
Slot 0: 'Virtual hotplug slot                                            ' 'OpenSC (www.opensc-project.org) '

4: C_GetSlotInfo
2015-05-05 23:12:54.723
[in] slotID = 0x1
[out] pInfo: 
      slotDescription:        'Feitian SCR301 00 00            '
                              '                                '
      manufacturerID:         'OpenSC (www.opensc-project.org) '
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      flags:                   7
        CKF_TOKEN_PRESENT                
        CKF_REMOVABLE_DEVICE             
        CKF_HW_SLOT                      
Returned:  0 CKR_OK
Slot 1: 'Feitian SCR301 00 00                                            ' 'OpenSC (www.opensc-project.org) '

5: C_Initialize
2015-05-05 23:12:54.724
[in] pInitArgs = (nil)
Returned:  0 CKR_OK
Child done. 0

5: C_OpenSession
2015-05-05 23:12:54.845
[in] slotID = 0x1
[in] flags = 0x4
pApplication=(nil)
Notify=(nil)
[out] *phSession = 0x21dada0
Returned:  0 CKR_OK

6: C_Login
2015-05-05 23:12:54.845
[in] hSession = 0x21dada0
[in] userType = CKU_USER
[in] pPin[ulPinLen] 0000000000400b5d / 4
    00000000  30 30 30 30                                      0000            
Returned:  5 CKR_GENERAL_ERROR
C_Login failed 5

-- 
dwmw2

Re: [Opensc-devel] How to find "hidden" ID-One Cosmo reader on Crypt Smart R2 microSD

[Frank M. <mo...@in...>]

You should look at 'lsusb -v' to see if you have an other interface node next to the storage device. However, without a driver for it you can't access the smart card.
--
Frank Morgner

Am 05.05.2015 8:01 vorm. schrieb Anthony Alba <asc...@gm...>:
>
> Hi list, 
>
> I have a microSD card "crypt smart R2",  card, which has a combo 
> ID-One Cosmo reader 
> and a Oberthur 128k v7 smartcard. 
>
> When plugged into a generic USB media reader, only a storage device appears. 
>
> Under Windows, after installing the ID-One Cosmo microSD Driver, both 
> a smartcard reader and 
> smartcard device appear in Device Manager. 
> 1. A removable media device appears 
> 2. Smart card readers: ID-One Cosmo microSD Reader Driver 
> 3. Smart cards: ActivIdentity Mini Driver (Oberthur ID-One Cosmo v7.0 128K) 
>
> Is there a way to get OpenSC to "see" the ID-One Cosmo smartcard/reader combo? 
>
> Here is the storage dmesg 
>
> lsusb 
> Bus 001 Device 044: ID 090c:6200 Silicon Motion, Inc. - Taiwan 
> (formerly Feiya Technology Corp.) microSD card reader 
>
> usb 1-13: new high-speed USB device number 44 using xhci_hcd 
> usb 1-13: New USB device found, idVendor=090c, idProduct=6200 
> usb 1-13: New USB device strings: Mfr=1, Product=2, SerialNumber=3 
> usb 1-13: Product: Generic USB2.0 card 
> usb 1-13: Manufacturer: Silicon Motion, Inc. 
> usb 1-13: SerialNumber: 12345678901234567890 
> usb 1-13: ep 0x81 - rounding interval to 128 microframes, ep desc says 
> 255 microframes 
> usb 1-13: ep 0x2 - rounding interval to 128 microframes, ep desc says 
> 255 microframes 
> usb-storage 1-13:1.0: USB Mass Storage device detected 
> scsi host89: usb-storage 1-13:1.0 
> scsi 89:0:0:0: Direct-Access     Generic  USB  SD Reader   1.00 PQ: 0 
> ANSI: 0 CCS 
> sd 89:0:0:0: Attached scsi generic sg5 type 0 
> sd 89:0:0:0: [sdd] 3874816 512-byte logical blocks: (1.98 GB/1.84 GiB) 
> sd 89:0:0:0: [sdd] Write Protect is off 
> sd 89:0:0:0: [sdd] Mode Sense: 4b 00 00 08 
> sd 89:0:0:0: [sdd] No Caching mode page found 
> sd 89:0:0:0: [sdd] Assuming drive cache: write through 
> sdd: sdd1 
> sd 89:0:0:0: [sdd] Attached SCSI removable disk 
>
>
>
> Regards 
> Anthont 
>
> ------------------------------------------------------------------------------ 
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications 
> Performance metrics, stats and reports that give you Actionable Insights 
> Deep dive visibility with transaction tracing using APM Insight. 
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y 
> _______________________________________________ 
> Opensc-devel mailing list 
> Ope...@li... 
> https://lists.sourceforge.net/lists/listinfo/opensc-devel 

Re: [Opensc-devel] How to find "hidden" ID-One Cosmo reader on Crypt Smart R2 microSD

[Vincent Le T. <vin...@my...>]

That's more a pcsc (reader) question, no ?
My guess is that the reader doesn't implement ccid or that you forgot to
install pcsc.
Vincent

Le mardi 5 mai 2015, Anthony Alba <asc...@gm...> a écrit :

> Hi list,
>
> I have a microSD card "crypt smart R2",  card, which has a combo
> ID-One Cosmo reader
> and a Oberthur 128k v7 smartcard.
>
> When plugged into a generic USB media reader, only a storage device
> appears.
>
> Under Windows, after installing the ID-One Cosmo microSD Driver, both
> a smartcard reader and
> smartcard device appear in Device Manager.
>  1. A removable media device appears
>  2. Smart card readers: ID-One Cosmo microSD Reader Driver
>  3. Smart cards: ActivIdentity Mini Driver (Oberthur ID-One Cosmo v7.0
> 128K)
>
> Is there a way to get OpenSC to "see" the ID-One Cosmo smartcard/reader
> combo?
>
> Here is the storage dmesg
>
> lsusb
> Bus 001 Device 044: ID 090c:6200 Silicon Motion, Inc. - Taiwan
> (formerly Feiya Technology Corp.) microSD card reader
>
> usb 1-13: new high-speed USB device number 44 using xhci_hcd
> usb 1-13: New USB device found, idVendor=090c, idProduct=6200
> usb 1-13: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-13: Product: Generic USB2.0 card
> usb 1-13: Manufacturer: Silicon Motion, Inc.
> usb 1-13: SerialNumber: 12345678901234567890
> usb 1-13: ep 0x81 - rounding interval to 128 microframes, ep desc says
> 255 microframes
> usb 1-13: ep 0x2 - rounding interval to 128 microframes, ep desc says
> 255 microframes
> usb-storage 1-13:1.0: USB Mass Storage device detected
> scsi host89: usb-storage 1-13:1.0
> scsi 89:0:0:0: Direct-Access     Generic  USB  SD Reader   1.00 PQ: 0
> ANSI: 0 CCS
> sd 89:0:0:0: Attached scsi generic sg5 type 0
> sd 89:0:0:0: [sdd] 3874816 512-byte logical blocks: (1.98 GB/1.84 GiB)
> sd 89:0:0:0: [sdd] Write Protect is off
> sd 89:0:0:0: [sdd] Mode Sense: 4b 00 00 08
> sd 89:0:0:0: [sdd] No Caching mode page found
> sd 89:0:0:0: [sdd] Assuming drive cache: write through
>  sdd: sdd1
> sd 89:0:0:0: [sdd] Attached SCSI removable disk
>
>
>
> Regards
> Anthont
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

[Opensc-devel] How to find "hidden" ID-One Cosmo reader on Crypt Smart R2 microSD

[Anthony A. <asc...@gm...>]

Hi list,

I have a microSD card "crypt smart R2",  card, which has a combo
ID-One Cosmo reader
and a Oberthur 128k v7 smartcard.

When plugged into a generic USB media reader, only a storage device appears.

Under Windows, after installing the ID-One Cosmo microSD Driver, both
a smartcard reader and
smartcard device appear in Device Manager.
 1. A removable media device appears
 2. Smart card readers: ID-One Cosmo microSD Reader Driver
 3. Smart cards: ActivIdentity Mini Driver (Oberthur ID-One Cosmo v7.0 128K)

Is there a way to get OpenSC to "see" the ID-One Cosmo smartcard/reader combo?

Here is the storage dmesg

lsusb
Bus 001 Device 044: ID 090c:6200 Silicon Motion, Inc. - Taiwan
(formerly Feiya Technology Corp.) microSD card reader

usb 1-13: new high-speed USB device number 44 using xhci_hcd
usb 1-13: New USB device found, idVendor=090c, idProduct=6200
usb 1-13: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-13: Product: Generic USB2.0 card
usb 1-13: Manufacturer: Silicon Motion, Inc.
usb 1-13: SerialNumber: 12345678901234567890
usb 1-13: ep 0x81 - rounding interval to 128 microframes, ep desc says
255 microframes
usb 1-13: ep 0x2 - rounding interval to 128 microframes, ep desc says
255 microframes
usb-storage 1-13:1.0: USB Mass Storage device detected
scsi host89: usb-storage 1-13:1.0
scsi 89:0:0:0: Direct-Access     Generic  USB  SD Reader   1.00 PQ: 0
ANSI: 0 CCS
sd 89:0:0:0: Attached scsi generic sg5 type 0
sd 89:0:0:0: [sdd] 3874816 512-byte logical blocks: (1.98 GB/1.84 GiB)
sd 89:0:0:0: [sdd] Write Protect is off
sd 89:0:0:0: [sdd] Mode Sense: 4b 00 00 08
sd 89:0:0:0: [sdd] No Caching mode page found
sd 89:0:0:0: [sdd] Assuming drive cache: write through
 sdd: sdd1
sd 89:0:0:0: [sdd] Attached SCSI removable disk



Regards
Anthont

Re: [Opensc-devel] cryptomate64 support

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

When you go to implement SM, please have a look at existing SM code in OpenSC such as the cwa14589.c and related files used by the card-dnie.c driver.


On 5/4/2015 9:50 AM, Carsten Blüggel wrote:
> Hi all,
>
> there is a new fork now, dedicated to an ACS acos5_64-driver (CryptoMate64):
>
> https://github.com/carblue/OpenSC/tree/master/src
>
> It's current status is:
> The function 'acos5_64_compute_signature', called when a priv. key usage is sign only, is known not to work properly.
> Secure Messaging is not implemented.
> Changing contents on the card is not implemented.
> If reading the card only, many usage scenarios should work, for example:
> Konsole output
> ssh-add -e /usr/lib/pkcs11/opensc-pkcs11.so
>
> The procedure to compile/install is as described in
> https://github.com/OpenSC/OpenSC/wiki/Compiling-and-Installing-OpenSC-on-Unix-flavors
> with 1 amendment: I didn't install the acsccid package (libccid seems to be sufficiant).
> (Replacing 'sudo make install' by 'sudo checkinstall' might be an option for easy removal lateron.)
>
> Feel free to contact me, if You want write access on this fork.
>
> Regards,
> Carsten
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] cryptomate64 support

[Carsten B. <ka6...@on...>]

Hi all,

there is a new fork now, dedicated to an ACS acos5_64-driver (CryptoMate64):

https://github.com/carblue/OpenSC/tree/master/src

It's current status is:
The function 'acos5_64_compute_signature', called when a priv. key usage 
is sign only, is known not to work properly.
Secure Messaging is not implemented.
Changing contents on the card is not implemented.
If reading the card only, many usage scenarios should work, for example:
Konsole output
ssh-add -e /usr/lib/pkcs11/opensc-pkcs11.so

The procedure to compile/install is as described in
https://github.com/OpenSC/OpenSC/wiki/Compiling-and-Installing-OpenSC-on-Unix-flavors
with 1 amendment: I didn't install the acsccid package (libccid seems to 
be sufficiant).
(Replacing 'sudo make install' by 'sudo checkinstall' might be an option 
for easy removal lateron.)

Feel free to contact me, if You want write access on this fork.

Regards,
Carsten

Re: [Opensc-devel] Request for inclusion of a new driver

[Vincent Le T. <vin...@my...>]

Hi,

The pull request is #453 (https://github.com/OpenSC/OpenSC/pull/453).

Frank already commented it
(there is a reference to a potential fix #454,
https://github.com/OpenSC/OpenSC/pull/454 - but the pull request doesn't
rely on it now)

regards,
Vincent

2015-04-29 15:51 GMT+02:00 Philip Wendland <wen...@gm...>:

> On 04/29/2015 03:08 PM, Vincent Le Toux wrote:
> > How should I submit the driver ?
> > A patch file ? Directly the c file + the instructions to register it ?
> > A pull request ? (will be a mess for me because my minidriver change is
> > still pending)
>
> My way of doing this (I don't know if it was the apporach most desired
> by the OpenSC team) was to have a pull request for the card driver, and
> different pull requests for fixes that touched general code.
>
> I had a seperate *local* branch where both (all) where combined for
> testing. I did also rebase the card driver from time to time onto the
> most recent OpenSC/master, to test it with the newest version. (This can
> also be done locally only.)
>
> git reset --hard (careful!), rebase/merge and cherry-pick could be
> useful tools for your local testing branch. Or you can work on the
> testing branch, and if the next commit works, integrate it in the
> driver-pull-request-branch.
>
> Philip
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>



-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

Re: [Opensc-devel] cryptomate64 support

[Carsten <ka6...@on...>]

>>On 24.04.2015, Pierre LADEN  wrote:
 >>
 >>Hi,
 >>
 >>Just wanted to let you know the end of the story, it might help other 
"lost" users.
 >>
 >>ACS send us a "Linux client kit" which provide PKCS11 lib for their 
tokens.
 >>The provided admin tool works quite well with Linux, allowing to 
manage the tokens.
 >>Ssh client, or pkcs11 compliant browser are working too, with that 
same lib.
 >>
 >>Unfortunately the library (libacospkcs11.so) is not opensource, and 
ACS does not seem to provide a full opensource opensc module.
 >>
 >>Regards,
 >>Pierre


Hi all,
the existence of a "Linux client kit" is good news for me, another 
"lost" user.
I tried to implement an "acos5_64"-driver for CryptoMate64 with some 
success, but I'm stuck finishing that.
What I can do and did, is implementing any functionality the reference 
manual exposes (except secure messaging so far), but don't know any more 
how to integrate that into the opensc framework.
After many hours of spare time spent on this open source project, I'm at 
the point to decide, either to give up and buy, or continue with 
substantiell help/co-working/take-over from/by somebody interested.


As an example of what is working (opensc-tool seems complete, 
opensc-explorer seems read-only complete), a listing of pkcs11-tool:
(The contents of my usb token have been set up based on an 
initialization with my employers windows client kit, populated/extended 
manually with 4 RSA keys, ODF, AODF, PrKDF, PuKDF, CDF (experimentell, 
self-signed), the pkcs#15-structure seems to be readable by opensc):

carsten@tux:~$ pkcs11-tool --module=/usr/lib/pkcs11/pkcs11-spy.so -lt
Using slot 1 with a present token (0x1)
Logging in to "(unknown) (Basic PIN)".
Please enter User PIN:
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  seems to be OK
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only RSA signatures)
  testing key 0 (DecryptSignenL)
  all 4 signature functions seem to work
  testing signature mechanisms:
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    SHA256-RSA-PKCS: OK
  testing key 1 (1790 bits, label=DecryptSignenS) with 1 signature 
mechanism
  testing key 2 (4096 bits, label=Decrypten) with 1 signature mechanism 
-- can't be used to sign/verify, skipping
  testing key 3 (4095 bits, label=Signen) with 1 signature mechanism
Verify (currently only for RSA):
  testing key 0 (DecryptSignenL)
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
  testing key 1 (DecryptSignenS) with 1 mechanism
    RSA-X-509: OK
  testing key 2 (Decrypten) with 1 mechanism
-- can't be used to sign/verify, skipping
  testing key 3 (Signen) with 1 mechanism
    RSA-X-509:   ERR: verification failed  ERR: C_Verify() returned 
CKR_SIGNATURE_INVALID (0xc0)
Unwrap: not implemented
Decryption (RSA)
  testing key 0 (DecryptSignenL)
    RSA-X-509: OK
    RSA-PKCS: OK
  testing key 1 (DecryptSignenS)
    RSA-X-509: OK
    RSA-PKCS: OK
  testing key 2 (Decrypten)
    RSA-X-509: OK
    RSA-PKCS: OK
  testing key 3 (Signen)  -- can't be used to decrypt, skipping
2 errors

Surprisingly, the first real word application, using openssh with the 
token, now suddenly does work, maybe due to upgrading to Ubuntu 15.04.
carsten@tux:~$ ssh-add -L
The agent has no identities.
carsten@tux:~$ ssh-add -s /usr/lib/pkcs11/opensc-pkcs11.so
Enter passphrase for PKCS#11:
Card added: /usr/lib/pkcs11/opensc-pkcs11.so
carsten@tux:~$ ssh-add -l
4095 0b:b5:ce:fe:ec:b9:c9:41:49:b2:a8:10:6f:ae:83:b0 
/usr/lib/pkcs11/opensc-pkcs11.so (RSA)
4095 3f:a8:b8:ed:90:04:98:2b:00:d6:10:dc:ce:a3:ec:2c 
/usr/lib/pkcs11/opensc-pkcs11.so (RSA)
1790 f6:da:8c:a3:cd:72:fb:6b:da:8c:51:d5:b9:c5:70:d9 
/usr/lib/pkcs11/opensc-pkcs11.so (RSA)
4096 d9:37:92:15:0b:41:50:0d:25:a1:ef:04:41:d8:73:a0 
/usr/lib/pkcs11/opensc-pkcs11.so (RSA)


carsten@tux:~$ opensc-tool -D
Configured card drivers:
  cardos           Siemens CardOS
  ...
  acos5            ACS ACOS5 card
  acos5_64         ACS ACOS5-64 Cryptographic USB/Card
  ...


Any comments are highly appreciated.

Regards,

Carsten

Re: [Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

[David W. <dw...@in...>]

On Fri, 2015-05-01 at 18:54 +0100, David Woodhouse wrote:
> On Fri, 2015-05-01 at 18:58 +0200, Ludovic Rousseau wrote:
> > 
> > > I note pcscd thinks there are two clients. I wonder if this is related
> > > to the pkcs11_helper behaviour at fork() that causes OpenVPN to 
> > > deadlock in a number of other circumstances:
> > >  https://bugzilla.redhat.com/show_bug.cgi?id=1135932
> > 
> > That may be the problem.
> > 
> > From the pcscd log file:
> > 00000007 winscard_svc.c:944:MSGCheckHandleAssociation() 
> > Invalidated handle
> 
> So... where does the bug lie?
> 
> On fork, the pkcs11-helper library will call C_Initialize() in the
> child for each provider module which was already active in the 
> parent.
> 
> Is that expected to work? It doesn't seem to — it causes this issue
> with the OpenSC PKCS#11 module, and it causes p11-kit-proxy.so to
> deadlock¹.
> 
> The cheap solution for now might be to avoid the whole question and
> use vfork() instead of fork() in OpenVPN for these cases. It's only
> fork-and-exec anyway. But it does want to be fixed properly, whatever
> the 'fix' should be.

FWIW this *is* valid behaviour from pkcs11-helper. It's recommended by
the PKCS#11 specification. See §2.5.2 of the Usage Guide¹ at 
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html#_Toc406759987
and in particular the part which says:

"In the scenario specified above, C should actually call C_Initialize
whether or not it needs to use Cryptoki if it has no need to use
Cryptoki, it should then call C_Finalize immediately thereafter.  This
(having the child immediately call C_Initialize and then call
C_Finalize if the parent is using Cryptoki) is considered to be good
Cryptoki programming practice, since it can prevent the existence of
dangling duplicate resources that were created at the time of the
fork() call; however, it is not required by Cryptoki."

So the problem here is either in OpenSC or PC/SC. Probably the former 
— perhaps OpenSC should be discarding (closing?) any existing file handles on getting the new C_Initialize() 
call?

-- 
dwmw2

¹ Thanks to Alon for pointing me at that.

Re: [Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

[David W. <dw...@in...>]

On Fri, 2015-05-01 at 18:58 +0200, Ludovic Rousseau wrote:
> 
> > I note pcscd thinks there are two clients. I wonder if this is related
> > to the pkcs11_helper behaviour at fork() that causes OpenVPN to deadlock in a number of other
> > circumstances:
> >  https://bugzilla.redhat.com/show_bug.cgi?id=1135932
> 
> That may be the problem.
> 
> From the pcscd log file:
> 00000007 winscard_svc.c:944:MSGCheckHandleAssociation() Invalidated handle

So... where does the bug lie?

On fork, the pkcs11-helper library will call C_Initialize() in the
child for each provider module which was already active in the parent.

Is that expected to work? It doesn't seem to — it causes this issue
with the OpenSC PKCS#11 module, and it causes p11-kit-proxy.so to
deadlock¹.

The cheap solution for now might be to avoid the whole question and
use vfork() instead of fork() in OpenVPN for these cases. It's only
fork-and-exec anyway. But it does want to be fixed properly, whatever
the 'fix' should be.

-- 
dwmw2
¹ https://www.mail-archive.com/p11...@li.../msg00126.html

Re: [Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

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

2015-05-01 15:00 GMT+02:00 David Woodhouse <dw...@in...>:
> On Fri, 2015-05-01 at 13:47 +0100, David Woodhouse wrote:
>> On Fri, 2015-05-01 at 00:50 +0200, Ludovic Rousseau wrote:
>> >
>> > It looks like pcscd has crashed and is no more responding.
>>
>> It hasn't. It's working fine and continues to happily service
>> requests, for example the immediately subsequent run of OpenConnect
>> (built with OpenSSL+libp11) which works fine:
>>  http://david.woodhou.se/openconnect-working.txt
>>
>>
>> > Can you also generate pcscd log as described in
>> > https://pcsclite.alioth.debian.org/ccid.html#support
>>
>> http://david.woodhou.se/pcsc-debug.txt along with newly-generated
>> http://david.woodhou.se/openvpn-fail-2.txt
>
> I note pcscd thinks there are two clients. I wonder if this is related
> to the pkcs11_helper behaviour at fork() that causes OpenVPN to deadlock in a number of other
> circumstances:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1135932

That may be the problem.

>From the pcscd log file:
00000007 winscard_svc.c:944:MSGCheckHandleAssociation() Invalidated handle

Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

[David W. <dw...@in...>]

On Fri, 2015-05-01 at 13:47 +0100, David Woodhouse wrote:
> On Fri, 2015-05-01 at 00:50 +0200, Ludovic Rousseau wrote:
> > 
> > It looks like pcscd has crashed and is no more responding.
> 
> It hasn't. It's working fine and continues to happily service
> requests, for example the immediately subsequent run of OpenConnect
> (built with OpenSSL+libp11) which works fine:
>  http://david.woodhou.se/openconnect-working.txt
> 
> 
> > Can you also generate pcscd log as described in
> > https://pcsclite.alioth.debian.org/ccid.html#support
> 
> http://david.woodhou.se/pcsc-debug.txt along with newly-generated
> http://david.woodhou.se/openvpn-fail-2.txt

I note pcscd thinks there are two clients. I wonder if this is related
to the pkcs11_helper behaviour at fork() that causes OpenVPN to deadlock in a number of other
circumstances:
 https://bugzilla.redhat.com/show_bug.cgi?id=1135932


-- 
dwmw2

Re: [Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

[David W. <dw...@in...>]

On Fri, 2015-05-01 at 00:50 +0200, Ludovic Rousseau wrote:
> 
> It looks like pcscd has crashed and is no more responding.

It hasn't. It's working fine and continues to happily service
requests, for example the immediately subsequent run of OpenConnect
(built with OpenSSL+libp11) which works fine:
 http://david.woodhou.se/openconnect-working.txt


> Can you also generate pcscd log as described in
> https://pcsclite.alioth.debian.org/ccid.html#support

http://david.woodhou.se/pcsc-debug.txt along with newly-generated
http://david.woodhou.se/openvpn-fail-2.txt

-- 
dwmw2

Re: [Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

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

2015-05-01 0:10 GMT+02:00 David Woodhouse <dw...@in...>:
> I'm fixing pkcs11-helper to support RFC7512 URIs, but I'm having
> difficulty testing it even before I make any changes.
>
> I'm using a Yubikey NEO.
>
> I'm getting this failure when testing with OpenVPN (which uses
> pkcs11-helper):
>
> Enter PIV_II (PIV Card Holder pin) token Password:
>
> 27: C_Login
> 2015-04-30 22:23:36.592
> [in] hSession = 0x143ffb0
> [in] userType = CKU_USER
> [in] pPin[ulPinLen] 00007ffcd447d0e0 / 4
>     00000000  66 69 73 68                                      fish
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:259:C_Login: C_Login(0x143ffb0, 1)
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:279:C_Login: C_Login() slot->login_user 4294967295
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:288:C_Login: C_Login() userType 1
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] framework-pkcs15.c:1414:pkcs15_login: pkcs15-login: userType 0x1, PIN length 4
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:293:sc_pkcs15_verify_pin: called
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(type:0;method:1;len:)
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] card.c:325:sc_lock: called
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] reader-pcsc.c:517:pcsc_lock: called
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] reader-pcsc.c:544:pcsc_lock: Yubico Yubikey NEO OTP+CCID 00 00:SCardBeginTransaction failed: 0x8010001d
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:356:sc_pkcs15_verify_pin: sc_lock() failed: -1101 (No readers found)
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] framework-pkcs15.c:1528:pkcs15_login: PKCS15 verify PIN returned -1101
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] misc.c:61:sc_to_cryptoki_error_common: libopensc return value: -1101 (No readers found)
> 0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:290:C_Login: fLogin() rv 5
> Returned:  5 CKR_GENERAL_ERROR
> Thu Apr 30 22:23:36 2015 PKCS#11: Cannot perform signature 5:'CKR_GENERAL_ERROR'
> Thu Apr 30 22:23:36 2015 OpenSSL: error:14099004:SSL routines:SSL3_SEND_CLIENT_VERIFY:RSA lib
>
> Full output at http://david.woodhou.se/openvpn-failing.txt and pcsc-spy
> log at http://david.woodhou.se/pcsc-spy.txt

from pcsc-spy.txt:
SCardStatus
 i hCard: 0x6FCFAD34
 i pcchReaderLen 0x00000000 (0)
 i pcbAtrLen 0x00000021 (33)
 o cchReaderLen 0x00000000 (0)
 o mszReaderName NULL
 o dwState 0x00000000 (0)
 o dwProtocol 0x00000000 (0)
 o bAtrLen 0x00000000 (0)
 o bAtr
 => RPC transport error. (SCARD_F_COMM_ERROR [0x80100013])  [0.000000097]
SCardGetStatusChange
 i hContext: 0x647ADCA1
 i dwTimeout: 0x00000000 (0)
 i cReaders: 1
 i szReader: Yubico Yubikey NEO OTP+CCID 00 00
 i  dwCurrentState: SCARD_STATE_CHANGED, SCARD_STATE_PRESENT (0x00000022)
 i  dwEventState: SCARD_STATE_CHANGED, SCARD_STATE_PRESENT (0x00000022)
 i  Atr length: 0x00000014 (20)
 i  Atr: 3B FA 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 4E 45 4F A6
 o szReader: Yubico Yubikey NEO OTP+CCID 00 00
 o  dwCurrentState: SCARD_STATE_CHANGED, SCARD_STATE_PRESENT (0x00000022)
 o  dwEventState: SCARD_STATE_CHANGED, SCARD_STATE_PRESENT (0x00000022)
 o  Atr length: 0x00000014 (20)
 o  Atr: 3B FA 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 4E 45 4F A6
 => Service not available. (SCARD_E_NO_SERVICE [0x8010001D])  [0.000000046]

It looks like pcscd has crashed and is no more responding.

Can you also generate pcscd log as described in
https://pcsclite.alioth.debian.org/ccid.html#support

Bye

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] C_Login returns CKR_GENERAL_ERROR / SCardBeginTransaction failed: 0x8010001d

[David W. <dw...@in...>]

I'm fixing pkcs11-helper to support RFC7512 URIs, but I'm having
difficulty testing it even before I make any changes.

I'm using a Yubikey NEO.

I'm getting this failure when testing with OpenVPN (which uses
pkcs11-helper):

Enter PIV_II (PIV Card Holder pin) token Password:

27: C_Login
2015-04-30 22:23:36.592
[in] hSession = 0x143ffb0
[in] userType = CKU_USER
[in] pPin[ulPinLen] 00007ffcd447d0e0 / 4
    00000000  66 69 73 68                                      fish            
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:259:C_Login: C_Login(0x143ffb0, 1)
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:279:C_Login: C_Login() slot->login_user 4294967295
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:288:C_Login: C_Login() userType 1
0x7fa848020800 22:23:36.592 [opensc-pkcs11] framework-pkcs15.c:1414:pkcs15_login: pkcs15-login: userType 0x1, PIN length 4
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:293:sc_pkcs15_verify_pin: called
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:294:sc_pkcs15_verify_pin: PIN(type:0;method:1;len:)
0x7fa848020800 22:23:36.592 [opensc-pkcs11] card.c:325:sc_lock: called
0x7fa848020800 22:23:36.592 [opensc-pkcs11] reader-pcsc.c:517:pcsc_lock: called
0x7fa848020800 22:23:36.592 [opensc-pkcs11] reader-pcsc.c:544:pcsc_lock: Yubico Yubikey NEO OTP+CCID 00 00:SCardBeginTransaction failed: 0x8010001d
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs15-pin.c:356:sc_pkcs15_verify_pin: sc_lock() failed: -1101 (No readers found)
0x7fa848020800 22:23:36.592 [opensc-pkcs11] framework-pkcs15.c:1528:pkcs15_login: PKCS15 verify PIN returned -1101
0x7fa848020800 22:23:36.592 [opensc-pkcs11] misc.c:61:sc_to_cryptoki_error_common: libopensc return value: -1101 (No readers found)
0x7fa848020800 22:23:36.592 [opensc-pkcs11] pkcs11-session.c:290:C_Login: fLogin() rv 5
Returned:  5 CKR_GENERAL_ERROR
Thu Apr 30 22:23:36 2015 PKCS#11: Cannot perform signature 5:'CKR_GENERAL_ERROR'
Thu Apr 30 22:23:36 2015 OpenSSL: error:14099004:SSL routines:SSL3_SEND_CLIENT_VERIFY:RSA lib

Full output at http://david.woodhou.se/openvpn-failing.txt and pcsc-spy
log at http://david.woodhou.se/pcsc-spy.txt 


-- 
dwmw2

Re: [Opensc-devel] RFC: Renaming engine_pkcs11.so to libpkcs11.so

[David W. <dw...@in...>]

On Wed, 2015-04-29 at 16:20 -0500, Douglas E Engert wrote:
> OK, you have answered my questions.

Excellent :)

So, any thoughts on how (if) to transition to 'libpkcs11.so'?

One option is just to go ahead and rename it. That means that existing
users would need to change their configuration to reflect the new
filename. And in fact *mostly* those users will have p11-kit and will
be able to migrate to just doing things the simple way — just
specifying the engine by name (which will now work) and using a
RFC7512 PKCS#11 URI.

It's not nice to *force* them to switch though. Having a symlink might
be nice, but I can't see how to do that since the makefiles don't even
seem to ™know* what the .so extension is on a given platform. We only
ask for 'engine_pkcs11.la'.

In the Fedora packaging for now I *have* just made a symlink, but I
really dislike doing anything only in the distro rather than fixing it
upstream.

-- 
dwmw2

Re: [Opensc-devel] RFC: Renaming engine_pkcs11.so to libpkcs11.so

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

OK, you have answered my questions.


On 4/29/2015 1:00 PM, David Woodhouse wrote:
> On Wed, 2015-04-29 at 11:00 -0500, Douglas E Engert wrote:
>> With this change cause problems in systems where libpkcs11.so
>> already exist in the standard load path?  For example Oracle Solaris.
>> /usr/lib/64/libpkcs11.so.1
>>
>> http://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/chapter1
>> -1/index.html
>>
>>
>> I would assume libpkcs11.so would implement a PKCS#11 module, not an engine for OpenSSL.
>> Will this only work because its in the engine directory and thus only work
>> when using OpenSSL?
>
> This doesn't go in the generic library path (and neither do PKCS#11
> modules need to, for that matter, but that's a different issue). This
> is in the OpenSSL engines directory, for example in my case
> /usr/lib64/openssl/engines/.
>
> That already contains a bunch of engines with generic-sounding
> filenames like libcapi.so, libgmp.so, etc. —the latter of which would
> *definitely* be a conflict with a real shared library in /usr/lib64.
>
> Those are loadable with ENGINE_by_id("foo") or by using '-engine foo'
> on the command line, because they have the standard filename that
> OpenSSL expects. Our engine_pkcs11.so, on the other hand, is not
> because it doesn't have a filename in the correct form. Which is the
> problem I'm trying to solve, of course.
>
> In the past it didn't matter because you had to jump through a lot of
> hoops to preconfigure it to tell it which PKCS#11 provider module to
> load anyway. But now you don't because...
>
>> On 4/29/2015 8:55 AM, David Woodhouse wrote:
>>> I've just fixed the Fedora packages (for F22+) so that this kind of
>>> command line will Just Work with RFC7512 PKCS#11 URIs:
>>>
>>> $ openssl req -new -keyform engine -engine pkcs11 -key
>>> "pkcs11:manufacturer=piv_II;id=%01"
>>
>> The OpenSC engine_pkcs11.so can load any PKCS#11 module, not just
>> the OpenSC version. It could even load the Solaris.
>> /usr/lib/64/libpkcs11.so.1
>
> ... reordering your message a little ...
>
>>> Do you still need an openssl.cnf with something like:
>>>
>>> [engine_section]
>>> pkcs11 = pkcs11_section
>>>
>>> [pkcs11_section]
>>> dynamic_path = /some/path/ssl/engine/libpkcs11.so
>>> [...]
>
> In a system with p11-kit, you don't need that. The engine will by
> *default* load p11-kit-proxy.so, which as its name implies is just a
> proxy which exposes each of the modules specified in the system
> configuration as slots of itself.
>
> You can still have a configuration and specify a different provider
> module, of course. Using p11-kit-proxy.so by default is only changing
> the behaviour in a case that *previously* would have just aborted with
> an error (no provider specified).
>
>>> Ideally, all of that '-engine pkcs11 -keyform engine' will
>>> eventually
>>> go away. When you provide a -key argument that starts with
>>> 'pkcs11:'
>>> it should *infer* that, like GnuTLS and other things do (including
>>> OpenConnect when built against OpenSSL+libp11).
>>
>> That sounds like the equivalent of having the engine code is built
>> in.
>
> Right. That would be nice.
>
>> What do you mean by eventually. Are you saying when OpenSSL supports
>> calling a PKCS#11 module, without using an engine?
>
> Technically, I don't care if it's using an engine or not, to be
> honest. But I *do* want to reach the point where you can just specify
> a key as "pkcs11:..." instead of a filename and it'll Just Work, like
> it does in GnuTLS.
>
> If that's done by having some wrapper code which automatically invokes
> the engine, or if that's done by relicensing libp11 to be compatible
> with the OpenSSL licence and merging it *properly*, or some other
> method, doesn't really matter.
>
> And no, I'm not going to attempt to put any kind of time estimate on
> this "eventually", either. Even if we don't count the part where we
> submit it to OpenSSL and have it ignored for years at a time :)
>
> But it is the end goal that I'd like to keep in mind.
>
>>> But in the meantime, we can settle for this because at least it's a
>>> massive improvement over what we had before.
>>
>> It may work, but just does not sound right to me at this time.
>>
>> Processes like login that use PAM can drag in packages like LDAP,
>> Kerberos and  NSS, some of which also support smart card login via
>> pkcs#11 too.
>
> Yes. And from the Fedora distribution point of view I want to make
> things work consistently. In all cases unless you explicitly *specify*
> a provider, you should have the modules which are present in the
> system's p11-kit configuration. And you should be able to specify
> objects by their PKCS#11 URI wherever you could specify a key or cert
> with a filename.
>
> The fixes for the engine and pkcs11_helper are part of that.
>
> And obviously although I'm *starting* with Fedora because it's easier
> to effect change there and get distro-wide policies like this
> implemented, I do expect that other systems (not just Linux) will
> follow.
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] RFC: Renaming engine_pkcs11.so to libpkcs11.so

[David W. <dw...@in...>]

On Wed, 2015-04-29 at 11:00 -0500, Douglas E Engert wrote:
> With this change cause problems in systems where libpkcs11.so 
> already exist in the standard load path?  For example Oracle Solaris.
> /usr/lib/64/libpkcs11.so.1
> 
> http://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/chapter1
> -1/index.html
> 
> 
> I would assume libpkcs11.so would implement a PKCS#11 module, not an engine for OpenSSL.
> Will this only work because its in the engine directory and thus only work
> when using OpenSSL?

This doesn't go in the generic library path (and neither do PKCS#11
modules need to, for that matter, but that's a different issue). This
is in the OpenSSL engines directory, for example in my case
/usr/lib64/openssl/engines/.

That already contains a bunch of engines with generic-sounding
filenames like libcapi.so, libgmp.so, etc. —the latter of which would
*definitely* be a conflict with a real shared library in /usr/lib64.

Those are loadable with ENGINE_by_id("foo") or by using '-engine foo'
on the command line, because they have the standard filename that
OpenSSL expects. Our engine_pkcs11.so, on the other hand, is not
because it doesn't have a filename in the correct form. Which is the
problem I'm trying to solve, of course.

In the past it didn't matter because you had to jump through a lot of
hoops to preconfigure it to tell it which PKCS#11 provider module to
load anyway. But now you don't because...

> On 4/29/2015 8:55 AM, David Woodhouse wrote:
> > I've just fixed the Fedora packages (for F22+) so that this kind of
> > command line will Just Work with RFC7512 PKCS#11 URIs:
> > 
> > $ openssl req -new -keyform engine -engine pkcs11 -key 
> > "pkcs11:manufacturer=piv_II;id=%01"
> 
> The OpenSC engine_pkcs11.so can load any PKCS#11 module, not just 
> the OpenSC version. It could even load the Solaris. 
> /usr/lib/64/libpkcs11.so.1

... reordering your message a little ...

> > Do you still need an openssl.cnf with something like:
> >
> > [engine_section]
> > pkcs11 = pkcs11_section
> >
> > [pkcs11_section]
> > dynamic_path = /some/path/ssl/engine/libpkcs11.so
> > [...]

In a system with p11-kit, you don't need that. The engine will by
*default* load p11-kit-proxy.so, which as its name implies is just a
proxy which exposes each of the modules specified in the system
configuration as slots of itself.

You can still have a configuration and specify a different provider
module, of course. Using p11-kit-proxy.so by default is only changing
the behaviour in a case that *previously* would have just aborted with
an error (no provider specified).

> > Ideally, all of that '-engine pkcs11 -keyform engine' will 
> > eventually
> > go away. When you provide a -key argument that starts with 
> > 'pkcs11:'
> > it should *infer* that, like GnuTLS and other things do (including
> > OpenConnect when built against OpenSSL+libp11).
> 
> That sounds like the equivalent of having the engine code is built 
> in.

Right. That would be nice.

> What do you mean by eventually. Are you saying when OpenSSL supports
> calling a PKCS#11 module, without using an engine?

Technically, I don't care if it's using an engine or not, to be
honest. But I *do* want to reach the point where you can just specify 
a key as "pkcs11:..." instead of a filename and it'll Just Work, like
it does in GnuTLS.

If that's done by having some wrapper code which automatically invokes
the engine, or if that's done by relicensing libp11 to be compatible
with the OpenSSL licence and merging it *properly*, or some other
method, doesn't really matter.

And no, I'm not going to attempt to put any kind of time estimate on
this "eventually", either. Even if we don't count the part where we
submit it to OpenSSL and have it ignored for years at a time :)

But it is the end goal that I'd like to keep in mind.

> > But in the meantime, we can settle for this because at least it's a
> > massive improvement over what we had before.
> 
> It may work, but just does not sound right to me at this time.
> 
> Processes like login that use PAM can drag in packages like LDAP, 
> Kerberos and  NSS, some of which also support smart card login via 
> pkcs#11 too.

Yes. And from the Fedora distribution point of view I want to make
things work consistently. In all cases unless you explicitly *specify*
a provider, you should have the modules which are present in the
system's p11-kit configuration. And you should be able to specify
objects by their PKCS#11 URI wherever you could specify a key or cert
with a filename.

The fixes for the engine and pkcs11_helper are part of that.

And obviously although I'm *starting* with Fedora because it's easier
to effect change there and get distro-wide policies like this
implemented, I do expect that other systems (not just Linux) will
follow.

-- 
dwmw2

Re: [Opensc-devel] RFC: Renaming engine_pkcs11.so to libpkcs11.so

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

With this change cause problems in systems where libpkcs11.so already exist
in the standard load path?  For example Oracle Solaris. /usr/lib/64/libpkcs11.so.1

http://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/chapter1-1/index.html


I would assume libpkcs11.so would implement a PKCS#11 module, not an engine for OpenSSL.
Will this only work because its in the engine directory and thus only work
when using OpenSSL?

On 4/29/2015 8:55 AM, David Woodhouse wrote:
> I've just fixed the Fedora packages (for F22+) so that this kind of
> command line will Just Work with RFC7512 PKCS#11 URIs:
>
> $ openssl req -new -keyform engine -engine pkcs11 -key "pkcs11:manufacturer=piv_II;id=%01"

The OpenSC engine_pkcs11.so can load any PKCS#11 module, not just the OpenSC
version. It could even load the Solaris. /usr/lib/64/libpkcs11.so.1

>
> Ideally, all of that '-engine pkcs11 -keyform engine' will eventually
> go away. When you provide a -key argument that starts with 'pkcs11:'
> it should *infer* that, like GnuTLS and other things do (including
> OpenConnect when built against OpenSSL+libp11).

That sounds like the equivalent of having the engine code is built in.
What do you mean by eventually. Are you saying when OpenSSL supports
calling a PKCS#11 module, without using an engine?

Do you still need an openssl.cnf with something like:

[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
dynamic_path = /some/path/ssl/engine/libpkcs11.so
[...]

>
> But in the meantime, we can settle for this because at least it's a
> massive improvement over what we had before.

It may work, but just does not sound right to me at this time.

Processes like login that use PAM can drag in packages like LDAP, Kerberos and
  NSS, some of which also support smart card login via pkcs#11 too.

>
> For now I'm just manually creating a symlink from libpkcs11.so to
> engine_pkcs11.so in the Fedora package to make '-engine pkcs11' work
> in the above.
>
> I'm not quite sure what is the best way to do that upstream. If we do
> actually rename, the old baroque way of doing things will stop
> working. Although it's only a minor tweak.
>
> Or perhaps we could make the symlink in the engine_pkcs11 makefiles...
> except that seems hard since libtool makes the .so file and we don't
> even know what the extension (.so) is.
>

Anyone else feel a little uneasy with this?

>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@gm...>

[Opensc-devel] RFC: Renaming engine_pkcs11.so to libpkcs11.so

[David W. <dw...@in...>]

I've just fixed the Fedora packages (for F22+) so that this kind of
command line will Just Work with RFC7512 PKCS#11 URIs:

$ openssl req -new -keyform engine -engine pkcs11 -key "pkcs11:manufacturer=piv_II;id=%01"

Ideally, all of that '-engine pkcs11 -keyform engine' will eventually
go away. When you provide a -key argument that starts with 'pkcs11:'
it should *infer* that, like GnuTLS and other things do (including
OpenConnect when built against OpenSSL+libp11).

But in the meantime, we can settle for this because at least it's a
massive improvement over what we had before.

For now I'm just manually creating a symlink from libpkcs11.so to
engine_pkcs11.so in the Fedora package to make '-engine pkcs11' work
in the above.

I'm not quite sure what is the best way to do that upstream. If we do
actually rename, the old baroque way of doing things will stop
working. Although it's only a minor tweak.

Or perhaps we could make the symlink in the engine_pkcs11 makefiles...
except that seems hard since libtool makes the .so file and we don't
even know what the extension (.so) is.

-- 
dwmw2

Re: [Opensc-devel] Request for inclusion of a new driver

[Philip W. <wen...@gm...>]

On 04/29/2015 03:08 PM, Vincent Le Toux wrote:
> How should I submit the driver ?
> A patch file ? Directly the c file + the instructions to register it ?
> A pull request ? (will be a mess for me because my minidriver change is
> still pending)

My way of doing this (I don't know if it was the apporach most desired
by the OpenSC team) was to have a pull request for the card driver, and
different pull requests for fixes that touched general code.

I had a seperate *local* branch where both (all) where combined for
testing. I did also rebase the card driver from time to time onto the
most recent OpenSC/master, to test it with the newest version. (This can
also be done locally only.)

git reset --hard (careful!), rebase/merge and cherry-pick could be
useful tools for your local testing branch. Or you can work on the
testing branch, and if the next commit works, integrate it in the
driver-pull-request-branch.

Philip

Re: [Opensc-devel] Request for inclusion of a new driver

[Andreas S. <and...@ca...>]

>> How should I submit the driver ?
>> A patch file ? Directly the c file + the instructions to register it ?
>> A pull request ? (will be a mess for me because my minidriver change is still pending)
> 
> I will let others comment on the above.

Just create a new branch in your repo at Github, put in the required
files and create a pull request for that branch.

Andreas


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com

Re: [Opensc-devel] Request for inclusion of a new driver

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

On 4/29/2015 8:08 AM, Vincent Le Toux wrote:
> No, there is no impact on other files except the one referencing the all the drivers to add a new reference to this driver.
> It is on my opinion a non breaking change (no modification on core functions, no duplication of code, ...)
>
> This change is independant of the minidriver modifications I proposed (but I tested it with this card).
>
> The card is compatible with iso 7816-15 with some small modifications in the commands sent to the card by the driver.
> There is no NDA / license issues as I got the official autorization to publish the current driver with the GPL license.
>
> How should I submit the driver ?
> A patch file ? Directly the c file + the instructions to register it ?
> A pull request ? (will be a mess for me because my minidriver change is still pending)

I will let others comment on the above.

>
> regards,
> Vincent LE TOUX
>
>
> 2015-04-29 14:51 GMT+02:00 Douglas E Engert <dee...@gm... <mailto:dee...@gm...>>:
>
>
>
>     On 4/29/2015 7:19 AM, Vincent Le Toux wrote:
>     > Hi,
>     >
>     > I'd like to request to include a new card driver in OpenSC.
>     > The card is the one produced by MaskTech gmbh.
>     >http://www.masktech.com/
>     >
>     > I've the agreement of the owner about that.
>
>     Any license or NDA issues? Are there specifications published?
>
>     >
>     >
>     > Is it possible ?
>     > If yes, can I include it in the branch I am using to test the minidriver modifications ?
>     > (https://github.com/OpenSC/OpenSC/tree/minidriver-cmck-issues-i426)
>
>     Please try and keep them independent. The minidriver supports many cards.
>
>     You are asking to support a new card. Based on problems with adding previous drivers,
>     new driver developer who are usually new to OpenSC, start making code changes to core
>     functions, or duplicating code.  Having the driver be its own branch can catch many of
>     these modifications that affect other cards.
>
>     Also the new driver may or may not be ready with the minidriver changes that sound
>     like they could be included with 0.15.0
>
>     >
>     > Thanks in advance
>     >
>     > regards
>     >
>     > --
>     > --
>     > Vincent Le Toux
>     >
>     > My Smart Logon
>      > www.mysmartlogon.com <http://www.mysmartlogon.com> <http://www.mysmartlogon.com/>
>      >
>      >
>      > ------------------------------------------------------------------------------
>      > One dashboard for servers and applications across Physical-Virtual-Cloud
>      > Widest out-of-the-box monitoring support with 50+ applications
>      > Performance metrics, stats and reports that give you Actionable Insights
>      > Deep dive visibility with transaction tracing using APM Insight.
>      > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>      >
>      >
>      >
>      > _______________________________________________
>      > Opensc-devel mailing list
>      > Ope...@li... <mailto:Ope...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>     --
>
>        Douglas E. Engert  <DEE...@gm... <mailto:DEE...@gm...>>
>
>
>     ------------------------------------------------------------------------------
>     One dashboard for servers and applications across Physical-Virtual-Cloud
>     Widest out-of-the-box monitoring support with 50+ applications
>     Performance metrics, stats and reports that give you Actionable Insights
>     Deep dive visibility with transaction tracing using APM Insight.
>     http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>     _______________________________________________
>     Opensc-devel mailing list
>     Ope...@li... <mailto:Ope...@li...>
>     https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>
>
>
> --
> --
> Vincent Le Toux
>
> My Smart Logon
> www.mysmartlogon.com <http://www.mysmartlogon.com/>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Request for inclusion of a new driver

[Martin P. <ma...@ma...>]

On 29/04/15 16:08, Vincent Le Toux wrote:
> There is no NDA / license issues as I got the official autorization to
> publish the current driver with the GPL license.
OpenSC is LGPL

MArtin