Peaceful coexistence of GnuPG and other smart card software

[Martin Paljak]

On Thu, Aug 11, 2011 at 15:51, Werner Koch <wk at gnupg.org> wrote:
> On Thu, 11 Aug 2011 11:09, martin at martinpaljak.net said:
>> Well. scdaemon can assume that other applications talk to the same
>> application on the card and do not change *information* but only
>
> Assuming something is not a good operation mode for a security
> application.
Even though "assumption is the mother of all screw ups", the card is
mostly used to access cryptographic keys. Verifying the cryptographic
integrity if the response from the card is far better and meaningful
than tracking "card state".

>
> An easy way out of the exclusive access scheme would be a notification
> from pcscd when an application has changed the card's state so that
> scdaemon may flush its cache.

Define "changed the card's state" ? There's SCARD_W_RESET_CARD. I know
that this is probably not what you mean, but still.
Also, I don't know how GnuPG works on Windows, but I doubt it is easy
or even possible to change the way Windows PC/SC service works.

>> Readers often change dynamically, especially with laptops. The logical
>> solution would be location a suitable card from all present readers,
>> not changing scdaemon.conf on every invocation. To be honest, I'm
>
> Scdaemon uses a reader id made up from the USB vendorid, productid and the
> serialnumber.  For PC/SC access the PC/SC reader name is used.
> Configuration utilities may use:
>
>  $ gpg-connect-agent 'scd getinfo reader_list' /bye
>  D 04E6:5116:21120804208192:0%0A
>  OK
>
> (this command does not yet list PC/SC reader).

OK, that's why I got nothing. I'm using it through PC/SC of course,
for the previously outlined reasons. Numbering of the readers changes
if you re-plug readers to different connectors (or in different
order).
OpenSC also used to have "static numbering of connected readers" but
this has proven to be inefficient in current environments as (well,
mostly for PKCS#11 based applications, more established platforms
(Windows, OS X) have their own frameworks)

>> That's more like a chicken and egg problem. Rest of the world uses
>> PC/SC and manages to get things done. It is far from a perfect
>
> I have no problems with PC/SC; I merely suggest to loop PC/SC access
> through scdaemon ;-)

You mean using scdaemon+its CCID driver instead of libccid? Why? Any
practical reasons? I don't think it is very practical. I believe
Ludovic's CCID driver is currently the most complete and tested driver
(as it is used by *many* and various applications, readers, cards and
users).


>> If there was a greedy application stack to allocate a device, it
>> should be the most appropriate and standard piece of the system. IMHO
>> PC/SC is that.
>
> This is low-level and can't do the things a high-level application like
> scdaemon is able to do.  Did you ever try to use X.509 card with several
> applications - it takes ages do anything because card I/O is slow and
> X.509 requires you to read a lot of stuff.  Well, unless the application
> "assumes" a certain state of the card.  Ask some tester of the German
> Health Card prototypes about their experience with the speed of the
> applications (and that is mostly card I/O and not network bounded).

Accessing smart cards is a low level thing. Much like accessing USB
devices. Or PCI cards. Or other external hardware.
Yes, one of the things missing in Linux is a "central service" (a
daemon) that manages the "more meaningful" higher level access to
smart cards (Tokend on OS X/Minidriver in Windows) and it stems from
the lack of an agreed-upon framework in Linux. There would be
GSecurity vs QSecurity (or KSecurity). Like there would be a
hierarchical-security vs weboftrust-security standoff.
But a slow yet working multi-application experience beats a
fast-but-not-working experience any time.
There are tricks like caching the "heavy X509" things (certificates)
and resetting+transaction the card for every granular operation that
help to remedy the problem.

I think it would make sense that everybody agrees upon having a single
interface to talk to actual smart card devices. And build upon it.


The same way it would make sense to support PKCS#11 and let the user
decide what he/she wants to risk with - either using his keys with a
proprietary (or free!) PKCS#11 stack with GnuPG or being forced to the
ugly bad world of X509, PKCS#11 and greedy CA-s ;)

> Scdaemon might not be the best design around as it is now a decade old
> but it has advantages over other solutions.  The Free Software community
> should at least demand free card specs to allow the implementation of
> the card's host part using Free Software.

While I feel your concern for open specs (OpenSC has many open source
drivers with no public docs at the same time), but there's a
practicality vs purity balance somewhere.
Yet another place to re-implement the same thing (how to access a card
with cryptographic keys) does not help either.

I'll write a separate e-mail about my current problems of using
CryptoStick with GnuPG (GPGTools) on OS X together with OpenSC. This
can't be changed with some support (code changes) from GnuPG.


Cheers,
Martin