Peaceful coexistence of GnuPG and other smart card software

[Martin Paljak]

Hello,

On 8/30/11 7:17 , Werner Koch wrote:
> On Tue, 30 Aug 2011 14:04, martin at martinpaljak.net said:
> 
>> 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
> 
> Card applications or host applications? For the former you merely need
> to write an app-foo module to scdaemon.  For the latter you may use the
> provided api or if you want pkcs#11, use scute.

Both. I'm recently a small fan of the CryptoStick device (probably soon
the OpenPGP v2 card as well, once I get to ordering some) generously
donated by GPF because of the 4k keys but I also have a bunch of
non-OpenPGP cards like national eID, which I'd like to use with GnuPG as
subkeys for daily use for example

Scute did not work for me. Eventually I'd anyway like to use OpenSC for
PKCS#11 (and for OS X/Chrome for SSL and Mail.app for X509 S/MIME and
Windows/Chrome for SSL). Also, scute suffers from the same lock-in
problem as scdaemon.


>> 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
> 
> No, any write/put/verify/etc operation.  Right this means that pc/sc
> would need to interpret the APDUs; thus it is likely that it needs to
> send notify us most of the time.

That's not provided by PC/SC and IMHO should not.

Thus the approach of assuming unknown state from the card for every
operation is justified and sounds like a reasonable approach.

>> which deals with more higher level "smart card mangling" with card
>> groups and files and whatnot. I don't have strong belief in the
> 
> Well, we agree here.  Microsoft uses mini drivers, GnuPG uses scdaemon.

There are many more functions in the SCard* family that do not directly
relate to implementing a Minidriver [1], at least not "externally" to
people wishing to implement smart card support for Windows platform
applications.

The key here is that Microsoft/CryptoAPI is a more like a platform
whereas GnuPG is an application. At least for me. I don't know any other
"consumers" of GnuPG/scdaemon stack.

So the aggressive resource grabbing of scdaemon is not justified IMHO.


>> 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"
> 
> No problem as long as all readers have different names.  Beware of bugs
> - it is probably not well tested because I always suggest the use of the
> internal driver.

All readers do have different names and that is the problem. When
hotplugging readers their names change, so it is not possible to have a
fixed and always meaningful configuration. Compare to ethX ordering
changing on bootup with early Linuxes (can't remember the details but
the problem had similar symptoms)

I'll classify this as a bug.


>> 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
> 
> Just configure the timeout value and it works.

Did not work for me, see my initial e-mail. scdaemon was kept running
and locked the reader. Maybe I got so desperate and mixed up with
gpg1/gpg2 that it was some kind of interference. I'll investigate one
more time. In any case it could be made more user friendly by default
(meaning less configuration needed for most uses).


> 
>> Disregard Linux and read it as "popular open source Unices".
> 
> GnuPG is also used on proprietary Unices.
Disregard "open source" as well. I meant "popular Unices", ones that
actually matter in connection with open source software or otherwise
recent computing (I doubt AIX or HPUX really matters)

The Unix problem is the Android problem (being Linux based) which is
fragmentation. There is no such thing for 90% for Unices as there is for
90% of Windows boxes or 99% of OS X boxes for "platform crypto". There
is no central API (like open() read() close()) that would deal with
crypto that would be universal and shared between platforms and accepted
and re-used by applications.

There are xyz_CryptoInit() and foobar_init_crypto_stack() and
MySecurityServicePKCS11Init() and whatnot, but they are not shared.

So it is virtually impossible to create a solution that would take
exclusive ownership of hardware devices like smart cards for the purpose
of presenting them to the rest of the system.


>> Linux^H^H^H^HUnices on the other hand have OpenSSL, NSS, ssh-agent,
>> gpg-agent, pcscd+ccid, PKCS#11, gnutls, OpenSC, ...
> 
> You are mixing something:
> 
> - NSS and GnuPG are systems with very similar goals.  In particular they
>   their usual use cases require a user interface.
NSS is a quite generic crypto library which also implements a bunch of
protocols like TLS. GnuPG on the other hand is mostly PGP and to me
manifests itself mostly as a command line utility.

NSS is more like OpenSSL, that by name should be a SSL library but
happens to be the thing that people link against to get sha1...

> - Pcscd is a low-evel hardware abstraction library.
PC/SC is an API for accessing smart card readers and cards.
> - OpenSC is a high level card application abstraction library.
> - PKCS#11 is an API
OpenSC and PKCS#11 fill the same goals: providing access to keys in
hardware. OpenSC just happens to implement more interfaces than only
PKCS#11 for accessing smart card type devices.
> - ssh-agent and gpg-agent are parts of larger systems (GnuPG and SSH)

You previously wanted to suggest that gpg-agent could be viewed as a
"minidriver" replacement (meaning a provider for a broader platform)
when yes, indeed, it is a part of an application.


>> Fedora folks think that "NSS should be the central service for
>> everything crypto" and have the "crypto consolidation effort" [1].
> 
> Because Redhat needs FIPS 140 validation for RHEL and once they decided
> that the easiest way to do this is by using the already FIPS validated
> NSS.
Yes. It also gives some benefits like "maybe working hardware key
machinery support" because of PKCS#11 support in NSS.

But I hope that it does not spread outside of Redhat and I envision
applications with several different backends [2].


>> 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
> 
> It is about free software and not about vendors.  At least for the GNU
> project using GnuPG seems to be a very good choice.
>> though it can use PKCS#11 which should be a good sign), gpg-agent
>> fails and ssh-agent fails. And PKCS#11 wins IMHO.
> 
> Sorry, you can't compare gpg-agent and ssh-agent - see above.

My point is that tying hardware access, which belongs to a "platform" if
anywhere at all, to a single implementation like gpg-agent/scdaemon is
not optimal. I've probably made some reckless comparisons.

>> 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
> 
> Right, it makes a lot of sense to them.  A stated goal of OpenSSH is to
> allow the use by proprietary systems.  Thus they do everything to make
> proprietary software vendors happy; i.e. use an pkcs#11 interface.
Is it such a bad goal? PKCS#11 seems a quite innocent approach compared
to some other things that are happening on the "border of free and
proprietary". It gets things done in practical environment so it should
be encouraged.


> Checkout who works on OpenSSH and what they do for a living.
I don't know. Do you have pointers? Can't blame one for earning a living
though...

In the end we're all biased and have certain affiliations. I try to
stick to common sense...

>> 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
> 
> Well, Microsoft doesn't use it anymore.
Because they have something better and more meaningful for Windows.
CryptoAPI. Nothing forbids applications from using PKCS#11 on Windows -
there are plenty of providers available and there's a lot of specialized
applications using PKCS#11 on Windows (HSM-s?), most are using
specialized hardware anyway. Most "desktop applications" are better off
using CryptoAPI.


>> "K" vs "G" debate common in Linux. Which is much less productive than
> 
> I am not using any of these desktops.  I would never tie software I
> maintain to one specific desktop GUI.

My comparison was arbitrary, as it seems to me that you want to tie
using OpenPGP cards to using GnuPG, by requiring the use of scdaemon for
any other purposes and vice-verse, re-creating existing software
(PKCS#11) to access existing hardware keys with GnuPG?

>> 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
> 
> The reasons was more that OpenSC used to be a collection of smart card
> related code with no common idea what to build.  I participated in the
> early OpenSC development but turned away for this reason and because of
> bad software maintenance style (API and ABIs changes at will).

Yeah, being kitchen-sink has had its downsides. But as said, PKCS#11
fixes the API/ABI problem these days. OpenSSH used to have code that
linked against libopensc and this has been abandoned for a good reason -
it was a bad choice in the beginning.

The purpose of OpenSC is much more focused right now: providing access
for hardware keys on supported cards to as many applications as possible
(and creating supported cards (personalizing) if possible)

I actually think that OpenSC should be split/forked one more time, by
creating an "OpenTMC" as "open token management center" that would add
more pieces for token issuing and management, like being a secure
messaging key manager (not a simple task either). Pure and simplistic
PKCS#15 creation won't be enough in near time for practical use.


>>  * 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?
> 
> So what was the problem?  The card code in master needs some work; there
> are some things which have not yet been implemented and we have not
> ported changes from 2.0.

"key not found" when decrypting with gpg2 even though key gets listed OK
but success with gpg1 (after setting the environment right for gpg, with
OpenPGP card in first unused PC/SC reader)

>>  * If I was to "fix" (in my terms) the problems with scdaemon:
>>   - selecting a suitable reader automagically without configuration
>> file/command line changes
> 
> You mean the default reader should be the reader which most likely
> supports most cards.  I.e. kick out all Omnicard and possible cheap
> internal readers?

The default reader used by scdaemon when used through gpg/gpg-agent
should be:
 - one that actually contains a card (not failing with "please insert a
card" message, which should only be used if there is a static
configuration or command line parameter)
 - one that contains a supported card (if I have reader A with a card
not supported by GnuPG and reader B with an OpenPGP card, reader B
should be used by default (or automagically))


>>   - locking the reader only when it is in fact used (for
>> encryption/decryption)
> 
> Better use the timeout option.  If the timeout option should be enabled
> by default we should discuss this.  If it works for more users better
> than we should enable it. 
Did not work. Should be enabled. Will try again. With multiple
applications a shared connection will always be open to the card from
another application, so scdaemon must also not fail when it can't
connect to reader in exclusive mode but use transactions instead. It
can't assume exclusive access.


>>  how should I continue? Should I fix gpg or gpg2? Or both? What is the
>> relation between gpg1 and gpg2 codebases?
> 
> Forget about gpg1 and cards - after all it uses an installed gpg-agent
> anyway before it falls back to the included code.  Thus without a
> running gpg-agent it is does not grab the reader.  We source copy files
> from 2.0 to 1.4; thus don't develop on the 1.4 branch.
> 
> If you want to fix something card related you better look at the stable
> 2.0 branch for now.
OK.


>> Some general pointers would suffice, I've done some homework but
>> probably not enough to succeed at once.
> 
> If you have problems feel free to ask; you may also jabber me (I use
> guug.de jabber address).  If you want to write code, we need a copyright
> assignments to the FSF.
OK.



[1] http://msdn.microsoft.com/en-us/library/aa380144(v=VS.85).aspx
[2] http://curl.haxx.se/docs/ssl-compared.html
-- 
@MartinPaljak
+3725156495