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

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 V1 Smartcard GnuPG V1	Smartcard OpenPGP V1 Smartcard GnuPG 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 :

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.

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 :

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).

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.

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 :

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.

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 :

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 gpg2 nous l'indique tout de suite :

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 :

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 :

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

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

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 :

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 :

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) :

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

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).

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

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 :

puis les clés privées :

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 :

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

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.

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 :

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

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é.

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

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) :

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 » :

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 :

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

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

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

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

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

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

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

Nous sauvegardons les modifications que nous avons effectuées :

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 :

Nous voyons apparaître ceci :

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

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.

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 :

nous supprimons le lien symbolique :

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

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

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

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 :

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 :

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.

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 gpg2 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é :

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