Comment sauvegarder en toute sécurité une clé privée GPG?

J'ai trouvé un gestionnaire de mots de passe CLI très intéressant appelé pass . Pour l'utiliser, vous générez une paire de clés GPG2 et utilisez l'outil pour vous aider à stocker les mots de passe dans des fichiers chiffrés gpg2.

Pour crypter les fichiers (ajouter un nouveau mot de passe), il utilise la clé publique.

Pour décrypter les fichiers (récupérer un mot de passe stocké), il utilise la clé privée, qui nécessite un mot de passe.

Cela fonctionne très bien.

Maintenant que l'outil stocke tous mes mots de passe, je veux sauvegarder toutes ces données afin que si mon ordinateur tombe en panne, je ne serai pas verrouillé de tous mes comptes en ligne.

L'outil s'intègre parfaitement avec git, j'ai donc pu facilement pousser les fichiers .gpg vers mon dépôt git privé sur un autre ordinateur. D'après ce que je comprends, ces fichiers sont inutiles sans la clé privée pour les décrypter.

Ma question est la suivante: comment sauvegarder les clés privées et publiques de manière sûre, afin de pouvoir restaurer la "base de données" sur une autre machine si le besoin s'en fait sentir? Puis-je simplement stocker les clés publiques et privées dans mon référentiel git et les importer ultérieurement sur une autre machine? Ou est-il considéré comme une pratique dangereuse de stocker une clé privée dans un dépôt git local privé? Le dépôt git nécessite un mot de passe pour y accéder. La clé privée est cryptée et nécessite un mot de passe pour s'ouvrir - cela permet-il de la stocker en toute sécurité?

Le stockage d'une clé privée PGP dans un système de contrôle des révisions ne pose pas en soi de problème de sécurité significatif. Le stockage de la clé privée dans un référentiel git local, privé (non publié) ne devrait avoir aucune incidence significative sur la sécurité par rapport au stockage de la clé privée sur le même ordinateur mais en dehors de tout référentiel git.

Le seul problème auquel je peux penser qui vient du stockage de la clé privée d'une manière contrôlée par la version est que, à moins que vous ne puissiez en quelque sorte détruire les anciennes révisions, les changements de phrase secrète vous procurent beaucoup moins de protection qu'ils ne le pourraient autrement.

Ce qui peut avoir ses propres implications en matière de sécurité, c'est le stockage d'une clé privée de manière à ce que quelqu'un d'autre puisse accéder au fichier de clés. Dans une telle situation, tout ce qui se trouve entre un attaquant et votre clé est la force de sa phrase secrète.

Reconnaissant que la sécurité du stockage n'est pas parfaite, et plus encore dans l'environnement moderne où les gens sauvegardent régulièrement vers les services cloud (ce qui signifie littéralement «ordinateur de quelqu'un d'autre»), nous protégeons généralement nos clés secrètes avec des mots de passe. J'espère que, même si vous utilisez par exemple gpg-agent, vous faites de même.

L' essentiel est que, tant que votre phrase secrète est bonne, même le stockage d'une copie du fichier de clé crypté sur l'ordinateur de quelqu'un d'autre devrait être relativement sûr.

Cependant, c'est assez gros si: les mots de passe ou les phrases secrètes de la plupart des gens sont plutôt moche en ce qui concerne les tentatives informatisées de les déchiffrer. GnuPG va assez loin pour essayer de fonctionner aussi bien que possible avec ce que vous lui donnez, mais pour une protection solide des données, vous avez besoin d' une bonne phrase de passe et vous devez la définir avant d' importer la clé privée dans le référentiel git. Une fois la clé importée, un attaquant pourrait en principe attaquer n'importe quelle version de celle-ci, et s'il a des raisons de croire qu'une révision particulière a une phrase secrète de moindre qualité, elle ira probablement pour cela. Pour cette raison, assurez-vous de bien choisir la phrase secrète. J'ai rédigé une petite introduction sur la façon de gérer les mots de passe, y comprisdes suggestions sur la façon de choisir des mots de passe ou des phrases secrètes dont vous devez vous souvenir , qui peuvent vous être utiles.

J'ai envisagé une configuration similaire récemment. Avant d'aborder votre question, permettez-moi de souligner ce qui me dérange à ce sujet. Ceci est expliqué en détail ici . En bref, lorsque Pass appelle GPG, il effectue un cryptage asymétrique (RSA / EC) inutile sous le capot. Inutile - car il n'y a pas de partie non fiable ici.

C'est ennuyeux car la crypto asymétrique est moins pérenne que la crypto symétrique. Par exemple, la cryptographie asymétrique d'aujourd'hui est brisée par des ordinateurs quantiques suffisamment grands, qui n'existent pas encore. Plus généralement, la crypto asymétrique repose sur des "problèmes mathématiques" que nous ne savons pas résoudre, bien plus que la crypto symétrique.

Pour atténuer cette faiblesse, le moins que vous puissiez faire est de garder votre clé publique GPG utilisée avec Pass également, car par exemple, l'attaque quantique (potentielle) a besoin de cette clé publique: voir ici .

Sur votre question réelle, il n'est pas clair si vous avez l'intention de stocker le dépôt git (avec les mots de passe) publiquement ou en privé. Si vous souhaitez le garder privé, vous pouvez à peu près faire ce que vous voulez et réduire la sécurité de la clé privée GPG à celle du support sur lequel vous sauvegardez le référentiel. Cependant, cela pourrait devenir un problème de poulet et d'oeuf: si le dépôt est privé, comment le récupérer en cas de crash? En d'autres termes, en cas de "mauvais plantage", vous devez d' abord récupérer quelque chose . Donc, vous voudrez peut-être garder le dépôt git privé, mais sauvegardez la clé GPG de manière à pouvoir la récupérer en premier, indépendamment de toute autre chose.

Les solutions de sauvegarde hors ligne sont nombreuses, avocats, sous-sols, etc. voir ici . Mais les sous-sols ne sont pas pour tout le monde, alors laissez-moi vous suggérer une solution en ligne:

• Créez une phrase de passe super forte qui n'est pas destinée à être tapée pendant des années. Suggestion: faute d'orthographe longue et mémorable d'une phrase qui a une certaine signification personnelle, ou d'un livre qui ne manquera pas d'exemplaires si vous avez besoin de le rechercher.

• Créez une archive tar avec votre clé secrète GPG exportée et peut-être vos informations d'identification SSH.

• Chiffrer symétriquement avec votre mot de passe: gpg --symmetric --armor.

• Créez un compte d'hébergement git gratuit.

• Créez un référentiel public , qui peut être cloné sans informations d'identification.

• Mettez-y la balle de goudron chiffrée et blindée.

Pour le récupérer après un "mauvais crash":

• Démarrez une clé USB en direct.

• Cloner le dépôt public.

• gpg --decrypt.

La phrase secrète symétrique sera votre principale protection contre les zombies. Parfois, les gens ne vous accordent pas, ni au lecteur anonyme, le bénéfice du doute lorsqu'il s'agit de choisir des mots de passe. Mais avec une bonne phrase secrète, la cryptographie symétrique devrait être solide.

Lorsque vous exportez votre clé privée GPG, elle sera chiffrée avec sa propre phrase secrète. Les versions récentes de GPG ne permettront pas une exportation non cryptée. Vous pouvez utiliser ici votre mot de passe GPG "normal". N'oubliez pas qu'en cas de plantage, vous aurez besoin des deux mots de passe pour accéder à votre clé privée GPG.

Une autre option que j'utilise est: Imprimez votre clé sur papier .

Les détails sont dans la réponse liée. Les grands avantages sont les suivants: vous pouvez facilement le stocker où vous le souhaitez et vous pouvez vérifier s'il est toujours en bon état en le regardant simplement. Mais le plus grand avantage est que personne ne peut le pirater sans être physiquement à l'endroit où vous stockez votre sauvegarde et la prenez.

Une autre réponse à cette question est "hors ligne", c'est-à-dire le stocker dans un endroit sûr et non connecté à un ordinateur. Je garde une copie complète et non chiffrée de toutes mes clés sur une disquette (je le fais depuis longtemps, c'est maintenant une habitude) dans le coffre-fort de la banque. La raison pour laquelle je les garde non chiffrés sur les médias de la banque est qu'un scénario potentiel de "perte" de la clé est l'oubli de la phrase de passe (mes phrases de passe ont tendance à avoir beaucoup de ponctuation et d'orthographe étranges, et l'oubli d'une seule inutilisable). Je n'ai jamais eu à me remettre de cette copie, mais je prévois le pire.

De plus, il y a une révocation de clé dans les médias et une note indiquant à mes héritiers ce que j'en fais, au cas où je ne serais plus disponible.