Using the Austrian 'Buergerkarte' under Linux

Last updated on 2022-11-20 24 min read

Disclaimer

This web page is written primarily in English, but uses German words originating from the Austrian law. There seems to be little point in artificially translating these terms when they are special definitions of a law written in German. I have tried to explain the terms when I first use them - if something is unclear, feel free to send me an email.

Introduction

Since the beginning of 2000, the Austrian government has begun introducing its digital signature scheme in form for the so called “Bürgerkarte”. This implementation of the European signature law into national law requires the use of smart cards for storing private keys and computing cryptographic operations like encryption, decryption, creating and verifying digital signatures.

Update 2014

Fortunately, a lot of the set-up effort described below is no longer required due to the Java Webstart implementation of the “Bürgerkartenumgebung” called MOCCA. As long as the reader driver is properly installed and the reader is accessible from Java applications, no further steps should be necessary.

There are two practical way of getting a digital signature card, also known as “Bürgerkarte”, in Austria at this time: either by adding certificates onto a e-card, the heavily critizised Austrian health insurance card, or to a proven Maestro card handed out by Austrian banks. I took the latter approach, partly because BAWAG funded all involved cost for the first year. Adding the certificate was easy enough, the procedure just takes an Austrian passport and about 20 minutes at one of the A-Trust certified registration authorities, conveniently also provided by many BAWAG branches. (However, transferring the certificate to a new card, i.e. creating a new certificate with exactly the same data and revoking the old one, takes even longer. One should think that such a transfer could be done quickly…)

Update: I now use my e-card as a Bürgerkarte, simply because this approach is for free while using the bank card costs 13€ per year for the “qualified” A-Trust certificate. Activating the e-card by creating the certificate is not that hard and should even worksunder Linux when trustDesk Basic has been installed correctly as documented below. For activation, simply follow the process documented here. However, under Linux the first step yields an error that I haven’t been able to fix so far. For activation, use Windows right now…

It is important to note that this certification process actually produces two private keys along with certificates signed by A-Trust: a so-called “Geheimhaltungszertifikat”, which is just a normal certificate bound to the name listed in the passport and which can be used for “einfache digitale Signaturen” (simple digital signatures) e.g. email signatures, and a so-called “Signaturzertifikat”, which can be used for “sichere digitale Signaturen” (secure digital signatures) that conform to the signature law. Although many people describe the difference between the two that the former is secured by a 4-digit PIN and the latter by a 6-digit PIN (which is true but the least of their differences), the real difference is that using the latter is only “allowed” with especially certified applications.
For testing the “Bürgerkarten-Umgebung”, i.e. the combination of smart card, smart card reader, certificates on the card, and the software on the host, there is a web page that allows to test a complete transaction with the “Signaturzertifikat”.
 

Available software support

At the time of this writing , there are two different free-as-in-beer (only for Austrians) software packages that can be used under Windows, and partially for Linux and Mac OS/X: trustDesk Basic by IT Solution and HotSign by BDC (Windows only), which is distributed by A-Trust. Only trustDesk Basic supports the current version 1.2 of the specification at the time of this writing, so it is the preferred application for using governmental online services for the Bürgerkarte. The following has been tested with trustDesk Basic version 2.7.4 for Linux (which may not be the most recent one, please check here for updates).

Additionally, there is another software package that can be used with the certificates and keys stored on the Bürgerkarte: a.sign client by A-Trust, which integrates encryption and digital signature functionality with the “Geheimhaltungszertifikat” into standard software like Outlook. It can not be used for creating digital signatures that conform to the Austrian digital signature law, but since recently there is also a version for Linux. They even provide Debian packages, although they do not conform to Debian packaging guidelines at all and the provided apt-get repository has a broken Packages file that lets apt-get re-download the file each time (hint: the version information in the packages does not match the package version in the repository Packages file). I have only briefly tried this software under Linux, but it claims to integrate use of the “Geheimhaltungszertifikat” into Firefox and Thunderbird, probably via openssl. This page will be updated as soon as I have some practical experience with it.

Hardware: supported smart card readers

Of course, to access the smart card, a card reader is necessary. There are currently only few card readers certified for this use, including the Kobil KAAN, the Reiner SCT cyberJack pinpad and e-com, and the Towitoko CHIPDRIVE pinpad pro, which is equal to the SCM Microsystems SPR532. The former two are supported quite well under Linux, but the latter has its problems…

Using the SCM SPR532 under Linux

(This might be why some search engine has directed you to this page.)
For the time being, this page just describes how to set up a specific card reader under Linux so that it is capable of interacting with a smart card used as a Bürgerkarte. The names that I have found this reader under are “Towitoko CHIPDRIVE pinpad pro”, “Chipdrive Pinpad Pro”, “SCM SPR 532”, and “Chipdrive pinpad 532”. When looking for drivers, it’s probably easiest to look for SCM 532, since that is the chipset.

PC/SC API

There are two possible drivers for using it under Linux:

  • The driver provided directly by SCM does not seem to work with the only application I am using right now under Linux, specifically the easybank ebanking portal (previously I used the BAWAG ebanking portal). This driver only supports the PC/SC API, but not CT-API, which is the one used by the Linux version of the A-Trust a.sign client.
    To install this driver, get the archive from SCM (latest version at the time of this writing is 1.16) and unpack its content to the directory /usr/lib/pcsc/drivers/. This will create /usr/lib/pcsc/drivers/spr332ccidDriver.bundle/ with the PC/SC CCID driver a bit deeper in the hierarchy.
  • Updated: The open source driver for PC/SC only works reliable with firmware versions >= 5.04 and it is thus recommended to update the firmware if it is older. Previously, I stated that the firmware should not be updated, but kept at version 4.15 is the reader was to be used with a Bürgerkarte, because this firmware was certified for “sichere digitale Signaturen” at that time. In 2005, A-Trust explicitly stated that readers must be bought with exactly this version to be usable. Fortunately, the situation has improved; nowadays, all firmware versions >= 4.15 will be accepted by the BKU (Bürgerkartenumgebung) software, i.e. trustDesk Basic, for use with the “Signaturzertifikat”. I got this information from Mr. Hirschbügl of A-Trust, their Linux and card reader expert. Subsequently, I updated my SCM SPR532 to the most recent firmware version 5.10 (firmware update under Windows only, also included in the most recent driver package version 1.84) at the time of this writing and can confirm that the BKU software still works under Windows (although it took about 4 reboots to get it to work again after the firmware update…). The biggest advantage of this firmware over the old version 4.15 is that it officially supports PC/SC 2.0 with the ability to use the keypad, but it also improves compatibility with the open source driver.

I highly recommend to use the open source driver with a recent firmware, at least 5.10 (version 5.09 is known to A-Trust to have some problems, and libccid 1.3 no longer works with the old firmware at all, not even using the steps given below). Under Debian/GNU Linux starting with the sarge release, this is simple to do:

  1. Install the packages pcscd (tested with version 1.4.4-2), pcsc-tools, and libccid (tested with version 1.3.1-1), and libpcsclite-dev (please see below for details).
  2. Execute /etc/init.d/pcscd restart
  3. After plugging in the card reader into an USB port, the syslog should show something similiar to the following:

Nov 30 22:07:17 localhost pcscd: pcscdaemon.c:507:main() pcsc-lite 1.4.4 daemon ready.
Nov 30 22:07:37 localhost kernel: usb 2-1: new full speed USB device using uhci_hcd and address 6
Nov 30 22:07:37 localhost kernel: usb 2-1: configuration #1 chosen from 1 choice
Nov 30 22:07:37 localhost pcscd: hotplug_libusb.c:478:HPAddHotPluggable() Adding USB device: 002:006
Nov 30 22:07:37 localhost pcscd: readerfactory.c:1113:RFInitializeReader() Attempting startup of SCM SPR 532 (60201EC1) 00 00
using /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so.1.3.1
Nov 30 22:07:37 localhost pcscd: readerfactory.c:980:RFBindFunctions() Loading IFD Handler 3.0
Nov 30 22:07:37 localhost pcscd: ifdhandler.c:1239:init_driver() LogLevel: 0x0003
Nov 30 22:07:37 localhost pcscd: ifdhandler.c:1249:init_driver() DriverOptions: 0x0000
Nov 30 22:07:37 localhost pcscd: ifdhandler.c:77:IFDHCreateChannelByName() lun: 0, device: usb:04e6/e003:libusb:002:006
Nov 30 22:07:37 localhost pcscd: ccid_usb.c:233:OpenUSBByName() Manufacturer: Ludovic Rousseau (ludovic.rousseau@free.fr)
Nov 30 22:07:37 localhost pcscd: ccid_usb.c:243:OpenUSBByName() ProductString: Generic CCID driver v1.3.1
Nov 30 22:07:37 localhost pcscd: ccid_usb.c:249:OpenUSBByName() Copyright: This driver is protected by terms of the
GNU Lesser General Public License version 2.1, or (at your option) any later version.
Nov 30 22:07:37 localhost pcscd: ccid_usb.c:397:OpenUSBByName() Found Vendor/Product: 04E6/E003 (SCM SPR 532)
Nov 30 22:07:37 localhost pcscd: ccid_usb.c:399:OpenUSBByName() Using USB bus/device: 002/006
Nov 30 22:07:37 localhost pcscd: ccid_usb.c:752:get_data_rates() IFD does not support GET_DATA_RATES request: Broken pipe
Nov 30 22:07:38 localhost pcscd: ifdhandler.c:271:IFDHGetCapabilities() lun: 0, tag: 0xFAE
Nov 30 22:07:38 localhost pcscd: ifdhandler.c:313:IFDHGetCapabilities() Reader supports 1 slot(s)

You should then be able to access a card in that reader, e.g. by using pcsc_scan. Starting pcsc_scan should show success in connecting to the reader:

PC/SC device scanner

V 1.4.0 (c) 2001-2004, Ludovic Rousseau <ludovic.rousseau@free.fr>

PC/SC lite version: 1.2.9-beta6

Scanning present readers

0: SPR 532 00 00

Sat Jul  2 12:12:47 2005

 Reader 0 (SPR 532 00 00)

        Card state: Card removed,

and, after putting a card into the slot, should be able to query it (this example is with an Austrian Maestro card, which is not supported and probably never will be due to a closed and closely restricted card operating system):

Sat Jul  2 12:13:12 2005

 Reader 0 (SPR 532 00 00)

        Card state: Card inserted,

        ATR: 3B BF 11 00 81 31 FE 45 45 50 41 00 00 00 00 26 35 87 90 00 00 00 00 F5

ATR: 3B BF 11 00 81 31 FE 45 45 50 41 00 00 00 00 26 35 87 90 00 00 00 00 F5

+ TS = 3B --> Direct Convention

+ T0 = BF, Y(1): 1011, K: 15 (historical bytes)

  TA(1) = 11 --> Fi=372, Di=1, 372.000 cycles/ETU

  TB(1) = 00 --> Programming Param P: 0 Volts, I: 0 milli-Ampères

  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1

-----

  TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1

-----

  TA(3) = FE --> IFSC: 254

  TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5

+ Historical bytes: 45 50 41 00 00 00 00 26 35 87 90 00 00 00 00 F5

Possibly identified card:

        NONE

The opensc tools (Debian package opensc) should also be able to access the reader. Running opensc-tool -l should be able to query the card reader:

Readers known about:

Nr.    Driver     Name

0      pcsc       SPR 532 00 00

1      openct     OpenCT reader (detached)

2      openct     OpenCT reader (detached)

3      openct     OpenCT reader (detached)

4      openct     OpenCT reader (detached)

5      openct     OpenCT reader (detached)

 

It is also possible to access at least the normal certificate under Linux even with the old firmware (but without PC/SC 2.0 and thus without keypad support). To force the driver to accept the old firmware, the following steps are necessary:

  1. Modify /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist: ifdDriverOptions should be set to 0x0004 to make it work with the old firmware version. Update: Versions >= 0.9.4 of the libccid Debian package now keep the Info.plist file as a config file at /etc/libccid_Info.plist, which means that changes to the file will no longer be overwritten by package updates. Very good.
  2. Execute /etc/init.d/pcscd restart
  3. Then you should see in the syslog that the firmware is accepted (this is using older pcscd and libccid versions, which also work):
Jul  2 12:11:29 styx kernel: usb 2-2: new full speed USB device using uhci_hcd and address 6
Jul  2 12:11:29 styx pcscd: ifdhandler.c:998:init_driver LogLevel: 0x0003
Jul  2 12:11:29 styx pcscd: ifdhandler.c:1009:init_driver DriverOptions: 0x0004
Jul  2 12:11:29 styx pcscd: ifdhandler.c:67:IFDHCreateChannelByName lun: 0, device: usb:04e6/e003:libusb:002:006
Jul  2 12:11:29 styx pcscd: ccid_usb.c:225:OpenUSBByName Manufacturer: Ludovic Rousseau (ludovic.rousseau@free.fr)
Jul  2 12:11:29 styx pcscd: ccid_usb.c:235:OpenUSBByName ProductString: Generic CCID reader v0.9.3
Jul  2 12:11:29 styx pcscd: ccid_usb.c:241:OpenUSBByName Copyright: This driver is protected by terms of the
GNU General Public License version 2, or (at your option) any later version.
Jul  2 12:11:29 styx pcscd: ccid_usb.c:376:OpenUSBByName Found Vendor/Product: 04E6/E003 (SPR 532)
Jul  2 12:11:29 styx pcscd: ccid_usb.c:378:OpenUSBByName Using USB bus/device: 002/006
Jul  2 12:11:29 styx pcscd: ccid_usb.c:672:ccid_check_firmware Firmware (4.15) is bogus! but you choosed to use it
Jul  2 12:11:30 styx pcscd: ifdhandler.c:239:IFDHGetCapabilities lun: 0, tag: 0xFAE

Other APIs

Only some applications work with the PC/SC API, seemingly because it brings forth a rather large middleware layer. A lot of applications seems to have been designed for the CT-API, but unfortunately SCM does not provide a CT-API driver for the SCM SPR532 for Linux yet. Currently, there seem to be two options:

  • openct: This library implements (among others) the CT-API for a selection of card readers. There is also a generic USB CCID driver, which is the standard that the SCM SPR532 actually implements. I did not yet have any luck with this CCID driver in openct, though success has been reported, albeit explicitly with the updated firmware. Additionally, this document only talks about PC/SC support, which is provided in a working form by libpcsc (see above).

  • libchipcard: This library also offers access to various card readers, including support for the generic PC/SC USB CCID drivermentioned above. libchipcard does not seem to be implemented on top of the PC/SC middleware and thus does not seem to use the pcscd daemon. Instead the last link suggests to compile a private version of that USB CCID driver just for libchipcard. I have not yet tried to recompile. This page suggests that it should work with both implementations, i.e. the one by SCM, and the open source driver. And it does indeed seem to find the reader:

    After installing the libchipcard2-tools package under Debian (version >= 1.9.15.99), stopping pcscd (because libchipcard also accesses the reader directly and thus conflicts with it), and executing /etc/init.d/libchipcard2-tools start, running chipcard-tool list prints:

    Server: 43f3af40

  Readers:

  - auto1-scm (scm, port 0)

    when the SCM driver is installed and

    Server: 43f3b054

  Readers:

  - auto1-ccid_scm_x32 (ccid_scm_x32, port 0)

    when the libccid package is installed (and configured to cope with the old firmware as described above). I did not get any further yet, more to follow.

Using the Reiner SCT cyberJack e-com under Linux

Since very recently (Novermber 2007), I also own a Reiner SCT cyberJack e-com reader in addition to my (now finally functional) SCM SPR532. There are some reasons for spending the money for two readers, but mostly because Reiner SCT readers are very well supported under Linux and thus mean significantly less tinkering effort to get them to work. This is thanks to the company itself, which has been providing drivers for both APIs (the “European” CT-API and the “Microsoft” PC/SC) under the LGPL for quite some time. Companies that are friendly to the open source community - Reiner SCT not only provides a specification but actual, open source code - should be supported, and so I have voted with my money. Another reason is that the e-com reader also features a display to show what the reader/smartcard combination is supposed to sign, which makes it an interesting piece of hardware to play with from a security research point of view. However, all of the steps documented below should equally apply to the cyberJack pinpad reader, which is a subset of the e-com (no display, and can’t execute its own applications).

  1. Download the libctapi-cyberjack2 (unsurprisingly, the CT-API support, tested with version 3.0.5-1) and optionally the ifd-cyberjack2 (PC/SC support, to be used e.g. with pcscd) packages directly from Reiner SCT.
  2. Install these packages. This will create a group called cyberjack to which all users that should be allowed to access the reader must be added. Therefore, it is best to add your current user account at this stage and login again.
  3. Create a symlink /usr/lib/libctapi.so to /usr/lib/libctapi-cyberjack.so and execute ldconfig. This symlink is necessary e.g. for CTScan from the a.sign Client to find and use the library in the first place (but shouldn’t be required for others, and can be removed after successfully executing CTScan).
    Update: This symlink is not necessary, as CTScan accepts the library as a command line parameter. It is sufficient to just call /bin/CTScan /usr/lib/libctapi-cyberjack.so. Thanks to Clemens Heuberger for this hint!
  4. Optionally, update the reader firmware using /usr/bin/cjflash. Yes, that’s right! They even provide an official firmware update tool for Linux! I hope that more companies will follow Reiner SCT in this regard.
  5. Verify that the reader can be accessed using CT-API by executing /usr/bin/cyberjack, also provided by the libctapi-cyberjack2 package. This will create 3 files in the current directory, so I recommend to execute this from within /tmp. Note that pcscd needs to be stopped before executing the cyberjack diagnostic tool, because it claims the reader and doesn’t allow direct CT-API access when loaded. You should see something like:
BEGIN: ermittle Distribution (0/6)

END  : ermittle Distribution (1/6) [OK]

BEGIN: ermittle Systeminformationen (1/6)

END  : ermittle Systeminformationen (2/6) [OK]

BEGIN: ermittle Gruppeninformation (2/6)

END  : ermittle Gruppeninformation (3/6) [OK]

BEGIN: ermittle laufende Dienste (3/6)

END  : ermittle laufende Dienste (4/6) [OK]

BEGIN: ermittle installierten Treiber (4/6)

END  : ermittle installierten Treiber (5/6) [OK]

BEGIN: ermittle und teste angeschlossene Leser (5/6)

END  : ermittle und teste angeschlossene Leser (6/6) [OK]

Es wurden 3 Dateien im aktuellen Verzeichnis angelegt:

- cyberjack-report.log: Enthaelt die Ergebnisse der Tests

- cyberjack-hints.log : Enthaelt moeglicherweise Hinweise

                        zu gefundenen Problemen und deren

                        Behebung.

- cyberjack.xml       : Enthaelt die Testergebnisse in fuer

                        den Support aufbereiteter Form.

Bitte senden Sie bei Problemen die Datei "cyberjack.xml"

an den Linux-Support von Reiner SCT.

and cyberjack-report.log should contain something similar to:

Distribution: Debian lenny/sid

System: Linux, 2.6.22-3-686, #1 SMP Mon Nov 12 08:32:57 UTC 2007, i686

Treiberdatei: /usr/lib/libctapi-cyberjack.so

Treiberversion: 3.0.5.64

Leser gefunden an 002/008: Cyberjack Ecom (a) (0c4b:0400)

Benutzer hat alle noetigen Rechte fuer den Leser an 002/008.

Firmware info for [usb:0c4b/0400:libusb:002:008]: [DESCTCJECA V3.0; Rev.  23]

Alle gefundenen Leser sind ansprechbar.

When the optional ifd-cyberjack2 package is installed, the reader can also be used with pcscd. After starting pcscd (tested with version 1.4.4-2), the reader should be detected with syslog lines like:

Nov 30 22:40:33 localhost pcscd: pcscdaemon.c:507:main() pcsc-lite 1.4.4 daemon ready.
Nov 30 22:40:33 localhost pcscd: hotplug_libusb.c:478:HPAddHotPluggable() Adding USB device: 002:008
Nov 30 22:40:33 localhost pcscd: readerfactory.c:1113:RFInitializeReader() Attempting startup of
REINER SCT CyberJack ecom_a (0000000000) 00 00 using /usr/lib/pcsc/drivers/ifd-cyberjack.bundle/Contents/Linux/ifd-cyberjack.so
Nov 30 22:40:33 localhost pcscd: readerfactory.c:980:RFBindFunctions() Loading IFD Handler 3.0
Nov 30 22:40:35 localhost pcscd: hotplug_libusb.c:402:HPEstablishUSBNotifications() Driver
ifd-cyberjack.bundle does not support IFD_GENERATE_HOTPLUG. Using active polling instead.
Nov 30 22:40:35 localhost pcscd: hotplug_libusb.c:411:HPEstablishUSBNotifications() Polling forced every 1 second(s)

And pcsc_scan should detect both the reader and a smart card (again an Austrian Maestro card in this case):

PC/SC device scanner
V 1.4.11 (c) 2001-2007, Ludovic Rousseau <ludovic.rousseau@free.fr>
Compiled with PC/SC lite version: 1.4.4
Scanning present readers
0: REINER SCT CyberJack ecom_a (0000000000) 00 00

Fri Nov 30 22:41:35 2007
 Reader 0: REINER SCT CyberJack ecom_a (0000000000) 00 00
  Card state: Card removed,

Fri Nov 30 22:42:43 2007
 Reader 0: REINER SCT CyberJack ecom_a (0000000000) 00 00
  Card state: Card inserted,
  ATR: 3B BF 11 00 81 31 FE 45 45 50 41 00 00 00 00 33 91 84 54 00 00 05 78 FE

ATR: 3B BF 11 00 81 31 FE 45 45 50 41 00 00 00 00 33 91 84 54 00 00 05 78 FE
+ TS = 3B --> Direct Convention
+ T0 = BF, Y(1): 1011, K: 15 (historical bytes)
  TA(1) = 11 --> Fi=372, Di=1, 372 cycles/ETU (9600 bits/s at 3.57 MHz)
  TB(1) = 00 --> VPP is not electrically connected
  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
-----
  TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1
-----
  TA(3) = FE --> IFSC: 254
  TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5
+ Historical bytes: 45 50 41 00 00 00 00 33 91 84 54 00 00 05 78
  Category indicator byte: 45 (proprietary format)
+ TCK = FE (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B BF 11 00 81 31 FE 45 45 50 41 00 00 00 00 33 91 84 54 00 00 05 78 FE
3B BF 11 00 81 31 .. 45 45 50 41 00 00 00 00 .. .. .. .. 00 00 .. .. ..
        Austrian Quick E-purse

Software

The final step is now to use a real application with the Bürgerkarte. Lacking Linux support for a Bürgerkarten-Umgebung, i.e. a software package that is certified to access the Signaturzertifikat, governmental applications can not yet be used under Linux (e.g. the test page or handing in the tax statement, which it is one of the applications I actually use with by Bürgerkarte). One of the applications I use and which works very well is the login to the easybank ebanking portal.

Java applets accessing the card reader, specifically the SecCommerce SecAuthenticator

General note about SecCommerce SecAuthenticator: I found that, whenever the reader configuration changes, SecAuthenticator might have problems detecting this. So when e.g. switching from PC/SC to CT-API, switching readers, or even just when updating pcscd to a newer release, it helps to remove all local settings with “rm ~/.seccommerce/*” and restart Firefox (and thus the Java applet VM). Make sure that no firefox-bin process remains running in the background.

To access it, just point Mozilla/Firefox/Iceweasel or Konqueror (tested with Konqueror and Iceweasel on Debian GNU/Linux testing/unstable as of November 2007) to the web page, and try to log in with the smart card (this will of course only work for BAWAG and easybank customers, but it should apply to other Java applets/applications too). This will install a Java applet that tries to access the smart card. If it hangs with a message “PC/SC: DLL laden”, then this has a simple reason that cost me roughly 2 days of debugging: the required native library libpcsclite.so can not be found. There is mostly the Java applet to blame. It could just tell us that it is looking for a library called exactly libpcsclite.so and that it can not find it instead of handing indefinitely (which led me to search for communication problems with the reader or the pcscd daemon). The Debian package does not install the necessary symlink /usr/lib/libpcsclite.so -> libpcsclite.so.1.0.0 due to the Debian policy. It is instead contained in the corresponding development package libpcsclite-dev. Installing the development package thus makes the SecCommerce Java applet work. Upon login, it creates a digital signature with the Geheimhaltungszertifikat to authenticate.

Updated: The SecCommerce SecAuthenticator Java applet that is used for the BAWAG and easybank login stopped to support the PC/SC API a while ago (with the official reason that PC/SC did not allow secure PIN entry with the embedded keypad), but now implements it again, including PC/SC 2.0! This is very good news, because now SecCommerce SecAuthenticator works with the SCM SPR532 under Linux and allows to use the “Geheimhaltungszertifikat” and the reader keypad. Thanks to Tilo Kienitz of SecCommerce for telling me about the update and getting me to try it again. One thing to note is that - in contrast to using the applet with the SCM SPR532 under Windows - the green “tickmark” button needs to be pressed after entering the 4-digit PIN to unlock the “Geheimhaltungszertifikat”. Otherwise it will simply abort with a time-out.

With the Reiner SCT cyberJack e-com reader and pcscd active as described above, the SecCommerce SecAuthenticator applet is also able to log in with the smart card using the reader keypad. With this reader - can’t write “in contrast” this time because we’re back where we started ;-) - the key presses seem to immediately trigger events on the host (the applet in this case), and the applet therefore continues right after entering the fourth digit of the PIN, without the need to press the green “OK” button.
Without pcscd, i.e. using the CT-API library directly, I have so far been unsuccessful to log in with SecAuthenticator.

 

Using trustDesk Basic as BKU (Bürgerkartenumgebung)

Recently, IT Solution began publishing Linux versions of trustDesk Basic. Installation has also been documented elsewhere, but I repeat the basic steps here for the sake of completeness:

  1. Download the most recent version (2.7.4 at the time of this writing). If you are running Debian GNU/Linux etch, lenny, or newer, or any other fairly recent Linux distribution that comes with a working Java VM (e.g. the sun-java6-jre package), then I recommend to get the version without the included JRE.

  2. cd /opt; sudo tar xvfz <download path>/tdb274.tgz

  3. cd /opt/tdb-release; ./setup.sh
    Here select the autostart option for your desktop environment(s), e.g. KDE. This must be executed once as root (e.g. with sudo) so that the setup tool can change the path in /opt/tdb-release/autostart.sh and once for each user that should run the software. When executed for a user, it creates (e.g. for KDE) an autostart file ~/.kde/Autostart/its-trustDeskbasic.desktop to automatically load trustDesk Basic in the background when this user logs in.

    Setting autostart options for the current user

     

  4. Then, at least for KDE (I haven’t tried with Gnome), add the trustDesk mini program to kicker - this is the only way to actually interact with the trustDesk Basic process running in the background.

    Adding the trustDesk mini program to kicker

     

  5. Now the reader needs to be configured. Note that I have not managed to get trustDesk Basic to work with PC/SC under Linux, i.e. not with pcscd running. This also means that it will not work with the SCM SPR532, but only with the Reiner SCT cyberJack readers for the time being (because only these come with a CT-API implementation). The SecCommerce SecAuthenticator applet demonstrates pretty well that both readers and their keypads can be accessed successfully with pcscd, so it should only be a matter of time until trustDesk Basic should be able to use it as well. For now, stop pcscd with /etc/init.d/pcscd stop.
    From the new icon on the kicker bar, select “Konfiguration und Updates”, then “Konfiguration”. Do not use the automatic configuration option. With pcscd running, this actually detects both readers (SCM SPR532 and Reiner SCT cyberJack e-com) when they are connected, but aborts later on when the 6-digit PIN should be entered when using the smart card.
    Instead, choose the expert mode configuration

    Choosing expert mode setup

    and manually enter the path to the cyberJack CT-API library and port number 1.

    Manually configuring CT-API for the reader

    For security reasons,the option “Software-PIN Eingabe erlauben” should be disabled.

That’s it, the BKU should now be up and running. The test page should work and all tests should successfully run through. I have verified that both Konqueror and Firefox/Iceweasel work with this configuration as of November 2007.

a.sign Client

I have not played much with the A-Trust a.sign Client so far. This is supposed to integrate the A-Trust certificates on smart cards with other applications like Firefox and Thunderbird (and supposedly more applications using openssl under Linux).
Installing a.sign Client under Debian is simple enough:

  1. Add the line
    deb http://www.a-trust.at/DownloadVerzeichnis/linux unstable main
    to /etc/apt/sources.list

  2. apt-get (or aptitude) install asignClient

  3. It is now recommended to set asignClient to hold (e.g. in aptitude), otherwise every update run will update asignClient with the same version over and over again. The reason is a broken Packages file in the apt repository.

  4. Execute /bin/CTScan, which should (when the /usr/lib/libctapi.so symlink is set as described above) print something like:

    ReaderTime=15000
CT-Library libctapi.so gefunden.
[Reader0]
CTAPI=libctapi.so
CTPort=1
isSecure=Yes
Reader=cyberJack e-com
Status0=4445534354434a4543412056332e30
UseGUI=Yes
Vendor=REINER SCT
  Port 2: Initialisierung fehlgeschlagen.
  Port 3: Initialisierung fehlgeschlagen.
  Port 4: Initialisierung fehlgeschlagen.
  Port 5: Initialisierung fehlgeschlagen.
  Port 6: Initialisierung fehlgeschlagen.
  Port 7: Initialisierung fehlgeschlagen.
  Port 8: Initialisierung fehlgeschlagen.
  Port 9: Initialisierung fehlgeschlagen.
#[Trace]
#Filename=
#LogLevel=128

  5. If that worked correctly, then the results should be written to /etc/a.sign Client, e.g. with
    sudo sh -c “/bin/CTScan > /etc/a.sign\ Client”

  6. Now modify /etc/a.sign Client to use the library libctapi-cyberjack.so instead of libctapi.so:

    --- /etc/a.sign Client~ 2007-12-01 14:28:01.000000000 +0100
+++ /etc/a.sign Client  2007-12-01 14:28:24.000000000 +0100
@@ -1,6 +1,6 @@
 ReaderTime=15000
 [Reader0]
-CTAPI=libctapi.so
+CTAPI=libctapi-cyberjack.so
 CTPort=1
 isSecure=Yes
 Reader=cyberJack e-com

    After that, the symlink /usr/lib/libctapi.so may be removed again so as not to have anything under /usr/lib that is not managed by dpkg.

  7. Start the a.sign Client with
    AClient

If everything is set up correctly, this should now display the reader and the certificates on the card.

Summary

Support for the Austrian Bürgerkarte under Linux has been improving drastically over the past 2 years: from non-workable in any sense to a working and stable solution at least with one reader. However, there are still too many combinations that don’t work. In particular, the SecCommerce SecAuthenticator applet only works with PC/SC (2.0), and trustDesk Basic only works with CT-API. This means that I need to start pcscd when I want to login using SecAuthenticator, and to stop it for using trustDesk Basic. Not nice.

The combinations of hardware, software, and APIs I have tried so far can be summarized quickly:

 
  SecAuthenticator trustDesk Basic
(broken PC/SC support)
asign Client
(no PC/SC support)
e-com with CT-API no yes yes
e-com with PC/SC yes no no
SPR532 with CT-API (no driver support, maybe openct would work?) no no no
SPR532 with PC/SC 2.0 yes no no

If you have tried other combinations, please let me know and I would be happy to update this document and the summary.

Linux Smartcard Digital Identity Hardware
René Mayrhofer
René Mayrhofer
Professor of Networks and Security & Director of Engineering at Android Platform Security; pacifist, privacy fan, recovering hypocrite; generally here to question and learn