Utilisation de smartcards GnuPG V2 au « quotidien », Partie 2

1. Utilisation de notre smartcard pour une ouverture de session (sous Gnome)

1.1 Installation de libpam-poldi

Pour cela, nous allons utiliser le paquet poldi (qui est encore un paquet expérimental du point de vue de Debian)

La partie configuration du paquet debian est un peu juste et ne donne pas toutes les informations nécessaires (il n'y a que le README.debian) à sa configuration, il faut donc se reporter à la documentation officielle de poldiprésente dans les sources pour en savoir plus.

Une des grosses différences, par rapport à la version 0.3, est que la ligne de commandes usuellement utilisée n'est plus disponible. Notez qu'une même smartcard peut être validée pour plusieurs utilisateurs.

Une fois installé, nous allons faire prendre en compte la carte et surtout l’associer à l’utilisateur. Pour ce faire, il faut être root, car seuls les droits root permettent de faire cette configuration. Le paquet intégré dans Squeeze est un peu différent du paquet dans Lenny, présenté dans l’article paru dans GNU/Linux Magazine n°113 (les options de la commande poldi-ctrl ne sont plus disponibles). Il faut directement paramétrer le fichier de configuration.

Dans la version précédente de libpam-poldi (0.3), il fallait effectuer la commande suivante :

Avec la version 0.4, la plupart du code a été réécrit pour prendre en compte deux « bases » : l'une locale et l'autre pki, à base de certificats x509.

Une commande résume toutes les informations nécessaires à poldi pour une smartcard donnée :

Nous avons le numéro de série de notre smartcard, qui peut d'ailleurs être directement lue sur cette dernière ; mais surtout la clé publique de notre clé d'authentification, au sens PAM du terme.

1.2 Choix de la méthode d'authentification

1.2.1 Méthode localdb

Pour cette méthode, nous ouvrons le fichier de configuration :

Il faut vérifier que la ligne suivante est présente :

Une fois cette vérification faite, nous nous intéressons aux deux fichiers servant à valider une smartcard pour un utilisateur donné. Le premier fichier à modifier est le fichier users :

et on y ajoute la ligne suivante dans le fichier :

En fait, on renseigne ici le numéro de la smartcard suivi d'un espace, suivi du nom de l'utilisateur (au sens Linux) que l'on veut associer à cette smartcard,

Le deuxième fichier est un fichier à créer, qui doit avoir comme nom le numéro de série de la smartcard. Pour ce faire, nous avons deux solutions :

L'autre méthode est bien sûr :

et ajouter les lignes suivantes :

Voilà, il ne nous reste plus qu'à activer cette authentification par smartcard au niveau de gdm.

1.2.2 Méthode x509

Il existe une autre méthode à base de certificats x509, mais elle nécessite la plupart du temps la mise en place d'un serveur LDAP pour stocker le certificat x509 en fonction de l'utilisateur. Cette méthode n'est pas décrite dans cet article.

1.3 Prise en compte de notre smartcard pour l'authentification

Il existe deux façons de faire, l'une sécurisée avec la demande du code PIN, une autre plus « automatisée » sans demande de code PIN. La seule présence de la smartcard dans le lecteur suffira (cependant, cette méthode n'est pas satisfaisante du point de vue de la sécurité car elle implique la présence en clair du code PIN de votre smartcard dans un fichier), nous vous laissons néanmoins libre de faire votre choix en toute connaissance de cause entre ces deux solutions. Les modifications présentées ci-dessous seront à faire avec les droits root.

Dans un premier temps, nous allons créer une copie du fichier common-auth (cette partie est commune aux deux méthodes) :

1.3.1 Méthode « sécurisée »

Nous allons ensuite modifier le fichier que nous venons de créer :

Nous allons ajouter la ligne suivante au tout début du fichier :

Puis nous sauvegardons ce fichier.

1.3.2 Méthode « automatisée »

Nous allons ensuite modifier le fichier que nous venons de créer :

Nous allons ajouter la ligne suivante au tout début du fichier :

Puis nous sauvegardons ce fichier. Nous considérerons ici que votre code PIN est celui d'origine 123456. Bien sûr, cette partie sera à adapter en fonction du code PIN de votre smartcard.

1.4 Activation de l'authentification poldi pour gdm

Nous allons maintenant nous occuper de la partie gdm. Pour ce faire, nous allons modifier la façon dont gdm doit demander l'authentification des utilisateurs. On modifie le fichier gdm pour prendre en compte la modification que nous venons d'effectuer précédemment :

On remplace la ligne

par la ligne suivante :

Voilà, lors de votre prochaine ouverture de session Gnome, si votre smartcard est dans votre lecteur, il vous sera demandé votre code PIN pour ouvrir votre session (si vous avez choisi la méthode sécurisée) ou cela sera transparent dans le cas de la deuxième méthode. Si cela ne fonctionne pas pour n'importe quelle raison, la méthode classique vous sera proposée.

Pour tester, il ne nous reste plus qu'à fermer notre session Gnome et à en ouvrir une autre. Si vous avez les sources de poldi, vous pouvez également directement tester vos modifications avec le binaire pam-test qui se trouve sous le répertoire test des sources.

Pour ce faire, vous pouvez aller dans le répertoire où se trouve ce binaire et taper la commande suivante :

Si tout s'est bien passé, lors de votre prochaine session Gnome, la mire va demander le nom de l'utilisateur que vous souhaitez utiliser, puis elle demandera d'insérer la smartcard, si ce n'est déjà fait, et enfin de taper le code PIN ou non suivant la méthode que vous aurez choisie.

De la même façon, nous pouvons également paramétrer l'authentification pour l'économiseur d'écran.

1.5 Activation de l'authentification poldi pour l'économiseur d'écran

On modifie gnome-screensaver pour prendre en compte la modification que nous venons d'effectuer :

On remplace la ligne

par la ligne suivante :

Lorsque votre économiseur d'écran s'activera, il vous sera demandé votre code PIN (ou non) pour déverrouiller votre économiseur d'écran. Si cela ne fonctionne pas, on repasse en authentification classique.

Bien que non abordé dans cet article, vous avez compris la logique liée à PAM. Vous pouvez donc l'appliquer aux outils login et sudo...

2. Connexion ssh sur des serveurs en utilisant la clé d'authentification de la smartcard

Nous supposons que le serveur ssh est déjà opérationnel. Tout d'abord, avant d'en arriver là, il convient de faire certaines modifications dans certains scripts déjà en place.

Nous commencerons par modifier le fichier 90gpg-agent qui se trouve sous /etc/X11/Xsession.d

On recherche la ligne suivante :

qui se trouve pratiquement à la fin du fichier, en y ajoutant –enable-ssh-support

On sauvegarde ce fichier.

Voici ce que retournait la commande avant modification du fichier 90gpg-agent :

Il est également nécessaire de modifier notre fichier de session .bashrc en y ajoutant ceci à la fin :

Cela permet de récupérer les différentes informations nécessaires à la gestion de notre clé ssh par l'agent gpg-agent.

Nous allons modifier le fichier gpg-agent.conf pour lui indiquer que nous souhaitons l'utiliser pour les clés ssh :

On y ajoute les lignes suivantes :

- defaut-cache-ttl-ssh 600 indique à gpg-agent de garder en cache durant 10 minutes la passphrase de notre clé ssh.

- Max-cache-ttl-ssh 1000 indique le temps maximum durant lequel gpg-agent peut garder en mémoire la passphrase.

On devra une nouvelle fois redémarrer notre session Gnome pour la prise en compte de ces modifications. Afin de constater si cela fonctionne correctement, nous pouvons déjà essayer la commande suivante :

La commande ssh-add -l devrait nous renvoyer la liste de toutes les empreintes de nos clés ssh.

Cependant, on s'aperçoit assez rapidement que ce n'est pas le cas… Il y a donc quelque chose qui « bloque ». Regardons si les informations présentes sur la smartcard sont bien accessibles :

Ici, c'est la troisième clé qui nous intéresse. Nous pouvons accéder à la clé dont nous avons besoin.

Pour la petite histoire, pensant à un problème d'option d'OpenSSH, j'ai recompilé avec l'option –with-opensc, les soucis ont tout de même perduré. J'ai donc vérifié avec la commande suivante si l’agent SSH était bien celui que je pensais :

L'agent n'était pas le bon. Après une rapide recherche sur Internet, le site de Gnome [1] donne la solution : gnome-keyring inclut sa propre gestion d'agents SSH. Il faut donc le désactiver. Pour cela, il existe deux solutions :

- soit en ligne de commandes : gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false,

- soit en passant par l'interface graphique après avoir lancé la commande gconf-editor, puis décocher le ssh qui se trouve dans => apps / gnome-keyring / daemon-components.

Une fois cette opération effectuée, il suffit de redémarrer sa session Gnome pour que cela soit pris en compte. On regarde l'affectation de la variable ad-hoc :

Il ne reste plus qu'à créer et/ou ajouter sa clé publique dans le fichier authorized_keys :

La commande ssh-add a eu pour effet de créer un fichier dans le répertoire ~/.gnupg/private-keys-v1.d :

qui correspond comme nous pouvons le constater à notre clé d'authentification au sens ssh du terme.

Nous allons maintenant ajouter notre clé dans le fichier sshcontrol.

et y ajouter la ligne suivante :

qui correspond à notre clé obtenue par la commande KEYPAIRINFO.

Voilà, la configuration de la partie ssh sur notre PC est achevée. Il ne nous reste plus qu'à ajouter notre clé publique ssh sur le ou les serveurs sur lesquels nous souhaitons nous connecter.

Sur chaque serveur où nous souhaitons pouvoir utiliser cette clé ssh pour nous connecter, nous allons créer le fichier authorized_keys (si ce dernier n'existe pas) et pour l'utilisateur concerné. Ce dernier pourra être différent de notre login sur notre PC (cela pourra par exemple être l'utilisateur root).

Une fois connectés sur le serveur avec les login et mot de passe usuels, nous tapons la commande suivante :

et nous y ajoutons notre clé publique :

Voilà ! Nous sauvegardons ce fichier et allons tester notre connexion à partir de notre PC.

Ca y est, nous nous sommes connectés sur notre serveur avec notre smartcard.

3. Interfaces GUI pour la gestion du trousseau de clés

3.1 GPA (GNU Privacy Assistant) version 0.9

La version de GPA 0.9 nécessite au minimum la version 1.2 de la libgpgme11. Comme cette version n’était pas disponible dans les dépôts Debian, il a fallu recompiler la bibliothèque. Il en va de même pour la version de GPA, cette dernière n’ayant pas été mise à jour dans les dépôts (toutes versions confondues) depuis la version 0.7. A l'heure actuelle, la version de libgpgme11 1.2 disponible sur les dépôts (Squeeze et Sid) n'est pas utilisable pour ce qui nous intéresse, car l'option utf8 n'est pas prise en compte, ce qui génère une erreur au lancement de GPA.

Lorsque vos paquets sont créés, il ne reste plus qu'à les installer :

puis à lancer gpa (Applications, Accessoires, GNU Privacy Assistant, ou exécutez gpa). Si aucune clé n’a encore été installée, la fenêtre ci-dessous s’affiche, invitant à créer un jeu de clés :

L’une des principales nouveautés de la version 0.9 est la gestion des smartcards. On le remarque tout de suite avec l’apparition d’un nouveau bouton dont la bulle de commentaire indique « Open the card manager ». Il suffit donc de cliquer dessus.

Dans le cas où l’on aurait pas encore modifié le fichier gpg.conf en y ajoutant use-agent, le message suivant s’afficherait : « Error accessing the card » et tout en bas à gauche de la fenêtre « Checking for card … ».

Si l'agent est déjà lancé, vous pouvez accéder à la gestion du contenu de la smartcard GnuPG V2. En bas, à gauche, on constatera le message « OpenPGP card detected ». On pourra également remarquer en cliquant sur le menu déroulant situé en haut à droite (Application selection) que l’on accède à la gestion des smartcards suivantes : openpgp, nks, p15, densig et geldkard.

Dans le cas de figure qui nous intéresse, nous allons nous occuper uniquement de la partie openpgp. On remarque aisément que l’on accède à la plupart des informations contenues dans notre smartcard, même si l’on accède à plus d’informations en ligne de commandes.

Pour information, les données que l’on peut lire (mais c’est d’ailleurs le cas en ligne de commandes) sont liées à la clé publique correspondante. Si vous avez importé votre clé publique dans votre trousseau ou renseigné la « Public Key URL » indiquant où est stockée votre clé publique, cela s'affichera. Dans le cas contraire, si votre clé publique n’est pas accessible, la seule information que vous pourrez obtenir sur les clés contenues dans votre smartcard sera la liste des empreintes de chacune d’elles, rien de plus.

Les « key attributes » sont disponibles depuis la version GnuPG2 2.0.13. Elles correspondent à la valeur d’encodage des clés RSA (1024, 1536, 2048 ou 3072 (la version V2 de cette smartcard n’acceptant pas de clés supérieures à 3072 bits)). Les nouvelles smartcards « accepteraient » même des clés de 4096 bits, mais sans aucune garantie de fonctionnement et ne peuvent d'ailleurs pas être générées « on-card » car paramétrées au maximum pour des clés de 3072 bits. Si l’on essaye d’avoir plus d’informations sur les différentes clés, on verra apparaître « Pas de clé sélectionnée », car GPA n’a pas trouvé la clé publique correspondante.

GPA ne permet pas de faire toutes les modifications que l'on souhaiterait (contrairement à la cli). Ainsi, toutes les parties dites optionnelles par gpg : nom, prénom, langue, sexe, url key, ne sont pas modifiables par cette interface (car ce sont des informations optionnelles du point de vue GnuPG).

L'avantage de ce logiciel, par rapport à son concurrent Seahorse, est qu'il permet de générer les trois clés directement sur la smartcard via son interface et d'accéder aux informations contenues sur notre smartcard.

3.2 Seahorse

Par rapport à GPA, Seahorse comporte quelques fonctionnalités complémentaires, mais affiche également des manques. Parmi les fonctionnalités absentes, on compte la gestion des smartcards (création de clés et détail de la smartcard). Cependant, il gère très convenablement les UID :

Par Seahorse, on peut tout à fait ajouter ou supprimer un UID. On peut également indiquer, dans le cas où plusieurs UID seraient présents, lequel est prioritaire. Voici le détail des clés vues par Seahorse :

On remarque rapidement nos trois clés. Par contre, il n’y a ici aucune notion ou référence à notre smartcard (ce que fait GPA).

3.3 GnuPG Shell

3.3.1 Interface principale :

GnuPG Shell est peut-être un peu plus limitée que les deux interfaces que nous venons de vous présenter, car elle est dédiée GnuPG. Cependant, elle permet de gérer normalement les clés GnuPG. Un petit plus pour sa part serait son interface « File Manager » qui permet de gérer la partie fichier.

3.3.1 Interface de gestion des fichiers :

Cette autre interface permet de gérer la partie fichier et permet de signer, chiffrer et déchiffrer des fichiers. Cependant, dans cette interface n'apparaîtront que les fichiers qui sont chiffrés.

4. Utilisation avec différents clients de courriels

Bien que pas nécessairement en rapport direct avec les smartcards, nous vous proposons d'aller encore un peu plus loin et d'implémenter le chiffrement et la signature numérique, basés sur gpg. Au moment critique, à savoir l'écriture de votre passphrase, c'est votre code PIN qui sera demandé. Magique !

4.1 Evolution

Nous considérons ici que vous avez déjà installé Evolution et paramétré votre compte courriel. Votre trousseau de clés contient déjà les clés que vous souhaitez utiliser.

Nous allons maintenant paramétrer votre compte pour pouvoir utiliser GnuPG.

Allez dans Edition/Préférences/Comptes de Messagerie, sélectionnez votre compte, puis cliquez sur Edition. Allez ensuite dans l’onglet de sécurité et indiquez dans le champ ID de la clé PGP/GPG l’ID de votre clé GPG correspondant à votre compte courriel, puis sélectionnez les options qui vous intéressent :

• Toujours signer les messages sortants lors de l'utilisation de ce compte ;
• Ne pas signer les demandes de réunion (compatibilité Outlook) ;
• Toujours chiffrer pour moi-même lors de l'envoi de messages chiffrés ;
• Toujours faire confiance aux clés de mon trousseau lors du chiffrement.

Pour signer et/ou chiffrer vos courriels il ne vous reste plus qu’à rédiger votre courriel en cliquant sur Nouveau, puis aller dans sécurité et sélectionner Signer avec PGP et/ou Chiffrer avec PGP :

Lorsque vous signerez votre courriel, le popup code PIN apparaîtra, il ne reste plus qu'à le compléter...

4.2 Claws-Mail

Pour la prise en charge de Claws-Mail, il faut créer un fichier gpg-agent.conf et y ajouter les lignes suivantes :

Dans la documentation de Claws-Mail, il est indiqué de mettre l'option no-grab. Cependant, cette option est assez dangereuse et fonctionne très bien sans.

Une fois ce fichier sauvegardé, nous nous intéressons à la partie Claws-Mail en elle-même : il faut ajouter les paquets claws-mail-pgpinline et claws-mail-pgpmime, ce qui ajoutera les modules pgp-core et pgp-mime.

On peut ensuite lancer Claws-Mail et paramétrer l'accès aux nouvelles fonctionnalités. Nous partons du principe que vous avez déjà installé Claws-Mail et paramétré une boite de courriels.

Voici le bandeau principal de Claws-Mail :

Il faut aller dans Configuration/Modules puis cliquer sur charger, nous sélectionnons ensuite pgpinline.so et pgpmime.so. Cela aura aussi pour conséquence de sélectionner pgpcore.so. Il ne reste plus qu'à valider.

Il faut maintenant activer l’utilisation de GnuPG pour chaque compte Claws-Mail.

Allez dans Configuration/Edition des comptes, puis sélectionnez le compte que vous voulez modifier et cliquez ensuite sur le bouton Modifier.

Pour finir, allez dans la partie Modules/GPG, si vous n'utilisez qu’une seule clé GPG, vous pouvez sélectionner la clé GnuPG par défaut. Dans le cas où vous utilisez plusieurs clés, vous pouvez sélectionner soit :

• choisir la clé en fonction de l’adresse courriel ;
• spécifier la clé manuellement (en indiquant l’ID de la clé souhaitée).

Vous pouvez maintenant utiliser cette nouvelle fonction. Pour pouvoir signer et/ou chiffrer un courriel, il va falloir cliquer sur le bouton Composer, ensuite il faudra aller dans Option/Système de Confidentialité et valider PGP MIME. Une fois ceci fait, il ne vous reste plus qu’à sélectionner Signer et/ou chiffrer pour avoir l’option souhaitée lorsque vous enverrez votre courriel.

Nous allons maintenant paramétrer la partie GPG, on ouvre Claws-Mail, puis dans Configuration/Préférences/Modules, on sélectionne GPG. On sélectionne ensuite les trois options suivantes (si elles ne sont pas déjà sélectionnées) :

• utiliser gpg-agent pour gérer les mots de passe ;
• monopoliser le clavier pendant la saisie de la phrase secrète ;
• avertir au démarrage si GnuPG ne fonctionne pas.

Nous allons maintenant paramétrer la partie qui concerne notre BAL pour chaque utilisateur pour qui nous souhaitons pouvoir utiliser GnuPG2. Dans ce cas, il faudra refaire la même opération.

Il faut également paramétrer la partie Confidentialité (qui se trouve également dans la partie Préférence, mais de votre compte courriel). Nous allons donc dans Configuration, Édition des Comptes et sélectionnons le compte qui nous intéresse, puis nous cliquons sur modifier. Ensuite, dans Compte, Confidentialité, nous sélectionnons PGP MIME ou PGP Inline et nous validons les différentes options qui nous intéressent pour chacune de ces deux options.

Puis, dans la fenêtre de composition des courriels, nous sélectionnons PGP MIME ou PGP Inline dans Système de confidentialité par défaut, ensuite à vous de sélectionner les options qui vous intéressent.

Voici la fenêtre de création de courriel avec les options GnuPG :

On confirme en cliquant sur le bouton Appliquer, puis Valider.

En fait, il y a deux plugins qui s’utilisent de façon différente :

• le plugin Inline : permet de chiffrer vos courriels tels quels directement ;
• le plugin PGP MIME : permet de chiffrer vos courriels et de les ajouter à votre courriel en tant que pièce jointe.

4.3 Thunderbird (icedove sous debian)

Pour Thunderbird, nous utilisons en fait le module Enigmail. Installons Enigmail si ce n’est déjà fait :

Lorsque l’on ouvre Icedove et que l’on va dans OpenPGP/Préférence, la fenêtre qui s’ouvre est très basique. Nous vous conseillons de valider dans cette fenêtre l’option Display expert settings, ce qui permet de mieux pouvoir la paramétrer. En particulier, on voit apparaître l’onglet Key Selection qui permet de paramétrer comme sur Claws-Mail l’association des clés en fonction des adresses courriels. Il est également possible d’affiner ce paramétrage en cliquant sur le bouton Edit Rules. Cependant, de base, le paramétrage proposé convient à la majorité des cas. Il y a également l’onglet Avanced qui est intéressant, on va en particulier pouvoir indiquer d’utiliser gpg-agent si on le souhaite.

Tout comme pour les autres, on rédige son courriel de la manière habituelle et au moment de l’envoyer, on clique sur le bouton OpenPGP et on valide l’option Sign message et/ou Encrypt message suivant ce que l’on souhaite faire. On pourrait également lui indiquer que l’on souhaite utiliser S/MIME (mais il faudrait alors également paramétrer cette option). Voilà, une fois que vous avez fait cela, il ne vous reste plus qu’à cliquer sur le bouton Envoyer.

Pour déchiffrer un courriel chiffré que vous aurez reçu, il suffira de sélectionner votre courriel, puis de cliquer sur le bouton Decrypt qui se trouve sur votre bandeau icedove.

Bandeau de composition de votre courriel :

5. FireGPG (une extension de Firefox ou iceweasel sous Debian)

FireGPG n'est pas un « vrai » programme autonome puisque c'est un plugin d'iceweasel. Cependant, il comporte des fonctionnalités très intéressantes, il serait vraiment dommage de ne pas en parler.

Nous installons donc ce plugin de la façon habituelle : Outils, Modules complémentaires, Catalogue, Recherche (tapez fireGPG), Ajouter à Iceweasel, Installer maintenant.

Cependant, une fois installé, nous devons le configurer. Dans notre cas, pour utiliser GnuPG2, il faudra modifier le binaire utilisé : Outils, FireGPG, Options, GPG, remplacez /usr/bin/gpg par /usr/bin/gpg2. Vous pouvez également activer gpg-agent.

Voilà, si vous relancez Firefox et retournez dans FireGPG (Outils, FireGPG, Gestionnaire de clés), vous verrez maintenant apparaître vos clés GPG (et normalement toutes celles présentes dans Seahorse ou GPA). A partir de là, vous pouvez signer ou chiffrer du texte, signer ou chiffrer des courriels avec GMail et également signer et/ou chiffrer des fichiers (Outils, FireGPG, Opération sur les fichiers).

Nous pouvons ainsi voir les différentes fonctionnalités disponibles.

Une fonctionnalité intéressante dans le menu Options est l'intégration du module pgpAuth qui permet de s'authentifier sur certains sites web.

Conclusion

Nous avons eu, dans cette deuxième partie de l'article, un aperçu un peu plus avancé des possibilités de GnuPG2, associées à une smartcard V2. J'espère que cette deuxième partie de l'article vous aura convaincu des possibilités de GnuPG2, décuplées par l’utilisation d’une smartcard GnuPG V2. Il reste encore d'autres possibilités à explorer comme la clé de chiffrement de partitions LUKS qui serait stockée sur notre smartcard favorite. Werner Koch travaille actuellement sur la version GnuPG 2.1 qui devrait intégrer (si les développements en cours aboutissent) la gestion de fonctionnalités EncFS à partir de GnuPG et donc de notre smartcard. Ceci fera peut-être l'objet d'une troisième partie de cet article.

Liens

[1] http://live.gnome.org/GnomeKeyring/Ssh

La page dédiée à Poldi : http://g10code.com/p-poldi.html

Le site de Gnu Privacy Assistant : http://wald.intevation.org/projects/gpa/

Le site de GnuPG Shell : http://fr.tech-faq.com/gnupg-shell.shtml

Le site de Claws-Mail : http://www.claws-mail.org/

Le site d'enigmail : http://enigmail.mozdev.org/home/index.php

Le site de FireGPG : http://fr.getfiregpg.org/s/home