Sunday, November 20, 2016

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?").

SystemDurationTotal amountMean
Flattr6 years100.27 €16.71 €/year
Bitcoin2 years19.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.

Sunday, November 6, 2016

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 TDi for i≥1, if present, are structural.
TDi encodes in its 4 high-order bits the presence of at most 4 other interface bytes: TAi+1 (resp. TBi+1, TCi+1, TDi+1) follow, in that order, if the 5th (resp. 6th, 7th, 8th) bit of TDi is 1.
TDi encodes in its 4 low-order bits (4th MSbit to 1st LSbit) an integer T, in range [0..15]. T = 15 is invalid in TD1, and in other TDi qualifies the following TAi+1 TBi+1, TCi+1, TDi+1 (if present) as global interface bytes. Other values of T indicates a protocol that the card is willing to use, and that TAi+1 TBi+1, TCi+1, TDi+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#%
89943.39 %
0x8045922.15 %
0x8137217.95 %
0x40954.58 %
0x00693.33 %
0x91462.22 %
0xC0452.17 %
0xC1271.30 %
0x10221.06 %
0x50160.77 %
0x0190.43 %
0x0E80.39 %
0x1120.10 %
0x1F10.05 %
0x3110.05 %
0x3F10.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 TD1 is present. So no other TA2, TB2, TC2 or TD2 is present and no protocol is defined so the default T=0 will be used.

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

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

For 5% of ATRs TD1 = 0x40 so TC2 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 TD1 = 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.

TD1 = 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.

Saturday, October 1, 2016

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.

Friday, September 30, 2016

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

Wednesday, September 28, 2016

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.

Tuesday, September 27, 2016

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)

Saturday, September 17, 2016

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):

TC1, 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 TA1, R = Fi/Di (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 TA1, 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 TC1 defines a time value between characters transmitted 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#%
91043.92 %
0x0079238.22 %
0xFF28713.85 %
0x02291.40 %
0x03180.87 %
0x01150.72 %
0x0860.29 %
0x0540.19 %
0x0430.14 %
0x0B20.10 %
0x0910.05 %
0x1010.05 %
0x3F10.05 %
0x6410.05 %
0x8110.05 %
0xFE10.05 %


The default value is 0. But 38.22% of cards explicitly define TC1=0.
A total of 82.14% of cards use the default value.
TC1=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).