Development

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.

Comments (2 posted)

Quote of the week

— Jeff Backus

Comments (11 posted)

OpenSSH 7.3 released

OpenSSH 7.3 is out. This release fixes a number of security issues (mostly related to timing attacks) and adds a handful of new minor features. The developers also warn that RSA keys less than 1024 bits will be refused in a near-future release.

Full Story (comments: 3)

Atom 1.9 released

Version 1.9 of the Atom editor has been released. New features include drag-and-drop support for altering the layout, improved resilience against lost files in the case of a hard crash, and "display layers," a feature that enables better and more flexible text transformations (such as syntax highlighting).

Comments (none posted)

GNOME Maps has tiles again

GNOME Maps recently ran into a tile problem (LWN article) when a service it relied on shut down. Jonas Danielsson reports that Maps will be getting tiles from Mapbox. "We access Mapbox through a GNOME based redirect, so that we could redirect to something else if a similar situation would arise again."

Comments (none posted)

Stellarium 0.15 is available

Version 0.15 of the Stellarium planetarium application has been released. This update moves to Qt 5.6 and introduces an internal change to the property system. Notably, the new property framework enables support for some additional control options, such as a web-based remote control panel. The star catalogs have also been updated, several new sky-culture data sets were added, a new bookmark tool was added, and support for the Miller Cylindrical Projection is now available.

Comments (none posted)

Firefox 48 released

Firefox 48 is out, featuring process separation (e10s) for some users, mandatory add-ons signatures, stable WebExtensions, enhanced download protection, and more. See the release notes for details.

Comments (18 posted)

Django 1.10 released

Django version 1.10 is now available. Among the new features supported are full-text search for PostgreSQL, support for Unicode usernames, and a new middleware framework designed "to solve the lack of strict request/response layering of the old-style of middleware", which effectively prevented the development of transactional features and imposed an undue burden on developers.

Comments (none posted)

LibreOffice 5.2 released

The LibreOffice 5.2 release is out. "LibreOffice 5.2 provides document classification according to the TSCP standard, and a set of improved forecasting functions in Calc. In addition, multiple signature descriptions are now supported, along with import and export of signatures from OOXML files. Interoperability features have also been improved, with better Writer import filters for DOCX and RTF files, and the added support for Word for DOS legacy documents." There's a lot more; see the release notes [PDF] for an illustrated list.

See also: this post from Michael Meeks on the last year of LibreOffice development.

Full Story (comments: 1)

Development newsletters from the past week

• What's cooking in git.git (July 27)
• What's cooking in git.git (July 29)
• What's cooking in git.git (August 2)
• This Week in GTK+ (August 1)
• OCaml Weekly News (August 2)
• Perl Weekly (August 1)
• PostgreSQL Weekly News (July 31)
• Python Weekly (July 28)
• Ruby Weekly (July 28)
• This Week in Rust (August 2)
• Wikimedia Tech News (August 1)

Comments (none posted)

Pagès: GIMP 2.9.4 and our vision for GIMP future

Jehan Pagès writes about the current GIMP development release and the plan from here. "I want to imagine a future where most big graphics program integrates GEGL, where Blender for instance would have GEGL as the new implementation of nodes, with image processing graphs which can be exchanged between programs, where darktable would share buffers with GIMP so that images can be edited in one program and updated in real time in the other, and so on. Well of course the short/mid-term improvements will be non-destructive editing with live preview on high bit depth images, and that’s already awesomely cool right?" See also the announcement for more information on the GIMP 2.9.4 release.

Comments (none posted)

Klitzke: Why Uber Engineering Switched from Postgres to MySQL

Evan Klitzke explains why Uber Engineering moved away from Postgresql. "The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL. In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL." (Thanks to Dimitri John Ledkov)

Comments (24 posted)