Pourquoi ne devrions-nous pas rouler les nôtres?
Pourquoi ne devrions-nous pas créer nos propres systèmes de sécurité?
Je vois beaucoup de questions ici sur la cryptographie personnalisée et les mécanismes de sécurité personnalisés, en particulier sur le hachage de mot de passe.
Dans cet esprit, je cherche une réponse canonique, avec les propriétés suivantes:
- Facile à comprendre pour un débutant.
- Clair et explicite dans pourquoi rouler le vôtre est une mauvaise idée.
- Fournit des exemples solides.
Vous pouvez lancer le vôtre, mais vous commettrez probablement une erreur de sécurité majeure si vous n'êtes pas un expert en sécurité/cryptographie ou si votre système a été analysé par plusieurs experts. Je suis plus disposé à parier sur un schéma de cryptage open source connu du public, que tout le monde peut voir et analyser. Plus d'yeux signifie plus probable que la version actuelle ne présente pas de vulnérabilités majeures, contrairement à quelque chose développé en interne par des non-experts.
De Phil Zimmermann (créateur PGP) Introduction à la cryptographie (Page 54) :
Quand j'étais à l'université au début des années 70, j'ai imaginé ce que je croyais être un excellent schéma de cryptage. Un simple flux de nombres pseudo-aléatoires a été ajouté au flux de texte en clair pour créer un texte chiffré. Cela contrecarrerait apparemment toute analyse de fréquence du texte chiffré et serait impossible à déchiffrer, même pour les agences de renseignement gouvernementales les plus ingénieuses. Je me sentais tellement content de ma réussite.
Des années plus tard, j'ai découvert ce même schéma dans plusieurs textes d'introduction à la cryptographie et articles de tutoriel. Comme c'est gentil. D'autres cryptographes avaient pensé au même schéma. Malheureusement, le schéma a été présenté comme une simple tâche de devoirs sur la façon d'utiliser des techniques de cryptanalyse élémentaires pour le casser de manière triviale. Voilà pour mon brillant plan.
De cette expérience humiliante, j'ai appris à quel point il est facile de tomber dans un faux sentiment de sécurité lors de la conception d'un algorithme de chiffrement. La plupart des gens ne réalisent pas à quel point il est diaboliquement difficile de concevoir un algorithme de cryptage capable de résister à une attaque prolongée et déterminée d'un adversaire ingénieux.
(Cette question a plus de discussion sur la citation ci-dessus.)
Si vous n'êtes pas convaincu de "Ne roulez pas vous-même [Cryptographie/Sécurité]", alors vous n'êtes probablement pas un expert et il y a de nombreuses erreurs que vous commettrez probablement.
Votre application est-elle robuste contre:
Timing Attacks . Par exemple, pour les nanosecondes, les clés complètement mauvaises et les clés partiellement mauvaises prennent-elles autant de temps pour échouer? Sinon, ces informations de synchronisation peuvent être exploitées pour trouver la bonne clé/mot de passe.
Attaques par force brute brutale ; par exemple, cela peut être fait en quelques secondes à quelques années (lorsque vous craignez qu'il ne se brise en quelques années). Peut-être que votre idée de la sécurité pourrait être une chance sur un milliard (1 000 000 000) de s'introduire (et si quelqu'un avec un bot net essayait quelques milliards de fois?). Mon idée est de viser quelque chose comme 1 sur 2128 (34 000 000 000 000 000 000 000 000 000 000 000 000), ce qui représente environ dix millions de milliards de milliards de fois plus de sécurité et est complètement hors de portée de deviner votre chemin.
Attaques sur les comptes d'utilisateurs en parallèle; Par exemple, vous pouvez hacher des mots de passe avec le même (ou pire non) `` sel '' sur tous les hachages de mot de passe dans la base de données, comme ce qui s'est passé avec les hachages LinkedIn divulgués.
Attaquez simplement n'importe quel compte spécifique. Peut-être qu'il y avait un sel aléatoire unique avec chaque mot de passe simplement haché (par exemple, MD5/SHA1/SHA2), mais comme vous pouvez essayer des milliards de mots de passe possibles sur n'importe quel hachage chaque seconde, donc en utilisant des listes de mots de passe communs, des attaques par dictionnaire, etc., il peut prenez seulement un attaquant secondes pour casser la plupart des comptes. Utilisez des hachages cryptographiques puissants comme bcrypt ou PBKDF2 pour éviter ou renforcer les hachages réguliers par un facteur approprié (généralement 10(3-8)).
Attaques sur des nombres "aléatoires" devinables/faibles. Peut-être que vous utilisez microtime/MT-Rand ou trop peu d'informations pour amorcer le nombre pseudo-aléatoire comme Debian OpenSSL l'a fait il y a quelques années .
Attaques qui contournent les protections. Peut-être que vous avez fait du hachage/validation des entrées côté client dans l'application Web et que cela a été ignoré par l'utilisateur qui a modifié les scripts. Ou vous avez une application locale que le client essaie d'exécuter sur une machine virtuelle ou démonte pour la désosser/modifier la mémoire/ou tricher d'une autre manière.
Autres attaques, y compris (mais n'essayant pas d'être une liste complète) CSRF , XSS =, injection SQL , écoute du réseau, attaques de reje , attaques Man in the Middle , débordements de tampon , etc. Les meilleures protections résumées très rapidement.
- CSRF: nécessite des jetons CSRF générés aléatoirement sur POST; XSS: toujours valider/échapper les entrées utilisateur non fiables avant de les entrer dans la base de données et de les afficher sur l'utilisateur/navigateur.
- SQLi: utilisez toujours des paramètres liés et limitez le nombre de résultats renvoyés.
- Écoute: cryptez le trafic réseau sensible.
- Rejouer: mettez des nonces uniques uniques dans chaque transaction.
- MitM: Web of Trust/Identique à la dernière visite du site/Certificat émis par une autorité de certification de confiance.
- Débordements de tampon: langage de programmation sécurisé/bibliothèques/protection de l'espace exécutable/etc).
Vous êtes seulement aussi fort que votre lien exploitable le plus faible. De plus, ce n'est pas parce que vous ne lancez pas votre propre schéma que votre schéma sera sécurisé qu'il est probable que la personne qui a créé ce que vous avez déployé n'était pas un expert ou a créé un schéma par ailleurs faible.
Il y a une maison dans ma région avec une terrasse vraiment agréable à l'extérieur de la salle familiale au deuxième étage. Il a l'air gonflé, jusqu'à ce que vous alliez en dessous et voyez comment il a été construit. Il semble que le propriétaire a décidé qu'il n'avait pas besoin de payer beaucoup d'argent à un constructeur ou à un architecte pour lui dire comment construire une terrasse. Il l'a construit lui-même et il ressemble à une toile d'araignée chaotique de 2x4 en dessous. Il [~ # ~] probablement [~ # ~] ira bien. Personnellement, je préférerais ne pas risquer la vie et les membres dans un travail de construction amateur comme ça.
Je pense que si vous voulez développer un algorithme pour faire du chiffrement, vous devriez le faire et passer un bon moment. Je ne recommanderais pas de l'utiliser pour masquer vos relevés bancaires en ligne, mais si vous voulez crypter les lettres d'amour de votre petite amie sur votre ordinateur à la maison, ça devrait aller - à condition que votre femme ne soit pas un cryptanalyste.
Il y a une histoire dans "The American Black Chamber" * sur la marine développant ses propres chiffres. La Marine montrerait son nouveau cryptosystème, satisfaite d'elle-même et Yardley, l'analyste de l'Armée, casserait rapidement le code, expliquant ce qu'elle avait fait de mal. Ils proposeraient de corriger le code mais Yardley a souligné que même s'ils pouvaient corriger des faiblesses spécifiques, sans une compréhension solide, ils allaient toujours avoir un problème. Leur système était intrinsèquement défectueux. C'est un peu comme réparer un toit qui fuit. Vous pouvez rapiécer pour toujours, mais l'eau va toujours trouver son chemin. Si vous ne voulez pas vous mouiller, le toit doit être construit par quelqu'un qui en sait plus que peu sur les toits.
Vous ai-je déjà parlé de la chirurgie du cerveau à faire par moi-même sur ma défunte belle-mère? Tout s'est bien passé jusqu'à ce qu'elle aille et meure. Sérieusement, peu d'entre nous confieraient notre santé à un médecin amateur; voulez-vous vraiment confier vos secrets aux logiciels amateurs? Je déteste l'admettre mais j'achète un billet de loterie tous les quelques mois. Je m'attends à perdre, mais le gain potentiel est énorme. Je peux jouer les cotes et peut-être que je sortirai devant. Si ce n’est pas le cas, je ne suis pas à la hauteur. Pourquoi jouer les cotes sur le cryptage? Le paiement n'est pas là.
Cordialement,/Bob Bryan
- Recommandé: Herbert O. Yardley, "La chambre noire américaine" - Un livre aussi intéressant aujourd'hui que lorsqu'il a été écrit en 1931. "La Chambre noire américaine était remplie de bonnes histoires bien racontées, ainsi que de descriptions franches des succès de Yardley dans cryptanalyse. C'était un best-seller en 1932 - aussi bien à l'étranger qu'au niveau national. " De NSA: Pearl Harbor Review - The Black Chamber
Bruce Scheier écrit en 1998:
N'importe qui, de l'amateur le plus ignorant au meilleur cryptographe, peut créer un algorithme qu'il ne peut lui-même casser. Ce n'est même pas difficile. Ce qui est difficile, c'est de créer un algorithme que personne d'autre ne peut casser, même après des années d'analyse. Et la seule façon de le prouver est de soumettre l'algorithme à des années d'analyse par les meilleurs cryptographes du monde.
Cory Doctorow a surnommé ce concept "la loi de Schneier" dans un 2004 discours :
Toute personne peut inventer un système de sécurité si intelligent qu'elle ne sait pas comment le briser.
À titre de suivi, this , encore une fois de Schneier:
Quand quelqu'un vous remet un système de sécurité et dit: "Je crois que c'est sûr", la première chose que vous devez demander est: "Qui diable êtes-vous? Montrez-moi ce que vous avez cassé pour démontrer que votre affirmation de la sécurité du système signifie quelque chose.
Phil Zimmerman a également écrit dans ses documents PGP originaux :
Quand j'étais à l'université au début des années 70, j'ai imaginé ce que je croyais être un excellent schéma de cryptage. Un simple flux de nombres pseudo-aléatoires a été ajouté au flux de texte en clair pour créer un texte chiffré. Cela contrecarrerait apparemment toute analyse de fréquence du texte chiffré et serait impossible à déchiffrer, même pour les agences de renseignement gouvernementales les plus ingénieuses. Je me sentais tellement content de ma réussite. Tellement sûr.
Des années plus tard, j'ai découvert ce même schéma dans plusieurs textes d'introduction à la cryptographie et articles de tutoriel. Comme c'est gentil. D'autres cryptographes avaient pensé au même schéma. Malheureusement, le schéma a été présenté comme une simple tâche de devoirs sur la façon d'utiliser des techniques de cryptanalyse élémentaires pour le casser de manière triviale. Voilà pour mon brillant plan.
Le message d'origine demandait un exemple:
Le Babington Plot est une bonne histoire d'un mauvais cryptosystème causant des problèmes. Mary Queen of Scots a été emprisonnée par sa cousine la reine Elizabeth I et communiquait avec des personnes de l'extérieur via des lettres cryptées. L'alphabet a été remplacé par un cryptoalphabet de gribouillis, de cercles croisés et de triangles avec des lettres supplémentaires affectées aux lettres communes, comme e, t, i et o, de sorte que la signification des lettres n'a pas pu être trouvée rapidement par analyse de fréquence. Ils ont également ajouté quelques caractères nuls qui ont été ignorés dans le décryptage pour déconcerter les analystes. Le problème était que la Reine avait un cryptanalyste très compétent dans son personnel en la personne de Thomas Phelippes qui était capable de décrypter les messages lorsqu'ils étaient interceptés.
Au fur et à mesure que les choses progressaient, Mary accepta un complot pour qu'elle s'échappe et prenne le trône. Lorsque les agents de la Reine ont intercepté la dernière lettre de Mary avant de la transmettre, ils ont ajouté une phrase chiffrée demandant les noms des personnes impliquées dans le complot "afin qu'elles puissent être correctement récompensées". Le correspondant de Mary répondit consciencieusement et les agents de la Reine firent exécuter toutes les personnes impliquées.
Quand mes enfants étaient petits, je leur envoyais des cryptogrammes avec leur déjeuner (avec une clé (en utilisant un chiffrement Vernam)). Généralement, c'étaient des blagues mais elles n'avaient jamais aucune importance. Dans un cas comme celui-là, rouler le vôtre est très bien. Si vous envisagez de renverser la Reine d'Angleterre (ou le Shah d'Iran ou la Thug-ocracy lentement réformatrice au Myanmar), je vous suggère de vous assurer que ce que vous utilisez ne peut pas être facilement déchiffré. Comme l'a dit Bruce Schneier , n'importe qui peut trouver un cryptosystème qu'il ne peut pas décrypter, mais trouver un autre que personne d'autre ne peut décrypter est plus difficile.
Je vais donner un exemple de quelque chose qui s'est passé ici où je travaille. Un de mes collègues était responsable de la conception d'un système de stockage de mots de passe (longue histoire, ne demandez pas) pour les comptes FTP de l'entreprise. On m'a demandé de prendre la relève, et la première chose que j'ai vue a été:
public string Encrypt(string rawText)
{
// homebrew code here
}
public string Decrypt(string encrypted)
{
// homebrew code here
}
Je les ai immédiatement arrachés, les remplaçant par des appels de bibliothèque cryptographique standard - et quand j'ai été interrogé, j'ai répondu:
"Vous jamais lancez votre propre routine de chiffrement."
Mon collègue m'a combattu pendant des heures à ce sujet. Il avait passé beaucoup de temps dessus, ce qui en faisait parfait, de sorte qu'un attaquant ne pouvait peut-être avoir aucun moyen de le casser . À un moment donné, ils ont même déclaré: "C'est plus sûr que l'AES256, car personne ne sait comment cela fonctionne."
À ce moment-là, je savais deux choses:
- Mon collègue était un parfait exemple de l'effet Dunning Kruger (un manque de connaissances sur un sujet le rendant plus susceptible de surestimer ses propres capacités)
- Mon collègue a dû être corrigé. Non seulement parce qu'ils étaient "mauvais", mais parce qu'ils étaient responsables de l'architecture des systèmes other, et je ne voulais pas qu'ils gardent le cryptage de brassage domestique.
J'ai donc mis de côté le code. Et à la place, j'ai essayé de casser la routine en appelant simplement la fonction Encrypt () et en examinant la sortie. Je suis novice - je ne suis pas cryptoanalyste - mais cela ne m'a pris que 4 heures. Je leur ai montré le crack, je les ai suivis tout au long de mes pas et j'ai réitéré: ne lancez jamais votre propre cryptage. J'espère qu'ils le prendront à cœur et ne le feront plus jamais.
Cela se résume donc à:
- Votre confiance dans la sécurité de votre cryptage a non une incidence sur sa sécurité réelle.
- Ne jamais rouler votre propre cryptage (ne peut pas être répété assez souvent ...)
En cryptographie, vous n'avez pas un seul adversaire qui vous attaque de la manière que vous attendez de lui. C'est pourquoi il est difficile de raisonner, car il faut penser à TOUT absolument.
Mais vraiment, personne ne peut déjouer tous les adversaires possibles. Le mieux que nous puissions faire est d'utiliser autant que possible nos connaissances communes et les recherches existantes et de prendre des mesures pour construire à partir de là, vecteur d'attaque par vecteur d'attaque.
C'est ainsi que sont abordés de nombreux problèmes au bord des capacités humaines, que ce soit la recherche en physique ou le jeu d'échecs au plus haut niveau.
Dans ces domaines, vous pouvez également ignorer ce sur quoi d'autres personnes travaillent et concevoir vos propres stratégies et théories, et si vous rencontrez votre premier adversaire qualifié, vous serez effacé par l'état de l'art de plus de manières que vous pouvez compter.
TL; DR
Les humains sont trop stupides pour faire de la cryptographie seul.
Il est généralement impossible de garantir qu'une personne qui conçoit un cryptosystème ne quittera pas l'entreprise pour laquelle il a été créé et d'utiliser sa connaissance de cette conception au détriment de son ancien employeur, sauf en concevant le cryptosystème de telle manière que tout ces connaissances qu'un adversaire peut acquérir pourraient être rendues inutiles.
Si l'on a un cryptosystème qui est sécurisé même contre les attaquants qui connaissent tout sauf une clé, et que l'on change la clé en une nouvelle valeur générée aléatoirement, alors le système sera sécurisé contre tous les attaquants qui n'ont pas la nouvelle clé. Même si les attaquants disposaient de suffisamment d'informations pour compromettre le système avant que la clé ne soit changée, ils ne pourraient pas casser le système par la suite.
À moins qu'un système n'ait besoin de protéger des données d'une valeur inhabituelle, il n'est probablement pas trop difficile de concevoir un système de cryptographie pour être suffisamment bon pour que, sans connaissance privilégiée, le coût de la fissuration dépasserait toute valeur qui pourrait être gagnée en le faisant. Non pas parce que la conception d'un bon crypto est facile, mais parce que la plupart des systèmes ne sont pas utilisés pour protéger quoi que ce soit qui serait de grande valeur pour un attaquant (même si un cryptographe qualifié pourrait facilement casser un système en 58 minutes, ce ne serait pas beaucoup de un risque à moins que la valeur de ces informations pour un attaquant ne dépasse le coût du temps du cryptographe).
Cependant, il est beaucoup plus difficile de concevoir un système afin qu'il puisse être renforcé contre une personne disposant de données privilégiées, et il y a très peu de personnes possédant une expertise suffisante pour concevoir un système qui pourrait - en changeant une clé - être rendu robuste par quelqu'un qui avait à la fois une connaissance approfondie de la conception et une expertise en cryptographie. Un expert en cryptographie sans connaissance privilégiée peut devoir rechercher des centaines ou des milliers d'erreurs potentielles qu'un concepteur aurait pu commettre, mais cette connaissance privilégiée peut permettre à cette personne d'identifier et d'exploiter une erreur immédiatement.
En fait, lancez votre propre crypto, puis jetez-le.
Comme Crypto Fails appelle, il est un peu dur de dire que vous ne pouvez pas écrire de code crypto du tout. Le principal problème est de ne pas prendre ce code et de l'utiliser n'importe où (dans le logiciel publié).
Vous devriez certainement lui donner un coup de feu et l'utiliser comme une expérience d'apprentissage. Encore mieux si vous êtes amis avec un cryptanalyste et que vous pouvez obtenir leurs commentaires sur ce que vous avez écrit. S'ils valent leur sel, eux aussi vous diront de ne pas utiliser le code dans la vraie vie, mais ils devraient être en mesure de vous donner des informations qui vous aideront à apprendre et à grandir.