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


Je suis nouveau à utiliser GnuPG et à essayer de comprendre comment l'utiliser au mieux. J'ai revu Explication courte et facile à comprendre de GPG / PGP pour des personnes non techniques?, mais la plupart des guides expliquent PGP avec une perspective de machine unique.

Je veux utiliser GnuPG sur trois appareils informatiques: un PC Linux, un ordinateur portable Linux et un téléphone Android.

Le cas d'utilisation fondamental est le cryptage / décryptage du courrier électronique géré par un service IMAP. Tous les périphériques ont donc besoin de la même clé privée pour le déchiffrement.

Je pense que mes choix sont les suivants:

  1. Copiez simplement toutes mes clés sur le trousseau de chaque appareil et utilisez principalement le mot de passe de la 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 ne réside que sur mon PC, ce dernier est distribué sur chaque appareil. Tant que mes appareils mobiles ne sont pas compromis, la clé jetable reste valide.

Je peux être trop paranoïaque et rendre cela plus compliqué que cela doit l'être, mais humourez-moi, s'il vous plaît. Je crois en ne mettant pas tous vos œufs dans le même panier.

La clé principale est supposée être mon identité numérique. Beaucoup d'efforts seront déployés pour renforcer la confiance autour de cette identité, et je souffrirai plutôt des inconvénients de ma paranoïa, que de perdre ma clé par négligence et de devoir instaurer la confiance autour d'une nouvelle clé maîtresse. (peut-être que ce n'est pas aussi grave que je le pense, mais je suis nouveau sur ce point).

Je suis plus susceptible de perdre mon ordinateur portable ou mon téléphone que mon PC. Si perte == compromis, alors je perdrais plutôt une paire de clés jetable (que je peux révoquer) que ma paire de clés maître. Je peux toujours accorder la confiance de ma clé maîtresse à une nouvelle clé jetable.

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

TL; DR

Un mot de passe est-il suffisamment protégé pour stocker mon maîtriser clé privée sur plusieurs appareils?

Mon plan pour l'option n ° 2 est-il réalisable? Ai-je eu 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 lors de l'utilisation de GnuPG pour un seul utilisateur sur plusieurs périphériques?


81
2017-08-25 23:55


origine




Réponses:


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

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) en utilisant une clé principale avec des sous-clés, et explique en outre comment supprimer la clé principale de n'importe quel 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:

  1. Ne compte pas principalement sur le 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 ne laisse bêtement mon lecteur flash branché ou que je connecte ce lecteur à un système compromis),

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

  4. Utilise la fonctionnalité de sous-clé de GnuPG. Qui semble un peu plus organisé que d'avoir un tas de clés en vrac sur votre porte-clés, oui?

Partie pertinente du wiki Subkey Subian

  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 en aurez peut-être besoin pour retourner à un endroit connu. (note: 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
    • Au gpg> rapide: addkey
    • Cela vous 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).
    • Choisissez une date d'expiration (vous pouvez faire pivoter vos sous-clés plus fréquemment 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
  3. Vous pouvez répéter ceci et créer également une sous-clé "RSA (encrypt only)", si vous le souhaitez.

  4. Copie maintenant $HOME/.gnupg à vos clés USB.

  5. Voici la partie délicate. Vous devez supprimer la clé principale privée et, malheureusement, GnuPG ne fournit pas un moyen pratique de le faire. Nous devons exporter la sous-clé, supprimer la clé privée et 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 identifiants de sous-clé suivis chacun 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érifier que gpg -K montre un sec# au lieu de juste 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 les éléments de clé privée de la sauvegarde, y compris la clé principale privée, resteront protégés par l’ancienne phrase secrète.)

Votre ordinateur est maintenant prêt à être utilisé normalement.

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

La dernière commande devrait maintenant lister votre clé privée avec sec et pas 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. [Paraphrase] et accentuation mien.

On pourrait être tenté d’avoir une seule sous-clé par machine afin d’échanger uniquement la sous-clé potentiellement compromise de cette machine. Si une seule sous-clé est utilisée sur toutes les machines, elle doit être échangée sur toutes les machines [lorsque cette seule sous-clé est ou est soupçonnée d'être compromise].

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


46
2017-08-26 01:28



Un bon Q & A, mais AFAIK, il y a toujours un problème avec cette configuration ... C'est génial pour la signature, mais pas pour le cryptage si vous ne voulez pas partager la même clé de cryptage entre vos différents appareils. message, gpg utilise par défaut la dernière clé enc non générée générée. Il n'est pas possible de forcer les expéditeurs à utiliser une sous-clé enc spécifique en fonction de l'UID (domicile ou travail, etc.). - KurzedMetal
C'est peut-être un problème. Ma plus grande préoccupation est de perdre le réseau de confiance que je construis autour de ma clé maîtresse (qui ne fait que signer). Bien sûr, la sous-clé de cryptage doit exister sur tous les périphériques que j'utilise pour lire les messages cryptés. Si ma clé de cryptage est compromise, le processus de récupération ne concerne que moi-même. au lieu de perdre ma clé de signature principale et de devoir demander / convaincre mon réseau de confiance de signer la nouvelle clé. Je n'avais pas l'intention de déplacer la sous-clé de cryptage dans mon coffre-fort. - Justin C


Comme quelqu'un qui n'aime pas les points de défaillance uniques (y compris les clés principales et notamment mots de passe), c'est comme ça que je le ferais. Cela 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 que cela pourrait probablement être associé à un travail cron et à quelques lignes de Bash.

Dans ce système, vous avez deux classes de paire de clés: clavier d'appareil et keypairs calendrier. Un clavier de l'appareil est généré pour l'utilisateur sur chaque périphérique et reste sur ce périphérique pendant toute sa durée de vie. UNE clavier horaire est généré par un serveur central à intervalles réguliers (mensuel, quotidien, horaire - dépend de la paranoïa que vous voulez être). La clé publique est annoncée publiquement (le serveur lui-même ayant sa propre paire de clés de périphériques avec laquelle signer), et la clé privée est distribuée chiffré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 ex. Avoir des appareils connectés directement au serveur.)

Pour signer des messages, vous devez utiliser la clé de périphérique de l'appareil sur lequel vous envoyez le message. Si quelqu'un souhaite vous envoyer un message, il peut le signer avec la clé de votre calendrier public actuel. (Ils devraient avoir un système automatisé pour suivre les annonces.) Vous pouvez ensuite lire leur message depuis n’importe quel appareil.

Pour lire les messages chiffrés plus anciens, les paires de clés d'anciennes versions temporelles sont sauvegardées sur chaque périphérique en fonction d'une stratégie appropriée (y compris le serveur générant une période de stockage des clés, si vous le souhaitez, 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 cependant autant de mots de passe au fil du temps que vous vous en sentez à l'aise).

Si un périphérique est volé ou compromis, vous pouvez utiliser un autre de vos périphériques de confiance pour créer un message signé publiquement, en vérifiant votre identité (par quelque moyen que ce soit, par exemple en notant que vous serez en 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 et toutes les clés temporelles auxquelles elle 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 politique de confiance vis-à-vis des clés de périphérique nouvellement annoncées doit suivre les règles de confiance actuelles. Je pense qu'une politique appropriée consiste à faire confiance au serveur de génération, à un périphérique mobile et à un appareil volumineux. le téléphone d'un utilisateur, un ordinateur de bureau et un VPS dans un cambriolage concerté avant que l'utilisateur ne le remarque.

Si votre serveur est compromis, il vous suffit de le révoquer selon la même procédure que pour tout autre périphérique compromis (éventuellement avec une politique plus stricte similaire à celle de l’ajout d’un nouveau périphérique) et d’utiliser un serveur entièrement sécurisé nouvelle paire de touches de l'appareil)


7
2017-08-02 00:33



La section de révocation est un peu trouble, car la révocation d’un appareil devrait être possible avec une annonce de tout autre appareil (afin de ne pas échouer si quelqu'un vole votre ordinateur portable et que votre téléphone ne peut pas contacter directement le serveur). être fait par un voleur (afin que les appareils doivent avoir une clé protégée par mot de passe pour la révocation). En cas de rapports contradictoires, toutes les clés doivent être temporairement méfiées jusqu'à ce qu'une vérification manuelle par un tiers puisse être effectuée. - Stuart P. Bentley
En fait, il peut être conseillé d’avoir un autre mécanisme pour révoquer les clés, en utilisant un mot de passe public fort qui est mis à jour manuellement (remplacé) de manière régulière, de cette façon, vous pouvez révoquer la clé sans dépendre de tout appareil (dites-vous que vous êtes seulement avec votre téléphone et que quelqu'un le vole), tant que vous gardez le mot de passe secret. - Stuart P. Bentley