Toute sécurité n'est-elle pas «à travers l'obscurité»?
Je sais que l'on ne devrait pas compter sur "l'obscurité" pour leur sécurité. Par exemple, choisir un port non standard n'est pas vraiment une sécurité, mais cela ne fait généralement pas de mal à le faire (et peut aider à atténuer certaines des attaques les plus triviales).
Le hachage et le chiffrement reposent sur une forte randomisation et des clés secrètes. RSA, par exemple, repose sur le secret de d et, par extension, p, q et ϕ(N). Puisque ceux-ci doivent être gardés secrets, tout le cryptage (et le hachage, si vous connaissez le vecteur de randomisation) n'est-il pas sécurisé par l'obscurité? Sinon, quelle différence y a-t-il entre obscurcir la sauce secrète et simplement garder les trucs secrets secrets? La raison pour laquelle nous appelons le cryptage (correct) sécurisé est que les calculs sont irréfutables: il est difficile, par exemple, de calculer N pour comprendre p et q (comme à notre connaissance). Mais cela n'est vrai que parce que p et q ne sont pas connus. Ils sont essentiellement obscurcis.
J'ai lu Le rôle valide de l'obscurité et À quel moment quelque chose compte-t-il comme 'la sécurité par l'obscurité'? , et ma question est différente parce que je ne pose pas de questions sur comment l'obscurité est valide ou quand dans le spectre un schéma devient obscur, mais plutôt, je demande si cacher tous nos trucs secrets n'est pas lui-même de l'obscurité, même si nous définissons notre sécurité comme étant grâce à ces mécanismes. Pour clarifier ce que je veux dire, les réponses à cette dernière question (excellentes, soit dit en passant) semblent s'arrêter à "... ils ont encore besoin de casser le mot de passe" - ce qui signifie que le mot de passe est toujours obscurci par l'attaquant.
Voir cette réponse .
Le point principal est que nous faisons une distinction nette entre l'obscurité et le secret ; si nous devons réduire la différence à une seule propriété, alors cela doit être mesurabilité. Est secret ce qui n'est pas connu des étrangers, et nous savons combien il est inconnu de ces étrangers. Par exemple, une clé symétrique de 128 bits est une séquence de 128 bits, telle que les 2128 les séquences possibles auraient une probabilité égale d'être utilisées, donc l'attaquant essayant de deviner une telle clé doit essayer, en moyenne, au moins 2127 d'entre eux avant de frapper le bon. C'est quantitatif. Nous pouvons faire des calculs, ajouter des chiffres et calculer coût d'attaque.
La même chose s'appliquerait à une clé privée RSA. Les mathématiques sont plus complexes car les méthodes connues les plus efficaces reposent sur factorisation entière et les algorithmes impliqués ne sont pas aussi faciles à quantifier que la force brute sur une clé symétrique (il y a beaucoup de détails sur RAM utilisation et parallélisme ou absence de celui-ci.) Mais cela reste secret.
En revanche, un algorithme obscur n'est "secret" que tant que l'attaquant ne travaille pas sur les détails de l'algorithme, et cela dépend de nombreux facteurs: accessibilité au matériel implémentant l'algorithme, compétences à la rétro-ingénierie, et smartness. Nous n'avons pas de moyen utile de mesurer à quel point une personne peut être intelligente. Un algorithme secret ne peut donc pas être "secret". Nous avons un autre terme pour cela, et c'est "obscur".
Nous voulons faire la sécurité par le secret parce que la sécurité est la gestion des risques: nous acceptons les frais généraux d'utilisation d'un système de sécurité parce que nous pouvons mesurer combien cela nous coûte l'utiliser, et combien il réduit le risque d'attaques réussies, et nous pouvons alors équilibrer les coûts pour prendre une décision éclairée. Cela peut ne fonctionner que parce que nous pouvons chiffrer les risques d'attaques réussies, et cela ne peut se faire que dans le secret, pas dans l'obscurité.
Je pense que le terme "sécurité par l'obscurité" est souvent utilisé à mauvais escient.
La citation la plus fréquemment citée lorsque l'on parle de sécurité par l'obscurité est principe de Kerckhoffs .
Elle ne doit pas être tenue secrète et doit pouvoir tomber entre les mains de l'ennemi sans inconvénient;
La sécurité par l'obscurité fait référence à la nécessité de conserver la conception et la mise en œuvre de un système de sécurité sécurisé en cachant les détails d'un attaquant. Ce n'est pas très fiable car les systèmes et les protocoles peuvent être rétroconçus et démontés avec suffisamment de temps. De plus, un système qui repose sur le fait de cacher son implémentation ne peut pas dépendre d'experts qui l'examinent pour détecter des faiblesses, ce qui conduit probablement à plus de failles de sécurité qu'un système qui a été examiné, a les bogues connus et corrigés.
Prenez RSA par exemple. Tout le monde dans le monde sait comment cela fonctionne. Eh bien, tous ceux qui ont une bonne compréhension des mathématiques sont impliqués de toute façon. Il est bien étudié et repose sur des problèmes mathématiques difficiles. Cependant, étant donné ce que nous savons sur les mathématiques impliquées, il est sécurisé à condition que les valeurs de p et q soient gardées secrètes. Il s'agit essentiellement de concentrer le travail de rupture (et de protection) du système en un secret qui peut être protégé.
Comparez cela avec un algorithme de chiffrement qui ne souscrit pas au principe de Kerckhoffs. Au lieu d'utiliser un schéma connu du public qui utilise une clé secrète, cet algorithme de chiffrement est secret. Quiconque connaît l'algorithme peut déchiffrer toutes les données chiffrées avec l'algorithme. C'est très difficile à sécuriser car l'algorithme sera presque impossible à garder hors des mains d'un ennemi. Voir Enigma machine pour un bon exemple de cela.
La différence essentielle réside dans ce qui est gardé secret.
Prenons l'exemple de RSA. Le principe de base de RSA est la mathématique simple. Quiconque possède un peu de connaissances mathématiques peut comprendre comment fonctionne RSA fonctionnellement (les mathématiques ont presque un demi-millénaire). Il faut plus d'imagination et d'expérience pour comprendre comment vous pouvez en tirer parti pour la sécurité, mais cela a été fait de manière indépendante au moins deux fois (par Rivest, Shamir et Adleman, et quelques années auparavant par Clifford Cocks ) . Si vous concevez quelque chose comme RSA et le gardez secret, il y a de fortes chances que quelqu'un d'autre soit assez intelligent pour le comprendre.
En revanche, une clé privée est générée au hasard. Lorsqu'elle est effectuée correctement, la génération aléatoire garantit qu'il est impossible de reconstruire le secret avec une puissance de calcul humainement disponible. Aucune quantité d'habileté ne permettra à quiconque de reconstruire une chaîne secrète de bits aléatoires, car cette chaîne n'a aucune structure pour l'intuition.
Les algorithmes cryptographiques sont inventés par intelligence, avec des objectifs largement partagés (protéger certaines données, mettre en œuvre l'algorithme à peu de frais,…). Il y a de fortes chances que des gens intelligents convergent vers le même algorithme. D'un autre côté, les chaînes aléatoires de bits secrets sont nombreuses et, par définition, les gens ne trouveront pas la même chaîne aléatoire¹. Donc, si vous concevez votre propre algorithme, il y a de fortes chances que votre voisin conçoive le même. Et si vous partagez votre algorithme avec votre ami et que vous souhaitez ensuite communiquer en privé avec lui, vous aurez besoin d'un nouvel algorithme. Mais si vous générez une clé secrète, elle sera distincte de celle de votre voisin et de votre copain. Il y a certainement une valeur potentielle à garder secret une clé aléatoire, ce qui n'est pas le cas pour garder un algorithme secret.
Un point secondaire sur le secret des clés est qu'il peut être mesuré. Avec un bon générateur aléatoire, si vous générez une chaîne aléatoire de n bits et la gardez secrète, il y a une probabilité de 1/2 ^ n que quelqu'un d'autre la trouve en un seul essai. Si vous concevez un algorithme, le risque que quelqu'un d'autre le découvre ne peut pas être mesuré.
Les clés privées RSA ne sont pas une simple chaîne aléatoire - elles ont une certaine structure, étant une paire de nombres premiers. Cependant, la quantité d'entropie - le nombre de clés RSA possibles d'une certaine taille - est suffisamment grande pour en rendre une pratiquement impossible à deviner. (Quant aux clés RSA étant pratiquement impossibles à reconstruire à partir d'une clé publique et d'un tas de textes en clair et de textes chiffrés, c'est quelque chose que nous ne pouvons pas prouver mathématiquement, mais nous pensons que c'est le cas parce que beaucoup de gens intelligents ont essayé et échoué. Mais c'est une autre histoire.)
Bien sûr, cela se généralise à tout algorithme cryptographique. Gardez les chaînes aléatoires secrètes. Publiez des designs intelligents.
Cela ne veut pas dire que tout doit être rendu public, sauf pour la petite partie qui est un tas aléatoire de bits. principe de Kerckhoff ne dit pas cela - il dit que la sécurité de la conception ne doit pas reposer sur le secret de la conception. Bien que les algorithmes cryptographiques soient mieux publiés (et vous devez attendre une dizaine d'années avant de les utiliser pour voir si suffisamment de personnes n'ont pas réussi à les briser), il existe d'autres mesures de sécurité qui doivent être gardées secrètes, en particulier des mesures de sécurité qui nécessitent une vérification active pour comprendre. Par exemple, certaines règles de pare-feu peuvent tomber dans cette catégorie; cependant un pare-feu qui n'offre pas de protection contre un attaquant qui connaît les règles serait inutile, car finalement quelqu'un les découvrira.
¹ Bien que ce ne soit pas vrai mathématiquement, vous pouvez littéralement parier dessus.
La sécurité consiste à garder des secrets, mais une bonne sécurité consiste à savoir quels secrets vous pouvez garder et lesquels vous ne pouvez pas.
Et en particulier, les meilleurs protocoles de sécurité sont construits autour du principe de la suppression du secret de la conception, afin que votre secret puisse être conservé sans avoir à garder le design secret également. Ceci est particulièrement important car les conceptions de systèmes sont notoirement impossibles à garder secrètes. C'est le cœur du principe de Kerckhoffs , qui remonte à la conception des anciennes machines de cryptage militaire.
En d'autres termes, si vous algorithme est votre secret, alors toute personne qui voit une implémentation de votre algorithme - toute personne qui a votre matériel, toute personne qui a votre logiciel, toute personne qui utilise votre service - a vu ton secret. L'algorithme est un endroit terrible pour mettre vos secrets, car les algorithmes sont si faciles à examiner. De plus, les secrets intégrés dans les conceptions ne peuvent pas être modifiés sans changer votre implémentation. Vous êtes coincé avec le même secret pour toujours.
Mais si votre machine n'a pas besoin d'être gardée secrète, si vous avez conçu votre système de telle sorte que le secret soit indépendant de la machine - une clé ou un mot de passe secret - alors votre système restera sécurisé même après examen de l'appareil par vos ennemis, pirates, clients, etc. De cette façon, vous pouvez concentrer votre attention sur la protection du mot de passe tout en restant convaincu que votre système ne peut pas être brisé sans lui.
La sécurité par l'obscurité se réfère généralement à principe de Kerchoff , qui stipule que le système doit être sécurisé même si tout sauf la clé est de notoriété publique. Cela ne s'applique pas seulement à la cryptographie ou à la génération de textes chiffrés. Cela signifie également que vous ne devez pas compter sur la génération d'URL, de mots de passe, de hachages, d'adresses de mémoire et même sur l'architecture du système pour être secret. La raison en est que quelque chose dans le système doit être secret, et isoler la partie secrète en un seul grand nombre le rend beaucoup plus facile à utiliser.
Les raisons de protéger la clé, et non l'algorithme, sont les plus grandes chances de fuite de l'algorithme, un plus grand nombre de clés possibles que les algorithmes possibles et le coût plus élevé d'une fuite. L'algorithme est très facile à fuir. Des algorithmes et des secrets matériels prétendument classés sont divulgués chaque jour, par exemple par:
- Un pirate volant votre code source
- Rendre votre algorithme disponible pour le pentesting ou les chercheurs pour examen.
- Rétro-ingénierie de votre algorithme par quiconque obtient le logiciel/matériel
- Rétro-ingénierie de votre algorithme par toute personne qui utilise également l'algorithme
- Anciens employés mécontents ou malveillants divulguant l'algorithme
- Deviner la force brute, car il est généralement beaucoup plus facile de deviner un algorithme non sécurisé que de deviner une clé de 256 bits.
Révéler votre algorithme aux chercheurs présente un Catch-22. Vous ne pouvez pas affirmer qu'une méthode secrète est sécurisée sans la révéler , auquel cas elle n'est plus secrète ou sécurisée. C'est pourquoi nous séparons la partie secrète de nos algorithmes. Vous pouvez montrer que l'utilisation de votre méthode ne révèle pas de clé secrète.
Une fuite ou une nouvelle clé est également très coûteuse lorsque l'algorithme fait partie du secret. Pour garder une longueur d'avance sur les attaquants, vous devez repenser et mettre à jour chaque utilisation de l'algorithme avec quelque chose de tout nouveau. Vous devrez peut-être même changer le "secret" tous les quelques mois si vous utilisez un système très sécurisé. Il est beaucoup plus facile de remplacer la clé dans un algorithme sécurisé que de remplacer l'intégralité de l'algorithme , en particulier lorsqu'il s'agit de matériel, de compatibilité descendante ou de pousser les mises à jour vers les clients. .
L'idée ici est que chaque système sécurisé a un secret. Chaque fois que vous générez quelque chose que vous ne voulez pas qu'un pirate puisse inverser ou deviner sans connaître un secret, c'est une bonne ingénierie pour:
- Rendez les connaissances secrètes faciles à modifier ou à remplacer.
- Assurez-vous que le secret lui-même est difficile à déduire des entrées et des sorties
- Assurez-vous que le secret est suffisamment complexe pour ne pas être deviné
Si je construis une boîte qui prend un nombre et en crache un autre (ou prend une graine et crache des valeurs "aléatoires", etc.), alors quelqu'un construit une boîte identique, je dois maintenant changer ma boîte. Si tout ce que j'ai à changer sur ma box est de changer un nombre de 256 bits, cela me fait gagner beaucoup de temps et d'efforts. De même, si je veux vendre ces boîtes, chacune doit être différente. Changer l'algorithme pour chaque boîte que vous vendez, au lieu de changer une clé aléatoire pour chaque boîte, serait ridiculement mauvais.
Enfin, il vaut la peine de comprendre que la sécurité à travers l'obscurité et "rouler votre propre crypto" se trouvent souvent ensemble. Ne lancez pas votre propre crypto. En changeant secrètement votre crypto, le gain de secret est compromis par une perte de sécurité. En lançant votre propre crypto, vous pouvez très probablement rendre votre système milliards ou même 2 ^ (grand nombre) fois moins cher à craquer, et je garantis qu'un attaquant ne prendra pas mille milliards de suppositions pour découvrir comment vous avez fait rouler votre propre système.
La sécurité par l'obscurité signifie que la sécurité dépend du maintien secret de l'algorithme.
Par exemple, si je décide d'utiliser rot13 pour mon cryptage, la sécurité du système dépend de moi pour m'assurer que personne d'autre ne connaît l'algorithme que j'utilise. Enfin, il m'incombe de déterminer le degré de fissuration de l'algorithme.
Un problème majeur est que je ne peux pas distribuer ce système, car n'importe qui peut simplement faire de l'ingénierie inverse de l'algorithme et l'utiliser pour briser mon cryptage. De plus, si le code est compromis, tout le reste l'est aussi.
Un protocole qui repose sur la sécurité par l'obscurité sera généralement éventuellement craquable en analysant également la sortie. (Bien sûr, on peut concevoir des algorithmes qui ne sont pas sujets à cela - la chose la plus simple à faire est de prendre l'algorithme RSA et les paires de clés de code dur, créant trivialement un algorithme de "sécurité par obscurité".) Il ne faut pas croire que l'algorithme ne sera finalement pas deviné.
D'un autre côté, si j'utilise RSA pour le chiffrement, je peux faire en sorte que chaque instance génère sa propre paire de clés, et ainsi le programme peut être distribué sans crainte. Je peux empêcher les clés d'être compromises par des périphériques matériels spéciaux qui contiennent la clé et peuvent chiffrer les messages, mais je n'ai pas la possibilité de cracher la clé. De plus, étant un protocole connu du public, beaucoup, beaucoup de gens ont analysé le protocole pour les failles de sécurité; Je peux faire confiance que les messages cryptés ne peuvent pas être piratés. Nous savons que les clés ne peuvent pas être devinées parce que la probabilité est de notre côté.
Ce n'est pas la sécurité par l'obscurité. C'est la sécurité par le secret. L'algorithme est public, il n'y a qu'un "secret" (la clé) qui est gardé secret.
Comme d'autres l'ont dit, l'obscurité fait vraiment référence à la mise en œuvre.
Laissez-moi vous donner un exemple. Supposons que vous et votre partenaire ayez une livre de pépites d'or dans votre maison que vous souhaitez sécuriser, mais que vous n'êtes pas d'accord sur la façon dont ...
Il se trouve que l'un d'entre vous a un génie, que vous pouvez ordonner d'incinérer toute personne qui se trouve à moins de 5 pieds sans donner de mot de passe.
L'un d'entre vous veut cacher les pépites dans le tuyau de vidange de l'évier de cuisine, disant que le drain fonctionnera toujours et que personne ne penserait jamais à y regarder. Cette méthode a été utilisée avec tous les anciens partenaires et n'a pas encore échoué.
Le mot de passe et l'emplacement sont tous deux "secrets", mais l'emplacement dépend de leur absence de recherche, tandis que le mot de passe, même si vous le réutilisez partout, repose sur le fait qu'ils ne le savent pas.
Prenez une échelle coulissante de 1 à 10, 10 étant "sécurité conforme IEEE" et 1 étant "chambre forte à l'épreuve des couteaux faite de couches de flanelle". "La sécurité par l'obscurité" est une expression utilisée pour décrire un plan de sécurité dans lequel la valeur est comprise entre 1 et 8, selon qui vous demandez et le jour de la semaine, ainsi que le niveau actuel estimé d'éjection de masse coronale de Betelgeuse.
En d'autres termes, c'est le résultat d'une mesure entièrement subjective de la proximité d'une politique de sécurité standard, car personne ne peut peut-être connaître la différence entre les risques, lors d'un exploit de jour zéro, d'un plan de sécurité standard vs un plan de sécurité non standard .
Je pense que la sécurité à travers l'obscurité peut être vue de cette manière:
Vous avez une porte qui se déverrouille en tournant le bouton de porte dans le sens des aiguilles d'une montre plutôt que dans le sens inverse des aiguilles d'une montre. Vous fournissez un trou de serrure sur le bouton de porte pour masquer le fait qu'il ne nécessite pas de clé pour se déverrouiller.
Traduit en technologie de l'information, je pense que cela s'apparente à l'implémentation d'une fonctionnalité de sécurité d'une manière inhabituelle pour repousser tout attaquant. Par exemple, masquer un serveur Web en tant que IIS alors qu'il s'agit en fait de Nginx.
La sécurité par l'obscurité n'est pas nécessairement mauvaise sécurité. La clé réside dans sa mise en œuvre. Autrement dit, si vous êtes capable de l'exécuter de manière cohérente sans vous déclencher en raison de cette fonctionnalité non conventionnelle que vous avez implémentée.
Beaucoup de texte, pour une grande question.
Permettez-moi de simplifier la réponse à cela par une analogie. L'obscurité peut être définie de nombreuses façons, toutes en accord avec une autre. "Quelque chose de difficile à comprendre est obscur".
Observez une porte, je suggérerai qu'il existe 3 façons de sécuriser une porte. 1. Cachez la poignée (obscurité, pas de sécurité) 2. Verrouillez-la avec une clé (sécurité) 3. Cachez la poignée et verrouillez-la avec une clé (sécurité et obscurité)
(Vous pouvez également masquer le trou de clé ou le verrou, en ce qui concerne mon analogie)
Ce qui importe, c'est même de penser que l'on sait que la porte a besoin d'une clé, on ne sait pas laquelle, que je secret ou que je garde. Tout le monde sait qu'une poignée sur la porte est utilisée pour l'ouvrir, cacher la poignée n'est que de l'obscurité.
Combinées, ces approches sont en fait plus sûres qu’elles ne le sont en elles-mêmes.
L'obscurité concerne la façon dont les choses sont sécurisées, plutôt que les informations nécessaires pour y accéder. Dans le cas de quelque chose comme le changement de ports, le port à utiliser est le moyen réel de sécurisation et est également facilement obtenu en observant le comportement. Lorsque vous utilisez un algorithme de source fermée et que vous vous appuyez sur la nature de la source fermée pour le rendre difficile à comprendre, la sécurité est la même pour tous les utilisateurs du système. Si vous le brisez une fois, vous le brisez pour tout le monde parce que vous laissez une attaque sur l'ensemble du système jusqu'à l'obscurité.
Pour quelque chose comme un mot de passe, c'est une clé. Oui, cette clé est un secret "obscur", mais connaître un mot de passe particulier ne casse pas le système, il casse l'utilisateur. La sécurité du système fonctionne parfaitement même lorsqu'elle est connue. Il réussit toujours à n'autoriser que les utilisateurs qui possèdent ces connaissances et chaque utilisateur peut utiliser un secret différent ou changer son secret pour autoriser l'accès.
Donc, la différence est si vous avez affaire au secret de la méthode ou au secret de la clé. Si la méthode nécessite la confidentialité pour être sécurisée, elle se casse, dans son intégralité, dès que la méthode est compromise. Si la méthode ne nécessite pas de confidentialité, mais uniquement des informations pour une utilisation particulière, elle fournit une sécurité car la portée d'un compromis est limitée à une relation 1: 1 entre le secret et la chose à laquelle on accède.
En effet, si vous pouvez associer le secret à une chose particulière à protéger et que la protection de ce secret est suffisante si vous remplacez la chose qu'il protège, alors le système est suffisamment sécurisé.