Ceci est un article complémentaire à l’article précédent : "Utilisation de smartcards, GnuPG V2 au " quotidien "", orienté sur une utilisation " avancée " des possibilités de cette smartcard couplée à GnuPG2. Nous y aborderons son utilisation au " quotidien " en tant qu’authentification lors de la phase de login d’une session Gnome ainsi que la connexion sur des serveurs via une connexion SSH. Nous terminerons avec l’utilisation de GUI pour gérer votre trousseau de clés, ainsi que l’utilisation au sein de différents logiciels de courriers électroniques.
|
|
|
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)
|
$ aptitude install libpam-poldi
|
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
poldi pré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 :
|
$ poldi-ctrl –associate –account <nom d’utilisateur> —serialno <numéro de série de la smartcard>
|
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 :
|
$ poldi-ctrl -d
Serial number: D2760001240102000005123456780000
Signing key fingerprint: E083F36F4ED7FA6A93FE24284386D4636BE72291
Key:
(public-key
(rsa
(n
#00C04F11F808E3BE1D205DC2B689EA52AF747E89C6B1F244A250FD80911B803A877774
776405CA4279DF5F1535750ABCA8317039D3CA8BE7174FEEA02771A0019E65BFAF9BC7F
469F6BB93E82056B0129B45F0345EB67703841386BFE351194A8E2CEA3F545E95D60E81
138482A194E3062497040E4CD5042AD4C8D4DFEE132CE0867A8D2FDA58DC64131DB1D05
3DB7AC8D4548F6D29DA6D651B5BE3C4C784A3B2797FA6C91DBA75D3FC49F335016D2389
F15DD02FF69027C433862AAC4A25E94E4B0B8627266B4A905B5B63D575B8AB0369398FC
6E4B1620B1B02ECADEB1C2F69C0251C4D9D3570717F877A35D66A3CC6A5C0332D101627
F095F8B3B1BDBD973D89175744B5AECC8CAC997F00574E6E7CD6809B3501DF43E6D1601
BF5334C9E1C5A506D8C39F8941BFBEA9029C0D79167759678575519138146D2A7AFFDCF
3123A588E1F58E117547E7FC03A53F8CB10B8BD669B7BCFA19A8820891469A626B97993
06C8CF668DF9ED92525C731EE13E64336B1D59855215B17AAB20FE6C2E3EB#)
(e #00010001#)
)
)
|
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
|
Pour cette méthode, nous ouvrons le fichier de configuration :
|
$ vi /etc/poldi/poldi.conf
|
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 :
|
$ vi /etc/poldi/localdb/users
|
et on y ajoute la ligne suivante dans le fichier :
|
D2760001240102000005123456780000 jdoe
|
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 :
|
$ poldi-ctrl —print-key > /etc/poldi/localdb/keys/D2760001240102000005123456780000
|
L’autre méthode est bien sûr :
|
$ vi /etc/poldi/localdb/keys/D2760001240102000005123456780000
|
et ajouter les lignes suivantes :
|
(public-key
(rsa
(n #00C04F11F808E3BE1D205DC2B689EA52AF747E89C6B1F244A250FD80911B803A
877774776405CA4279DF5F1535750ABCA8317039D3CA8BE7174FEEA02771A0019E65BF
AF9BC7F469F6BB93E82056B0129B45F0345EB67703841386BFE351194A8E2CEA3F545E
95D60E81138482A194E3062497040E4CD5042AD4C8D4DFEE132CE0867A8D2FDA58DC64
131DB1D053DB7AC8D4548F6D29DA6D651B5BE3C4C784A3B2797FA6C91DBA75D3FC49F3
35016D2389F15DD02FF69027C433862AAC4A25E94E4B0B8627266B4A905B5B63D575B8
AB0369398FC6E4B1620B1B02ECADEB1C2F69C0251C4D9D3570717F877A35D66A3CC6A5
C0332D101627F095F8B3B1BDBD973D89175744B5AECC8CAC997F00574E6E7CD6809B35
01DF43E6D1601BF5334C9E1C5A506D8C39F8941BFBEA9029C0D7916775967857551913
8146D2A7AFFDCF3123A588E1F58E117547E7FC03A53F8CB10B8BD669B7BCFA19A88208
91469A626B9799306C8CF668DF9ED92525C731EE13E64336B1D59855215B17AAB20FE6
C2E3EB#)
(e #00010001#)
)
)
|
Voilà, il ne nous reste plus qu’à activer cette authentification par smartcard au niveau de gdm.
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) :
|
$ cp /etc/pam.d/common-auth /etc/pam.d/common-auth-poldi
|
|
|
|
1.3.1 Méthode " sécurisée "
|
Nous allons ensuite modifier le fichier que nous venons de créer :
|
$ vi /etc/pam.d/common-auth-poldi
|
Nous allons ajouter la ligne suivante au tout début du fichier :
|
auth sufficient pam_poldi.so
|
Puis nous sauvegardons ce fichier.
|
|
|
1.3.2 Méthode " automatisée "
|
Nous allons ensuite modifier le fichier que nous venons de créer :
|
$ vi /etc/pam.d/common-auth-poldi
|
Nous allons ajouter la ligne suivante au tout début du fichier :
|
auth sufficient pam_poldi.so try-pin=123456 quiet
|
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 :
|
@include common-auth-poldi
|
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 :
|
$ ./pam-test gdm
login:jdoe
|
|
Insert authentication card for user `jdoe’ Enter your PIN Code
Authentication succeeded
Authenticated as user `jdoe’
|
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 :
|
$ vi /etc/pam.d/gnome-screensaver
|
On remplace la ligne
par la ligne suivante :
|
@include common-auth-poldi
|
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
|
% vi /etc/X11/Xsession.d/90gpg-agent
|
On recherche la ligne suivante :
|
STARTUP=" $GPGAGENT —daemon —sh —write-env-file=$PID_FILE $STARTU "
|
qui se trouve pratiquement à la fin du fichier, en y ajoutant
–enable-ssh-support
|
STARTUP=" $GPGAGENT—daemon —enable-ssh-support —sh —write-env-file=$PID_FILE $STARTU "
|
On sauvegarde ce fichier.
Voici ce que retournait la commande avant modification du fichier
90gpg-agent :
|
$ ssh-add -l
Could not open a connection to your authentication agent.
|
Il est également nécessaire de modifier notre fichier de session
.bashrc en y ajoutant ceci à la fin :
|
# Setup Information required by GnuPG and ssh
if [ -f " ${HOME}/.gpg-agent-info-$(hostname) "]; then
. " ${HOME}/.gpg-agent-info-$(hostname) "
|
|
export GPG_AGENT_INFO
export SSH_AUTH_SOCK
export SSH_AGENT_PID
fi
GPG_TTY=$(tty)
export GPG_TTY
|
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 :
|
$ vi ~/.gnupg/gpg-agent.conf
|
On y ajoute les lignes suivantes :
|
# SSH-Agent activation
enable-ssh-support
default-cache-ttl-ssh 600
max-cache-ttl-ssh 1000
|
●
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 :
|
$ ssh-add -l
The agent has no identities.
|
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 :
|
$ echo scd learn —force | gpg-connect-agent | grep KEYPAIRINFO
S KEYPAIRINFO C87584EC4DC34CBD7B8A8F25CBC962F059E88C31 OPENPGP.1
S KEYPAIRINFO 36A75C357D7EC4357289371C5153DFECA85A3CF4 OPENPGP.2
S KEYPAIRINFO B348E102E64EBAA2B78A2A7D269412CA582CFA8E OPENPGP.3
|
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 :
|
$ echo $SSH_AUTH_SOCK
/tmp/keyring-J7HU9g/socket.ssh
|
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 :
|
% echo $SSH_AUTH_SOCK
/tmp/gpg-yCxt0i/S.agent.ssh
|
Il ne reste plus qu’à créer et/ou ajouter sa clé publique dans le fichier
authorized_keys :
|
$ ssh-add -l
3072 cf:55:cc:7e:db:74:43:c7:b0:11:ec:27:36:4e:26:b8 cardno:000512345
678 (RSA)
$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDATxH4COO+HSBdwraJ6lKvdH6JxrHyR
KJQ/YCRG4A6h3d0d2QFykJ5318VNXUKvKgxcDnTyovnF0/uoCdxoAGeZb+vm8f0afa7k+
ggVrASm0XwNF62dwOEE4a/41EZSo4s6j9UXpXWDoEThIKhlOMGJJcEDkzVBCrUyNTf7hM
s4IZ6jS/aWNxkEx2x0FPbesjUVI9tKdptZRtb48THhKOyeX+myR26ddP8SfM1AW0jifFd
0C/2kCfEM4YqrEol6U5LC4YnJmtKkFtbY9V1uKsDaTmPxuSxYgsbAuyt6xwvacAlHE2dN
XBxf4d6NdZqPMalwDMtEBYn8JX4s7G9vZc9iRdXRLWuzIysmX8AV05ufNaAmzUB30Pm0W
Ab9TNMnhxaUG2MOfiUG/vqkCnA15FndZZ4V1UZE4FG0qev/c8xI6WI4fWOEXVH5/wDpT+
MsQuL1mm3vPoZqIIIkUaaYmuXmTBsjPZo357ZJSXHMe4T5kM2sdWYVSFbF6qyD+bC4+s=
cardno:000512345678
|
La commande
ssh-add a eu pour effet de créer un fichier dans le répertoire
~/.gnupg/private-keys-v1.d :
|
4154456C666B1C933968D48F7A0B40363A2CF0A3.key
|
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 :
|
B348E102E64EBAA2B78A2A7D269412CA582CFA8E 0
|
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 :
|
$ vi ~/.ssh/authorized_keys
|
et nous y ajoutons notre clé publique :
|
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDATxH4COO+HSBdwraJ6lKvdH6JxrHy
RKJQ/YCRG4A6h3d0d2QFykJ5318VNXUKvKgxcDnTyovnF0/uoCdxoAGeZb+vm8f0afa7
k+ggVrASm0XwNF62dwOEE4a/41EZSo4s6j9UXpXWDoEThIKhlOMGJJcEDkzVBCrUyNTf
7hMs4IZ6jSaWNxkEx2x0FPbesjUVI9tKdptZRtb48THhKOyeX+myR26ddP8SfM1AW0ji
fFd0C/2kCfEM4YqrEol6U5LC4YnJmtKkFtbY9V1uKsDaTmPxuSxYgsbAuyt6xwvacAl
HE2dNXBxf4d6NdZqPMalwDMtEBYn8JX4s7G9vZc9iRdXRLWuzIysmX8AV05ufNaAmzUB
30Pm0WAb9TNMnhxaUG2MOfiUG/vqkCnA15FndZZ4V1UZE4FG0qev/c8xI6WI4fWOEXVH
5/wDpT+MsQuL1mm3vPoZqIIIkUaaYmuXmTBsjPZo357ZJSXHMe4T5kM2sdWYVSFbF6qy
D+bC4+s= cardno:000512345678
|
Voilà ! Nous sauvegardons ce fichier et allons tester notre connexion à partir de notre PC.
|
$ ssh root@monserveur
Entrer votre Code PIN
monserveur:/#
|
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 :
|
dpkg –i libgpgme11_1.2.0-1_local_i386.deb gpa_0.9.0-1_local_i386.deb
|
puis à lancer gpa (, , , 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 :
 |
|
Fig 1 : Fenêtre de démarrage si aucune clé n’est disponible
|
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.
 |
|
Fig 2 : Fenêtre générale de GPA (partie smartcard)
|
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).
 |
|
Fig 3 : Fenêtre présentant les détails de notre clé
|
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.
 |
|
Fig 4 : bandeau de 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 :
 |
|
Fig 5 : Fenêtre présentant 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 :
 |
|
Fig 6 : Fenêtre présentant le détail de notre clé
|
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.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.
 |
|
Fig 7 : Fenêtre principale avec informations sur la clé
|
|
|
|
3.3.2 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.
 |
|
Fig 8 : File Manager avec fichier chiffré
|
|
|
|
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 !
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 , sélectionnez votre compte, puis cliquez sur . Allez ensuite dans l’onglet de sécurité et indiquez dans le champ 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 , puis aller dans sécurité et sélectionner et/ou :
Lorsque vous signerez votre courriel, le popup code PIN apparaîtra, il ne reste plus qu’à le compléter...
 |
|
Fig 9 : options GPG
|
Pour la prise en charge de Claws-Mail, il faut créer un fichier
gpg-agent.conf et y ajouter les lignes suivantes :
|
$ vi ~/.gnupg/gpg-agent.conf
|
|
pinentry-program /usr/bin/pinentry-gtk-2
#no-grab
default-cache-ttl 1800
|
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.
|
$ aptitude install claws-mail-pgpinline claws-mail-pgpmime
|
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 :
 |
|
Fig 10 : Bandeau principal de Claws-Mail
|
Il faut aller dans puis cliquer sur , 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 , puis sélectionnez le compte que vous voulez modifier et cliquez ensuite sur le bouton .
Pour finir, allez dans la partie , 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 , ensuite, il faudra aller dans et valider . Une fois ceci fait, il ne vous reste plus qu’à sélectionner 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 , on sélectionne . 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 (qui se trouve également dans la partie , mais de votre compte courriel). Nous allons donc dans , et sélectionnons le compte qui nous intéresse, puis nous cliquons sur modifier. Ensuite, dans , , nous sélectionnons ou 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 ou dans . Ensuite, à vous de sélectionner les options qui vous intéressent.
Voici la fenêtre de création de courriel avec les options GnuPG :
 |
|
Fig 11 : Options GPG
|
On confirme en cliquant sur le bouton , puis .
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 :
|
$ aptitude install enigmail
|
Lorsque l’on ouvre Icedove et que l’on va dans , la fenêtre qui s’ouvre est très basique. Nous vous conseillons de valider dans cette fenêtre l’option , ce qui permet de mieux pouvoir la paramétrer. En particulier, on voit apparaître l’onglet 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 . Cependant, de base, le paramétrage proposé convient à la majorité des cas. Il y a également l’onglet 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 et on valide l’option et/ou 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 .
Pour déchiffrer un courriel chiffré que vous aurez reçu, il suffira de sélectionner votre courriel, puis de cliquer sur le bouton qui se trouve sur votre bandeau .
Bandeau de composition de votre courriel :
 |
|
Fig 12 : Options GPG
|
|
|
|
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 :
, , , (tapez fireGPG), , .
Cependant, une fois installé, nous devons le configurer. Dans notre cas, pour utiliser GnuPG2, il faudra modifier le binaire utilisé : , , , , remplacez
/usr/bin/gpg par
/usr/bin/gpg2. Vous pouvez également activer gpg-agent.
Voilà, si vous relancez Firefox et retournez dans (, , ), 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 (, , ).
 |
|
Fig 13 Interface de FireGPG
|
Nous pouvons ainsi voir les différentes fonctionnalités disponibles.
Une fonctionnalité intéressante dans le menu est l’intégration du module
pgpAuth qui permet de s’authentifier sur certains sites web.
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.
|
Auteur : Michel HAVEZ
|
| Utilisateur GNU/Linux depuis 1996. Debian depuis 2006 |
