Comment envoyer des clés privées en toute sécurité
Quelle est la méthode recommandée et les meilleures pratiques pour envoyer des clés privées et des clés privées SSL? Je pensais zipper les fichiers, puis utiliser gpg:
gpg -c thefile.Zip
Le problème devient alors comment envoyer la phrase secrète utilisée pour chiffrer à l'autre extrémité? Y a-t-il une meilleure solution?
TL; DR: les clés privées sont appelées privées pour une raison.
Vous pouvez sécuriser les clés privées en ne les transmettant pas du tout.
- Si vous avez un accès Shell au serveur sur lequel ils sont utilisés, vous les générez simplement in situ .
- Si le périphérique cible est trop faible/sous-alimenté pour générer les clés, il est également trop faible pour utiliser le chiffrement asymétrique (cela inclut les sources d'entropie). Bien sûr, il existe des périphériques câblés à mémoire limitée (cartes à puce, par exemple), mais vous pouvez utiliser un lien physiquement sécurisé pour y déplacer les clés sans être connecté à Internet. Un cas d'angle plutôt obscur est le cryptage asymétrique utilisé dans un appareil distant (lire: une sonde spatiale ou un satellite) mais les conditions ne sont probablement pas remplies en pratique (une clé compromise mais une autre liaison sécurisée toujours disponible).
- Si vous ne disposez pas d'un accès Shell sécurisé (SSH) au périphérique cible, vous ne pouvez généralement pas copier (SCP) en toute sécurité les fichiers. L'utilisation du courrier électronique pour déplacer les clés, même sous une forme cryptée, attire une attention injustifiée sur le message et laisse la trace dans peut-être des dizaines d'endroits sur Internet.
- L'envoi des clés signifie que les gens à l'autre bout du canal doit vous faire confiance et vous devez leur faire confiance. Ce n'est pas toujours une bonne proposition dans les entreprises et autres environnements à enjeux élevés (chaque partie peut forger des communications avec les clés privées en main).
EDIT: Pour le cas d'utilisation indiqué de clés privées pour un hébergeur, il est préférable de les générer sur place.
GPG peut vous permettre de les envoyer en toute sécurité sans avoir à envoyer de phrase secrète. Si la destination a sa propre clé GPG, vous pouvez crypter le fichier afin qu'eux seuls puissent l'ouvrir. Par exemple, gpg -e -r E9053BDA thefile.Zip me permettra uniquement d'ouvrir le fichier.Zip avec ma clé GPG sans qu'aucun de nous ne communique de phrase secrète. Alternativement gpg-Zip -e -r E9053BDA *.crt compressera et chiffrera tous les *.crt fichiers dans une seule commande.
Référence de la documentation:
Pour transmettre des clés en privé de manière sécurisée (ou toute clé/phrase secrète avec laquelle vous les avez chiffrées), vous n'avez aucune chance que d'utiliser un canal sécurisé et préétabli dès le départ.
Selon vos besoins et les possibilités disponibles, cela peut inclure
- envoyer des e-mails cryptés à une adresse pour laquelle vous disposez déjà de clés publiques de confiance, que ce soit OpenPGP ou S/MIME
- les envoyer par courrier (escargot), scellé si nécessaire
- voyager en personne, si nécessaire en comparant les pièces d'identité officielles
- téléchargement sécurisé sur une machine de confiance, par exemple en utilisant SSH
- envoyer un e-mail crypté, tout en transmettant la phrase secrète via un autre canal (téléphone, messagerie texte)
La méthode à utiliser dépend entièrement de vos besoins et des eve-droppers potentiels. Si les institutions gouvernementales et les agences secrètes sont des attaquants possibles, la plupart de ces moyens seront compromis dès le départ: ni le téléphone, ni le courrier postal ne seront plus sécurisés - et peut-être d'autres.
Si vous voulez simplement communiquer avec quelqu'un d'autre, les deux extrémités devraient générer leurs propres paires de clés, distribuer la clé publique tout en gardant la clé privée privée. Vous devez encore échanger des informations sur les clés publiques, par exemple l'empreinte digitale, via un canal de confiance préétabli comme décrit ci-dessus.
Tout d'abord, lisez ce que Deer Hunter a écrit ci-dessus. La meilleure façon d'envoyer en toute sécurité des clés privées est de ne jamais les envoyer en premier lieu. Arrêt complet.
Cela étant dit, il y a probablement des circonstances dans lesquelles vous pourriez légitimement avoir besoin de transférer des clés privées qui existent entre vos mains et et dans un emplacement vers les mains de quelqu'un d'autre dans un autre emplacement. Vous devez minimiser ces temps autant que possible , de préférence en marchant simplement avec le client qui en a besoin en générant les clés elles-mêmes. Mais il peut y avoir des moments où ce n'est pas pratique pour une raison quelconque (ou, plus probablement) ce n'est pas votre appel à faire. Alors, que faites-vous alors?
Eh bien, vous faites ce que les gouvernements et les entreprises technologiques font quand ils ont besoin de distribuer des clés de chiffrement très sensibles (si le plus souvent dans des scénarios de distribution de clés de clavier symétriques ou même ponctuelles, plutôt qu'avec des clés privées asymétriques) vers un emplacement distant: vous :
(1.) Chiffrez l'enfer des clés à transférer avant qu'elles ne quittent vos installations, en utilisant une clé "externe" unique créée uniquement pour un transfert, puis détruite. Si cette clé de cryptage de protection est générée à partir d'un mot de passe ou d'une phrase de passe, le mot de passe ou la phrase répond à des exigences de très haute résistance.
(2.) Utilisez un canal avec une bien meilleure sécurité que les réseaux polyvalents existants - alias Internet! - -pour obtenir le paquet chiffré à sa destination. La livraison physique d'un dispositif de mémoire contenant la clé chiffrée est le canal le plus simple mais pas toujours le plus pratique.
(3.) Gardez en votre possession la clé "externe" qui déverrouille le cryptage protecteur (ou un mot de passe/phrase de passe qui constitue la base de la clé) jusqu'à ce qu'il soit temps de transférer la ou les clés que vous souhaitez pour les transférer puis les décrypter chez le client. Cela signifie soit que vous vous présentez à l'événement de transfert de clé en personne pour déchiffrer le chiffrement de protection, soit que vous envoyez la clé qui déverrouille le chiffrement de protection à l'aide d'un autre canal électronique haute sécurité indépendant pour le mettre à la place du client au moment du déchiffrement.
(Pourquoi ne pas simplement passer au n ° 3 et envoyer la clé privée d'origine dont vous avez besoin pour passer au client par ce canal électronique le plus sécurisé? Parce que nous ne faisons confiance à aucun canal, pas même ce que nous pensons être celui qui a particulièrement- bonne sécurité, presque suffisante pour gérer les informations comme une clé privée. Nous faisons en sorte qu'un possible adversaire intercepte au moins deux canaux/mécanismes de transfert , et nous le faisons difficile d'intercepter quoi que ce soit d'utile de l'un, encore moins des deux.
Maintenant, tout cela semble ardu et compliqué. Mais en réalité, cela ne doit pas du tout nécessairement l'être non plus. (En supposant que nous soyons dans une situation commune, cette clé est importante, mais elle ne serait pas vraiment catastrophique si elle était compromise.) Par exemple, vous pourriez:
-Utilisez un périphérique USB protégé par cryptage matériel réputé - les options ne manquent pas - pour le transport. Écrivez-y la clé privée, verrouillez-la avec un mot de passe/code/phrase unique et conduisez-la dans la ville jusqu'à l'emplacement du client qui a besoin de la clé. Branchez-le lorsque vous y arrivez, déverrouillez-le et copiez la clé privée sur le système du client.
-Prenez une nouvelle clé USB ordinaire (non utilisée précédemment). Utilisez un logiciel dans lequel vous avez une grande confiance pour crypter la clé privée d'un fichier. Transférez le fichier vers l'USB. Ensuite, revérifiez USB - juste pour être sûr - que la seule chose qu'il contient est le paquet maintenant crypté. Faites un courrier recommandé ou FedEx pour le faire parvenir sur le site du client. À son arrivée, utilisez Off-the-Record ou une application de messagerie de sécurité similaire comme celle-ci pour transmettre la clé du cryptage de protection (ou le mot de passe/la phrase nécessaire pour la recréer) au client, qui décrypte et obtient la clé privée .
-Vous avez besoin de pouvoir distribuer à plusieurs reprises des clés à un client, à la demande et par voie électronique? Chiffrez la clé privée dans le fichier comme dans le dernier exemple. Avoir un serveur VPN ou SSH d'accès simple mais sécurisé que vous utilisez uniquement pour la distribution de fichiers de clés cryptés, que le client a des informations d'authentification pré-partagées pour se connecter et que vous gardez normalement déconnecté de tout accès distant. Lorsque le client vous appelle et vous indique qu'il est prêt à recevoir la clé, transférez-la de votre environnement de stockage interne vers le serveur. Activez les connexions à distance au serveur à partir de l'adresse IP du client. Le client se connecte et récupère le fichier de clé cryptée. Enfin, vous utilisez ensuite une application de messagerie haute sécurité (ou autre) pour transférer la clé de protection à votre client.
Beaucoup d'options. Il est vrai qu'il y a du travail dans chacun si vous voulez que le transfert soit bien sécurisé. Rejeté par la perspective de faire le travail? C'est compréhensible. Dans ce cas, voir le point # 1 (le point original fait par Deer Hunter): créez un arrangement technologique où vous n'avez pas du tout besoin de transférer des clés privées.
La bonne façon de procéder dans un canal non sécurisé consiste à utiliser une infrastructure à clé publique pour envoyer une clé privée.
1) Le destinataire reçoit une paire de clés publique/privée.
2) La partie émettrice utilisera alors la clé publique de la partie réceptrice pour crypter la clé privée et l'envoyer. Ce cryptage ne peut être décrypté que par la clé privée du destinataire que seul le destinataire connaît. De cette façon, la clé privée peut être envoyée de manière sécurisée sur un canal non sécurisé.
Il y a plus à considérer: comment le destinataire peut-il garantir l'identité de l'expéditeur? Pour ce faire, l'expéditeur doit également générer une paire de clés privée/publique.
L'expéditeur après avoir crypté "La clé privée" avec la clé publique du destinataire, l'expéditeur devra crypter le résultat avec sa clé privée pour générer le message final avant de l'envoyer. Après avoir reçu le message, le destinataire devra d'abord déchiffrer le message avec la clé publique de l'expéditeur. En cas de succès, il peut garantir que le message est authentique.
Soit K la clé privée doit être envoyée, E est le cryptage, D est le décryptage
Expéditeur: Message M = E (E (K, pub-k-receiver), pri-k-sender)
Récepteur: K = D (D (M, pub-k-sender), pri-k-receiver)
Le récepteur doit maintenant se demander si le message est récent, c'est-à-dire qu'il ne doit pas y avoir d'anciennes données qu'un tiers a interceptées et rejouées ultérieurement. Habituellement, un horodatage est intégré dans le message M pour résoudre ce problème.
Expéditeur: Message M = E (E (horodatage K +, pub-k-receiver), pri-k-sender)
Récepteur: K = D (D (M, expéditeur pub-k), récepteur pri-k) - horodatage
En règle générale, vous ne devez pas envoyer de clés privées, mais si vous devez absolument envoyer une clé privée, chiffrez-la avec la clé publique du destinataire. Gardez à l'esprit que votre destinataire doit être prêt à prendre le risque de conserver une copie de la clé privée.