La synchronisation de clés privées est-elle une bonne idée?
FAQ sur la sécurité d'Ubuntu One indique que Canonical chiffre les connexions et restreint l'accès aux données de l'utilisateur. Tout cela est très bien et je fais confiance à SSL pour les transactions bancaires en ligne et à d’autres choses plus précieuses que mes clés privées.
Cela dit, je suis très inquiet de placer mon ~/.ssh/id_dsa dans le nuage. De toute évidence, aucun système n'est totalement sécurisé. Une partie informée pourrait-elle alors quantifier les risques de manière pragmatique?
Le stockage Ubuntu One n'est pas crypté avec une clé cryptographique utilisateur
À l'instar de Dropbox, le magasin Ubuntu One n'est pas chiffré avec une phrase secrète spéciale. Il serait donc techniquement possible que quelqu'un accède à vos données, que ce soit par un employé indigne de confiance ou par une violation de la sécurité. Voir ce rapport de bogue sur le chiffrement de données de stockage UbuntuOne c'est toujours une liste de souhaits.
Je n’aurais donc pas synchronisé mon dossier ~/.ssh sur le cloud. Sauf si vous définissez un conteneur chiffré qui est ensuite envoyé sur le cloud, mais pour les clés ssh, ce n'est pas toujours pratique. Mais je vous donne encore des moyens pratiques de chiffrer vos données:
Plus d'informations
Ubuntu One utilise le cryptage pour la connexion (comme dit dans le fait), cela signifie que les données sont transmises sur une sorte de HTTPS. Vous pouvez utiliser une animation vraiment bien faite de ce qui est visible pour les indiscrets lors de l'utilisation de HTTPS , avec l'aimable autorisation de EFF (Electronic Frontier Foundation) .
En cliquant sur le bouton HTTPS de l'animation EFF, vous pourrez voir ce que tout le monde peut voir lorsque vous placez vos clés SSH dans un conteneur Dropbox ou Ubuntu One. Comme le dit l'animation, de nombreuses personnes sur site.com (par exemple, one.ubuntu.com) seraient en mesure de visualiser vos données (et bien plus encore). Même si vous utilisiez quelque chose comme Tor pour acheminer tout votre trafic, cela signifierait que les utilisateurs de site.com peuvent accéder aux données.
Vous devez donc chiffrer les données avant qu'elles ne quittent votre ordinateur. Donc, il arrive crypté sur site.com avec des identifiants inconnus. Bien sûr, vous devrez utiliser un mécanisme de cryptage fort pour empêcher les personnes de site.com de le lire très lentement.
Bien sûr, dans le cas d'une banque, vous ne pouvez pas chiffrer votre argent, car vous payez la banque pour le gérer à votre place. Vous n'avez donc pas d'autre choix que de faire confiance à la banque pour rendre son système informatique aussi sécurisé que ses coffres-forts physiques, de sorte que seul un petit sous-groupe d'employés (ceux qui gèrent votre compte) puissent voir et modifier vos données.
Il existe différentes mesures disponibles pour définir le risque, mais vous devez tenir compte de la valeur des données ou des systèmes auxquels la clé pourrait donner accès. Si la clé est perdue et qu'une entité peut l'utiliser pour y accéder, qu'est-ce qui sera compromis? La crainte sera-t-elle l'exposition de données confidentielles, la perte de données, la possibilité de compromettre des comptes d'un niveau administratif ou comptable, etc.? Si vous pouvez recréer des données non confidentielles et si vous avez des données confidentielles stockées de manière sécurisée (cryptées, par exemple), la tâche est moins urgente. Je pense qu'énumérer des solutions de contournement pour différentes faiblesses du système fait partie de la définition de votre risque global. De manière pragmatique, il est peu probable que le stockage de votre fichier .id_rsa pose problème, en particulier si vous faites pivoter les clés à un certain intervalle. Cela repose sur plusieurs hypothèses, mais néanmoins, je ne stockerais pas les données .ssh non chiffrées si cette option était viable.
Je suis assez inquiet de mettre mon ~/.ssh/id_dsa dans le nuage.
Eh bien, une solution est ce que je fais avec mes clés privées ssh et gpg avec Dropbox: les chiffrer dans une archive et supprimer les originaux "bruts". Chaque fois que nécessaire, je l'extrais temporairement puis je le supprime une fois terminé.
J'utilise p7Zip (utilise le cryptage AES-256), mais vous pourriez utiliser un certain nombre d'autres outils. Ainsi, tout ce qui est synchronisé est l'archive chiffrée. Même si le stockage en nuage est compromis, personne ne peut extraire les clés privées à moins de connaître la phrase secrète de l'archive.
Pour faciliter la vie des choses que vous faites fréquemment (par exemple, le déchiffrement gpg), vous pouvez avoir un simple script bash pour gérer la partie de déchiffrement/utilisation/suppression temporaire; il devrait également désactiver temporairement les démons de synchronisation afin que les clés extraites ne soient pas synchronisées par accident.
Vous pouvez enregistrer vos clés sur U1 à l'aide de l'outil de sauvegarde Deja-dup. Si vous définissez un mot de passe, les fichiers de sauvegarde sont automatiquement cryptés sur U1. Pas besoin de le faire manuellement.
Solution simple. Sorte de. Si vous ne pouvez pas utiliser quelque chose comme une clé USB, insérez une phrase secrète sur votre clé SSH. Authentification instantanée à deux facteurs (en quelque sorte). Vous n'avez même pas besoin de télécharger une nouvelle clé publique.