That HOWTO was very helpful. I hope more documentation like this will pop up on the net. It's been really hard to find info on the OpenPGP card implementation.
I've been searching around the net for an answer to whether it's possible to use large keys on smartcards with GPG (2048+). Anyone on the list know whether it's possible to import off-card generated keys into OpenPGP Card which are larger than 1024bits? I now know that the card is only capable of 'generating' 1024bit keys on the card, but there should be enough space to store off-card generated 1024bit+ keys?
Kory T
On Mar 14, 2005, at 5:07 PM, Robert Golovniov wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
Hello Kory,
I've seen your posting at the gnupg-users mailing list, and since no
one responded to you yet, I decided to try answer your question.
I am not sure whether GnuPG at this stage supports other cards than
OpenPGP card. But for this card you may find some points mentioned
below quite helpful:
The GnuPG Smartcard HOWTO Written by Werner Koch <[EMAIL PROTECTED]> v0.0, 2004-09-21
Table of Contents
XXXX
N. Introduction
GnuPG supports smartcards since version 1.3.3. The next generation of GnupG, version 1.9.x also supports this card. Cards most comply with the OpenPGP card specification version 1.0 available at http://g10code.com/docs/openpgp-card-1.0.pdf .
N. Installation
Since version 1.3.90, GnuPG will be build be default with support for smartcards. A configure time option may be used to exclude this support. To support all available methods of accessing a card reader, the library libusb available at
http://prdownloads.sourceforge.net/libusb/
should be installed prior to building GnuPG. On Debian GNU/Linux systems a mere
apt-get install libusb-dev
should be sufficient. Note, that the, at this time unreleased, development version of this library is not supported. The do the usual ./configure and make as descibed in the GnuPG installation. If you are using the 1.9 branch of GnuPG and plan to use the PC/SC driver (see below) you should now install the software so that the pcsc wrapper binary will be available at the right place.
N. Hardware
Obviously you need an OpenPGP smartcard. To plug this card into you computer you will also need a card reader. Such readers are not yet installed on most computers but they are available at some computer stores. The quite usual readers used for flash memory are not what we want.
Here is a list of readers we have tested and know that they work:
* SCM Microsystems SCR335
This is a small USB reader sized 65*45*8mm and also very suitable for use with laptops. This is a CCID (Chip Card Interface Device; USB device class 11) reader and GnuPG comes with direct support for it.
* SCM Microsystems SPR532
This is an USB/serial reader equipped with a numerical keypad and 3
extra buttons. The pinpad may be used to securely entered the
PIN. This device may be used as a serial reader or as a USB
CCID reader. We have however only tested the USB interface.
* Towitoko Chipdrive micro
This one comes in 2 flavours: Serial and USB, both are very similar and of the same size 65*45*8mm. AFAIK, these readers are not anymore manufactured and have been replaced by the SCR335.
* Omnikey Cardman 2020
* Omnikey Cardman 2010
From my experience the SCM readers work best and are a lot faster than the other readers, because they are able to transfer data at up to 115200 kb/s which is the highest possible rate supported by smartcards.
N. Drivers
Although they are called drivers, the drivers fro smartcard readers are more a library to translate the proprietary reader protocol to a standard protocol. Drivers used to be connected to the serial port and as such utilize the actual serial driver of the OS. Most USB readers available today still behave like serial readers, just connected through USB. When using the Linux kernel you often need pl2303 module to access this one. Modern reders support the CCID specification and are native USB devices; GnuPG directly supports these.
The are 3 standard protocols used to access a reader from an application and appendant driver" to translate the protocol.
N.1 CTAPI Driver
This is the old and simple API (Chip Terminal API) used since the beginning of chipcards. To make use of it, yuou need an appropriate CTAPI driver which comes in form of a shared library. TO enable it you need to give a option to gpg; either on the command line (prefix it with 2 dashes) or in the configuration file gpg.conf. For example to use the CTAPI driver for the Towitoko readers you may put
ctapi-driver /usr/lib/libtowitoko.so.2
into ~/.gnupg/gpg.conf. This will try to use the reader at the first serial port. To select a reader on a specific port, you need to use the option reader port. for example to use the reader at /dev/ttyS2 you add this to your gpg.conf:
reader-port 2
How the reader port is actually specified depends on the type of reader and the "driver". For example you may use the libtowitoko also for the USB version of the driver in which case you use
reader-port 32768
to select the first USB attached reader.
N.2 PC/SC Driver
FIXME: Tell about pcsclite, that thre is a CCID driver too, that there are sometime problems wityh it. pcsc-wrapper.
N.3 CCID Driver
This driver is built into gpg if it has been build with LIBUSB support. The driver will be used by default if a the option --disable-ccid has not been given.
To use the driver you must probably setup your system. In particular make sure that you have suffiecient permissions to access the USB devices for read and write. This setup depends on the system you are using:
N.3.1 GNU/Linux
The USB stack is here accessed by means of libUSB through the special usbfd. Thus make sure that this file system has been mounted; the suggested way of doing so is by using the following line in /etc/fstab:
none /proc/bus/usb usbfs default 0 0
To get the permission right you may use the lazy way of mounting the USB filesystem under your uid. For example if your userID is 1000, you may use this line in /etc/fstab
none /proc/bus/usb usbfs default,devuid=1000 0 0
After mounting this file system (using "mount /proc/bus/usb") all files below /proc/bus/usb are owned by you. You may instead use devgid to allow access by a group. There is however a major security problem with this approach: The owner of the files has full permissions to all connected USB devices not matter what type of device. Thus it is strongly suggested to use the follwoing method instead.
If your system comes with hotplug support you may assign permissions on a per devices base. Here we want to give permissions to all CCID devises to the user in the group "scard". You need to create the following 2 files.
A mapping file to select what script to run for which device:
=== /etc/hotplug/usb/gnupg-ccid.usermap ===
# The entries below are used to detect CCID devices and run a script
#
# USB_MATCH_VENDOR 0x0001
# USB_MATCH_PRODUCT 0x0002
# USB_MATCH_DEV_LO 0x0004
# USB_MATCH_DEV_HI 0x0008
# USB_MATCH_DEV_CLASS 0x0010
# USB_MATCH_DEV_SUBCLASS 0x0020
# USB_MATCH_DEV_PROTOCOL 0x0040
# USB_MATCH_INT_CLASS 0x0080
# USB_MATCH_INT_SUBCLASS 0x0100
# USB_MATCH_INT_PROTOCOL 0x0200
#
# script match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi
# bDeviceClass bDeviceSubClass bDeviceProtocol
# bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
#
# flags V P Bcd C S Prot Clas Sub Prot Info
#
# Generic CCID device
gnupg-ccid 0x0080 0x0 0x0 0 0 0 0 0x00 0x0B 0x00 0x00 0x00000000
# SPR532 is CCID but without the proper CCID class
gnupg-ccid 0x0003 0x04e6 0xe003 0 0 0 0 0x00 0x0B 0x00 0x00 0x00000000
=======
This file states that the script "gnupg-ccid" should be run if a devices matching the parameters comes available by plugging it into the USB. The script to actually assign the permissions is:
=== /etc/hotplug/usb/gnupg-ccid ===
#!/bin/sh
# This script changes the permissions and ownership of a USB device
# under /proc/bus/usb to grant access to this device to users in the
# "scard" group.
#
# Arguments :
# -----------
# ACTION=[add|remove]
# DEVICE=/proc/bus/usb/BBB/DDD
# TYPE=usb
#
# latest hotplug doesn't set DEVICE on 2.6.x kernels
if [ -z "$DEVICE" ] ; then
IF=`echo $DEVPATH | sed 's/\(bus\/usb\/devices\/\)\(.*\)-\(.*\)/\2/'`
DEV=`echo $DEVPATH | sed 's/\(bus\/usb\/devices\/\)\(.*\)-\(.*\)/\3/'`
DEV=`expr $DEV + 1`
DEVICE=`printf '/proc/bus/usb/%.03d/%.03d' $IF $DEV`
fi
if [ "$ACTION" = "add" -a "$TYPE" = "usb" ]; then chgrp scard "$DEVICE" chmod g=rw "$DEVICE" fi ======
Don't forget to "chmod +x" this script.
N. Features of the OpenPGP card
FIXME: list feature and explain why "only 1024 bit RSA and why not DSA etc.
N. Looking at a card
The first thing you should do is to have a look at the card and by this also check whether your setup works. Put your OpenPGP card into the reader and run
gpg --card-status
For an empty card you should see an output similar to:
gpg: detected reader `Towitoko Chipdrive USB 00 00' Application ID ...: D2760001240101000001000000CB0000 Version ..........: 1.0 Manufacturer .....: PPC Card Systems Serial number ....: 000000CB Name of cardholder: [not set] Language prefs ...: de Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Max. PIN lengths .: 254 254 254 PIN retry counter : 3 3 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none]
the first line is actually printed to stderr and telling you the reader used. It depends on the reader and the driver.
The other information is the standard output for the cards I am using. Depending on the manufactorer different default values migth be shown and obviously the combination of manufactorer and serial number is unique. The serial number is used by gpg to associate a key with a physical card so that it may prompt you to insert the right card into the reader. With the forthcoming revision 1.1 of the OpenPGP card spec you might notice a few other lines in the output.
The max. PIN lengths as shown above are unchangeable constants put into the card during personalization (i.e. right after the chip has been glued to the card body). Same goes for the PIN retry counters which are commonly set to 3 as experience has shown that this is a suitable value. These retry counters are decremented for each wrong PIN presented to the card and reset to the default of 3 if a correct OPIN has been presented. The first and second counter are for the standard PIN and gpg makes sure that they are syncronized (the second PIN is only required due to ISO-7816 standard pecularities). The third value reflects the retry counter for the Admin PIN.
The value of the signature counter is 0 indicating that no signature has yet been done using the Signature Key. In fact there is no key currently stored on the card. This counter is incremented with each signature and only reset to 0 is a new Signature Key has been created or imported to the card.
If you run the card-status command on an initialzed card you will see data put by the owener onto the card:
Application ID ...: D2760001240101000001000000290000
Version ..........: 1.0
Manufacturer .....: PPC Card Systems
Serial number ....: 00000029
Name of cardholder: Archibald Goodwin
Language prefs ...: de
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: archi
Signature PIN ....: forced
Max. PIN lengths .: 254 254 254
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: AB6E 49C1 2834 1F3C CE57 A8CD DF98 07BC E702 A550
Encryption key....: 7BC2 FC86 8599 FD03 6E33 4EB5 D45E AE41 E370 D3DC
Authentication key: 5B81 A544 068F E66A 464C FB04 4754 3878 B64A 8ABB
General key info..: pub 1024R/E702A550 2004-04-28 Archibald Goodwin\
(test) <[EMAIL PROTECTED]>
Here the name of the card holder has been set as well as language preferences. These are standard data objects for chip cards and usually used by terminals to display a name and a message in a friendly way. gpg does not make used of these fields but allows to set them.
A special data objcet of the OpenPGP card is the Login Data which may be used to store the account name of the card holder. The GnuPG convention is to use the data up to an optional line feed character for the account name. This account name may be used for login purposes. gpg does not enforce any match of this name with a name used in the key. See the source (app-openpgp.c) for some special features of the login-name field.
The signature counter has been bumped up to 6 which indicates under the current gpg implementation that this the key stored on the card has not been used. While creating the key teh card has been asked to do 6 signing operations: 1 self-siganture to bind the name to the primary key and 2 key-binding signatures. This has then been repeated for the secret key part.
3 keys have been created or imported to the card. Their corresponding OpenPGP fingerprints are shown: The signature key is commonly used as the primary OpenPGP key, the encryption key as a subkey and the authentication key is not used by GPG but by other tools like ssh or PAM modules for authentication services. These fingerprints are stored on the card in special DOs to link the key with a public keypublic store in the usual public keyring. When using cards implementing the 1.1. version of the OpenPGP card specification, the creation date of the keys will also be shown. If this corresponding public OpenPGP key is available, the primary user ID is show at the last line.
N. Initializing a new card
Here is the standard way on how to prepare a new card for use. Assuming that the reader works and the card can be accessed (see above, command "gpg --card-status"), you should enter
gpg --card-edit
The basic information of the card will be shown (this is the same output as with "gpg --card-status") followed by a prompt. You may how enter the command "help" to see a list of available commands. However these commands are not very useful now as they don't allow to change any data on the card. You need to get into the Admin mode to do this. So go ahead and enter "admin". Now the "help" command will show you more commands at your dispose.
The first thing we want to store on the card is the name of the card owner. This is technically not required but useful to identify the card if you are using more than one card. Enter "name" and follow the prompts. You will be asked for surname and given name separately because the name is store in an ISO speicified format which allows to distinguish between thye name parts (that is the same format as used in the machine readable part of passports). gpg currently does only allow plain ASCII characters for this field. After entering the data you will be asked for a PIN to unlock the card. When beeing asked for a PIN look carefully t the prompt: It may either be the "PIN" or the "Admin PIN", both are different and in particular entering a wrong "Admin PIN" is dangerous. Okay, here wou will be asked for the "Admin PIn" and - being a fresh card - you should enter the dfault value for the Admin PIN: "12345678" (without the qoutes of course). The Admin PIN is usually cached and in general it is not required to enter it again unless you have removed the card. See below unter "PIN Management" for more details. Having done all this the name should be stored on the card; check it using the "list" or "l" command.
Now you might want to tell the card what language you prefer ("lang") or whether a terminal should address you as Mister or Madame ("sex"). You may want to omit this because gpg does not make any use of them.
Now for a more exiting exercise: Generation of the key. Enter the command "generate" and you will then be asked whether to make an off-card backup of the encryption key. You usually want to say yes here. This backup is useful because without it you won't be able to access any data you encrypted with the card in case you lost the card (we don't hoe so) or the card gets damaged. Recall that a smartcard is a small embedded device and the chip may have a malfunction or physical break if the card is bended too hard.
In case that an existing key exists in the card, a security question has to be answered, so that a key won't get inadvertly overwritten. After that you have to answer the usual questions when generating a key (name, email, expiration etc.). Now sit back for about a minute while the card starts to generate the keys and gpg generates and imports the encryption key. During this process you might get distrubed by questions for the PIN and the Admin PIN. Don't miz them up. The PIn is required for the binding signatures and for a fresh card you will have to enter the default PIN of "123456" (note that this one is 2 charatres shorter than the default Admin PIN).
Now your card is ready for use and carries your keys. What's left to do is to save away the backup key you probably decided to create. This backup key is protected using the passphrase you entered for it and should be transferred to another media and stored at a safe place (you may want to write the passphrase then down). It is important that you delete the copy of the key on the hard disk too. The best choice here is to use a tool like "shred" (from the GNU coreutils package) or "wipe" to make sure that the original content gets overwritten. For storing the key a printout is also a good idea - you usually don't need it so entering the ASCII armored format back won't be that of a problem in case the card breaks and the decryption key is not anymore available. The command gpg --enarmor may be used to convert the backup key into a printable format. In case of the case see below on how to restore a backup key.
N. PIN Management
Fixme: Tell how to change the PIN, how to unblock it etc.
N. Advanced features
N.1 Using the card only for subkeys
Sometimes it is useful to use the card not in the default way. In particular if you already own a key with a lot of key signatures it would be a waste to start over with a new key. The card does not support DSA keys so moving the primary key onto the card is not an option. Even if you are using an RSA key, the currently available cards do only allow for 1024 bit keys which is probably not what you are using. Fortunately we can help anyway.
The way it works is to use the key on the card only for signing and decryption but not for key signing. By keeping the primary key offline (which is a thing you can do with gpg since many years), you won't expose even this key to remote attacks. In fact I am using such a method for my 5B0358A2 key created back in spring 1999. The first years it was troublesome becuase other OpenPGP implementations and the keyservers were not able to cope with signing subkeys but the times they have changed and signing sub keys are today state of the art. Obviously if you ever had your pirmary key stored on a networked box there is some chance that it has already been compromised and thus the card stuff won't help you - Let's assume this is not the case and your primary key has always been safely stored.
To start creating a card using an offline primary key you must first make the primary key accesible; i.e. walk down to the 7th basement take those shiny metal keys, oben the vault and take out your laptop you are using to sign other keys. Install the card rader as usual and prepare a card as describe above - however don't use the "generate" command but enter "quit" and start gpg again using "gpg --edit-key <your_keyid>". Now enter "addcardkey" and gpg will show you a short menu to select whether a signing, decryption or authentication key shall be generated. First you should create a signing key; select this and gpg will create a new key for you on the card. If such a key already exists on the card, a security query needs to be answered as usual. Afte rthis has worked out you may either want to run the "save" command to commit the changes (note that the key won't get deleted from the card if you you exit without saving but this is is then mostly useless. Alternativly you may then choose to create another subkey using "addcardkey", this time selecting an encryption key and proceed as described. Note that gpg will always use the latest created key of a given type.
However there is no direct way to create a backup key of the card's decrytpion key like it is done with the "generate" command. However it is easy to do this with a few steps more: First create a regular RSA subkey of 1024 bit length using the "addkey" command and then select this new key and run the command "keytocard"; gpg will transfer the key to the card and replace the existing secret key with a stub. Well you have benn smart enough to make a copy of your whole secret key before running the "keytocard" command - otherwise the procedure would have been pointless.
N.2 Moving an existing key to a card
This is basicaly described above. You may transfer any key (primary or sub) to a card using the command "keytocard", given only that the card supports the type of the key and the length. gpg does proper checking and will tell you if it won't be possible. The "addtokey" command is mostly self-explaining but you should make sure that you do a "save" later to save a way the replaced secret key. Without the safe you create merely a copy of a key on the card.
GLOSSARY
CHV - Card Holder Verfication, commonly followed by a a number denoting the which CHV is meant. The OpenPGP card uses 3 CHVs: CHV1, CHV2, CHV3. The are often also referenced as PIN 1, PIN 2 and PIN 3. CHV3 is used the so called Admin PIN (sometimes also called SO PIN (Security Officer).
PC/SC -
CTAPI -
CCID - Chip Card Interface Description. The specification for the USB device class 11 used for chip card readers.
OpenPGP
Copyright 2004 Free Software Foundation, Inc.
This file is free software; as a special exception the author gives unlimited permission to copy and/or distribute it, with or without modifications, as long as this notice is preserved.
This file is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY, to the extent permitted by law; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=
Please let me know if I can be of any other help to you.
- --
-=Robert & Beata Golovniov | Psalms 27:4=-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~
OpenPGP key for secure communication at: http://tinyurl.com/4df7a
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) - GPGshell v3.40rc2 Comment: Using PGP/GnuPG for Internet privacy. Comment: Gossamer Spider Web of Trust: http://www.gswot.org
iD8DBQFCNUZHWh2fA2M/bQcRA3o1AJwJ+2KreV7m469EfQvRgijblp9NLQCg03wP 6UxdGlIxjyrdz18OSVUHYms= =3LW9 -----END PGP SIGNATURE-----
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
