Re: [Opensc-devel] OpenSC at FOSDEM 2018

[Frank M. <fra...@gm...>]

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
>