Peaceful coexistence of GnuPG and other smart card software

[Martin Paljak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

On 26/08/11 16:52, Werner Koch wrote:
> On Thu, 11 Aug 2011 15:53, martin at martinpaljak.net said: It is not
> about integrity but about user experience.  For example if we know
> that we did a verify we don't need to ask the user for the a PIN. 
> Sure we could also try to do it without a a verify and only ask for
> the PIN if the operation failed.  It turned out that the way we do
> it now is much more user friendly.

User friendly would be if me as a user could use the card with the
applications I chose, instead of being locked out totally for reasons
mentioning either "security" (common in OpenSC camp) or "usability"
(your argument).

In fact it sounds more like KDE vs GNOME and who is more "right" in
the way a desktop should be built. The most stupid thing is that users
suffer while developers build walled gardens.


>> Define "changed the card's state" ? There's SCARD_W_RESET_CARD. I
>> know
> 
> See above.

You asked for "notification from pcscd when an application has changed
the card's state". PC/SC defines SCARD_W_RESET_CARD, is this what you
mean with a "card state change" ? Or something in the SCARD_STATE_*
range? This is real and available, if this is OK, why don't you use
it? If not, what exactly should be signalled ?


> 
>> 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.
> 
> PC/SC under Windows does the same as pcsclite - no problem at all.

See above. I think what you have in mind is signalling on another
level than PC/SC is designed to operate. PC/SC can not (SHOULD NOT)
know which APDU-s change the logical card state, that is meaningful to
scdaemon. PC/SC in the incarnation it exists in pcsc-lite is quite low
level. If you were interested in extending an existing pcsclite API,
you could look at the rest of the SCa
The best way to rd* API from pcscworkgroup^Ħ^H^H^H^H^H^HMicrosoft,
which deals with more higher level "smart card mangling" with card
groups and files and whatnot. I don't have strong belief in the
non-low-level PC/SC calls either.

If the state chnages present in pcsclite are not enough, fixes in
Windows world is almost impossible without monkeypatching. Which makes
them not worth it.


>> 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)
> 
> We do this for years without any problems (at least for the few who
> use more than one reader); we merely did not implement the list
> feature.


Probably you then have quite static setups, even if you use multiple
readers. Right now what I have to do is plug out all "non-permanent"
readers, plug in the device and re-run gpg(2) to have success without
requiring an always changing command line option or configuration file
change.


> 
>>> 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
> 
> No, I mean using pc/sc - it is actually what GnuPG does on Windows
> and on Unix if it is not possible to use the internal driver.  As
> said before: the internal CCID driver was needed because we had
> CCID readers but no support for them in pcsclite.  I like to keep
> it because it removes an unnecessary library and daemon dependency
> and actually allow the use of readers which are not supported by
> libccid (old SCR335).
Sure, why not. In fact, the internal CCID driver might be useful on
resource-constrained (embedded) platforms running gpg only.

For the rest of scenarios, there should be enough reasons for allowing
multiple consumers to access a single hardware device (reader and/or
card) in a multi-application desktop environment. Through PC/SC, as
this is what the rest of the world uses (to my knowledge) to access
smart cards.

>> 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
> 
> I am not talking about a certain operating system kernel.  GnuPG is
> not related to Linux; I for example use it with *BSD all the time.
> You may view scdaemon/gpg-agent as this central service.

Disregard Linux and read it as "popular open source Unices".

What I mean is the absence of an API/library/daemon/component that
would be deployed and advocated and developed as "the alpha and omega
of cryptography for Unices" and that would actually take into account
meaningful hardware access, with the special case of smart cards and
readers (which is much more dynamic target than a dedicated HSM in
that matter)

Windows has CryptoAPI and applications written against it claim
"platform support for smart cards and other cryptographic hardware" by
default. OS X up to now used to have KeychainServices/CDSA/Tokend mess
(with the Tokend being the equivalent of scdaemon for smart cards)
which native OS X applications use(d) to get access to software
certificates, trust services and also compliant smart cards (heck,
there was even a Tokend bridge for PKCS#11 devices, which could be
used throgh the PKCS#11 module provided by OS X for Tokend devices..
very meta).

Linux^H^H^H^HUnices on the other hand have OpenSSL, NSS, ssh-agent,
gpg-agent, pcscd+ccid, PKCS#11, gnutls, OpenSC, ...

Fedora folks think that "NSS should be the central service for
everything crypto" and have the "crypto consolidation effort" [1].
Many revolt for obvious reasons, as it limits their options. Will it
come to Debian? I doubt it.

The problem of all those little libraries dealing with (software)
crypto in Unices or otherwise portable software is that it omits the
platform specific parts that deal with accessing hardware devices in
an pleaseant and user-friendly manner (the prominent user of PKCS#11,
Mozilla, has demonstrated that PKCS#11 directly is not a friendly
create. This is something p11-kit [2] should help to remedy)

Claiming any single vendor-defined interface with a single
implementation to be the de facto "central service" in an open
environment is not a smart move. Microsoft can do it and Apple can do
whatever they want, as application developers are forced to integrate
with their tools and platform if they want to succeed.

That's why OpenSSL (engine) fails, NSS as a forced library fails (even
though it can use PKCS#11 which should be a good sign), gpg-agent
fails and ssh-agent fails. And PKCS#11 wins IMHO.

("Opinions are like assholes. Everybody's got one and everyone thinks
everyone else's stinks." [3])

I really wish there was one that dealt with the basics: providing
access to *keys* and leaving the rest out. For this to succeed, Linux
folks need to agree on the lowest level, as everything else would be
like K vs G or PGP vs X509 debate. I don't want to be forced
G-everything or K-everything stack to get a meaningful experience, I'd
like to choose what I want to use.

>> 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
> 
> pkcs#11 does not make any sense at all.  It is a kludge to support
> the ugluy NSS based applications.

Sorry, I don't buy that. PKCS#11 makes *much* sense in *many*
applications having zero need for or knowledge of NSS.
Take OpenSSH - last time I checked could use PKCS#11 without requiring
NSS.

PKCS#11 is far from perfect, but it is the only cross-platform,
"stable" API which developers on Unices can use wihout falling for the
"K" vs "G" debate common in Linux. Which is much less productive than
embracing *something* as a common solution and building upon it.

The goal here is not to point fingers telling who is more ugly or more
wrong, but to get to a point where user has the power (enough to be a
poweruser without the risk of shooting himself in the leg with a
bazooka) to choose the application stack with the hardware at hand.


>> 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
> 
> Most of the core OpenSC code is (was?) about creating card
> applications and not about accessing cards.  The whole pkcs#15
> business in OpenSC is way to complicated for accessing pkcs#15
> cards; you don't need all the additional layers and the often
> unconsciously changed ABI.

OpenSC consists of two major parts at the core:
 - PKCS#15 structure creating for cards that can be personalized
("creating applications")
 - Decoding PKCS#15 structures and synthesising PKCS#15-ish structures
for cards that don't implement it (like OpenPGP or Estonian eID cards)
to provide access to on-card keys.

The ratio of different drivers, especially when taking into account
number of cards in use, is probably strongly for read-only cards.

The other big parts of OpenSC are platform specific API-s like Tokend
for OS X or a Minidriver for Windows, that enable to use the smart
cards supported by OpenSC in the most convenient manner on a given
platform.

About ABI: libopensc as a library has been deprecated for the reasons
of not having a well designed API with the right level of abstraction
and documentation in the first place and because there is a better
option available for 99% applications (that want to use OpenSC to
access on-card keys): PKCS#11. libopensc as an API for "standard for
smart card access" was anyway doomed to fail for the same reasons as
NSS/OpenSSL would fail.


> PKCS#15 was once established with the idea to make card access easy
> and uniform.  It does not work, but that's a different story.

Unfortunately I have to agree to some extent, but again - that is a
totally different story.


Coming back to the questions in my original e-mail, my intent is not
to just flame as hell but to fix the issue(s).

 * How could I help to debug the the problem, so that I could use gpg2
for decryption. Would a debug log with max verbose settings help?
 * If I was to "fix" (in my terms) the problems with scdaemon:
  - selecting a suitable reader automagically without configuration
file/command line changes
  - locking the reader only when it is in fact used (for
encryption/decryption)
 how should I continue? Should I fix gpg or gpg2? Or both? What is the
relation between gpg1 and gpg2 codebases?

Some general pointers would suffice, I've done some homework but
probably not enough to succeed at once.


Best,
Martin

[1] http://fedoraproject.org/wiki/FedoraCryptoConsolidation
[2] http://p11-glue.freedesktop.org/p11-kit.html
[3] http://www.imdb.com/title/tt0113321/quotes?qt=qt0492371
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOXNHCAAoJEHSCZV4wfjRSqeYP/1A+DrBIhfuxvKGNKqRRNBaX
8okVmVPlFSq3uyBDOUgfQfqoIPktdZgFjJ+MpBBUwgxnpnjJv8lP6+cDILM4zgxl
kKsg1DDT8fnL4KFiaLc/4Drc2xYOahzbvon7KVfzaToQjQZnYAYyNziMgZ5RlCml
PErnM+xyzbMV9lZYTDkfHJIF5XBlBabMI6fkwGHG0Z7cwWmyRIpooKaFV9Vt5HO1
rQkvEc3pcdS4WeKPovxw1XM6dFYmYxEpmWJaZ2w/9qn8IMsoSoO/ToQKkSRlz1Tz
oTjSAIMqR90G9OmR7IDQXAOIq3oTUqBRlkZEXuRZKR70zT64X7nbcHjOl7rETGGg
qS32dgNlKwDBhFRSdJ39MMqyugRotGGNclW8cY/Nydr22V2vvf2+G2HQfj3yXipq
+wF4owYyL7dMdfbvh0W/KuiKh+4rFi+DL/0oZ+xvZ3Rc0eUy195lGIoycFgfK8xo
301ewinE1EFqfZ6rZZuN/8PhpX12ZGAE0xcdjMxu4mrtDq+AdBexaDI32urAytBF
jp0aVKvVTuamLisi7Dk1Ez1tKpk0rkHnwz0oHaWDbbYA7oboEkoU4HI77RjURY3g
UtPCF7XQllFe9bgBQ8yfSX7g1nNArQtnHQHe2Kutf7BgZSUhGI+177JHNENhk/ww
o5YvelNejQUdH/xPNSwE
=iRma
-----END PGP SIGNATURE-----