GnuPG

Selon le site officiel : GnuPG est une implémentation complète et gratuite du standard OpenPGP tel que défini par le RFC4880 (également appelé PGP). GnuPG vous permet de chiffrer et de signer vos données et vos communications. il comporte un système de gestion de clés polyvalent, ainsi que des modules d’accès pour tous les types de répertoires de clés publiques. GnuPG, également connu sous le nom de GPG, est un outil de ligne de commande doté de fonctionnalités facilitant l’intégration à d’autres applications. Une multitude d’applications frontales et de bibliothèques sont disponibles. GnuPG fournit également un support pour S/MIME et Secure Shell (ssh).
le contenu de ce “post” est une traduction de “GnuPG Archwiki”

Installation

Installez le paquet gnupg
Ceci installera également pinentry , une collection de dialogues simples de saisie de code confidentiel ou de phrase secrète que GnuPG utilise pour la saisie de phrase secrète. Le script shell /usr/bin/pinentry détermine quelle boîte de dialogue pinentry est utilisée, dans l’ordre décrit dans le paragraphe pinentry .
Si vous souhaitez utiliser une interface graphique ou un programme s’intégrant à GnuPG, consultez Liste des applications/Sécurité # Cryptage, signature, stéganographie .

Configuration

Emplacement du répertoire

$GNUPGHOME est utilisé par GnuPG pour pointer vers le répertoire dans lequel ses fichiers de configuration sont stockés. Par défaut, $GNUPGHOME n’est pas défini et votre $HOME est utilisé à la place. ainsi, vous trouverez un répertoire ~/.gnupg juste après l’installation.

Pour modifier l’emplacement par défaut, exécutez gpg de cette manière $ gpg --homedir path/to/file ou définissez la variable d’environnement GNUPGHOME .

Fichiers de configuration

Les fichiers de configuration par défaut sont ~/.gnupg/gpg.conf et ~/.gnupg/dirmngr.conf .

Par défaut, le répertoire gnupg a ses autorisations définies sur 700 et les autorisations des fichiers qu’il contient sont définies sur 600 . Seul le propriétaire du répertoire est autorisé à lire, à écrire et à accéder aux fichiers. Ceci est pour des raisons de sécurité et ne devrait pas être changé. Au cas où ce répertoire ou un fichier à l’intérieur ne respecterait pas cette mesure de sécurité, vous recevrez des avertissements concernant les autorisations non sécurisées des fichiers et des répertoires de départ.

Ajoutez à ces fichiers les options longues de votre choix. N’écrivez pas les deux tirets, mais simplement le nom de l’option et les arguments requis. Vous trouverez des fichiers squelettes dans /usr/share/doc/gnupg/ . Ces fichiers sont copiés dans ~/.gnupg à la première exécution de gpg s’ils n’y existent pas. D’autres exemples se trouvent dans le paragraphe Voir aussi

De plus, pacman utilise un ensemble différent de fichiers de configuration pour la vérification de la signature du paquet.

Options par défaut pour les nouveaux utilisateurs

Si vous souhaitez configurer certaines options par défaut pour les nouveaux utilisateurs, placez les fichiers de configuration dans /etc/skel/.gnupg/.
Lorsque le nouvel utilisateur est ajouté au système, les fichiers d’ici seront copiés dans son répertoire personnel GnuPG. Il existe également un script simple appelé addgnupghome que vous pouvez utiliser pour créer de nouveaux répertoires de base GnuPG pour les utilisateurs existants:

# addgnupghome user1 user2

Ceci ajoutera les /home/user1/.gnupg/ et /home/user2/.gnupg/ respectifs et copiera les fichiers du répertoire squelette dans celui-ci. Les utilisateurs avec le répertoire personnel GnuPG existant sont tout simplement ignorés.

Usage

Remarque: Chaque fois qu’un user-id est requis dans une commande, il peut être spécifié avec votre identifiant de clé, votre empreinte digitale, une partie de votre nom ou votre adresse e-mail, etc. GnuPG est flexible à cet égard.

Créer une paire de clés

Générez une paire de clés en tapant un terminal:

$ gpg --full-gen-key

Conseil: Utilisez l’option –expert pour obtenir d’autres chiffrement tels que ECC . [1]

La commande demandera des réponses à plusieurs questions.

  • une clé RSA (signer uniquement) et RSA (chiffrer uniquement).
  • une taille de clé de la valeur par défaut (2048). Une taille de clé plus grande de 4096 “ne nous donne presque rien, tout en nous coûtant cher” [2] .
  • une date d’expiration. Une période d’un an est assez bonne pour l’utilisateur moyen. De cette façon, même si l’accès au trousseau est perdu, les autres utilisateurs pourront savoir qu’il n’est plus valide. Plus tard, si nécessaire, la date d’expiration peut être étendue sans avoir à émettre une nouvelle clé.
  • votre nom et votre adresse email. Vous pouvez ajouter plusieurs identités à la même clé ultérieurement ( par exemple , si vous souhaitez associer plusieurs adresses électroniques à cette clé).
  • pas de commentaire facultatif. Comme la sémantique du champ de commentaire n’est pas bien définie , sa valeur d’identification est limitée.
  • une phrase secrète sécurisée .

Remarque: le nom et l’adresse électronique que vous entrez ici seront visibles par quiconque importe votre clé.

Générer un certificat de révocation

Après avoir généré votre clé, l’une des premières choses à faire est de créer un certificat de révocation:

$ gpg --gen-revoke --armor --output=revocation_certificate.asc user-id

Ce certificat peut être utilisé pour révoquer votre clé si elle est perdue ou compromise.

Avertissement: toute personne ayant accès au certificat de révocation peut révoquer votre clé. Protégez votre certificat de révocation comme vous protégez vos clés secrètes. Imprimez-le, enregistrez-le sur un disque et stockez-le en toute sécurité. Il sera suffisamment court pour que vous puissiez le saisir à nouveau à la main sans trop d’effort si vous l’imprimez.

Liste des clés

Pour répertorier les clés de votre jeu de clés publiques:

$ gpg –list-keys

Pour répertorier les clés de votre jeu de clés secret:

$ gpg –list-secret-keys

Exporter votre clé publique

L’utilisation principale de gpg est d’assurer la confidentialité des messages échangés via une cryptographie à clé publique. Ainsi, chaque utilisateur distribue la clé publique de son trousseau, qui peut être utilisée par d’autres personnes pour chiffrer des messages à destination de l’utilisateur. La clé privée doit toujours rester privée, sinon la confidentialité est rompue. Voir w: Cryptographie à clé publique pour des exemples concernant l’échange de messages.

Ainsi, pour que d’autres puissent vous envoyer des messages cryptés, ils ont besoin de votre clé publique.

Pour générer une version ASCII de la clé publique d’un utilisateur dans un fichier public.key (par exemple, pour la distribuer par courrier électronique):

$ gpg --output public.key --armor --export user-id

Vous pouvez également ou #Utiliser un serveur de clés pour partager votre clé.

Conseil: Ajoutez –no-emit-version pour éviter d’imprimer le numéro de version ou ajoutez le paramètre correspondant à votre fichier de configuration.

Importer une clé publique

Pour chiffrer des messages à d’autres personnes et vérifier leurs signatures, vous avez besoin de leur clé publique. Pour importer une clé publique avec le nom de fichier public.key dans votre jeu de clés:

$ gpg --import public.key

Sinon, #Utilisez un serveur de clés pour trouver une clé publique.

Utiliser un serveur de clés

Vous pouvez enregistrer votre clé auprès d’un serveur de clé publique PGP afin que d’autres personnes puissent la récupérer sans avoir à vous contacter directement:

$ gpg --send-keys key-id

Avertissement: Une fois qu’une clé a été soumise à un serveur de clés, elle ne peut pas être supprimée du serveur. [3]

Conseil: Vous pouvez accéder à votre identifiant de clé par $ gpg --list-secret-keys --keyid-format=LONG <email> . Le key-id est la clé de hachage fournie dans la seconde ligne.

Pour connaître les détails d’une clé sur le serveur de clés, sans l’importer, procédez comme suit:

$ gpg --search-keys user-id

Pour importer une clé depuis un serveur de clés:

$ gpg --recv-keys key-id
  • Attention:
    • Vous devez vérifier l’authenticité de la clé publique récupérée en comparant son empreinte digitale à celle que le propriétaire a publiée sur une ou plusieurs sources indépendantes (par exemple, en contactant directement la personne). Voir Wikipedia: empreinte digitale de clé publique pour plus d’informations.
    • L’utilisation d’un identifiant court peut entraîner des collisions. Toutes les clés portant l’ID court seront importées. Pour éviter cela, utilisez l’empreinte complète ou l’ID de clé longue lors de la réception d’une clé. [4]

Les serveurs de clés les plus courants:

  • Groupe de serveurs de clés SKS : fédéré, aucune vérification, les clés ne peuvent pas être supprimées.
  • Mailvelope Keyserver : central, vérification des identifiants de messagerie, les clés peuvent être supprimées.
  • keys.openpgp.org : central, vérification des identifiants de messagerie, suppression des clés, aucune signature de tiers (c.-à-d. absence de support Web of Trust).

Répertoire de clés Web

Le protocole WKS (Web Key Service) est une nouvelle norme de distribution de clés, dans laquelle le domaine de messagerie fournit son propre serveur de clés appelé Web Key Directory (WKD) . Lors du chiffrement sur une adresse électronique (par exemple, user@example.com ), GnuPG (> = 2.1.16) interrogera le domaine ( example.com ) via HTTPS pour la clé publique OpenPGP si elle ne figure pas déjà dans le trousseau local. Notez que l’option auto-key-locate wkd doit contenir wkd (qui est la valeur par défaut).

# gpg --recipient user@example.org --auto-key-locate local,wkd --encrypt doc

Consultez le wiki de GnuPG pour obtenir une liste des fournisseurs de messagerie prenant en charge WKD. Si vous contrôlez vous-même le domaine de votre adresse e-mail, vous pouvez suivre ce guide pour activer WKD pour votre domaine. Pour vérifier si votre clé peut être trouvée dans le WKD, vous pouvez utiliser cette interface Web .

Crypter et décrypter

Asymétrique

Vous devez importer la clé publique d’un utilisateur avant de chiffrer (options –encrypt ou -e ) un fichier ou un message destiné à ce destinataire (options –recipient ou -r ). De plus, vous devez créer une paire de clés si vous ne l’avez pas déjà fait.

Pour chiffrer un fichier avec le nom doc , utilisez:

$ gpg --recipient user-id --encrypt doc

Pour décrypter (option –decrypt ou -d ) un fichier portant le nom doc .gpg chiffré avec votre clé publique, utilisez:

$ gpg --output doc --decrypt doc.gpg

gpg vous demandera votre phrase secrète, puis décryptera et écrira les données de doc .gpg à doc . Si vous omettez l’option *-o ( –output *), gpg écrira les données déchiffrées sur stdout.

  • Add –armor pour chiffrer un fichier à l’aide d’une armure ASCII (convient pour copier et coller un message au format texte)
  • Utilisez -R user-id ou –hidden-recipient user-id au lieu de -r pour ne pas mettre les ID de clé de destinataire dans le message chiffré. Cela permet de masquer les destinataires du message et constitue une contre-mesure limitée contre l’analyse du trafic.
  • Ajoutez –no-emit-version pour éviter d’imprimer le numéro de version ou ajoutez le paramètre correspondant à votre fichier de configuration.
  • Vous pouvez utiliser gnupg pour chiffrer vos documents sensibles en utilisant votre propre identifiant utilisateur en tant que destinataire ou en utilisant le drapeau –default-recipient-self
    Cependant, vous ne pouvez créer ce fichier qu’un à la fois, bien que vous puissiez toujours archiver divers fichiers, puis chiffrer l’archive. Voir aussi Disk encryption#Available methods si vous souhaitez chiffrer des répertoires ou un système de fichiers complet.

Symétrique

Le chiffrement symétrique ne nécessite pas la génération d’une paire de clés et peut être utilisé pour chiffrer simplement des données avec une phrase secrète. Utilisez simplement –symmetric ou -c pour effectuer le cryptage symétrique:

$ gpg -c doc

L’exemple suivant:

  • Chiffre la doc avec un chiffre symétrique à l’aide d’une phrase secrète
  • Utilise l’algorithme de chiffrement AES-256 pour chiffrer la phrase secrète
  • Utilise l’algorithme de synthèse SHA-512 pour modifier la phrase secrète.
  • Mangles la phrase de passe pour 65536 itérations

    $ gpg -c –s2k-cipher-algo AES256 –s2k-digest-algo SHA512 –s2k-count 65536 doc

Pour déchiffrer un doc .gpg crypté symétriquement à l’aide d’une phrase secrète, le contenu déchiffré en sortie dans le même répertoire que doc :

$ gpg --output doc --decrypt doc.gpg

Maintenance de la clé

Sauvegardez votre clé privée

Pour sauvegarder votre clé privée, procédez comme suit:

$ gpg --export-secret-keys --armor <user-id> > privkey.asc

Notez que la version 2.1 de gpg a modifié le comportement par défaut de sorte que la commande ci-dessus applique une protection par phrase secrète, même si vous avez délibérément choisi de ne pas en utiliser une pour la création de clé. En effet, autrement, toute personne ayant accès au fichier exporté ci-dessus serait en mesure de chiffrer et de signer des documents comme si vous étiez vous-même sans avoir besoin de connaître votre phrase secrète.

Avertissement: La phrase secrète est généralement le lien le plus faible pour la protection de votre clé secrète. Placez la clé privée dans un endroit sûr sur un autre système / périphérique, tel qu’un conteneur verrouillé ou un lecteur crypté. C’est la seule sécurité que vous ayez à reprendre le contrôle de votre trousseau de clés en cas, par exemple, de panne de lecteur, de vol ou pire.

Pour importer la sauvegarde de votre clé privée:

$ gpg --import privkey.asc

Conseil: Paperkey peut être utilisé pour exporter des clés privées sous forme de texte lisible par un humain ou de codes à barres lisibles par une machine pouvant être imprimés sur papier et archivés.

Modifier votre clé

L’exécution de la commande gpg --edit-key <user-id> présentera un menu qui vous permettra d’effectuer la plupart des tâches liées à la gestion des clés.

Quelques commandes utiles dans le sous-menu Edit Key:

 > passwd # change le mot de passe
 > clean # compacte tout ID utilisateur qui n'est plus utilisable (par exemple, révoqué ou expiré)
 > revkey # révoquer une clé
 > addkey # ajoute une sous-clé à cette clé
 > expire # change le délai d'expiration de la clé
 > adduid # ajouter des noms, des commentaires et des adresses électroniques supplémentaires
 > addphoto # ajoute une photo à la clé (JPG, 240x288 recommandé, entrez le chemin complet de l'image lorsque vous y êtes invité)

Tapez help dans le sous-menu Edit Key pour plus de commandes.

Conseil: Si vous avez plusieurs comptes de messagerie, vous pouvez les ajouter en tant qu’identité à l’aide de la commande adduid . Vous pouvez ensuite définir votre favori comme primary .

Sous-clé d’exportation

Si vous envisagez d’utiliser la même clé sur plusieurs périphériques, vous pouvez supprimer votre clé principale et ne conserver que la sous-clé de cryptage minimal sur des systèmes moins sécurisés.

Commencez par rechercher la sous-clé que vous souhaitez exporter.

$ gpg --list-secret-keys

Sélectionnez uniquement cette sous-clé à exporter.

$ gpg -a --export-secret-subkeys [id de sous-clé]!  > /tmp/subkey.gpg

Avertissement: Si vous oubliez d’ajouter le!, Toutes vos sous-clés seront exportées.

À ce stade, vous pouvez vous arrêter, mais il est probablement préférable de modifier également le mot de passe. Importez la clé dans un dossier temporaire.

 $ gpg --homedir / tmp / gpg --import /tmp/subkey.gpg
 $ gpg --homedir / tmp / gpg --edit-key <id-utilisateur>
 > passwd
 > save
 $ gpg --homedir / tmp / gpg -a --export-secret-subkeys [id de sous- clé] !  > /tmp/subkey.altpass.gpg

Remarque: vous recevrez un avertissement indiquant que la clé principale n’était pas disponible et que le mot de passe n’a pas été modifié, mais que le mot de passe de la sous-clé peut être ignoré en toute sécurité.

À ce stade, vous pouvez maintenant utiliser /tmp/subkey.altpass.gpg sur vos autres appareils.

Extension de la date d’expiration

Avertissement: Ne supprimez jamais vos sous-clés expirées ou révoquées, sauf si vous avez une bonne raison. Cela risquerait de vous faire perdre la capacité de déchiffrer des fichiers chiffrés avec l’ancienne sous-clé. Veuillez supprimer uniquement les clés expirées ou révoquées des autres utilisateurs pour nettoyer votre trousseau de clés.

Il est judicieux de définir une date d’expiration sur vos sous-clés afin que, si vous perdez l’accès à la clé (par exemple, vous oubliez la phrase secrète), les clés ne continuent pas à être utilisées indéfiniment. Lorsque la clé expire, il est relativement simple de prolonger la date d’expiration:

 $ gpg --edit-key <id-utilisateur>
 > expire

Une nouvelle date d’expiration vous sera demandée, ainsi que la phrase secrète de votre clé secrète, utilisée pour signer la nouvelle date d’expiration.

Répétez cette opération pour toutes les autres sous-clés qui ont expiré:

> key 1
> expire

Enfin, enregistrez les modifications et quittez:

  > save

Mettez-le à jour sur un serveur de clés.

$ gpg –keyserver pgp.mit.edu –send-keys

Si vous utilisez cette clé sur plusieurs ordinateurs, vous pouvez également exporter la clé publique (avec les nouvelles dates d’expiration signées) et l’importer sur ces ordinateurs:

 $ gpg --export <id-utilisateur >> pubkey.gpg
 $ gpg --import pubkey.gpg

Il n’est pas nécessaire de réexporter votre clé secrète ni de mettre à jour vos sauvegardes: la clé secrète principale elle-même n’expire jamais et la signature de la date d’expiration laissée sur la clé publique et les sous-clés est tout ce qui est nécessaire.

Rotation des sous-clés

Avertissement: Ne supprimez jamais vos sous-clés expirées ou révoquées, sauf si vous avez une bonne raison. Cela risquerait de vous faire perdre la capacité de déchiffrer des fichiers chiffrés avec l’ancienne sous-clé. Veuillez supprimer uniquement les clés expirées ou révoquées des autres utilisateurs pour nettoyer votre trousseau de clés.

Si vous préférez ne plus utiliser les sous-clés une fois qu’elles ont expiré, vous pouvez également en créer de nouvelles. Faites cela quelques semaines à l’avance pour permettre aux autres de mettre à jour leur trousseau de clés.

Conseil: Vous n’avez pas besoin de créer une nouvelle clé simplement parce qu’elle a expiré. Vous pouvez prolonger la date d’expiration, voir la section # Extension de la date d’expiration .

Créer une nouvelle sous-clé (à répéter pour les clés de signature et de cryptage)

  $ gpg --edit-key <id-utilisateur>
 > addkey

Et répondez aux questions suivantes qu’il vous pose (voir paragraphe créez une paire de clés pour les réglages suggérés).

Sauvegarder les modifications

  > save

Mettez-le à jour sur un serveur de clés.

$ gpg --keyserver pgp.mit.edu --send-keys <id-utilisateur>

Vous devrez également exporter une nouvelle copie de vos clés secrètes à des fins de sauvegarde. Reportez-vous à la section Sauvegardez votre clé privée pour savoir comment procéder.

Conseil: La révocation de sous-clés expirées est inutile et peut-être de la mauvaise forme. Si vous révoquez constamment des clés, les autres risquent de perdre confiance en vous.

Révoquer une clé

Si vous perdez votre clé secrète ou si elle est compromise, vous voudrez la révoquer en important d’abord votre clé publique si vous n’avez plus accès à la paire de clés. Ensuite, vous importerez votre certificat de révocation :

$ gpg --import révocation_certificat.asc

Vous devez maintenant rendre publique la clé que vous venez de révoquer. Si vous avez utilisé un serveur de clés, envoyez la clé au serveur de clés . Sinon, distribuez la clé révoquée à vos collègues.

Signatures

Les signatures certifient et horodatent les documents. Si le document est modifié, la vérification de la signature échouera. Contrairement au chiffrement qui utilise des clés publiques pour chiffrer un document, les signatures sont créées avec la clé privée de l’utilisateur. Le destinataire d’un document signé vérifie ensuite la signature à l’aide de la clé publique de l’expéditeur.

Créer une signature

Signer un fichier

Pour signer un fichier, utilisez l’ –sign ou -s :

$ gpg --output doc .sig --sign doc

doc .sig contient à la fois le contenu compressé du fichier d’origine doc et la signature au format binaire, mais le fichier n’est pas chiffré. Cependant, vous pouvez combiner la signature avec le cryptage .

Clearsign un fichier ou un message

Pour signer un fichier sans le compresser au format binaire, utilisez:

$ gpg --output doc .sig --clearsign doc

Ici, le contenu du document d’origine et la signature sont stockés sous une forme lisible par l’homme dans doc .sig .

Faire une signature détachée

Pour créer un fichier de signature séparé à distribuer séparément du document ou du fichier, utilisez –detach-sig :

$ gpg --output doc .sig --detach-sig doc

Ici, la signature est stockée dans doc .sig , mais le contenu de doc n’est pas stocké dans celle-ci. Cette méthode est souvent utilisée dans la distribution de projets logiciels pour permettre aux utilisateurs de vérifier que le programme n’a pas été modifié par un tiers.

Vérifier une signature

Pour vérifier une signature, utilisez l’indicateur –verify :

$ gpg --verify doc .sig

où doc .sig est le fichier signé contenant la signature que vous souhaitez vérifier.

Si vous vérifiez une signature détachée, le fichier de données signé et le fichier de signature doivent être présents lors de la vérification. Par exemple, pour vérifier la dernière ISO de Arch Linux, vous feriez:

$ gpg --verify archlinux-version.iso.sig

archlinux-version.iso doit être situé dans le même répertoire.

Vous pouvez également spécifier le fichier de données signé avec un deuxième argument:

$ gpg --verify archlinux-version.iso.sig /path/to/archlinux-version.iso

Si un fichier a été crypté en plus d’être signé, décryptez- le simplement et sa signature sera également vérifiée.

gpg-agent

gpg-agent est principalement utilisé en tant que démon pour demander et mettre en cache le mot de passe du trousseau. Ceci est utile si GnuPG est utilisé depuis un programme externe comme un client de messagerie. gnupg est livré avec des sockets utilisateur systemd activés par défaut. Ces sockets sont gpg-agent.socket , gpg-agent-extra.socket , gpg-agent-browser.socket , gpg-agent-ssh.socket et dirmngr.socket .

  • Le gpg-agent.socket principal est utilisé par gpg pour se connecter au démon gpg-agent .
  • L’utilisation prévue de gpg-agent-extra.socket sur un système local consiste à configurer un transfert de socket de domaine Unix à partir d’un système distant. Cela permet d’utiliser gpg sur le système distant sans exposer les clés privées au système distant. Voir gpg-agent (1) pour plus de détails.
  • Le gpg-agent-browser.socket permet aux navigateurs Web d’accéder au démon gpg-agent .
  • gpg-agent-ssh.socket peut utiliser gpg-agent-ssh.socket pour mettre en cache les clés SSH ajoutées par le programme ssh-add . Voir l’ agent #SSH pour la configuration nécessaire.
  • Le dirmngr.socket démarre un démon GnuPG qui gère les connexions aux serveurs de clés.

Remarque: Si vous utilisez un emplacement non par défaut , vous devrez éditer tous les fichiers de socket pour utiliser les valeurs de gpgconf --list-dirs

Configuration

gpg-agent peut être configuré via le ~/.gnupg/gpg-agent.conf . Les options de configuration sont listées dans gpg-agent (1). Par exemple, vous pouvez modifier le cache ttl pour les clés non utilisées:

  ~ / .gnupg / gpg-agent.conf 

  default-cache-ttl 3600

Conseil: pour mettre en cache votre phrase secrète pendant toute la session, exécutez la commande suivante:
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXX
où XXXXX est la clé. Vous pouvez obtenir sa valeur lors de l’exécution de gpg --with-keygrip -K . La phrase secrète sera stockée jusqu’au redémarrage de gpg-agent . Si vous configurez la default-cache-ttl , elle aura la priorité.

Recharger l’agent

Après avoir modifié la configuration, rechargez l’agent à l’aide de gpg-connect-agent :

$ gpg-connect-agent reloadagent /bye

La commande devrait imprimer OK .

Cependant, dans certains cas, seul le redémarrage peut ne pas être suffisant, par exemple lorsque keep-screen a été ajouté à la configuration de l’agent. Dans ce cas, vous devez d’abord arrêter le processus en cours d’agent gpg puis vous pouvez le redémarrer comme expliqué ci-dessus.

pinentry

gpg-agent peut être configuré via la strophe pinentry-program pour utiliser une interface utilisateur pinentry particulière lorsque l’ utilisateur est invité à entrer une phrase secrète. Par exemple:

~/.gnupg/gpg-agent.conf

pinentry-program /usr/bin/pinentry-curses

Vous pouvez choisir d’autres programmes Pinentry - voir pacman -Ql pinentry | grep /usr/bin/

Conseil: Pour utiliser /usr/bin/pinentry-kwallet vous devez installer le package kwalletcli AUR .

N’oubliez pas de recharger l’agent après avoir modifié la configuration.

Cache des mots de passe

max-cache-ttl et default-cache-ttl définissent le nombre de secondes que gpg-agent doit mettre en cache les mots de passe. Pour entrer un mot de passe une fois par session, définissez-le sur une valeur très élevée, par exemple:

  gpg-agent.conf 

  max-cache-ttl 60480000
 default-cache-ttl 60480000

Pour la mise en cache des mots de passe en mode d’émulation SSH, définissez plutôt default-cache-ttl-ssh et max-cache-ttl-ssh , par exemple:

  gpg-agent.conf 

  default-cache-ttl-ssh 60480000
 max-cache-ttl-ssh 60480000

Phrase secrète sans surveillance (Unattended passphrase)

À partir de GnuPG 2.1.0, l’utilisation de gpg-agent et de pinentry est requise, ce qui peut entraîner une rupture de la compatibilité ascendante des phrases secrètes acheminées depuis STDIN à l’aide de l’option de ligne de commande –passphrase-fd 0 . Pour avoir le même type de fonctionnalité que les versions précédentes, il faut faire deux choses:

Commencez par éditer la configuration de gpg-agent pour autoriser le mode pinentry en boucle :

~/.gnupg/gpg-agent.conf

allow-loopback-pinentry

Rechargez l’agent s’il est en cours d’exécution pour que les modifications prennent effet.

Deuxièmement, l’application doit être mise à jour pour inclure un paramètre de ligne de commande permettant d’utiliser le mode de bouclage comme suit:

$ gpg --pinentry-mode loopback ...

… ou si cela n’est pas possible, ajoutez l’option à la configuration:

~/.gnupg/gpg.conf

pinentry-mode loopback

Remarque: l’ auteur en amont indique que la définition d’ pinentry-mode loopback dans gpg.conf dans gpg.conf peut interrompre une autre utilisation. L’utilisation de l’option de ligne de commande doit être préférée dans la mesure du possible. [5]

Agent SSH

gpg-agent a une émulation d’agent OpenSSH. Si vous utilisez déjà la suite GnuPG, vous pouvez envisager d’utiliser son agent pour mettre également en cache vos clés SSH . En outre, certains utilisateurs peuvent préférer la boîte de dialogue de saisie du code PIN fournie par l’agent GnuPG dans le cadre de la gestion de sa phrase secrète.

Définir SSH_AUTH_SOCK

Vous devez définir SSH_AUTH_SOCK afin que SSH utilise gpg-agent au lieu de ssh-agent . Pour vous assurer que chaque processus peut trouver votre instance gpg-agent quel que soit le type de shell utilisé, pam_env.

~/.pam_environment

SSH_AGENT_PID	DEFAULT=
SSH_AUTH_SOCK	DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
  • Remarque:
    • Si vous définissez manuellement SSH_AUTH_SOCK (comme dans cet exemple pam_env), n’oubliez pas que l’emplacement de votre socket peut être différent si vous utilisez un GNUPGHOME personnalisé. Vous pouvez utiliser l’exemple bash suivant ou remplacer SSH_AUTH_SOCK par la valeur de gpgconf --list-dirs agent-ssh-socket .
    • Si GNOME Keyring est installé, il est nécessaire de désactiver son composant ssh. Sinon, il écrasera SSH_AUTH_SOCK .

Sinon, compter sur Bash. Cela fonctionne également pour les emplacements de socket non standard:

~/.bashrc

unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi

Remarque: Le test impliquant la variable gnupg_SSH_AUTH_SOCK_by concerne le cas où l’agent est démarré en tant gpg-agent --daemon /bin/sh , auquel cas le shell hérite de la variable SSH_AUTH_SOCK du parent, gpg-agent [6] .

Configurez pinentry pour utiliser le TTY correct

Définissez également GPG_TTY et actualisez le TTY si l’utilisateur est passé en session X, comme indiqué dans gpg-agent (1) . Par exemple:

~/.bashrc

export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye >/dev/null

Ajouter des clés SSH

Une fois que gpg-agent est en cours d’exécution, vous pouvez utiliser ssh-add pour approuver les clés, en suivant les mêmes étapes que pour ssh-agent . La liste des clés approuvées est stockée dans le fichier ~/.gnupg/sshcontrol .

Une fois votre clé approuvée, vous obtiendrez une boîte de dialogue d’ identification à chaque fois que votre phrase secrète sera nécessaire. Pour la mise en cache des mots de passe, voir cache des mots de passe.

Utilisation d’une clé PGP pour l’authentification SSH

Vous pouvez également utiliser votre clé PGP en tant que clé SSH. Cela nécessite une clé avec la capacité d’ Authentication. L’utilisation d’une clé PGP pour l’authentification SSH offre divers avantages, notamment:

  • Réduction de la maintenance des clés, car vous n’aurez plus besoin de maintenir une clé SSH.
  • La possibilité de stocker la clé d’authentification sur une carte à puce. GnuPG détectera automatiquement la clé lorsque la carte est disponible et l’ajoutera à l’agent (vérifiez avec ssh-add -l ou ssh-add -L ). Le commentaire de la clé devrait ressembler à: openpgp:key-id ou cardno:card-id.

Pour récupérer la partie clé publique de votre clé GPG/SSH, exécutez gpg --export-ssh-key gpg-key

Sauf si vous avez votre clé GPG sur une carte-clé, vous devez ajouter votre clé à $GNUPGHOME/sshcontrol pour être reconnue en tant que clé SSH. Si votre clé est sur une keycard, son keygrip est ajouté implicitement à sshcontrol . Si non, obtenez la poignée de votre clé de cette façon:

$ gpg --list-keys --with-keygrip

sub   rsa4096 2018-07-25 [A]
      Keygrip = 1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7

Puis éditez sshcontrol comme ceci. L’ajout de la saisie au clavier est une action ponctuelle. vous n’aurez plus besoin de modifier le fichier, sauf si vous ajoutez des clés supplémentaires.

$GNUPGHOME/sshcontrol

1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7

Carte à puce (Smartcards)

Texte alternatif

GnuPG utilise *scdaemon comme interface avec votre lecteur de carte à puce. Veuillez vous reporter à la page de manuel scdaemon (1) pour plus de détails.*

GnuPG uniquement les configurations

Remarque: pour autoriser l’accès direct de scdaemon aux lecteurs de carte à puce USB, la dépendance optionnelle libusb-compat doit être installée.

Si vous n’envisagez pas d’utiliser d’autres cartes que celles basées sur GnuPG, vous devriez vérifier le paramètre reader-port dans ~/.gnupg/scdaemon.conf . La valeur “0” fait référence au premier lecteur de port série disponible et la valeur “32768” (valeur par défaut) au premier lecteur USB.

GnuPG avec pcscd (PCSC Lite)

pcscd (8) est un démon qui gère l’accès à une carte à puce (API SCard). Si scdaemon de GnuPG ne parvient pas à connecter directement la carte à puce (en utilisant, par exemple, son support CCID intégré), il se replie et tente de trouver une carte à l’aide du pilote PCSC Lite.

Pour utiliser pscsd, installez pcsclite et ccid . Ensuite, démarrez et/ou activez pcscd.service. Vous pouvez également démarrer et/ou activer pcscd.socket pour activer le démon si nécessaire.

Toujours utiliser pcscd

Si vous utilisez une carte à puce avec un pilote opensc (par exemple, des cartes d’identité de certains pays), vous devriez prêter une attention particulière à la configuration de GnuPG. Hors de la boîte, vous pourriez recevoir un message comme celui-ci lorsque vous utilisez gpg --card-status

gpg: selecting openpgp failed: ec=6.108

Par défaut, scdaemon essaiera de se connecter directement au périphérique. Cette connexion échouera si le lecteur est utilisé par un autre processus. Par exemple: le démon pcscd utilisé par OpenSC. Pour faire face à cette situation, nous devons utiliser le même pilote sous-jacent que opensc afin qu’ils puissent bien travailler ensemble. Afin de faire en sorte que scdaemon utilise pcscd, vous devez supprimer le reader-port de ~/.gnupg/scdaemon.conf , spécifier l’emplacement de la bibliothèque libpcsclite.so et désactiver ccid pour nous assurer que nous utilisons pcscd:

~/.gnupg/scdaemon.conf

pcsc-driver /usr/lib/libpcsclite.so
card-timeout 5
disable-ccid

Veuillez vérifier scdaemon si vous n’utilisez pas OpenSC.

Accès partagé avec pcscd

GnuPG scdaemon est le seul client pcscd populaire qui utilise l’indicateur PCSC_SHARE_EXCLUSIVE lors de la connexion à pcscd . D’autres clients, tels que OpenSC PKCS # 11, utilisés par les navigateurs et les programmes répertoriés dans Identification électronique utilisent PCSC_SHARE_SHARED qui permet un accès simultané à une seule carte à puce. pcscd pas un accès exclusif à la carte à puce tant que d’autres clients sont connectés. Cela signifie que pour utiliser les fonctionnalités de la carte à puce GnuPG, vous devez au préalable avoir à fermer toutes les fenêtres de votre navigateur ouvertes ou à effectuer d’autres opérations gênantes. GPGTools / MacGPG2 contient un correctif en dehors de l’arbre qui permet à scdaemon d’utiliser un accès partagé, mais les développeurs de GnuPG s’y pcscd car lorsqu’un client pcscd authentifie la carte à puce, certains autres clients pcscd malveillants pourraient effectuer des opérations authentifiées avec la carte sans vous. connaissance. Vous pouvez lire le fil complet de la liste de diffusion ici .

Si vous acceptez le risque pour la sécurité, vous pouvez utiliser le correctif de GPGTools / MacGPG2 git repo ou utiliser le package AUR gnupg-scdaemon-shared-access . Après avoir patché votre scdaemon vous pouvez activer l’accès partagé en modifiant votre fichier scdaemon.conf et en ajoutant son extrémité de ligne d’ shared-access .

Cartes multi-applets

Lors de l’utilisation de YubiKeys ou d’autres dongles USB multi-applets avec OpenSC PKCS # 11, des problèmes peuvent survenir lorsque OpenSC bascule votre Yubikey d’OpenPGP en applet PIV, rompant ainsi le scdaemon .

Vous pouvez résoudre le problème en obligeant OpenSC à utiliser également l’applet OpenPGP. Ouvrez le fichier /etc/opensc.conf , recherchez Yubikey et changez le driver = "PIV-II"; par driver = "openpgp"; . Si aucune entrée de ce type n’existe, utilisez pcsc_scan . Recherchez la réponse pour réinitialiser ATR: 12 34 56 78 90 AB CD ... Puis créez une nouvelle entrée.

/etc/opensc.conf

...
card_atr 12:23:34:45:67:89:ab:cd:... {
    name = "YubiKey Neo";
    driver = "openpgp"
}
...

Après cela, vous pouvez tester avec pkcs11-tool -O --login que l’applet OpenPGP est sélectionné par défaut. D’autres clients PKCS # 11 tels que les navigateurs doivent éventuellement être redémarrés pour que cette modification soit appliquée.

Trucs et astuces

Algorithme différent

Vous voudrez peut-être utiliser des algorithmes plus puissants:

~/.gnupg/gpg.conf

...

personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES

Dans la dernière version de GnuPG, les algorithmes par défaut utilisés sont SHA256 et AES, les deux étant suffisamment sécurisés pour la plupart des utilisateurs. Cependant, si vous utilisez une version de GnuPG antérieure à 2.1 ou si vous souhaitez un niveau de sécurité encore plus élevé, suivez les étapes ci-dessus.

Crypter un mot de passe

Il peut être utile de chiffrer un mot de passe pour qu’il ne soit pas écrit en clair sur un fichier de configuration. Un bon exemple est votre mot de passe email.

Commencez par créer un fichier avec votre mot de passe. Vous devez laisser une ligne vide après le mot de passe, sinon gpg renverra un message d’erreur lors de l’évaluation du fichier.

Puis lancez:

$ gpg -e -a -r <id-utilisateur>  fichier_mot_de_passe

-e est pour chiffrer, -a pour armor (sortie ASCII), -r pour l’ID utilisateur du destinataire.

Vous obtenez avec un nouveau fichier fichier_mot_de_passe.asc
Astuce: pass automatise ce processus.

Révoquer une clé

  • Attention:
    • Toute personne ayant accès à votre certificat de révocation peut révoquer votre clé, la rendant ainsi inutile.
    • La révocation de clé ne doit être effectuée que si votre clé est compromise ou perdue, ou si vous oubliez votre phrase secrète.

Les certificats de révocation sont générés automatiquement pour les clés nouvellement générées, même si l’utilisateur peut en générer une manuellement ultérieurement. Ceux-ci sont situés à ~/.gnupg/openpgp-revocs.d/. Le nom de fichier du certificat est l’empreinte de la clé à révoquer.

Pour révoquer votre clé, importez simplement le certificat de révocation:

$ gpg --import <empreinte> .rev

Renvoyez ensuite la clé qui a été révoquée au (x) serveur (s) de votre choix.

Changer le modèle de confiance

Par défaut, GnuPG utilise le Web of Trust comme modèle de confiance. Vous pouvez changer cela en Confiance lors de la première utilisation en ajoutant --trust-model=tofu lors de l’ajout d’une clé ou en ajoutant cette option à votre fichier de configuration GnuPG. Plus de détails sont dans “this email to the GnuPG list”.

Masquer tous les identifiants de destinataires

Par défaut, l’ID de clé du destinataire se trouve dans le message crypté. Cela peut être supprimé au moment du chiffrement pour un destinataire en utilisant hidden-recipient <user-id> . Pour le supprimer pour tous les destinataires, ajouter throw-keyids à votre fichier de configuration. Cela permet de masquer les destinataires du message et constitue une contre-mesure limitée contre l’analyse du trafic. (En utilisant un peu d’ingénierie sociale, toute personne capable de déchiffrer le message peut vérifier si l’un des autres destinataires est celui qu’il suspecte.) Du côté de la réception, cela peut ralentir le processus de déchiffrement car toutes les clés secrètes disponibles doivent être essayées ( par exemple avec --try-secret-key <user-id> )

Utilisation de caff pour la signature de clés

Pour permettre aux utilisateurs de valider les clés sur les serveurs de clés et dans leurs trousseaux de clés (c’est-à-dire, assurez-vous qu’ils appartiennent bien à qui ils prétendent appartenir), PGP / GPG utilise le Web of Trust . Les clés de signature permettent aux utilisateurs de se réunir à un emplacement physique pour valider les clés. Le protocole de signature de clé Zimmermann-Sassaman est un moyen de les rendre très efficaces. Ici, vous trouverez un article explicatif.

Pour faciliter le processus de signature des clés et d’envoi des signatures aux propriétaires après la signature de la clé, vous pouvez utiliser l’outil caff . Il peut être installé à partir du fichier AUR avec le package caff-git AUR .

Pour envoyer les signatures à leurs propriétaires, vous avez besoin d’un MTA en état de fonctionnement . Si vous n’en avez pas déjà un, installez msmtp .

Toujours montrer les identifiants et les empreintes digitales

Pour toujours afficher les identifiants de clé longs, ajouter keyid-format 0xlong à votre fichier de configuration. Pour toujours afficher les empreintes digitales complètes des clés, ajouter with-fingerprint à votre fichier de configuration.

Capacités personnalisées

Pour une personnalisation ultérieure, il est également possible de définir des fonctionnalités personnalisées pour vos clés. Les fonctionnalités suivantes sont disponibles:

  • Certifier (uniquement pour les clés principales) - permet à la clé de créer des sous-clés, obligatoire pour les clés principales.
  • Signer - permet à la clé de créer des signatures cryptographiques que d’autres peuvent vérifier avec la clé publique.
  • Chiffrer - permet à quiconque de chiffrer des données avec la clé publique, que seule la clé privée peut déchiffrer.
  • Authentifier - permet à la clé de s’authentifier avec divers programmes non-GnuPG. La clé peut être utilisée par exemple comme une clé SSH.

Il est possible de spécifier les capacités de la clé principale en lançant:

$ gpg --full-generate-key --expert

Et sélectionnez une option qui vous permet de définir vos propres capacités.

De manière comparable, pour spécifier des fonctionnalités personnalisées pour les sous-clés, ajouter l’indicateur --expert à gpg --edit-key

Dépannage

Pas assez d’octets aléatoires disponibles

Lors de la génération d’une clé, gpg peut rencontrer cette erreur:

Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!

Pour vérifier l’entropie disponible, vérifiez les paramètres du noyau:

$ cat /proc/sys/kernel/random/entropy_avail

Un système Linux en bonne santé avec beaucoup d’entropie disponible aura un rendement proche de 4 096 bits d’entropie. Si la valeur renvoyée est inférieure à 200, le système manque d’entropie.

Pour le résoudre, rappelez-vous que vous n’avez pas souvent besoin de créer des clés et de faire ce que le message suggère (par exemple, créer une activité de disque, déplacer la souris, modifier le wiki - tout cela créera une entropie). Si cela ne vous aide pas, vérifiez quel service utilise l’entropie et envisagez de l’arrêter pour le moment. Si ce n’est pas une alternative, voir Génération de nombres aléatoires # Alternatives

su

Lors de l’utilisation pinentry, vous devez disposer des autorisations appropriées du terminal utilisé (par exemple /dev/tty1). Cependant, avec su (ou sudo ), la propriété reste avec l’utilisateur d’origine, pas avec le nouvel utilisateur. Cela signifie que pinentry va échouer, même en tant que root. Le correctif consiste à modifier les autorisations du périphérique à un moment donné avant l’utilisation de pinentry (c’est-à-dire l’utilisation de gpg avec un agent). Si vous faites gpg en tant que root, changez simplement le propriétaire en root juste avant d’utiliser gpg:

# chown root /dev/ttyN  # where N is the current tty

puis changez-le après avoir utilisé gpg la première fois. L’équivalent est susceptible d’être vrai avec /dev/pts/. Remarque: Le propriétaire de tty doit correspondre à l’utilisateur pour lequel pinentry est en cours d’exécution. Faire partie du groupe tty ne suffit pas . Astuce: Si vous lancez gpg avec scriptil utilisera un nouveau tty avec le propriétaire correct:

# script -q -c "gpg --gen-key" /dev/null

L’agent se plaint de la fin du fichier

Le programme pinentry par défaut est /usr/bin/pinentry-gnome3, qui nécessite un bus de session DBus pour fonctionner correctement. Voir General troubleshooting#Session permissions pour plus de détails.

Vous pouvez également utiliser différentes options décrites dans le paragraphe pinentry

Autorisations de configuration KGpg

Il a été difficile pour kgpg d’ avoir accès aux options ~/.gnupg/. Un problème peut être dû à un fichier d’ options obsolète , voir le rapport de bogue

GNOME sur Wayland annule le socket de l’agent SSH

Pour les sessions Wayland, gnome-session met SSH_AUTH_SOCK à la prise standard gnome-keyring, $XDG_RUNTIME_DIR/keyring/ssh. Ceci remplace toute valeur définie dans les fichiers d’unité systemd ~/.pam_environmment.

Voir GNOME/Keyring#Disable keyring daemon components pour savoir comment désactiver ce comportement.

Mutt

Mutt peut ne pas utiliser gpg-agent correctement, vous devez définir une variable d’environnement GPG_AGENT_INFO (le contenu n’a pas d’importance) lors de l’exécution de mutt. Assurez-vous également d’activer correctement la mise en cache des mots de passe, voir paragraphe gestion des mots de passe.

Voir ce fil de discussion

Carte à puce non détectée

Votre utilisateur peut ne pas avoir l’autorisation d’accéder à la carte à puce, ce qui entraîne la projection de celle-ci card error, même si la carte est correctement installée et insérée.

Une solution possible consiste à ajouter un nouveau groupe scard incluant les utilisateurs ayant besoin d’accéder à la carte à puce.

Ensuite, utilisez les règles udev , similaires à celles-ci:

/etc/udev/rules.d/71-gnupg-ccid.rules

ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"

Il faut adapter VENDOR et MODEL en fonction du résultat de lsusb, l’exemple ci-dessus s’applique à une YubikeyNEO.

Voir également