New version of pcsc-lite: 1.8.20

I just released a new version of pcsc-lite 1.8.20.
pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

Changes:
1.8.20: Ludovic Rousseau
30 December 2016

• Fix a crash and potential security issue in pcscd

ATR statistics: TB2 - Global, deprecated

Article from the series "ATR statistics"

TB2 - Global, deprecated

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

From Wikipedia https://en.wikipedia.org/wiki/Answer_to_reset#Interface_byte_TB2

TB₂, if present, is global. The usage of TB₂ is deprecated since the 2006 edition of the standard, which prescribes that cards should not include TB₂ in the ATR, and readers shall ignore TB₂ if present.

In the 1997 edition of the standard, TB₂ (8th to 1st bit) encode PI2, which when in range 50..250 (other values being RFU) encode V_PP in increments of 0.1 V, and subsumes the coarser indication given by PI1 of TB₁. Refer to that section for why modern Smart Cards have no use of V_PP, and thus of TB₂.

Historical note: Provision for TB₂ did not exist in ISO/IEC 7816-3:1989, and was introduced because V_PP = 12.5 V became a popular value in EEPROM technology, replacing 25 V and 21 V.

TB2	#	%
	2070	99.90 %
0x3F	1	0.05 %
0x45	1	0.05 %

Only 2 cards use a TB₂ value.

• 3B FF 00 FF 81 31 00 45 65 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00
• TB₂= 0x45 Programming param PI2 (PI1 should be ignored): 69 (dV)
• This card also has TB₁ = 0xFF Programming Param P: 31 Volts, I: RFU 
• 3F FF 3F 3F 3F 3F 00 3F 3F FF 3F 3F 3F 3F 3F FF 3F FF 95 3F FF 95 3F FF
• TB₂ = 0x3F Programming param PI2 (PI1 should be ignored): 63 (dV)
• This card also has TB₁ = 0x3F Programming Param P: 31 Volts, I: 50 milliAmperes  

I agree these 2 ATRs are quiet unusual.

ATR statistics: TA2 - Global, specific mode byte

Article from the series "ATR statistics"

TA2 - Global, specific mode byte

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

From Wikipedia https://en.wikipedia.org/wiki/Answer_to_reset#Interface_byte_TA2

Interface byte TA₂, if present, is global, and is named the specific mode byte.

Presence of TA₂ commands that the reader use specific mode as defined by TA₂ and earlier global bytes, rather than negotiable mode when TA₂ is absent.

TA₂ encodes in its 4 low-order bits an integer T defining the protocol required by the card, in the convention used for TD₁ (EMV prescribes that a card which T encoded in TA₂ does not match that in TD₁ shall be rejected).

The 5th bit is 0 to encodes that the required ETU duration is F_i/D_i clock cycles as defined by TA₁ (or its default value if absent); or 1 to indicate that the ETU duration is implicitly known (by some convention, or setting of the reader; EMV prescribes that such card shall be rejected).

The 6th and 7th bit are reserved for future use; 0 indicates not used.

The 8th bit is 1 to indicate that the card is unable to change the negotiable/specific mode (that is, does not propose other settings); or 0 to indicate that card has that ability (perhaps after a warm ATR).

Historical note: Provision for specific mode did not exist in ISO/IEC 7816-3:1989. Back then, the interface character TA₂ had no particular name or function, and was specific (to the protocol introduced by TD₁). ISO/IEC 7816-3:1997 introduced the specific mode and the specific mode byte, with interim note helping cards with specific mode byte TA₂ in their ATR dealing with a reader that did not implement specific mode.

TA2	#	%
	1983	95.70 %
0x81	48	2.32 %
0x80	31	1.50 %
0x00	10	0.48 %

TA₂ is used by only 4.30% of cards. 95.70% of smart cards in my list have no TA₂ defined.

• 0x81 indicates "Protocol to be used in spec mode: T=1 - Unable to change - defined by interface bytes".
• The 4 low-order bits are set to 0001b so T=1 protocol.
• The 8th bit set to 1 to indicate unable to change the negotiable/specific mode
• 0x80 indicates "Protocol to be used in spec mode: T=0 - Unable to change - defined by interface bytes"
• The 4 low-order bits are set to 0000b so T=0 protocol.
• The 8th bit set to 1 to indicate unable to change the negotiable/specific mode
• 0x00 indicates "Protocol to be used in spec mode: T=0 - Capable to change - defined by interface bytes"
• The 4 low-order bits are set to 0000b so T=0 protocol.
• The 8th bit set to 0 to indicate the card is able to change the negotiable/specific mode

New version of pcsc-lite: 1.8.19

I just released a new version of pcsc-lite 1.8.19.
pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

Changes:
1.8.19: Ludovic Rousseau
9 December 2016

• SCardGetStatusChange(): Fix a (rare) race condition
• Doxygen:
• SCardGetStatusChange() may return SCARD_E_UNKNOWN_READER
• SCardConnect() and SCardReconnect() will never return SCARD_E_NOT_READY
• pcsc-spy:
• fix display of execution time
• log the thread number in the results
• Some other minor improvements

macOS Sierra and pam_smartcard

In Sierra a new smart card component has been introduced: pam_smartcard. PAM is Pluggable Authentication Modules.

The source code is available at macOS 10.12 Source and is part of the pam_modules component.

pam_smartcard

The pam_smartcard(8) manage is:

pam_smartcard(8)          BSD System Manager's Manual         pam_smartcard(8)

NAME
     pam_smartcard -- Smartcard PAM module

SYNOPSIS
     [service-name] function-class control-flag pam_smartcard [options]

DESCRIPTION
     The Smartcard PAM module supports authentication function class.  In
     terms of the function-class parameter, this is ``auth.''

   The Smartcard Authentication Module
     This module permits or denies users based on smartcard authentication
     support in the Open Directory database, and the presence of an appropri-
     ate smartcard in the reader attached to the local machine. When a card is
     locked, the user is asked to unlock it with his PIN.

   The following options may be passed to this account management module:
     no_check_shell
             Continues evaluation even if user's shell is not valid. Normally,
             users with a shell like /usr/bin/false are considered as dis-
             abled.

EXAMPLE
     Adding the following line on the top of the /etc/pam.d/sudo enables smartcard support for sudo:
             auth   sufficient     pam_smartcard.so

SEE ALSO
     pam.conf(5), pam(8) SmartCardServices(7)

BSD                             August 27, 2015                            BSD

I guess this is related to the introduction of the native support of PIV cards in Sierra. See "macOS Sierra and PIVToken source code".

The pam_smartcard PAM module is used by two services by default:

• authorization_ctk
• screensaver_ctk

$ grep pam_smartcard /etc/pam.d/*
/etc/pam.d/authorization_ctk:auth       required       pam_smartcard.so  use_first_pass
/etc/pam.d/screensaver_ctk:auth       required       pam_smartcard.so  use_first_pass

$ cat /etc/pam.d/authorization_ctk 
# ctk: auth 
auth       required       pam_smartcard.so   use_first_pass
account    required       pam_opendirectory.so

$ cat /etc/pam.d/screensaver_ctk 
# ctk: auth 
auth       required       pam_smartcard.so  use_first_pass
account    required       pam_opendirectory.so
account    sufficient     pam_self.so
account    required       pam_group.so no_warn group=admin,wheel fail_safe
account    required       pam_group.so no_warn deny group=admin,wheel ruser fail_safe

SmartCardServices

Another interesting man page is SmartCardServices(7). Here is an extract:

SmartCardServices(7) BSD Miscellaneous Information Manual SmartCardServices(7)

NAME
     SmartCardServices -- overview of smart card support

DESCRIPTION
     SmartCardServices is a set of components for OS X smart card support.

     Any smart card which supports the PIV standard is supported natively by
     OS X. Access to smart card items is possible using the keychain inter-
     face. Applications can install additional drivers for smart cards that
     are not natively supported.

     Smart card certificates are automatically added to user's keychain when a
     smart card is inserted. Smart card certificates can be listed with
     security using the list-smartcards or export-smartcard commands. Keychain
     Access GUI cannot be used to manipulate or list these certificates.

SETUP
     To associate users with smart cards, the system can be set up for either
     fixed key mapping or attribute based mapping. For fixed key use
     sc_auth(8) or use the dialog which appears automatically when an unasso-
     ciated smartcard is inserted into a reader. This dialog can be globally
     suppressed by:

           sudo defaults write /Library/Preferences/com.apple.security.smartcard UserPairing -bool NO

     Attribute matching can be set up using the appropriate AttributeMapping
     section in the configuration file as described below. There is no default
     configuration. If no AttributeMapping exists or the configuration file is
     missing, attribute matching is not used. If both fixed key mapping and
     attribute mapping are able to associate the inserted smart card with a
     user, attribute mapping takes precedence.

     By default certificates do not need to be trusted to allow association.
     Certificate trust can be globally enforced by setting:

           sudo defaults write /Library/Preferences/com.apple.security.smartcard checkCertificateTrust -bool YES

[...]

PAM PKCS#11?

Since PAM is available in macOS maybe the PAM PKCS#11 module can be used without too much changes? This module is for GNU/Linux but may be adapted for macOS.

In this case, adding support for smart card login in macOS, if you already have a PKCS#11 library for your card, should be easy.

Conclusion

The use of smart card in macOS for high level services (like authentication) is easier in Sierra, at least for PIV smart cards.

I imagine that the support of other smart cards models will be proposed by third parties "soon".

macOS Sierra and smart card source code

Apple released the source code of the open source components they use in Sierra (OS X 10.12 released in September 2016). The components are available at OS X 10.12 Source.

As I did for El Capitan in "OS X El Capitan and smart card source code" I will document what I found.

The smart card related components are:

• SecurityTokend
• SmartcardCCID

See "macOS Sierra and smart cards status" for a general discussion of the changes in El Capitan.

SecurityTokend

The version changed from 55108 in El Capitan to 55111 in Sierra.

The changes are very limited:

• the Xcode project uses Security.framework
• 1 bug fixed "to prevent uninitialized value when following CALL ends with exception" according to the source code comment

diffstat:

 SecurityTokend-55111/SecurityTokend.xcodeproj/project.pbxproj    |    6 ++++++
 SecurityTokend-55111/lib/transition.cpp                          |    1 +
 SecurityTokend-55111/security_tokend_client/transition.cpp       |    1 +
 3 files changed, 8 insertions(+)

SmartcardCCID

The version changed from 55008.40.1 in El Capitan (10.11.4) to 55013 in Sierra.

Changes:

• CCID driver upgraded from 1.4.21 (released 21 October 2015) to 1.4.24 (released 22 May 2016)
• two Apple patches (RSA_SecurID_getpasswd.c.patch, scardcontrol.c.patch) are no more needed since the problem is fixed upstream

No change:

• the same libusb version 1.0.9 is used. This version was released in 2012-04-02. The latest libusb version is 1.0.21 released in 2016-10-01.
• the CCID driver provided by Apple has 4 patches. These patches are related to the way Apple builds the driver.

Conclusion

No disruptive changes this time.

The source code of CryptoTokenKit (introduced in Yosemite. See "OS X Yosemite BETA and smart cards status") is not provided. That is not surprising since this it is an Apple only component and not a fork of an existing free software.

OS X El Capitan and CCID evolution

In a previous blog article "OS X El Capitan and CCID driver upgrades" I mentioned the evolution of the CCID driver for the same major release of OS X 10.11.x.

With the availability of the source code at Apple Open Source it is easy to see what happened.

OS X Version	SmartcardCCID	CCID
10.11	SmartcardCCID-55008	1.4.14
10.11.1	SmartcardCCID-55008	1.4.14
10.11.2	SmartcardCCID-55008.20.1	1.4.20
10.11.3	SmartcardCCID-55008.20.1	1.4.20
10.11.4	SmartcardCCID-55008.40.1	1.4.21
10.11.5	SmartcardCCID-55008.40.1	1.4.21
10.11.6	SmartcardCCID-55008.40.1	1.4.21

I will try to closely follow the evolution of macOS Sierra (10.12) source code to avoid surprises in the future.

Bitcoins received for this blog: 2 years later

Two years ago (November 2014) I proposed to send me bitcoins in "How to help my projects? Send me bitcoins!".

Bitcoin

After 2 years I got 3 donations for a total amount of 0.02858649 BTC (or approximately 19.37€). The 3 transactions are public and can be seen at https://blockchain.info/address/14iqwd2wEATig6JJD6zwkpvq7AYaECgtng. A great thanks to my 3 donors.

This is not a huge amount. In comparison I received 100.27€ from Flattr in 6 years (see "How to help my projects?").

System	Duration	Total amount	Mean
Flattr	6 years	100.27 €	16.71 €/year
Bitcoin	2 years	19.37 €	9.67 €/year

The problem with Flattr (as I explained in "My Flattr experience") is that the funds are automatically "reinvested" so the real result after 6 years is 0€ in my pockets.

Adsense? No!

Google just proposed me to enrol in the AdSense program. Their estimation is a gain of 10,18 € per month.

Bonne nouvelle ! Votre compte répond aux critères requis pour bénéficier du traitement AdSense accéléré.
Vous devriez pouvoir gagner jusqu'à 10,18 € par mois*. Faites en sorte que votre blog vienne grossir les rangs de ces millions d'autres qui rapportent de l'argent grâce à AdSense. S'inscrire

*Les revenus mentionnés ne sont que des estimations basées sur le trafic récemment enregistré par votre blog. Nous ne pouvons en garantir le montant. Les comptes et les revenus AdSense doivent également respecter le Règlement du programme et les Conditions d'utilisation AdSense.

But since I do not like ads in web pages (and I use an advertisement blocker) I will not use AdSense or any other advertising system.

Conclusion

Please continue sending bitcoins. My bitcoin address is at the bottom of each blog page.

ATR statistics: TD1 - Structural, encodes Y2 and T

Article from the series "ATR statistics"

TD1 - Structural, encodes Y2 and T

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

From Wikipedia https://en.wikipedia.org/wiki/Answer_to_reset#Interface_bytes_TDi:

Interfaces bytes TD_i for i≥1, if present, are structural.
TD_i encodes in its 4 high-order bits the presence of at most 4 other interface bytes: TA_i+1 (resp. TB_i+1, TC_i+1, TD_i+1) follow, in that order, if the 5th (resp. 6th, 7th, 8th) bit of TD_i is 1.
TD_i encodes in its 4 low-order bits (4th MSbit to 1st LSbit) an integer T, in range [0..15]. T = 15 is invalid in TD₁, and in other TD_i qualifies the following TA_i+1 TB_i+1, TC_i+1, TD_i+1 (if present) as global interface bytes. Other values of T indicates a protocol that the card is willing to use, and that TA_i+1 TB_i+1, TC_i+1, TD_i+1 (if present) are specific interface bytes applying only to that protocol. T = 0 is a character-oriented protocol. T = 1 is a block-oriented protocol. T in the range [3..14] is RFU.
Historical note: provision for dynamically qualifying interface bytes as global using T = 15 did not exist in ISO/IEC 7816-3:1989.

TD1	#	%
	899	43.39 %
0x80	459	22.15 %
0x81	372	17.95 %
0x40	95	4.58 %
0x00	69	3.33 %
0x91	46	2.22 %
0xC0	45	2.17 %
0xC1	27	1.30 %
0x10	22	1.06 %
0x50	16	0.77 %
0x01	9	0.43 %
0x0E	8	0.39 %
0x11	2	0.10 %
0x1F	1	0.05 %
0x31	1	0.05 %
0x3F	1	0.05 %

TD1 (as the other TDi bytes) is structural and indicates:

• How to interpret the other ATR bytes
• What communication protocol the card wants to use

For 43% of the ATRs no TD₁ is present. So no other TA₂, TB₂, TC₂ or TD₂ is present and no protocol is defined so the default T=0 will be used.

For 22% of ATRs TD₁ = 0x80 so bit 8 is set to indicate that a TD₂ is present and T=0 is used. One such ATR is 3B 80 80 01 01.

For 17% of ATRs TD₁ = 0x81 so, as in the previous case, TD₂ is present but T=1 is used. One such ATR is 3B 82 81 31 76 43 C0 02 C5

For 5% of ATRs TD₁ = 0x40 so TC₂ is present and T=0 is used. One such ATR is 3B 85 40 20 68 01 01 00 00

I will not document all the other cases. I let this exercise to the reader.

One special case is TD₁ = 0x?E to indicate the T=14 protocol.

From ISO 7816-3:

The type T refers to a transmission protocol and/or qualifies interface bytes.

• T=0 refers to the half-duplex transmission of characters specified in clause 10.
• T=1 refers to the half-duplex transmission of blocks specified in clause 11.
• T=2 and T=3 are reserved for future full-duplex operations.
• T=4 is reserved for an enhanced half-duplex transmission of characters.
• T=5 to T=13 are reserved for future use by ISO/IEC JTC 1/SC 17.
• T=14 refers to transmission protocols not standardized by ISO/IEC JTC 1/SC 17.
• T=15 does not refer to a transmission protocol, but only qualifies global interface bytes.

As you can see in the list above "T=14 refers to transmission protocols not standardized by ISO/IEC JTC 1/SC 17." In my list T=14 is used only by pay TV cards like 3B 9F 21 0E 49 52 44 45 54 4F 20 41 43 53 03 83 95 00 80 55.

TD₁ = 0x?F is also another special case to indicate T=15, which is not a protocol, and will change the interpretation of the following ATR bytes.

Smart cards on Ubuntu on Windows 10?

Since Windows 10 Anniversary it is possible to install Ubuntu 14.04 as a Windows subsystem (or something like that). See "Run Bash on Ubuntu on Windows" or any other documentation.

Of course I was curious and tried. Yes, I have a Windows partition. It is just used to upgrade the laptop firmware since it is not easy or even possible to upgrade the Dell laptop firmware from GNU/Linux.

Build

After some time the tools needed to build pcsc-lite and libccid are installed. The two builds are successful.

$ /usr/local/sbin/pcscd --version
pcsc-lite version 1.8.18.
Copyright (C) 1999-2002 by David Corcoran <corcoran musclecard.com>.
Copyright (C) 2001-2015 by Ludovic Rousseau <ludovic .rousseau="" free.fr>.
Copyright (C) 2003-2004 by Damien Sauveron <sauveron labri.fr>.
Report bugs to <pcsclite-muscle@lists.alioth.debian.org>.
Enabled features: Linux x86_64-unknown-linux-gnu serial usb libudev usbdropdir=/usr/local/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/usr/local/etc/reader.conf.d

Issues

The build is a success but the execution fails.

Not working libudev

$ sudo /usr/local/sbin/pcscd --foreground --debug
00000000 debuglog.c:289:DebugLogSetLevel() debug level=debug
00001975 configfile.l:358:DBGetReaderList() Parsing conf file: /usr/local/etc/reader.conf.d
00001005 pcscdaemon.c:655:main() pcsc-lite 1.8.18 daemon ready.
libudev: udev_monitor_enable_receiving: bind failed: Invalid argument
00005302 hotplug_libudev.c:758:HPRegisterForHotplugEvents() udev_monitor_enable_receiving() error: -1

^C01658892 pcscdaemon.c:188:signal_thread() read failed: Interrupted system call

Not really surprising, libudev fails to register the reception of events. This was expected since udev is a device manager for the Linux kernel and we do not have a Linux kernel here.

We could configure pcsc-lite to use libusb instead of libudev to manage hotplug. But that would also not work, see bellow.

Not working libusb

$ lsusb
unable to initialize libusb: -99

The libusb library is not usable.

$ strace lsusb
[...]
gettimeofday({1475313910, 750505}, NULL) = 0
openat(AT_FDCWD, "/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
brk(0x1bfa000)                          = 0x1bfa000
getdents(3, /* 20 entries */, 32768)    = 481
getdents(3, /* 0 entries */, 32768)     = 0
brk(0x1bf2000)                          = 0x1bf2000
close(3)                                = 0
write(2, "unable to initialize libusb: -99"..., 33unable to initialize libusb: -99
) = 33
exit_group(1)                           = ?
+++ exited with 1 +++

This is because the file system does not provide the USB virtual files in /dev/bus/usb/ or /proc/bus/usb/.

$ ls -l /dev
ls: cannot access /dev/lxss: Operation not permitted
ls: /dev/random: Invalid argument
total 0
drwxr-xr-x 2 root     root    0 Oct  1 10:04 block
lrwxrwxrwx 1 root     root   13 Oct  1 10:04 fd -> /proc/self/fd
crw------- 1 root     root 0, 0 Oct  1 11:28 kmsg
c????????? ? ?        ?       ?            ? lxss
crw-rw-rw- 1 root     root 1, 3 Jan  1  1970 null
crw-rw-rw- 0 root     tty  5, 2 Oct  1 10:31 ptmx
drwxr-xr-x 0 root     root    0 Oct  1 10:04 pts
crw-rw-rw- 1 root     root 1, 8 Oct  1 11:28 random
lrwxrwxrwx 1 root     root    8 Oct  1 10:04 shm -> /run/shm
lrwxrwxrwx 1 root     root   15 Oct  1 10:04 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root     root   15 Oct  1 10:04 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root     root   15 Oct  1 10:04 stdout -> /proc/self/fd/1
crw------- 1 rousseau tty  4, 1 Oct  1  2016 tty
crw-rw-rw- 1 root     tty  4, 0 Oct  1  2016 tty0
crw------- 1 rousseau tty  4, 1 Oct  1  2016 tty1
crw-rw---- 1 root     tty  4, 2 Oct  1 11:28 tty2
crw-rw-rw- 1 root     root 1, 9 Oct  1 11:28 urandom
crw-rw-rw- 1 root     root 0, 0 Oct  1 11:28 zero

$ ls -l /proc
total 0
dr-xr-xr-x 1 root     root     0 Oct  1 10:07 1
dr-xr-xr-x 1 rousseau rousseau 0 Oct  1 10:07 2
dr-xr-xr-x 1 rousseau rousseau 0 Oct  1 11:29 22063
-r--r--r-- 1 root     root     0 Oct  1 10:04 cmdline
-r--r--r-- 1 root     root     0 Oct  1 10:04 cpuinfo
-r--r--r-- 1 root     root     0 Oct  1 10:04 filesystems
-r--r--r-- 1 root     root     0 Oct  1 10:04 interrupts
-r--r--r-- 1 root     root     0 Oct  1 10:04 loadavg
-r--r--r-- 1 root     root     0 Oct  1 10:04 meminfo
lrwxrwxrwx 1 root     root     0 Oct  1 10:04 mounts -> self/mounts
lrwxrwxrwx 1 root     root     0 Oct  1 10:04 net -> self/net
lrwxrwxrwx 1 root     root     0 Oct  1 10:04 self -> 22063
-r--r--r-- 1 root     root     0 Oct  1 10:04 stat
dr-xr-xr-x 1 root     root     0 Oct  1 10:04 sys
-r--r--r-- 1 root     root     0 Oct  1 10:04 uptime
-r--r--r-- 1 root     root     0 Oct  1 10:04 version

Existing packages

The libccid package is available for this Ubuntu 14.04 in Windows 10.

$ apt-cache policy libccid
libccid:
  Installed: (none)
  Candidate: 1.4.15-1
  Version table:
     1.4.15-1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packagess

Since I made a build from the source code I have not installed this package.

Port or not

I was curious to know if the packages have been rebuilt for "Windows" with a special configuration. So I selected a package at random (in fact I used a short package name to limit the number of key presses needed to enter the package name. The m4 package is a good candidate for that.).

m4 package as downloaded by apt from "Windows":

$ pwd
/var/cache/apt/archives
$ sha1sum m4_1.4.17-2ubuntu1_amd64.deb
4358d262605ae065a7dc9b6e0c80b3c7f44bf1cc  m4_1.4.17-2ubuntu1_amd64.deb

m4 package as downloaded from http://packages.ubuntu.com/trusty/amd64/m4/download for amd64 architecture:

$ pwd
/mnt/c/Users/Ludovic/Downloads
$ sha1sum m4_1.4.17-2ubuntu1_amd64.deb
4358d262605ae065a7dc9b6e0c80b3c7f44bf1cc  m4_1.4.17-2ubuntu1_amd64.deb

The two packages are exactly the same.

The apt repository is the same as for a real Ubuntu system.

$ cat /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu trusty main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu trusty-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu trusty-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu trusty-security main restricted universe multiverse

$ dpkg --print-architecture
amd64

Conclusion

As expected many Linux features (udev, USB) are missing. Maybe Microsoft will work on that to provide more support.

I also note that the system is much slower on Ubuntu in Windows than on a real Linux kernel (and a Debian system) on the same hardware. In particular the file system accesses, when installing packages for example, are around an order of magnitude slower.

New version of libccid: 1.4.25

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

Changes:
1.4.25 - 30 September 2016, Ludovic Rousseau

• Add support of
• Aladdin R.D. JaCarta (idProduct: 0x0402)
• Broadcom Corp 5880 (idProduct: 0x5832)
• Broadcom Corp 5880 (idProduct: 0x5833)
• Broadcom Corp 5880 (idProduct: 0x5834)
• ESMART Token GOST X2 ET1020-A
• Feitian VR504 VHBR Contactless & Contact Card Reader
• Feitian bR500
• Gemalto K50
• appidkey GmbH ID100-USB  SC Reader
• appidkey GmbH ID50 -USB
• Remove suport of
• Broadcom Corp 5880 (idProduct: 0x5800)
• Broadcom Corp 5880 (idProduct: 0x5805)
• KEBTechnology KONA USB SmartCard
• macOS: Fix composite device enumeration
• Fix crash with GemCore Pos Pro and GemCore Sim Pro
• Some minor improvements

pam_pkcs11: new/last version 0.6.9

About

From the project wiki page:

This Linux-PAM login module allows a X.509 certificate based user login. The certificate and its dedicated private key are thereby accessed by means of an appropriate PKCS #11 module. For the verification of the users’ certificates, locally stored CA certificates as well as either online or locally accessible CRLs are used.

The idea is to use a smart card and its corresponding PKCS#11 library to login (and more) into a GNU/Linux system.

Changes

This version has many changes. The previous version 0.6.8 was released in April 2012. Thanks to all the contributors that provided patches.

• Support many certificates
• Italian translation
• When searching LDAP, filter on the certificate
• Add an LDAP "uid_attribute", use it to speed up
• Add "attribute_map" to LDAP mapping
• Treat "attribute_map" as a list of ANDed clauses
• Do not fail if card was already unlocked, e.g. by a previous PAM module
• Add CERT_SERIAL "serial" as a valid option
• Support OpenSSL 1.1.x
• Other minor changes

Download

Download the .tar.gz archive from https://sourceforge.net/projects/opensc/files/pam_pkcs11/

Conclusion

I am the maintainer of pam_pkcs11 but it do not use this software any more and have no time to take care of this project. A new maintainer is welcome.

macOS Sierra and smart cards status

macOS Sierra (macOS 10.12) is now available since 20th September, 2016.

API Differences between 10.11 and 10.12

The differences are listed in the developer page macOS Sierra 10.12. The page only document big changes. Regarding smart cards we only have:

Support for Smart Card Driver Extensions

You can now create NSExtension-based smart card drivers, allowing the contents of certain types of smart cards to be presented as part of the system keychain. This mechanism is intended to replace the deprecated Common Data Security Architecture, although for macOS 10.12, both architectures are supported.

The driver extensions are limited to read-only mode, so that it is not possible to alter the contents of a smart card using the standard keychain interface. For more information, see CryptoTokenKit Framework Reference.

See also a previous blog article "macOS Sierra: Smart Card Driver Extensions". I guess I will write again about this new technology in future blog articles.

Updates on CryptoTokenKit framework, PCSC framework and CCID driver are not listed in this high level page.

PC/SC

Since Yosemite (10.10) 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>65</string>
 <key>CFBundleShortVersionString</key>
 <string>8.0</string>
 <key>CFBundleVersion</key>
 <string>1</string>
 <key>ProjectName</key>
 <string>SmartCardServices</string>
 <key>SourceVersion</key>
 <string>196001003000000</string>
</dict>
</plist>

The BuildVersion changed from 13 on El Capitan to 65 on Sierra, and SourceVersion changed from 79001001000000 to 196001003000000. I have no idea what the SourceVersion "number" is.

It looks like Apple made 65-13 = 52 builds of the PC/SC framework since Yosemite 10.11.0.

PC/SC Bugs fixed

These bugs were found in El Capitan and are now fixed in Sierra:

1. SCardGetAttrib() returns SCARD_E_NOT_TRANSACTED when it should not
2. Connecting a CT700 Gemalto smart card reader renders PC/SC useless
3. SCardConnect() returns SCARD_E_PROTO_MISMATCH instead of SCARD_E_SHARING_VIOLATION
4. SCardGetAttrib() returns SCARD_E_NOT_TRANSACTED instead of SCARD_E_INSUFFICIENT_BUFFER

Some bugs reported on El Capitan are still present in Sierra. I updated the page "OS X El Capitan and smart cards: known bugs".

CCID driver

Driver version 1.4.24.
El Capitan had: 1.4.14 in 10.11.0 and 1.4.21 in 10.11.6

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

 You can have a look at the CCID README file to know what changes between version 1.4.21 and version 1.4.24.

Note that the CCID driver version 1.4.24 provided in macOS Sierra is the latest available version (as I write this blog). version 1.4.24 has been released in May 2016 (4 months ago only).

It is important to note that Apple regularly upgrades the CCID driver. I guess Apple will continue to upgrade the CCID driver in minor versions of Sierra, as they did with minor versions of El Capitan.

Conclusion

• Some PC/SC framework bugs fixed.
• Updated version of the CCID driver.
• Support for Smart Card Driver Extensions (replacing tokend)

ATR statistics: TC1 - Global, encodes N

Article from the series "ATR statistics"

TC1 - Global, encodes N

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

From Wikipedia https://en.wikipedia.org/wiki/Answer_to_reset#Interface_byte_TC1 (with some edition to remove extra details):

TC₁, if present, is global, and encodes the Extra Guard Time integer (N), from 0 to 255 (8th MSbit to 1st LSbit); otherwise, N = 0. N defines how much the Guard Time that the reader must apply varies from a baseline of 12 ETU (corresponding to 1 start bit, 8 data bits, 1 parity bit, and 2 stop bits; with the second stop bit possibly used for an error indication by the receiver under protocol T = 0). The Guard Time is the minimum delay between the leading edge of the previous character, and the leading edge of the next character sent.
Except when N is 255, the Guard Time is: GT = 12 ETU + R*N/f
where:

• f is the clock frequency being generated by the reader;
• R is some number of clock cycles, either:
• per ETU, R = F/D, if T = 15 is absent from the ATR;
• defined by TA₁, R = F_i/D_i (or its default value), if T = 15 is present in the ATR.

N = 255 has a protocol-dependent meaning: GT = 12 ETU during PPS (Protocol and Parameters Selection) and protocol T = 0, GT = 11 ETU under protocol T = 1 (corresponding to 1 start bit, 8 data bits, 1 parity bit, and 1 stop bit; with no error indication).
Except under protocol T = 1, the card transmits with a Guard Time of 12 ETU, irrespective of N. Under protocol T = 1, the Guard Time defined by N is also the Character Guard Time (CGT), and applies to card and reader for characters sent in the same direction.
Note: The reader remains bound by the Guard Time GT defined by N when other prescriptions specify another minimum delay between leading edges of characters in different directions, even when that minimum is lower than GT.

Historical note: ISO/IEC 7816-3:1989 only defined that N code the EGT as a number of ETU, the method now used when T = 15 is absent from the ATR. With this convention, cards that allow negotiation of a reduced number of clock cycles per ETU after PPS must also allow a proportionally reduced number of clock cycles for the EGT, which does not match with a common EGT motivation: account for delays before the card can receive the next character. The 1997 edition of the standard introduced that when T = 15 is present in the ATR, N code the EGT as a multiple of the number of clock cycles per ETU coded by TA₁, making the EGT effectively independent of the number of clocks cycles per ETU negotiated, while maintaining compatibility with former readers at least if they did not change the number of clock cycles per ETU.

To make it short TC₁ defines a time value between characters transmitted between the card and the reader. The default value correspond to a Guard Time of 12 ETU. But the card can specify a bigger value (the card is not fast enough).

TC1	#	%
	910	43.92 %
0x00	792	38.22 %
0xFF	287	13.85 %
0x02	29	1.40 %
0x03	18	0.87 %
0x01	15	0.72 %
0x08	6	0.29 %
0x05	4	0.19 %
0x04	3	0.14 %
0x0B	2	0.10 %
0x09	1	0.05 %
0x10	1	0.05 %
0x3F	1	0.05 %
0x64	1	0.05 %
0x81	1	0.05 %
0xFE	1	0.05 %

The default value is 0. But 38.22% of cards explicitly define TC₁=0.
A total of 82.14% of cards use the default value.
TC₁=255 is also a special value not far from the default value of 12 ETU.

The real number of cards that are not fast enough to use the full speed is only of 4.00% (84 cards).

Smart Card Services moved from an Apple server to github.com

Mac OS Forge

Apple had a software forge to host Free Software they used in Mac OS X. The site is https://www.macosforge.org/ and now indicates:

macOS forge hosted open source projects closely related to macOS.

One of the hosted project is:

Smart Card Services
The Smart Card Services project is comprised of several components which, when combined, provide the necessary abstraction layer and integration of smart cards into Apple’s CDSA implementation.

Smart Card Services contains different parts:

• SmartCardServices: contains Apple version of pcsc-lite. See "Differences between Apple pcsc-lite and the "official" pcsc-lite"
• Tokend: BELPIC, CAC, PIV, PKCS11 tokend
• TokendPKCS11: PKCS#11 library above tokend
• SmartcardCCID: CCID driver

Alive projects?

From the list above most of the projects are now dead.

• Since Yosemite, pcsc-lite is no more used and has been replaced in 2014 by Crypto Token Kit.
  See "OS X Yosemite BETA and smart cards status"
• tokend architecture is deprecated since Lion in 2011
  See "Mac OS X Lion and tokend"
• CCID driver is no more updated to reflect what is installed in current macOS versions.
  El Capitan provides the version 1.4.21 but the site still provides version 1.3.8.

Conclusion

The project Smart Card Services is interesting mainly for historical reasons. The development of smart card components available in macOS is now done elsewhere., i.e. internally at Apple and the source code is no more public.

macOS Sierra: Smart Card Driver Extensions

macOS Sierra is not yet available. But Apple already provides documentation about what is new.

Smart Card Driver

For example the page https://developer.apple.com/library/prerelease/content/releasenotes/MacOSX/WhatsNewInOSX/Articles/OSXv10.html talks about the Smart Card Driver Extensions that will replace tokend:

Support for Smart Card Driver Extensions

You can now create NSExtension-based smart card drivers, allowing the contents of certain types of smart cards to be presented as part of the system keychain. This mechanism is intended to replace the deprecated Common Data Security Architecture, although for macOS 10.12, both architectures are supported.

The driver extensions are limited to read-only mode, so that it is not possible to alter the contents of a smart card using the standard keychain interface. For more information, see CryptoTokenKit Framework Reference.

Important points

"for macOS 10.12, both architectures are supported"

The good news is that both tokend and Smart Card Driver are supported in 10.12.

Note that Apple does not say what will happen in 10.13. I guess the message here is that support of tokend will be removed in 10.13.

tokend is deprecated since Mac OS X Lion (10.7 released in 2011. See "Mac OS X Lion and tokend"). tokend support may disappear in 2017 with 10.13. So that would be 6 years of deprecation.

"limited to read-only mode"

As with tokend the new token is also in read-only mode.

Conclusion

macOS Sierra will provide new technologies to play with. The smart card integration should be better.

PC/SC sample in go

To continue the list of PC/SC wrappers initiated in 2010 with "PC/SC sample in different languages" I now present a sample in go.

scard go wrapper

I used the scard go wrapper from Michael Gehring.

The github project does not provide any documentation. You can get some help from a previous project go.pcsclite also from Michael Gehring.

The scard wrapper API has a nice godoc page.

Installation

The installation is quiet simple.

$ cd foobar
$ export GOPATH=$(pwd)

$ go get github.com/ebfe/scard

I used the default golang-go package on Debian stable (jessie 8.5).

$ go version
go version go1.3.3 linux/amd64

Sample source code

package main

import (
    "fmt"
    "github.com/ebfe/scard"
)

func main() {
    // Establish a PC/SC context
    context, err := scard.EstablishContext()
    if err != nil {
        fmt.Println("Error EstablishContext:", err)
        return
    }

    // Release the PC/SC context (when needed)
    defer context.Release()

    // List available readers
    readers, err := context.ListReaders()
    if err != nil {
        fmt.Println("Error ListReaders:", err)
        return
    }

    // Use the first reader
    reader := readers[0]
    fmt.Println("Using reader:", reader)

    // Connect to the card
    card, err := context.Connect(reader, scard.ShareShared, scard.ProtocolAny)
    if err != nil {
        fmt.Println("Error Connect:", err)
        return
    }

    // Disconnect (when needed)
    defer card.Disconnect(scard.LeaveCard)

    // Send select APDU
    var cmd_select = []byte{0x00, 0xa4, 0x04, 0x00, 0x0A, 0xA0,
  0x00, 0x00, 0x00, 0x62, 0x03, 0x01, 0x0C, 0x06, 0x01}
    rsp, err := card.Transmit(cmd_select)
    if err != nil {
        fmt.Println("Error Transmit:", err)
        return
    }
    fmt.Println(rsp)

    // Send command APDU
    var cmd_command = []byte{0x00, 0x00, 0x00, 0x00}
    rsp, err = card.Transmit(cmd_command)
    if err != nil {
        fmt.Println("Error Transmit:", err)
        return
    }
    fmt.Println(rsp)
    for i := 0; i < len(rsp)-2; i++ {
        fmt.Printf("%c", rsp[i])
    }
    fmt.Println()
}

Remarks

You can get another sample code example_test.go in the scard project. This sample code greatly helped me implement my own sample code.

Results

$ go run hello_world.go
Using reader: Gemalto PC Twin Reader (70D7E2EE) 00 00
[144 0]
[72 101 108 108 111 32 119 111 114 108 100 33 144 0]
Hello world!

Conclusion

The github project scard has no documentation or README file. After discussion with Michael Gehring it is on purpose.

This blog article should give more visibility to the project.

ATR statistics: TB1 - Global, deprecated

Article from the series "ATR statistics"

TB1 - Global, deprecated

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

From Wikipedia https://en.wikipedia.org/wiki/Answer_to_reset#Interface_byte_TB1 (with some edition to remove extra details):

TB₁, if present, is global. The usage of TB₁ is deprecated since the 2006 edition of the standard, which prescribes that cards should not include TB₁ in the ATR, and readers shall ignore TB₁ if present. EMV still requires that the card includes TB₁ = ‘00’, and that remains common practice; doing so explicitly indicates that the card does not use the dedicated contact C6 for the purpose of supplying a programming voltage (V_PP) to the card; the cards might however use C6 for Standard or Proprietary Use (SPU), such as communicating with a NFC front end by the Single Wire Protocol (SWP). On the reader side, EMV requires making a warm ATR for cards with TB₁ other than ‘00’ in the cold ATR, and handling any TB₁ in a warm ATR as if it was ‘00’.

TB₁ was previously indicating (coarsely) the programming voltage V_PP and maximum programming current required by some cards on the dedicated contact C6 during programming of their EPROM memory. Modern Smart Cards internally generate the programming voltage for their EEPROM or Flash memory, and thus do not use V_PP. In the 1997 and earlier editions of the standard:

• The low 5 bits of TB₁ (5th MSbit to 1st LSbit) encode PI1; if TB₂ is absent, PI1 = 0 indicates that the C6 contact (assigned to V_PP) is not connected in the card; PI1 in range [5..25] encodes the value of V_PP in Volt (the reader shall apply that voltage only on specific demand by the card, with a tolerance of 2.5%, up to the maximum programming current; and otherwise leave the C6 contact used for V_PP within 5% of the V_CC voltage, up to 20 mA); if TB₂ is present, it supersedes the indication given by TB₁ in the PI1 field, regarding V_PP connection or voltage.
• The high bit of TB₁ (8th bits) is reserved, shall be 0, and can be ignored by the reader.
• The 6th and 5th bits of TB₁ encode the maximum programming current (assuming neither TB₁ nor TB₂ indicate that V_PP is not connected in the card).

7th and 6th bits	00	01	10	11
Maximum programming current	25 mA	50 mA	RFU(#)	RFU

(#) This was 100 mA in ISO/IEC 7816-3:1989.

TB1	#	%
0x00	1228	59.27 %
	776	37.45 %
0x25	61	2.94 %
0x2F	2	0.10 %
0x35	2	0.10 %
0x20	1	0.05 %
0x3F	1	0.05 %
0xFF	1	0.05 %

Only 68 ATRs (3.2%) have a TB₁ different from 0x00.

The TB₁ value found are (in order of appearance):

• 0x25 "Programming Param P: 5 Volts, I: 50 milliamperes"
• 0x2F "Programming Param P: 15 Volts, I: 50 milliamperes"
• 0x35 "Programming Param P: 21 Volts, I: 50 milliamperes"
• 0x20 "VPP is not electrically connected"
• 0x3F "Programming Param P: 31 Volts, I: 50 milliamperes"
• 0xFF "Programming Param P: 31 Volts, I: RFU"

Most of the smart cards with TB₁ = 0x25 are PayTV cards. maybe TB₁ is using a non standard value to confuse the smart card reader.

Broadcom CCID readers

Par inconnu — http://www.broadcom.com/company/factsheet.php?source=top, marque déposée, https://fr.wikipedia.org/w/index.php?curid=1691847

Broadcom updated the firmware of some of their (bogus) devices. For example the reader Broadcom Corp 5880 (idProduct 0x5805) is bogus. The problem is that frames bigger than 64 bytes (wMaxPacketSize) fails on the contact reader.

Broadcom 5880

The 5880 device name is used by all the 8 Broadcom devices in my list. So it is not easy to know exactly what device is present in a computer. You can use the GNU/Linux command line lsusb or my program parse to have more details.

Dell laptops

Par Dell — Dell, Domaine public, https://commons.wikimedia.org/w/index.php?curid=10341993

The Broadcom devices are often present in Dell laptop.

For example the Dell Latitude E5570 has one such Broadcom 5880 device. This is the version idProduct 0x5805 with the bug described above.

Firmware upgrade

Dell now provides a firmware upgrade Dell ControlVault2 Driver and Firmware that includes a fix for the smart card reader. After the firmware upgrade the smart card reader has a new idProduct 0x5834.

This device is already in the "should work" list and will be included in the CCID driver version 1.4.25 (available soon).

Contactless reader

The Broadcom 5880 in the Dell Latitude E5570 (with idProduct 0x5805 and 0x5834 after the upgrade) also provides a contactless interface. But this contactless interface is still not supported by my CCID driver.

I guess the interface is not really CCID compliant and no RF (radio frequency) field is emitted by the reader. I guess a special command has to be send to the reader to activate the RF field, maybe to limit the power consumption when no contactless card is used.

Conclusion

3 Broadcom 5880 devices are in the "unsupported" list. Maybe the firmware upgrade will fix all of them. At least the upgrade fixes 2 of them (the 0x5805 as above and also the 0x5800 converted in 0x5832)

pcsc-lite: (much) faster SCardDisconnect()

Since pcsc-lite 1.8.18 the function SCardDisconnect() has a new behaviour.

Some history

Always on

At the beginning of pcsc-lite (circa 1999) the card was always powered on when inserted in a smart card reader. The code was simple: when a card is inserted in a reader then power on the card. This worked great.

At that time the USB 1.1 was quite new and most smart card readers were using a serial port and an external power supply.

Auto power off

In 2010 most of the smart card readers were connected using USB and used the USB cable to get the power. So it was a good idea to power off a smart card that is not used to reduce the power consumed in particular when you use a laptop computer.

So I implemented a mechanism to automatically power off an unused card. The card is powered off if it is not used 5 seconds after the power on. See "Card auto power on and off" for more details.

SCardDisconnect(..., SCARD_UNPOWER_CARD) would power off the card, power it on again and 5 seconds later, if not used, power off the card.

Remove extra power on

SCardDisconnect(..., SCARD_UNPOWER_CARD) would not return before the power on succeeds. This operation takes time because the reader has to get the ATR from the card. The application specifically used SCARD_UNPOWER_CARD so we can expect the card will not be used after that.

Since the card auto power on and off mechanism was already implemented in 2010 the card was already automatically powered on when needed. It was simple to modify the pcsc-lite code and remove the useless power on.

Benefit

The benefit is simple: SCardDisconnect(..., SCARD_UNPOWER_CARD) is now much faster. I included some numbers in the patch commit message.

Before the change: SCardDisconnect(SCARD_UNPOWER_CARD) in 61 ms
After the change: SCardDisconnect(SCARD_UNPOWER_CARD) in 1.4 ms

Speedup (for the card used) = 61/1.4 = x44
If you use a card that is slower to power up then the gain is even higher.

I think a speedup of x10 or x100 on a PC/SC function deserve a blog article, even if SCardDisconnect(..., SCARD_UNPOWER_CARD) is not always on the performance critical path of an application.

Thanks

I would like to thank Christophe FERRANDO from Sylyca for the implementation of this feature.

Conclusion

If you want to get a change or an improvement in pcsc-lite, just contact me.

New version of pcsc-lite: 1.8.18

I just released a new version of pcsc-lite 1.8.18.
pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

Changes:
1.8.18: Ludovic Rousseau
10 August 2016

• SCardDisconnect(): much faster with SCARD_UNPOWER_CARD
• SCardConnect(): Fix a possible duplicated hCard context
• Fix compilation on FreeBSD
• Fix compilation on Solaris
• Some other minor improvements

macOS Sierra and PIVToken source code

Deprecated tokend API is now replaced

In "macOS Sierra and CryptoTokenKit API" I presented the updated CryptoTokenKit API. This API is not completely new but was not really used.

Apple now provides the source code of PIVToken: a token for PIV (Personal Identity Verification) smart cards using the new API instead of the old tokend/CDSA API.

PIVToken : short source code

The code is available at Code sample: PIVToken: Using CryptoTokenKit to add support for new types of tokens.

I used the tools sloccount to count the number of lines of code.

$ sloccount .
SLOC Directory SLOC-by-Language (Sorted)
493     PIVToken        objc=493

Totals grouped by language (dominant language first):
objc:           493 (100.00%)

$ scloccunt --details .
227 objc PIVToken PIVToken/Token.m
162 objc PIVToken PIVToken/TokenSession.m
50 objc PIVToken PIVToken/NSData_Zip.m
14 objc PIVToken PIVToken/TokenSession.h
36 objc PIVToken PIVToken/Token.h
4 objc PIVToken PIVToken/NSData_Zip.h

The token is only 493 lines of Objective-C.

I am not a PIV expert or even user so I can't really tell if all the PIV features are supported in this token.

Subject to changes

" This sample demonstrates how to write an extension for CryptoTokenKit framework to support new types of SmartCards or any other cryptographic token. "

I would not be surprised if the code changes before the final macOS Sierra release.

Conclusion

It is time to study the sample code and work on replacement of existing tokend tokens.

New version of pcsc-tools: 1.4.27

I just released a new version of pcsc-tools, a suite of tools for PC/SC.

Changes:
1.4.27 - 2 July 2016, Ludovic ROUSSEAU

• 72 new ATRs
• ATR_analysis: propose to submit the ATR if not known
• pcsc_scan: Handle "simultaneous" readers removal

macOS Sierra and CryptoTokenKit API

macOS Sierra

Apple presented macOS Sierra 10.12 during the World Wide Developer Conference (WWDC) 2016 in June 13, 2016.

https://en.wikipedia.org/w/index.php?curid=50807596

I could not find information about smart cards or CryptoTokenKit API in Apple Sierra preview page or Wikipedia Sierra page. I am not surprised. Smart cards are far less used than Siri for example :-)

I already wrote about the CryptoTokenKit API when this API has been introduced in "OS X Yosemite BETA and smart cards status" in July 2014, 2 years ago.

It looks like the CryptoTokenKit API is more mature now since the documentation is available as web pages (and not just .h header files).

CryptoTokenKit

The API documentation web page is "CryptoTokenKit Access Smart Cards and manage user interactions."

A lot of functions are marked as Beta. So I would expect some/many changes between the beta version(s) of Sierra and the official Sierra release planned for fall 2016.

Beta Software

This documentation contains preliminary information about an API or technology in development. This information is subject to change, and software implemented according to this documentation should be tested with final operating system software.

Conclusion

Only Apple developers have access to this first Sierra beta version. Because of the Apple NDA I can't write about information not already public.

A new beta version of macOS Sierra should be available in July 2016. This time it will be a public beta for everyone. More information to come...

UEFI Smart Card Reader Protocol implementation

Last year (May 2015) I presented the new UEFI (Unified Extensible Firmware Interface Specification) protocol called "Smart Card Reader Protocol" in the article "UEFI Smart Card Reader Protocol".

I also presented a sample Hello World application in "PCSC sample in C for UEFI".

Source code

The source code of my implementation of the protocol is available in my github edk2 project. Be sure to use the SmartCard branch.

The source code of the Hello World application and some other test/debug tools is available in my github UEFI-SmartCardReader-Samples project.

Integration in TianoCore

My "Smart Card Reader Protocol" implementation is a port of my CCID driver. So the core of the driver uses the same GNU LGPL v2+ license.
I proposed my implementation on the edk2-devel mailing list in "[edk2] [PATCH 0/4] Add an implementation of EFI_SMART_CARD_READER_PROTOCOL".

Unfortunately the copyleft license GNU LGPL v2+ is a problem for some TianoCore members. So my code was not integrated in TianoCore (a reference implementation of UEFI) and I moved to something else.

Conclusion

You can use my implementation of the "Smart Card Reader Protocol". Be careful the GNU LGPL v2+ license is fine with your project.

New version of pcsc-lite: 1.8.17

I just released a new version of pcsc-lite 1.8.17.
pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

Changes:
1.8.17: Ludovic Rousseau
29 May 2016

• Fix SCardEndTransaction() issue with a SCARD_SHARE_EXCLUSIVE connection
• Fix an issue when used with systemd (problem in signal handler)
• SCardGetAttrib(): set pcbAttrLen when buffer is too small
• Doxygen: SCardGetAttrib() pbAttr can be NULL
• Doxygen: SCardGetAttrib() *pcbAttrLen contains the buffer size
• fix compilation warnings and link errors on SunOS
• Some other minor improvements

PySCard 1.9.4 released

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

The PySCard project is available at:

• sourceforge
• pypi
• github

Changes

1.9.4 (May 2016)

• Fix installation using pip and easy_install
• Avoid El Capitan SCardGetAttrib bug
• CardConnection: Add context management
• PCSCCardConnection: raise NoCardException if SCARD_E_NO_SMARTCARD
• Stop CardMonitor monitor thread after traceback print.
• minor improvements

1.9.3 (March 2016)

• Fix SCardControl() on Windows 7
• Fix installation using pip and easy_install

OS X El Capitan 10.11.5 and CCID driver fix

As explained in my previous article "OS X El Capitan 10.11.5 and CCID driver still broken" the upgrade to 10.11.5 did not fix the CCID driver issue.

To fix the issue you have to download and install the "OS X El Capitan 10.11.5 Combo Update".

The file size is 1.5 GB. You can install it even if you already upgraded your system to 10.11.5.

Fixed CCID driver

Now I have:

$ pwd
/usr/libexec/SmartCardServices/drivers
$ ls -lR ifd-ccid.bundle/
total 0
drwxr-xr-x  5 root  wheel  170 23 mai 18:54 Contents

ifd-ccid.bundle//Contents:
total 24
-rw-r--r--  1 root  wheel  36860 21 déc 06:05 Info.plist
drwxr-xr-x  6 root  wheel    204 23 mai 18:54 MacOS
-rw-r--r--  1 root  wheel    470 21 déc 06:05 version.plist

ifd-ccid.bundle//Contents/MacOS:
total 512
lrwxr-xr-x  1 root  wheel      20 23 mai 18:52 libccid.dylib -> libccid.dylib.1.4.21
-rwxr-xr-x  1 root  wheel  165888 17 sep  2015 libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  166096  3 déc 07:33 libccid.dylib.1.4.20
-rwxr-xr-x  1 root  wheel  166096  5 mai 08:02 libccid.dylib.1.4.21

Note that the symbolic link libccid.dylib now points to the latest driver version.

The files libccid.dylib.1.4.14 and libccid.dylib.1.4.20 are now useless and could be removed. But because of System Integrity Protection it is not easy and I think I will not remove them.

Conclusion

The problem should now be fixed.

If you installed a copy of the CCID driver in /usr/local/libexec/SmartCardServices/drivers/ as suggested by some people you may want to remove it now to avoid conflicts with the Apple provided CCID driver.

New version of libccid: 1.4.24

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

Changes:
1.4.24 - 22 May 2016, Ludovic Rousseau

• Add support of
• Generic USB Smart Card Reader
• Giesecke & Devrient GmbH StarSign CUT S
• HID AVIATOR Generic
• better support of Elatec TWN4 SmartCard NFC
• better support of SCM SCL011
• betetr support of HID Aviator generic
• fix SCARD_ATTR_VENDOR_IFD_SERIAL_NO attribute size
• fix a race condition on card events with multiple readers
• Some minor improvements

OS X El Capitan 10.11.5 and CCID driver still broken

Mac OS X El Capitan version 10.11.5 is now available. The Apple documentation "About the OS X El Capitan v10.11.5 Update" does not mention the CCID driver. But I am not surprised since many bugs have been fixed but are not listed in the upgrade message.

Unfortunately the problem reported in "OS X El Capitan and CCID driver upgrades" is still not fixed.

OS X 10.11.5

On Mac OS X 10.11.5 I have:

$ pwd
/usr/libexec/SmartCardServices/drivers

$ ls -lR ifd-ccid.bundle/
total 0
drwxr-xr-x  5 root  wheel  170 23 mar 09:30 Contents

ifd-ccid.bundle//Contents:
total 24
-rw-r--r--  1 root  wheel  36860 21 déc 06:05 Info.plist
drwxr-xr-x  6 root  wheel    204 23 mar 09:30 MacOS
-rw-r--r--  1 root  wheel    470 21 déc 06:05 version.plist

ifd-ccid.bundle//Contents/MacOS:
total 512
lrwxr-xr-x  1 root  wheel      20  4 nov  2015 libccid.dylib -> libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  165888 17 sep  2015 libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  166096  3 déc 07:33 libccid.dylib.1.4.20
-rwxr-xr-x  1 root  wheel  166096 12 mar 09:30 libccid.dylib.1.4.21

In my case the CCID driver is working but the driver binary is still wrong. I still have an half upgrade with the Info.plist file from CCID version 1.4.21 but the libccid.dylib binary is from CCID version 1.4.14.

Broken upgrade

If you had a broken upgrade with a file libccid.dylib either missing or pointing to a non existing file you may still have the same problem.

Proposed solution

The solution I proposed is still valid. See "OS X El Capitan and CCID driver upgrades".

I don't like the idea to install another CCID driver in /usr/local/ since that will/may create new problems when Apple fixes the original problem.

Conclusion

I reported a new bug at Apple as bug #26396810 "CCID smart card reader driver update not fixed in 10.11.5".

Update

On 24th May 2016, Apple closed my bug report as a duplicate:

Engineering has determined that your bug report (26396810) is a duplicate of another issue (26328490) and will be closed.

OS X El Capitan and CCID driver upgrades

Silent upgrade of the CCID driver

This is part of the series: "OS X El Capitan and smart cards: known bugs".

The first version of El Capitan 10.11 in September, 2015 was provided with the CCID driver version 1.4.14. See "OS X El Capitan and smart cards status" for more details.

I recently discovered that Apple upgraded the CCID driver in the minor upgrades (also thanks to Martin P. for the notice):

• Mac OS X 10.11.3 provides the CCID driver version 1.4.20 (driver released 5 August 2015)
• Mac OS X 10.11.4 provides the CCID driver version 1.4.21 (driver released 21 October 2015)

OS X 10.11

On Mac OS X 10.11 (or 10.11.0) I have:

$ ls -lR /usr/libexec/SmartCardServices/drivers
total 0
drwxr-xr-x  3 root  wheel  102 23 aoû  2015 ifd-ccid.bundle

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle:
total 0
drwxr-xr-x  5 root  wheel  170  5 oct  2015 Contents

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents:
total 56
-rw-r--r--  1 root  wheel  27616  5 oct  2015 Info.plist
drwxr-xr-x  4 root  wheel    136  2 oct  2015 MacOS
-rw-r--r--  1 root  wheel    471 23 aoû  2015 version.plist

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS:
total 176
lrwxr-xr-x  1 root  wheel      20  2 oct  2015 libccid.dylib -> libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  165888 17 sep  2015 libccid.dylib.1.4.14

OS X 10.11.3

On Mac OS X 10.11.3 I have:

$ ls -lR /usr/libexec/SmartCardServices/drivers
total 0
drwxr-xr-x  3 root  wheel  102 Aug 23  2015 ifd-ccid.bundle

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle:
total 0
drwxr-xr-x  5 root  wheel  170 Jan 28 10:05 Contents

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents:
total 24
-rw-r--r--  1 root  wheel  33873 Sep 23  2015 Info.plist
drwxr-xr-x  5 root  wheel    170 Jan 28 10:05 MacOS
-rw-r--r--  1 root  wheel    469 Sep 23  2015 version.plist

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS:
total 344
lrwxr-xr-x  1 root  wheel      20 Dec  9 15:06 libccid.dylib -> libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  165888 Oct 18  2015 libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  166096 Jan 14 03:06 libccid.dylib.1.4.20

OS X 10.11.4

On Mac OS X 10.11.4 I have:

$ pwd
/Volumes/ElCapitan/usr/libexec/SmartCardServices/drivers

$ ls -lR ifd-ccid.bundle/
total 0
drwxr-xr-x  5 root  wheel  170 Mar 22 13:23 Contents

ifd-ccid.bundle//Contents:
total 24
-rw-r--r--  1 root  wheel  36860 Dec 21 06:05 Info.plist
drwxr-xr-x  5 root  wheel    170 Mar 22 13:23 MacOS
-rw-r--r--  1 root  wheel    470 Dec 21 06:05 version.plist

ifd-ccid.bundle//Contents/MacOS:
total 344
lrwxr-xr-x  1 root  wheel      20 Sep 16  2015 libccid.dylib -> libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  165888 Sep  3  2015 libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  166096 Mar 12 09:30 libccid.dylib.1.4.21

Half upgrade

What is strange is that only the driver Info.plist file has been updated. A new binary driver is installed (libccid.dylib.1.4.20 or libccid.dylib.1.4.21) but not used.

The driver Info.plist file contains:

<key>CFBundleExecutable</key>
 <string>libccid.dylib</string>

So the driver binary is always the file libccid.dylib. And, as you can see from the previous commands libccid.dylib is just a symbolic link to the same libccid.dylib.1.4.14 file.

It looks like the upgrade is not complete:

• New readers present in the driver Info.plist file will be recognized
• Bugs fixes and new code from versions 1.4.15 to 1.4.21 are not used since the driver binary used is still at version 1.4.14.

Broken upgrade

Some/many people reported that the CCID driver was not working any more after the 10.11.4 upgrade. I have not (yet) reproduce this problem myself.

The driver configuration looks like this:

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS:
lrwxr-xr-x 1 root wheel         20    3 déc 08:37   libccid.dylib -> libccid.dylib.1.4.20
-rwxr-xr-x 1 root wheel     166096   12 mar 09:30   libccid.dylib.1.4.21

The symbolic link points to a non-existent libccid.dylib.1.4.20 file. So, of course, the driver is not loaded and the support of CCID readers is broken.

Error message in the system log file:

com.apple.ifdreader[219]: Failed to load IFD bundle executable:
'file:///usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/' with error: Error Domain=NSCocoaErrorDomain Code=4 "The bundle “CCIDCLASSDRIVER” couldn’t be loaded because its executable couldn’t be located." UserInfo={NSLocalizedFailureReason=The bundle’s executable couldn’t be located., NSLocalizedRecoverySuggestion=Try reinstalling the bundle., NSBundlePath=/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle, NSLocalizedDescription=The bundle “CCIDCLASSDRIVER” couldn’t be loaded because its executable couldn’t be located.}

Proposed solution

Because of System Integrity Protection [or wikipedia], it is forbidden to change/remove/add files in the /usr/ directory.

My proposal to fix the issue, until Apple provides a fix, is to:

1. disable SIP
2. fix the symbolic link using some think like
   

   cd /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS
   ln -sf libccid.dylib.1.4.21 libccid.dylib

3. enable SIP

Another solution

In the Apple developer forums "gtall" reported the same problem in "el capitan 10.11.4 unable to see smartcard" and "Metsma" posted a different workaround.

Maybe Apple will publish a Technical Note to give a better solution or, better, provide a version 10.11.5 with a fix for the CCID driver.

Conclusion

I reported the problem to Apple as bug #25873806 "CCID smart card reader driver update failed in 10.11.4".

That is the first time that Apple updates a smart card component (instead of just fixing bugs) with minor revisions of Mac OS X. Maybe it is a sign that Apple cares about smart cards?

My list of El Capitan known smart card bugs contains 7 unfixed bugs and 3 wanted features. There is still Apple work to do for the next (minor or major) release of Mac OS X.

Update

On 26th April 2016, Apple closed my bug report as a duplicate:

"Engineering has determined that your bug report (25873806) is a duplicate of another issue (25416818) and will be closed."