In this document we will discuss and collect the various options for inexpensive, convenient hardware that can be used to provide high-level cryptographic capabilities for authentication, digital signatures and decreasing compromising vectors in secure environments.
There are a number of smartcard and USB devices that provide the user with a mechanism to isolate private keys and offload authentication to a small device that can be carried on the person. Using one of these devices on your TPC provides you with a new layer of security that you would otherwise not have. The benefits are primarily that you can physically remove the device and thus the secret key from your computer when you don’t need it. Also, most devices require a PIN to use, so if the device is stolen it is not usable without the PIN. Many of the devices will lock up if too many failures are attempted, so brute-forcing is not a viable attack vector. Additionally, most devices are supposedly designed so that the keys can never leave the card, so it impossible to extract the sensitive keys to perform attacks externally from the card (as long as you generate the key on the card itself, rather than putting onto the device an already existing key).
The cards have a processor and software, which generate the keys, use the keys and destroy the keys. The cards do not have any interface to extract the keys. Thus, the cards work differently than a simple disk. They are not just a key storage, they are rather small computers themselves which perform the actual cryptographic operations such as signature creation.
They work well in linux and work with GnuPG.
You need to have a smartcard reader to use this card, this can either be a PCMCIA smartcard, which would enable you to put the card into your PCMCIA slot on your laptop, but would require you to have an external reader for a desktop system without a PCMCIA slot. Its possible to do some hardware hacking and make a USB-sized card to use in a USB-key dongle, however the card wasn’t designed to be popped out and you risk damaging the interface in doing so.
The card may be limited to 1024 bit keys, however the back of the card says “RSA with 1024 bit minimum” and I’ve been told by someone that they put a 2048 bit subkey on their card… This needs to be tried… There is talk of trying to move to a 4096-bit OpenPGP card
It sounds like you can use this card to ssh authenticate , I know someone who has successfully set this up and will post information about this shortly.
Please see this page for information about how to get started with this card.
The Schlumberger Axalto Cryptoflex e-gate comes in a smartcard format, but the interface has been perforated so you can pop it out and pop it in a USB smartcard reader. Its relatively easy to setup and use for SSH, PAM authentication. dkg has also gotten it to work for openssl-enabled access (such as Firefox), but expressed frustration with how tedious it was, especially because so few sites use mutual TLS authentication. You can also configure your xscreensaver to authenticate against it, and make it so when you pull the device, your ssh-keys are flushed from the agent and your screensaver locks (note: this link is from 2005 and the udev system has changed so this doesn’t work now).
Using PGP with the device is somewhat conflicted because the GnuPG author doesn’t allow the use of external smartcards other than the OpenPGP smartcard, and the the openPGP smartcard couldn’t be used for things such as SSH authentication and PAM authentication (this needs to be verified, as the landscape has changed significantly in the last few years).
The following links look promising for a GNUPG implementation of PKCS#11, (need to experiment with these, please see the PKCS#11 protocol information below about the political problems associated with this):
to quote from dkg:
The card is limited to a 2048-bit key, and challenge-response round trip time is human-perceptible (a little under 1.5 seconds).
Supposedly this card, contains a smart chip that has roughly the same computing power as the 1970’s Radio Shack TRS-80 Model 1 Personal Computer.
Also some heavy usage data from dkg:
Under heavy use (average 6.11 plug/unplug cycles/day over the last 107
days), i find that the mechanical components of the USB key fail me
about once a year: the USB connection becomes intermittent and flaky.
But the smartcard itself is fine, and swapping it into a new USB key
clears up the issue.
The card and USB key can be obtained for approximately $30.
Bizarrely, they appear to have recently renamed the cryptoflex to the “TPC” and are selling it for $23.10. That same page says “Please note that 32K Cards will be OFF LINE in February 2008” — it’s not clear what “OFF LINE” means, but they may be discontinued.
The USB device itself used by dkg is the key format e-gate connector (new format), which is
something like the USB Shell Token V1 (Old name = Reflex 531) shown here. However, i bought them in a pack of 5 for ~$25 if my memory serves correctly, which is totally out of line with their current prices. This is kind of anxiety inducing.
These devices can also be found at USASmartCard.com’s "Linux and Open Source" category page.
Yubico sells OTP authentication devices for $25 (less in bulk.) The whole system (besides the hardware) is open sourced, including the protocol, the verification server, and code to use the public verification server. The device itself is a small little card that fits into the bottom of a USB port. The computer recognizes it as a keyboard. When you press the conductive button, it spits out an string of characters, encoded with 128-bit AES to be decoded by a authentication server. You can use it with PAM for two factor authentication with SSH, or you can patch software like squirrelmail to work with the OTPs. Also works with OpenID.
Other smartcard hardware¶
Need information about the following other hardware:
Belgian Personal ID Card
Hardware Security Modules (HSMs) are similar to smartcards and offer a comparable level of protection, but they typically have more memory for keys and the have a much higher performance. HSMs are available in different forms: PCI cards, SCSI devices or network devices. The main application for HSMs are server applications which need a high level of security as well as throughput; examples are applications which sign public documents or issue certificates. Dedicated crypto hardware also can improve the performance of a server application significantly, because it can process cryptographic operations much faster than the multi-purpose CPUs of most host systems.
Linux and smartcards¶
The opensc project¶
The opensc-project provides the functional libaries and application support for PKCS #15 compatible cards. Debian has packages available (opensc and libopensc2-dev).
The openct project¶
The openct project implements drivers for several smart card readers, you typically need the support for your smartcard in openct and an application that supports your specific card (opensc). Most crypto tokens are supported by a combination of opensc and openct.
M.U.S.C.L.E. stands for the Movement for the Use of Smart Cards in a Linux Environment. Despite the Linux in their name, their goal is to provide cross-platform smartcard and cryptographic support. So they provide Linux, Solaris, Mac OS X drivers, applications and middleware. They provide the pcsc-lite libraries, and have the goal of developing ISO-7816-4 compliant drivers, APIs and resource managers for various smartcards including Schlumbeger Reflex 60 line of reader and all ISO-7816-4 compliant smart cards. I think they are wanting to get Ibuttons and SECURE-ID working via the PC/SC specifications that Microsoft put out. This stuff appears to be pretty low-level.
Mac OS X and smartcards¶
There are multiple interface standards through which an application can access smartcards or HSMs. The most frequently used are PKCS#11, PKCS#15 which are part of the PKCS family of standards, and the Microsoft Crypto API.
Microsot Crypto API¶
The Microsoft Crypto API is an integral part of all current versions of Microsoft Windows, and most Microsoft applications use this interface for cryptographic operations. This includes email clients, their web browser as well as web servers. A main drawback is that it is only available on Windows platforms. Smartcard vendors typically support this API, HSM vendors don’t support this API as frequently as PKCS#11.
The PKCS#11 API is available on almost all platforms including Windows, Linux, Solaris and other Unix systems. Smartcard vendors typically PKCS#11, HSM vendors typically support at least PKCS#11.
PKCS#11 is different from other PKCS implementations because it defines an API where the previous ones did not. The details of shielding applications from the details of cryptographic tokens are described in PKCS#11 and has a simplified user model (only one user and an optional Security Officer). Its written in C and is also known as “Cryptoki”.
The trust model involved in PKCS#11 seems to be building on the broken X.509 hierarchical trust relationships that are very problematic. Its bringing users into the SSL certificate model (similarly S/MIME does the same thing). Large corporate certificate authorities are very interested in strict hierarchical trust relationships that can be monitored and centrally controlled, and although its refreshing to see a standard that is widely implemented, this is not a model of society that we are interested in pursuing, much less supporting.
As dkg points out, these cards are just RSA engines and it would be interesting to find out if we can use the storage on the cards to hold OpenPGP certificates/signatures and use the RSA engine instead of using the PKCS#11 CA hierarchical models?
the answer isn’t to just blindly trust a hierarchical authority; it’s to create better automated tools that can accurately express the nuanced trust models humans actually hold. And PKCS#11 isn’t that (web of trust comes closer). Ah well.
PKCS#15 establishes a standard that enables users in to use cryptographic tokens to identify themselves to multiple, standards-aware applications, regardless of the application’s cryptokin provider. Its not as widely implemented as PKCS#11, but has been gaining in interest in standards bodies as an electronic ID card or subscriber identity module.
PKCS#15 is a detailed description of how certain higher-level abstractions such as how keys and certificates are represented on a token in terms of data structures, file contents, directory structures. The goal is to enable portability of personal credentials stored on cryptographic tokens across applications. Supposedly it is “an attempt to eliminate differences between tokens with respect to certain security-related information” and is a “‘token edge’ specification for the exchange of information between a host and a token” and is not biased towards particular IC cards or tokens and is oriented toward PKCS#11 objects but not tied to PKCS #11.
Its not clear to me the difference between PKCS#11 and PKCS#15 either. I think the main difference is #15 describes the information format standard and #11 describes the interface.
Validated key protection schemes (CC, FIPS, etc.)¶