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

Je commence à utiliser GnuPG et à essayer de comprendre comment l'utiliser au mieux. J'ai examiné l' explication courte, facile à comprendre de GPG / PGP pour les personnes non techniques? , 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:

1. 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.

2. 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 aussi grave que moi). 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 une protection suffisante pour stocker mon maître clé privée sur plusieurs périphériques?

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 2 est une mauvaise idée, quelles sont les meilleures pratiques lors de l'utilisation de GnuPG pour un seul utilisateur sur plusieurs périphériques?

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 que le manuel de GnuPG et la FAQ occultent.

Tout 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 ce joyau: http://wiki.debian.org/subkeys .

Le wiki de Debian explique comment implémenter l'option n ° 2 (voir OP) à l' aide d'une clé principale avec 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, une clé USB). Les sous-clés peuvent ensuite être réparties entre mes trousseaux de clés sur chaque appareil.

Avantages:

1. Ne compte pas principalement sur mot de passe pour protéger la clé principale,

2. 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),

3. Ceci est une pratique mise en œuvre par l'équipe de développement Debian.

4. 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

1. Faites des sauvegardes de vos fichiers GnuPG existants ($ HOME / .gnupg). Protège-les. 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

2. Créez une nouvelle sous-clé pour la signature.

   • Trouvez votre identifiant de clé: gpg --list-keys yourname
   • gpg --edit-key YOURMASTERKEYID
   • A l' gpg>invite: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.
   • Sauvegarder la clé: save

3. Vous pouvez répéter cette opération et créer une sous-clé "RSA (chiffrement uniquement)", si vous le souhaitez.

4. Maintenant, copiez $HOME/.gnupgsur vos clés USB.

5. 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é.

   • Exporter les sous - clés: gpg --export-secret-subkeys YOURMASTERKEYID >secret-subkeys(choisir qui sous - clés pour exporter, spécifiez les ID de chaque sous - clé suivi avec un point d'exclamation: gpg --export-secret-subkeys SUBKEYID! [SUBKEYID! ..])
   • Retirez votre clé secrète principale: gpg --delete-secret-key YOURMASTERKEYID
   • Importer les sous-clés: gpg --import secret-subkeys
   • Vérifiez que gpg -Kmontre un sec#au lieu de seulement secpour 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).
   • Vous pouvez également modifier le mot de passe 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 chiffré 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 secet 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 mon emphase .

On pourrait être tenté d'avoir une seule sous-clé par machine, de sorte qu'il suffit 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 cryptage, il est dit que gpg ne crypte que pour la sous - clé de cryptage la plus récente et non pour toutes les sous-clés de cryptage connues et non révoquées.

En tant que personne qui n'aime pas les points de défaillance uniques (y compris les clés principales et surtout 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: les paires de clés de périphérique et les paires de clés de calendrier . 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 ce périphérique 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 (mensuel, quotidien, horaire - dépend de la 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 avec laquelle 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 anciennes sont sauvegardées sur chaque appareil conformément à une stratégie appropriée (y compris le serveur générateur de clés, si vous le souhaitez - encore une fois, en fonction de 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 actuelles. 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 ou totalement (avec nouvelle clé de l’appareil).