Calculer la clé de chiffrement AES en fonction du texte en clair et de son texte chiffré?
Je suis chargé de créer des tables de base de données dans Oracle qui contiennent des chaînes chiffrées (c'est-à-dire que les colonnes sont RAW). Les chaînes sont chiffrées par l'application (en utilisant AES, clé 128 bits) et stockées dans Oracle, puis récupérées plus tard d'Oracle et déchiffrées (c'est-à-dire qu'Oracle lui-même ne voit jamais les chaînes non chiffrées).
Je suis tombé sur cette seule colonne qui sera l'une des deux chaînes. Je crains que quelqu'un ne remarque et suppose probablement quelles sont ces deux valeurs pour comprendre la clé AES.
Par exemple, si quelqu'un voit que la colonne est soit Ciphertext # 1 ou # 2:
Ciphertext # 1:
BF,4F,8B,FE, 60,D8,33,56, 1B,F2,35,72, 49,20,DE,C6.Ciphertext # 2:
BC,E8,54,BD, F4,B3,36,3B, DD,70,76,45, 29,28,50,07.
et connaît les Plaintexts correspondants:
Plaintext # 1 ("Detroit"):
44,00,65,00, 74,00,72,00, 6F,00,69,00, 74,00,00,00.Plaintext # 2 ("Chicago"):
43,00,68,00, 69,00,63,00, 61,00,67,00, 6F,00,00,00.
peut-il en déduire que la clé de chiffrement est "Buffalo"?
42,00,75,00, 66,00,66,00, 61,00,6C,00, 6F,00,00,00.
Je pense qu'il ne devrait y avoir qu'une seule clé de 128 bits qui pourrait convertir Plaintext # 1 en Ciphertext # 1. Cela signifie-t-il que je devrais plutôt utiliser une clé 192 bits ou 256 bits ou trouver une autre solution?
(En passant, voici deux autres textes chiffrés pour les mêmes textes en clair mais avec une clé différente.)
Ciphertext # 1 A ("Detroit"):
E4,28,29,E3, 6E,C2,64,FA, A1,F4,F4,96, FC,18,4A,C5.Ciphertext # 2 A ("Chicago"):
EA,87,30,F0, AC,44,5D,ED, FD,EB,A8,79, 83,59,53,B7.
[Question connexe: Lorsque vous utilisez AES et CBC, le IV peut-il être un hachage du texte en clair? ]
J'ajoute une réponse en tant que wiki communautaire parce que je pense que la réponse acceptée est dangereusement trompeuse . Voici mon raisonnement:
La question est de savoir comment pouvoir dériver les clés AES. À cet égard, la réponse acceptée est correcte: c'est ce qu'on appelle une attaque en texte clair connue , et AES est résistant à ce type d'attaque. Ainsi, un attaquant ne pourra pas en tirer parti pour dériver la clé et s'enfuir avec toute la base de données.
Mais il y a une autre attaque potentiellement dangereuse en jeu ici: a Ciphertext Indistinguishablity Attack . De Wikipédia:
L'indiscernabilité du texte chiffré est une propriété de nombreux schémas de chiffrement. Intuitivement, si un cryptosystème possède la propriété de ne pas pouvoir être distingué, un adversaire sera incapable de distinguer des paires de textes chiffrés en fonction du message qu'il crypte.
L'OP nous a montré que cette colonne contient l'une des deux valeurs possibles, et puisque le cryptage est déterministe (c'est-à-dire qu'il n'utilise pas un IV aléatoire), et l'attaquant peut voir quelles lignes ont la même valeur les unes que les autres. Tout ce que l'attaquant a à faire est de trouver le texte en clair de cette colonne pour une seule ligne, et ils ont craqué le cryptage sur toute la colonne. Mauvaise nouvelle si vous voulez que ces données restent privées - je suppose que c'est pourquoi vous les avez cryptées en premier lieu.
Atténuation: Pour vous protéger contre cela, rendez votre cryptage non déterministe (ou du moins apparaissez non déterministe pour l'attaquant) afin que les cryptages répétés de la même chose le texte en clair produit différents textes chiffrés. Vous pouvez par exemple le faire en utilisant AES en mode Cipher Block Chaining (CBC) avec un aléatoire Initialization Vector (IV) . Utilisez un générateur de nombres aléatoires sécurisé pour générer un nouveau IV pour chaque ligne et stocker le IV dans le tableau. De cette façon, sans la clé, l'attaquant ne peut pas dire quelles lignes ont un texte en clair correspondant.
Pour un chiffrement de bloc avec une clé de n bits, si, étant donné un bloc de texte en clair et le texte chiffré correspondant, la clé peut être devinée en moins de 2n-1 pas en moyenne, alors ce chiffrement de bloc sera dit "cassé" et les cryptographes se feront un devoir de ne pas l'utiliser. L'AES n'est pas (encore) cassé. Alors ne vous inquiétez pas.
Cependant, certaines choses peuvent encore être dites:
- Le fait d'avoir un texte en clair et le texte chiffré correspondant permet à un attaquant de vérifier une valeur de clé potentielle.
- Le 2n-1 la valeur est en fait la moitié de la taille de l'espace clé. L'idée est que l'attaquant peut essayer toutes les clés possibles, jusqu'à ce qu'une correspond. En moyenne, il devra essayer la moitié des touches avant de frapper la bonne. Cela suppose que l'espace clé a une taille 2n. Vous avez toujours la possibilité de réduire l'espace des clés: par exemple, si vous décidez que votre clé est le nom d'une ville américaine, alors le nombre de clés possibles est très inférieur (il ne doit pas y avoir plus de 100 000 villes aux États-Unis) . Par conséquent, vous n'obtiendrez la sécurité de 128 bits promise que si votre processus de génération de clés peut effectivement produire une clé de 128 bits.
- Vous cryptez apparemment chaque valeur en la remplissant directement dans un noyau AES. AES étant déterministe, cela signifie que deux cellules avec la même valeur donneront le même bloc chiffré, et tout attaquant peut le remarquer. En d'autres termes, vous divulguez des informations sur les cellules qui sont égales les unes aux autres. Selon votre situation, cela peut ou non être un problème; vous devez en être conscient.
- Vous ne dites pas comment vous gérez des valeurs supérieures à 16 octets. Ce n'est pas un problème simple. En général, cela nécessite un mode de chaînage tel que CBC, et un vecteur d'initialisation (cela dépend du mode; pour CBC, une valeur aléatoire de 16 octets - un nouveau IV pour chaque valeur cryptée) (cela peut également corriger la fuite d'informations du point précédent).
La réponse: non, la clé AES ne peut pas être récupérée dans ce scénario. AES est sécurisé contre les attaques connues en texte brut. Cela signifie que, même si un attaquant connaît le texte en clair et le texte chiffré correspondant (son chiffrement sous une clé AES inconnue), l'attaquant ne peut pas récupérer la clé AES. En particulier, l'attaquant ne peut pas récupérer la clé AES plus rapidement que de simplement essayer les clés possibles les unes après les autres - ce qui prendra plus de temps que la durée de vie de notre civilisation, en supposant que la clé AES est choisie au hasard.
P.S. J'ai remarqué que tout ce que vous utilisez pour le cryptage ne semble pas utiliser un IV. Il s'agit d'un risque pour la sécurité. Je ne sais pas quel mode de fonctionnement vous utilisez, mais vous devez utiliser un mode de cryptage bien considéré (par exemple, le cryptage en mode CBC, le cryptage en mode CTR) avec une IV aléatoire. Le fait que chiffrer plusieurs fois le même message vous donne toujours le même texte chiffré à chaque fois est une fuite de sécurité qu'il vaut mieux éviter. Vous pouvez éviter cette fuite en utilisant un mode de fonctionnement standard avec une IV appropriée. (Vous devriez probablement également utiliser un code d'authentification de message (MAC) pour authentifier le texte chiffré et empêcher toute modification.)
Salez votre cryptage.
De cette façon, il n'y aura aucun motif de cryptage. (Il y a aussi d'autres avantages!)
https://stackoverflow.com/questions/5051007/what-is-the-purpose-of-salt
AES n'est pas aussi simple que de construire une table Rainbow. La première chose que vous devez réaliser est que la table nécessite un vecteur d'initialisation. Tant que vous changez cela sur une base semi-régulière, la construction d'une table Rainbow (ce qui n'est pas vraiment réaliste) prendrait très très longtemps. Des ordres de grandeur longs. Étant donné qu'une table Rainbow typique aurait essentiellement 2 dimensions, vous auriez essentiellement besoin d'un cube d'ensembles de résultats pour comprendre à la fois l'IV et la clé.
Si vous lisez le post de Thomas Pornin, il explique en détail ce que cela signifie, en termes de brutalité forçant le résultat.
Le souci réaliste est qu'une personne ayant accès à la base de données pourrait injecter une chaîne à partir d'un autre champ (probablement parce que vous n'utilisez pas de valeur de remplissage aléatoire dans la colonne par élément. Ou d'amorçage.)
Si vous amorcez la valeur, vous n'aurez pas ce problème, et la seule attaque (réaliste) contre le texte chiffré lui-même est rendue beaucoup plus difficile.