GnuPG + Smartcard
Kory T
talmage at zero.ad.jp
Mon Mar 14 11:19:43 CET 2005
Thanks for the help Robert.
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 <wk at gnupg.org>
> 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)
> <archi at foobar.example>
>
> 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-----
>
>
More information about the Gnupg-users
mailing list