La sécurité par l'obscurité est horrible. La sécurité ET l'obscurité sont-elles bonnes?
Normalement, je prêche que rouler votre propre algorithme de chiffrement personnalisé est une mauvaise idée. Mais cela fera-t-il vraiment mal si c'est la couche la plus externe? Ou cela va-t-il aggraver la sécurité?
AES -> CipherText -> CustomEncryptionAlgorithm-> CipherText
Je pense que la couche supplémentaire aidera. Imaginons que même si CustomEncryptionAlgorithm est un bogue rempli de bogues, cela ne peut pas aggraver les choses. En effet, la sortie AES est déjà impossible à distinguer du bruit aléatoire.
D'un autre côté, quelque chose me dit que ce qui suit est problématique
CustomEncryptionAlgorithm -> CipherText -> AES -> CipherText
Est-il mauvais? et pourquoi?
Veuillez ne pas commenter les ressources de l'entreprise consacrées à la sécurité et à l'obscurité, etc. (je conviens que la sécurité vient en tête). Je suis plus intéressé à comprendre la théorie cryptographique derrière les vulnérabilités de cette approche.
Ne lancez pas votre propre crypto!
D'un point de vue cryptographique purement , toute fonction bijective conservant la longueur ne peut pas réduire la sécurité. En fait, même la fonction d'identité , définie comme f (x) = x , ne réduira pas la sécurité, en supposant que les clés utilisés pour le chiffrement standard et votre chiffrement homebrew sont mutuellement indépendants. La seule façon possible de réduire la sécurité est que votre fonction homebrew n'utilise pas une clé différente et indépendante et fuit la clé dans le texte chiffré, par exemple avec fk(x) = x ⊕ k fait sur chaque bloc individuel d'entrée x , un classique XOR vulnérable aux attaques en texte clair connues.
D'un point de vue pratique, il existe des pièges qui peuvent être importants. J'ai mentionné la conservation de la longueur ci-dessus pour une bonne raison. Une fonction de compression est toujours une fonction, et parfois la compression et le chiffrement peuvent conduire à très mauvais résultats . C'est en partie pourquoi votre deuxième exemple, avec votre algorithme personnalisé appliqué avant le chiffrement standard, est en effet pire. Il peut divulguer des informations sur le texte en clair sur toute sa longueur. Il peut également y avoir des bogues dans votre implémentation qui entraînent d'autres failles de sécurité. D'un point de vue purement théorique, ils sont hors de portée.
Il m'a été souligné dans un commentaire que je n'insistais peut-être pas suffisamment sur la gravité d'une idée. Bien que cela puisse convenir en théorie, le monde réel fonctionne différemment. En fait, utiliser votre propre crypto homebrew est une très mauvaise idée , peu importe comment vous l'utilisez. La seule fois où vous devriez réellement le faire, c'est si vous êtes un cryptographe professionnel. Bernstein peut le faire. Rivest peut le faire. Rijmen peut le faire. Vous ne pouvez pas. Ne vous tirez pas dans le pied et utilisez plutôt des algorithmes appropriés.
Il existe un risque lorsque vous appliquez d'abord votre algorithme de chiffrement personnalisé.
Ceci est basé sur le fait qu'un cryptage comme AES fuit des informations sur la longueur du texte en clair.
Supposons l'exemple extrêmement hypothétique (et peu pratique) où votre algorithme personnalisé "chiffre" un texte en clair à un octet comme 0x40 en 64 zéros et un texte en clair à deux octets comme 0x02 0x00 en 512 zéros.
Lorsque vous cryptez cela en utilisant AES, un attaquant connaîtra toujours la longueur du résultat chiffré personnalisé simplement en regardant la longueur du texte chiffré AES.
Avec ces informations, l'attaquant peut 'décrypter' cela dans le texte en clair d'origine sans avoir la clé de cryptage AES.
En résumé: un très mauvais algorithme personnalisé peut en effet nuire à la sécurité d'un cryptage AES suivant.
La première question à poser lors de l'évaluation de tout type de système de sécurité est "Qui est l'attaquant et que peuvent-ils faire?" À l'extrémité inférieure, vous êtes contre un attaquant qui peut simplement voir la sortie cryptée de l'un de vos messages. Dans le haut de gamme, vous êtes confronté à un attaquant qui connaît les paires de texte en clair et de texte chiffré de centaines d'autres messages , qui peut contraindre votre ordinateur à chiffrer d'autres messages avec la même clé =, qui peut surveiller les lignes électriques de votre bâtiment et mesurer les minuscules variations de consommation électrique au fur et à mesure du processus de cryptage , et toutes sortes d'attaques similaires. Les algorithmes de chiffrement standard sont vérifiés pour s'assurer qu'ils résistent même à ces puissants adversaires.
Si vous utilisez d'abord votre propre cryptage, même si la deuxième couche est un cryptage de qualité militaire, vous risquez de diminuer votre sécurité par rapport à l'utilisation du cryptage standard.
Par exemple, supposons que vous chiffrez du texte. Vous utilisez d'abord un simple chiffre de substitution puis utilisez votre choix d'algorithme de frappe lourde. Malheureusement, les chiffres de substitution dépendent intrinsèquement de la recherche de tableaux à partir d'informations privées (c'est-à-dire votre texte en clair et votre clé). Cela les rend vulnérables aux attaques de synchronisation: en raison de la façon dont les caches CPU fonctionnent si deux lettres dans le texte en clair sont proches, elles crypteront probablement plus rapidement que deux lettres plus éloignées. Cela ne ressemble pas à beaucoup d'informations, mais si un attaquant peut regarder suffisamment de cryptages, il peut potentiellement déterminer ce qu'est le texte en clair sans devoir craquer AES ou tout ce que vous utilisez en haut.
Si votre couche de cryptage personnalisée n'interagit pas du tout avec les informations secrètes: c'est-à-dire qu'elle fonctionne avec des données qui ont déjà été suffisamment cryptées pour la transmission et ne touche pas les clés du cryptage standard, alors cela peut être sûr. Au moins, il ne sera pas possible de contourner le cryptage standard. Il existe cependant des risques, car chaque logiciel supplémentaire comporte des risques supplémentaires. Peut-être qu'un bogue dans votre couche personnalisée permet à un adversaire distant d'exécuter des commandes arbitraires sur votre machine; alors ils pourraient simplement envoyer le texte en clair!
Le message à retenir, alors, est que le fait d'avoir un morceau d'excellent code de sécurité bien vérifié et sans bogue comme une fonction de cryptage standard peut toujours être compromis si vous mettez un programme développé par un buggy (de toute sorte, cryptage ou autre) sur le même système.
Facile. Ne faites pas cela.
Tout d'abord, les algorithmes de chiffrement sont conçus pour que vous, moi et tout le monde autour de nous puisse le regarder et essayer de le casser. Vous pouvez littéralement regarder les mathématiques pour AES . Beaucoup de gens intelligents ont investi du temps pour valider AES. C'est un principe de bon chiffrement et pourquoi nous pouvons lui faire confiance.
Deuxièmement, l'obscurité n'est jamais une option de "sécurité". Cela n'apporte aucun avantage. Si vous y croyez réellement, je vous renvoie à "la loi de Schneier" .
N'importe qui peut inventer un système de sécurité qu'il ne peut lui-même casser. Je l'ai dit si souvent que Cory Doctorow l'a nommée "Loi 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 sont vous?" Montrez-moi ce que vous avez cassé pour démontrer que votre affirmation de la sécurité du système signifie quelque chose. - Bruce Schneier, 2016
Tout ce que vous avez fait, c'est:
- Introduisez des risques inutiles dans votre application
- Augmentation du temps de débogage pour les problèmes
- Temps CPU ajouté pour une fonction sans valeur
Le principal le plus élémentaire de la sécurité. Keep It Simple Stupid (KISS).
La sécurité par obscurité est bonne, parfois même génial, tant que ce n'est pas la seule couche de sécurité sur laquelle vous comptez. Mais dans votre cas, je crains que cela n'en vaille pas la peine.
Prenons l'exemple de GPG. Si vous utilisez GPG pour crypter un fichier avec AES, il aura un en-tête qui permet à un attaquant de le reconnaître comme un fichier GPG crypté avec AES. Si vous utilisez ensuite un cryptage personnalisé pour crypter le fichier GPG, vous obtiendrez un fichier qui pourrait être méconnaissable. Un attaquant pourrait supposer à tort que vous utilisez n'importe quel type de cryptage (et perdre beaucoup de temps pour rien), ou pourrait supposer que vous utilisez votre cryptage personnalisé, puis décider d'utiliser des techniques de cryptanalyse pour analyser votre fichier (et réussir à le décrypter si il est assez bon ou votre algorithme suce assez). D'un autre côté, si vous le faites dans l'autre sens (chiffrez d'abord avec un algorithme personnalisé puis avec AES), le scénario ne change pas de manière significative après tout.
Cela dit, je crains que cela n'en vaille pas la peine car le cryptage personnalisé a un énorme con de toute façon: vous devrez stocker votre logiciel de cryptage quelque part, et votre logiciel est totalement personnalisé, ce qui signifie que si pour quelque chose raison pour laquelle vous le perdez (sauvegardes perdues ou volées, etc.) vous êtes foutu et vous ne pourrez récupérer aucune de vos données.
Une meilleure solution pourrait être d'utiliser plusieurs couches de chiffrement à l'aide d'algorithmes déjà connus et disponibles. Par exemple, GPG semble prendre en charge le double poisson, le camélia, etc. Je n'ai aucune expérience pour savoir quels algorithmes devraient être considérés comme les plus sûrs, à part AES. Quoi qu'il en soit, à titre d'exemple, AES -> TWOFISH -> CAMELLIA est probablement une bien meilleure solution que votre AES -> CUSTOM_ALGO. Bien sûr, à condition d'utiliser différents mots de passe forts pour chaque couche de chiffrement!
OPSEC? ...
Mettre des barrières supplémentaires entre les informations critiques et un adversaire est une bonne idée en général, à condition que cela soit fait efficacement.
L'obscurité en tant que mesure de sécurité significative est traitée par le principe de l'OPSEC (sécurité opérationnelle). En bref, cela implique de priver un adversaire de toute information qui pourrait l'aider à compromettre votre organisation via des méthodes sociales ou techniques.
Avec une bonne cryptographie, cependant, garder les clés secrètes est suffisant pour protéger vos données. Toutes les couches techniques supplémentaires doivent être justifiées par leurs propres mérites techniques.
... Ou buste
La cryptographie est une discipline mathématique très compliquée, et de petites erreurs peuvent avoir d'énormes conséquences. Lorsqu'il s'agit de cryptographie, supposez que la valeur d'un algorithme est pratiquement nulle, sauf indication contraire d'un expert de confiance.
Aux États-Unis, les NSA et NIST sont respectivement les évaluateurs officiels des algorithmes et des implémentations cryptographiques. Si vous ne savez pas où chercher des opinions ou si vous voulez une base raisonnable pour les politiques internes, commencez Là.
En pratique, encapsuler un bon crypto est inutile. Une fois qu'un attaquant rencontre un bon crypto, il pivote et attaque généralement les points de terminaison où les données non cryptées sont exposées.
Il peut s'agir du serveur Web où les utilisateurs fournissent des informations, du système SCADA qui alimente votre base de données ou des postes de travail où les employés analysent ou surveillent les informations. Si vous disposez d'une pompe de données qui extrait des informations d'une base de données et les convertit dans un autre format pour la livraison à un fournisseur/client, c'est une autre grande cible. Alternativement, ils pourraient aller chercher vos clés.
Sur l'équilibre
L'ajout de fonctionnalités à une application a une chance non nulle d'introduire des bogues et de compliquer le dépannage. Cela peut entraîner des temps d'arrêt prolongés en cas de problème ou des réponses plus lentes aux failles de sécurité de l'application. En raison de ces facteurs, une caractéristique de sécurité de peu ou pas de valeur est un inconvénient plutôt qu'une amélioration.
Si vous souhaitez vous protéger contre une attaque potentielle sur AES, vous devez simplement utiliser un autre standard de cryptographie basé sur un algorithme approuvé plutôt que de développer le vôtre. Vous obtiendrez une meilleure sécurité avec moins d'effort.
Il y a deux problèmes principaux avec le mode de sécurité et d'obscurité.
L'obscurité peut interférer avec la sécurité. Si vous lancez votre propre crypto, il est très probable qu'il soit défectueux. Même les meilleurs systèmes ont des défauts, même si les meilleurs experts y ont travaillé pendant des décennies. Les chances que vous puissiez faire mieux que la communauté de la sécurité sont faibles.
Peu de choses sont vraiment obscures. Il n'y a pas beaucoup de nouvelles idées en crypto et tout ce que vous faites est susceptible d'être une variation de quelque chose qui a été fait auparavant, donc ce n'est pas si obscur que ça. Les modifications mineures sont quelque chose que les attaquants ont l'habitude de gérer.
Il est facile de voir que la première variante (dernier algorithme personnalisé) ne peut pas compromettre la sécurité d'un cryptage bien connu, car si c'était le cas, ce serait une méthode pour casser le cryptage bien connu. Après tout, les attaquants pourraient également exécuter l'algorithme personnalisé sur un cryptage crypté uniquement avec le cryptage bien connu s'il les aidait à le déchiffrer.
L'autre direction (algorithme personnalisé en premier) pourrait en effet compromettre la sécurité de l'algorithme bien connu en introduisant une redondance dans l'entrée en texte clair du cryptage bien connu, ce qui pourrait potentiellement affaiblir cet algorithme.
Par exemple, prenez le schéma de "cryptage" personnalisé totalement imparfait suivant: répétez le texte en clair deux fois pour produire un "cyphertext". Cela conduit à une quantité extrême de redondance supplémentaire dans l'entrée du deuxième algorithme, ce qui pourrait affaiblir certains cryptages réels. (Qu'il affaiblisse ou non AES est une question différente.) Cela s'est réellement produit avec Enigma , où les opérateurs ont répété une séquence de trois lettres dans son texte en clair qui a rendu son texte crypté vulnérable à certains types d'attaques. Citant de la Cryptanalyse de la page Wikipedia d'Enigma :
Le deuxième problème était la répétition de la clé de message dans l'indicateur, ce qui était une grave faille de sécurité. Le paramètre de message a été codé deux fois, ce qui a entraîné une relation entre le premier et le quatrième, le deuxième et le cinquième, ainsi que le troisième et le sixième caractère. Ce problème de sécurité permit au bureau de chiffrement polonais de pénétrer dans le système Enigma d'avant-guerre dès 1932. Le 1er mai 1940, les Allemands modifièrent les procédures pour chiffrer la clé de message une seule fois.
Comme cela a été dit: Qui est l'attaquant?
C'est vraiment ce que vous devez découvrir et définir en premier!
Est-ce votre grand-mère technophobe qui a des problèmes avec la télécommande du téléviseur? Votre petite (et très curieuse) sœur? Votre père, qui programme et gère les ordinateurs et sait comment retirer un disque dur? L'intimidateur de l'école locale qui vous travaille? Crime organisé? Une entreprise qui peut dépenser des millions pour louer des ordinateurs cloud pour une attaque de crack? Un dictateur du tiers monde? FBI, NSA ou agences équivalentes dans votre propre pays? Une puissance mondiale qui a un excellent service d'espionnage et qui ne vous dérange pas les sacs mortuaires pour vous avoir?
Deuxièmement: quelle sécurité supplémentaire réelle votre "cryptage" 1 vous donnerait-il contre vos attaquants? À moins que vous ne puissiez expliquer pourquoi le cryptage du texte chiffré à nouveau [2] est nécessaire ou très utile, vous ne devriez pas le faire. Plus de complexité ne signifie pas plus de sécurité, cela signifie plus de bugs et plus de chances que les choses ne fonctionnent pas correctement?
Et pourquoi les attaquants ne s'introduisent-ils pas par effraction dans votre maison et ne placent-ils pas un logiciel espion ou un enregistreur de frappe sur votre ordinateur? Êtes-vous sûr que votre cryptage sera d'une quelconque aide contre la crypto-analyse de tuyau en caoutchouc [3], ou s'il n'y a aucune chance de cela, qui est assez puissant pour briser l'AES mais incapable de vous atteindre ou de vous faire chérir et de vous rapprocher?
Disons simplement que votre chance d'obtenir le cryptage fort et sécurisé est à peu près aussi élevée que ma chance de marcher sur la lune; avec le cryptage, non seulement tout doit fonctionner avec la bonne clé, mais rien ne peut fonctionner sans elle ...
Je ne connais aucun cryptosystème construit par quelqu'un en dehors du domaine qui ne s'est pas fissuré lors de la vérification par des experts, et combien de systèmes de cryptage solides inventés par les meilleurs experts ont été brisés?
Un exemple serait la communication de la Seconde Guerre mondiale de l'Allemagne aux sous-marins. Certaines communications très secrètes étaient "réservées aux officiers", qui étaient cryptées, des méta-informations étaient ajoutées et les deux étaient ensuite cryptées par la clé régulière et envoyées. À la réception, l'opérateur radio/Enigma décrypterait le message et transmettrait les métadonnées et le bloc toujours crypté à l'officier. ( voir ici par exemple )
"dans lequel un tuyau en caoutchouc est appliqué avec force et fréquemment sur la plante des pieds jusqu'à ce que la clé du cryptosystème soit découverte, un processus qui peut prendre un temps étonnamment court et qui est assez peu coûteux en calcul."
La solution 1 pourrait potentiellement réduire la sécurité si vous utilisez la même clé secrète pour chiffrer AES et CustomEncryptionAlgorithm.
CustomEncryptionAlgorithm peut permettre la déduction de la clé secrète et donc compromettre également AES.
Si vous créez une clé unique pour CustomEncryptionAlgorithm, tout devrait bien se passer.
Quelque chose comme KEY = SHA-2 (AES-CipherText)
Le problème est qu'il est possible que votre fonction de chiffrement personnalisée présente un bogue et qu'elle réduise en quelque sorte la sécurité. La seule façon pour vous d'être sûr que votre CustomEncryptionAlgorithm ne réduit pas votre sécurité est d'avoir des chercheurs plus intelligents que vous, moi et le reste de votre équipe réunis pour en parler et vérifier votre travail. Mais alors ce n'est pas du tout obscur.
Pour faire un exemple extrême:
public string CustomEncryptionAlgorithm(string plaintext) {
var ciphertext = plaintext.shuffle();
return "password";
return ciphertext; // ya ya. I know. You'd never make a bug that obvious.
// tell it to the guy who did the 'goto bug' at Apple
}
Vous obtiendriez quelque chose comme ça en conséquence si vous utilisiez ce schéma:
AES -> CipherText -> CustomEncryptionAlgorithm-> CipherText:
'abcABC123!@#' -> 'password' 'correct_horse_staple_battery' -> 'password' 'password' -> 'password'
En revanche, si vous avez utilisé l'autre schéma:
CustomEncryptionAlgorithm -> CipherText -> AES -> CipherText
'abcABC123!@#' -> '8ZnO44trPK48kqr3rDxkdQ==' 'correct_horse_staple_battery' -> '8ZnO44trPK48kqr3rDxkdQ==' 'password' -> '8ZnO44trPK48kqr3rDxkdQ=='
Un peu mieux, peut-être. Mais toujours pas bon du tout.
C'est mauvais, mauvais , mauvais.
Il y a une anecdote d'un protocole mobile d'Extrême-Orient pour l'initialisation SIM ou quelque chose de similaire, qui a utilisé une combinaison de RSA (bon, sécurisé et fort) et quelque chose de homebrewed.
La faiblesse décisive n'était pas seulement le cryptage "additionnel" fait maison. Mais le problème était qu'en fait, il y avait un cas spécial où la méthode supplémentaire était associative avec RSA, ce qui provoquait un saignement partiel des clés. Je ne me souviens pas des détails, comme on me l'a dit comme anecdote de conférence il y a de nombreuses années.
Mais le point est vrai: avec un ajout homebrew incorrect à un protocole autrement sécurisé, vous pourriez rendre le protocole plus faible que sa version d'origine. Donc, c'est un non majeur.
Vous vous référez au deuxième algorithme comme de l'obscurité, vous semblez donc supposer qu'il n'ajoute aucune sécurité.
S'il n'ajoute en fait pas de sécurité, pourquoi l'utiliser? Utilisez le deuxième mot de passe en plus du premier pour le cryptage aes. Un mot de passe deux fois plus long est beaucoup plus sûr que deux mots de passe (exemple: 2^2+2^2 = 4 contre. 2^4 = 16), surtout quand le deuxième algorithme n'est pas sûr de toute façon.
Réponse courte: c'est possible, mais pas dans votre exemple.
Réponse longue: D'autres réponses ont suffisamment expliqué pourquoi votre exemple n'est pas si utile et peut blesser. Cela dit, l'obscurité peut être très utile. Exemple: ne placez pas SSH sur le port 22. Si vous passez de 22 à 2222, vous aurez une infime fraction des tentatives de force brute que vous auriez autrement. Si vous passez au port 10000 + Rand(1,55535), ils disparaîtront probablement complètement. Un autre exemple est le cognement de port. Fondamentalement, l'obscurité est surtout utile dans le processus de connexion, pas dans le cryptage ou les mots de passe.
Si c'est fait correctement: bien sûr. La question est de savoir comment savez-vous que c'est correct? Vous pouvez certainement écrire quelque chose qui fuit des informations à travers différentes couches. Le plus évident est la longueur et les répétitions. L'utilisation de la même clé peut également poser problème.
Il est tout simplement trop difficile de dire ce qui est bien et tout le reste. Bien sûr, vous pourriez faire valoir que l'utilisation de ROT13 avant AES le rend un peu sûr et mon intuition dirait ... eh bien, cela ne peut pas faire de mal, mais je ne sais pas vraiment.
Mon intuition dirait que si vous appliquez un algorithme qui produit une sortie indiscernable du hasard sans changer la longueur, puis appliquez AES, cela ne devrait pas au moins réduire la sécurité d'AES.
L'obscurité fait partie de ne sécurité (générale) et est orthogonale à la sécurité (le cryptage AES dans votre cas). L'obscurité se défend contre des menaces différentes de la crypto. Prenez les mots de passe par exemple - les hachages cryptographiques sont nécessaires pour empêcher les fuites de texte en clair du serveur, TLS empêche d'écouter le trafic réseau, tandis que l'obscurité étant un formulaire de mot de passe remplissant avec [*******] empêche de jeter un œil à votre texte en clair par un spectateur aléatoire. Vous ne pouvez donc pas faire de sécurité par obscurité (uniquement), mais la sécurité avec obscurité est généralement la voie à suivre. Dans le monde réel, l'obscurité signifie cacher les métadonnées, par ex. mailing avec BCC au lieu de CC/To ou blocage des cookies tiers.