Menu
▾
▴
opensc-devel
|
From: Jakub J. <jj...@re...> - 2018-01-05 15:23:28
|
Hello there, this year I am going to FOSDEM and I will have a talk about Smart Cards, OpenSC and friends [1]. If you want to hear it, meet me in person or discuss something, let me know. [1] https://fosdem.org/2018/schedule/event/smartcards_in_linux/ See you in Brussels, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. |
|
From: NdK <ndk...@gm...> - 2018-01-05 16:59:02
|
Il 05/01/2018 16:23, Jakub Jelen ha scritto: > this year I am going to FOSDEM and I will have a talk about Smart > Cards, OpenSC and friends [1]. If you want to hear it, meet me in > person or discuss something, let me know. Will you highlight the problems smartcards create, too? I'd really like to have "all" my keys on smartcard: - website authentication - mail signing/decryption - ssh auth -... Too bad that if I'm using the smartcard from Firefox I can neither access it from SSH nor sign/decrypt a mail! Soo it's still "one card-one key" (mostly). That's, IMVHO, one of the factors that prevent wider adoption. BYtE, Diego |
|
From: Ludovic R. <lud...@gm...> - 2018-01-05 17:16:10
|
Hello, 2018-01-05 17:58 GMT+01:00 NdK <ndk...@gm...>: > Il 05/01/2018 16:23, Jakub Jelen ha scritto: > > > this year I am going to FOSDEM and I will have a talk about Smart > > Cards, OpenSC and friends [1]. If you want to hear it, meet me in > > person or discuss something, let me know. > Will you highlight the problems smartcards create, too? > > I'd really like to have "all" my keys on smartcard: > - website authentication > - mail signing/decryption > - ssh auth > -... > > Too bad that if I'm using the smartcard from Firefox I can neither > access it from SSH nor sign/decrypt a mail! > Soo it's still "one card-one key" (mostly). That's, IMVHO, one of the > factors that prevent wider adoption. > If your PKCS#11 library is correctly designed then you can use your smart card at the same time in all your applications. Your problem is not with the smart card itself. What PKCS#11 library are you using? Bye -- Dr. Ludovic Rousseau |
|
From: NdK <ndk...@gm...> - 2018-01-05 17:39:54
|
Il 05/01/2018 18:15, Ludovic Rousseau ha scritto: > If your PKCS#11 library is correctly designed then you can use your > smart card at the same time in all your applications. > Your problem is not with the smart card itself. > What PKCS#11 library are you using? Plain OpenSC in Linux. No extra drivers, if that's what you mean. Tested with Aventra MyEID cards. But Epass2003 does the same (and it does have other problems, too... "onepin"...). I know that Firefox is an uncooperative beast (still no easy way to enable "friendly" mode to avoid asking all the PINs after many years with an open ticket), but that's just part of the problem. Call it a symptom: every program works thinking it's the only one using the token. BYtE, Diego |
|
From: Douglas E E. <dee...@gm...> - 2018-01-05 18:17:20
|
I addition to Ludovic's comments... It also depends on the middleware that is trying to use the card. Some middleware like the Gnu OpenPGP wants exclusive access to the card thus locking out other user applications. With multiple applications on the same card, like Yubikey with PIV and OpenPGP applications only one application can be active (only one AID selected) at a time on the card. Switching between them can cause the login state to be dropped. Some middleware can not recover from some other middleware selecting an AID on the card and and are not smart enough to reselect their AID. Some cards are not smart enough to ignore an attempt to select an AID that is not on the card and loose the login state for the currently selected application. And lastly Some middleware may reset or power off the card while other middleware is still using it. When smart cards where first introduced, each card had an ATR and a single vendor application and vendor middleware. i.e. No interference between middleware cards each responded to only onle card with the single AID. Today its the application on the card that is important, and a card may have more then one application and an application may be available on many different cards. Thus the ATR can not be used to select the application in some cases. And there are multiple version of middleware to support the multiple applications. For example PIV is supported on more then a dozed approved cards and a few non-approved cards. OpenPGP is available on multiple cards. And Yubikey can have both a PIV and OpenPGP application on the same card. And did I mention Java middleware and non-PKCS#11 middleware? If you have control over all the middleware that might try and access a card,you might be able to get them to work together. For example if it is all opensc based in opensc.conf use disconnect = leave rather than reset. What card and what application/middleware are you using? Jakub, Sounds like a good talk as FOSDEM. Sorry I can not be there. These problems outlined above would be a good follow up talk of BOF. On 1/5/2018 10:58 AM, NdK wrote: > Il 05/01/2018 16:23, Jelen ha scritto: > >> this year I am going to FOSDEM and I will have a talk about Smart >> Cards, OpenSC and friends [1]. If you want to hear it, meet me in >> person or discuss something, let me know. > Will you highlight the problems smartcards create, too? > > I'd really like to have "all" my keys on smartcard: > - website authentication > - mail signing/decryption > - ssh auth > -... > > Too bad that if I'm using the smartcard from Firefox I can neither > access it from SSH nor sign/decrypt a mail! > Soo it's still "one card-one key" (mostly). That's, IMVHO, one of the > factors that prevent wider adoption. > > 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 > . > -- Douglas E. Engert <DEE...@gm...> |
|
From: Bernd E. <ec...@zu...> - 2018-01-05 18:25:41
|
Hello, Did you try scdaemon (scenario 1 with SCd-PKCS11 should work with Firefox) https://github.com/sektioneins/scd-pkcs11/blob/master/README.md Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: NdK <ndk...@gm...> Sent: Friday, January 5, 2018 5:58:52 PM To: ope...@li... Subject: Re: [Opensc-devel] OpenSC at FOSDEM 2018 Il 05/01/2018 16:23, Jakub Jelen ha scritto: > this year I am going to FOSDEM and I will have a talk about Smart > Cards, OpenSC and friends [1]. If you want to hear it, meet me in > person or discuss something, let me know. Will you highlight the problems smartcards create, too? I'd really like to have "all" my keys on smartcard: - website authentication - mail signing/decryption - ssh auth -... Too bad that if I'm using the smartcard from Firefox I can neither access it from SSH nor sign/decrypt a mail! Soo it's still "one card-one key" (mostly). That's, IMVHO, one of the factors that prevent wider adoption. 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-06 11:12:01
|
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 |
|
From: Ludovic R. <lud...@gm...> - 2018-01-06 16:20:58
|
Hello, 2018-01-06 12:11 GMT+01:00 NdK <ndk...@gm...>: > IMVHO PKCS#11 greatly suffered "design by committee", making it hard to > use it correctly in a multi-app scenario. A PKCS#11 application do not have to take care of other applications. The complexity to support multi applications is in the PKCS#11 library, not the application(s). 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. > Many programs can access the same smart card at the "same" time. But each of them should take care that they are not alone using the card. The easy solution is to get an exclusive access. That is not the only possible solution. I am not sure what is the (default) behaviour of OpenSC here. I do not want to start a flame war so I will stop here. Bye -- Dr. Ludovic Rousseau |
|
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: NdK <ndk...@gm...> - 2018-01-06 11:23:03
|
Il 05/01/2018 19:17, Douglas E Engert ha scritto: > What card and what application/middleware are you using? The most versatile card I have is the Aventra MyEID (that IIRC can store up to 15 keys and 15 PINs). That's single-applet, so there shouldn't be multi-applet-related problems. OpenSC as middleware (IIUC). FF, TB, SSH and GPG as "clients". BYtE, Diego |
|
From: Douglas E E. <dee...@gm...> - 2018-01-06 17:09:16
|
On 1/6/2018 5:22 AM, NdK wrote: > Il 05/01/2018 19:17, Douglas E Engert ha scritto: > >> What card and what application/middleware are you using? > The most versatile card I have is the Aventra MyEID (that IIRC can store > up to 15 keys and 15 PINs). That's single-applet, so there shouldn't be > multi-applet-related problems. > OpenSC as middleware (IIUC). FF, TB, SSH and GPG as "clients". I do not have a myEID but When you say clients: FF, TB, SSH they all use PKCS#11 and if you use the OpenSC PKCS#11 for each and set disconnect = leave should help these work together. (See note below.) But if by GPG "client" you mean Gnu scdaemon that may request exclusive access via PCSC and thus lockout other applications. Google for: scdaemon exclusive to see some discussions on this including: https://github.com/OpenSC/OpenSC/issues/953 Note: that PCSC standards do define access by user, but this does not appear to be implemented. Thus a smart card used on one system may be accessible via processes of different users. Thus disconnect = reset and exclusive provide some protection against this as each process must provide the PIN to access the card. So disconnect = leave should be used only on a single user systems. > > BYtE, > Diego > > -- Douglas E. Engert <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2018-01-06 16:43:32
|
On 1/6/2018 5:11 AM, 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. Yes that looks like it is trying to address some of these problem. But as it is trying to use some of the middleware that wants exclusive access to a token at PCSC level, (Gnu OpenPGP) it still has problems. > > 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. I do not have a myEID card, so it is not clear if using the multiple certs and key and using GPG keys is the same problem with myltiple applets on the card. > > Guess what's the "normal user" reaction? "fsck smartcards". I know. That is a problem. Most applets are developed by developers only interested in their applet. But users are more interested in using a single token that can be used from multiple applications. > > 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. Cards are slow, and designed to be cheap and fit in a wallet. Some tokens are much faster, and you may want to look at a faster device. The way the card is accessed, each ssh command may have to read a lot of data off the slow card, before doing any operation. If every application upon closing, resets the card, the next time the card is used will require more time to open. Consider trying opensc.conf disconnect = leave; rather than reset. Can make a big difference if all applications trying to use the card do the same thing. > > 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 is the way things developed. The PKCS* and ISO standards date from the late nineties for use with smart "cards" that were slow and relatively cheep. Loot at some hsm token if you want speed. > > 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 > -- Douglas E. Engert <DEE...@gm...> |
|
From: NdK <ndk...@gm...> - 2018-01-06 21:14:25
|
Il 06/01/2018 17:43, Douglas E Engert ha scritto: > Yes that looks like it is trying to address some of these problem. But > as it > is trying to use some of the middleware that wants exclusive access to a > token at PCSC level, (Gnu OpenPGP) it still has problems. Yup. I got it wrong at the first read. :-) What I couldn't understand is if it allows for more than the 3 keys OpenPGP uses... > I do not have a myEID card, so it is not clear if using the multiple > certs and key and using GPG keys is the same problem with myltiple applets > on the card. It does not have a separate applet for OpenPGP, so OpenPGP should see just a "keys container". >> Guess what's the "normal user" reaction? "fsck smartcards". > I know. That is a problem. Most applets are developed by developers only > interested in their applet. But users are more interested in using a single > token that can be used from multiple applications. Yup. IMVHO the card should be just a "keys container and access conditions enforcer": to perform crypto ops with a key you have to supply a certain PIN. The rest should not pertain to the card but only to the middleware. > Cards are slow, and designed to be cheap and fit in a wallet. Some tokens > are much faster, and you may want to look at a faster device. > The way the card is accessed, each ssh command may have to read a lot > of data off the slow card, before doing any operation. Why? In my ignorance I'd assume the "driver" caches the card data so it can be provided quickly to the clients. Then, if my 42 ssh sessions ask for a signature each and every "transaction" with the card takes 1 second, I'll have all the sessions open in ~42 seconds. That's acceptable. What's not acceptable is that every client have to read all the objects on-card, select the one it's interested in and do the crypto op. > That is the way things developed. The PKCS* and ISO standards date from > the late nineties for use with smart "cards" that were slow and relatively > cheep. Cards continue to be slow & "cheap"... Too bad both computers and users changed a lot in 20 years. Not to mention network pervasivity: 20 years ago it would have been unimmaginable to verify online every transaction (actually that's one of the reasons the "students card" project failed in my university: even the intranet was not sufficiently pervasive...). > Loot at some hsm token if you want speed. It's not only a matter of speed. It's a matter of convenience. 20 years ago a person carried 2-3 "cards". Now it's normal to have at least 7-8, plus fidelity cards. But noone is really interested in having the user use just one card for everything (identity document, driver's license, multiple credit cards, access card, etc). Every "entity" wants the user to have a card with entity's name on it. User's convenience is not on the priority list. I'll just throw an idea -- feel free to flame me. Why couldn't OpenSC (or another program) act as a "proxy", mediating access to card for the different clients, keeping a context for each (possibly emulating "secure channel", but SO_PEERCRED or SCM_CREDENTIALS could be enough: if the machine is compromised, it's game over anyway). This way it could cache the certs and the key IDs, keep separate contexts for different programs, avoid exclusive locks, etc. Uhm... actually it could even be a token between the PC and the card reader (a board that can act both as USB device and USB host on different ports at the same time)... BYtE, Diego |
|
From: <J.W...@mi...> - 2018-01-06 23:18:01
|
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. Sent from my iPhone > On 5 Jan 2018, at 17:59, NdK <ndk...@gm...> wrote: > > Il 05/01/2018 16:23, Jakub Jelen ha scritto: > >> this year I am going to FOSDEM and I will have a talk about Smart >> Cards, OpenSC and friends [1]. If you want to hear it, meet me in >> person or discuss something, let me know. > Will you highlight the problems smartcards create, too? > > I'd really like to have "all" my keys on smartcard: > - website authentication > - mail signing/decryption > - ssh auth > -... > > Too bad that if I'm using the smartcard from Firefox I can neither > access it from SSH nor sign/decrypt a mail! > Soo it's still "one card-one key" (mostly). That's, IMVHO, one of the > factors that prevent wider adoption. > > 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 > 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: NdK <ndk...@gm...> - 2018-01-07 10:53:53
|
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 |
|
From: Frank M. <fra...@gm...> - 2018-01-07 13:53:25
|
Have you debugged the problem? On 07.01.2018 11:53, NdK wrote: > 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 > > ------------------------------------------------------------------------------ > 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: Douglas E E. <dee...@gm...> - 2018-01-07 14:14:37
|
Sorry your are disappointed in the state of smart card these days. It is what it is for a number of historical reasons. o Multiple vendors providing cards middleware and applications to use only their cards. o Difference of opinions on how cards should be used. o Developers are concerned with their cards and not others. o Standards are overly complicated and most things are optional leading to no common standards. o OS vendors never really adopted smart cards. The market was way to small. o and the list goes on. Note that much of the middleware including pkcs11 runs in the user applications not in the OS. So caching is done by each application as long as it keeps pkcs11 active. So every ssh use if a key requires pkcs11 to be loaded the card connected, certificates be read etc. But long running applications can lock out access to a card from other applications. Some call this a security requirement. Others would call this a bug. 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. On 1/7/2018 4:53 AM, NdK wrote: > 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 > > ------------------------------------------------------------------------------ > 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 > -- Douglas E. Engert <DEE...@gm...> |
|
From: Anders R. <and...@gm...> - 2018-01-07 14:22:59
|
Smart cards represent "a blast from the past". Embedded security (assuming Intel & Co succeeds tightening the current ugly issues..) is the future. |
|
From: NdK <ndk...@gm...> - 2018-01-07 23:22:43
|
Il 07/01/2018 15:22, Anders Rundgren ha scritto: > Smart cards represent "a blast from the past". Should simply be rethought. > Embedded security (assuming Intel & Co succeeds tightening the current > ugly issues..) is the future. I don't think so. A smartcard (or a token) can physically be removed from the system, preventing its use. A chip on the mobo no. Neither can it be carried to another machine and "just work". BYtE, Diego. |
|
From: NdK <ndk...@gm...> - 2018-01-07 23:17:55
|
Il 07/01/2018 14:53, Frank Morgner ha scritto: > Have you debugged the problem? Quite some time ago. 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). BYtE, Diego |
|
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: 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
|
|
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: 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: 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.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X