Comment gérer les clés GPG sur plusieurs systèmes?

Question

Je commence à utiliser GnuPG et à essayer de comprendre comment l'utiliser au mieux. J'ai examiné l'explication courte et facile à comprendre de GPG/PGP pour les non-techniciens , mais la plupart des guides expliquent PGP avec une perspective mono-machine.

Je souhaite utiliser GnuPG sur trois périphériques informatiques: un PC Linux, un ordinateur portable Linux et un téléphone Android.

Le cas d'utilisation fondamental est le cryptage/décryptage des e-mails gérés par un service IMAP. Tous les appareils ont donc besoin de la même clé privée pour le décryptage.

Je suppose que mes choix sont:

Il suffit de copier toutes mes clés dans le trousseau de chaque appareil et de s’appuyer principalement sur le mot de passe de clé privée pour la protection.
Créez une clé principale (avec --gen-key) pour représenter mon identité, puis créez une clé jetable distincte (à nouveau avec --gen-key) pour chiffrer/déchiffrer les e-mails et signer avec la clé principale. Le premier réside uniquement sur mon PC, le dernier est distribué à chaque appareil. Tant que mes appareils mobiles ne sont pas compromis, la clé jetable reste valide.

Je suis peut-être trop paranoïaque et je complique les choses, mais amusez-moi, s'il vous plaît. Je crois en ne mettant pas tous vos œufs dans le même panier.

La clé principale est censée être mon identité numérique. Beaucoup d’efforts seront consacrés à l’instauration d’un climat de confiance autour de cette identité, et je préférerais subir les inconvénients de ma paranoïa plutôt que de perdre ma clé par négligence et d’instaurer la confiance autour d’une nouvelle clé principale (peut-être que ce n'est pas le cas. t aussi mauvais que je pense, mais je suis nouveau à cela) .

Je suis plus susceptible de perdre mon ordinateur portable ou mon téléphone que mon PC. En cas de perte == compromis, je préfère perdre une paire de clés jetable (que je peux révoquer) que ma paire de clés principale. Je peux toujours accorder la confiance de ma clé principale à une nouvelle clé jetable.

Désolé pour la très longue question. :-)

TL; DR

Un mot de passe est-il une protection suffisante pour stocker ma clé privée maître sur plusieurs appareils?

Mon plan pour l'option n ° 2 est-il réalisable? Ai-je quelque chose de mal ou peut-il être amélioré?

Si l'option n ° 2 est une mauvaise idée, quelles sont les meilleures pratiques lorsque vous utilisez GnuPG pour un seul utilisateur sur plusieurs périphériques?

Justin C · Accepted Answer

Eh bien, c'est un peu gênant. Pendant une semaine, j'ai passé des heures à essayer de résoudre ce problème, et la réponse semble résider dans les sous-clés - un sujet abordé dans le manuel de GnuPG et FAQ.

En recherchant ce que sont les sous-clés et pourquoi elles pourraient être utilisées à la place de --gen-key, je suis tombé sur cette gemme: http://wiki.debian.org/subkeys .

Le wiki de Debian explique comment implémenter l'option 2 (voir OP) en utilisant une clé principale avec des sous-clés, et explique également comment supprimer la clé principale de tout système après l'avoir stockée sur un support de sauvegarde ( par exemple un lecteur flash). Les sous-clés peuvent ensuite être réparties entre mes trousseaux de clés sur chaque appareil.

Avantages:

Ne compte pas principalement sur mot de passe pour protéger la clé principale,
Si un système est compromis, la clé principale n'est pas immédiatement disponible (à moins que je laisse bêtement mon lecteur flash branché ou que je connecte ledit lecteur à un système compromis),
Ceci est une pratique mise en œuvre par l'équipe de développement Debian.
Utilise la fonctionnalité de sous-clé de GnuPG. Ce qui semble un peu plus organisé que d'avoir un tas de clés en vrac sur votre trousseau de clés, oui?

Partie pertinente du wiki de la sous-clé Debian

Faites des sauvegardes de vos fichiers GnuPG existants ($ HOME/.gnupg). Garde les en sécurité. Si quelque chose ne va pas au cours des étapes suivantes, vous aurez peut-être besoin de cette information pour revenir à un endroit réputé. (Remarque: umask 077 entraînera des autorisations restrictives pour la sauvegarde.)
- umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg
Créez une nouvelle sous-clé pour la signature.
- Trouvez votre clé ID: gpg --list-keys yourname
- gpg --edit-key YOURMASTERKEYID
- À l'invite gpg>: addkey
- Ceci demande votre mot de passe, tapez-le.
- Choisissez le type de clé "RSA (sign only)".
- Il serait sage de choisir une taille de clé de 4096 (ou 2048) bits.
- Choisissez une date d'expiration (vous pouvez faire pivoter vos sous-clés plus souvent que les clés principales ou les conserver pour la durée de vie de la clé principale, sans expiration).
- GnuPG créera (éventuellement) une clé, mais vous devrez peut-être attendre qu'elle obtienne assez d'entropie pour le faire.
- Enregistrez la clé: save
Vous pouvez répéter cette opération et créer une sous-clé "RSA (chiffrement uniquement)", si vous le souhaitez.
Maintenant, copiez $HOME/.gnupg sur vos clés USB.
Voici la partie délicate. Vous devez supprimer la clé principale privée. Malheureusement, GnuPG n’est pas un moyen pratique de le faire. Nous devons exporter la sous-clé, supprimer la clé privée et réimporter la sous-clé.
- Exportez les sous-clés: gpg --export-secret-subkeys YOURMASTERKEYID >secret-subkeys (pour choisir les sous-clés à exporter, spécifiez les ID de sous-clé suivis d'un point d'exclamation: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..])
- Supprimez votre clé secrète principale: gpg --delete-secret-key YOURMASTERKEYID
- Importer les sous-clés: gpg --import secret-subkeys
- Vérifiez que gpg -K affiche un sec# au lieu de sec pour votre clé privée. Cela signifie que la clé secrète n'est pas vraiment là. (Voir aussi la présence d'un paquet OpenPGP factice dans la sortie de gpg --export-secret-key YOURMASTERKEYID | gpg --list-packets).
- Modifiez éventuellement la phrase secrète protégeant les sous-clés: gpg --edit-key YOURMASTERKEYID passwd. (Notez que le matériel de clé privée de la sauvegarde, y compris la clé principale privée, restera protégé par l'ancienne phrase secrète.)

Votre ordinateur est maintenant prêt pour une utilisation normale.

Lorsque vous devez utiliser les clés principales, montez le lecteur USB crypté et définissez la variable d'environnement GNUPGHOME:

export GNUPGHOME=/media/something gpg -K

ou utilisez l'argument de ligne de commande --home:

gpg --home=/media/something -K

Cette dernière commande devrait maintenant lister votre clé privée avec sec et non sec#.

Plusieurs sous-clés par machine contre une seule sous-clé pour toutes les machines

Extrait du wiki de la sous-clé Debian. Initialement noté dans les commentaires. [Paraphrasant] et l'emphase mine.

On pourrait être tenté d'avoir une sous-clé par machine de sorte que vous n'ayez besoin que d'échanger la sous-clé potentiellement compromise de cette machine. Si une seule sous-clé est utilisée sur toutes les machines, elle doit être remplacée par toutes les machines [lorsque cette sous-clé est ou est supposée être compromise].

Mais cela ne fonctionne que pour la signature de sous-clés . Si vous avez plusieurs sous-clés de chiffrement, il est dit que gpg ne chiffre que pour la sous-clé de chiffrement la plus récente et non pour toutes les sous-clés de chiffrement connues et non révoquées.

Stuart P. Bentley · Answer

En tant que personne qui n'aime pas les points de défaillance uniques (y compris les clés principales et , en particulier les mots de passe), c'est ce que je ferais. Il permet aux appareils de fonctionner via un réseau de confiance, tout en permettant une identité décentralisée.

Je ne sais pas s'il existe déjà un système pour cela, mais je pense qu'il pourrait probablement être scanné avec un travail cron et quelques lignes de Bash.

Dans ce système, vous avez deux classes de paires de clés: paires de clés de périphérique et paires de clés temporelles . Une paire de clés de périphérique est générée pour l'utilisateur sur chaque périphérique et reste sur celui-ci pendant toute sa durée de vie. Une paire de clés de temps est générée par un serveur central à intervalles réguliers (tous les jours, tous les jours, toutes les heures - dépend du degré de paranoïa que vous souhaitez être). La clé publique est annoncée publiquement (le serveur lui-même disposant de sa propre paire de clés de périphérique à signer) et la clé privée est distribuée cryptée avec la clé publique de chaque périphérique censé avoir accès à cette clé. (Cette distribution doit être aussi privée que possible, par exemple en faisant en sorte que les périphériques se connectent directement au serveur.)

Pour signer des messages, vous utiliseriez la clé de l’appareil depuis lequel vous envoyez le message. Si quelqu'un veut vous envoyer un message, il peut le signer avec votre clé de calendrier public actuelle. (Ils devraient avoir un système automatisé pour suivre les annonces.) Vous pouvez ensuite lire leur message à partir de n’importe quel appareil.

Pour lire des messages cryptés plus anciens, les paires de clés temporelles plus anciennes sont sauvegardées sur chaque appareil selon une stratégie appropriée (y compris le serveur générant la paire de clés temporelle, si vous le souhaitez - là encore, selon votre niveau de paranoïa), des paires de clés protégées par mot de passe protégeant les anciennes clés (avec le nombre de mots de passe que vous gardez au fil du temps).

Si un appareil est volé ou autrement compromis, vous pouvez utiliser un autre de vos appareils de confiance publique pour créer un message signé publiquement, vérifiant votre identité (par quelque moyen que ce soit, par exemple, en notant que vous serez à une réunion publique et/ou demander à un ami de confiance de vous vérifier en personne) et révoquer la clé de périphérique compromise ainsi que toutes les clés de délai auxquelles il avait accès. Lors de la révocation de la clé, vous supprimez également le périphérique volé de la liste des périphériques de confiance du serveur (avec un mot de passe et votre clé de périphérique de confiance).

La stratégie de confiance des clés de périphérique récemment annoncées doit suivre les mêmes règles de confiance. Je pense qu'une stratégie appropriée consiste à faire confiance au serveur générateur, à un périphérique mobile et à un périphérique volumineux et lourd, car il est difficile de voler/infiltrer le téléphone d’un utilisateur, un ordinateur de bureau et un serveur VPS dans un hold-up concerté avant que l’utilisateur ne le remarque.

Si votre serveur est compromis, vous le révoquez simplement en suivant la procédure décrite pour tout autre périphérique compromis (éventuellement avec une stratégie plus stricte similaire à celle permettant d'ajouter un nouveau périphérique), et utilisez un serveur entièrement sécurisé à nouveau (avec un nouveau nouvelle clé de l’appareil).