Free software and smartcards

Last week, we took a look at the Nitrokey Pro, a compact USB peripheral that embeds a microcontroller for performing one-time password (OTP) authentication and includes a GnuPG-compatible smartcard element. One interesting facet of any such product-related story is the chance to reflect on the amount of trust that smartcards inspire in members of the free-software community. It is generally accepted that the secure storage provided by a smartcard is far superior to a hard disk when it comes to protecting one's keys and other secrets. But the world of smartcard development is not free from its share of concerns for those who care about software freedom. Few of the products available let one work entirely with free tools, and most of the projects involved suffer from the same challenges that plague any development niche: lack of time, documentation, and resources.

For the record, much of what follows is the outcome of my private research into the topic to better understand the YubiKey NEO, Nitrokey Pro, and other smartcards that offer some form of cryptographic signing or authentication feature. Consequently, it is far from comprehensive, but it will hopefully be useful to some in the free-software community, since those are the features of leading interest.

In the world at large, of course, the majority of smartcards are deployed by banks, cell phone networks, and other such commercial ventures. The ISO 7816 series of specifications standardizes many aspects of these devices, including the physical size and electrical pin-out of the contact pads (for contact cards), the low-level command set, and the serial protocols used to communicate between the card and the reader. Key generation and other cryptographic functions are generally hardware-level features of the card's CPU or some coprocessor. Thanks to the dominance of the commercial market, user-configurable cards almost always follow these standards.

What is an OpenPGP card?

Software developers are usually interested in cards that also adhere to the OpenPGP Card standard. This is a functional specification (currently at revision 2.1 [PDF]) that describes an API for the card to interact with an OpenPGP application (including GnuPG and others). It defines the commands the code running on the card must respond to as well as the relevant data that must be made available to the OpenPGP application (plus the data that must be stored on the card but remain inaccessible). The inaccessible data includes the key material itself; other data includes counters (such as the signature counter), metadata fields, timestamps, and so on.

Crucially, the OpenPGP format does not implement a filesystem on the card's storage. Rather, data is stored as Data Objects (DOs) in TLV (Tag, Length, Value) format, which the card must return in response to GET DATA commands. Nothing in the OpenPGP Card specification restricts how the application running on the card's CPU is implemented, however, nor how the DO structures are stored in ROM.

As a practical matter, though, OpenPGP Card manufacturers are few, so there are not many competing implementations. Cards include a vendor ID; only 14 vendors are recognized by GnuPG at present. Of those vendors, some either no longer sell OpenPGP Cards or they do not sell to the public. Several of the others (such as Yubico) do not implement OpenPGP Card support directly, but do so instead through Java Card, which we will look at below.

The popular OpenPGP cards sold by Kernel Concepts and those given as a benefit to Free Software Foundation Europe (FSFE) members are both manufactured by ZeitControl. At present, the OpenPGP smartcard embedded in Nitrokey devices is also a SIM-sized ZeitControl card (although Nitrokey has expressed interest in changing this for future hardware revisions).

ZeitControl's cards run an operating system called BasicCard. Like the name implies, the application-execution environment of the card is a BASIC interpreter (specifically, ZC-Basic). The OpenPGP Card products come with ZeitControl's OpenPGP-compatible application pre-installed; the source code is not available. ZeitControl sells a BasicCard development kit that consists of a Windows SDK and a card reader. There is little in the way of documentation available otherwise, although the company site says some source code is provided with the BasicCard development kit.

Interestingly enough, Yutaka Niibe of the Free Software Initiative of Japan (FSIJ) has implemented the OpenPGP Card specification in the gnuk token project, which is a fully free-software stack, but the gnuk hardware is not a smartcard.

From the PC's side, GnuPG can communicate directly with OpenPGP Card smartcards, provided that a supported card reader is available. The GnuPG code includes its own driver for the USB Chip Card Interface Device (CCID) class. The other widely implemented reader standard is Windows's Personal Computer/Smart Card (PC/SC). Free-software drivers for PC/SC readers are available, and GnuPG can access them if given the --disable-ccid switch.

OpenSC and PKCS#11

Most other smartcards in the wild run some form of proprietary application on top of a proprietary card OS. The OpenSC project maintains drivers to interact with many such cards (some implemented via reverse-engineering), including national ID cards, transit cards, and more.

The project also has its own command-line tool for interacting with OpenPGP cards. But OpenSC's emphasis is on supporting PKCS#11, a general-purpose application-level API and ABI for security and cryptographic operations. The OpenSC OpenPGP Card tool reads DOs from the OpenPGP card and emulates a filesystem for the purpose of interfacing with the other pieces of the OpenSC toolbox. If one uses any of the other OpenSC tools to initialize the card, it will wipe out the onboard OpenPGP application and create the filesystem and data structures it needs for PKCS#11 support—assuming that the card is writable at all, which ZeitControl's OpenPGP cards are. That is why (as we saw last week) the Nitrokey Pro can be tricky to use with both OpenPGP and a PKCS#11 program.

For general, non-OpenPGP smartcards, OpenSC offers read-only support for some brands and full configurability for others. The fully configurable cards can be formatted with OpenSC's PKCS#11 tools; OpenSC provides an interface library that runs on the host PC and accesses the cryptographic features of the card. The advantage of this approach is that many applications can implement support for PKCS#11 with relative ease. The configurable cards, however, likely still run a proprietary card OS; they simply allow OpenSC's tools to reformat the storage area and they offer the necessary low-level cryptographic functions.

Java Card

Of the other ways one could format a smartcard, the most flexible option available at present is perhaps the Java Card standard, which means that the card runs a Java Runtime Environment (JRE) that supports the Java Card subset of the Java language.

This, too, does not mean that the underlying card OS is free software, however. One of the most popular Java Cards for aftermarket programming is NXP's, for example, which runs Java Card Open Platform (JCOP), a Java-Card–oriented card OS formerly developed at IBM. Despite the name, it is not open source.

Java Card SDKs are frequently proprietary products sold by the card vendors (see Gemalto's developer kit, for example), but one can download Java Card development tools from Oracle (if one is willing to check the click-through agreement box) for free. At the moment, however, the Oracle development kit is for Windows only but it is reported to work on Linux as well.

The good news is that, even if the card OS remains proprietary, the execution environment does still allow for free-software applications (in this case, Java applets) to be written and loaded onto the card. This is because of the Global Platform interaction specification, which defines APIs for installing, updating, and otherwise interacting with Java Card applets.

Global Platform also offers a set of tools for working with applets and Java Cards. Although it seems to be under fairly active development, there is also a fork available on GitHub, maintained by Martin Paljak, that may be worth checking out instead.

Potential applet developers should take a look at Paljak's AppletPlayground, which contains links to more than a dozen open-source applets, implementing features ranging from PGP support to hardware wallets to payment and identification card standards.

For OpenPGP, Joeri de Ruiter's Java Card OpenPGP Card applet implements the OpenPGP card specification on the Java Card JRE. De Ruiter's applet is the one shipped by Yubico on the YubiKey NEO; GunPG recognizes the applet as a standard OpenPGP Card, so no additional configuration is required. Some Java Cards may also support PKCS#11, but this is atypical because the PKCS#11 API expects direct access to the card's filesystem—something that Java Cards, as a rule, do not offer. The OpenSC project has a wiki page tracking the status of several cards.

Challenges, responses

From a free-software perspective, it is troubling that no smartcards seem to offer a card OS for which source code is available. The likelihood of a backdoor being present in such OSes is rather small, but there is still the possibility of security bugs in the card or its application-execution environment to be concerned about. There are several small card-OS vendors, the majority of whom sell card hardware as well. It would be interesting to see whether or not any of them could be convinced to engage with the free-software community.

The Oracle Java Card SDK provides debugging and testing tools, including an emulator, which is undoubtedly why there are free-software Java Card applets being developed at all. It also helps that Java Card applets seem to enjoy a reputation for genuinely living up to Java's "write once, run anywhere" philosophy. Almost all other smartcard application-execution environments, from ZC-Basic to Microsoft's Visual Basic and C# smartcard platforms, lack even this basic level of tool availability for Linux developers. When there is software to be found, it is rarely in any form of public version control.

So there is clearly room for improvement where compilers and tooling are concerned; the same can also be said for documentation. Many of the sites one reads to get a handle on the development world are littered with dead links—including everything from device manufacturers that are now owned by holding companies to the missing "Release Notes" linked to from Oracle's official Java Card site. Smartcard development is not alone in this regard, but it is unfortunate. The smartcard form factor holds considerable potential, but it remains a little-examined niche within free software as a whole.