Changes:

2.2.1 (January 2025)

• patches from Ludovic Rousseau

  • waitforcardevent(): do not miss events between 2 calls

  • Use Windows locale to decode Unicode text

  • ACKS: add missing contributors

• patches from Kurt McKee

  • Test, fix, and simplify ATR parsing

Web hosting

Since May 2023 I host the blog myself (on my own server using my own domain name) and no more on Google blogger servers. I am very happy with this change.

Statistics

For 2024 the blog served 225977 pages (~25 pages per hour) for a total of 26.41 GB.

Conclusion

Thank you to you, readers.

Do not hesitate to suggest new subjects, or tools, et caetera you would like to read about. See About me to contact me.

This blog has no advertising. If you want to support me you can become a GitHub Sponsors.

Executive summary

Your file ~/.gnupg/scdaemon.conf should contain:

disable-ccid
pcsc-shared

PC/SC access sharing

More and more applications are using smart cards. So they all need to behave cooperatively to share the access to the card.

PC/SC provides a way to connect to a smart card and get an exclusive access to it. That is the parameter dwShareMode of SCardConnect(). It can take 3 values:

• SCARD_SHARE_SHARED - This application will allow others to share the reader.

• SCARD_SHARE_EXCLUSIVE - This application will NOT allow others to share the reader.

• SCARD_SHARE_DIRECT - Direct control of the reader, even without a card. SCARD_SHARE_DIRECT can be used before using SCardControl() to send control commands to the reader even if a card is not present in the reader. Contrary to Windows winscard behavior, the reader is accessed in shared mode and not exclusive mode.

If you use SCARD_SHARE_EXCLUSIVE then no other application can use the reader, and the card inserted in the reader, until the application calls SCardDisconnect().

If you try to use SCARD_SHARE_EXCLUSIVE while another application already has a connection to the reader then your own call fails with SCARD_E_SHARING_VIOLATION. Only one application can connect to the reader when SCARD_SHARE_EXCLUSIVE is used.

Problem with GnuPG

A user reported an issue on PC/SC because he was not able to use GnuPG2 in Yubikey 5 with gpg2 only initialized properly after restarting pcscd #215.

He gets the output:

$ gpg2 --card-status
gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

I tried to reproduce the problem and log the GnuPG PC/SC calls as described in PCSC API spy using LIBPCSCLITE_DELEGATE. Unfortunately the environment variable LIBPCSCLITE_DELEGATE is ignored by scdaemon (GnuPG program used to access the smart card). I guess that is because scdaemon sanitizes its environment to limit attacks.

I had to slightly modify pcsc-lite to force the use of the spying library:

diff --git a/src/libredirect.c b/src/libredirect.c
index ac023f4..e40d7f6 100644
--- a/src/libredirect.c
+++ b/src/libredirect.c
@@ -127,7 +127,7 @@ static void log_line(const char *fmt, ...)

 static LONG load_lib(void)
 {
-#define LIBPCSC "libpcsclite_real.so.1"
+#define LIBPCSC "libpcscspy.so.0"

    const char *lib;

From the PC/SC calls the problem is obvious:

SCardEstablishContext
 i dwScope: SCARD_SCOPE_SYSTEM (0x00000002)
 o hContext: 0x43293756
 => SCARD_S_SUCCESS [0x00000000]  [0.010792]
SCardListReaders
 i hContext: 0x43293756
 i mszGroups: (null)
 o pcchReaders: 0x0000001A
 o mszReaders: NULL
 => SCARD_S_SUCCESS [0x00000000]  [0.000161]
SCardListReaders
 i hContext: 0x43293756
 i mszGroups: (null)
 o pcchReaders: 0x0000001A
 o mszReaders: Alcor Micro AU9540 00 00
 o mszReaders: 
 => SCARD_S_SUCCESS [0x00000000]  [0.000287]
SCardConnect
 i hContext: 0x43293756
 i szReader Alcor Micro AU9540 00 00
 i dwShareMode: SCARD_SHARE_EXCLUSIVE (0x00000001)
 i dwPreferredProtocols: 0x00000003 (T=0, T=1)
 i phCard 0x00000000 (0)
 i pdwActiveProtocol 0x00000000 (0)
 o phCard 0x00000000 (0)
 o dwActiveProtocol: T=1 (0x00000002)
 => SCARD_E_SHARING_VIOLATION [0x8010000B]  [0.007124]
SCardReleaseContext
 i hContext: 0x43293756
 => SCARD_S_SUCCESS [0x00000000]  [0.000101]

The call to SCardConnect() fails with SCARD_E_SHARING_VIOLATION.

Werner Koch (GnuPG author & maintainer) added a comment in the issue:

I then modified my ~/.gnupg/scdaemon.conf file to contain:

disable-ccid
pcsc-shared

And it now works better:

SCardEstablishContext
 i dwScope: SCARD_SCOPE_SYSTEM (0x00000002)
 o hContext: 0x4EFB8700
 => SCARD_S_SUCCESS [0x00000000]  [0.011911]
SCardListReaders
 i hContext: 0x4EFB8700
 i mszGroups: (null)
 o pcchReaders: 0x0000001A
 o mszReaders: NULL
 => SCARD_S_SUCCESS [0x00000000]  [0.000177]
SCardListReaders
 i hContext: 0x4EFB8700
 i mszGroups: (null)
 o pcchReaders: 0x0000001A
 o mszReaders: Alcor Micro AU9540 00 00
 o mszReaders: 
 => SCARD_S_SUCCESS [0x00000000]  [0.000162]
SCardConnect
 i hContext: 0x4EFB8700
 i szReader Alcor Micro AU9540 00 00
 i dwShareMode: SCARD_SHARE_SHARED (0x00000002)
 i dwPreferredProtocols: 0x00000003 (T=0, T=1)
 i phCard 0x00000000 (0)
 i pdwActiveProtocol 0x00000000 (0)
 o phCard 0x1EF6C421 (519488545)
 o dwActiveProtocol: T=1 (0x00000002)
 => SCARD_S_SUCCESS [0x00000000]  [0.009658]
SCarControl
 i hCard: 0x1EF6C421
 i dwControlCode: CM_IOCTL_GET_FEATURE_REQUEST (0x42000D48)
 i bSendLength 0x00000000 (0)
 i bSendBuffer
 i  NULL
 o bRecvLength 0x00000006 (6)
 o bRecvBuffer
 o  0000 12 04 42 33 00 12                               ..B3..
 => SCARD_S_SUCCESS [0x00000000]  [0.000267]
  parsing CM_IOCTL_GET_FEATURE_REQUEST results:
  Tag FEATURE_GET_TLV_PROPERTIES is 0x42330012
[...]

The call to SCardConnect() now works ang GnuPG continues with SCarControl(), etc.

GnuPG history

The GnuPG code uses PCSC_SHARE_EXCLUSIVE since the first version supporting PC/SC in commit 1bcf8ef9dea1a9b171c27ef48cadb79df6201e33.

Author: Werner Koch <wk@gnupg.org>
Date:   Tue Aug 5 17:11:04 2003 +0000

    Cleanups, fixes and PC/SC support

+  err = pcsc_connect (reader_table[slot].pcsc.context,
+                      portstr? portstr : list,
+                      PCSC_SHARE_EXCLUSIVE,
+                      PCSC_PROTOCOL_T0|PCSC_PROTOCOL_T1,
+                      &reader_table[slot].pcsc.card,
+                      &reader_table[slot].pcsc.protocol);

The option to use PCSC_SHARE_SHARED was introduced in 2021 with commit 5732e7a8e97cebf8e850c472e644e2a9b040836f.

Author: Werner Koch <wk@gnupg.org>
Date:   Fri Mar 12 09:21:57 2021 +0100

    scd: New option --pcsc-shared.

    * scd/scdaemon.h (opt): Add field opcsc_shared.
    * scd/scdaemon.c (opcscShared): New.
    (opts): Add "--pcsc-shared".
    (main): Set flag.
    * scd/apdu.c (connect_pcsc_card): Use it.
    (pcsc_get_status): Take flag in account.
    * scd/app-openpgp.c (cache_pin): Bypass in shared mode.
    (verify_chv2: Do not auto verify chv1 in shared mode.
    * scd/app-piv.c (cache_pin): By pass caceh in shared mode.
    --

    This option should in general not be used.  The patch tries to limit
    bad effects but using shared mode is somewhat dangerous depending on
    the other PC/SC users.

   err = pcsc_connect (pcsc.context,
                       reader_table[slot].rdrname,
-                      PCSC_SHARE_EXCLUSIVE,
+                      opt.pcsc_shared? PCSC_SHARE_SHARED:PCSC_SHARE_EXCLUSIVE,
                       PCSC_PROTOCOL_T0|PCSC_PROTOCOL_T1,
                       &reader_table[slot].pcsc.card,
                       &reader_table[slot].pcsc.protocol);

Temporary exclusive access

It is possible to get an exclusive access to a card but still share the reader with other applications.

The idea is to request an exclusive access for a short time, only when needed, using PC/SC transactions.

SCardBeginTransaction()

Establishes a temporary exclusive access mode for doing a series of commands in a transaction.

You might want to use this when you are selecting a few files and then writing a large file so you can make sure that another application will not change the current file. If another application has a lock on this reader or this application is in SCARD_SHARE_EXCLUSIVE the function will block until it can continue.

SCardEndTransaction()

Ends a previously begun transaction.

The calling application must be the owner of the previously begun transaction or an error will occur.

The application connects to the reader using SCARD_SHARE_SHARED. And then uses SCardBeginTransaction()/SCardEndTransaction() to send a list of APDU without any interruption. Typically the application does something like:

1. start a transaction

2. submit the user PIN code

3. perform a protected operation like signing

4. invalidate the user PIN code

5. end the transaction

With this algorithm another application cannot inject a command between steps 1 and 5 and benefit from the verified user PIN.

Conclusion

Using an exclusive access at SCardConnect() is problematic in a multi applications system.

Use PC/SC transactions instead.

Pros

The application binary does not depend on an external library. It is then easier to use on a minimal system that works on "any" x86_64 GNU/Linux distribution.

This request comes from a user of Alpine Linux. See github issue #216.

Cons

The mechanism to log pcsc-lite calls can't be used (PCSC API spy using LIBPCSCLITE_DELEGATE). It will also not be possible to use the mechanism to redirect calls for RDP (How to use LIBPCSCLITE_DELEGATE?).

If the library libpcsclite.a uses a protocol version that is different from the protocol version used by the installed pcscd server then client/server communication will fail. It will not "run everywhere". (See Accessing smart cards from inside a flatpak sandbox).

Conclusion

The Debian package does NOT provide the static version of the library because of the cons listed above.

But it may make sens for Alpine Linux or another specialized distribution to provide a static version of the library.

Changes:

2.3.1: Ludovic Rousseau

24 December 2024

• Install a default /etc/default/pcscd file

• auth.c: implement polkit support for FreeBSD

• meson:

  • also build static version of libpcsclite

  • add options to disable polkit and libsystemd

  • add "filter_names" in features when needed

• Doxygen: document dwCurrentState use for "\\?PnP?\Notification"

• Some other minor improvements

Changes:

2.2.0 (October 2024)

• patches from Ludovic Rousseau

  • PCSCCardRequest

    • handle KeyboardInterrupt in waitforcard() & waitforcardevent()

    • use a local PC/SC context to avoid locks

  • smartcard.util.padd(): do NOT modify the input parameter

  • CardMonitoring: a timeout exception IS expected

  • Fix pydoctor documentation

  • wx: fix module and examples

  • Minor changes

• patches from Kurt McKee

  • Remove Python 2 conditional code

  • Eliminate Windows Vista and Windows 7 conditionals

  • Test and improve the synchronization code

  • Test and update the Observer.py code

  • Remove ClassLoader.py

  • Migrate a src/ layout

  • Migrate test/* from unittest to pytest

  • Add missing GSM 03.38 symbols for decoding

  • Support only Python 3.9 and higher

  • Remove the Python 2.x-only Pyro dependency

  • Migrate CI to use the official Coveralls action

  • Standardize local and CI testing to use tox

  • Build wheels in CI for all supported Python versions

  • Build the docs as a part of the test suite

  • Begin to add type annotations to the package

  • Deprecate the HexListToBinString, BinStringToHexList, hl2bs, and bs2hl utility functions

  • Support "64" as an ATR baud rate adjustment integer (ISO 7816-3 2006)

CCID

% grep -A 1 CFBundleShortVersionString /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist
        <key>CFBundleShortVersionString</key>
        <string>1.5.1</string>

My CCID driver has not been updated in macOS since Sonoma. It is still version 1.5.1.

The CCID version 1.5.2 was released in January 2023 but that version was not included by Apple in macOS Sonoma. That was a bit surprising when Sonoma was released in 2023. It is now worrying.

The current/latest version is 1.6.1 released in July 2024. I guess Apple provides my CCID driver as a backup only. They do not plan to invest much time and update to the latest version.

Apple Open Source

The Open Source components included in macOS are listed at <https://opensource.apple.com/releases/>

The Open Source components of Sequoia 15.0 are already available.

The component SmartcardCCID-55036 points to the GitHub project apple-oss-distributions/SmartcardCCID. The patch for version 55036 released on September 24th, 2024 for Sequoia compared to version 55033 released on September 22th, 2023 for Sonoma is limited to changes in the way the software is patched by Apple. You can see the difference at SmartcardCCID-55036.

I note that this project on GitHub has 2 forks <https://github.com/apple-oss-distributions/SmartcardCCID/forks>:

• classicvalues/SmartcardCCID

  One patch applied in the whitesource/configure branch to Add .whitesource configuration file. I do not know what whitesource is. It may be related to an Atlassian service called Mend for Jira Data Center (formerly WhiteSource).

  The repository owner is Classic Values described as "Software Development and Design Corporation built by Freelancing Solo-entrepreneur" with more than 5000 projects.

• swissbit-eis/SmartcardCCID

  This fork is more interesting. Some minor patches have been applied.

  One patch is slow down ccid communication and it adds a delay of 10ms on each USB write. I have no idea why. Maybe to allow a slow/bogus swissbit reader to correctly interact with the driver.

  The repository owner is Swissbit AG (EIS Division).

  This company sells CCID tokens. I already have one in my "should work" list <https://ccid.apdu.fr/select_readers/?idVendor=4976>

Apple CCID driver

As with Sonoma, the driver used by default for CCID smart card readers is a driver written by Apple.

See the chapter "Reader name dynamically generated" from macOS Sonoma and smart cards status to know how I know that. It is related to the reader name reported by PC/SC, for example by pcsctest installed by default on macOS.

If I compare the Info.plist of the usbsmartcardreaderd.slotd with the latest macOS Sonoma I get:

% diff -u /Volumes/Sonoma/System/Library/CryptoTokenKit/usbsmartcardreaderd.slotd//Contents/Info.plist /System/Library/CryptoTokenKit/usbsmartcardreaderd.slotd//Contents/Info.plist
--- /Volumes/Macintosh HD/System/Library/CryptoTokenKit/usbsmartcardreaderd.slotd//Contents/Info.plist      2024-09-05 11:17:41
+++ /System/Library/CryptoTokenKit/usbsmartcardreaderd.slotd//Contents/Info.plist   2024-10-01 06:10:49
@@ -3,7 +3,7 @@
 <plist version="1.0">
 <dict>
    <key>BuildMachineOSBuild</key>
-   <string>22A380019</string>
+   <string>22A380021</string>
    <key>CFBundleDevelopmentRegion</key>
    <string>en</string>
    <key>CFBundleExecutable</key>
@@ -27,21 +27,21 @@
    <key>DTCompiler</key>
    <string>[com.apple](http://com.apple).compilers.llvm.clang.1_0</string>
    <key>DTPlatformBuild</key>
-   <string></string>
+   <string>24A318</string>
    <key>DTPlatformName</key>
    <string>macosx</string>
    <key>DTPlatformVersion</key>
-   <string>14.7</string>
+   <string>15.0</string>
    <key>DTSDKBuild</key>
-   <string>23G1000s</string>
+   <string>24A318</string>
    <key>DTSDKName</key>
-   <string>macosx14.7.internal</string>
+   <string>macosx15.0.internal</string>
    <key>DTXcode</key>
-   <string>1500</string>
+   <string>1600</string>
    <key>DTXcodeBuild</key>
-   <string>15E6079e</string>
+   <string>16A6170g</string>
    <key>LSMinimumSystemVersion</key>
-   <string>14.7</string>
+   <string>15.0</string>
    <key>NSHumanReadableCopyright</key>
    <string>Copyright © 2020 Apple. All rights reserved.</string>
 </dict>

Not very interesting nor informative.

Known bugs

The page listing the bugs I found in Sonoma is available at macOS Sonoma and smart cards: known bugs.

I have not been notified by Apple that a bug has been fixed in Sequoia. So I guess the bugs are still present.

I discovered a new problem with Apple driver: the error returned by SCardConnect() call is "Card is unresponsive."

    % pcsctest
    MUSCLE PC/SC Lite Test Program
    Testing SCardEstablishContext    : Command successful.
    Testing SCardGetStatusChange
    Please insert a working reader   : Command successful.
    Testing SCardListReaders         : Command successful.
    Reader 01: Gemplus USB SmartCard Reader
    Enter the reader number          : 1
    Waiting for card insertion
                                     : Command successful.
    Testing SCardConnect             : Card is unresponsive.

I get this result even if the card is correctly powered. The reader LED is fixed, indicating the card is powered.

I was able to sometimes get the card ATR. Very strange to have such a simple bug unnoticed by QA.

After enabling my CCID driver (see Enable my CCID driver), of course, the problem is fixed.

Conclusion

If you have a smart card issue on macOS Sequoia, my first suggestion is to switch from the Apple driver to my CCID driver and check again.

Changes:

1.5.17 - October 2024, Ludovic Rousseau

• Add AES in counter mode support (CKM_AES_CTR)

• Add simple derivation mechanisms support (CMK_CONCATENATE_*)

• Fix reference counting in PyKCS11Lib.load()

• remove python 2 support from ckbytelist

• minor improvements

Changes:

2.1.1 (September 2024)

• Fix a regression introduced in 2.1.0

Changes:

2.1.0 (September 2024)

• PCSCCardRequest: fix active polling (was a 0.1 sec loop)

• Fix use of undefined variable hresult in exceptions

• Fix print() use in pyscard user’s guide

• Fix deprecation warnings

• Minor changes