Blog moved to

I moved my blog from to . Why? I wanted to move away from Blogger (owne...

Thursday, February 17, 2022

One smart card reader accessible from many computers

In 2010 I wrote the article "PC/SC client and server on two different hosts". At that time OpenSSH was not able to redirect Unix sockets.

I just received a request to (re)do something similar. Of course, I forgot I wrote this article 12 years ago. So I started searching for a solution, again.

Since OpenSSH 6.7 (released in 2014) it is possible to redirect Unix sockets over the network.


The normal pcsc-lite use case is described in the figure bellow: 

The goal is to have 2 computers connected by a network and transfer the pcsc-lite internal connection over the network as described bellow:


On computer1 you have your smart card reader(s) connected and pcscd will run as usual. You do not need to change your pcsc-lite configuration.

A user on computer1 is able to connect to computer2 using ssh and run something like:

$ ssh -N -R/tmp/pcscd.comm:/run/pcscd/pcscd.comm computer2

Note that the socket on computer2 is /tmp/pcscd.comm and not /run/pcscd/pcscd.comm as on computer1. That is because of access rights restriction. Only root is allowed to create files in /run/pcscd/.

Otherwise I get the error:

Warning: remote port forwarding failed for listen path /run/pcscd/pcscd.comm

So I create the socket on computer2 in /tmp/ instead.


On computer2 you define the pcsc-lite socket path to use.

$ export PCSCLITE_CSOCK_NAME=/tmp/pcscd.comm

And you can run your PC/SC application as usual.

Connection in the other direction

It is also possible to do the SSH connection from the client to the server. On the client you do something like

$ ssh -N -L/tmp/pcscd.comm:/run/pcscd/pcscd.comm computer1

It may be easier this way if the client is light terminal and does not have an ssh server running for example.

Socket access rights

The socket /tmp/pcscd.comm is created as the user running the ssh command. For example in my case it is created as user "rousseau".

$ ls -l /tmp/pcscd.comm
srw------- 1 rousseau rousseau 0 17 févr. 12:07 /tmp/pcscd.comm

As you can see the access rights are limited to read & write for "rousseau" and no access for the other users. You may want to share the remote connection to other users in the client computer. You can do something like:

$ chmod a+rw /tmp/pcscd.comm

The administrator of the system is free to configure the access rights to use.


When you stop the ssh execution, the socket /tmp/pcscd.comm created on the client side is not removed.

So if you run ssh again you will get the error:

$ ssh -N -R/tmp/pcscd.comm:/run/pcscd/pcscd.comm computer2
Warning: remote port forwarding failed for listen path /tmp/pcscd.comm

or (if the connection is used in the other direction):

$ ssh -N -L/tmp/pcscd.comm:/run/pcscd/pcscd.comm computer1
unix_listener: cannot bind to path /tmp/pcscd.comm: Address already in use
Could not request local forwarding.

One card, multiple computers

The same smart card can also be accessed from different computers. The ssh redirection is not limited to one computer. You can have 1 server and 10 clients all connected to the same server so connected to the same smart card reader(s).


The pcsc-lite daemon pcscd will still play his role of resource manager. So if the applications are correctly written with PC/SC transactions to get exclusive access to the card, no problem is expected. i.e. no more problems than if the 3 applications were all running locally in computer1.

Multi-architecture support

It is possible to run the server on one CPU architecture and run clients on a different CPU architecture.

I tried running the server on a x86-64 CPU (Intel PC) and the client on a ARM-32 CPU (Raspberry Pi 3 using armv7l). It works like a charm.

The internal pcsc-lite protocol is not sensible to 32 or 64-bits CPU differences. I have not tested a mix with big-endian and little-endian CPUs. I do not have a computer using a big-endian CPU. I am pretty sure that configuration would fail.


This architecture is a generalisation of accessing the pcscd server from the host and also from guests in virtual environments (described in "Accessing smart cards from inside a flatpak sandbox") but, this time, with remote computers. 

I am sure people will find many original use cases for an architecture like this. Please tell me if and how you use it.

Monday, February 14, 2022

Fedora, flatpak and pcsc-lite

The bug "Unable to list readers inside flatpak, when pcscd runs on host." was very strange. It is not like the potential problem I described in "Accessing smart cards from inside a flatpak sandbox" where we have 2 sides (host & flatpak container) using different versions of the pcsc-lite internal protocol.

In the present case both sides are using the same protocol but SCardGetStatusChange() fails with a very strange error: Unknown error: 0x53204253. 0x53204253 is not a (valid) error code returned by any of the PC/SC functions.

Fedora custom build

After some debug I discovered that Fedora provides pcsc-lite packages with a modification.

From your can download the source package which contains the patch file pcsc-lite-1.9.1-maxreaders.patch.

diff -up ./src/PCSC/ ./src/PCSC/
--- ./src/PCSC/	2018-08-20 16:02:17.708302410 -0700
+++ ./src/PCSC/	2018-08-20 16:02:49.462500967 -0700
@@ -281,7 +281,7 @@ extern const SCARD_IO_REQUEST g_rgSCardT
 #define PCSCLITE_VERSION_NUMBER		"@VERSION@"	/**< Current version */
 /** Maximum readers context (a slot is count as a reader) */
 #define MAX_READERNAME			128
diff -up ./src/PCSC/pcsclite.h.readers_32 ./src/PCSC/pcsclite.h
--- ./src/PCSC/pcsclite.h.readers_32	2018-08-20 16:02:30.993385481 -0700
+++ ./src/PCSC/pcsclite.h	2018-08-20 16:03:00.061567242 -0700
@@ -281,7 +281,7 @@ extern const SCARD_IO_REQUEST g_rgSCardT
 #define PCSCLITE_VERSION_NUMBER		"1.9.5"	/**< Current version */
 /** Maximum readers context (a slot is count as a reader) */
 #define MAX_READERNAME			128

This patch redefines PCSCLITE_MAX_READERS_CONTEXTS which is the maximum number of readers supported by pcsc-lite and update the value from 16 to 48.

pcsc-lite internal protocol

To implement the function SCardGetStatusChange() pcsc-lite exchanges the list of readers between the daemon (pcscd) and the client (

pcscd will sent a list of PCSCLITE_MAX_READERS_CONTEXTS readers and is expecting a list of PCSCLITE_MAX_READERS_CONTEXTS readers.

Flatpak issue

In the case of flatpak the server is running on the host and is provided by Fedora, and the client is running inside the flatpak container and is provided by whoever provides the flatpak so possibly with a pcsc-lite client not from Fedora.

And now we have a problem: the daemon is sending a list of 48 readers while the client is expecting a list of only 16 readers. After that, many bad things can happen, like incorrect return values. 

Flatpak solution

The solution is simple: include in the flatpak container a client library that is configured like the server on your host i.e. patch the pcsc-lite included in the container.

The bad news is that the flatpak contained application will not be universal any-more. You will need 2 different containers for Fedora and for Debian for example.

pcsc-lite-ccid patch

The pcsc-lite-ccid Fedora package (CCID reader driver) also uses a patch to increase the number of supported readers.

The package source code is available at and contains the file ccid-1.4.34-maxreaders.patch

diff -up ./src/ccid_ifdhandler.h.readers_32 ./src/ccid_ifdhandler.h
--- ./src/ccid_ifdhandler.h.readers_32	2018-08-20 16:06:34.080905748 -0700
+++ ./src/ccid_ifdhandler.h	2018-08-20 16:07:04.638097096 -0700
@@ -47,7 +47,7 @@ extern int DriverOptions;
  * The maximum number of readers is also limited in pcsc-lite (16 by default)
  * see the definition of PCSCLITE_MAX_READERS_CONTEXTS in src/PCSC/pcsclite.h
  * CCID driver specific functions

According to the spec file pcsc-lite-ccid.spec this changes dates from June 2021:

* Fri Jun 25 2021 Jakub Jelen <> - 1.4.34-2
- Add support for more readers

So less than a year.

Increase the number of readers?

I guess Fedora/RedHat has one (or more) customer(s) with a need to support more than 16 readers. Maybe that is the case of 0.01% of pcsc-lite users (rough estimation out of my mind). And for some users 48 readers will not be enough (See "A reader for 96 smart cards? sysmoSIMBANK").

A long term solution is to move from a hard coded limit of CCID_DRIVER_MAX_READERS readers to a dynamic (unlimited) list. This is already planed for pcsc-lite in "use a list instead of a fixed size array for 16 reader states" and for ccid in "use a list instead of a fixed size array for 16 reader states". I had no motivation to implement that so far. If you need this change please contact me.

Revert the Fedora patches?

One option to solve the issue with Flatpak would be for Fedora/RedHat to revert the patches.

I don't know if they have more customers using more than 16 smart card readers, or more customers using Flatpak applications.


Flatpak applications with a need to access smart cards or tokens (Chrome, Teams) may be difficult to use on Fedora/RedHat.

Friday, February 11, 2022

Accessing smart cards from inside a flatpak sandbox

I received a bug report about "Unable to list readers inside flatpak, when pcscd runs on host." complaining that a smart card reader is not accessible from inside a flatpak sandbox. 

I then discovered many other flatpak issues regarding smart cards access in

I never used flatpak so I start by trying to reproduce the problem.


  • GNU/Linux Debian testing
  • flatpak 1.12.4-1
  • pcscd 1.9.5-1

Simple test

The idea is to run pcsc_scan from a flatpak sandbox using the pcscd daemon on the host. This is possible since the flatpak patch "Add support for PCSC socket".

Since the daemon (pcscd) and the client library ( use a socket (/run/pcscd/pcscd.comm by default) to communicate we just have to export the socket in the sandbox to allow the communication.

The important part for that is:

  - --socket=pcsc


File fr.apdu.pcsc_scan.yml

app-id: fr.apdu.pcsc_scan
runtime: org.freedesktop.Platform
runtime-version: '21.08'
sdk: org.freedesktop.Sdk
  - --socket=pcsc
  - name: pcsc-lite
      - --disable-libudev
      - --disable-libsystemd
      - --without-systemdsystemunitdir
      - --disable-serial
      - --disable-usb
      - --disable-documentation
      - '/include'
      - '/bin/pcsc-spy'
      - '/lib/libpcscspy*'
      - '/lib/pkg-config'
      - '/share/doc'
      - '/share/man'
      - rm /app/sbin/pcscd
      - rmdir /app/sbin || true
      - type: archive
        sha256: 9ee3f9b333537562177893559ad4f7b8d5c23ebe828eef53056c02db14049d08
  - name: pcsc-tools
      - '/bin/gscriptor'
      - '/bin/scriptor'
      - '/bin/ATR_analysis'
      - '/share/pcsc'
      - '/share/man'
      - type: archive
        sha256: 651c8dd74bcb33db4c16935ce5d80dd1aa6eb20ba9d5c4b9631a098326ef8b9f
  - name:
    buildsystem: simple
      - install -D /app/bin/
      - type: file



By default pscs_scan calls ATR_analysis which is a Perl script. I do not want to include Perl in my sandbox so I create a wrapper to call pcsc_scan with the -n argument to disable the use of ATR_analysis.

pcsc_scan -n


$ flatpak-builder --user --install build-dir fr.apdu.pcsc_scan.yml


$ flatpak run fr.apdu.pcsc_scan 
Using reader plug'n play mechanism
Scanning present readers...
0: Gemalto PC Twin Reader 00 00
Fri Feb 11 17:55:17 2022
 Reader 0: Gemalto PC Twin Reader 00 00
  Event number: 6
  Card state: Card inserted, Shared Mode, 
  ATR: 3B A7 00 40 18 80 65 A2 08 01 01 52

It works fine. Youpi!


You need to use the same protocol version for the pcsc-lite daemon and the pcsc-lite client.

If not then pcscd will complain with something like:

Journalctl :
Jan 16 16:24:42 nuc01.lan pcscd[2066]: 99999999 winscard_svc.c:383:ContextThread() Client protocol is 4:4
Jan 16 16:24:42 nuc01.lan pcscd[2066]: 00000040 winscard_svc.c:385:ContextThread() Server protocol is 4:3

The protocol version major & minor is defined in winscard_msg.h.

Protocol history

  • 4.4 since pcsc-lite 1.8.24, Oct 2018
  • 4.3 since pcsc-lite 1.8.9, Oct 2013
  • 4.2 since pcsc-lite 1.6.5, Dec 2010
  • 4.1 since pcsc-lite 1.6.5, Dec 2010
  • 4.0 since pcsc-lite 1.6.0, May 2010

So if the server side is older than 1.8.24 (Oct 2018) and the client side is newer you have a problem.

For example Ubuntu 18.04 LTS provides pcscd 1.8.23-1. This can be problematic.

Reproducing the problem

To check that I modified the file fr.apdu.pcsc_scan.yml to build pcsc-lite 1.8.23 instead of the latest version 1.9.5.

The build is successful but the execution fails with:

$ flatpak run fr.apdu.pcsc_scan
SCardEstablishContext: Service was stopped.

And in the logs on the host I see:

$ journalctl --unit=pcscd
févr. 11 18:55:07 debian pcscd[3715]: 00000006 winscard_svc.c:361:ContextThread() Received command: CMD_VERSION from client 8
févr. 11 18:55:07 debian pcscd[3715]: 00000004 winscard_svc.c:373:ContextThread() Client is protocol version 4:3
févr. 11 18:55:07 debian pcscd[3715]: 00000001 winscard_svc.c:382:ContextThread() Communication protocol mismatch!
févr. 11 18:55:07 debian pcscd[3715]: 00000002 winscard_svc.c:384:ContextThread() Client protocol is 4:3
févr. 11 18:55:07 debian pcscd[3715]: 00000001 winscard_svc.c:386:ContextThread() Server protocol is 4:4
févr. 11 18:55:07 debian pcscd[3715]: 00000002 winscard_svc.c:396:ContextThread() CMD_VERSION rv=0x8010001E for client 8

Here the server is using version 4.4 but the client is using version 4.3.
The error code 0x8010001E is SCARD_E_SERVICE_STOPPED.


The solution is simple: use the same protocol version on both sides.

If your host is using an old pcsc-lite using the internal protocol 4.3 then include an old (between 1.8.9 and 1.8.23) pcsc-lite in your flatpak image.

I know this is not perfect. It is then not possible to provide an application in one flatpak and deploy it everywhere and anywhere.


The protocol between the daemon and the client is internal to pcsc-lite. It has not been designed to be interoperable with something else, including older versions of pcsc-lite itself.

pcsc-lite is free software. So you are free to install whatever version you want.