Re: [Opensc-devel] OpenSC at FOSDEM 2018

[NdK <ndk...@gm...>]

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