Sunday, January 24, 2021

New version of libccid: 1.4.34

I just released version 1.4.34 of libccid the Free Software CCID class smart card reader driver.

Changes

1.4.34 - 24 January 2021, Ludovic Rousseau
  • Add support of
    • ACS ACR1252IMP Reader
    • ACS CryptoMate EVO
    • Aktiv Rutoken SCR 3001 Reader
    • Avtor KP-375BLE
    • Avtor SC Reader KP382
    • BIT4ID mLector AIR DI V3
    • BIT4ID miniLector AIR NFC v3
    • Bit4id Digital-DNA Key (ProductID 0x2354)
    • Canokeys Canokey
    • DESKO GmbH IDenty chrom
    • DESKO GmbH PENTA Scanner
    • FT Biopass CCID
    • FT Biopass FIDO2
    • FT Biopass KB CCID
    • FT Biopass KB FIDO CCID
    • Feitian BLE CCID Dongle
    • Feitian R805
    • Feitian vR504 Contactless Reader
    • GoTrust Idem Key
    • Identiv uTrust 3720 Contactless Reader
    • Sunrex HP USB Business Slim Smartcard CCID Keyboard
    • sysmocom - s.f.m.c. GmbH sysmoOCTSIM
  • Fail if the requested protocol is not supported by reader
  • Disable USB suspend for the AlcorMicro AU9520 reader
  • Return "no smart card" if we get notified during a transmit
  • Minor improvements reported by Maksim Ivanov
  • Some other minor improvements

Wednesday, January 13, 2021

macOS Big Sur and smart card source code

Apple released the source code of the open source components they use in Big Sur (macOS 11.0, released in October 2020). The components are available at macOS X 11.0.1 Source.


SmartcardCCID

The SmartcardCCID component moved from version SmartcardCCID-55018.0.2 in Catalina 10.15.0 to SmartcardCCID-55021.40.1 in Big Sur 11.0.1.

Incomplete diff:

diff -ru SmartcardCCID-55018.0.2/SmartcardCCID.plist SmartcardCCID-55021.40.1/SmartcardCCID.plist
--- SmartcardCCID-55018.0.2/SmartcardCCID.plist	2019-08-21 00:16:22.000000000 +0200
+++ SmartcardCCID-55021.40.1/SmartcardCCID.plist	2020-04-28 20:53:09.000000000 +0200
@@ -6,13 +6,13 @@
 		<key>OpenSourceProject</key>
 		<string>ccid</string>
 		<key>OpenSourceVersion</key>
-		<string>1.4.31</string>
+		<string>1.4.32</string>
 		<key>OpenSourceWebsiteURL</key>
 		<string>https://ccid.apdu.fr</string>
 		<key>OpenSourceURL</key>
-		<string>https://ccid.apdu.fr/files/ccid-1.4.31.tar.bz2</string>
+		<string>https://ccid.apdu.fr/files/ccid-1.4.32.tar.bz2</string>
 		<key>OpenSourceImportDate</key>
-		<string>2019-08-20</string>
+		<string>2020-04-27</string>
 		<key>OpenSourceModifications</key>
 		<array>
 			<string>destDirFix.patch - makefile.in, customized destination directory</string>
diff -ru SmartcardCCID-55018.0.2/ccid/Makefile SmartcardCCID-55021.40.1/ccid/Makefile
--- SmartcardCCID-55018.0.2/ccid/Makefile	2019-08-21 00:16:21.000000000 +0200
+++ SmartcardCCID-55021.40.1/ccid/Makefile	2020-08-06 20:06:44.000000000 +0200
@@ -24,11 +24,12 @@
 	find $(DSTROOT)/ -name 'usb*.h' -exec rm \{\} \;
 	rm -r $(DSTROOT)/usr/include
 	rm -r $(DSTROOT)/usr/lib
-	install_name_tool -id $(CCIDDriversPath)$(CCIDdylib) $(DSTROOT)$(CCIDDriversPath)$(CCIDdylib) 
+	install_name_tool -id $(CCIDDriversPath)$(CCIDdylib) $(DSTROOT)$(CCIDDriversPath)$(CCIDdylib)
+	codesign -s - $(DSTROOT)$(CCIDDriversPath)$(CCIDdylib)
 
 # Automatic Extract & Patch
 AEP_Project    = ccid
-AEP_Version    = 1.4.31
+AEP_Version    = 1.4.32
 AEP_ProjVers   = $(AEP_Project)-$(AEP_Version)
 AEP_Filename   = $(AEP_ProjVers).tar.bz2
 AEP_ExtractDir = $(AEP_ProjVers)
[...]

As we already saw in macOS Big Sur and smart cards status the CCID driver was updated from version 1.4.31 to version 1.4.32. You can find the patches Apple applies to the CCID driver in the ccid/files/ directory. Nothing special to say.

In fact, after checking the different releases of Catalina 10.15.x in https://opensource.apple.com/ I found that the CCID driver was upgraded from 1.4.31 to 1.4.32 in Catalina itself from 10.15.5 to 10.15.6.

So Apple upgraded the CCID driver within the same major version version of macOS.
And they missed the opportunity to upgrade to 1.4.33 in Big Sur. Maybe it is planned for a future minor version upgrade of Big Sur?


libusb

SmartcardCCID includes the libusb component used by the CCID driver.

This libusb library is statically linked to the CCID driver and can't be used by another project.

The version is 1.0.9. This is a very old version of libusb that was released in April 2012. The current libusb version is 1.0.24 released in December 2020.

I guess Apple does not want to upgrade a component that works fine enough from them.


SecurityTokend

This component is the same as in Catalina. It is SecurityTokend-55113.

It is strange to still find a tokend related component. Tokend technology is deprecated since Mac OS X Lion in 2011 (Mac OS X Lion and tokend).

Tokend was disabled by default in Catalina but was still usable (macOS Catalina and smart cards status).

In Big Sur tokend are not usable at all.

This component SecurityTokend does not contain any tokend plugin. There were in the Tokend component, not SecurityTokend. This component generates two file: SecurityTokend.framework and libsecurity_tokend_client.a. I am not sure what they are used for.


Conclusion

Interesting parts of the smart card stack would be the CryptoTokenKit and WinSCard layers. But since Apple moved away from the Free Software project pcsc-lite in macOS Yosemite in 2014 (OS X Yosemite and smart cards status) these components are not open source.

Monday, January 4, 2021

MUSCLE mailing list statistics for 2020

As I did in 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 and 2019 I propose some statistics of the MUSCLE mailing list usage.

Evolution

YearTotal number of messages Progression
2009603
2010718+19 %
2011999+39 %
2012207-79 %
2013198-4 %
2014194-2 %
2014194-2 %
2015120-38 %
2016125+4 %
2017128+2 %
201866-51 %
201929-56 %
202076+162 %

Comments

A high increase in the number of messages. Maybe the mailing list is not dead after all.

Statistics from 3.1.2020 to 24.11.2020
for pcsclite-muscle@lists.infradead.org


People who have written most messages:

  Author  Msg  Percent 
1ludovic.rousseau@gmail.com36 47.37 %
2Marc.Kewitz.ext@rohde-schwarz.com4 5.26 %
3axel.braun@gmx.de4 5.26 %
4trenta.sis@gmail.com3 3.95 %
5emaxx@google.com3 3.95 %
6suffsuccotash@gmail.com3 3.95 %
7stephan.guilloux@crisalid.com3 3.95 %
8zeroconf@zeroconf.ee3 3.95 %
9thomas@schlenkhoff.me2 2.63 %
10izh1979@gmail.com2 2.63 %
11sebastien@lorquet.fr2 2.63 %
12gregor.waltz@raritan.com1 1.32 %
13gsvelto@mozilla.com1 1.32 %
14Gabriele Svelto1 1.32 %
15tristan.degroof@multiversum.broedersvanliefde.be1 1.32 %
16t-pcsc@girst.at1 1.32 %
17mstjohns@comcast.net1 1.32 %
18mauro@faresoftware.it1 1.32 %
19Axel.braun@gmx.de1 1.32 %
20godfreyhkchung@gmail.com1 1.32 %
21jonathan.verner@nexusgroup.com1 1.32 %
 other1 1.32 %

Best authors, by total size of their messages (w/o quoting):

  Author  KBytes 
1ludovic.rousseau@gmail.com1032.8
2stephan.guilloux@crisalid.com 38.4
3zeroconf@zeroconf.ee 31.9
4emaxx@google.com 31.7
5Marc.Kewitz.ext@rohde-schwarz.com 30.6
6sebastien@lorquet.fr 29.5
7izh1979@gmail.com 23.3
8suffsuccotash@gmail.com 17.2
9gsvelto@mozilla.com 13.6
10trenta.sis@gmail.com 12.4
11mstjohns@comcast.net 11.3
12axel.braun@gmx.de 10.8
13godfreyhkchung@gmail.com 10.0
14t-pcsc@girst.at 9.7
15Gabriele Svelto 8.2
16Axel.braun@gmx.de 4.1
17thomas@schlenkhoff.me 2.9
18tristan.degroof@multiversum.broedersvanliefde.be 2.7
19jonathan.verner@nexusgroup.com 2.0
20gregor.waltz@raritan.com 1.4
21mauro@faresoftware.it 1.1

Best authors, by average size of their message (w/o quoting):

  Author  bytes 
1ludovic.rousseau@gmail.com29376
2sebastien@lorquet.fr15120
3gsvelto@mozilla.com13970
4stephan.guilloux@crisalid.com13096
5izh1979@gmail.com11923
6mstjohns@comcast.net11535
7zeroconf@zeroconf.ee10893
8emaxx@google.com10814
9godfreyhkchung@gmail.com10216
10t-pcsc@girst.at9922
11Gabriele Svelto8439
12Marc.Kewitz.ext@rohde-schwarz.com7844
13suffsuccotash@gmail.com5869
14trenta.sis@gmail.com4218
15Axel.braun@gmx.de4210
16tristan.degroof@multiversum.broedersvanliefde.be2798
17axel.braun@gmx.de2753
18jonathan.verner@nexusgroup.com2032
19thomas@schlenkhoff.me1490
20gregor.waltz@raritan.com1462
21mauro@faresoftware.it1143

Table showing the most successful subjects:

  Subject  Msg  Percent 
1[Pcsclite-muscle] Workaround for missing suspend/resume9 11.84 %
2[Pcsclite-muscle] Different behaviour with Select MF on Omnikey7 9.21 %
3[Pcsclite-muscle] Alcor Micro AU9520 not recognized by libccid 1.4.317 9.21 %
4[Pcsclite-muscle] Fwd: dead lock caused by SCardReleaseContext4 5.26 %
5[Pcsclite-muscle] memory consumption3 3.95 %
6[Pcsclite-muscle] pcsc-lite release3 3.95 %
7[Pcsclite-muscle] Exclusive access mode to the smart card reader3 3.95 %
8[Pcsclite-muscle] Lenovo laptops, GNU/Linux and smart card readers?3 3.95 %
9[Pcsclite-muscle] Chrome gets stuck and firefox won't open3 3.95 %
10[Pcsclite-muscle] Confused about extended APDU support2 2.63 %
11Potential security issues in CCID2 2.63 %
12[Pcsclite-muscle] SCardConnect behavior with invalid contexts2 2.63 %
13[Pcsclite-muscle] Missing checks of ATRDecodeAtr returns2 2.63 %
14[Pcsclite-muscle] Race condition during readerstate update2 2.63 %
15[Newsletter] Re: [Pcsclite-muscle] Race condition during2 2.63 %
16[Pcsclite-muscle] Alcor Micro AU9520 not recognized by libccid2 2.63 %
17New version of pcsc-lite: 1.8.261 1.32 %
18[Pcsclite-muscle] Linux Kernel 5.5 / CCID / PCSCLITE change1 1.32 %
19[Pcsclite-muscle] pcsclite-muscle Digest, Vol 24, Issue 21 1.32 %
20[Pcsclite-muscle] [Question] How to read SCARD_READER_CAPABILITIES1 1.32 %
21[Pcsclite-muscle] multi threading from a single pcsc handle /1 1.32 %
22[Pcsclite-muscle] Interfacing 32 bit driver with 64 pcscd1 1.32 %
23Unicode characters in a reader name1 1.32 %
24New version of libccid: 1.4.331 1.32 %
25[Pcsclite-muscle] How to dectect card status?1 1.32 %
26[Pcsclite-muscle] Potential hang in SCardTransmit1 1.32 %
27[Pcsclite-muscle] Instances of Undefined behavior in CCID1 1.32 %
28Incomplete archive between May 2018 and June 20201 1.32 %
29Lenovo laptops, GNU/Linux and smart card readers?1 1.32 %
30[Pcsclite-muscle] Race condition during readerstate1 1.32 %
 other6 7.89 %

Most used email clients:

  Mailer  Msg  Percent 
1(unknown)66 86.84 %
2Mozilla/5.x5 6.58 %
3Evolution 3.36.5 (3.36.5-1.fc32) 3 3.95 %
4K-9 Mail for Android1 1.32 %
 other1 1.32 %

Table of maximal quoting:

  Author  Percent 
1mauro@faresoftware.it 19.95 %
2jonathan.verner@nexusgroup.com 19.71 %
3axel.braun@gmx.de 17.27 %
4Axel.braun@gmx.de 11.83 %
5t-pcsc@girst.at 11.03 %
6tristan.degroof@multiversum.broedersvanliefde.be 10.60 %
7suffsuccotash@gmail.com 9.36 %
8thomas@schlenkhoff.me 7.59 %
9gregor.waltz@raritan.com 6.58 %
10stephan.guilloux@crisalid.com 4.97 %
11ludovic.rousseau@gmail.com 3.57 %
12trenta.sis@gmail.com 3.04 %
13Marc.Kewitz.ext@rohde-schwarz.com 2.29 %
14zeroconf@zeroconf.ee 1.75 %
15godfreyhkchung@gmail.com 1.51 %
16gsvelto@mozilla.com 0.43 %
17emaxx@google.com 0.00 %
18izh1979@gmail.com 0.00 %
19sebastien@lorquet.fr 0.00 %
20Gabriele Svelto 0.00 %
21mstjohns@comcast.net 0.00 %
 average 3.59 %

Maximal quoting:

Author : ludovic.rousseau@gmail.com
Subject : [Pcsclite-muscle] Alcor Micro AU9520 not recognized by libccid 1.4.31
Date : Thu, 5 Nov 2020 14:43:12 +0100
Quote ratio: 62.97% / 18890 bytes

Longest message:

Author : ludovic.rousseau@gmail.com
Subject : [Pcsclite-muscle] Alcor Micro AU9520 not recognized by libccid 1.4.31
Date : Wed, 4 Nov 2020 22:37:47 +0100
Size : 729365 bytes

Most successful subject:

Subject : [Pcsclite-muscle] Workaround for missing suspend/resume
No. of msgs: 9
Total size : 90764 bytes

Final summary:

Total number of messages: 76
Total number of different authors: 21
Total number of different subjects: 35
Total size of messages (w/o headers): 1407974 bytes
Average size of a message: 18525 bytes

Sunday, January 3, 2021

Happy new year 2021

 Dear readers,

I wish you a happy new year for 2021.

In 2020 I published 43 articles on this blog (25 in 2019, 24 in 2018, 34 in 2017 and 49 in 2016 and 51 in 2015). It is a 72% increase compared to 2019.

Audience

The number of readers in 2020 is decreasing (-15%) compared to 2019.


We still have the same 5 top countries in the same order than in 2019. USA is first one by a large margin.

 

I have a lot of readers (40%) coming from a Windows operating system.

It is surprising because I do not have many articles specifically about Windows. But at the same time a lot of my source codes or projects are also working on Windows.


Most read articles

No real surprise here: macOS & smart card and sample codes in different programming languages.

At the 8th place we find the article "pcsc_scan on Windows" I wrote in 2017. This article was not in the top-10 last year.


Thank you

Thank you to you, readers.

This blog has no advertising. If you want to support me you can send me some bitcoins or become a github sponsor.

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: https://pypi.org/project/PyKCS11/ 
 

Changes

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

socat - Multipurpose relay is described upstream as:
Abstract
what:
"netcat++" (extended design, new implementation)
OS:
AIX, BSD, HP-UX, Linux, Solaris e.a. (UNIX)
lic:
GPL2
inst:
tar x...; ./configure; make; make install
doc:
README; socat.html, socat.1; xio.help
ui:
command line
exa:
socat TCP6-LISTEN:8080,reuseaddr,fork PROXY:proxy:www.domain.com:80
keyw:
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) {
    Debug("SSL_load_error_strings()");
    SSL_load_error_strings();
@@ -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;
+      }
+#endif
+
+      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;
+
+end:
+      ENGINE_finish(engine);
+   }
+   else
+      result = SSL_CTX_use_PrivateKey_file(ctx, file, type);
+
    Debug1("SSL_CTX_use_PrivateKey_file() -> %d", result);
    return result;
 }


Usage

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:
ID="ABCDEF"
INDEX=0
PIN=1234

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/libsofthsm2.so  \
    --slot-index $INDEX --label "Certificate" \
    --write-object client.pem --type cert --id $ID

Import the private key:
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so \
    --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/libsofthsm2.so \
    --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, CN=test.example.org/emailAddress=foo@example.org
  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/libpkcs11.so (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

[openssl_init]
engines = engine_section

[engine_section]
pkcs11 = pkcs11_section

[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-1.1/libpkcs11.so
MODULE_PATH = /usr/lib/softhsm/libsofthsm2.so
init = 0

Define and export OPENSSL_CONF environment variable:

export OPENSSL_CONF=engine.conf

Run the client:
socat - 'openssl-connect:www.example.com:4433,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.

Results

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.

Conclusion

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.


tokend

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.

PC/SC

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
<?xml
version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <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 ./blog.app/Contents/MacOS/blog
./blog.app/Contents/MacOS/blog:
	/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

CCID

% grep -A 1 CFBundleShortVersionString /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist
	<key>CFBundleShortVersionString</key>
	<string>1.4.32</string>
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 https://opensource.apple.com we will see if some modifications were needed.

Conclusion

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