FLOSS Luxtrust

A FLOSS driver for the Luxtrust smartcard and signing stick, in the OpenSC framework is being developed by User:lmamane.

Some day, hopefully soon, it will just be part of OpenSC and you'll just install your distro's packets. In the meantime, here's how to get the code manually.

Status

This driver should work for every application that supports PKCS#11, in particular the Mozilla applications. So you can authenticate to websites, sign and decrypt email, etc.

However:

• It can use only the authentication key, not the signature (non-repudiation) key. Usage of the latter has to be cryptographically authenticated, so more work to develop.
• It does not work for the luxtrust.lu website, because this website
  • uses the signature key for authentication (yes, really!)
  • does not use the facilities provided by the browser, but a mix of Java code and binary object/machine code (!) that looks for the Gemalto libraries by hardcoded filename (!). Yes, it really is that bad; yes, it really downloads a shared library (.so/.dll) to your machine and uses that. "Obviously" (at least the GNU/Linux version of) that shared library is only available for IA32, so even if we would hack things to emulate the gemalto libraries perfectly, it still wouldn't work for amd64, sparc, PowerPC, mips or any other architecture.

So for now, you still need to use the Gemalto binary-only middleware to activate your smartcard, to revoke it on-line, etc.

Cards

Working:

• Luxtrust Signing Stick
• Luxtrust Smartcard

To be tested:

• French certigreffe

Websites

Working:

• etat.lu websites for companies
  • eTVA
  • company registry (RCSL)
• etat.lu websites for individuals
  • guichet.lu ([1])

Not working:

• luxtrust.lu

Unknown status

• bcee.snet.lu most probably does not work out of the box. It may or may not work if you link from /usr/lib/pkcs11/libgclib.so to openssl-pkcs11.so; I (lmamane) get unrelated Java error "cannot open zip file", so I don't know.

Applications

Working:

• Mozilla family
  • Firefox / Iceweasel: authentication to websites
  • Thunderbird / Icedove: email signing and decryption (with the auth certificate!)
• openssl command-line tool: MIME signing / decryption, PKCS1 RSA computations, reading certificates (both your own and also the LuxTrust ones), ...

Not working:

• Microsoft Windows-native applications (using CryptoAPI instead of PKCS #11)
  • Microsoft Internet Explorer
  • Smartcard authentication to a Microsoft Windows Active Directory domain

GNU/Linux & other Unixy systems

Get Source

Either download a complete ready tarball (snapshot from November 2010) from local cypherpunks, or do it manually to get the latest OpenSC:

Get a SVN trunk checkout of OpenSC (see [2]):

svn co http://www.opensc-project.org/svn/opensc/trunk opensc

apply patch from trac ticket #267:

wget https://www.opensc-project.org/opensc/raw-attachment/ticket/267/lem_gemsafe_v2_svnr5562.patch
cd opensc
patch -p0 < ../lem_gemsafe_v2_svnr5562.patch

If the tool segfaults in strlen when using a card with an empty label, please apply this patch [3]

Compile

Replace N with number of CPU cores in your system, plus one.

./bootstrap
./configure --prefix=/some/place
make -jN

Install

make install
#or, depending on choice of /some/place
sudo make install

Use

Now, /some/place/bin contains command-line utilities to manipulate your card. In particular, pkcs15-tool allows to read the contents of the card, change the user or admin PIN, unblock user PIN (using the admin PIN), ...

To use with an application that supports the PKCS#11 interface (e.g. the Mozilla applications), use /some/place/lib/opensc-pkcs11.so.

You can also "test" the card using the following command:

/some/place/bin/pkcs11-tool --module /some/place/lib/opensc-pkcs11.so -l -t

However, for the time being, this will fail with a confusing "User not logged in" when the test tries to use the signature key.

It is also very slow (up to 30 seconds) if you don't enable caching (see below).

Performance

By default, the card is very slow. The Luxtrust proprietary middleware has appropriate speed, because it caches most information on the computer. You can set up the open middleware to cache too.

1. Edit /some/place/etc/opensc.conf, and uncomment the "use_file_caching = true" line in the "framework pkcs15" section.
2. Initialize the cache using the following command: /some/place/bin/pkcs15-tool --learn-card

Microsoft Windows

We here show how to cross-compile from a Debian (or Ubuntu) GNU/Linux machine with mingw. You can also use Cygwin or compile directly on Windows.

Build

Get the tarball, or get the source with SVN.

svn co http://www.opensc-project.org/svn/build/trunk cross-build
cd cross-build
cd sources
wget http://www.cypherpunks.lu/opensc/opensc-0.12.0-rc1+lem.tar.gz
cd ..
MAKEFLAGS=-j1 CHOST=i586-mingw32msvc CBUILD=i686-pc-linux-gnu ./build

Parallel build does not work because of OpenSSL build system bug. Try this patch if you want a parallel build, it "Works For Me (tm)".

Install

This creates a .exe installer; run it.

Use

c:\program files\opensc\bin contains command-line utilities to manipulate your card. In particular, pkcs15-tool allows to read the contents of the card, change the user or admin PIN, unblock user PIN (using the admin PIN), ... Put that directory in your path or run from there.

To use with an application that supports the PKCS#11 interface (e.g. the Mozilla applications), use c:\program files\opensc\bin\opensc-pkcs11.dll; yes, that's bin/, not lib/, that's somewhat suprising / confusing.

As far as I (lmamane) know, a CryptoAPI driver for OpenSC (used by native applications, e.g. Internet Explorer, smartcard login to Windows, ...) is not available yet.

Development

Resources

Trac ticket upstream: [#267 https://www.opensc-project.org/opensc/ticket/267]

Lionel's git repo: git://git.debian.org/users/lmamane/opensc.git

Development happens in branch luxtrust of that git repo. This branch might be rebased on top of further imported commits from SVN, so if you fork it, please advise with Lionel.

Notes

The main next step is to get the driver able to use the signing key. This needs implementation of "secure messaging" (SM) so that the commands are cryptographically authenticated.

It seems support of SM is being implemented in the vtarasov/opensc-sm.trunk branch in the upstream SVN, so that's our best shot. However, this branch is not very active as of June 2011.

From preliminary analysis, it seems that bog-standard ISO 7816-4 SM with TripleDES is being used, in "authenticated header" mode (class byte 0C in APDU).

• For a "get public key", the INS=CB and "READ BINARY" (INS=C0) commands are authenticated.
• For a "sign/decrypt data", TODO

A good guess at the initial key used is: The contents of on-card file "00 01" encrypted with key "MISTRALGEMPLUSMK". To be checked whether this gives the same result on every card or varies (for each card, for each card type (LuxTrust, Certigreffe, ...), ...). Here's how to do that in the OpenSC driver code:

int r;
size_t i;
sc_path_t path;
sc_file_t *file;
u8 key[8];
unsigned char buf[256];

sc_format_path("00 01", &path);
r = sc_select_file(card, &path, &file);
SC_TEST_RET(card->ctx, SC_LOG_DEBUG_NORMAL, r, "select_file failed");
assert(file->size == 8);
r = sc_read_binary(card, 0, key, 8, 0);
if (r < 0)
  SC_TEST_RET(card->ctx, SC_LOG_DEBUG_NORMAL, r, "read_binary failed");
r = sm_encrypt_des_cbc3(card->ctx, "MISTRALGEMPLUSMK", key, 8, &buf, &i, 1);
if (r < 0)
  SC_TEST_RET(card->ctx, SC_LOG_DEBUG_NORMAL, r, "read_binary failed");

Footnotes

<references/>