Utilisation de smartcards, GnuPG V2 au « quotidien »

GNU/Linux Magazine n° 123 | janvier 2010 | Michel Havez

Ceci est un article complémentaire à l’article écrit par Denis Bodor, paru dans le GNU/Linux Magazine n°113, orienté sur la version V2 de cette smartcard et sous le système GNU/debian squeeze. Nous verrons dans cette première partie son implémentation avec GnuPG2, la différence entre ces deux versions de smartcard (V1 et V2), son utilisation dans différents contextes : génération de clés, le transfert de clés existantes sur la smartcard, la création d’une smartcard de secours au cas où, …

1. Différences entre la V1 et la V2

Le 3 juillet 2009, les premières smartcards GnuPG V2 étaient mises à disposition, engendrant quelques différences importantes par rapport à la version V1 :

  • stockage de trois clés RSA jusqu’à 3072 bits contre 1024 pour la version précédente
  • longueur de code PIN contenue entre 6 et 32 caractères contre 254 pour la version antérieure. De l’aveu même de Werner Koch, il est déjà difficile pour la majorité des personnes de se souvenir d’un code à 6 caractères, imaginez avec une possibilité de 254…

Une des différences notable est l’apparition de smartcard dite à « puce détachable », ce qui signifie que l’on peut détacher la puce comme pour les téléphones portables et les incorporer dans des clés USB spéciales qui acceptent ce type de format (puce téléphonique).

A l’heure actuelle, à notre connaissance, les cartes Fellowship crypto card n’ont pas encore évolué vers la version V2.

Afin de valider les différentes phases d’installation et de configuration présentées dans cet article, nous considérerons que nous partons sur une version de squeeze fraîchement installée. Il se peut donc que vous n’ayez pas certaines installations de paquets à faire si vous les avez déjà faites précédemment.

1.1 Paramètres embarqué dans la puce

Descriptif smartcard v1 et v2
Tab 1. Descriptif smartcard v1 et v2

Voici un descriptif sommaire des principaux changements entre la V1.1 et la V2.0 de la puce :

  • correction de la description de l’AID (RID de la FSFE)
  • alignement sur les changements et les innovations dans l’ISO 7816 et EN 14890
  • amélioration des capacités étendues
  • amélioration de l’algorithme attribut
  • définition d’importation des clés selon la norme ISO 7816-8
  • des algorithmes de hachage supplémentaires et des comportements différents de PSO : CDS commande
  • simplification dans la gestion de mot de passe.

1.2 Différences au niveau de l’aspect esthétique

Smartcard OpenPGP V1 Smartcard GnuPG V2
Smartcard OpenPGP V1Smartcard OpenPGP V1
Smartcard GnuPG V1Smartcard GnuPG V2
Tab2. Différences graphiques entre les smartcards v1 et v2

Outre les GNU protecteurs qui disparaissent, on remarque la puce détachable (modèle spécifique) de la smartcard GnuPG V2. On constate également que la sérigraphie est passée d’OpenPGP à GnuPG.

2. Problèmes de jeunesse

Lorsque j’ai passé ma commande d’une smartcard OpenPGP, je pensais recevoir la version 1 et non pas la version 2. Cependant, rencontrant des problèmes d’approvisionnement et renseignement pris, le fournisseur attendait la réception des nouvelles smartcards. Ce fut une surprise, mais également le début des problèmes…

En effet, pour fonctionner, cette dernière a besoin au minimum de la version 2.0.12 de GnuPG2, cependant elle n’était disponible, à ce moment-là, pour aucune des versions de Debian… J’ai donc été contraint de refaire moi-même un paquet. Après de nombreux tests, pensant que mon paquet n’était pas bon, j’ai fini par poster mes problèmes rencontrés sur la liste de développement de GnuPG, car il était impossible de générer des clés à partir de la smartcard. Par la suite, d’autres personnes ont relaté le même problème, ce qui pouvait dans un premier temps être assez rassurant (cela ne provenait pas du paquet). Werner Koch sortit par la suite trois patchs afin de solutionner ce problème. J’ai régénéré un paquet en y appliquant les trois patchs : 01-scd-pw2.patch, 03-opgp-writekey.patch et 06-opgp-sign3072.patch (d’ailleurs les mainteneurs du paquet GnuPG2 pour différentes distributions font référence à ce billet pour créer leur paquet). Nouveau paquet à disposition, il est dès lors possible de créer les trois clés RSA de 2048 bits.

Pour information, dans la distribution Debian, les paquets GnuPG2 2.0.12 ne sont pas utilisables avec les smartcards V2 car ils n’intègrent pas les patchs mentionnés. Seule la version 2.0.13, qui vient de sortir à la date d’écriture de cet article, intègre ces patchs et évite donc de devoir faire soi-même ses paquets. Depuis, une nouvelle version de GnuPG est également sortie, la 1.4.10a, sortie réellement le 5 septembre, qui permet également d’exploiter les smartcards V2.

2.1 Correction de certains bugs

La version 2.0.13, sortie le 4 septembre, a corrigé certains bugs et en particulier intégré les trois patchs mentionnés permettant d’utiliser la smartcard V2 avec des clés RSA de 2048. Je précise bien ici 2048 bits, car à ce moment-là, l’utilisation de clés RSA de 3072 bits posait toujours des problèmes. En fait, pour être plus précis, c’est uniquement la phase de déchiffrement qui posait des problèmes. En effet, avec les clés de 3072 bits, on pouvait signer et chiffrer ses courriels. Le problème se posait lors de la phase de déchiffrement. On ne pouvait pas déchiffrer les courriels ayant été chiffrés avec une clé de 3072 bits, ce qui était plutôt gênant. D’après l’analyse de Werner, le problème se situerait d’une part dans la gestion d’APDU et, d’autre part, peut-être dans un bug du code de la smartcard. L’utilisation d’une clé RSA pour l’authentification ou le ssh ne pose quant à elle aucun problème en 3072 bits.

La version 2.0.13 a également vu apparaître la possibilité de choisir la force de chacune des trois clés (comme nous l’avons vu précédemment),

D’autres bugs existent, mais sont plutôt en rapport avec une utilisation de logiciels propriétaires, nous n’en parlerons donc pas dans cet article.

Une grosse attente se situe donc sur la résolution du bug des clés de chiffrement en 3072 bits, puisque ces smartcards doivent supporter de telles clés. Cette correction vient d’être faite et a été confirmée le 19 octobre par Werner Koch. Les smartcards à partir du numéro 347 ne comportent plus ce bug, les toutes dernières permettraient même d’héberger des clés de 4096 bits (cependant, dans ce dernier cas, il faudra une évolution de GnuPG2 pour pouvoir exploiter ces clés, ce qui sera peut-être intégré dans la prochaine version de GnuPG2, sauf si le développement actuel des nouvelles fonctionnalités prend plus de temps que prévu et ne permet donc pas cette intégration dans la prochaine version), mais c’est en bonne voie. Mais l’utilisation de ses smartcards n’est garantie qu’avec des clés de 3072 bits maximum à l’heure actuelle.

3. Utilisation avec différents matériels

Les opérations ci-dessous sont décrites dans le cas où vous utiliseriez votre lecteur de smartcard avec d’autres applications que GnuPG, et donc pas en mode « direct ». Si vous utilisez les drivers CCID fournis avec GnuPG2, il faut bien sûr que votre lecteur soit un lecteur compatible CCID.

3.1 Clavier cherry SmartBoard XX44 incluant un lecteur de smartcard

Commençons par installer les paquets nécessaires à l’utilisation de ce lecteur de carte. Ce dernier ayant été validé pour le driver libccid (cf http://pcsclite.alioth.debian.org/supported.html#0x046A0x0010), nous aurions pu installer les deux paquets suivants : libccid et pcscd. Cependant, la libccid est défaillante, dans notre cas, et cette dernière n’est pas en mesure d’exploiter convenablement notre smartcard v2 à l’heure actuelle (ceci est dû à un problème au niveau du mode APDU étendu).

Nous devons passer par le paquet de driver propriétaire : pcsc-omnikey :

$ aptitude install pcsc-omnikey pcscd

Ces drivers règlent les problèmes que j’ai rencontré avec le drivers libccid, c’est dommage car cela implique d’utiliser deux drivers différents.

3.2 Lecteur de smartcard expresscard SMC SCR3340

Contrairement au clavier cherry, le lecteur de smartcard expresscard SMC SCR3340 fonctionne parfaitement avec les drivers de la libccid (alors que, contrairement au clavier cherry, ce dernier n’est pas « estampillé » supporté par la libccid, mais juste « devrait fonctionner »). Les tests effectués de création de clés, de signature, chiffrement/déchiffrement et authentification n’ont posé aucun problème.

$ aptitude install libccid pcscd

3.3 Lecteur de smartcard Covadis véga-alpha incluant un pavé numérique

Ce lecteur a la particularité d’intégrer un pavé numérique (keypad). Par conséquent, le code PIN ou le code PIN admin qui est saisi ne sort pas du lecteur et ne peut donc être intercepté par un rootkit comme lorsqu’on le tape sur notre clavier d’ordinateur. Ce lecteur permet d’accroître encore un peu plus la sécurité.

Cependant, à ce jour, je n’ai pas réussi à faire fonctionner le keypad avec GnuPG, bien que les tests effectués avec la libccid démontrent que le keypad est bien supporté par PCSC-Lite :

SCardControl(CM_IOCTL_GET_FEATURE_REQUEST): OK
...
Reader supports FEATURE_VERIFY_PIN_DIRECT
Reader supports FEATURE_MODIFY_PIN_DIRECT
Reader supports FEATURE_IFD_PIN_PROPERTIES

D’ailleurs les tests effectués avec une version modifiée du fichier scardcontrol.c m’ont permis de tester avec succès la vérification et le changement du code PIN de ma smartcard GnuPG V2 en mode « SecurePIN » (il reste donc à l’intégrer dans GnuPG2).

$ scardcontrol
...
Secure verify PIN
...
Enter your PIN:
card response: 90 00
SCardControl: OK
Secure modify PIN
...
Enter your PIN:
card response: 90 00
SCardControl: OK

A noter également que les messages s’affichent correctement sur l’écran LCD du Vega-Alpha.

Actuellement, ce lecteur fonctionne donc en mode transparent sans utilisation du secure PIN.

Dans le cas où le keypad fonctionnerait, il est toutefois possible de le désactiver en ajoutant l’option disable-keypad dans le fichier scdaemon.conf, même si cela n’est pas recommandé. Il ne reste plus qu’à attendre que GnuPG autorise l’utilisation de PCSC-Lite avec un keypad ou que le code interne ccid évolue.

3.4 Lecteur de smartcard GEMALTO interface USB

Archlinux

Installer ccid (pcslite)

yaourt -S ccid

Tuer la tâche scdaemon

sudo pkill scdaemon

Relancer le daemon pcsclite

sudo systemctl restart pcscd.service

Insérer dans un port USB le lecteur GEMALTO avec une puce GnuPG et tester

gpg --card-status

4. Obligation de l’utilisation de gpg-agent avec GnuPG2

Pour les trois lecteurs, on peut vérifier le bon fonctionnement de ces derniers avec pcsc_scan qui fait partie du paquet pcsc-tools. Si ce n’est pas fait, on installe ce paquet :

$ aptitude install pcsc-tools

Avant d’exécuter la commande pcsc_scan, nous allons récupérer la dernière version du fichier smartcard_list.txt, le paquet actuel ne contenant pas l’ATR de notre smartcard (la version V2 de notre smartcard n’étant pas encore intégrée dans le paquet officiel), Ludovic Rousseau a eu la gentillesse d’ajouter l’ATR correspondant dans son fichier lorsque je le lui ai signalé. Je le remercie au passage.

$ wget http://ludovic.rousseau.free.fr/softwares/pcsc-tools/smartcard_list.txt --output-document=~/.smartcard_list.txt

Maintenant que nous avons récupéré le fichier contenant l’ATR, nous allons pouvoir vérifier que notre lecteur communique bien avec notre carte :

$ pcsc_scan

Compiled with PC/SC lite version: 1.4.102
Scanning present readers...
0: Covadis Vega (000000F5) 00 00
Fri Oct 2 17:08:12 2009
 Reader 0: Covadis Vega (000000F5) 00 00
 Card state: Card inserted,
 ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C

.......

Possibly identified card (using /home/jdoe/.smartcard_list.txt):
3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C

Comme nous pouvons le constater, il a bien reconnu notre lecteur (ici, le Covadis Vega-Alpha) ainsi que notre smartcard(GnuPG card V2), reconnue par son ATR (numéro unique caractérisant chaque modèle de smartcard).

Nous avons validé que notre lecteur communique avec notre smartcard, mais cela n’est pas suffisant pour fonctionner avec GnuPG2.

Le résultat de la simple commande de statut de gpg nous l’indique tout de suite :

$ gpg --card-status
gpg: le porte-clés '/home/jdoe/.gnupg/secring.gpg' a été créé
gpg le porte-clés 'home/jdoe/.gnupg/pubring.gpg' a été créé
gpg: selecting openpgp failed : Unknown IPC command
gpg: la carte OpenPGP n'est pas disponible: Unkown IPC command

Il faut ajouter use-agent dans le fichier gpg.conf qui se trouve ici dans votre répertoire personnel de gnupg. On en profitera d’ailleurs pour ajouter également d’autres options :

$ vi /home/jdoe/.gnupg/gpg.conf

# FILE CREATED BY SEAHORSE

On va donc ajouter les lignes suivantes :

### +++ … GPGConf … +++###
use-agent
utf8-strings
keyserver hkp://keys.gnupg.net
### +++ … GPGConf … +++###

Voici l’explication de ces options :

  • use-agent : utilisation de l’agent gpg-agent qui est initialisé dans le script 90gpg-agent qui se trouve sous /etc/X11/Xsession.d (obligatoire avec GnuPG2)
  • utf8-strings: permet de gérer le codage utf8
  • keyserver: indique le serveur de clés GPG publiques (on peut ici mettre le serveur GPG de son choix).

On sauvegarde ce fichier, puis on redémarre sa session Gnome.

On refait un essai :

$ gpg –card-status

Application ID ...: D2760001240102000005123456780000
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 12345678
Name of cardholder: [non positionné]
Language prefs ...: de
Sex ..............: non spécifié
URL of public key : [non positionné]
Login data .......: [non positionné]
Signature PIN ....: forcé
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

et cette fois-ci, on accède bien au contenu de notre smartcard (cf paragraphe 1,1, partie smartcard V2).

5. Génération des trois clés

5.1 Génération des trois clés « on-card »

La smartcard (v1, v2) offre effectivement la possibilité de générer directement 3 clés : 1 clé dite de signature qui contient la clé principale, une clé de chiffrement qui est une sous-clé de chiffrement, et une clé d’authentification qui est également une sous-clé qui pourra servir pour l’authentification PAM ou SSH. Cependant, il faut savoir qu’il y a certaines restrictions dans le cas de cette génération « on-card » : ne pourront être « extraites » que la clé publique et la clé de chiffrement (uniquement si on a sélectionné l’option « sauvegarde à la génération des clés »), la clé d’authentification ne pouvant pas être extraite de la smartcard, ni la clé principale (clé de signature). C’est la particularité de la smartcard, on peut y importer des clés, mais on ne peut pas extraire de clés (à l’exception de la clé de chiffrement à la génération des trois clés « on-card »).

Cette méthode est donc très limitée, puisqu’en cas de perte de notre smartcard, nous serons obligés de recréer une nouvelle paire de clés. Il faut savoir également que la « sauvegarde » effectuée lors de la génération des clés « on-card » n’est pas une vraie sauvegarde GPG, cette dernière ne pouvant être utilisée que sur une autre smartcard. De plus, comme nous l’avons vu, elle ne contient que la clé de chiffrement.

Nous allons vous présenter ici la génération de trois clés de 3072 bits (cas d’une carte dont le numéro de série est supérieur à 347). Dans le cas contraire, vous devrez créer les trois clés avec soit trois clés de 2048 bits, soit la clé de signature et de chiffrement en 2048 bits et la clé d’authentification en 3072 bits.

Bien sûr, la partie personnelle (nom, adresse e-mail, validité de la clé, …) sera à adapter en fonction de vos besoins :

$ gpg --card-edit

...

Commande>admin  
Les commandes d'administration sont permises  
Commande>generate  
Faire une sauvegarde hors carte de la clé de chiffrement ? (O/n) o  
Notez que les réglages d'usine des codes PIN sont
PIN = `123456' PIN admin = `12345678'  
Vous devriez les changer avec la commande --change-pin  
Entrez votre Code PIN Admin  
Entrez votre Code PIN  
What keysize do you want for the Signature key? (2048)3072  
Entrez votre Code PIN Admin    
The card will now be re-configured to generate a key of 3072 bits
NOTE: There is no guarantee that the card supports the requested size.  
If the key generation does not succeed, please check the
documentation of your card to see what sizes are allowed.  
What keysize do you want for the Encryption key? (2048) 3072  
Entrez votre Code PIN Admin  
The card will now be re-configured to generate a key of 3072 bits  
What keysize do you want for the Authentication key? (2048) 3072  
Tapez votre Code PIN Admin  
The card will now be re-configured to generate a key of 3072 bits  

...

Spécifiez combien de temps cette clé devrait être valide.  
0 = la clé n'expire pas  

...

La clé est valide pour ? (0)0  
La clé n'expire pas du tout  
Est-ce correct ? (o/N) o  

...

Nom réel:John DOEbis  
Adresse e-mail:johnbis@doe.net  
Commentaire:test bis  
Vous avez sélectionné ce nom d'utilisateur:  
"John DOEbis (test bis) <johnbis@doe.net>"  
Changer le (N)om, le (C)ommentaire, l'(E)-mail ou (O)K/(Q)uitter ?O  
Entrer votre Code PIN Admin  
Entrer votre Code PIN  
Vous avez besoin d'une phrase de passe pour protéger votre clé
secrète.  
Entrer votre Passphrase  
Confirmer votre Passphrase  
gpg: NOTE: sauvegarde de la clé de la carte dans
`/home/jdoe/.gnupg/sk_C7E25E0720F24A95.gpg'  
gpg: clé EE9E178B marquée comme ayant une confiance ultime.  
les clés publique et secrète ont été créées et signées.  
gpg: vérifier la base de confiance  
gpg: 3 marginale(s) nécessaires, 1 complète(s) nécessaires, modèle
de confiance PGP
gpg: profondeur: 0 valide: 2 signé: 0
confiance: 0-. 0g. 0n. 0m. 0f. 2u  
pub 3072R/EE9E178B 2009-11-12  
Empreinte de la clé = C9AA BEBE 44E9 CB5D 7BFE 4C0B 3BBF E783 EE9E 178B  
uid John DOEbis (test bis) <johnbis@doe.net>  
sub 3072R/3B3F2C02 2009-11-12  
sub 3072R/20F24A95 2009-11-12  
Commande>quit  

Vérifions la liste des clés publiques présentes :

$ gpg --list-key

/home/jdoebis/.gnupg/pubring.gpg
pub 3072R/EE9E178B 2009-11-12
uid John DOEbis (test bis) <johnbis@doe.net>
sub 3072R/3B3F2C02 2009-11-12

Listez des clés privées présentes :

jdoe@kndl01:~$ gpg --list-secret-key
/home/jdoebis/.gnupg/secring.gpg
sec> 3072R/EE9E178B 2009-11-12
N° de série de la carte = 0005 12345678
uid John DOEbis (test bis) <johnbis@doe.net>
ssb> 3072R/3B3F2C02 2009-11-12

5.2 Génération des clés « off-card » et création de la clé d’authentification

Une autre solution consiste à générer ses clés « off-card », puis à les importer dans la puce de la smartcard par la suite. C’est d’ailleurs cette solution qui est privilégiée par GnuPG (avec en plus la génération de sous-clés qui seront sur votre PC).

Nous allons détailler ici une solution intermédiaire qui nous permettra d’avoir toujours nos clés sur notre smartcard et non pas en hébergement partagé entre votre disque dur et votre carte. Pour ceux qui ont déjà généré leur paire de clés, certaines étapes ne seront pas à effectuer, à condition d’avoir généré des clés de type RSA, d’une taille maximale de 3072 bits, la smartcard ne supportant que des clés de ce type.

5.2.1 Génération de la paire de clé « off-card »

Avant toute chose, nous allons supposer ici que vous n’avez pas encore utilisé GnuPG sur votre PC et donc que vous n’avez pas de répertoire .gnupg. Nous allons créer nos clés directement sur notre carte de sauvegarde (ici une carte SD, /media/disk-1). Nous y créons un répertoire pour recevoir nos clés :

$ mkdir /media/disk-1/gpg_sav

Les personnes possédant déjà leur paire de clés peuvent passer directement à l’étape (5.2.2)

Nous allons vous présenter ici la génération de clés de 3072 bits (cas d’une carte dont le numéro de série est supérieur à 347). Dans le cas contraire, vous devrez créer les clés en 2048 bits. Bien sûr, la partie personnelle : nom, adresse e-mail, date de validité, …, sera à personnaliser :

$ gpg --homedir /media/disk-1/gpg_sav --gen-key

...

gpg: le porte-clés `/media/disk-1/gpg_sav/secring.gpg` a été créé
gpg: le porte-clés `/media/disk-1/gpg_sav/pubring.gpg` a été créé

...

Sélectionnez le type de clé désiré:
(1) RSA and RSA (default)

...

Votre choix ?1
les clés RSA peuvent faire entre 1024 et 4096 bits de longueur.
Quelle taille de clé désirez-vous ? (2048)3072
La taille demandée est 3072 bits
Spécifiez combien de temps cette clé devrait être valide.
0 = la clé n'expire pas

...

La clé est valide pour ? (0)0
La clé n'expire pas du tout
Est-ce correct ? (o/N) o

...

Nom réel:John DOE
Adresse e-mail:john@doe.net
Commentaire:Compte de test
Vous avez sélectionné ce nom d'utilisateur:
"John DOE (Compte de test) <john@doe.net>"
Changer le (N)om, le (C)ommentaire, l'(E)-mail ou (O)K/(Q)uitter ?O
Vous avez besoin d'une phrase de passe pour protéger votre clé secrète.
Entrer votre Passphrase
Confirmer votre Passphrase

…

gpg: /media/disk-1/gpg_sav/trustdb.gpg: base de confiance créée
gpg: clé 6CC468AC marquée comme ayant une confiance ultime.
les clés publique et secrète ont été créées et signées.
gpg: vérifier la base de confiance
gpg: 3 marginale(s) nécessaires, 1 complète(s) nécessaires, modèle de confiance PGP
gpg: profondeur: 0 valide: 1 signé: 0
confiance: 0-. 0g. 0n. 0m. 0f. 1u
pub 3072R/6CC468AC 2009-11-12
Empreinte de la clé = 82E7 9476 23EA 78AD BB4B 94AF E50C 3BCA 6CC4 68AC
uid John DOE (Compte de test) <john@doe.net>
sub 3072R/D9B0321B 2009-11-12
Commande>quit

5.2.2 Génération de la de clé d’authentification « off-card »

Nous allons créer notre clé d’authentification en passant par le mode expert, car seul ce mode donne accès à cette option (cette clé d’authentification en 3072 bits fonctionnera pour toutes les smartcards V2 (il n’y a pas ici de restriction par rapport au numéro de série de votre smartcard) :

$ gpg --homedir /media/disk-2/.gpg_sav --expert --edit-key 6CC468AC

...

La clé secrète est disponible.
pub 3072R/6CC468AC créé: 2009-11-12 expire: jamais utilisation: SC
confiance: ultime validité: ultime
sub 3072R/D9B0321B créé: 2009-11-12 expire: jamais utilisation: E
[ ultime ] (1). John DOE (Compte de test) <john@doe.net>
Commande>addkey
La clé est protégée.
Vous avez besoin d'une phrase de passe pour déverrouiller la
clé secrète pour l'utilisateur: « John DOE (Compte de test) <john@doe.net> »
clé de 3072 bits RSA, ID 6CC468AC, créée le 2009-11-12
Entrer votre Passphrase
Sélectionnez le type de clé désiré:

...

(8) RSA (indiquez vous-même les capacités)
Votre choix ?8
Actions possibles pour une clé RSA: Signer Chiffrer Authentifier
Actions actuellement permises: Signer Chiffrer
(S) Inverser la capacité de signer

...

Votre choix ?s
Actions possibles pour une clé RSA: Signer Chiffrer Authentifier
Actions actuellement permises: Chiffrer

...

(C) Inverser la capacité de chiffrement
Votre choix ? cc
Actions possibles pour une clé RSA: Signer Chiffrer Authentifier
Actions actuellement permises:

...

(A) Inverser la capacité d'authentifier
Votre choix ?a
Actions possibles pour une clé RSA: Signer Chiffrer Authentifier
Actions actuellement permises: Authentifier

...

(Q) Terminé
Votre choix ? qq
les clés RSA peuvent faire entre 1024 et 4096 bits de longueur.
Quelle taille de clé désirez-vous ? (2048)3072
La taille demandée est 3072 bits
Spécifiez combien de temps cette clé devrait être valide.
0 = la clé n'expire pas

...

La clé est valide pour ? (0)0
La clé n'expire pas du tout
Est-ce correct ? (o/N)o
Créer vraiment ? (o/N)o
Un grand nombre d'octets aléatoires doit être généré. Vous devriez faire
autre-chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers; cela donne au générateur de
nombres aléatoires une meilleure chance d'avoir assez d'entropie.
pub 3072R/6CC468AC créé: 2009-11-12 expire: jamais utilisation: SC
confiance: ultime validité: ultime
sub 3072R/D9B0321B créé: 2009-11-12 expire: jamais utilisation: E
sub 3072R/6BE72291 créé: 2009-11-12 expire: jamais utilisation: A
[ ultime ] (1). John DOE (Compte de test) <john@doe.net>

Commande>save

Créons sur notre clé de sauvegarde un répertoire .gnupg, copie conforme de notre .gpg_sav :

$ cp -pR /media/disk-1/.gpg_sav /media/disk-1/.gnupg

Il suffit ensuite de créer un lien symbolique qui pointera vers notre répertoire /media/disk-1/.gnupg.

Attention, il faut vérifier qu’il n’existe pas de répertoire .gnupg sous notre home directory.
Pour cela, la commande suivante ne doit donner aucun résultat (comme nous n’avons pas encore réellement initialisé GnuPG2, cela devrait être le cas).

$ ls -ltra ~/.gnupg
$ ls: ne peut accéder .gnupg: Aucun fichier ou dossier de ce type

S’il existe, renommez-le. Nous allons maintenant créer notre lien symbolique :

$ ln -s /media/disk-1/.gnupg/ .gnupg

voilà, de cette façon, à aucun moment nos clés ne seront réellement sur notre disque dur.

Nous allons maintenant pouvoir « initialiser » GnuPG2 et vérifier que les clés qui ont été créées sont bien disponibles. Tout d’abord les clés publiques :

$ gpg --list-key

/home/jdoe/.gnupg/pubring.gpg
-----------------------------
pub 3072R/6CC468AC 2009-11-12
uid John DOE (Compte de test) <john@doe.net>
sub 3072R/D9B0321B 2009-11-12
sub 3072R/6BE72291 2009-11-12
puis les clés privées :

$ gpg --list-secret-key

/home/jdoe/.gnupg/secring.gpg
-----------------------------
sec 3072R/6CC468AC 2009-11-12
uid John DOE (Compte de test) <john@doe.net>
ssb 3072R/D9B0321B 2009-11-12
ssb 3072R/6BE72291 2009-11-12

Voilà, les clés que nous avons créées sont bien là et elles ont été créées dans la même « philosophie » que les clés « on-card ». Nous avons une clé de signature (qui est en fait la clé principale), une sous-clé de chiffrement et une sous-clé d’authentification. Cependant, à la grande différence de la méthode « on-card », cette méthode va nous permettre de pouvoir créer une smartcard contenant ces trois clés, mais surtout une smartcard de secours, copie conforme de la première, puisque nous avons une copie complète au sens GnuPG du terme.

Nous allons donc créer dans la foulée une clé de révocation :

$ gpg --gen-revoke john@doe.net > revocation_john_doe.gpg

sec 3072R/6CC468AC 2009-11-12 John DOE (Compte de test) <john@doe.net>
Générer un certificat de révocation pour cette clé ? (o/N)o
choisissez la cause de la révocation:
0 = Aucune raison spécifiée

...

Q = Annuler
(Vous devriez sûrement sélectionner 1 ici)
Votre décision ?0
Entrez une description optionnelle ; terminez-là par une ligne vide:
>Compte de test

>
Cause de révocation: Aucune raison spécifiée
Compte de test
Est-ce d'accord ? (o/N)o
Vous avez besoin d'une phrase de passe pour déverrouiller la
clé secrète pour l'utilisateur: « John DOE (Compte de test) <john@doe.net> »
clé de 3072 bits RSA, ID CC468AC, créée le 2009-11-12
sortie avec armure ASCII forcée.
Certificat de révocation créé.

...

Nous déplaçons ce fichier dans le répertoire de sauvegarde de notre clé :

$ mv revocation_john_doe.gpg /media/disk-1/gpg_sav

6. Création d’une smartcard de secours

6.1 A partir des clés générées « on-card »

La smartcard de secours, dans ce cas-là, sera très restreinte, puisque seule la clé de chiffrement peut y être importée. Elle permettra de continuer à consulter et lire les courriels ou fichiers chiffrés avec cette identité cryptographique et c’est tout (puisque cette clé est une sous-clé de l’ancienne clé principale qui était dans la smartcard d’origine). Cette méthode n’est pas conseillée, sauf si l’on veut changer régulièrement de clé et perdre l’accès à ses anciennes données.

$ gpg --edit-key EE9E178B

...
La clé secrète est disponible.
pub 3072R/EE9E178B créé: 2009-11-12 expire: jamais utilisation: SC
confiance: ultime validité: ultime
sub 3072R/3B3F2C02 créé: 2009-11-12 expire: jamais utilisation: A
sub 3072R/20F24A95 créé: 2009-11-12 expire: jamais utilisation: E
[ ultime ] (1). John DOEbis (test bis) <johnbis@doe.net>

Commande>toggle

sec 3072R/EE9E178B créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/3B3F2C02 créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/20F24A95 créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
(1) John DOEbis (test bis) <johnbis@doe.net>

Commande>bkuptocard ./sk_C7E25E0720F24A95.gpg

...
Sélectionnez l'endroit où stocker la clé:
...

(2) Clé de chiffrement
Votre choix ?2
Vous avez besoin d'une phrase de passe pour déverrouiller la
clé secrète pour l'utilisateur: « John DOEbis (test bis)
<johnbis@doe.net> »
clé de 3072 bits RSA, ID 20F24A95, créée le 2009-11-12
Entrer votre Passphrase
Entrez Code PIN Admin
sec 3072R/EE9E178B créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/3B3F2C02 créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/20F24A95 créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
(1) John DOEbis (test bis) <johnbis@doe.net>

Commande>quit

Enregistrer les changements? (o/N)o

Si votre clé publique est déjà chargée, vous aurez accès au « General key info ». Dans le cas contraire, il faudra la charger. Nous allons préparer le terrain et configurer notre smartcard pour aller chercher notre clé publique :

$ gpg --card-edit

...
Commande>admin

Les commandes d'administration sont permises

Commande>url

URL pour récupérer la clé publique: %shttp://monserveur/EE9E178B .asc

Commande>fetch

gpg: clé EE9E178B: clé publique « John DOEbis (test bis) <johnbis@doe.net> » importée
gpg: Quantité totale traitée: 1
gpg: importée: 1 (RSA: 1)

Si nous faisons à nouveau un gpg –card-edit, nous obtenons les informations suivantes pour « General key info » :

General key info..: pub 3072R/20F24A95 2009-11-12 John DOEbis (test bis) <johnbis@doe.net>
sec# 3072R/EE9E178B créé: 2009-11-12 expire: jamais
ssb# 3072R/3B3F2C02 créé: 2009-11-12 expire: jamais
ssb> 3072R/20F24A95 créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345679

Nous remarquons que la clé de chiffrement est bien prise en compte pour notre nouvelle smartcard, comme l’atteste le numéro de série de notre smartcard figurant pour cette clé. Nous constatons également le signe dièse (#) devant la clé privée et la sous-clé d’authentification. Ce signe signifie que ces deux clés ne sont pas présentes, ce qui est tout à fait normal, puisqu’elles ne peuvent pas être extraites de la smartcard originale (les clés ayant été créées « on-card »).

Nous pourrons utiliser cette smartcard pour consulter les courriels qui ont été chiffrés auparavant, ainsi qu’accéder aux fichiers que nous avons pu chiffrer. Il reste à modifier la confiance que nous souhaitons accorder à cette clé.

$ gpg --edit-key EE9E178B

...
Commande>trust

pub 3072R/EE9E178B créé: 2009-11-12 expire: jamais utilisation: SC
confiance: inconnu validité: inconnu
sub 3072R/3B3F2C02 créé: 2009-11-12 expire: jamais utilisation: A
sub 3072R/20F24A95 créé: 2009-11-12 expire: jamais utilisation: E
[ inconnue] (1). John DOEbis (test bis) <johnbis@doe.net>
Décidez maintenant à quel point vous avez confiance en cet utilisateur
pour qu'il vérifie les clés des autres utilisateurs (en vérifiant les
passeports, en vérifiant les empreintes de plusieurs sources
différentes, etc.)

...

5 = je donne une confiance ultime
Votre décision ?5
Voulez-vous vraiment donner une confiance ultime à cette clé ? (o/N)o
pub 3072R/EE9E178B créé: 2009-11-12 expire: jamais utilisation: SC
confiance: ultime validité: inconnu
sub 3072R/3B3F2C02 créé: 2009-11-12 expire: jamais utilisation: A
sub 3072R/20F24A95 créé: 2009-11-12 expire: jamais utilisation: E
[ inconnue] (1). John DOEbis (test bis) <johnbis@doe.net>
Notez que la validité affichée pour la clé n'est pas nécessairement
correcte tant que vous n'avez pas relancé le programme.
Commande>quit

Nous allons maintenant vérifier que cela a bien été pris en compte en retapant la même commande :

$ gpg --edit-key EE9E178B

...
La clé secrète est disponible.
pub 3072R/EE9E178B créé: 2009-11-12 expire: jamais utilisation: SC
confiance: ultime validité: ultime
sub 3072R/3B3F2C02 créé: 2009-11-12 expire: jamais utilisation: A
sub 3072R/20F24A95 créé: 2009-11-12 expire: jamais utilisation: E
[ ultime ] (1). John DOEbis (test bis) <johnbis@doe.net>

6.2 Création d’une smartcard et smartcard de secours à partir des clés générées « off-card »

Il existe, là encore, deux façons de procéder. L’une à base de sous-clés qui restent sur votre PC, votre smartcard ne contenant que votre clé privée. L’inconvénient de cette méthode est de requérir le contenu du répertoire personnel gnupg pour fonctionner. Nous allons voir qu’il est possible de conserver le principe des clés générées « on-card » à partir des clés « off-card », sans les inconvénients de la méthode « on-card » (inconvénient principal étant la perte de la clé principale en cas de perte ou de défaillance de la smartcard).

Commençons par créer une copie du fichier secring.gpg qui contient la clé privée. Il ne faut surtout pas travailler directement sur votre copie de sauvegarde car cette dernière sera inutilisable par la suite.

Nous faisons une sauvegarde de notre clé privée afin de pouvoir créer nos deux smartcards (la principale et celle de sauvegarde) :

$ cd ~/.gnupg
$ cp secring.gpg secring.gpg.sav

Cette copie servira pour la création de la smartcard de « sauvegarde ». Nous avons maintenant tout ce dont nous avons besoin pour créer nos deux smartcards.

6.2.1 Création de notre smartcard principale

Transférons la clé secrète sur notre smartcard « principale » :

$ gpg --edit-key 6CC468AC

...
La clé secrète est disponible.
pub 3072R/6CC468AC créé: 2009-11-12 expire: jamais utilisation: SC
confiance: ultime validité: ultime
sub 3072R/D9B0321B créé: 2009-11-12 expire: jamais utilisation: E
sub 3072R/6BE72291 créé: 2009-11-12 expire: jamais utilisation: A
[ ultime ] (1). John DOE (Compte de test) <john@doe.net>

Commande>toggle

sec 3072R/6CC468AC créé: 2009-11-12 expire: jamais
ssb 3072R/D9B0321B créé: 2009-11-12 expire: jamais
ssb 3072R/6BE72291 créé: 2009-11-12 expire: jamais
(1) John DOE (Compte de test) <john@doe.net>

Commande>keytocard

Enlever réellement la clé principale ? (o/N) o

...

Sélectionnez l'endroit où stocker la clé:
(1) Clé de signature
(3) Clé d'authentification
Votre choix ?1
Vous avez besoin d'une phrase de passe pour déverrouiller la
clé secrète pour l'utilisateur: « John DOE (Compte de test)
<john@doe.net> »
clé de 3072 bits RSA, ID 6CC468AC, créée le 2009-11-12
Entrer votre Passphrase
Entrez Code PIN Admin
sec 3072R/6CC468AC créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/D9B0321B créé: 2009-11-12 expire: jamais
ssb 3072R/6BE72291 créé: 2009-11-12 expire: jamais
(1) John DOE (Compte de test) <john@doe.net>

Nous transférons les deux sous-clés. Pour ce faire, nous sélectionnons tout d’abord la clé de chiffrement (key 1). Le symbole ***** apparaît devant cette clé, indiquant qu’elle est bien sélectionnée :

Commande>key 1

sec 3072R/6CC468AC créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb* 3072R/D9B0321B créé: 2009-11-12 expire: jamais
ssb 3072R/6BE72291 créé: 2009-11-12 expire: jamais
(1) John DOE (Compte de test) <john@doe.net>

Nous la transférons maintenant sur la smartcard avec la commande keytocard :

Commande>keytocard
...

Nous sélectionnons l’endroit où nous souhaitons qu’elle soit stockée, ici il n’y a qu’une seule possibilité :

Sélectionnez l'endroit où stocker la clé:
(2) Clé de chiffrement
Votre choix ?2
Vous avez besoin d'une phrase de passe pour déverrouiller la
clé secrète pour l'utilisateur: « John DOE (Compte de test)
<john@doe.net> »
clé de 3072 bits RSA, ID D9B0321B, créée le 2009-11-12
Entrer votre Passphrase
Entrez votre Code PIN Admin
sec 3072R/6CC468AC créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb* 3072R/D9B0321B créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/6BE72291 créé: 2009-11-12 expire: jamais
(1) John DOE (Compte de test) <john@doe.net>

Nous devons maintenant désélectionner cette clé :

Commande>key 1

sec 3072R/6CC468AC créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/D9B0321B créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/6BE72291 créé: 2009-11-12 expire: jamais
(1) John DOE (Compte de test) <john@doe.net>

Au passage, nous constatons qu’elle est bien stockée sur notre smartcard. Nous sélectionnons la deuxième sous-clé :

Commande>key 2

sec 3072R/6CC468AC créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/D9B0321B créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb* 3072R/6BE72291 créé: 2009-11-12 expire: jamais
(1) John DOE (Compte de test) <john@doe.net>

Nous la transférons maintenant sur la smartcard avec la commande keytocard :

Commande>keytocard

Nous sélectionnons l’emplacement où nous souhaitons qu’elle soit stockée, ici authentification :

Sélectionnez l'endroit où stocker la clé:
(3) Clé d'authentification
Votre choix ?3
Vous avez besoin d'une phrase de passe pour déverrouiller la
clé secrète pour l'utilisateur: « John DOE (Compte de test)
<john@doe.net> »
clé de 3072 bits RSA, ID 6BE72291, créée le 2009-11-12
Entrer votre Passphrase
Entrez votre Code Admin
sec 3072R/6CC468AC créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/D9B0321B créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb* 3072R/6BE72291 créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
(1) John DOE (Compte de test) <john@doe.net>

Nous désélectionnons la sous-clé :

Commande>key 2

sec 3072R/6CC468AC créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/D9B0321B créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb 3072R/6BE72291 créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
(1) John DOE (Compte de test) <john@doe.net>

Nous sauvegardons les modifications que nous avons effectuées :

Commande>save

Et voilà, nous avons créé notre première smartcard contenant les clés que nous avions créées « off-card ». Nous pouvons d’ailleurs aisément le vérifier :

$ gpg –card-status

Nous voyons apparaître ceci :

Signature key ....: 82E7 9476 23EA 78AD BB4B 94AF E50C 3BCA 6CC4 68AC
created ....: 2009-11-12 17:56:19
Encryption key....: 511D BCE6 7E27 1DE8 AE28 ACCF E053 DF7D D9B0 321B
created ....: 2009-11-12 17:56:19
Authentication key: E083 F36F 4ED7 FA6A 93FE 2428 4386 D463 6BE7 2291
created ....: 2009-11-12 17:59:43
General key info..: pub 3072R/6CC468AC 2009-11-12 John DOE (Compte de test) <john@doe.net>
sec> 3072R/6CC468AC créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb> 3072R/D9B0321B créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678
ssb> 3072R/6BE72291 créé: 2009-11-12 expire: jamais
n° de carte: 0005 12345678

A présent, nos clés sont bien sur notre smartcard. Nous pourrions également le vérifier avec la commande suivante :

$ gpg --list-secret-key

/home/jdoe/.gnupg/secring.gpg
-------------------------------

sec> 3072R/6CC468AC 2009-11-12
N° de série de la carte = 0005 12345678
uid John DOE (Compte de test) <john@doe.net>
ssb> 3072R/D9B0321B 2009-11-12
ssb> 3072R/6BE72291 2009-11-12

Ce qui indique bien que nos clés sont stockées sur notre smartcard (numéro de série).

6.2.2 Création de notre smartcard de secours

Passons à la création d’une smartcard de secours. Pour ce faire, nous allons reprendre certaines étapes effectuées précédemment.

Pour cela, nous allons déjà réinitialiser la partie clé secrète, car le fichier actuel secring.gpg ne contient plus notre clé secrète, mais heureusement, nous l’avions prévu.

$ cp secring.gpg.sav secring.gpg

A partir de là, il ne vous reste plus qu’à reprendre toute la partie précédente que nous avons effectuée lors de la création de notre smartcard principale (c’est-à-dire la partie 6.2.1 entièrement).

Une fois que cela est fait, nous pouvons activer GnuPG sur notre PC avec les fichiers « qui vont bien ».

Pour cela, nous allons supprimer tous les fichiers secring.gpg :

$ rm ~/.gnupg/secring*

nous supprimons le lien symbolique :

$ cd ..
$ rm .gnupg

Une fois effectué, nous créons notre vrai répertoire .gnupg

$ mkdir .gnupg

Il ne nous reste plus qu’à y transférer les fichiers nécessaires :

$ cp /media/disk-1/.gnupg/* ./.gnupg

Voilà, il faut réactiver la configuration en prenant la smartcard « principale », ce qui est finalement très simple.

$ gpg –card-status
gpg: le porte-clés `/home/jdoe/.gnupg/secring.gpg` a été créé

Cela n’a l’air de rien, mais cette simple commande a permis de retrouver notre « bonne » configuration. Cette commande a d’ailleurs recréé le fichier secring.gpg qui permet de faire référence à la smartcard.

Vérifions-le :

$ gpg --list-secret-key

/home/jdoe/.gnupg/secring.gpg
---

sec> 3072R/6CC468AC 2009-11-12
N° de série de la carte = 0005 12345679
uid John DOE (Compte de test) <john@doe.net>
ssb> 3072R/D9B0321B 2009-11-12
ssb> 3072R/6BE72291 2009-11-12

Voilà, c’est fini. Il ne nous reste plus qu’à utiliser notre belle smartcard, fraîchement générée.

7. Test du bon fonctionnement : signature, chiffrement et déchiffrement, vérification de la signature en une seule ligne de commande

Voici probablement la chose la plus simple à utiliser, si tout s’est bien passé jusqu’à présent.

Nous allons également vérifier que le compteur de signature de notre smartcard s’incrémente bien lorsque nous utilisons la fonction de signature. Pour cela, regardons à combien il se trouve avant :

$ gpg --card-status | grep "Signature counter"
Signature counter : 0

On remarque ici que notre compteur est à 0, puisque nous ne l’avons pas encore utilisé. Dans le cas de clés générées « on-card », ce compteur serait à 6, car les clés et sous-clés « s’entre-signent » lors de la génération des clés.

$ echo "TEST" | gpg -ase -r 6CC468AC | gpg
gpg: chiffré avec une clé de 3072 bits RSA, ID D9B0321B, créée le
2009-11-12
« John DOE (Compte de test) <john@doe.net> »
Entrez votre Code PIN pour signature
Entrez votre Code PIN
TEST
gpg: Signature faite le jeu. 12 nov. 2009 19:18:32 CET avec la clé RSA
ID 6CC468AC
gpg: Bonne signature de « John DOE (Compte de test) <john@doe.net>»

Petite explication de cette ligne de commande :

  • -a : créer une sortie ASCII avec armure
  • -s : faire une signature
  • -e : chiffre les données
  • -r : déchiffre et/ou vérifie la signature pour la clé dont le numéro est spécifié ou le user-id

Ainsi, cette « simple » ligne de commande va « simuler » la signature du message « TEST », chiffrer ce message, puis gpg va déchiffrer et vérifier la signature du message. Par conséquent, si tout fonctionne correctement, vous devriez voir apparaître : TEST ainsi que la vérification de la signature à la fin du traitement de cette commande.

Si vous avez bien ce résultat, vous avez validé que votre jeu de clé (publique/privée) permet d’effectuer les tâches de signature, de chiffrement et surtout de déchiffrement et de vérification de signature.

Vérifions que notre compteur s’est bien incrémenté :

$ gpg --card-status | grep "Signature counter"  
Signature counter : 1

Conclusion

Nous avons vu l’implémentation de GnuPG2, associée à une smartcard GnuPG V2, la création d’une smartcard de secours et enfin validé le bon fonctionnement de notre smartcard V2 avec GnuPG2. J’espère que cette première partie de l’article vous aura donné envie d’utiliser GnuPG2 et d’aller encore plus loin dans l’utilisation d’une smartcard GnuPG V2. Nous verrons dans une deuxième partie son utilisation au « quotidien » dans différentes situations : avec des fonctions avancées comme l’ouverture de session Gnome, et l’ouverture de session ssh, une utilisation plus « classique » avec la gestion de votre trousseau de clés et l’utilisation de différents logiciels de courriels. J’espère également que l’intégration des lecteurs avec « keypad » s’améliorera, ce qui augmentera un peu plus le gain de sécurité.

Liens

Le site de GnuPG : http://gnupg.org/
Le manuel de GnuPG : http://gnupg.org/documentation/manuals/gnupg.pdf
Le site g10code (site entre autres de la smartcard) : http://g10code.com/
Le manuel de la smartcard : http://g10code.com/docs/openpgp-card-2.0.pdf
Le site pour acheter la smartcard : http://shop.kernelconcepts.de