Menu
▾
▴
opensc-devel — discussion of developement of OpenSC and related projects
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(26) |
Feb
(64) |
Mar
(78) |
Apr
(36) |
May
(51) |
Jun
(40) |
Jul
(43) |
Aug
(102) |
Sep
(50) |
Oct
(71) |
Nov
(42) |
Dec
(29) |
| 2014 |
Jan
(49) |
Feb
(52) |
Mar
(56) |
Apr
(30) |
May
(31) |
Jun
(52) |
Jul
(76) |
Aug
(19) |
Sep
(82) |
Oct
(95) |
Nov
(58) |
Dec
(76) |
| 2015 |
Jan
(135) |
Feb
(43) |
Mar
(47) |
Apr
(72) |
May
(59) |
Jun
(20) |
Jul
(17) |
Aug
(14) |
Sep
(34) |
Oct
(62) |
Nov
(48) |
Dec
(23) |
| 2016 |
Jan
(18) |
Feb
(55) |
Mar
(24) |
Apr
(20) |
May
(33) |
Jun
(29) |
Jul
(18) |
Aug
(15) |
Sep
(8) |
Oct
(21) |
Nov
(5) |
Dec
(23) |
| 2017 |
Jan
(3) |
Feb
|
Mar
(17) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(20) |
Sep
(17) |
Oct
(21) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(62) |
Feb
(4) |
Mar
(4) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
|
Dec
(5) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(14) |
Feb
(21) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2023 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Douglas E E. <dee...@gm...> - 2018-01-12 18:20:50
|
It turns out I have from Aventra a MyEID card card which also has PIV. Due to the way the card responds to the PIV SELECT AID the PIV driver does not select the card. I have a fix for this. But before submitting a PR, I need to look at the MyEID as it does have an AID: ./pkcs15-tool --list-applications Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00 Application 'Aventra': AID: A000000063504B43532D3135 and this is then another card that can have multiple applets doug@XUbuntu-16:/opt/ossl-1.1/bin$ ./opensc-tool -s "00 A4 04 00 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 00" Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00 Sending: 00 A4 04 00 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 00 Received (SW1=0x90, SW2=0x00): 6F 25 81 02 7F FF 82 01 38 83 02 50 15 86 03 11 o%......8..P.... 30 FF 85 02 00 E2 8A 01 07 84 0C A0 00 00 00 63 0..............c 50 4B 43 53 2D 31 35 PKCS-15 doug@XUbuntu-16:/opt/ossl-1.1/bin$ ./opensc-tool -s "00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00" Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00 Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 Received (SW1=0x90, SW2=0x00): 4F 06 00 00 10 00 01 00 79 08 4F 06 00 00 10 00 O.......y.O..... 01 00 50 18 4D 79 45 49 44 20 50 49 56 20 63 61 ..P.MyEID PIV ca 72 64 20 65 6D 75 6C 61 74 69 6F 6E rd emulation But does not appear to have an OpenPGP applet. This adds more urgency to address issues in: https://github.com/OpenSC/OpenSC/issues/962 On 1/12/2018 8:04 AM, Jakub Jelen wrote: > On Sat, 2018-01-06 at 12:11 +0100, NdK wrote: >> Il 05/01/2018 19:01, Bernd Eckenfels ha scritto: >>> Hello, >>> Did you try scdaemon (scenario 1 with SCd-PKCS11 should work with >>> Firefox) >>> https://github.com/sektioneins/scd-pkcs11/blob/master/README.md >> >> IIUC that's for GPG to use OpenSC-managed cards. >> >> Practical example. I have a MyEID cards where I load a couple of keys >> for web auth (say work portal and CAcert), a key for mail signing >> (X509), a key for SSH access and the 3 GPG keys (DEC, SIG, AUT, and >> possibly the master C key too). >> That's what I could do before problems started (I last tested quite >> some >> time ago, so it might a bit fuzzy). IIRC, if I had Firefox open I >> couldn't access any key from other apps (including Thunderbird). >> If I closed FF, then I could sign/decrypt mails in Thunderbird, but >> either with X509 or GPG (Enigmail). And to use SSH I had to close TB, >> too. > > Hello Diego, > I am not using web authentication using PKCS#11, but (for the sake of > correct outcomes here) I got to test it today and it works as expected > without any concurrent issues (until you let the GnuPG's scdaemon into > the round) with all the cards I have around, but mostly with PIV on > yubikey. > > I believe you should give it a try again. You might be pleasantly > surprised (unless the MyEID cards have some different issues than my > cards). > > The scdaemon could be replaced with a tool that does not require > exclusive access and talks PKCS#11, such as gnupg-pkcs11-scd [1] and > then we should be over these problems. > >> Guess what's the "normal user" reaction? "fsck smartcards". > > Yes, some of the configuration steps should be more explicit > (disconnect = leave), and we should support both applets on the smart > card (PIV, OpenPGP) on yubikey [2] to make it working setup for general > users. But I would not say it is impossible nor that we are far. > > [1] http://gnupg-pkcs11.sourceforge.net/index.html > [2] https://github.com/OpenSC/OpenSC/issues/962 > > Thanks for inputs and regards, > -- Douglas E. Engert <DEE...@gm...> |
|
From: Jakub J. <jj...@re...> - 2018-01-12 14:05:09
|
On Sat, 2018-01-06 at 12:11 +0100, NdK wrote: > Il 05/01/2018 19:01, Bernd Eckenfels ha scritto: > > Hello, > > Did you try scdaemon (scenario 1 with SCd-PKCS11 should work with > > Firefox) > > https://github.com/sektioneins/scd-pkcs11/blob/master/README.md > > IIUC that's for GPG to use OpenSC-managed cards. > > Practical example. I have a MyEID cards where I load a couple of keys > for web auth (say work portal and CAcert), a key for mail signing > (X509), a key for SSH access and the 3 GPG keys (DEC, SIG, AUT, and > possibly the master C key too). > That's what I could do before problems started (I last tested quite > some > time ago, so it might a bit fuzzy). IIRC, if I had Firefox open I > couldn't access any key from other apps (including Thunderbird). > If I closed FF, then I could sign/decrypt mails in Thunderbird, but > either with X509 or GPG (Enigmail). And to use SSH I had to close TB, > too. Hello Diego, I am not using web authentication using PKCS#11, but (for the sake of correct outcomes here) I got to test it today and it works as expected without any concurrent issues (until you let the GnuPG's scdaemon into the round) with all the cards I have around, but mostly with PIV on yubikey. I believe you should give it a try again. You might be pleasantly surprised (unless the MyEID cards have some different issues than my cards). The scdaemon could be replaced with a tool that does not require exclusive access and talks PKCS#11, such as gnupg-pkcs11-scd [1] and then we should be over these problems. > Guess what's the "normal user" reaction? "fsck smartcards". Yes, some of the configuration steps should be more explicit (disconnect = leave), and we should support both applets on the smart card (PIV, OpenPGP) on yubikey [2] to make it working setup for general users. But I would not say it is impossible nor that we are far. [1] http://gnupg-pkcs11.sourceforge.net/index.html [2] https://github.com/OpenSC/OpenSC/issues/962 Thanks for inputs and regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. |
|
From: NdK <ndk...@gm...> - 2018-01-09 17:23:01
|
Il 09/01/2018 17:53, Anders Rundgren ha scritto: > Maybe "AI" will require a minor PKCS #11 update.... Not necessarily, if PKCS#11 allows for interactive key agreement (multi-step DH)... Tree Parity Machines (the simplest form of neural network) can exploit the speed difference between simple learning and mutual learning to converge to a common state faster than an attacker. The security margin derives from information theory and does not require assumptions like "this problem is difficult": the upper bound of what the attacker can know is mathematically determined (too bad it's relatively high). Actually TPMs' mutual learning is more practical than some PQC algorithms :) BYtE, Diego |
|
From: Anders R. <and...@gm...> - 2018-01-09 16:53:56
|
On 2018-01-09 17:48, NdK wrote: > Il 09/01/2018 16:00, J.W...@mi... ha scritto: > >>> With anything virtualised, how can you guarantee its uniqueness? >> It could be cloned by your evil chambermaid. > Not (easily, or by a simple chambermaid) if it's inside a secure > coprocessor. Remember the TPM? > At the end: a smartcard in a different form factor and with a trendier > name (just waiting someone proposing a name with "blockchain" in it... > ROFLASTC!). Yes! Smart cards supporting a combination of "blockchain" and "AI" is what we all are waiting on :-) Maybe "AI" will require a minor PKCS #11 update.... Anders > > BYtE, > Diego > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: NdK <ndk...@gm...> - 2018-01-09 16:48:29
|
Il 09/01/2018 16:00, J.W...@mi... ha scritto: >> With anything virtualised, how can you guarantee its uniqueness? > It could be cloned by your evil chambermaid. Not (easily, or by a simple chambermaid) if it's inside a secure coprocessor. Remember the TPM? At the end: a smartcard in a different form factor and with a trendier name (just waiting someone proposing a name with "blockchain" in it... ROFLASTC!). BYtE, Diego |
|
From: NdK <ndk...@gm...> - 2018-01-09 16:35:50
|
Il 09/01/2018 14:18, J.W...@mi... ha scritto: > That sounds like two programs trying to get an exclusive lock on some of the EF's on the card. > AFAICR, that was already addressed at FOSDEM 3 or 4 years ago... > Still, encrypting/decrypting remains a sequential process, and no userland should try to get a long-lasting exclusive lock Pls, explain that to Mozilla team... Possibly w/ the "friendly certs" 9yo issue... I kept using FF mainly for "tab groups" feature... Lacking it *and* w/ an uncooperative token management, I'll be free to move to other browsers. :) BYtE, Diego |
|
From: <J.W...@mi...> - 2018-01-09 15:30:43
|
Eh... Virtualised biometrics ??? And with PIN: you can clone them 10000 fold, and do a parallel brute force attack. So, no. This sounds just good enough for your cookie jar. Not if the life's of your loved ones might depend on it. -----Original Message----- From: Anders Rundgren [mailto:and...@gm...] Sent: dinsdag 9 januari 2018 16:23 To: Witvliet, J, Ing., DMO/OPS/I&S/APH; ope...@li... Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 On 2018-01-09 16:00, J.W...@mi... wrote: > With anything virtualised, how can you guarantee its uniqueness? > It could be cloned by your evil chambermaid. Even if the device (or key) is protected by a PIN and/or biometrics? Anders > > -----Original Message----- > From: Anders Rundgren [mailto:and...@gm...] > Sent: dinsdag 9 januari 2018 15:21 > To: Witvliet, J, Ing., DMO/OPS/I&S/APH; > ope...@li... > Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 > > On 2018-01-09 14:01, J.W...@mi... wrote: >> I dare to disagree strongly. >> Perhaps (...) until the time we have BIO-interface like in "The Matrix" > > My guess is that in 5-10 years most SIMs will be virtualized. ARM and Intel already have this working. > > This will accelerate the downward spiral for other smart card applications as well. > > The e-passport project is a failure, other solutions are taking over. > > Anders > >> >> -----Original Message----- >> From: Anders Rundgren [mailto:and...@gm...] >> Sent: zondag 7 januari 2018 15:23 >> To: ope...@li... >> Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 >> >> Smart cards represent "a blast from the past". >> Embedded security (assuming Intel & Co succeeds tightening the current ugly issues..) is the future. >> >> >> --------------------------------------------------------------------- >> - >> -------- Check out the vibrant tech community on one of the world's >> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> >> >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. >> >> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. >> > > > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. > > This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. |
|
From: Anders R. <and...@gm...> - 2018-01-09 15:22:56
|
On 2018-01-09 16:00, J.W...@mi... wrote: > With anything virtualised, how can you guarantee its uniqueness? > It could be cloned by your evil chambermaid. Even if the device (or key) is protected by a PIN and/or biometrics? Anders > > -----Original Message----- > From: Anders Rundgren [mailto:and...@gm...] > Sent: dinsdag 9 januari 2018 15:21 > To: Witvliet, J, Ing., DMO/OPS/I&S/APH; ope...@li... > Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 > > On 2018-01-09 14:01, J.W...@mi... wrote: >> I dare to disagree strongly. >> Perhaps (...) until the time we have BIO-interface like in "The Matrix" > > My guess is that in 5-10 years most SIMs will be virtualized. ARM and Intel already have this working. > > This will accelerate the downward spiral for other smart card applications as well. > > The e-passport project is a failure, other solutions are taking over. > > Anders > >> >> -----Original Message----- >> From: Anders Rundgren [mailto:and...@gm...] >> Sent: zondag 7 januari 2018 15:23 >> To: ope...@li... >> Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 >> >> Smart cards represent "a blast from the past". >> Embedded security (assuming Intel & Co succeeds tightening the current ugly issues..) is the future. >> >> >> ---------------------------------------------------------------------- >> -------- Check out the vibrant tech community on one of the world's >> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> >> >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. >> >> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. >> > > > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. > > This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. > |
|
From: <J.W...@mi...> - 2018-01-09 15:00:42
|
With anything virtualised, how can you guarantee its uniqueness? It could be cloned by your evil chambermaid. -----Original Message----- From: Anders Rundgren [mailto:and...@gm...] Sent: dinsdag 9 januari 2018 15:21 To: Witvliet, J, Ing., DMO/OPS/I&S/APH; ope...@li... Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 On 2018-01-09 14:01, J.W...@mi... wrote: > I dare to disagree strongly. > Perhaps (...) until the time we have BIO-interface like in "The Matrix" My guess is that in 5-10 years most SIMs will be virtualized. ARM and Intel already have this working. This will accelerate the downward spiral for other smart card applications as well. The e-passport project is a failure, other solutions are taking over. Anders > > -----Original Message----- > From: Anders Rundgren [mailto:and...@gm...] > Sent: zondag 7 januari 2018 15:23 > To: ope...@li... > Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 > > Smart cards represent "a blast from the past". > Embedded security (assuming Intel & Co succeeds tightening the current ugly issues..) is the future. > > > ---------------------------------------------------------------------- > -------- Check out the vibrant tech community on one of the world's > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. > > This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. |
|
From: Anders R. <and...@gm...> - 2018-01-09 14:21:34
|
On 2018-01-09 14:01, J.W...@mi... wrote: > I dare to disagree strongly. > Perhaps (...) until the time we have BIO-interface like in "The Matrix" My guess is that in 5-10 years most SIMs will be virtualized. ARM and Intel already have this working. This will accelerate the downward spiral for other smart card applications as well. The e-passport project is a failure, other solutions are taking over. Anders > > -----Original Message----- > From: Anders Rundgren [mailto:and...@gm...] > Sent: zondag 7 januari 2018 15:23 > To: ope...@li... > Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 > > Smart cards represent "a blast from the past". > Embedded security (assuming Intel & Co succeeds tightening the current ugly issues..) is the future. > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. > > This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. > |
|
From: <J.W...@mi...> - 2018-01-09 13:18:42
|
That sounds like two programs trying to get an exclusive lock on some of the EF's on the card. AFAICR, that was already addressed at FOSDEM 3 or 4 years ago... Still, encrypting/decrypting remains a sequential process, and no userland should try to get a long-lasting exclusive lock Hans -----Original Message----- From: NdK [mailto:ndk...@gm...] Sent: zondag 7 januari 2018 11:54 To: Witvliet, J, Ing., DMO/OPS/I&S/APH Cc: ope...@li... Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 Il 07/01/2018 00:17, J.W...@mi... ha scritto: > You know there is a patch for OpenSSH, so it can use ssl keys/certificates.... > Afaicr this feature is for years in the commercial branch of ssh. Uh? I've been able to use a simple PKCS11Provider config option to specify the lib to use and access keys on card. But the point is that if Firefox is accessing the same card, ssh fails. BYtE, Diego Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. |
|
From: <J.W...@mi...> - 2018-01-09 13:01:14
|
I dare to disagree strongly. Perhaps (...) until the time we have BIO-interface like in "The Matrix" -----Original Message----- From: Anders Rundgren [mailto:and...@gm...] Sent: zondag 7 januari 2018 15:23 To: ope...@li... Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 Smart cards represent "a blast from the past". Embedded security (assuming Intel & Co succeeds tightening the current ugly issues..) is the future. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Opensc-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opensc-devel Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. |
|
From: <J.W...@mi...> - 2018-01-09 12:45:50
|
Belgium is right now. And The Netherlands (for private citizens) in 15 Years :-( Right now, some of the Dutch Ministries ARE using ID-cards. MoD relies heavily on it -----Original Message----- Essentially only Estonia continues with eID cards. Anders ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Opensc-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opensc-devel Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. |
|
From: Jakub J. <jj...@re...> - 2018-01-09 09:31:56
|
On Sat, 2018-01-06 at 12:11 +0100, NdK wrote: > Il 05/01/2018 19:01, Bernd Eckenfels ha scritto: > > Hello, > > Did you try scdaemon (scenario 1 with SCd-PKCS11 should work with > > Firefox) > > https://github.com/sektioneins/scd-pkcs11/blob/master/README.md > > IIUC that's for GPG to use OpenSC-managed cards. > > Practical example. I have a MyEID cards where I load a couple of keys > for web auth (say work portal and CAcert), a key for mail signing > (X509), a key for SSH access and the 3 GPG keys (DEC, SIG, AUT, and > possibly the master C key too). > That's what I could do before problems started (I last tested quite > some > time ago, so it might a bit fuzzy). IIRC, if I had Firefox open I > couldn't access any key from other apps (including Thunderbird). > If I closed FF, then I could sign/decrypt mails in Thunderbird, but > either with X509 or GPG (Enigmail). And to use SSH I had to close TB, > too. > > Guess what's the "normal user" reaction? "fsck smartcards". > > Then an unrelated problem (that probably can't be fixed w/o changing > a > lot of things): CSSH. CSSH opens ssh sessions to a "cluster" of > machines > (I used it with 42 parallel sessions) and allows to send the same > commands to all the sessions. But if the ssh key is on card (and > noone > else is using it), it's simply too slow to handle such a batch of > requests and logins timeout. If I am right, this should be possible to handle with ssh-agent, if the initialization and keys listing overhead is too large. By loading the card into ssh-agent, the authentication then should be only the signature and therefore significantly faster. The "caching" from library point of view might be problematic, because you need to detect if it is still the same card or different with quite a confidence. For example OpenCryptoki is using client-server model, where pkcsslotd daemon can monitor and cache whatever is going on with the slot and card, such as watching remove and insert events and if there is none, just serve what was cached much faster. It probably has its disadvantages though. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. |
|
From: Jakub J. <jj...@re...> - 2018-01-09 08:41:57
|
On Mon, 2018-01-08 at 18:29 +0100, NdK wrote: > Il 08/01/2018 08:10, Frank Morgner ha scritto: > > > If OpenSC is not responsive enough, have you tried enabling file > > caching? > > Uh? The bottleneck is the access to the token... But I didn't know > file > caching and I'll have to have a look. > > > Did you disable the card drivers that you don't need? > > No, I usually have to use OS supplied packages (for long term > maintenance). Surely, on a test machine I can experiment with git > releases, but for deployment I have to wait for the changes to arrive > in > the distro. The driver selection is in configuration file so there is no need to recompile. Just find out what driver is your card using, for example with "opensc-tool -n" and then add it to the /etc/opensc.conf, such as "card_drivers = PIV-II, internal;" (leaving internal in the end allows the detection of other types, but your -- in this case PIV-II will be the first one to detect). Regards, Jakub |
|
From: NdK <ndk...@gm...> - 2018-01-08 17:29:58
|
Il 08/01/2018 08:10, Frank Morgner ha scritto: > If OpenSC is not responsive enough, have you tried enabling file > caching? Uh? The bottleneck is the access to the token... But I didn't know file caching and I'll have to have a look. > Did you disable the card drivers that you don't need? No, I usually have to use OS supplied packages (for long term maintenance). Surely, on a test machine I can experiment with git releases, but for deployment I have to wait for the changes to arrive in the distro. > Instead of using 42 ssh sessions to the same machine, Never said these sessions are to the same machine. It would be useless. It's ~half of a 81 PCs lab. cssh is used to send the same command to all the sessions. Before using cssh, it took 3 days to deploy all the updates on all the machines. With cssh it only takes ~2h. > Complaining doesn't help much for making the situation better, Yup. I stopped complaining-without-trying-to-debug about 30 years ago :) Mine was not intended as a complaint, just as a reminder of a series of "problems" users have to face. > so here are some short hints: Tks. I'll keep 'em handy. > * Using smart cards in a managed environment work quite good (even > with PKCS#11)! Your company just needs a good IT department that > configures everything that's needed. I am one of the most experienced Linux users in our IT team (that's the main reason I can't easily deploy anything compiled from sources: other techs wouldn't be able to maintain it). BYtE, Diego |
|
From: Douglas E E. <dee...@gm...> - 2018-01-08 15:43:50
|
On 1/8/2018 3:19 AM, Anders Rundgren wrote: > I know that RedHat have designed their crypto platform around PKCS #11. > No other vendors have. Oracle Solaris did. > https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/chapter1-1/index.html Solaris did. I did much of my early smart card development on Solaris workstations until Oracle dropped Solaris workstations. Never followed up on how much of the "Third-party Hardware and Software pluggable tokens" in Userland" were also implemented in the "Third-party Hardware crypto providers" in "Kernel" -- Douglas E. Engert <DEE...@gm...> |
|
From: Florent <fde...@gm...> - 2018-01-08 09:24:55
|
> IIRC, both FF and TB use exclusive locking. > Moreover (at least FF) asks for *all* the PINs (they say that's for > enabling discovery of "hidden" certs... can only be bypassed from > command line using "friendly certs" option). > Does this command line really exists? I don't find anything related in https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options |
|
From: Anders R. <and...@gm...> - 2018-01-08 09:19:21
|
On 2018-01-08 10:12, Jakub Jelen wrote: >> History is becoming a weight that prevents further evolution. Many >> limitations are rooted in assumptions that are no longer true. >> We'd need PKCS11-2018, a complete revision of the standard that >> ditches >> a lot of dead weight. > > PKCS#11 is not dead. There is going to be PKCS#11 3.0 [1], which I try > to follow, but I don't think, there is going to be any significant > change in the way of handling multiple processes. Or what dead weight > you mean in this case? I know that RedHat have designed their crypto platform around PKCS #11. No other vendors have. PKCS #11 for smart cards isn't going anywhere, neither does PC/SC. Intel and ARM are all into embedded security. Essentially only Estonia continues with eID cards. Anders |
|
From: Jakub J. <jj...@re...> - 2018-01-08 09:15:13
|
On Sat, 2018-01-06 at 17:57 +0000, Ian Hill wrote: > Hi > > I have the following card which I have managed to find with libccid, > however, it is not supported by OpenSC. > > $ opensc-tool --atr > Using reader with a card: FT U2F CCID [CCID] 00 00 > 3b:f9:13:00:00:81:31:fe:45:4a:43:4f:50:32:34:32:52:33:a2 > > > Is there a driver in the works, or can I help with any information? Did you try with the latest master? There were some changes related to the epass2003 driver (Feitian) that might be related. If it will not help, the vendor should be able to help you. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. |
|
From: Jakub J. <jj...@re...> - 2018-01-08 09:12:36
|
On Mon, 2018-01-08 at 00:31 +0100, NdK wrote:
> Il 07/01/2018 15:14, Douglas E Engert ha scritto:
>
> > Note that much of the middleware including pkcs11 runs in the user
> > applications not in the OS.
>
> IMO that's one of the problems. Connect the daemon to the user's
> processes ("session" is limiting...).
>
> > Some call this a security requirement.
>
> I call it lazyness. Many programs use long-term locking only because
> it's simpler to handle. You don't risk that objects change without
> you
> knowing.
>
> History is becoming a weight that prevents further evolution. Many
> limitations are rooted in assumptions that are no longer true.
> We'd need PKCS11-2018, a complete revision of the standard that
> ditches
> a lot of dead weight.
PKCS#11 is not dead. There is going to be PKCS#11 3.0 [1], which I try
to follow, but I don't think, there is going to be any significant
change in the way of handling multiple processes. Or what dead weight
you mean in this case?
>
> > Others would call this a bug.
>
> Ill-planned feature, since there usually are many processes.
>
> > There are some things you can do. For some cards, OpenSC can cache
> > certificates
> > and other data in in the user's home directory. OpenSC can try and
> > leave
> > the card
> > in a logged instate if you set the disconnect = leave see the
> > comments
> > in opensc.conf.
> > But other applications not using OpenSC can still lock the access
> > to the
> > card at the PCSC level.
>
> All the SC-aware programs I tried in Linux required OpenSC :)
GnuPG's scdaemon is example that was already mentioned several times,
that is widely used and that does not go through the OpenSC, which
makes it common problem.
Anyway, thank you Diego for your valuable comments and ideas. I will
certainly have a look into them and try to address them in my talk or
in OpenSC project, if it would be possible.
[1] https://wiki.oasis-open.org/pkcs11/3.0WorkItems
Thanks,
--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
|
|
From: Jakub J. <jj...@re...> - 2018-01-08 08:51:34
|
On Mon, 2018-01-08 at 08:10 +0100, Frank Morgner wrote: > If OpenSC is not responsive enough, have you tried enabling file > caching? > Did you disable the card drivers that you don't need? Instead of > using 42 > ssh sessions to the same machine, have you tried using a single > session > running tmux or GNU screen on the other end of the connection? In > OpenSC we > try to support multi applications as best as we can. It should at > least be > possible to use the same OpenSC library in different applications > without > much of a problem. If not, well, report, debug and fix the problem! > If you > don't do it, the situation will stay as it is. > > For example, for more that a year now, I've been using the Minidriver > wrapper of OpenSC in large scale now with at least a dozen of > "client" > applications. Yes, there were concurrency issues; yes there were > performance issues; yes there were things like memory corruptions; > yes > there were configuration problems. However, looking into this, I not > only > got a better understanding how OpenSC is working internally, I also > understood how Windows (CNG) is working. OpenSC now even outperforms > the > proprietary middleware solution that I've been using before. > > Complaining doesn't help much for making the situation better, so > here are > some short hints: > > Performance: > > - use `use_file_caching = true`. (check if your card driver > actually > supports file caching!) > - some drivers support internal file (path) caching that's always > enabled. That, however, is very complex and error prone ( > https://github.com/OpenSC/OpenSC/issues/1159)... I'd recommend to > use > file caching on disk instead > - disable card drivers you don't need > - analyze the card driver and remove unused card transactions > > > Concurrency: > > - by default, OpenSC uses fine grained locking only for the smart > card > transactions (i.e. SCardBeginTransaction) without the need for a > global > lock (read: using Firefox and Thunderbird at the same time should > not lead > to errors) > - (the hard part) running multiple processes with the same library > needs > to be tested. The problems may be specific to the actual smart > card driver, > so there is no way around actually doing the testing. > > > End user adoption: > > - PKCS#11 has been designed as API for applications. It was not > designed > to be used by end users. That's the reason U2F support is directly > built > into the applications, which allows a much better user > interaction. > - On Windows and even macOS the situation is much better, because > both, > a smart card driver and a smart card application only have a > single "entry > point". The OS offers APIs that transparently handle the token and > it > offers a unified infrastructure for installing token drivers. > (Maybe this > is the root of GPG's (scdaemon) attitude on requiring an > execlusive lock on > the card. It wants to be the only smart card framework for the > whole > system. Unfortunately this doesn't go well with the bazaar that > Linux is.) > - Using smart cards in a managed environment work quite good (even > with > PKCS#11)! Your company just needs a good IT department that > configures > everything that's needed. > > Coming back to the original topic of this message: Thanks Jakub for > taking > this opportunity! Something new I'd like to hear in a talk would be > some > ideas on how to overcome the lack of documentation, how to achieve > good > testing (especially with smart cards!) and how you see things like > WebUSB > (e.g. think of a Web App that contains everything including reader > driver, > smart card driver and smart card application). > > Though, I think I cannot be present at FOSDEM, I hope you can publish > the > slides (e.g. in the OpenSC wiki)! Thank you for the write up, ideas and comments. I will certainly try to address some the topics discussed here, since I understand that these are very important points for people considering to use smart cards of any form. For anyone who would like to see the talk, it should be streamed/recorded. But I will certainly share the results here. Thanks, Jakub |
|
From: Frank M. <fra...@gm...> - 2018-01-08 07:17:12
|
According to the docs there aren't any PKI applications (e.g. GIDS) on your token by default (https://www.ftsafe.com/products/FIDO/Single_Button_FIDO). You need to contact the vendor instead of this list. 2018-01-07 23:19 GMT+01:00 Ian Hill <we...@us...>: > Thanks, I know that, however with this usb key you can also enable smart > card mode (CCID) as well using the Feitian application, which I have done. > Similar to the Yubikey 4 and Neo. > > The output file I attached previously shows that the usb is a valid CCID > smart card and Ludovic of libccid has this usb on his 'should work's list. > The only issue seems to be that there is not a Opensc driver, perhaps based > on an update to the Feitian ePass2003 usb smart card. > > Note this is totally separate to U2F mode, which I can actually disable if > required. > > On Sun, 7 Jan 2018, 10:11 pm Bernd Eckenfels, <ec...@zu...> > wrote: > >> You cannot store certificates or keys on a U2F only device, it only >> supports the U2F features for key derivation. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ------------------------------ >> *From:* Ian Hill <we...@us...> >> *Sent:* Sunday, January 7, 2018 10:27:39 PM >> *To:* Frank Morgner >> *Cc:* Bernd Eckenfels; ope...@li... >> *Subject:* Re: [Opensc-devel] Feitian U2F NFC + CCID (FT U2F CCID) >> >> >> Thanks, this usb supports both U2F and CCID, the U2F works as expected, >> however, having enabled the CCID mode although it is recognised as a CCID >> card under libccid there is no suitable driver in Opensc. >> >> If anyone can help with the driver I can test it this end. >> >> On Sun, 7 Jan 2018, 1:58 pm Frank Morgner, <fra...@gm...> >> wrote: >> >>> U2F is yet an other token standard. So, by design, it is not to be used >>> with the APIs that OpenSC is offering. However, that should not be a >>> problem, because U2F capable applications should have native support for >>> your token without the need of OpenSC. >>> >>> >>> In theory we could add low level support for U2F and even some PKCS#11 >>> wrapping for U2F into OpenSC. But currently there are no applications that >>> have use for this. >>> >>> 2018-01-06 22:20 GMT+01:00 Ian Hill <we...@us...>: >>> >>>> Yep, it's the U2F version and that works fine, however, I would like to >>>> add gpg keys to it and have enabled U2F & CCID mode. >>>> >>>> It is now recognised by libccid using the latest stable version but not >>>> recognised by Opensc. >>>> >>>> I assume if I can get Opensc working I should be able to add either gpg >>>> or RSA keys to the smart card. >>>> >>>> On Sat, 6 Jan 2018, 7:57 pm Bernd Eckenfels, <ec...@zu...> >>>> wrote: >>>> >>>>> Sounds like Fido Universal Two Factor. Chrome should be able to use >>>>> that as a login token. (There is for example a Yubikey U2F Token which >>>>> works great with Chrome) >>>>> >>>>> Gruss >>>>> Bernd >>>>> -- >>>>> http://bernd.eckenfels.net >>>>> ------------------------------ >>>>> *From:* Ian Hill <we...@us...> >>>>> *Sent:* Saturday, January 6, 2018 6:57:03 PM >>>>> *To:* ope...@li... >>>>> *Subject:* [Opensc-devel] Feitian U2F NFC + CCID (FT U2F CCID) >>>>> >>>>> Hi >>>>> >>>>> I have the following card which I have managed to find with libccid, >>>>> however, it is not supported by OpenSC. >>>>> >>>>> $ opensc-tool --atr >>>>> Using reader with a card: FT U2F CCID [CCID] 00 00 >>>>> 3b:f9:13:00:00:81:31:fe:45:4a:43:4f:50:32:34:32:52:33:a2 >>>>> >>>>> >>>>> Is there a driver in the works, or can I help with any information? >>>>> >>>>> >>>>> Ian >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------ >>>> ------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Opensc-devel mailing list >>>> Ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >>>> >>>> >>> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______ >> _________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > |
|
From: Frank M. <fra...@gm...> - 2018-01-08 07:10:26
|
If OpenSC is not responsive enough, have you tried enabling file caching? Did you disable the card drivers that you don't need? Instead of using 42 ssh sessions to the same machine, have you tried using a single session running tmux or GNU screen on the other end of the connection? In OpenSC we try to support multi applications as best as we can. It should at least be possible to use the same OpenSC library in different applications without much of a problem. If not, well, report, debug and fix the problem! If you don't do it, the situation will stay as it is. For example, for more that a year now, I've been using the Minidriver wrapper of OpenSC in large scale now with at least a dozen of "client" applications. Yes, there were concurrency issues; yes there were performance issues; yes there were things like memory corruptions; yes there were configuration problems. However, looking into this, I not only got a better understanding how OpenSC is working internally, I also understood how Windows (CNG) is working. OpenSC now even outperforms the proprietary middleware solution that I've been using before. Complaining doesn't help much for making the situation better, so here are some short hints: Performance: - use `use_file_caching = true`. (check if your card driver actually supports file caching!) - some drivers support internal file (path) caching that's always enabled. That, however, is very complex and error prone ( https://github.com/OpenSC/OpenSC/issues/1159)... I'd recommend to use file caching on disk instead - disable card drivers you don't need - analyze the card driver and remove unused card transactions Concurrency: - by default, OpenSC uses fine grained locking only for the smart card transactions (i.e. SCardBeginTransaction) without the need for a global lock (read: using Firefox and Thunderbird at the same time should not lead to errors) - (the hard part) running multiple processes with the same library needs to be tested. The problems may be specific to the actual smart card driver, so there is no way around actually doing the testing. End user adoption: - PKCS#11 has been designed as API for applications. It was not designed to be used by end users. That's the reason U2F support is directly built into the applications, which allows a much better user interaction. - On Windows and even macOS the situation is much better, because both, a smart card driver and a smart card application only have a single "entry point". The OS offers APIs that transparently handle the token and it offers a unified infrastructure for installing token drivers. (Maybe this is the root of GPG's (scdaemon) attitude on requiring an execlusive lock on the card. It wants to be the only smart card framework for the whole system. Unfortunately this doesn't go well with the bazaar that Linux is.) - Using smart cards in a managed environment work quite good (even with PKCS#11)! Your company just needs a good IT department that configures everything that's needed. Coming back to the original topic of this message: Thanks Jakub for taking this opportunity! Something new I'd like to hear in a talk would be some ideas on how to overcome the lack of documentation, how to achieve good testing (especially with smart cards!) and how you see things like WebUSB (e.g. think of a Web App that contains everything including reader driver, smart card driver and smart card application). Though, I think I cannot be present at FOSDEM, I hope you can publish the slides (e.g. in the OpenSC wiki)! Regards, Frank. 2018-01-06 12:11 GMT+01:00 NdK <ndk...@gm...>: > Il 05/01/2018 19:01, Bernd Eckenfels ha scritto: > > Hello, > > Did you try scdaemon (scenario 1 with SCd-PKCS11 should work with > Firefox) > > https://github.com/sektioneins/scd-pkcs11/blob/master/README.md > IIUC that's for GPG to use OpenSC-managed cards. > > Practical example. I have a MyEID cards where I load a couple of keys > for web auth (say work portal and CAcert), a key for mail signing > (X509), a key for SSH access and the 3 GPG keys (DEC, SIG, AUT, and > possibly the master C key too). > That's what I could do before problems started (I last tested quite some > time ago, so it might a bit fuzzy). IIRC, if I had Firefox open I > couldn't access any key from other apps (including Thunderbird). > If I closed FF, then I could sign/decrypt mails in Thunderbird, but > either with X509 or GPG (Enigmail). And to use SSH I had to close TB, too. > > Guess what's the "normal user" reaction? "fsck smartcards". > > Then an unrelated problem (that probably can't be fixed w/o changing a > lot of things): CSSH. CSSH opens ssh sessions to a "cluster" of machines > (I used it with 42 parallel sessions) and allows to send the same > commands to all the sessions. But if the ssh key is on card (and noone > else is using it), it's simply too slow to handle such a batch of > requests and logins timeout. > > IMVHO PKCS#11 greatly suffered "design by committee", making it hard to > use it correctly in a multi-app scenario. Smartcards made it even worse, > being able to host multiple applets but with only one active at a time: > the very concept "only one program can access the card at any time". > That actually "forces" developers to ask for exclusive access and the > loop closes. > > That's why I have some cards lying around (MyEID, Epass2003, GnuK, a > couple of JCOP card models for programming experiments) but don't use 'em. > > BYtE, > Diego > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: NdK <ndk...@gm...> - 2018-01-07 23:31:39
|
Il 07/01/2018 15:14, Douglas E Engert ha scritto:
> Note that much of the middleware including pkcs11 runs in the user
> applications not in the OS.
IMO that's one of the problems. Connect the daemon to the user's
processes ("session" is limiting...).
> Some call this a security requirement.
I call it lazyness. Many programs use long-term locking only because
it's simpler to handle. You don't risk that objects change without you
knowing.
History is becoming a weight that prevents further evolution. Many
limitations are rooted in assumptions that are no longer true.
We'd need PKCS11-2018, a complete revision of the standard that ditches
a lot of dead weight.
> Others would call this a bug.
Ill-planned feature, since there usually are many processes.
> There are some things you can do. For some cards, OpenSC can cache
> certificates
> and other data in in the user's home directory. OpenSC can try and leave
> the card
> in a logged instate if you set the disconnect = leave see the comments
> in opensc.conf.
> But other applications not using OpenSC can still lock the access to the
> card at the PCSC level.
All the SC-aware programs I tried in Linux required OpenSC :)
BYtE,
Diego
|
5 messages has been excluded from this view by a project administrator.
