Conséquences pour la sécurité du stockage du fichier de clés dans un dépôt public

Quelles sont les implications pour la sécurité du stockage du fichier de clés dans un dépôt public, avec le code source?Conséquences pour la sécurité du stockage du fichier de clés dans un dépôt public

La raison pour laquelle il est stocké dans le dépôt est la commodité. Il n'y a pas de dépendances quand vous faites un 'git pull ou clone' et vous construisez sur votre machine locale (par exemple avec sbt sign-release): vous fournissez simplement le mot de passe lorsque vous y êtes invité et une application signée est créée. Disons que je le protège avec un mot de passe de 20 caractères (lettres, chiffres, caractères spéciaux, etc.) obtenu à partir d'un programme générateur de mot de passe. Je pense qu'il serait infaisable pour un attaquant de monter une attaque et d'avoir accès à la clé privée dans le keystore. J'aimerais que les experts en sécurité/cryptographie se demandent s'il est sécuritaire de stocker des fichiers de clés dans un dépôt public.

Merci

Source

2010-10-19 Babu Srinivasan

@ babu-srinivasan: C'est possible car il y a des limites sur les tentatives après que quelqu'un télécharge et fasse une attaque hors ligne. Quoi qu'il en soit, les clés privées sont assignées à une entité particulière (afin qu'elle puisse aussi être utilisée pour l'authentification d'identité) et vous n'envoyez pas de carte d'identité/d'accès par la poste (comme je le pense). – yadab

Je suppose que vous vouliez dire "pas de limite sur les tentatives". Mon point est que c'est un mot de passe généré aléatoirement et donc seulement une attaque par force brute est possible. L'attaquant ne connaît pas la longueur du mot de passe. Donc, même si l'attaquant peut vérifier un milliard de mots de passe en une seconde, il faudra des millions d'années pour trouver le mot de passe. La question est, y at-il des attaques de force non-brute pour ce problème. –

@ babu-srinivasan: oui, je voulais dire «pas de limite aux tentatives». Merci. Mais la longueur du mot de passe peut rendre la tâche d'obtenir de mot de passe à la clé très longue pour un attaquant après que tout est basé sur la longueur de la clé, vous pouvez avoir AES-256. Maintenant, il n'est pas facile de casser AES en force brute et ce qui est très difficile. Mais dans le processus, vous réduisez la sécurité de 1024 longueur de clé (votre clé RSA rpivate) à 256 force de clé (aes-256). Becuase une longueur de clé de 256 protège 1024 clé de longueur ?? Ai-je tort? – yadab

keyring Cacher et le code appartient à "la sécurité par l'obscurité". Les directeurs En théorie la sécurité devrait être loin de ce concept, mais dans ce genre de scénario, la réponse pourrait être qu'exposer des données sensibles sur un référentiel public pourrait vous exposer à des attaques qui agissent sur la vulnérabilité spécifique des keyrings ou l'implémentation de l'algorithme sécurisé. bientôt. Je veux dire que tous les algorithmes que vous utilisez sont sûrs à 100% et Keyrings aussi, mais la version des keyrings pourrait contenir une vulnérabilité ou un bug spécifique ou une mauvaise implémentation de l'algorithme sécurisé. Par conséquent, exposer ces données sur un référentiel public pourrait vous exposer à un pirate informatique qui veut seulement prouver ses compétences.

Source

2010-10-22 05:39:29 robob

Robob, la sécurité par l'obscurité ne s'applique pas ici. Cela s'applique où vous dépendez de l'attaquant ne sachant pas ce qu'est le crypto algo. Ce n'est pas le cas ici. L'algorithme est bien connu. –

Je ne suis pas d'accord avec vous ou avec ce concept restreint de "Sec through Obsc". Je ne vous montre pas le plan pour une attaque militaire ou je ne vous dis pas où est la clé, pour moi est "Sec Through Obsc" :-) – robob

De toute façon le problème en est un autre, le problème est que déplacer ces keyrings à un public endroit pourrait exposer ces données à un grand nombre d'attaques .. – robob

J'ai fait quelques recherches. J'ai trouvé l'information sur JKS algo dans How does keytool protect keys? et JKS protection (http://metastatic.org/source/JKS.html). Sur cette base, je réponds à ma propre question: Je suis arrivé à la conclusion qu'avec mon mot de passe aléatoire de 20 caractères, l'utilisation d'un sel aléatoire de 20 octets et SHA1 (mot de passe, sel) pour obtenir un flux aléatoire de longueur égale à la longueur de clé de 2048, qui est XORed avec la clé privée, qu'il est impossible de calculer dans un avenir prévisible pour extraire la clé privée.

Source

2010-10-23 20:52:43

Conséquences pour la sécurité du stockage du fichier de clés dans un dépôt public

Répondre

Questions connexes