Façons de générer des clés symétriques et asymétriques
Nous utilisons une carte personnalisée basée sur Beaglebone Black et souhaitons utiliser le cryptage hybride pour le cryptage du fichier du firmware, c'est-à-dire symétrique pour le cryptage du gros fichier du firmware et asymétrique pour le cryptage du fichier de clé symétrique. Je me réfère au blog this pour une idée de cryptage hybride.
Maintenant, concernant la génération de la clé symétrique et des clés asymétriques (principalement dans le script Bash), j'ai les doutes suivants.
Clé symétrique
Méthode 1:
openssl Rand 128 > sym_keyfile.key
Doute 1:
Comment la longueur de la clé, par ex. 128, 192 ou 256, affectent le chiffrement et le déchiffrement? Faut-il seulement du temps pour le chiffrement et le déchiffrement?
Méthode 2:
cat /dev/urandom | head -n 128 > sym_keyfile.key
Méthode 3:
cat /dev/random | head -n 128 > sym_keyfile.key
Doute 2:
Quelle méthode est la plus aléatoire, la méthode 1 ou la méthode 2? J'ai tendance à penser que la méthode 2 est assez aléatoire et la page de manuel de random, urandom suggère d'utiliser urandom en cas de doute. Cependant, nous avons suffisamment d'entropie pour générer un nombre aléatoire plus sûr.
Doute 3:
Pouvons-nous demander à OpenSSL de prendre un nombre aléatoire de /dev/urandom?
Clé asymétrique
Génération de clé privée:
openssl genrsa -out keyfile.key 4096
Génération de clé publique à partir de la clé privée:
openssl rsa -in keyfile.key -pubout -out keyfile.pub
Maintenant, quand je lis l'aide d'OpenSSL concernant rsa, il dit:
La commande rsa traite les clés RSA. Ils peuvent être convertis entre différentes formes et leurs composants imprimés. Notez que cette commande utilise le format compatible SSLeay traditionnel pour le chiffrement par clé privée: les applications plus récentes doivent utiliser le format PKCS # 8 plus sécurisé à l'aide de l'utilitaire pkcs8.
Doute 4:
Est-ce que l'aide d'OpenSSL suggère d'utiliser pkcs#8 pour générer à la fois la clé privée et la clé publique ou uniquement pour générer la clé publique à partir de la clé privée?
Doute 5:
Suggérez-vous une autre méthode pour générer des clés asymétriques plus sécurisées?
Vous semblez demander une étude comparative sur les PRNG (générateurs de nombres pseudo-aléatoires) utilisés par défaut par OpenSSL et le noyau Linux. Cela pourrait très probablement remplir un volume plein de formules mathématiques, et pour aggraver OpenSSL et Linux PRNG ne sont pas indépendants puisque OpenSSL utilisera /dev/urandom comme graine par défaut , et il y a un travail en cours pour fournir une alternative PRNG pour Linux (vous pouvez voir Stephan Müller travailler sur le sujet ici et là et aussi ses discussions sur la liste de diffusion du noyau Linux).
Cependant, le fait est que dans la plupart des cas, les deux partageront les mêmes forces et faiblesses:
- Force: les deux sont du code mature et bien audité généralement accepté comme PRNG sécurisé cryptographiquement,
- Faiblesse: comme leur nom l'indique, ils sont tous deux pseudo générateur de nombres aléatoires, ce qui signifie qu'ils sont tous les deux des algorithmes déterministes qui, étant donné les mêmes graines, produiront la même sortie. L'imprévisibilité des nombres produits dépend donc directement de l'imprévisibilité des graines.
Donc, sur le plan de la sécurité, votre principale préoccupation ici peut ne pas être celle d'OpenSSL ou de /dev/urandom à utiliser (surtout quand on sait maintenant que le premier s'appuie sur le second en coulisse), mais pour assurer la qualité de l'ensemencement. En particulier, ce que vous mai voulez, c'est une ou plusieurs sources de TRNG (True Random Number Generator), c'est-à-dire. certains matériel composant spécialement conçu pour servir des données aléatoires imprévisibles adaptées à la cryptographie.
Cela vous garantira que la qualité des semences utilisées par les algorithmes mentionnés ci-dessus ne dépendra pas de facteurs externes tels que les E/S du système, la charge, etc. (lorsqu'elles seront disponibles, ces sources d'entropie seront très probablement toujours utilisées, mais fusionnées avec l'entrée TRNG). Dans la plupart des situations, cela aura plus d'impact sur vos atouts globaux que de choisir entre deux implémentations bien établies PRNG.
Maintenant pour répondre à vos doutes:
Doute 1:
Comment la longueur de la clé, par ex. 128, 192 ou 256, affectent le chiffrement et le déchiffrement? Faut-il seulement du temps pour le chiffrement et le déchiffrement?
Oui, c'est le cas: une clé plus grande nécessite plus de puissance de calcul pour crypter et décrypter. L'idée derrière cela est que, même si cela nécessitera plus d'efforts de la part des appareils légitimes connaissant la bonne clé, cela nécessitera également "exponentiellement" plus d'efforts de la part de tout attaquant potentiel.
Concernant la bonne longueur, vous trouverez déjà beaucoup de discussions sur ce site sur ce sujet ( comme ce joli tablea ), avec quelques cas généraux et certains tenant compte de certaines contraintes (comme les appareils embarqués qui ont puissance de calcul très limitée).
Doute 2:
Quelle méthode est la plus aléatoire, la méthode 1 ou la méthode 2? J'ai tendance à penser que la méthode 2 est assez aléatoire et la page de manuel de random, urandom suggère d'utiliser urandom au cas où on n'en serait pas sûr. Cependant, nous avons suffisamment d'entropie pour générer un nombre aléatoire plus sûr.
La méthode 3 peut se bloquer soudainement et pendant une durée indéterminée. Si ce n'est pas ce que vous voulez (et généralement vous ne le voulez pas), le choix est en effet entre les méthodes 1 et 2.
De là, le choix n'est qu'une question de préférence personnelle. Je dirais que la syntaxe utilisant OpenSSL est plus portable et plus simple, ce qui peut aider à éviter les bugs (par exemple en utilisant -n (nombre de lignes) au lieu de -c (nombre d'octets) comme paramètre de la commande head;)).
Doute 3:
Pouvons-nous demander à OpenSSL de prendre un nombre aléatoire dans/dev/urandom?
Il s'agit du comportement par défaut, mais si vous voulez vous assurer que cette documentation OpenSSL est votre amie et vous conseille d'ajouter le -Rand paramètre:
openssl Rand -Rand /dev/urandom 128 > sym_keyfile.key
Doute 4:
Est-ce que l'aide d'OpenSSL suggère d'utiliser pkcs # 8 pour générer à la fois la clé privée et la clé publique ou uniquement pour générer la clé publique à partir de la clé privée?
Comme indiqué dans le commentaire LvB, il s'agit de la façon dont les clés sont stockées, et non générées (c'est comme stocker un fichier dans un .Zip, .rar ou .tar.gz archive).
Si vous avez le choix, OpenSSL vous conseille en effet d'utiliser des formats modernes et standardisés au lieu du format SSLeay historique:
- Avec PKCS8, vous stockerez la clé privée dans un fichier (éventuellement crypté) et la clé publique/le certificat dans un autre fichier (texte en clair).
- Avec PKCS12, vous regrouperez les composants privés et publics dans un seul fichier (ce qui peut sembler plus pratique mais implique que si le
.p12le fichier est crypté, alors même le certificat public ne sera pas lisible sans déchiffrer le fichier au préalable).
Pratiquement, le choix se résumera souvent à ce qui est supporté par les applications qui utiliseront les clés. Sa documentation vous demandera souvent où et comment stocker le matériel clé.
Doute 5:
Suggérez-vous une autre méthode pour générer des clés asymétriques plus sécurisées?
J'ai déjà mentionné les appareils TRNG ci-dessus, et je vous conseillerais également de rester sur des terres connues en utilisant des implémentations logicielles matures et bien connues. Un logiciel implémentant de mauvais algorithmes ou de bons algorithmes mais avec une implémentation buggy peut également anéantir votre sécurité.
Et enfin, restez informé puisque des erreurs peuvent se produire partout , mais elles sont plus susceptibles d'être détectées et résolues rapidement dans des solutions bien établies que dans des solutions exotiques.
Plutôt que d'essayer d'implémenter le chiffrement hybride vous-même, je vous recommande d'utiliser openssl smime sous-commande. Une autre option consiste à utiliser gpg, ce qui est probablement beaucoup plus approprié que openssl pour signer et crypter des fichiers.
Tous les deux openssl smime et gpg effectue automatiquement le chiffrement hybride.