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, il vous suffit de les générer 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 un cryptage 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 sont peu susceptibles d'être remplies dans la pratique (une clé compromise mais un autre lien sécurisé 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 en toute sécurité (SCP) les fichiers. L'utilisation du courrier électronique pour déplacer les clés, même sous forme chiffrée, attire indûment l'attention sur le message et laisse la trace dans des dizaines d'endroits sur Internet.
• L'envoi des clés signifie les personnes à l'autre bout de la ligne. la chaîne doit vous faire confiance et vous devez lui faire confiance. Ce n'est pas toujours une bonne proposition dans les entreprises et autres environnements à enjeux élevés (l'une ou l'autre des parties peut établir 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 vaut toujours mieux 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 dispose de sa propre clé GPG, vous pouvez crypter le fichier afin qu’elles seules puissent l’ouvrir. Par exemple, gpg -e -r E9053BDA thefile.zip me permettra seulement d'ouvrir thefile.zip avec ma clé GPG sans qu'aucun de nous ne communique jamais de mot de passe. Sinon, gpg-zip -e -r E9053BDA * .crt compressera et cryptera tous les fichiers * .crt en une seule commande.

Documentation Référence:

• Page du manuel gpg
• Page du manuel gpg-zip

Pour transmettre des clés de manière privée de manière sécurisée (ou des clés / phrases de passe avec lesquelles vous les avez cryptées), vous n'avez aucune chance que d'utiliser un canal sécurisé et de confiance préétabli dès le début.

En fonction de vos besoins et les possibilités disponibles, cela peut inclure

• l'envoi de courriers cryptés à une adresse pour laquelle vous avez déjà des clés publiques de confiance, peu importe si OpenPGP ou S / MIME
• envoi les utiliser par courrier (escargot), scellé si nécessaire
• voyager en personne, si nécessaire comparer les identifiants officiels
• téléchargement sécurisé vers une machine de confiance, par exemple en utilisant SSH
• envoyer un e-mail chiffré, tout en transmettant la phrase de passe via un autre canal (téléphone, messagerie texte)

La méthode à utiliser dépend entièrement de vos besoins et des éventuels problèmes de veille. Si les institutions gouvernementales et les agences secrètes sont des attaquants potentiels, la plupart de ces moyens seront compromis dès le début: ni le téléphone, ni le courrier postal ne seront plus sécurisés - et peut-être d'autres.

Si vous le souhaitez simplement communiquer avec quelqu'un d'autre, les deux extrémités doivent générer leurs propres paires de clés, distribuer la clé publique tout en gardant la clé privée privée. Vous devez toujours é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. Arrêt complet.

Cela étant dit, il y a probablement des circonstances dans lesquelles vous pourriez légitimement avoir besoin de transférer certaines clés privées qui existent entre vos mains & et dans un endroit aux mains de quelqu'un d'autre dans un autre endroit . Vous devez minimiser ces temps autant que vous le pouvez , de préférence en accompagnant simplement le client qui en a besoin en générant les clés eux-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 symétriques ou même ponctuelles , plutôt qu'avec des clés privées asymétriques) vers un emplacement distant: vous:

(1.) Cryptez l'enfer de la / des clé (s) à transférer avant elle / ils quittez jamais vos installations, en utilisant une clé «externe» unique créée uniquement pour un transfert puis détruite. Si cette clé de chiffrement 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 sécurité bien meilleure que les réseaux à usage général existants - c'est à dire Internet! - pour obtenir le paquet chiffré vers sa destination. La livraison physique d'un dispositif de mémoire contenant la clé cryptée est le canal le plus simple mais pas toujours le plus pratique.

(3.) Conservez la clé "externe" qui déverrouille le cryptage de protection (ou un mot de passe / une phrase de passe qui forme la base de la clé) en votre possession jusqu'à ce qu'il soit temps de transférer la clé / s vous souhaitez les transférer, puis les déchiffrer à l'emplacement du client. Cela signifie soit que vous soyez à l'événement de transfert de clé en personne pour décrypter le cryptage de protection, soit que vous envoyez la clé qui déverrouille le cryptage de protection en utilisant un autre canal électronique haute sécurité indépendant pour l'amener chez le client au moment du décryptage.

(Pourquoi ne pas simplement passer au n ° 3 et envoyer la clé privée d'origine dont vous avez besoin pour passer au client via ce canal électronique de plus haute sécurité? Parce que nous ne faisons confiance à aucun canal, pas même à ce que nous pensons être celui qui a une sécurité particulièrement bonne, presque suffisante pour gérer les informations comme une clé privée. Nous permettons à un adversaire possible d'intercepter au moins deux canaux / mécanismes de transfert , et nous rendons difficile d'intercepter quoi que ce soit d'utile de l'un ou l'autre , sans parler des deux.

Maintenant, tout cela semble ardu et compliqué. Mais en réalité, cela n'a pas du tout besoin de l'être non plus. (En supposant que nous sommes dans un commun, cette-clé-est -importante-mais-elle-ne-serait-pas-vraiment-catastrophique-si-elle-était-compromise.) Par exemple, vous pourrait:

-Utiliser un périphérique USB protégé par cryptage matériel bien considéré - il ne manque pas d'options - pour le transport. Écrivez une clé privée à cela, verrouillez-la avec un mot de passe / code / phrase fort unique et conduisez-la à travers 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.

-Attrapez une nouvelle clé USB ordinaire (non utilisée auparavant). Utilisez un logiciel en lequel vous avez une grande confiance pour crypter la clé privée dans un fichier. Transférez le fichier sur la clé USB. Ensuite, vérifiez à nouveau USB - juste pour être sûr - que la seule chose qui s'y trouve est le paquet maintenant crypté. Faites un courrier recommandé ou FedEx pour le faire parvenir sur le site du client. Quand il arrive, utilisez Off-the-Record ou une application de messagerie de sécurité similaire comme elle pour transmettre la clé au cryptage de protection (ou mot de passe / phrase nécessaire pour le régénérer) au client, qui déchiffre ensuite & obtient la clé privée .

-Besoin de pouvoir distribuer à plusieurs reprises des clés à un client, à la demande et par voie électronique? Cryptez la clé privée dans le fichier comme dans le dernier exemple. Disposez d'un VPN ou d'un serveur d'accès SSH simple mais sécurisé que vous n'utilisez que pour la distribution de fichiers de clés cryptés, que le client a des informations d'authentification pré-partagées auxquelles se connecter et que vous gardez normalement déconnecté de tout accès distant. Lorsque le client vous appelle et vous dit 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 saisit le fichier de clé crypté. Enfin, vous utilisez ensuite une application de messagerie haute sécurité (ou autre) pour transférer la clé de protection à votre client.

De nombreuses options. Il est vrai qu'il y a du travail dans chacun si vous voulez que le transfert soit bien sécurisé. Découragé par la perspective de faire le travail? C'est compréhensible. Dans ce cas, voir le point 1 (le point original de 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 faire cela dans un canal non sécurisé est d'utiliser une infrastructure à clé publique pour envoyer une clé privée.

1) Le destinataire génère une paire de clés publique / privée.

2) L'expéditeur utilisera ensuite la clé publique du destinataire 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é privée / publique.

L'expéditeur après avoir chiffré "La Clé Privée" avec la clé publique du destinataire, l'expéditeur devra chiffrer le résultat avec sa clé privée pour générer le message final avant l'envoi. 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 frais, c'est-à-dire qu'il n'y a pas 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 (K + horodatage, pub-k-receiver), pri-k-sender)

Récepteur: K = D (D (M, pub-k-sender), pri-k-receiver) - horodatage

En général, vous ne devriez pas envoyer de clés privées, mais si vous devez absolument envoyer une clé privée, cryptez-la avec la clé publique du destinataire. Gardez à l’esprit que votre destinataire doit être prêt à prendre le risque que vous puissiez conserver une copie de la clé privée.

Je vais répéter ce que les autres ont dit en premier, puis ajouter un autre point.

Ce qui a été dit:

Ne partagez que les clés publiques si possible - c'est ainsi que fonctionne la sécurité.

Si les clés privées doivent être partagées, ne les envoyez pas via une infrastructure partagée (notez que les téléphones portables et les lignes fixes ne sont pas complètement sûrs).

Si les clés doivent être envoyées via une infrastructure partagée , cryptez correctement et utilisez des canaux sécurisés. Pensez à envoyer une pièce via deux canaux différents.

De préférence si les clés partagées ne sont pas utilisées trop longtemps.

Et une nouvelle pensée:

Considérez de plus en utilisant la stéganographie pour les communications avec les personnes avec lesquelles vous interagissez souvent et partagez des photos, ce sera plus difficile à repérer.

Mais pour répéter, les systèmes comme Bitcoin sont puissants car les clés privées ne sont pas partagées, ce chaque compte doit être rompu individuellement. Les systèmes avec des clés partagées exposent tout le monde à des pauses uniques ou à des erreurs uniques dans le groupe.

Envoyez la clé privée d'un service de messagerie anonyme à une adresse de service de messagerie jetable de 48 heures. Il vous suffit de publier publiquement votre adresse e-mail jetable avec la clé publique à la vue de tout le monde et d'attendre que votre expéditeur-partenaire vous envoie le PK dans les 48 heures. Après 48 heures, le jetable s'évapore. Personne n'a besoin de faire confiance à personne. Les deux parties pourraient toujours utiliser le même PK pour tous les messages futurs sans jamais recommencer cette transaction. Cependant, c'est moins sûr de le faire de cette façon.