! Disclaimer ! Je ne suis qu’un passionné qui a eu envie de vous parler de PGP et GPG. Vous n’avez aucune raison de me croire sur parole, et je vous recommande vivement de ne pas me croire sur parole.

Ce que je dis peut être erroné, soit par erreur de ma part, soit parce que la technologie évolue. Dans tous les cas, le principal est que vous compreniez ce que vous faites, pas que vous recopiez bêtement ce que j’écris ! ;-)

Hello à vous,

Aujourd’hui j’ai envie de vous parler d’une technologie qui m’intéresse tout particulièrement en ce moment : PGP : Pretty Good Privacy, ou plus particulièrement sa version améliorée : OpenPGP. Littéralement, de la vie privée pas trop mauvaise. Parfait ! Et vu que le libre c’est bien, je vais me concentrer exclusivement sur GnuPG (GPG).

Sommaire

Introduction rapide
Les principes derrière PGP
GPG Like A Boss
Outils
Premiers réglages
Prise en main
Outils utilisant PGP
Inconvénients

Introduction rapide

GnuPG n’est rien de plus qu’une implémentation d’OpenPGP, c’est à dire un outil qui stocke vos paires de clefs privées/publiques ainsi que les clefs publiques de vos connaissances. GnuPG est capable de chiffrer des messages textuels, des fichiers … et certaines applications s’intègrent bien à GPG, mais nous en reparlerons plus tard !

Dans les interfaces GPG, vous trouverez plusieurs informations pour chaque clef : son empreinte (fingerprint), un nom, un commentaire (facultatif) et une adresse email (facultative). Ces données sont propres à la clef et ne peuvent être modifiées.

Lorsque vous voudrez chiffrer un message pour un destinataire particulier, vous utiliserez soit son nom soit son adresse email : GPG identifiera la clef publique à utiliser, et tout fonctionnera à merveille (en théorie).

De votre côté, si le client GPG que vous utilisez est bien conçu (Astuce: il l’est), vous devrez définir une passphrase sur votre clef privée.

Important ! Pensez à stocker une copie externe de cette clef privée (et de son mot de passe…), sinon vous perdrez votre identité.

Si jamais vous perdez votre clef, il vous sera toujours possible de la révoquer (une clef de révocation est générée en même temps que votre clef). Vous devez donc stocker votre clef de révocation à un autre endroit que votre clef privée !

Les principes derrière PGP

PGP est un système décentralisé : aucun utilisateur n’a plus de pouvoir qu’un autre, ce qui n’est clairement pas le cas avec les autorités de certification.

Ce système (comme tous les systèmes) présente des avantages et des inconvénients : si je vous donne ma clef publique qui affirme que je suis Mark Zuckerberg, rien ne le prouve. Le Web Of Trust résout partiellement ce problème.

Le second inconvénient est qu’il n’existe pas un endroit centralisé qui regroupe toutes les clefs PGP du monde, posant des problèmes de transparence et de diffusion des clefs. À l’heure actuelle, les KeyServers sont synchronisés et servent de socle commun, bien que diffuser directement sa clef publique est courant.

Le Web of Trust, qu’est-ce que c’est ? Dans un monde sans autorité, et donc sans confiance universelle, il est nécessaire d’attribuer soi même la confiance à accorder à une identité. Ainsi, vous pouvez signer une identité pour indiquer à GPG que vous la confirmez. Mieux encore, vous pouvez ajouter votre signature à l’un des KeyServers : tous les gens qui vous font confiance sauront que vous faites confiance à cette identité, et seront donc rassurés. Bien entendu, rien ne vous oblige à publier cette signature; et il est même parfois préférable de ne pas la publier : les gens sont-ils obligés de savoir que vous avez communiqué avec _Monsieur X, crypto-terroriste_ ?

GPG Like A Boss

Afin d’utiliser GPG sereinement, il est nécessaire de comprendre comment le système de clefs fonctionne.

Une clef est définie par un couple de valeurs privé/publique, qui utilise un algorithme _“qui va bien”_ (RSA, DSA, ElGamal ou ECC) et qui possède une durée de vie.

Il existe deux types de clefs : - la clef principale, qui définit votre identité. Vous ne pouvez pas la changer sans “corrompre” votre identité, donc il faut la traiter avec extrême prudence. Elle doit au moins être capable de certifier. - les clefs secondaires (subkeys), qui peuvent utiliser un algorithme différent de la clef principale et à qui on peut donner des capacités différentes de la clef principale.

Il existe quatre capacités :

C, Certification : utilisée pour signer des clefs, qu’elles soient à vous (subkeys) ou non.
S, Signing : utilisée pour signer des données. <3
E, Encryption : utilisée pour chiffrer des données. <3
A, Authentication : peu fréquent, mais peut-être pratique si vous souhaitez utiliser votre clef GPG pour vous connecter en SSH. Particulièrement intéressant si vous avez une clef physique (Yubico <3) qui stocke votre clef GPG.

Afin de garantir un usage optimal de GPG, et donc votre sécurité, il est recommandé d’utiliser une durée de vie maximale de 1 an; d’utiliser l’algorithme RSA avec une longueur de clef suffisante (> 4096 bits) ou ECC.

Autre recommendation, plus difficile cette fois-ci : donner uniquement capacité de certification à votre clef principale, créer une sous-clef spécialement pour la signature et l’encryption et une autre sous-clef capable de certifier les clefs des autres utilisateurs.

Je trouve, personnellement, que c’est trop compliqué pour mon cas d’utilisation.

Peu de temps avant les deux ans de votre clef, pensez à la renouveler en changeant sa date d’expiration. Si vous désirez changer de clef, il faudra signer la nouvelle clef avec l’ancienne sans pour autant révoquer immédiatement l’ancienne : si la clef est révoquée, la signature est invalidée.

Outils

La partie la plus intéressante ! Celle où on passe à la pratique.

Le site officiel d’où vous pourrez télécharger GnuPG est gnupg.org, et je vous invite dès maintenant à le télécharger.

Étant un utilisateur d’OS X, je prends la version Mac GPG, qui offre une intégration graphique sympathique ainsi qu’une intégration dans l’application Mail.

En théorie, vous devriez vérifier que ce que vous venez de télécharger est bel et bien la version officielle de gnupg, mais ce sera impossible à moins d’avoir déjà une version de gpg sur votre ordinateur. Il faudra donc faire confiance pour ce premier téléchargement, ou demander à une personne de confiance de confirmer le binaire. Nous ferons confiance à https pour cette fois.

Premiers réglages

Les paramètres par défaut de GPG ne sont pas mauvais, mais ils ne sont pas parfaits non plus. Il est préférable de les changer avant de commencer à l’utiliser. Dans ~/.gnupg/gpg.conf, on ajoute à la fin du fichier :

# Impose des algorithmes plus fiables
personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 AES192 AES CAMELLIA256 CAMELLIA192 CAMELLIA128 TWOFISH ZLIB BZIP2 ZIP Uncompressed
cipher-algo AES256
digest-algo SHA512
s2k-digest-algo SHA512

# Permet d'afficher des valeurs de fingerprint de 16 caractères
keyid-format 0xlong

# N'inclut pas la version de votre GPG en commentaire de vos fichiers
no-emit-version
# Lors de l'export d'une clef, exclut les signatures par défaut
export-options export-minimal

On peut en profiter pour passer par HPKS (le HTTPS pour les serveurs de clefs) ou Tor pour les consultations de key server, voire passer par des .onions <3 Il suffit d’ajouter, toujours à la fin de ~/.gnupg/gpg.conf, la valeur keyserver hkps://hkps.pool.sks-keyservers.net ou keyserver hkp://jirk5u4osbsr34t5.onion

Si vous utilisez GPG 2.0 (et non GPG 2.1), vous devrez épingler le certificat manuellement : voir la procédure officielle.

Pour imposer à GPG l’utilisation de Tor, on ajoute use-tor à la fin de ~/.gnupg/dirmngr.conf (ou de ~/.gnupg/gpg.conf si vous utilisez GPG 2.0).

Autre remarque, préférer l’usage de gpg2 (2.x) au lieu de gpg (1.x).

Prise en main

Les interfaces étant assez conviviales, je vais me concentrer sur l’outil en ligne de commande.

Obtenir une identité

$ gpg2 --gen-key
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 1y
Key expires at Sun May  6 23:00:07 2018 CEST
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: UnGeek.fr
Email address: punkeel@ungeek.fr
Comment: 
You selected this USER-ID:
    "UnGeek.fr "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

gpg: removing stale lockfile (created by 8092)
gpg: key 0xE0306ECBA3A0980A marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   5  signed:   4  trust: 0-, 0q, 0n, 0m, 0f, 5u
gpg: depth: 1  valid:   4  signed:   0  trust: 3-, 0q, 0n, 0m, 1f, 0u
gpg: next trustdb check due at 2017-01-01
pub   4096R/0xE0306ECBA3A0980A 2016-05-06 [expires: 2017-05-06]
      Key fingerprint = 71E9 CA67 2C81 042D 36E7  2485 E030 6ECB A3A0 980A
uid                 [ultimate] UnGeek.fr 
sub   4096R/0x828B1A85FB9F94DE 2016-05-06 [expires: 2017-05-06]

Notre clef est générée, avec l’algorithme RSA, une durée de vie de deux ans.

Bonus: © @aeris22

On peut vérifier que la configuration de la clef est correcte avec l’outil pgpdump (non, GPG n’est pas capable de le faire…)

$ git clone https://github.com/kazu-yamamoto/pgpdump.git -b v0.30
$ cd pgpdump
$ ./configure && make
$ gpg2 --export 08DF861E | ./pgpdump
...
	Hashed Sub: preferred symmetric algorithms(sub 11)(7 bytes)
		Sym alg - AES with 256-bit key(sym 9)
		Sym alg - AES with 192-bit key(sym 8)
		Sym alg - AES with 128-bit key(sym 7)
		Sym alg - Camellia with 256-bit key(sym 13)
		Sym alg - Camellia with 192-bit key(sym 12)
		Sym alg - Camellia with 128-bit key(sym 11)
		Sym alg - Twofish with 256-bit key(sym 10)
	Hashed Sub: preferred hash algorithms(sub 21)(4 bytes)
		Hash alg - SHA512(hash 10)
		Hash alg - SHA384(hash 9)
		Hash alg - SHA256(hash 8)
		Hash alg - RIPEMD160(hash 3)
	Hashed Sub: preferred compression algorithms(sub 22)(4 bytes)
		Comp alg - ZLIB <RFC1950>(comp 2)
		Comp alg - BZip2(comp 3)
		Comp alg - ZIP <RFC1951>(comp 1)
		Comp alg - Uncompressed(comp 0)
...

On retrouve bien la configuration que nous avons donné plus tôt à GPG. Super !

Rechercher une clef

Il est possible de lister toutes les clefs que GPG connait, et si on lui donne un argument il filtrera les clefs pour n’afficher que celles qui correspondent, même partiellement, à notre terme de recherche.

$ gpg2 –list-keys
pub   rsa4096/0xE0306ECBA3A0980A 2016-05-06 [SC] [expires: 2017-05-06]
uid                   [ultimate] UnGeek.fr punkeel@ungeek.fr
sub   rsa4096/0x828B1A85FB9F94DE 2016-05-06 [E] [expires: 2017-05-06]
$ gpg2 –list-keys punkeel
pub   rsa4096/0xE0306ECBA3A0980A 2016-05-06 [SC] [expires: 2017-05-06]
uid                   [ultimate] UnGeek.fr punkeel@ungeek.fr
sub   rsa4096/0x828B1A85FB9F94DE 2016-05-06 [E] [expires: 2017-05-06]

Obtenir notre clef publique

$ gpg2 --armor --export punkeel@ungeek.fr
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFctBfEBEADe/dTxFVOFKG63V/36T/O61yS6yjC7k39VvNr3ETi3h8rDYTNS
...
=AYCW
-----END PGP PUBLIC KEY BLOCK-----

L’option --armor indique à GPG de nous donner la clef protégé dans une armure, c’est à dire une version lisible par un humain. L’armure n’est rien de plus que la partie —–XXX PGP PUBLIC KEY BLOCK—–.

Si vous me donnez cette clef publique, je serais en possession de votre identité.

Ajouter une clef publique

Cool, des amis en plus ! Je vous invite à télécharger ma clef publique ici : PunKeel.asc, à copier le contenu de ce fichier et à exécuter ceci :

$ gpg2 –import
Coller ici ma clef publique, avec l’armure
Ctrl+D
gpg: key FF57EC5B089BB801: “PunKeel (My main email) punkeel@me.com” 1 new user ID
gpg: key FF57EC5B089BB801: “PunKeel (My main email) punkeel@me.com” 6 new signatures
gpg: key FF57EC5B089BB801: “PunKeel (My main email) punkeel@me.com” 2 new subkeys
gpg: Total number processed: 1
gpg:           new user IDs: 1
gpg:            new subkeys: 2
gpg:         new signatures: 6

Si vous ne voyez pas la mention key FF57EC5B089BB801, c’est que Keybase n’est pas un service fiable. Si vous obtenez un message d’erreur, c’est dommage. :(

À partir de maintenant, gpg2 --list-keys vous affichera au moins deux clefs : la mienne et la votre.

Vous pouvez désormais m’envoyer des emails chiffrés et signés ! La classe !

Pour le plaisir, je vais signer deux documents.

$ cat 1.txt Je suis gentil $ gpg2 –clearsign –sign 1.txt

You need a passphrase to unlock the secret key for user: “PunKeel (My main email) punkeel@me.com“ 4096-bit RSA key, ID 1BC20F3F92E1D390, created 2015-06-19 (main key ID FF57EC5B089BB801) $ cat 2.txt Je suis Bill Gates $ gpg2 –clearsign –sign 2.txt

L’option --clearsign précise que je veux obtenir un fichier final lisible par un humain, au format ASCII donc. GPG s’occupe de me créer un fichier par signature générée : 1.txt.asc et 2.txt.asc. Vous pourrez les trouver ici : Gist (je vous conseille de prendre la version Raw).

Je vous invite à les télécharger, à les enregistrer avec leurs noms respectifs et à vérifier leurs signatures.

$ gpg2 --verify 1.txt.asc
gpg: Signature made Fri May  6 23:23:42 2016 CEST using RSA key ID 1BC20F3F92E1D390
gpg: Good signature from "PunKeel (My main email) " [ultimate]
gpg:                 aka "PunKeel " [ultimate]
gpg:                 aka "PunKeel " [ultimate]
gpg:                 aka "[jpeg image of size 8915]" [ultimate]
gpg:                 aka "[jpeg image of size 13373]" [unknown]

Youpi, le fichier 1 a bien été signé par moi !

Alors, ai-je signé le fichier 2 ? :O

Communiquer avec un KeyServer

Un Serveur de Clé est un point central dans PGP qui se charge de distribuer les clefs et les signatures des utilisateurs.

Pour rechercher une clef :

$ gpg2 --search-key punkeel
gpg: searching for "punkeel" from hkp server pool.sks-keyservers.net
(1)	PunKeel <punkeel@me.com>
	PunKeel <punkeel.0@gmail.com>
	PunKeel (My main email) <punkeel@me.com>
	  2048 bit RSA key FF57EC5B089BB801, created: 2014-03-07, expires: 2017-01-01
(2)	PunKeel (Nice day, huh ?) <punkeel.0@gmail.com>
	  2048 bit RSA key BD06F2BE7B46C1ED, created: 2012-06-22, expires: 2012-12-22 (expired)
Keys 1-2 of 2 for "punkeel".  Enter number(s), N)ext, or Q)uit > Q

On trouve mes deux clefs, l’une est déjà expirée et l’autre déjà importée.

Importons la seconde clef, même si elle est déjà expirée :

$ gpg2 --recv-key 0xBD06F2BE7B46C1ED
gpg: requesting key BD06F2BE7B46C1ED from hkp server pool.sks-keyservers.net
gpg: key BD06F2BE7B46C1ED: public key "PunKeel (Nice day, huh ?) <punkeel.0@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

C’est tout.

Pour envoyer une clef sur un KeyServer, il faut préciser quelle clef envoyer : gpg2 --send-keys BD06F2BE7B46C1ED enverra la clef, ce qui n’a pas de sens ici vu qu’on vient de l’importer de ce même serveur.

Outils utilisant PGP

Plusieurs outils supportent ou utilisent GPG. Cette liste n’est pas exhaustive, mais je pense qu’elle contient assez d’arguments pour vous convaincre que GPG c’est le bien.

OpenSSH

L’agent SSH et l’agent GPG sont capables de coopérer et de partager une clef (identité) commune. Je ne l’ai jamais fait, et je n’ai pas envie de le recommander … donc je ne vais pas vous apprendre à l’utiliser.

Git <3 <3 <3

Lorsque vous travaillez en équipe avec un serveur Git partagé, n’importe qui peut envoyer des commits en votre nom. On pourrait penser que cela ne pose aucun problème, mais … si le code qui est envoyé est utilisé de manière abusive (virus), on vous accusera à tort. Avec une signature, vous pourrez prouver que ce n’était potentiellement pas vous. Mieux encore, en vous synchronisant bien avec votre équipe, vous pouvez imposer ces commits : tout le monde prend sa part de responsabilités dans le code qu’il créé. Encore mieux mieux, GitHub et GitLab supportent presque la vérification des commits ! Pour automatiser la signature de vos commits, il suffit de configurer cette option :

$ git config --global commit.gpgsign true

Bonus: Si vous êtes sur OS X et que vous utilisez GitHub Desktop, il vous est impossible de commit avec une signature. Pour corriger cela, lancez cette commande : $ git config --global gpg.program /usr/local/bin/gpg2

Mails

Et oui, vos emails peuvent être signés et/ou chiffrés avec GPG. La configuration est tout de même assez délicate, et toutes les options ne sont pas supportées. À vrai dire, seul le contenu de votre message est chiffré (avec les fichiers joints) : les entêtes, c’est à dire les destinataires, le sujet, la date et votre identité (email, IP), ne sont pas inclus dedans. De plus, il existe deux formats : PGP/MIME et PGP/Inline. Il est préférable d’utiliser le premier : en mode Inline, seul le contenu textuel est chiffré (ce qui exclut le format HTML, les pièces jointes …)

Facebook

Et oui. J’ai osé. Depuis peu (Août 2015), Facebook propose deux options à ses utilisateurs : signer ses emails avec sa clef publique, ou chiffrer les emails qu’il vous envoie avec votre clef privée (ainsi gmail ne pourra pas fouiner). De plus, il est désormais possible d’afficher sa clef publique sur son profil Facebook. Un beau geste !

apt et la distribution de softwares

On l’oublie souvent, mais les signatures numériques qui assurent la fiabilité de vos softwares est GPG. Lorsque vous ajoutez un dépôt à Debian, en plus de copier des commandes bizarres, vous autorisez la clef GPG de son éditeur.

Vanilla

Et oui. Vous pouvez aussi utiliser PGP tel quel, sans sur-couche. Par exemple, en vous fournissant la signature d’un document, nous avons juste utilisé gpg et un hébergeur de données. C’est suffisant. Si j’étais en possession de votre clef privée, j’aurais pu chiffrer mon message … mais ce n’est pas le cas.

Inconvénients

Si PGP était si bien, tout le monde l’utiliserait.

La sécurité, c’est compliqué !!

Imaginez, vous formatez par erreur votre ordinateur, et vous ne pouvez plus prouver votre identité, ou lire vos anciens emails. Inadmissible !

Votre sécurité dépend de vous

En effet, si vous égarez ou publiez votre clé privée, vous mettez fin à votre identité et ne serez plus en mesure de déchiffrer vos anciens documents.

La difficulté de mise en place

Les premiers pas dans le monde obscur de GPG sont impossible à réaliser : sans Web Of Trust, la confiance n’est en théorie accordée à personne. Le processus est donc plus long que d’envoyer directement le message.

L’absence d’autorité

Ce qui rejoint le point précédent, en somme : une autorité, ce n’est rien de plus qu’une personne en qui on a confiance. Elle n’est utile que lorsqu’on vient d’arriver, ou lorsqu’une personne nous est totalement inconnue.

Le support réduit

Il n’existe pas, à ce jour, de client Mail disponible sur mobile qui soit assez fiable pour être utilisé. Dans tous les cas, transporter sa clé GPG dans son mobile, ce n’est pas très fiable, par nature. Le support de GPG dans un navigateur Web est aussi une lacune : pour communiquer avec par mail via un webmail (Gmail.com, Zimbra…) il faut soit utiliser un add-on (Mailvelope, par exemple), soit faire des aller-retour dans la ligne de commande pour effectuer manuellement les opérations. Finalement, ceux qui profitent d’un peu de sécurité sont les mêmes que ceux qui bénéficient d’une sécurité quasi-totale … et les “autres” sont littéralement à poil.

S/MIME

Ce n’est pas un inconvénient en soi, mais le simple fait qu’il existe deux technologies incompatibles ne rend pas la tâche aisée. Je trouve que PGP est nettement supérieur à S/MIME, pour toutes les technologies annexes supportées et l’absence d’autorités que je ne connais pas. Cependant, je trouve tout à fait légitime l’utilisation de S/MIME dans un cadre d’entreprise : la société donne des certificats individuels et certifie que son possesseur est bien celui qu’il prétend.

C’est tout. Bientôt, je l’espère, un article qui présentera Keybase.io et en vantera les mérites ! Amusez-vous bien ! :D

Un grand merci à @aeris22 qui a pris le temps de me relire et de corriger quelques-unes de mes erreurs.