Ma première (vraie) clé PGP

Je me suis sérieusement mis à OpenPGP. C'était dans ma TODO depuis trop longtemps. Ce billet regroupe juste mes réflexions, ma manière de faire et les différentes lignes de commandes extraites du man qui pourront m'être utiles un jour. Rien d'innovant en soi.

Ce billet devait être un shaarli à l'origine mais vu sa longueur, il a atterri ici.

Attention : ce billet n'est ni de la vulgarisation ni une source d'information 100 % fiable. Il s'agit juste d'un retour d'expérience et de quelques notes d'un n00b qui s'est penché sur le sujet.

Voici la documentation que j'ai utilisée :

Table des matières

Introduction

D'abord, il faut faire la différence entre OpenPGP (la norme, RFC 4880) et les différentes implémentations disponibles (PGP, GnuPG, GPG4Win, ...).

ÉDIT du 30/05/2016 à 16h00 : Dans ce billet de blog, je vais traiter exclusivement de GnuPG (+ Enigmail comme frontend) c'est-à-dire l'implémentation disponible sous GNU/Linux. Pour les utilisateurs-trices de Windows, je vous renvoie vers le tuto de Zythom (partie 1, partie 2 et partie 3) d'une part et vers les explications de Numérama d'autre part. Je vous rappelle néanmoins qu'il ne peut pas y avoir de sécurité sur un système fermé, c'est-à-dire un système dont personne (sauf Microsoft) n'a le code source et ne sait donc comment il fonctionne. Le logiciel libre apporte des garanties supplémentaires nécessaires (mais pas suffisantes, mais c'est toujours mieux). Fin de l'édit.

Ensuite, il faut assimiler qu'on ne désigne pas une clé par son ID (identifiant) qu'il soit court ou long mais par son empreinte (fingerprint), pour des raisons de sécurité : « Short OpenPGP Key IDs, for example 0×2861A790, are 32 bits long. They have been shown to be easily spoofed by another key with the same Key ID. Long OpenPGP Key IDs (for example 0xA1E6148633874A3D) are 64 bits long. They are trivially collidable, which is also a potentially serious problem. If you want to deal with a cryptographically-strong identifier for a key, you should use the full fingerprint. You should never rely on the short, or even long, Key ID. ». Source : OpenPGP Best Practices.

Générer une paire de clés

ÉDIT du 30/05/2016 à 19h00 :

Configurer GnuPG

Avant de générer une paire de clés, la première étape est d'avoir un bon fichier gpg.conf avec les paramètres recommandés (utilisation des ID longs, affichage des fingerprint, utilisation d'un cluster de serveurs de clés interrogés avec le protocole sécurisé hkps, priorité aux algos forts, ...) car les paramètres par défaut de GPG sont… insuffisants.

Même si vous utilisez Enigmail pour générer votre paire de clés, cette étape de configuration est nécessaire !

GPG version 1.X ou GPG version 2.X ?

Pour l'usage quotidien, peu importe. gpg ou gpg2 fonctionnent de la même manière, avec les mêmes commandes, respectent la même norme. Parmi les différences, citons : la version 1 est monolithique (un seul binaire qui fait tout) alors que la version 2 délègue du taff : dirmngr pour l'accès aux serveurs de clés, libgcrypt pour les opérateurs cryptographiques,… D'après le manuel, la version 2 est plus adaptée pour les environnements graphiques alors que la version 1 est plus adaptée pour les utilisations en ligne de commande et les utilisations automatiques. Les versions 2.X récentes apportent le support de S/MIME et la gestion des courbes élliptiques.

Sous Debian GNU/Linux, gpg et gpg2 sont deux binaires différents qui co-habitent. Sous ArchLinux, gpp pointe sur gpg2.

En revanche, ce qui va différer, c'est le bout de configuration concernant les serveurs de clés : si l'on utilise gpg2, il faut créer un fichier ~/.gnupg/dirmngr.conf (si le dossier caché .gnupg n'existe pas, on le crée) avec le contenu suivant en plus du fichier gpg.conf qu'on va créer plus loin :

hkp-cacert /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem

Il faudra également vérifier que le logiciel dirmngr est bien installé, avec apt-get, par exemple :

apt-get install dirmngr
Configuration commune à GPG version 1.X et GPG version 2.X

Ensuite, il faut créer un fichier texte ~/.gnupg/gpg.conf (si le dossier caché .gnupg n'existe pas, on le crée) avec le contenu suivant :

# Options for GnuPG
 
## Générales (https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf)
# Uncomment the following option to get rid of the copyright notice
no-greeting
 
# Disable inclusion of the version string in ASCII armored output
no-emit-version
 
# Disable comment string in clear text signatures and ASCII armored messages
no-comments
 
 
## Crypto preferences (http://www.bortzmeyer.org/nouvelle-cle-pgp.html et https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf)
# list of personal digest preferences. When multiple digests are supported by
# all recipients, choose the strongest one
personal-cipher-preferences AES256 AES192 AES
 
# list of personal digest preferences. When multiple ciphers are supported by
# all recipients, choose the strongest one
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
 
# For the keys we create / message digest algorithm used when signing a key
cert-digest-algo SHA512
 
# For the signatures and other things we generate
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed
 
 
## Serveur de clés (https://help.riseup.net/en/security/message-security/openpgp/best-practices#selecting-a-keyserver-and-configuring-your-machine-to-refresh-your-keyring)
# sks-keyservers.net mieux car checks de bon fonctionnement réguliers et hkps > *
keyserver hkps://hkps.pool.sks-keyservers.net
 
# https://sks-keyservers.net/sks-keyservers.netCA.pem
keyserver-options ca-cert-file=/etc/ssl/certs/hkps.pool.sks-keyservers.net.pem
 
# When creating a key, individuals may designate a specific keyserver to use to pull their keys from. 
# It is recommended that you use the following option to ~/.gnupg/gpg.conf, which will ignore such designations :
keyserver-options no-honor-keyserver-url
 
 
## Affichage des clés (https://help.riseup.net/en/security/message-security/openpgp/best-practices#selecting-a-keyserver-and-configuring-your-machine-to-refresh-your-keyring)
# Format long. Short OpenPGP Key IDs, for example 0×2861A790, are 32 bits long. They have been shown to be easily spoofed by another key with the same Key ID.
keyid-format 0xlong
 
# Long OpenPGP Key IDs (for example 0xA1E6148633874A3D) are 64 bits long. They are trivially collidable. If you want to deal with a cryptographically-strong identifier for a key, you should use the full fingerprint. You should never rely on the short, or even long, Key ID.
with-fingerprint

Attention : pour pouvoir utiliser le protocole sécurisé d'échange de clés hkps, et si vous utilisez GPG 1.X, il faut installer le package « gnupg-curl ».

Attention : dans tous les cas (gpg 1.X ou 2.X), il faut récupérer le certificat x509 de sks-keyservers.net dispo en https://sks-keyservers.net/sks-keyservers.netCA.pem pour le stocker en /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem .

Fin de l'édit du 30/05/2016 à 19h00.

Réellement générer votre paire de clés

À partir d'ici, vous pouvez utilisez Enigmail à la place des commandes barbares que je propose ci-desous à condition d'utiliser une version d'Enigmail >= 1.8 ! Les versions inférieures générent des clés insufissantes pour 2016..

  • Générer une paire de clés :
    gpg --gen-key

    ÉDIT du 02/11/2014 à 16h00 : Choisir : RSA et RSA, une taille de 4096 octets. ÉDIT du 30/05/2016 à 14h30 : 4096 est une bonne taille encore aujourd'hui puisque l'ANSSI, via son référentiel général de sécurité (RGS) (document B1) indique que 2048 bits sont le minimum aujourd'hui pour des clés RSA et que 3072 bits sont recommandés. La NSA indique 3072 bits minimum. Donc 4096 bits, c'est tout bon. Fin de l'édit du 30/05/2016.

    Ensuite, il faut préciser une date d'expiration d'un maximum de 2 ans. Cette date d'expiration, qui peut être vu comme étant facultative (si un certificat de révocation a été généré et stocké en lieu sûr, voir ci-dessous), ajoute pourtant une sécurité supplémentaire : si vous avez toujours votre clé privée, vous pourrez reporter la date d'expiration même après l'expiration (sans vous refaire une nouvelle paire de clés). Si vous n'avez plus votre clé privée (vol (copie + suppression quoi), compromission) et que vous n'avez pas généré le certificat de révocation (ou que vous l'avez perdu), alors vos correspondances et vos correspondants sont potentiellement menacés et la date d'expiration permet de réduire la durée d'exposition au danger de vos correspondants. L'expiration est aussi un moyen de résoudre les nombreux dysfonctionnements "par design" de la révocation dont le fait qu'il faut que tous vos contacts mettent à jour leur trousseau de clés pour que la révocation devienne effective. Retenez donc que l'expiration n'a rien en commun avec la révocation : la première est une sécurité (qui peut être contournée si elle s'active), la deuxième est définitive (une clé révoquée ne revient pas à la vie, en gros). Fin de l'édit du 02/11/2014.

    ÉDIT du 30/05/2016 à 20h15 : Ne pas indiquer de commentaire, c'est juste stupide / sans intérêt dans la plupart des cas…

    Saisissez une phrase de passe secrète solide car c'est sur elle que reposera la sécurité de vos échanges futurs. Pour qu'elle soit solide et mémorisable, utilisez la méthode Diceware avec un minimum de 5 mots qui n'ont rien à voir entre eux. De manière humoristique (mais tout à fait sérieux dans le fond), voir : https://xkcd.com/936/. Fin de l'édit.

  • Si la clé doit couvrir/fonctionner pour plusieurs "identités", notamment plusieurs adresses mails :
    gpg --edit-key "<fingerprint>"

    puis commande « adduid » pour ajouter toutes les identités/mail puis GnuPG: Selecting A Primary UID pour sélectionner l'identité principale. ÉDIT du 30/05/2016 à 20h05 : Évidemment, toutes les identités/adresses mails que vous joigniez à la même clé GPG marque leur appartenance à une même clé privée donc à une même personne. Donc il ne faut pas utiliser la même clé GPG pour des adresses mails que vous ne voulez pas voir mélangées (perso / pro, par exemple ou perso / identité sur les sites porno). Fin de l'édit.

  • Générer le certificat de révocation en avance et le conserver précieusement à l'abri des regards indiscrets (utile en cas de gros pépin exposant vos contacts à une usurpation de votre identité) :
    gpg -o maclepgp.revoke --gen-revoke "<fingerprint>"

    ÉDIT du 02/11/2014 à 17h05 : Toute personne en possession de ce certificat pourra révoquer votre paire de clés sans aucun contrôle (pas de demande de passphrase, par exemple) donc faites très attention ! Une révocation est définitive et elle empêchera tout ordinateur la connaissant de chiffrer des mails à votre intention ! Voir la section « Révoquer une paire de clés avec un certificat de révocation » à la fin de ce billet pour plus d'informations. Fin de l'édit.

  • Exporter la clé publique (pour un test avec une clé de test, par exemple) :
    gpg -a -o maclepgp.pub --export "<fingerprint>"

    Pour info : « -a | --armor : Create ASCII armored output. The default is to create the binary OpenPGP format. »

  • Publier la clé publique sur un serveur de clés (pour la vraie clé de production, c'est LA méthode à utiliser) :
    gpg --send-key "<fingerprint>"
  • Vous pouvez générer des sous-clés mais ce n'est pas aussi trivial que le sous-entendent les tutoriels. Pour un début, je m'en passerai. Pour la sécurité, mieux vaut des outils cryptos compris que des fonctionnalités supplémentaires incomprises. Par défaut, GPG génère une sous-clé de chiffrement en plus de la clé de signature.
  • Pensez à sauvegarder un maximum de chose : tout le dossier .gnupgp ainsi qu'un export de la clé privée :
    gpg --export-secret-keys -a -o maclepgp.private "<fingerprint>"

    et à stocker tout ça à l'abri des regards indiscrets ! Pensez à sauvegarder à chaque signature d'une clé (la votre ou celle d'autrui).

Chiffrer/déchiffrer/signer/vérifier la signature (d')un fichier

  • Chiffrer un fichier :
    gpg -ae <fichier>

    Le champ « choisir le destinataire » est un champ de recherche (accepte la fingerprint, une partie de l'identité, ...).

  • Déchiffrer un fichier :
    gpg -ad <fichier>

    Ajouter « -o » pour avoir la sortie dans un fichier au lieu de stdout.

  • Chiffrer et signer un message en même temps :
    gpg -ase <fichier>
  • Déchiffrer en vérifiant la signature : pareil qu'un déchiffrement sans signature. GPG indiquera simplement en plus s'il a réussi à vérifier la signature ou non.
  • Signer uniquement un fichier (« --clearsign » peut aussi être utile s'il faut garder le texte clair et signer à côté) :
    gpg -as <fichier>
  • Vérifier la signature (il faut bien évidemment avoir d'abord importé la clé publique correspondant à la clé privée qui a générée la signature, ce qui est le cas ici ; On voit souvent ce mécanisme avec les sources des logiciels libres sérieux) :
    gpg --verify <fichier>.(sig|asc)

Des personnes utilisent OpenPGP pour chiffrer certains de leurs fichiers qu'ils ne vont pourtant transmettre à personne (exemple : fichier de mots de passe). Est-il mieux d'utiliser OpenSSL ou GPG pour réaliser cette opération ? Je n'ai aucune réponse définitive. Pour moi, les deux outils sont équivalents. Et sur cet aspect-là, la CLI GPG est plus conviviale que la CLI OpenSSL.

ÉDIT du 30/05/2016 à 17h15 :

Stocker vos mots de passe

Hé oui, GPG vous permet de constituer un gestionnaire de mots de passe à la KeePassX : stockez vos mots de passe dedans, sous forme chiffrée. Pour accéder à votre trousseau de mots de passe, il faut votre clé privée OpenPGP et sa phrase de passe.

Le gestionnaire de mots de passe utilisant GPG que j'apprécie et que je recommande se nomme pass. Voir sur mon shaarli pour un avis détaillé : Pass: The Standard Unix Password Manager - GuiGui's Show - Liens.

Fin de l'édit.

Trouver la clé publique d'un correspondant, la vérifier et l'ajouter à votre trousseau

Méthodes pour obtenir la clé publique d'un correspondant :

  • Chercher une clé sur un serveur de clés :
    gpg --search-keys "<ID ou une partie de l'identité>"

    L'import est proposé si la recherche réussit. Il faudra vérifier la fingerprint (vérifier le lien entre une clé et son titulaire supposé) de cette clé via, au pire, l'utilisation d'un un canal alternatif (téléphone, XMPP,...) ou en se reposant sur le graphe de relations (une connaissance commune en qui vous avez confiance tous les deux qui aurait signé vos clés au préalable), au mieux : une rencontre de visu (AFK). À ce titre, je rappelle qu'une identité, en droit français, ça ne se vérifie pas nécessairement par des documents d'état civil mais aussi par au moins 2 témoignages. 😉

  • À partir d'une fingerprint :
    gpg --recv-key "<fingerprint>"

    Là aussi, il faut forcément vérifier la fingerprint.

  • À partir d'un fichier :
    gpg --import <cleducorrespondant>.asc

    Il faut vérifier la fingerprint.

Commandes utiles :

  • Voir le trousseau :
    gpg --list-keys 
    gpg --list-sigs
  • Voir la fingerprint d'une clé :
    gpg --fingerprint <keyID>
  • Supprimer une clé de votre trousseau :
    gpg --delete-key "<fingerprint>"
  • Signer une clé et lui accorder un niveau de confiance :
    gpg --edit-key "<fingerprint>"

    puis commande « sign » puis choisir un degré de confiance, normalement 3 ou 4, puis « quit ».

  • Publier le graphe des relations (les clés que vous avez signées) :
    gpg --send-key "<fingerprint>"

    Ici « fingerprint » désigne l'empreinte de chaque clé que vous avez signé puisque votre signature apparaît sur leur clé (--list-sig). Ne pas indiquer de fingerprint pousse toutes les clés sur le serveur de clés (sauf celles signées localement, voir ci-dessous). Source : Distributing keys - The GNU Privacy Handbook. Corollaire : vous devez "--refresh-keys <votre_fingerprint>" pour avoir, dans votre trousseau local, les signatures que d'autres personnes ont apposé à votre clé.

  • Il est possible de signer localement une clé, c'est-à-dire, de la signer sans que la signature soit exportée sur un serveur de clés. Cela permet de masquer une partie de votre graphe de relations. Lors d'un échange de clés, il est important de demander à votre interlocuteur s'il souhaite que vous apparaissisez dans son graphe de relations et inversement. Ça permet aussi ne pas conduire autrui (si autrui utilise le modèle de la toile de confiance) si vous souhaitez importer une clé sans faire les vérifications qui s'imposent normalement. Tout ça en évitant les demandes de confirmation (voire d'erreur) de votre MUA. Pour se faire :
    gpg --edit-key "<fingerprint>"

    puis juste les commandes « lsign » et « quit ».

  • Grâce à la toile de confiance, il est possible pour deux interlocuteurs ayant une (ou plusieurs) relations en commun (qui ont signées leurs clés) de vérifier leurs identités respectives sans pour autant avoir communiqué sur un canal sécurisé. On notera qu'utiliser ce mécanisme nous rend vulnérables aux vérifications effectuées par les relations communes : comment ont-elles signé les clés ? Selon quels critères ? Peut-on vraiment avoir confiance en leur process ? Il est donc de l'appréciation de chacun de recourir ou non à la toile de confiance.
  • ÉDIT DU 10/06/2016 À 19H40 : Visualiser votre graphe de relations / votre toile de confiance en utilisant sig2dot . FIN DE L'ÉDIT.

Chiffrer/déchiffrer/signer/vérifier la signature (d')un mail

Comme j'utilise principalement Icedove, j'ai pris la bien connue extension enigmail. Installée via apt-get puis chargée automatiquement après un redémarrage d'Icedove. L'assistant est convivial, rien à détailler. ÉDIT du 30/05/2016 à 15h30 : Ce n'est pas une bonne idée : sous Debian Wheezy, on avait Enigmail 1.7.X alors que la version 1.8 apportait d'énormes changements (rsa 4096 par défaut, expiration = maintenant + 5 ans, proposition appuyée pour faire générer le certificat de révocation, etc.). Il vaut donc mieux installer l'extension comme toute extension, depuis addons.mozilla.org. Fin de l'édit.

ÉDIT du 30/05/2016 à 15h30 : Attention, le couple Thunderbird+Enigmail n'est pas forcément le plus sécurisé.

D'une part, Enigmail est une extension de Thunderbird, ce qui signifie que les fonctionnalités qu'elle apporte n'ont pas été prévues par les développeurs-euses de Thunderbird, ce qui signifie qu'Enigmail est un contournement crade du cheminement normal de l'envoi d'un mail avec Thunderbird : Enigmail intercepte l'envoi d'un mail, fait sa tambouille, ré-injecte le mail à envoyer. Même si ça fonctionne, ce comportement n'est pas sain.

D'autre part, le format d'un mail, le format MIME, est démoniaque. Un mail est toujours composé d'une partie entêtes et d'une partie corps mais le corps peut être subdivisé. C'est le cas quand il y a un message + une pièce jointe ou quand le mail est envoyé dans une version texte ET dans une version HTML pour plaire à tout le monde. C'est aussi le cas quand un mail est chiffré ou signé avec PGP et qu'on utilise PGP/MIME : la signature / le texte chiffré est dans un compartiment séparé logé dans le corps du mail. Là où ça se complique, c'est que l'enchaînement et l'imbrication de parties MIME peuvent aller assez loin. L'ennui, c'est qu'Enigmail informe très mal de quelles parties du mail sont chiffrées / signées. Exemple bateau : rédiger un mail au format plain/text, coller un blob PGP au milieu, Engimail avertira que TOUT le mail est signé alors que seul le blob PGP l'est. Ça peut amener à des tromperies des utilisateurs-trices du genre le corps du mail, celui qui s'affiche, que l'utilisateur lit, est nullement signé, seule un autre compartiment dans le mail l'est donc l'utilisateur-trice n'a aucune garantie sur l'authenticité et l'intégrité du corps du mail qu'il-elle lit ! Exemple concret ici : KMail indique clairement les parties qu'il n'a pas traité alors qu'Enigmail affiche le bandeau vert "toutVaBien".

Bref, notons que chaque logiciel mail dispose de son propre frontend à PGP et que tous ne se valent pas.
Fin de l'édit.

Enigmail fait le travail de déchiffrement et/ou vérification des signatures automatiquement à la réception d'un mail :

  • Si vous obtenez le message « Message déchiffré; Signature non vérifiée; cliquez sur l'icône « stylo » », ne cherchez pas l'icône stylo mais cliquez sur « détails » à droite de ce bandeau d'information. Vous n'avez pas la clé publique de votre correspondant dans votre trousseau.
  • Si vous obtenez le message « [...] Signature non certifiée [...] », alors vous n'avez pas signé la clé publique de votre correspondant.
  • « Message déchiffré; Signature correcte de [...] ». Tout est ok \o/ .
  • Je n'ai pas encore rencontré les autres messages (déchiffrement impossible, par exemple).

ÉDIT du 30/05/2016 à 19h45 : Attention : Enigmail permet également de générer facilement une paire de clés de manière conviviale mais il est impératif de configurer GPG au préalable car les paramètres par défaut sont insuffisants. Voir la première partie de ce billet. Fin de l'édit.

Pour envoyer un mail avec du contenu chiffré et/ou signé, on peut aussi utiliser les méthodes précédentes sur les fichiers puis

mail -s "" <adresse_mail_destinataire> < <fichier>.asc

Mais ce n'est pas vraiment sérieux. 😀

Quelques précautions à prendre lors de l'envoi d'un mail signé/chiffré

  • PGP/inline ou PGP/MIME ? Voir : Choisir PGP/MIME ou PGP/Inline chez Vigdis et Choisir PGP/MIME ou PGP/Inline chez le Hollandais Volant pour un exposé des différents arguments. Je retiens que pour la signature, on se pose aucune question : PGP/MIME. Pour un mail chiffré, il faut se décider à prendre en compte les MUA en carton (au détriment de la sécurité) ou pas. Pensez à configurer votre MUA. Pour Icedove/Enigmail, voir : Enigmail Configuration Manual - Per Account Settings. Sous Debian GNU/Linux Wheezy, je remarque que PGP/MIME est utilisé par défaut.
  • Dans tous les cas, le sujet du mail n'est pas chiffré (comme le reste des en-têtes), il faut donc éviter de mettre l'information confidentielle dedans. Évidemment, cela rend plus difficile l'estimation de la priorité (du point de vue du destinataire donc exit le header posé par l'expéditeur) d'un mail et la recherche. Compromis entre simplicité et sécurité, as usual.

    J'en profite pour rappeler que les métadonnées (adresse d'expédition, adresses destinataires (même CCi), heure, poids, fréquence des échanges) sont vues par tous les intermédiaires entre vous et votre correspondant. OpenPGP ne change pas ça !

    • PGP = contenu chiffré/signé de bout en bout ;
    • TLS = chiffrement point à point entre deux serveurs SMTP. Les métadonnées ne circulent donc plus en clair, seuls les MTA sur le chemin voient les métadonnées ;
    • Autohébergé + TLS + PGP = le top : métadonnées connues exclusivement des serveurs SMTP de l'expéditeur et du destinataire, métadonnées (+ contenu, of course) chiffrées entre les serveurs et contenu protégé de bout en bout par PGP. Notons qu'il suffit de tcpdump, au niveau 3, en amont d'un serveur mail personnel, autohébergé ou non, pour savoir qui écrit à qui, quand à quelle heure, à quelle fréquence : pas besoin de virer TLS ni de pirater les serveurs de mails. Bah oui, on sait que le serveur A avec l'IP A est à GuiGui... Forcément, tout mail qui en sort est émis par GuiGui, tout mail qui entre est à destination de GuiGui.
  • Les pièces jointes non incluses dans le corps du mail laissent leur nom apparaître même avec PGP donc, pareil que pour le sujet : ne pas y mettre la fameuse information confidentielle. Cf : Parce que vous vous foutez de vos libertés, ce sont les miennes qui disparaissent. Apparemment, ce comportement dépend du MUA : Mutt ne fait pas fuiter le nom des pièces jointes, par exemple.
  • Si vous perdez votre clé privée, c'est mort pour déchiffrer les mails, même les mails échangés dans le passé ! Faites attention avec votre trousseau et sauvegardez-le bien !

ÉDIT du 30/05/2016 à 16h30 :

Quid des webmails ?

Utiliser un webmail avec OpenPGP est une mauvaise idée.

Déjà, ça suppose que, même si le webmail ne rapatrie pas vos mails sur la machine que vous utilisez, il vous faut quand même votre clé privée sur la machine que vous utilisez afin de déchiffrer les mails entrants et de signer les mails sortants. Si vous êtes au taff et que votre disque dur n'est pas chiffré OU que votre boss (ou une équipe de votre société) est root sur votre machine, il est hors de question de stocker votre clé privée sur cette machine, de base. Donc usage webmail ou pas, ce n'est pas la question. En revanche, si vous avez un moyen de stockage externe de votre clé privée (pas sur une clé USB, hein, root peut toujours vous voler votre clé privée :- ) duquel la clé ne sort jamais comme une Yubikey 4 (les versions d'avant gèrent uniquement des clés de 2048 bits max, ce qui est pourri de nos jours) alors vous n'êtes pas concerné-e par ce premier point mais…

Ensuite, ça suppose que le webmail, qui n'est autre qu'une page web distante, puisse exécuter du code sur votre machine. Cela se fait avec JavaScript. Peut-on avoir confiance en un langage exécuté sur votre machine mais réellement piloté par le webmail distant, c'est-à-dire par une machine hors de chez vous, hors de votre contrôle ? Même quand il s'agit de manipuler votre clé privée (qui doit rester privée, je le rappelle) ? Même quand il s'agit de chiffrer/déchiffrer ?

Un cas concret met en évidence quelques problèmes qui peuvent survenir : Tails - FireGPG susceptible to devastating attacks :

Webmail interfaces commonly use text boxes for email composition, so FireGPG is a natural fit for this use case: the user writes his or her email plaintext in the text box, selects the plaintext and uses one of the "Encrypt" or "Sign and encrypt" actions available from the FireGPG menu to transform the selection to its encrypted counterpart.

The FireGPG design incorrectly assumes that this is safe, but it is not, since JavaScript running on the page can still control and observe much of what is happening on the page. For instance, a simple script can set up a timer that silently submits the contents of the text box back to the server every second, thereby leaking the plaintext as it is written, effectively bypassing any subsequent encryption. In fact, many non-malicious webmail services do just that at longer intervals, to save a draft of a message in case the user's browser crashes.

[...]

FireGPG also has three commands to sign (but not encrypt) messages: "Sign", "Wrapped sign" and "Clearsign". Simple JavaScript can replace the contents of the text box when the user selects it, so if the user does not re-read the text after selecting one of the 'sign' commands, the attacker will be able to obtain the user's signature on an arbitrary message.

Quant à Mailvelope, c'est totalement basé sur un framework JavaScript, OpenPGP.js… Pour ma part : problème de confiance envers JavaScript.

Enfin, même si vous chiffrez/signez votre prose en local avant de copier le blob GPG dans un webmail (ce que fait l'applet GPG de Tails), un webmail utilise forcément PGP/Inline et on a vu ci-dessus que ce n'était ni le plus sécurisé ni le top visuellement parlant. Ça concerne tous les webmails : Roundcube, Mailpile,…

Pour qu'un webmail puisse gérer PGP/MIME, il n'y a que deux méthodes possibles : soit votre clé privée est stockée sur le serveur de mails, soit il faut implémenter un parseur MIME en Javascript qui s'exécutera uniquement côté client. Dans le premier cas, ça pourrait convenir uniquement aux serveurs de mails qui ne sont pas mutualisés entre plusieurs utilisateurs. Et encore : il existe un risque de se faire voler sa clé privée OpenPGP via un logiciel pas à jour et/ou une faille dans un site web présent sur le même serveur, par exemple. Dans le deuxième cas, quitte à ré-implémenter un parseur MIME, autant avoir un client mail lourd. Surtout que recoder un parseur MIME n'est pas simple, il y aura des bugs, des failles, etc.

OpenPGP et confidentialité persistante (PFS - Perfect Forward Secrecy)

Contrairement à OTR ou à TLS ou SSH, OpenPGP ne peut pas apporter la confidentialité persistante : si votre clé privée est volée, le voleur peut, une fois qu'il a la passphrase : 1) déchiffrer tout contenu chiffré ultérieurement avec la clé publique, 2) signer du contenu, 3) déchiffrer tout contenu produit antérieurement au vol qui tomberait sous sa main. Ainsi, si vos mails et votre clé privée sont volés, c'est la fin : tous vos échanges passés sont connus par le voleur. Avec la PFS, le 3) est évité.

OpenPGP ne peut pas apporter cette propriété de confidentialité persistante car elle suppose un échange synchrone pour se transmettre une clé de chiffrement temporaire. Or, le mail n'est pas prévu pour être synchrone.

FIN DE L'ÉDIT du 30/05/2016 à 16h30

ÉDIT DU 05/07/2016 À 17h00

Changer la date d'expiration d'une clé

Votre clé arrive bientôt à expiration voire elle a expiré ? Voici comment repousser la date d'expiration.

En ligne de commande

gpg --edit-key "<fingerprint_de_votre_clé"

Pour changer la date d'expiration de votre clé principale :

expire

Je recommande de repousser la date d'un an, surtout si vous êtes un-e novice : à ce stade, on perd souvent sa clé privée et cert' de révocation donc ce n'est pas la peine d'avoir une date d'expiration de 2 ou 5 ans… Donc, on indique « 1y » à GPG. Puis on confirme notre choix et on saisit notre phrase de passe pour que la modification prenne effet.

Ensuite, il faut s'occuper de chacune de vos sous-clés. Pour les voir, il faut utiliser la commande « list ». Par défaut, GPG crée une sous-clé de chiffrement. Il faut donc la renouveller elle-aussi.

D'abord, on la sélectionne (clé qui porte l'index, le numéro 1):

key 1

Ensuite, on recommence le topo : expire , 1y, on confirme.

Il faut faire cela pour chaque sous-clé.

Une fois que cela est fait, on sauvegarde nos changements :

save

Avant-dernière étape, mettre à jour notre clé sur les serveurs de clés pour que nos contacts puissent prendre connaissance que notre clé ne va pas expirer cette fois-ci et qu'ils peuvent continuer à l'utiliser :

gpg --send-key "<fingerprint_de_votre_clé>

Dernière étape : comme toujours, il faut penser à sauvegarder l'intégralité de votre trousseau (tout le dossier .gnupg, en gros) + une copie de votre clé privée modifiée. Voir la fin de la partie « Générer une paire de clés » pour avoir la commande d'export qui fait ce job.

Avec Enigmail

Il faut aller dans l'item « Gestion de clés » du menu « Enigmail » puis cliquer droit sur votre clé (facile de la reconnaître, elle est en gras) et choisir « Changer la date d'expiration » dans le menu. Par défaut, Enigmail sélectionne votre clé principale + sa sous-clé de chiffrement et propose de reporter la date d'expiration d'une année, c'est un bon choix donc on se contente de valider.

FIN DE L'ÉDIT du 05/07/2016 À 17h00

ÉDIT du 02/11/2014 à 17h15 :

Révocation

Je parle ici d'une révocation voulue : nous changeons de clés car l'ancienne clé à fait son temps (exemple : taille de clé devenue trop faible avec le temps, avancées cryptanalyse, ...) ou n'a pas été générée avec les paramètres recommandés permettant d'assurer un minimum de sécurité. Évidemment, les fichiers et mails chiffrés avec votre ancienne clé doivent rester lisibles.

Évidemment, je vous recommande très fortement de sauvegarder votre trousseau (tout le dossier ~/.gnupg quoi) avant de commencer. Tant que vous n'avez pas propagé vos modifications sur un serveur de clés (commande « gpg --send-key »), vous pouvez toujours restaurer votre ancien dossier .gnupg pour revenir en arrière. Une fois les modifications poussées sur un serveur de clés, c'est trop tard, notamment pour la révocation donc vérifiez bien vos manipulations avant de procéder à cet envoi.

Cette section est inspirée de : Révoquer une clé GnuPG - Sima78.

Générer une nouvelle paire de clés

La première étape est de générer une nouvelle paire de clés. Je vous recommande de lire la section « Générer une paire de clés » en haut de ce billet à propos de la conf recommandée pour GnuPG et de comment on génère/sauvegarde une paire de clés et le certificat de révocation associé. Ci-dessous, je fais le strict minimum concernant la génération d'une nouvelle paire de clés.

On génère une nouvelle paire de clés :

gpg --gen-key

On signe notre nouvelle clé avec notre ancienne clé :

gpg --default-key <fingerprint_ancienne_clé> --sign-key <fingerprint_nouvelle_cle>

Cela permet d'indiquer à tout le monde que c'est bien votre nouvelle clé à vous (vous l'avez signée). Cela est purement indicatif : en effet, en cas de compromission totale (récupération de votre clé privée et de sa passphrase), la personne mal-intentionnée peut très bien générer une nouvelle paire de clés et la signer avec votre ancienne paire de clés histoire de tromper vos correspondants avant que vous vous rendiez compte de la compromission et que vous les préveniez. L'avantage de procéder ainsi pour l'attaquant est qu'il commence une nouvelle chaîne de confiance sous son contrôle.

On publie la partie publique sur un serveur de clés :

gpg --send-key <fingerprint_nouvelle_cle>

Tester la nouvelle paire de clés

Avant d'aller plus loin, il faut tester notre nouvelle paire de clés.

Pour que GnuPG utilise votre nouvelle paire de clés par défaut (sans qu'on ai besoin de lui indiquer « --default-key » à chaque commande), il faut modifier le fichier gpg.conf pour ajouter la ligne suivante :

default-key "fingerprint_nouvelle_clé"

Ce morceau de configuration ne sera plus utile une fois l'ancienne clé révoquée : GnuPG ignorera l'ancienne clé sauf pour déchiffrer / vérifier la signature d'anciens fichiers/mails.

Pour que Thunderbird/Enigmail utilisent votre nouvelle paire de clés : menu « Édition », « Paramètres des comptes », choisir le compte mail dans la liste à gauche, « Sécurité OpenPGP ». Cocher « Utiliser un identifiant de clé particulier », cliquer sur le bouton « Choisir une clef ... » et choisir la nouvelle clé.

À ce stade, vos anciens fichiers et mails chiffrés/signés sont encore parfaitement lisibles et vérifiables. Votre nouvelle clé vous permet de chiffrer/signer des fichiers et des mails. Chez vos correspondants, Enigmail affiche « Signature non vérifiée » : c'est normal, ils doivent importer et signer votre nouvelle partie publique.

Révoquer l'ancienne clé

gpg --edit-key "<fingerprint_ancienne_clé>"
[...]
gpg> revkey

Confirmez que vous voulez vraiment révoquer cette clé, choisissez la raison « 2 = La clé a été remplacée », vous pouvez indiquer une raison comme « taille de clé insuffisante » puis confirmez que vous êtes d'accord avec la touche « o » puis tapez la commande « save » puis « quit ».

Vous pouvez vérifier que votre clé a bien été révoquée avec les commandes habituelles comme « --list-keys ».

Si tout est OK, vous pouvez pousser votre clé révoquée sur les serveurs de clés. Attention, la révocation devient définitive à partir d'ici !

gpg --send-key <fingerprint_ancienne_clé>

Quand je vous ai dit que la révocation est devenue effective à ce stade, je vous ai un peu menti : elle sera effective quand tous vos contacts auront mis à jour leur trousseau. En attendant qu'ils le fassent, ils peuvent toujours utiliser votre ancienne clé publique pour vous envoyer des mails/fichiers chiffrés alors qu'elle a pourtant été révoquée. D'où l'importance de mettre à jour régulièrement son trousseau de clés : « gpg --refresh-keys » ou, mieux pour la confidentialité de votre graphe de relations, parcimonie.

Voilà, on a terminé. \o/

À ce stade, vous pouvez toujours déchiffrer/vérifier vos anciens mails/fichiers. L'ancienne clé n'est plus utilisable, ni dans GnuPG directement ni dans Enigmail pour chiffrer/signer de nouveaux fichiers/mails. Si vous tentez quand même de signer un mail avec votre ancienne clé privée, Enigmail vous hurle dessus : « L'adresse de courriel ou ID de clé '<lala>' ne correspond pas à une clé OpenPGP valide et non-expirée. ». \o/

Évidemment, tous vos correspondants doivent signer votre nouvelle clé publique. 🙂

Évidemment, ne vous amusez pas à supprimer l'ancienne clé de votre trousseau ! Si vous le faîtes, vos anciens mails et fichiers chiffrés sont perdus (illisibles) ! À titre d'information, les commandes dangereuses à ne pas faire (mais GnuPG crache plein d'avertissements pour vous convaincre de faire marche arrière) sont : « --delete-secret-keys <fingerprint> » puis « --delete-key <fingerprint> ».

Révoquer une paire de clés avec un certificat de révocation

Ci-dessus, nous avons vu comment révoquer une paire de clés avec la commande « revkey ». Voyons maintenant comment faire dans la pire hypothèse : vous n'avez plus votre clé privée, vous avez une machine vierge et vous avez votre certificat de révocation.

D'abord, il faut importer la clé publique à partir d'un fichier ou d'un serveur de clés :

gpg --import <ma_cle_pgp_pwned>.asc
OU
gpg --search-keys "<ID_ou_une_partie_de_l'identité>"

Ensuite, il faut importer le certificat de révocation :

gpg --import maclepgp.revoke

On vérifie que tout est OK avec les commandes habituelles comme « --list-keys ».

Si tout est OK, vous pouvez pousser votre clé révoquée sur les serveurs de clés. Attention, la révocation devient définitive à partir d'ici !

gpg --send-key <fingerprint_ancienne_cle>

Fin de l'édit.

Conclusion

OpenPGP et ses implémentations, ce n'est pas encore accessible à tous, comme tout ce qui tourne autour de la sécurité.

Je déconseille le tutoriel La cryptographie facile avec PGP sur le SdZ notamment à cause du paragraphe suivant (vers la fin) : « Normalement, toutes les clés devraient être signées par d'autres, elles-mêmes signées par d'autres, et ainsi de suite jusqu'à arriver à quelques personnes fiables comme Phil Z (l'inventeur de PGP), Linus Torvalds (le créateur de Linux) ou Richard Stallman (le fondateur de GNU) : ce réseau reliant les clés entre elles est appelé réseau de confiance (web of trust). ». Le modèle de la toile de confiance n'a rien en commun avec le modèle hiérarchique des AC x509 bien connues !

Tout ça pour dire d'être prudent lorsque l'on parle de crypto. 🙂

Aucun commentaire.

Ajoutez votre commentaire