====== Utilisation de GNU Privacy Guard (version 2) ====== Ce logiciel est installé par défaut sous Linux – au moins sur Debian et Ubuntu – est désormais disponible en version 2 sur les distributions les plus récentes. Mon [[cryptographie:gnupg|utilisation de la version précédente]] n’est plus pertinente, mais elle sera la base de cet article. Les principales évolutions sont décrites [[https://www.gnupg.org/faq/whats-new-in-2.1.html|ici]]. ===== Générer de l'entropie ===== ==== RNG-Tools ==== Avant de générer des clefs, il est nécessaire de créer de l'entropie sur le système. La solution est d'installer le paquet ''rng-tools'' (sous Debian). sudo apt update && sudo apt install rng-tools Pour configuer ''rng-tools'' il faut éditer le fichier ''/etc/default/rng-tools'', mais c'est normalement inutile celui-ci pouvant reconnaître seul les sources d'entropie. Il faudra surtout éviter de le configurer avec ''/dev/urandom'' comme source (voir [[https://lwn.net/Articles/525459/|cet article]]). ===== Configuration de GNUPG ===== ==== Serveur de clés ==== Nous utiliserons le [[https://sks-keyservers.net/overview-of-pools.php|groupe de serveur de clés sks]]. Le bon fonctionnement des machines de ce groupe est vérifié par des contrôles de routine réguliers. Si un serveur ne fonctionne pas bien, il sera automatiquement retiré du groupe. Nous devrons aussi nous assurer que nous communiquerons avec le groupe de serveurs de clés au travers d’un canal chiffré, en utilisant un protocole qui s’appelle ''hkps''. Pour utiliser le groupe de serveurs de clés, il faudra télécharger [[https://sks-keyservers.net/sks-keyservers.netCA.pem|l’autorité de certification de sks-keyservers.net]] cd; curl -O https://sks-keyservers.net/sks-keyservers.netCA.pem sudo cp sks-keyservers.netCA.pem /usr/share/ca-certificates/ echo sks-keyservers.netCA.pem | sudo tee -a /etc/ca-certificates.conf sudo update-ca-certificates rm ~/sks-keyservers.netCA.pem **sks-keyservers.net** : "This service is deprecated. This means it is no longer maintained, and new HKPS certificates will not be issued. Service reliability should not be expected. 2021-06-21: Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all." Il faudra ensuite utiliser les paramètres suivants dans ''~/.gnupg/gpg.conf'' : keyserver hkps://hkps.pool.sks-keyservers.net Et spécifier le chemin d’accès complet où vous avez sauvegardé le fichier de l’autorité de certification en bas du fichier ''dirmngr.conf'' : hkp-cacert /etc/ssl/certs/sks-keyservers.netCA.pem Sous certaines versions du système – avant Ubuntu 18.04 – il faudra une double extension, car la commande ''update-ca-certificates'' semble en rajouter une à celle existante sur le nom du fichier. hkp-cacert /etc/ssl/certs/sks-keyservers.netCA.pem.pem Avec cette configuration les interactions avec le serveur de clés seront chiffrées avec ''hkps'', qui masquera notre réseau de relations sociales pour éviter qu’il soit divulgué à quiconque intercepterait le trafic réseau. Par exemple, si vous faites ''gpg --refresh-keys'' sur un serveur de clés qui ne supporte que ''hkp'', quelqu’un surveillant le trafic pourrait voir toutes les clés que nous possédons dans notre trousseau en observant les demandes de mises à jour envoyées pour chacune d’entre elles. C’est là une information plutôt intéressante ! Note : [[hkps://keys.indymedia.org|hkps://keys.indymedia.org]], [[hkps://keys.mayfirst.org|hkps://keys.mayfirst.org]] et [[hkps://keys.riseup.net|hkps://keys.riseup.net]] sont d’autres serveurs qui proposent ce service, mais il est préférable de leur préférer un groupe de serveurs. === Serveur via TOR === Il existe aussi des serveurs en ''.onion'' afin de passer directement le trafic via le réseau [[https://www.torproject.org/|Tor]]. keyserver hkp://jirk5u4osbsr34t5.onion === Forcer l'utilisation de notre serveur === Un utilisateur qui crée sa clé peut indiquer un serveur de clés spécifique auquel s’adresser pour récupérer les nouvelles versions de sa clé. Il est recommandé d’utiliser l’option suivante dans ''~/.gnupg/gpg.conf'', qui ignorera de telles instructions : keyserver-options no-honor-keyserver-url C’est une bonne chose à faire, car - cela évite que les gens indiquent des méthodes non-sécurisées pour télécharger des mises à jour de leurs clés, - et même si le serveur choisi utilise ''hkps'' le rafraîchissement échouera parce que le ''ca-cert'' ne correspondra pas, ne correspondra pas, et donc la clé ne sera jamais mise à jour ; - notez aussi qu’un attaquant pourrait désigner un serveur de clés sous son contrôle afin de surveiller à quel moment et depuis quel endroit nous rafraîchissons les clés. === Rafraîchir automatiquement les clefs === Nous devons nous assurer que les clés se rafraîchissent régulièrement. La meilleure façon de le faire avec Debian ou Ubuntu est d’utiliser ''parcimonie'' : sudo apt install parcimonie [[https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/|Parcimonie]] est un démon qui rafraîchit lentement votre trousseau de clés à partir d’un serveur de clés en passant par [[https://www.torproject.org/|Tor]]. Il utilise un délai aléatoire et un nouveau circuit Tor pour chaque clé. Le but est de compliquer la vie d’un attaquant qui voudrait corréler les mises à jour de clés avec votre trousseau. Vous ne devriez pas utiliser ''gpg --refresh-keys'' ou la fonction équivalente de votre client de messagerie pour rafraîchir les clés, parce que vous dévoilerez ainsi à toute personne qui vous écoute, et à l’opérateur du serveur de clés, la totalité des clés que vous désirez rafraîchir. === Ne pas faire confiance aux serveurs de clefs === N’importe qui peut envoyer des clés sur les serveurs et il n’y a pas de raison de croire que celles que vous téléchargez appartiennent vraiment à la personne dont elles indiquent le nom. Nous devons donc vérifier personnellement avec le propriétaire l’empreinte entière de sa clé. Nous devrons faire cette vérification face à face ou par téléphone. Une fois que nous aurons vérifié l’empreinte, nous pourrons télécharger la bonne clé depuis un serveur : gpg --recv-key '' Attention aux apostrophes droites ci-dessus (‘) qu’il faut placer autour de l’empreinte complète et qui sont nécessaires pour que la commande fonctionne. Les guillemets droits (") fonctionnent également. Ne vous fiez pas à l’identifiant de clef. === Méfiance avec l'identifiant de la clef === Les identifiants courts pour les clés OpenPGP, par exemple 0×2861A790, sont d’une longueur de 32 bits. Il fut démontré la [[http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html|possibilité de les usurper]] avec une autre clé qui a le même identifiant. Les identifiants longs pour les clés OpenPGP (par exemple 0xA1E6148633874A3D) sont d’une longueur de 64 bits. Il est trivial de générer des collisions dessus, ce qui est également un [[https://www.debian-administration.org/users/dkg/weblog/105|problème potentiellement sérieux]]. L’utilisation du ''fingerprint'' est préférable. ==== Le fichier gpg.conf ==== La configuration utilisateur se fait dans le fichier ''gpg.conf'' ainsi que dans ''dirmngr.conf'' du répertoire par défaut de l'application. Si ces fichiers n'existent pas il faudra les créer et leur attribuer des droits limités : nano ~/.gnupg/gpg.conf chmod 600 ~/.gnupg/gpg.conf chmod 600 ~/.gnupg/dirmngr.conf Par défaut, le répertoire ''~/.gnupg'' a ses autorisations définies sur 700 et les fichiers contenus sur 600. Seul le propriétaire du répertoire est autorisé à lire, écrire et accéder aux fichiers. Ceci est à des fins de sécurité et ne doit pas être modifié. Dans le cas où ce répertoire ou n'importe quel fichier à l'intérieur de celui-ci ne respecte pas cette mesure de sécurité, vous obtiendrez des avertissements concernant les autorisations de fichiers et de répertoires personnels non sécurisés. # # This is an implementation of the Riseup OpenPGP Best Practices # https://help.riseup.net/en/security/message-security/openpgp/best-practices # Adapted by d2air for GnuPG v2 #----------------------------- # default key #----------------------------- # The default key to sign with. If this option is not used, the default key is # the first key found in the secret keyring #default-key 0xD8692123C4065DEA5E0F3AB5249B39D24F25E3B6 #----------------------------- # behavior #----------------------------- # 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 # Display long key IDs keyid-format 0xlong # List all keys (or the specified ones) along with their fingerprints with-fingerprint # Display the calculated validity of user IDs during key listings list-options show-uid-validity verify-options show-uid-validity # Display usage list-options show-usage # Try to use the GnuPG-Agent. With this option, GnuPG first tries to connect to # the agent before it asks for a passphrase. use-agent #----------------------------- # keyserver #----------------------------- # This is the server that --recv-keys, --send-keys, and --search-keys will # communicate with to receive keys from, send keys to, and search for keys on keyserver hkps://hkps.pool.sks-keyservers.net keyserver hkp://jirk5u4osbsr34t5.onion # When using --refresh-keys, if the key in question has a preferred keyserver # URL, then disable use of that preferred keyserver to refresh the key from keyserver-options no-honor-keyserver-url # When searching for a key with --search-keys, include keys that are marked on # the keyserver as revoked keyserver-options include-revoked #----------------------------- # algorithm and ciphers #----------------------------- # list of personal digest preferences. When multiple digests are supported by # all recipients, choose the strongest one personal-cipher-preferences AES256 AES192 AES CAST5 # list of personal digest preferences. When multiple ciphers are supported by # all recipients, choose the strongest one personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # message digest algorithm used when signing a key cert-digest-algo SHA512 # This preference list is used for new keys and becomes the default for # "setpref" in the edit menu default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed # Disable 3DES algorithm and SHA1 checksum disable-cipher-algo 3DES # to comment on older versions weak-digest SHA1 Le détail des différentes options possibles de ce fichier se trouvent [[https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html|ici]]. ==== Le fichier dirmngr.conf ==== # The option --use-tor Dirmngr and thus GnuPG into “Tor mode” to route all network access via Tor (an anonymity network). use-tor # Provide a certificate store to override the system default # Get this from https://sks-keyservers.net/sks-keyservers.netCA.pem hkp-cacert /etc/ssl/certs/sks-keyservers.netCA.pem Le détail des différentes options possibles de ce fichier se trouvent [[https://www.gnupg.org/documentation/manuals/gnupg/Dirmngr-Options.html|ici]]. ===== Configuration de la clef ===== ==== Clef primaire robuste ==== Par défaut il est actuellement recommandé de générer une clé RSA de 4096 bits avec l’algorithme de hachage SHA-512, mais les [[https://www.gnupg.org/faq/whats-new-in-2.1.html#ecc|courbes elliptiques]] sont maintenant supportées via l’option ''expert''. ==== Transition d'une ancienne clef ==== En cas transition, une méthode est de rédiger un [[https://riseup.net/fr/security/message-security/openpgp/key-transition|communiqué de transition]] signé par les deux clés, puis en informer les gens. [[http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/|Cette page]] détaille le processus à suivre pour générer une telle clé en s’assurant d’utiliser le bon algorithme de hachage (ça peut être compliqué avec des versions de GnuPG plus anciennes que la 1.4.10). ==== Délai d'expiration ==== Mettre une date d’expiration sur sa clé est une bonne chose. Pourquoi ? Parce que vous pouvez toujours étendre votre date d’expiration, même une fois qu’elle est passée ! Cette expiration est plutôt une sorte de valve de sûreté ou un « dispositif de l’homme mort » qui se déclenchera automatiquement à un certain moment. Si vous avez accès à la clé privée, vous pouvez le désamorcer. L’idée est de configurer un mécanisme qui désactivera votre clé au cas où vous n’y accéderiez plus (et ne disposez pas d’un certificat de révocation). Paramétrer une date d’expiration vous obligera à repousser cette date quand elle approchera. C’est une petite chose que vous devrez vous souvenir de faire. Vous pouvez penser que c’est pénible et que vous ne voulez pas vous en occuper, mais c’est en fait une bonne chose de faire cela de façon régulière pour maintenir à niveau vos compétences OpenPGP. Cela indique aux utilisateurs que la clé est toujours active, que le détenteur de la clé l’utilise toujours, et cela vous donne une occasion de vérifier l’état actuel de vos outils, et vos bonnes pratiques. Du reste, beaucoup de personnes refuseront de signer une clé qui n’a pas de date d’expiration ! Si vous avez déjà généré une clé sans date d’expiration, vous pouvez en spécifier une sur votre clé existante en utilisant la commande suivante : gpg --edit-key '' À présent, sélectionnez la sous-clé pour laquelle vous voulez paramétrer une date d’expiration (par exemple la première), ou aucune pour paramétrer l’expiration de votre clé primaire, puis invoquez la commande ''expire'' : gpg> key 1 gpg> expire Ajustez ensuite la date à une valeur raisonnable (par exemple deux ans plus tard), puis sauvegardez la clé et quittez : Key is valid for? (0) 2y gpg> save Vous pouvez alors envoyer votre clé aux serveurs de clés pour publier ce changement : gpg --send-key '' ==== Générer une paire de clefs ==== Pour de nombreuses personnes, les courbes NIST et Brainpool ont une origine douteuse et le plan pour GnuPG est d'utiliser par défaut la courbe de Bernstein 25519. GnuPG 2.1.0 est déjà compatible avec les clés de signature utilisant la variante Ed25519 de cette courbe. Ceci n'a pas encore été standardisé par l'IETF (c'est-à-dire qu'il n'y a pas de RFC), mais nous n'attendrons plus et continuerons en utilisant le format proposé pour cet algorithme de signature. gpg --expert --full-gen-key gpg (GnuPG) 2.1.15; Copyright (C) 2016 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Sélectionnez le type de clef désiré : (1) RSA et RSA (par défaut) (2) DSA et Elgamal (3) DSA (signature seule) (4) RSA (signature seule) (7) DSA (indiquez vous-même les capacités) (8) RSA (indiquez vous-même les capacités) (9) ECC et ECC (10) ECC (signature seule) (11) ECC (indiquez vous-même les capacités) Quel est votre choix ? 9 Sélectionnez le type de courbe elliptique désiré : (1) Curve 25519 (3) NIST P-256 (4) NIST P-384 (5) NIST P-521 (6) Brainpool P-256 (7) Brainpool P-384 (8) Brainpool P-512 (9) secp256k1 Quel est votre choix ? 1 Veuillez indiquer le temps pendant lequel cette clef devrait être valable. 0 = la clef n'expire pas = la clef expire dans n jours w = la clef expire dans n semaines m = la clef expire dans n mois y = la clef expire dans n ans Pendant combien de temps la clef est-elle valable ? (0) 10y La clef expire le mer. 01 déc. 2027 23:59:59 CET Est-ce correct ? (o/N) o GnuPG doit construire une identité pour identifier la clef. Nom réel : John Doe Adresse électronique : john@domaine.eu Commentaire : Vous avez sélectionné cette identité : « John Doe  » Changer le (N)om, le (C)ommentaire, l'(A)dresse électronique ou (O)ui/(Q)uitter ? O De nombreux octets aléatoires doivent être générés. Vous devriez faire autre chose (taper au clavier, déplacer la souris, utiliser les disques) pendant la génération de nombres premiers ; cela donne au générateur de nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie. De nombreux octets aléatoires doivent être générés. Vous devriez faire autre chose (taper au clavier, déplacer la souris, utiliser les disques) pendant la génération de nombres premiers ; cela donne au générateur de nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie. gpg: clef 0xCBC5A900D93F92C5 marquée de confiance ultime. gpg: répertoire « /home/john/.gnupg/openpgp-revocs.d » créé gpg: revocation certificate stored as '/home/john/.gnupg/openpgp-revocs.d/A0B000FF0000FF0011111111A0B00000000000FF.rev' les clefs publique et secrète ont été créées et signées. pub ed25519/0xA0B00000000000FF 2017-12-03 [SC] [expire : 2027-12-01] Empreinte de la clef = A0B0 00FF 0000 FF00 1111 1111 A0B0 0000 0000 00FF uid John Doe sub cv25519/0xB0FFFFFFFFFFFF00 2017-12-03 [E] [expire : 2027-12-01] === Base de confiance === Les clés sont identifiées par une valeur hexadécimale. 0xA0B00000000000FF est notre clé maîtresse et nous lui accordons une confiance ultime (donc au-delà de “complète” et de “marginale”) puisqu’il s’agit de notre propre clé. GnuPG rappelle aussi les règles (le modèle de confiance) utilisées par défaut pour considérer une clé publique comme valide, une clé doit être signée par un utilisateur à qui nous accordons une confiance “complète” ou par trois utilisateurs à qui nous accordons une confiance “marginale”. Notre clé publique est considérée comme valide puisque nous lui accordons une confiance ultime, ''1 u.'' sur la dernière ligne du code ci-dessous : gpg: 3 marginale(s) nécessaire(s), 1 complète(s) nécessaire(s), modèle de confiance PGP gpg: profondeur : 0 valables : 1 signées : 0 confiance : 0 i., 0 n.d., 0 j., 0 m., 0 t., 1 u. Le niveau de confiance est précisé avec la nomenclature : * i. : inconnu (non calculable) * n.d. : non décidé, pas d'avis, je ne sais pas * j. : aucune, pas de confiance * m. : confiance marginale * t. : confiance totale ou complète * u. : confiance ultime Ces informations peuvent s'afficher avec la commande : gpg --check-trustdb === Sous-clef générée === La dernière ligne de sortie de la commande ''gpg --expert --full-gen-key'' indique la création d'une sous clé notée **sub**. sub cv25519/0xB0FFFFFFFFFFFF00 2017-12-03 [E] [expire : 2027-12-01] Il faut utiliser la commande ''gpg --edit-key'' pour obtenir plus d'informations : gpg --edit-key 'A0B000FF0000FF0011111111A0B00000000000FF' gpg (GnuPG) 2.1.15; Copyright (C) 2016 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. La clef secrète est disponible. sec ed25519/0xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime ssb cv25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E [ ultime ] (1). John Doe Le champ **utilisation** nous indique l'usage possible avec ces clés. * C : certificate ou signer la clé publique d'un utilisateur * S : signer un document (mail, fichier...) * E : chiffrer un document * A : authentification (SSH, TLS...) Avec la commande de génération de clés GnuPG ne crée pas une paire, mais deux. La première est utilisable pour signer d’autres clés ainsi que des documents, mais c’est une sous-clé (subkey ou clé subordonnée) qui est utilisée pour chiffrer. Pourquoi ? Pour des raisons de sécurité, mais surtout de praticité, car tout le fonctionnement du réseau de confiance repose sur la signature des clefs publiques des utilisateurs. Si la clé de chiffrement est corrompue (par exemple un attaquant souhaitant lire nos messages et qui réussit) elle pourra être révoquée et une nouvelle pourra être créer, cette nouvelle clé sera rattachée à la clé maîtresse qui ne sera pas corrompue (enfin normalement) et il ne sera pas nécessaire de reconstruire les signatures sur la clé publique détruisant par la même le réseau de confiance. GnuPG fait cela par défaut avec les options 1 et 2 – et 9 en mode expert – du processus de génération de clefs de la commande ''gpg --expert --full-gen-key''. Les options 3 et 4 – et 10 en mode expert – de ce processus permettent de créer une seule et unique paire maîtresse. === Générer une seconde sous-clef === Après la génération d’une paire de clés, nous disposons d’une paire de clés maîtresse et d’une sous-clef pour le chiffrement. L’idée est ici de créer une nouvelle sous-clé pour la signature des documents afin de ne pas avoir à utiliser la clé principale pour autre chose que la signature d’autres clés publiques, cette tâche ne pouvant pas être déléguée à une sous-clé. gpg --expert --edit-key 'A0B000FF0000FF0011111111A0B00000000000FF' gpg (GnuPG) 2.1.15; Copyright (C) 2016 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. La clef secrète est disponible. sec ed25519/0xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime ssb cv25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E [ ultime ] (1). John Doe gpg> addkey Sélectionnez le type de clef désiré : (3) DSA (signature seule) (4) RSA (signature seule) (5) Elgamal (chiffrement seul) (6) RSA (chiffrement seul) (7) DSA (indiquez vous-même les capacités) (8) RSA (indiquez vous-même les capacités) (10) ECC (signature seule) (11) ECC (indiquez vous-même les capacités) (12) ECC (chiffrement seul) (13) Clef existante Quel est votre choix ? 10 Sélectionnez le type de courbe elliptique désiré : (1) Curve 25519 (3) NIST P-256 (4) NIST P-384 (5) NIST P-521 (6) Brainpool P-256 (7) Brainpool P-384 (8) Brainpool P-512 (9) secp256k1 Quel est votre choix ? 1 Veuillez indiquer le temps pendant lequel cette clef devrait être valable. 0 = la clef n'expire pas = la clef expire dans n jours w = la clef expire dans n semaines m = la clef expire dans n mois y = la clef expire dans n ans Pendant combien de temps la clef est-elle valable ? (0) 2y La clef expire le mar. 03 déc. 2019 23:59:59 CET Est-ce correct ? (o/N) o Faut-il vraiment la créer ? (o/N) o De nombreux octets aléatoires doivent être générés. Vous devriez faire autre chose (taper au clavier, déplacer la souris, utiliser les disques) pendant la génération de nombres premiers ; cela donne au générateur de nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie. sec ed25519/0xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime ssb cv25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E ssb ed25519/0xB0FFFFFFFFFFFF22 créé : 2017-12-03 expire : 2019-12-03 utilisation : S [ ultime ] (1). John Doe gpg> save === Préférences des clefs === Il est possible de vérifier et de définir les préférences d'utilisation des algorithmes de chiffrement, de hachage et de compression directement pour chaque clef avec ces commandes : gpg --expert --edit-key 'A0B000FF0000FF0011111111A0B00000000000FF' gpg (GnuPG) 2.1.15; Copyright (C) 2016 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. La clef secrète est disponible. sec ed25519/0xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime ssb cv25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E ssb ed25519/0xB0FFFFFFFFFFFF22 créé : 2017-12-03 expire : 2019-12-03 utilisation : S [ ultime ] (1). John Doe gpg> showpref [ ultime ] (1). John Doe Chiffrement : AES256, AES192, AES, CAST5, 3DES Hachage : SHA512, SHA384, SHA256, SHA224, SHA1 Compression : ZLIB, BZIP2, ZIP, Non compressé Fonctionnalités : MDC, Serveur de clefs sans modification gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed Définir la liste de préférences en : Chiffrement : AES256, AES192, AES, CAST5, 3DES Hachage : SHA512, SHA384, SHA256, SHA224, SHA1 Compression : ZLIB, BZIP2, ZIP, Non compressé Fonctionnalités : MDC, Serveur de clefs sans modification Faut-il vraiment mettre à jour les préférences ? (o/N) Les algorithmes 3DES (chiffrement) et [[https://debian-administration.org/users/dkg/weblog/48|SHA1]] (hachage) ne doivent être plus être utilisés. Ils doivent se trouver à la fin des préférences d'utilisation, à cause de la [[https://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024964.html|RFC 4880]] il est impossible de les enlever même avec la commande des préférences recommandées excluant ceux-ci : setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed ==== Ajouter une alerte dans le calendrier ==== Il vaut mieux paramétrer une alerte dans un agenda pour nous rappeler la date d’expiration, si possible avant la date, afin de pouvoir faire le changement un peu en avance. Cependant il sera toujours possible de reporter la date d’expiration de la clé même après son expiration. ==== Certificat de révocation ==== La génération d'un certificat de révocation est un étape importante dans la création de clés. En cas d'oubli de la phrase de passe ou si la clé privée est compromise ou perdue, il faudra attendre que la clé expire sauf si avec un certificat de révocation qui pourra être publier sur les serveurs de clés pour signaler aux autres utilisateurs que la clé a été révoquée. Une clé révoquée peut encore être utilisée pour vérifier ses anciennes signatures ou pour déchiffrer des données (à condition d'avoir accès à la clé privée), mais elle ne peut plus être utilisée pour chiffrer de nouveaux messages à notre intention. Depuis la version 2.1.0 un certificat de révocation est créé dans le dossier ''~/.gnupg/openpgp-revocs.d/'' au moment de la génération de la clef, mais cela peut se faire via la commande : gpg --output revoke.asc --gen-revoke '' === Révocation d'une clef === La révocation se fait avec les commandes suivantes : gpg --import /home/john/.gnupg/openpgp-revocs.d/A0B000FF0000FF0011111111A0B00000000000FF.rev gpg --keyserver hkps.pool.sks-keyservers.net --send-keys A0B000FF0000FF0011111111A0B00000000000FF Et avec un dossier parallèle : gpg --homedir=/media/veracrypt1 --keyring=~/.gnupg/pubring.gpg --trustdb-name=~/.gnupg/trustdb.gpg --output ~/Bureau/revoke.asc --gen-revoke A0B000FF0000FF0011111111A0B00000000000FF gpg --homedir=/media/veracrypt1 --keyring=~/.gnupg/pubring.gpg --trustdb-name=~/.gnupg/trustdb.gpg --import ~/Bureau/revoke.asc gpg --keyserver hkps.pool.sks-keyservers.net --send-keys A0B000FF0000FF0011111111A0B00000000000F ou : gpg --homedir=/media/veracrypt1 --keyring=~/.gnupg/pubring.gpg --trustdb-name=~/.gnupg/trustdb.gpg --import ~/.gnupg/openpgp-revocs.d/A0B000FF0000FF0011111111A0B00000000000FF.rev gpg --keyserver hkps.pool.sks-keyservers.net --send-keys A0B000FF0000FF0011111111A0B00000000000F === Révocation d'une sous-clef === Révoquer une sous-clé ne nécessite pas de certificat de révocation, cela peut se faire directement depuis l’interface interactive avec la commande ''gpg --edit-keys'' suivi de l’identifiant de la clé maîtresse. Il faudra ensuite utiliser la commande ''key'' avec la valeur de sa position (la position se compte à partir de 0) pour sélectionner la sous-clé et ensuite la commande ''revkey''. gpg --expert --edit-key 'A0B000FF0000FF0011111111A0B00000000000FF' gpg (GnuPG) 2.1.15; Copyright (C) 2016 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. La clef secrète est disponible. sec ed25519/0xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime ssb cv25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E ssb ed25519/0xB0FFFFFFFFFFFF22 créé : 2017-12-03 expire : 2019-12-03 utilisation : S [ ultime ] (1). John Doe gpg> key 1 sec ed25519/xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime ssb* cv25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E ssb ed25519/0xB0FFFFFFFFFFFF22 créé : 2017-12-03 expire : 2019-12-03 utilisation : S [ ultime ] (1). John Doe gpg> revkey Voulez-vous vraiment révoquer cette sous-clef ? (o/N) Le caractère ''*'' placé sur la ligne de la sous-clé après **sub** indique qu’elle est bien sélectionnée. ==== Utilisation sans clefs primaires ==== La clé primaire est nécessaire que pour la certification (signature de clefs publiques), cette tache se réalise peu fréquemment. Il est possible de supprimer la clé secrète afin de n’utiliser que les sous-clés pour le chiffrement et la signature de documents. === Sauvegarde des clefs === Il est recommandé de faire avant toutes manipulations une copie du répertoire ''~/.gnupg/'' : cd; tar cjvf gnupg-`date +%Y%m%d`.tbz2 ~/.gnupg === Exportation des clefs === Si la procédure pour cela était relativement « tordue » avec GnuPG 1.4 et 2.0 (il n’était pas possible de supprimer uniquement la clef primaire du trousseau privée, de sorte qu’il fallait, en gros : exporter les sous-clefs uniquement, supprimer la clef primaire – ce qui supprimait aussi les sous-clefs rattachées, puis ré-importer uniquement les sous-clefs ; c’est devenu beaucoup plus simple avec GnuPG 2.1. Trouvez le keygrip de votre clef primaire : gpg --with-keygrip -K /home/john/.gnupg/pubring.kbx ------------------------------ sec ed25519/xA0B00000000000FF 2017-12-03 [SC] [expire : 2027-12-01] Keygrip = D4DF0C35D3E22FA6AC37DA2E54FB03F73616A3CB uid [ultimate] John Doe La clef privée xA0B00000000000FF se trouve dans le fichier ''~/.gnupg/private-keys-v1.d/D4DF0C35D3E22FA6AC37DA2E54FB03F73616A3CB.key''. Sortez simplement ce fichier de son répertoire et stockez-le sur le support de votre choix. Quand vous auez besoin d’utiliser la clef primaire, remettez temporairement le fichier en place et c’est tout. Je vous recommande de conserver la ou les clefs privées sur un support externe dans un volume crypté avec [[https://veracrypt.codeplex.com/|VeraCrypt]]. === Double répertoire gnupg pour les clefs privées === Pour éviter de manipuler l’importation et l’exportation de fichiers pour les opérations de signature de clefs ou de création de sous-clés, il est possible de créer sur un support amovible (disque, clef USB…) – et si possible chiffré – une autre configuration de GnuPG. Je vous propose de faire cela sur un volume crypté avec [[https://veracrypt.codeplex.com/|VeraCrypt]]. == Exportation des clefs == Il faut exporter les clefs dans des fichiers : gpg --armor --export 0xA0B00000000000FF > clepublique.asc gpg --armor --export-secret-key 0xA0B00000000000FF > clesecrete.asc gpg --armor --export-secret-subkeys 0xA0B00000000000FF > sousclessecretes.asc Avec ces commandes, la clef publique est exportée dans le fichier ''clepublique.asc'', la clé privée dans le fichier ''clesecrete.asc'' et les clés secrètes des sous-clés dans le fichier ''sousclessecretes.asc''. La commande ''--armor'' n’est pas obligatoire, mais elle permet d’imprimer les fichiers produits en les créant en ASCII. Aucun mot de passe est demandé à l’exportation des clés secrètes, car elles sont exportées crypter. == Suppression des clefs secrètes == Après les avoir sauvegardées, il faut maintenant supprimer les clés secrètes de notre trousseau : gpg --delete-secret-keys 0xA0B00000000000FF gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. sec ed25519/0xA0B00000000000FF 2017-12-03 John Doe Faut-il supprimer cette clef du porte-clefs ? (o/N) o C'est une clef secrète — faut-il vraiment la supprimer ? (o/N) o La commande ''gpg --list-secret-keys'' confirmera la suppression par une sortie vide. == Réimporter les sous-clefs secrètes == Afin de pouvoir utiliser notre configuration uniquement avec des sous-clés nous devons les réimporter : gpg --import sousclesecrete.asc gpg: clef 0xAAAAAAAAFFFFFFFF : clef secrète importée gpg: clef 0xAAAAAAAAFFFFFFFF : « John Doe » n'est pas modifiée gpg: Quantité totale traitée : 1 gpg: non modifiées : 1 gpg: clefs secrètes lues : 1 gpg: clefs secrètes importées : 1 La commande ''gpg --list-secret-keys'' affichera : gpg --list-secret-keys /home/john/.gnupg/pubring.kbx ------------------------------ sec# ed25519/0xA0B00000000000FF 2017-12-03 [expire : 2027-12-01] Empreinte de la clef = AAAA BBBB CCCC DDDD EEEE FFFF 0000 1111 2222 3333 uid John Doe ssb ed25519/0xB0FFFFFFFFFFFF00 2017-12-03 ssb ed25519/0xB0FFFFFFFFFFFF22 2017-12-03 Le caractère ''#'' placé sur la ligne de la clé privée après **sec** indique qu’elle n’est pas disponible mais les deux sous-clefs privées sont bien présentes. Cette configuration peut être utiliser pour chiffrer et signer des documents. À cause de l’absence de la clef privée maîtresse des fonctionnalités ne seront plus disponibles à l’édition, par exemple : gpg> addkey Les parties secrètes de la clef principale ne sont pas disponibles. gpg: Échec de génération de la clef : Pas de clef secrète == Configuration alternative externe == gpg --homedir=/media/veracrypt1 --import clepublique.asc clesecrete.asc gpg: Attention : les droits du répertoire personnel « /media/veracrypt2 » ne sont pas sûrs gpg: le trousseau local « /media/veracrypt1/pubring.kbx » a été créé gpg: /media/veracrypt1/trustdb.gpg : base de confiance créée gpg: clef 000000FF : clef publique « John Doe » importée gpg: clef 000000FF : clef secrète importée gpg: clef 000000FF : « John Doe » n'est pas modifiée gpg: Quantité totale traitée : 2 gpg: non modifiées : 2 gpg: clefs secrètes lues : 1 gpg: clefs secrètes importées : 1 Pour supprimer l’avertissement de cette sortie ''gpg: Attention : les droits du répertoire personnel « /media/veracrypt1 » ne sont pas sûrs'' il faut accorder des permissions en lecture et écriture uniquement à l’utilisateur courant (nous). chmod 700 /media/veracrypt1 == Utilisation du répertoire alternatif == Il est possible d’utiliser ce répertoire seulement comme avec ''.gnupg'', mais aussi avec celui ci. Pour ce type d’utilisation, par exemple pour modifier sa clé ou signer celle d’un autre utilisateur, il suffit de monter la volume contenant notre répertoire alternatif. Pour éditer notre clef avec les deux répertoires la commande est la suivante : gpg --homedir=/media/veracrypt1 --keyring=~/.gnupg/pubring.kbx --trustdb-name=~/.gnupg/trustdb.gpg --edit-key 'A0B000FF0000FF00111111110000AAAAFFFFFFFF' gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. La clef secrète est disponible. pub ed25519/0xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime sub ed25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E sub ed25519/0xB0FFFFFFFFFFFF22 créé : 2017-12-03 expire : 2019-12-03 utilisation : S [ ultime ] (1). John Doe gpg> Le paramètre obsolète ''secret-keyring'' est maintenant inutile. Toutes les opérations nécessitant la clé privée principale deviennent possibles, mais attention tous les changements se feront dans le répertoire alternatif ''/media/veracrypt1'', ainsi l’ajout d’une sous clé devra être répercuté manuellement dans le répertoire courant. gpg2 --home=/media/veracrypt1 --armor --export 0xA0B00000000000FF > maj-clepublique.asc Cette commande mettra à jour que la partie publique des clés. Il faudra faire la même opération pour les clés privées, mais **il existe un problème de fusion des sous-clés**, il n’existe pas de mise à jour des sous-clés secrètes. Pour contrer ce problème il faut effacer toutes les clés privées du répertoire courant (celui sans la clé privée maîtresse) puis exporter les sous-clés secrètes du répertoire alternatif pour les importer dans le répertoire courant. gpg --delete-secret-keys 0xA0B00000000000FF gpg --homedir=/media/veracrypt1 --armor --export-secret-subkeys 0xA0B00000000000FF > maj-sousclesecrete.asc gpg --import maj-sousclesecrete.asc === Certification d'une clef publique === Pour signer une clef publique avec le répertoire alternatif, après avoir vérifier le fingerprint avec le correspondant, il faut utiliser la commande pour éditer la clef : gpg --homedir=/media/veracrypt1 --keyring=~/.gnupg/pubring.kbx --trustdb-name=~/.gnupg/trustdb.gpg --edit-key 0xBBAACC001122334455 puis dans la console les commandes ''key'', ''sign'' et ''trust'' puis ''save'' pour finir. ==== Publication de la clef publique ==== Vous pouvez maintenant publier la clef publique, pour cela il faut utiliser la commande : gpg --send-keys 0xA0B00000000000FF ===== GnuPG et authentification SSH ===== ==== Générer une sous-clef d’authentification ==== gpg --homedir=/media/veracrypt1 --keyring=~/.gnupg/pubring.kbx --trustdb-name=~/.gnupg/trustdb.gpg --edit-key 'A0B000FF0000FF00111111110000AAAAFFFFFFFF' gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. La clef secrète est disponible. sec ed25519/0xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime ssb cv25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E ssb ed25519/0xB0FFFFFFFFFFFF22 créé : 2017-12-03 expire : 2019-12-03 utilisation : S [ ultime ] (1). John Doe gpg> addkey Les parties secrètes de la clef principale sont stockées sur la carte. Sélectionnez le type de clef désiré : (3) DSA (signature seule) (4) RSA (signature seule) (5) Elgamal (chiffrement seul) (6) RSA (chiffrement seul) (7) DSA (indiquez vous-même les capacités) (8) RSA (indiquez vous-même les capacités) (10) ECC (signature seule) (11) ECC (indiquez vous-même les capacités) (12) ECC (chiffrement seul) (13) Clef existante Quel est votre choix ? 11 Actions possibles pour une clef ECDSA/EdDSA : Signer Authentifier Actions actuellement permises : Signer (S) Inverser la capacité de signature (A) Inverser la capacité d'authentification (Q) Terminé Quel est votre choix ? A Actions possibles pour une clef ECDSA/EdDSA : Signer Authentifier Actions actuellement permises : Signer Authentifier (S) Inverser la capacité de signature (A) Inverser la capacité d'authentification (Q) Terminé Quel est votre choix ? S Actions possibles pour une clef ECDSA/EdDSA : Signer Authentifier Actions actuellement permises : Authentifier (S) Inverser la capacité de signature (A) Inverser la capacité d'authentification (Q) Terminé Quel est votre choix ? Q Sélectionnez le type de courbe elliptique désiré : (1) Curve 25519 (3) NIST P-256 (4) NIST P-384 (5) NIST P-521 (6) Brainpool P-256 (7) Brainpool P-384 (8) Brainpool P-512 (9) secp256k1 Quel est votre choix ? 1 Veuillez indiquer le temps pendant lequel cette clef devrait être valable. 0 = la clef n'expire pas = la clef expire dans n jours w = la clef expire dans n semaines m = la clef expire dans n mois y = la clef expire dans n ans Pendant combien de temps la clef est-elle valable ? (0) 5y La clef expire le ven. 27 oct. 2023 03:42:20 CEST Est-ce correct ? (o/N) o Faut-il vraiment la créer ? (o/N) o De nombreux octets aléatoires doivent être générés. Vous devriez faire autre chose (taper au clavier, déplacer la souris, utiliser les disques) pendant la génération de nombres premiers ; cela donne au générateur de nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie. sec ed25519/0xA0B00000000000FF créé : 2017-12-03 expire : 2027-12-01 utilisation : SC confiance : ultime validité : ultime ssb cv25519/0xB0FFFFFFFFFFFF00 créé : 2017-12-03 expire : 2027-12-01 utilisation : E ssb ed25519/0xB0FFFFFFFFFFFF22 créé : 2017-12-03 expire : 2019-12-01 utilisation : S ssb ed25519/0xB0FFFFFFFFFFFF44 créé : 2018-12-03 expire : 2023-12-01 utilisation : A [ ultime ] (1). John Doe gpg> save ==== Le fichier gpg-agent.conf ==== Pour activer le support SSH dans l'agent GnuPG nous éditerons ainsi le fichier : enable-ssh-support ==== Le fichier sshcontrol ==== Pour indiquer à GnuPG notre clef d’authentification pour SSH nous ajouterons son identifiant (keygrip) dans le fichier ''~/.gnupg/sshcontrol''. gpg -k --with-keygrip /home/john/.gnupg/pubring.kbx ------------------------------ pub ed25519/0xA0B00000000000FF 2017-12-03 [SC] [expire : 2027-12-01] Empreinte de la clef = A0B0 00FF 0000 FF00 1111 1111 A0B0 0000 0000 00FF Keygrip = AABBCCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDD uid [ ultime ] John Doe sub cv25519/0xB0FFFFFFFFFFFF00 2017-12-03 [E] [expire : 2027-12-01] Keygrip = BBCCDD00000000000000000000000000000000EE sub ed25519/0xB0FFFFFFFFFFFF22 2017-12-03 [S] [expire : 2019-12-01] Keygrip = CCDDEEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF sub rsa4096/0xB0FFFFFFFFFFFF44 2018-12-03 [A] [expire : 2023-12-01] Keygrip = DDEEFF00000000000000000000000000000000GG Nous récupérons la clé d'authentification 0xB0FFFFFFFFFFFF44 avec l’identifiant associé afin de l’ajouter au fichier ''~/.gnupg/sshcontrol''. echo "DDEEFF00000000000000000000000000000000GG 0" >> ~/.gnupg/sshcontrol Le chiffre après l’identifiant est la durée en seconde pendant laquelle l’agent gardera la clé en mémoire. Si ''0'' – la valeur par défaut – est utilisé la durée sera de 30 minutes. DDEEFF00000000000000000000000000000000GG 0 ===== Logiciels ===== * [[https://gpgtools.org/|GnuPG pour macOS]] * [[https://www.gpg4win.org/|GnuPG pour Windows]] * [[https://play.google.com/store/apps/details?id=org.sufficientlysecure.keychain|OpenKeychain]], PGP pour Android * [[https://play.google.com/store/apps/details?id=com.fsck.k9|K-9 Mail]] pour Android supporte OpenPGP * [[https://addons.mozilla.org/fr/firefox/addon/mailvelope/| Mailvelope]], une extension Firefox pour les webmails * [[https://addons.thunderbird.net/fr/thunderbird/addon/enigmail/| Enigmail]], une extension Thunderbird ===== Références ===== * [[https://wiki.archlinux.org/index.php/GnuPG|GnuPG sur wiki.archlinux.org]] * [[https://linuxfr.org/users/gouttegd/journaux/de-la-gestion-des-clefs-openpgp|De la gestion des clefs OpenPGP]] * Bonnes pratiques pour [[https://help.riseup.net/fr/security/message-security/openpgp/best-practices|l'utilisation d'OpenPGP]] * [[https://github.com/ioerror/duraconf/|duraconf]], a collection of hardened configuration files for SSL/TLS services par Jacob Appelbaum * [[https://www.debian-administration.org/users/dkg/weblog/105|OpenPGP Key IDs are not useful]] * [[https://debian-administration.org/users/dkg/weblog/48|HOWTO prep for migration off of SHA-1]] in OpenPGP * [[https://linuxfr.org/news/gnupg-openpgp-js-cie-quoi-de-neuf|GnuPG, OpenPGP.js & cie : quoi de neuf ?]] * [[https://linuxfr.org/users/spack/journaux/gnupg-et-authentification-ssh|GnuPG et authentification SSH]]