Thursday, December 31, 2020

New PyKCS11 1.5.10 available

I just released a new version of PyKCS11, a Python wrapper above the PKCS#11 API.
See "PyKCS11 introduction" or "PyKCS11’s documentation".

The project is registered at Pypi: 


1.5.10 - December 2020, Ludovic Rousseau
  • Add CKH_* constants
  • CKA_HW_FEATURE_TYPE artibute value is a number
  • Makefile: use python3 by default
  • minor improvements

Wednesday, December 16, 2020

PKCS#11 support in socat


socat - Multipurpose relay is described upstream as:
"netcat++" (extended design, new implementation)
AIX, BSD, HP-UX, Linux, Solaris e.a. (UNIX)
tar x...; ./configure; make; make install
README; socat.html, socat.1;
command line
socat TCP6-LISTEN:8080,reuseaddr,fork
tcp, udp, ipv6, raw ip, unix-socket, pty, pipe, listen, socks4, socks4a, proxy-connect, ssl-client, filedescriptor, readline, stdio, exec, system, file, open, tail -f, termios, setsockopt, chroot, fork, perm, owner, trace, dump, dgram, ext3, resolver, datagram, multicast, broadcast, interface, socket, sctp, generic, ioctl

The main idea of socat is to make a network connection between 2 hosts. It is possible to use a TLS connection. socat can use a private key stored in a file on disk. But it was not possible to use PKCS#11 as the cryptographic engine.

The benefit of using a PKCS#11 engine is that any PKCS#11 library can be used. So, of course, in my case the PKCS#11 library will be to use a smart card. So the private key will be inside a smart card and will stay protected inside the smart card.

My patch

socat already uses OpenSSL to process the private key.

OpenSSL already supports PKCS#11 through an "engine" mechanism.

It was rather easy to add support of OpenSSL engines in socat. I just replaced a call to SSL_CTX_use_PrivateKey_file() by a call to ENGINE_load_private_key() with the correct engine initialisation.
If the private key "filename" starts with "pkcs11:" then this is not a filename but a PKCS#11 URI scheme (defined in RFC-7512) already understood by OpenSSL pkcs11 engine.

The socat argument is then something like "key=pkcs11:id=%56%78;pin-value=1234"

diff --git a/sslcls.c b/sslcls.c
index f9ce389..ddcefd7 100644
--- a/sslcls.c
+++ b/sslcls.c
@@ -21,6 +21,8 @@
 #include "sysutils.h"
 #include "sycls.h"
+#include <openssl/engine.h>
 void sycSSL_load_error_strings(void) {
@@ -214,10 +216,76 @@ int sycSSL_CTX_use_certificate_chain_file(SSL_CTX *ctx, const char *file) {
    return result;
+static void display_openssl_errors(int l)
+   const char *file;
+   char buf[120];
+   int e, line;
+   if (ERR_peek_error() == 0)
+       return;
+   Error2("At %s:%d:\n", __FILE__, l);
+   while ((e = ERR_get_error_line(&file, &line))) {
+       ERR_error_string(e, buf);
+       Error3("- SSL %s: %s:%d\n", buf, file, line);
+   }
 int sycSSL_CTX_use_PrivateKey_file(SSL_CTX *ctx, const char *file, int type) {
    int result;
    Debug3("SSL_CTX_use_PrivateKey_file(%p, \"%s\", %d)", ctx, file, type);
-   result = SSL_CTX_use_PrivateKey_file(ctx, file, type);
+   if (0 == strncmp(file, "pkcs11:", 7))
+   {
+      /* Starts with "pkcs11:" -> use pkcs11 OpenSSL engine */
+      /* See RFC-7512: The PKCS #11 URI Scheme */
+      const char *privkey = file;
+      ENGINE *engine;
+      EVP_PKEY *pkey;
+      result = -1; /* error by default */
+      ENGINE_add_conf_module();
+      ENGINE_load_builtin_engines();
+      engine = ENGINE_by_id("pkcs11");
+      if (engine == NULL) {
+          Error("Could not get engine\n");
+          display_openssl_errors(__LINE__);
+          goto end;
+      }
+#if 0
+      if (!ENGINE_ctrl_cmd_string(engine, "VERBOSE", NULL, 0)) {
+          display_openssl_errors(__LINE__);
+          goto end;
+      }
+      if (!ENGINE_init(engine)) {
+          Error("Could not initialize engine\n");
+          display_openssl_errors(__LINE__);
+          goto end;
+      }
+      pkey = ENGINE_load_private_key(engine, privkey, 0, 0);
+      if (pkey == NULL) {
+          printf("Could not load key\n");
+          display_openssl_errors(__LINE__);
+          goto end;
+      }
+      else
+          result = 1;
+      ENGINE_finish(engine);
+   }
+   else
+      result = SSL_CTX_use_PrivateKey_file(ctx, file, type);
    Debug1("SSL_CTX_use_PrivateKey_file() -> %d", result);
    return result;


You need to have a certificate. For the example I will use OpenSSL to generate a self-signed certificate for the client but you can also use your own certification authority.

See socat documentation "Securing Traffic Between two Socat Instances Using SSL" for details.

Client side

Generate an RSA key pair:
openssl genrsa -out client.key 2048

Generate a self-signed certificate:
openssl req -new -key client.key -x509 -days 365 -out client.pem

Define some shell variables:

Install the SoftHSM software PKCS#11 lib:

On Debian it is the softhsm2 package.
Of course you can use any PKCS#11 library and use a real smart card. But for now we will use a software only PKCS#11 lib for ease of use.

Create a new SoftHSM token
softhsm2-util --init-token --label "A token" \
    --pin $PIN --so-pin 123456 \
    --slot $INDEX

Install OpenSC to get pkcs11-tool command:
On Debian it is the opensc package.

Import the certificate:
pkcs11-tool --module /usr/lib/softhsm/  \
    --slot-index $INDEX --label "Certificate" \
    --write-object client.pem --type cert --id $ID

Import the private key:
pkcs11-tool --module /usr/lib/softhsm/ \
    --slot-index $INDEX --label "Private key" \
    --write-object client.key --type privkey --id $ID --pin $PIN

List the imported objects:
pkcs11-tool --module /usr/lib/softhsm/ \
    --list-objects --pin $PIN
We get:
Using slot 0 with a present token (0x3a608bb2)
Private Key Object; RSA 
  label:      Private key
  ID:         abcdef
  Usage:      decrypt, sign, unwrap
  Access:     sensitive
Certificate Object; type = X.509 cert
  label:      Certificate
  subject:    DN: C=FR, ST=Some-State, L=Paris, O=Ludovic Rousseau blog,
  ID:         abcdef

Delete the client private key since the key is now in the PKCS#11 token:
rm client.key

Install the OpenSSL PKCS#11 engine:
On Debian it is the package libengine-pkcs11-openssl that provides the file /usr/lib/x86_64-linux-gnu/engines-1.1/ (on a x86_64 architecture).

Server side

Generate an RSA key pair:
openssl genrsa -out server.key 2048

Generate a self-signed certificate:
openssl req -new -key server.key -x509 -days 365 -out server.pem

Copy the client certificate file client.pem to the server, and the server certificate file server.pem to the client.

Run the socat server:
socat openssl-listen:4433,reuseaddr,cert=server.pem,cafile=client.pem,key=server.key -

Client side

Configure the OpenSSL engine:

Create a file named engine.conf and containing:

openssl_conf = openssl_init

engines = engine_section

pkcs11 = pkcs11_section

engine_id = pkcs11
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-1.1/
MODULE_PATH = /usr/lib/softhsm/
init = 0

Define and export OPENSSL_CONF environment variable:

export OPENSSL_CONF=engine.conf

Run the client:
socat - ',cafile=server.pem,cert=client.pem,verify=1,key=pkcs11:id=%AB%CD%EF;pin-value=1234;token=A%20token'

Note the key=pkcs11:id=%AB%CD%EF;pin-value=1234 arguments.


On the client I get:

2020/12/16 22:12:51 socat[6335] E SSL_connect(): error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

On the server I get:

2020/12/16 22:12:52 socat[31137] E SSL_accept(): error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate

I have a problem with my self signed certificates. I searched for a few hours but without finding the solution.

Plan B: disable certificate checks

To make the server accept the client connection I have to add the socat argument verify=0 on the server side.

socat openssl-listen:4433,reuseaddr,cert=server.pem,cafile=client.pem,key=server.key,verify=0 -

Now the connection works fine in both direction. It is a bad solution. Don't do that on a production server.

Upstream integration

I sent my patch to the upstream maintainer, Gerhard Rieger, in Feb 2020. Gerhard will review the patch and give it a try.


I have no news from the socat maintainer since Feb 2020. So I decided to write my blog article even if my patch has not been reviewed and accepted or rejected.

May my patch help you secure a socat connection with your smart card (or another PKCS#11 token).

Sunday, November 15, 2020

macOS Big Sur and smart cards status

macOS Big Sur (macOS 11.0) is now available since November, 2020.


A tokend is a piece of software used to bridge a cryptographic device (like a smart card) and the CDSA (Common Data Security Architecture) architecture.

Since macOS Lion (10.7 in 2011) the CDSA/tokend technology is deprecated. See "Mac OS X Lion and tokend".

tokend was disabled by default in Catalina but it was still possible to enable it again.

With macOS Big Sur tokend is now completely removed. The manpage SmartCardServices-legacy(7) is also no more present.


Since Yosemite (macOS 10.10 in 2014) the PC/SC layer is no more a fork of pcsc-lite. So comparing versions with pcsc-lite is useless.
% cat /System/Library/Frameworks/PCSC.framework/Versions/A/Resources/version.plist
version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ""> <plist version="1.0"> <dict> <key>BuildAliasOf</key> <string>CryptoTokenKit</string> <key>BuildVersion</key> <string>25</string> <key>CFBundleShortVersionString</key> <string>8.0</string> <key>CFBundleVersion</key> <string>1</string> <key>ProjectName</key> <string>SmartCardServices</string> <key>SourceVersion</key> <string>487040010000000</string> </dict> </plist>
The CFBundleShortVersionString is still 8.0 as for Mojave and Catalina. The SourceVersion changed from 408011002000000 to 487040010000000. But I have no idea what that means :-).
I have not yet made many tests of the PC/SC layer. So far it works fine.

Crypto Token Kit

CryptoTokenKit is the native smart card API since the complete rewrite in macOS Yosemite 10.10 (OS X Yosemite BETA and smart cards status).

The directory /System/Library/Frameworks/CryptoTokenKit.framework/CryptoTokenKit/ changed a bit between Catalina and Big Sur. For example the file CryptoTokenKit is no more present.

I tried my Objective-C sample and the code still works fine (as expected) even if the binary is now linked to a non-existent library file.
% otool -L ./
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1673.126.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0)
	/System/Library/Frameworks/CryptoTokenKit.framework/Versions/A/CryptoTokenKit (compatibility version 1.0.0, current version 1.0.0)
% ls /System/Library/Frameworks/CryptoTokenKit.framework/Versions/A/CryptoTokenKit
ls: /System/Library/Frameworks/CryptoTokenKit.framework/Versions/A/CryptoTokenKit: No such file or directory


% grep -A 1 CFBundleShortVersionString /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist
Apple updated the CCID driver from version 1.4.31 in Catalina to 1.4.32 in Big Sur.

Version 1.4.32 is not the latest version available. I released this version on April, 22th 2020.
The latest version (for now) of the CCID driver is 1.4.33 released on June 25th, 2020. 

Apple Silicon

macOS Big Sur is also the operating system for the new Apple computers using the Apple Silicon CPU (an ARM based CPU). The binaries provided with macOS Big Sur are now also compiled for ARM.

For example with the CCID driver:
% cd /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS/
% file libccid.dylib 
libccid.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64e:Mach-O 64-bit dynamically linked shared library arm64e]
libccid.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
libccid.dylib (for architecture arm64e):	Mach-O 64-bit dynamically linked shared library arm64e
My CCID driver works fine with GNU/Linux on a RaspberryPi with an ARM CPU. So it is not surprising that it works also fine with an Apple Silicon CPU.

When Apple will publish the patches they made to Free Software programs used in Big Sur at we will see if some modifications were needed.


No big changes in Big Sur for the smart card world.

Monday, November 2, 2020

How to get smart card support

I, more and more, receive direct emails asking for help about a general question about smart cards.


Free support

It is OK to send me an email or create a github, salsa, etc. ticket if you find a bug in a software I maintain. But it is, in general, not OK to contact me directly because you have a problem with your smart card project.

I do provide Free Software (as in free speech), not free support (as in free beer). If you really want support from me then contact me, we can agree on something.

pcsclite-muscle mailing list

For community support you should use the pcsclite-muscle mailing list. You can register to the list at and access to the archives at

On the mailing list you will find many smart card experts. Some of them know much more about some smart card details than me. Most of the time I will answer your question. But some other people may have a better/different answer.

One major benefit of using a public mailing list is that you can find answers about already known problems in the mailing list archives. So the more users use the mailing list the richer the archives will be.


Mailing list success

Since 2009 I publish the mailing list statistics for the previous year. For example read "MUSCLE mailing list statistics for 2019".

The number of messages on the list is declining. In part because people use other ways to get answers: direct email to me, github issues, etc.


Email is an old technology. Mailing list is an old technology. You have to fight against spam, etc.

But I think it is a nice way to get free support.

Tuesday, October 20, 2020

Unhappy user

 I just received this email:

Subject: I have a question with your library

Your library is garbage.  

It's too unstable, sometimes it works, sometimes it doesn't.
 Why do you publicize your library, as if it really works?

I've just wasted time configuring, fixing bugs, reading your old recommendations.

This is horrible. The version of pcsc lite has failed, I have sometimes failed to read nfc or newly released readers. Even your makefile for C fails. It is impossible to maintain your library. Sometimes it has worked, but I restart the pc and it no longer works. It's terrible.

 I just wasted my time with your library trash.  

First I thought it was just a spam. But then it talks about pcsc-lite so it must really be for me.

I don't find any question in the text. I also do not find any specific issue or problem to fix.

It is strange to take the time to write such an email. I think that is the first time I receive this kind of email.

I do not include the author name or email address. But if you (the author of the email) read this I propose you to join the pcsclite-muscle mailing list and report your problems there. I am sure someone can help you.

Sunday, October 18, 2020

sysmoOCTSIM: 8 slots reader

Sysmocom designed and sells a smart card reader with 8 slots for SIM sized cards (2FF form factor). It is the sysmoOCTSIM



I received such a reader a few days ago (thanks Harald W.). In my case the reader has a nice aluminium casing to protect the electronic.

I added the reader in my list at: sysmocom_sysmoOCTSIM.


8 slots

The reader has 8 slots. From the CCID USB descriptor:

  bMaxSlotIndex: 0x07

The index starts at 0 so a maximum of 7 indicates 8 slots.


And it declares that it can support 8 slots busy at the same time.

  bMaxCCIDBusySlots: 8

So it is possible to use the 8 slots at the same time.

This device is the only one to have 8 slots in my list:

You can also display the reader list sorted by bMaxSlotIndex field to easily see the other readers that have more than 1 slot.


Free Software Firmware

The reader firmware is free software (or open source if you prefer this denomination). The license is GNU GPL 2 or a later version.

The git repository is
The bug tracker is

The only other free software CCID firmware I know of is Tian Tian Xiang Shang used in the GnuK project (An Implementation of USB Cryptographic Token for GnuPG).

CCID driver limitation

My CCID driver does support multi-slots readers since version 0.9.2 released in 2004.

But the driver is limited because it does not support using the slots at the same time, even if the reader declares it supports it.

pcsc-lite has support for simultaneous multi-slot. But the driver tells pcsc-lite that simultaneous multi-slot is not supported. See this code:

Of course I tried to modify the code of the CCID driver to tell pcsc-lite that simultaneous multi-slot can be used. But then the driver is confused by mixed USB frames. I then remembered why this support was disabled.



Adding support of simultaneous multi-slots is possible. That will require some work on the CCID driver.

If you want or plan to use such a reader with pcsc-lite on GNU/Linux or another Unix system then contact me so we can discuss what you can do.


I sometimes receive requests about configurations with a lot of smart card readers. Using an 8 slots reader can be part of the solution. This reader requires the use of only one USB port and has its own power supply unit.

The reader firmware is Free Software and I like that. It can only be a good point in the selection of a smart card reader.

Friday, October 16, 2020

GitHub Sponsors: US$ 20 per month

Since January 2020 I participate in the GitHub Sponsors. See my post "GitHub Sponsors".

I received the first payment in May 2020. See "GitHub Sponsors: first payment".

You can see my public GitHub sponsor page at "Become a sponsor to LudovicRousseau".

New sponsor

I now have a new sponsor at $10 per month. That will double my Sponsors revenue. Yeah!
Thanks a lot to the existing 6 sponsors. You are wonderful.

I added a new tier at $20/month in case someone want to be even more generous.


It is also possible to send me bitcoins. See "How to help my projects? Send me bitcoins!".

Someone sent me some BTC cents (or micro cents) just a few days ago. Thanks to you anonymous.


I plan to make a status in next January for the 1st anniversary of my participation to the GitHub Sponsors program.

Wednesday, September 16, 2020

PySCard 2.0.0 released

 I just released a new version 2.0.0 of pyscard. PySCard is a python module adding smart cards support (PC/SC) to Python.

The version is 2.0.0 because after 1.9.9 I had not so many choices. This version does not bring any new feature. It is a bug fix release.

The PySCard project is available at:


2.0.0 (September 2020)

  • SCardStatus(): Fix a crash in case of PC/SC error
  • toASCIIString(): replace non-ASCII characters by '.'
  • remove i386 (32-bits) support on macOS

Friday, July 31, 2020

New PyKCS11 1.5.9 available

I just released a new version of PyKCS11, a Python wrapper above the PKCS#11 API.
See "PyKCS11 introduction" or "PyKCS11’s documentation".

The project is registered at Pypi:


1.5.9 - July 2020, Ludovic Rousseau
  • call C_GetSlotList() with a NULL parameter to correctly initialize some PKCS#11 lib conforming to PKCS#11 version 2.40.

Thursday, July 30, 2020

Smart card and blockchain?

I received my first ATR description containing the word "blockchain". It is for ATR 3B 89 80 01 66 49 46 58 42 53 32 47 6F 32.

The card description is "Blockchain Security 2Go (JavaCard)" and refer to "Infineon's Blockchain Security 2Go Starter Kit".

The license of the github project is MIT License but the project does not contain any source code. So I am not sure what this github project is about.

Note: I do not have such a smart card. So I can't write much more about this card and project.

Tuesday, July 7, 2020

Smart card Usage in Debian: applications

The last layer above the smart card reader driver, the PC/SC resource manager and the middleware are user applications.

I updated the list when writing this blog article. New Debian packages have been added, and others have been removed.

ausweisapp2: Official authentication app for German ID cards and residence permits

cardpeek: Tool to read the contents of ISO7816 smartcards

connman-gtk: fully-featured GUI for ConnMan with systray support

entropybroker: infrastructure for distributing random numbers (entropy data)

gnokii-cli: Datasuite for mobile phone management (console interface)

gnokii-smsd: SMS Daemon for mobile phones

gnome-boxes: Simple GNOME app to access remote or virtual systems

gnome-phone-manager: control aspects of your mobile phone from your GNOME 2 desktop

gnupg: GNU privacy guard - a free PGP replacement

golang-pault-go-ykpiv-dev: high level cgo wrapper around

network-manager-openconnect: network management framework (OpenConnect plugin core)

network-manager-openconnect-gnome: network management framework (OpenConnect plugin GNOME GUI)

nitrokey-app: Application to manage the Nitrokey

openconnect: open client for Cisco AnyConnect, Pulse, GlobalProtect VPN

opensc: Smart card utilities with support for PKCS#15 compatible cards

pcsc-tools: Some tools to use with smart cards and PC/SC

plasma-nm: Plasma5 networkmanager library.

python3-yubikey-manager: Python 3 library for configuring a YubiKey

qemu-system-arm: QEMU full system emulation binaries (arm)

qemu-system-mips: QEMU full system emulation binaries (mips)

qemu-system-misc: QEMU full system emulation binaries (miscellaneous)

qemu-system-ppc: QEMU full system emulation binaries (ppc)

qemu-system-sparc: QEMU full system emulation binaries (sparc)

qemu-system-x86: QEMU full system emulation binaries (x86)

rdesktop: RDP client for Windows NT/2000 Terminal Server and Windows Servers

spice-client-gtk: Simple clients for interacting with SPICE servers

srsue: User Equipment implementation for LTE

virt-viewer: Displaying the graphical console of a virtual machine

vinagre: remote desktop client for the GNOME Desktop

wpasupplicant: client support for WPA and WPA2 (IEEE 802.11i)

x2gothinclient-chroot: Install X2Go Thin Client chroot (metapackage)

xgnokii: Datasuite for mobile phone management (X interface)

ykcs11: PKCS#11 module for the YubiKey PIV applet

yubico-piv-tool: Command line tool for the YubiKey PIV applet

yubikey-manager: Python library and command line tool for configuring a YubiKey

yubioath-desktop: Graphical interface for displaying OATH codes with a Yubikey


Package # of installation % of Debian systems
gnupg18985396,29 %
wpasupplicant10066651,06 %
vinagre4942425,07 %
opensc2433612,34 %
qemu-system-x86182929,28 %
plasma-nm174978,87 %
rdesktop105755,36 %
virt-viewer96384,89 %
qemu-system-arm47082,39 %
qemu-system-ppc40992,08 %
qemu-system-mips40962,08 %
qemu-system-misc40702,06 %
qemu-system-sparc40072,03 %
openconnect36791,87 %
network-manager-openconnect24571,25 %
network-manager-openconnect-gnome18320,93 %
pcsc-tools17430,88 %
gnome-boxes14460,73 %
spice-client-gtk7910,40 %
python3-yubikey-manager3380,17 %
xgnokii3190,16 %
yubikey-manager2980,15 %
gnokii-cli2880,15 %
cardpeek1760,09 %
yubico-piv-tool1650,08 %
gnome-phone-manager1550,08 %
yubioath-desktop1150,06 %
nitrokey-app1030,05 %
connman-gtk730,04 %
ausweisapp2690,03 %
gnokii-smsd470,02 %
ykcs11360,02 %
entropybroker190,01 %
srsue20,00 %
golang-pault-go-ykpiv-dev10,00 %
x2gothinclient-chroot00,00 %


The first real smart card application with the most installations is OpenSC with 12% of Debian systems. Hello and well done to my OpenSC developers collegues.

The use of smart card is not developed. Maybe it is more deployed in enterprises since "many" business laptops have an integrated smart card reader. So there must be market and customer demand for these configurations. But maybe also these enterprises systems do not have the popularity-contest package installed so are not visible in the statistics here.

Smart card Usage in Debian: middleware

See "Smart card Usage in Debian: pcscd and drivers" for the previous article.

The next layer above the smart card reader driver and PC/SC resource manager are middleware. These software are between PC/SC and the user application.

I updated the list when writing this blog article. New Debian packages have been added, and others have been removed.

cackey: CAC and PIV Smartcard PKCS #11 cryptographic module

coolkey: Smart Card PKCS #11 cryptographic module

libckyapplet1: Smart Card Coolkey applet

libckyapplet1 is a dependency of coolkey. So they are both installed at the same time.

libckyapplet1-dev: Smart Card Coolkey applet development files

libcacard0: Virtual Common Access Card (CAC) Emulator (runtime library)

libcacard0 is a dependency of all the qemu-system-* packages. That can explain why this package is installed in so much systems.

libcacard-dev: Virtual Common Access Card (CAC) Emulator (development files)

libchipcard6: library for accessing smartcards

libchipcard-data: configuration files for libchipcard

libchipcard-dev: API for smartcard readers

libchipcard-tools: tools for accessing chipcards

libengine-pkcs11-openssl: OpenSSL engine for PKCS#11 modules

libgnokii7: Gnokii mobile phone interface library

libopenconnect5: open client for Cisco AnyConnect, Pulse, GlobalProtect VPN - shared library

libopenconnect5 is a dependency of plasma-nm (Plasma5 networkmanager library). Plasma is the KDE graphical workspaces environment.

libosmosim0: Osmo SIM library

Part of libosmocore: Open Source MObile COMmunications CORE library (metapackage)

libpam-p11: PAM module for using PKCS#11 smart cards

Part of pam-p11: PAM module for using PKCS#11 smart cards

libpam-pkcs11: Fully featured PAM module for using PKCS#11 smart cards

libpam-poldi: PAM module allowing authentication using a OpenPGP smartcard

libpcscada0.7.5: Ada bindings to PC/SC middleware

libspice-client-glib-2.0-8: GObject for communicating with Spice servers (runtime library)

libspice-client-glib-2.0-8 is a dependency of vinagre: remote desktop client for the GNOME Desktop

libspice-client-gtk-3.0-5: GTK3 widget for SPICE clients (runtime library)

libspice-client-gtk-3.0-5 is also a dependency of vinagre: remote desktop client for the GNOME Desktop

libykpiv1: Library for communication with the YubiKey PIV smartcard

openjdk-8-jre-headless: OpenJDK Java runtime, using Hotspot JIT (headless)

openjdk-11-jre-headless: OpenJDK Java runtime, using Hotspot JIT (headless)

We can see that openjdk-8-jre-headless has been replaced by openjdk-11-jre-headless.

openjdk-13-jre-headless: OpenJDK Java runtime, using Hotspot JIT (headless)

openjdk-13-jre-headless is not yet in Debian stable. So the number of installation is low. This version is also replaced by openjdk-14-jre-headless since 2020.

openjdk-14-jre-headless: OpenJDK Java runtime, using Hotspot JIT (headless)

openjdk-15-jre-headless: OpenJDK Java runtime, using Hotspot JIT (headless)

openjdk-15-jre-headless is very new. It is in Debian unstable but has not yet migrated to Debian testing. So the number of installation is very low.

opensc-pkcs11: Smart card utilities with support for PKCS#15 compatible cards

python3-pykcs11: PKCS#11 wrapper for Python

python3-pyscard: Python3 wrapper above PC/SC API

python3-pyscard is a dependency of python3-yubikey-manager. Users are installing this package not because they love this software (I am the upstream maintainer) but because they use a yubikey.


Package # of installation % of Debian systems
libcacard05487827,83 %
libspice-client-glib-2.0-85393527,35 %
openjdk-11-jre-headless5145526,10 %
libspice-client-gtk-3.0-54902924,87 %
openjdk-8-jre-headless4292121,77 %
opensc-pkcs112437512,36 %
libopenconnect5190349,65 %
python3-pyscard3690,19 %
openjdk-14-jre-headless3400,17 %
libengine-pkcs11-openssl3120,16 %
openjdk-13-jre-headless3000,15 %
libchipcard-data1990,10 %
libckyapplet11930,10 %
coolkey1900,10 %
libchipcard61820,09 %
libykpiv11780,09 %
libcacard-dev1350,07 %
libchipcard-tools1310,07 %
libpam-pkcs11900,05 %
openjdk-15-jre-headless780,04 %
libpam-poldi390,02 %
libpam-p11330,02 %
libosmosim0290,01 %
python3-pykcs11190,01 %
libchipcard-dev180,01 %
cackey120,01 %
libckyapplet1-dev30,00 %
libpcscada0.7.530,00 %
libgnokii720,00 %


Many (all?) smartcard middleware packages with an important installation base are not installed for themselves but because they are a dependency of another package.

So users are installing packages with smart card features or services but without any need or use of the smart card features.
It is not a problem. It is how dependencies works.