Question:
Obligé d'utiliser un IV statique (AES)
Mantorok
2010-12-10 21:44:35 UTC
view on stackexchange narkive permalink

Nous avons dû étendre notre site Web pour communiquer les informations d'identification de l'utilisateur au site Web d'un fournisseur (dans la chaîne de requête) en utilisant AES avec une clé de 256 bits, mais ils utilisent un IV statique lors du déchiffrement des informations.

J'ai indiqué que l'IV ne devrait pas être statique et que ce n'est pas dans nos normes de le faire, mais s'ils le modifient de leur côté, nous engagerons les [gros] coûts, nous avons donc accepté de l'accepter comme un risque de sécurité et utiliser le même IV (à ma grande frustration).

Ce que je voulais savoir, c'est à quel point est-ce une menace pour la sécurité? Je dois être en mesure de le communiquer efficacement à la direction afin qu’elle sache exactement ce qu’elle accepte.

Nous utilisons également la même CLÉ partout.

Merci

Trois réponses:
#1
+40
Thomas Pornin
2010-12-10 22:54:49 UTC
view on stackexchange narkive permalink

Cela dépend du mode de chaînage. AES est un chiffrement par bloc, il est appliqué sur des blocs de 16 octets (exactement). Le mode de chaînage définit comment les données d'entrée deviennent plusieurs de ces blocs et comment les blocs de sortie sont ensuite assemblés. La plupart des modes de chaînage doivent fonctionner avec une sorte de "valeur de départ", qui n'est pas secrète mais devrait changer pour chaque message: c'est le IV.

Réutiliser le même IV est mortel si vous utilisez le chaînage CTR mode. En mode CTR, AES est utilisé sur une séquence de contre-valeurs successives (commençant par IV), et la séquence résultante de blocs chiffrés est combinée (par XOR au niveau du bit) avec les données à chiffrer (ou déchiffrer). Si vous utilisez le même IV, vous obtenez la même séquence, qui est le fameux "pad à deux temps". Fondamentalement, en XORing deux chaînes cryptées ensemble, vous obtenez le XOR des deux données en texte clair. Cela ouvre à un très grand nombre d'attaques, et fondamentalement tout est cassé.

Les choses sont moins graves si vous utilisez CBC. Dans CBC, les données elles-mêmes sont divisées en blocs de 16 octets. Lorsqu'un bloc doit être chiffré, il est d'abord XORé avec le bloc chiffré précédent. Le IV a le rôle du bloc "-1" (le bloc chiffré précédent pour le premier bloc). La principale conséquence de la réutilisation de l'IV est que si deux messages commencent par la même séquence d'octets, les messages chiffrés seront également identiques pour quelques blocs. Cela fuit des données et ouvre la possibilité de certaines attaques.

Pour résumer, ne faites pas cela. Utiliser le même IV avec la même clé a toujours et à jamais vaincu l'objectif de l'IV, la raison pour laquelle un mode de chaînage avec IV a été utilisé en premier lieu.

Je viens de dire que la réponse de Thomas Pornin (et le commentaire de GregS) sont absolument correctes. Pour info, Thomas Pornin est un cryptographe et cryptanalyste très respecté.
C'est la bonne réponse. Si vous avez la possibilité d'insérer des données aléatoires quelque part dans le message avant que les données ne deviennent sensibles, vous devriez être en or (les données aléatoires serviront de IV d'un pauvre homme). Vous devez utiliser au moins l'équivalent d'un bloc de données aléatoires. Par exemple, si vous envoyez un message au format XML et que vous pouvez insérer un attribut `random-data =" # {base_64_encode (secure_random_bytes (32))} "` dans l'élément racine XML (sans rompre les schémas ou les contrats) , cela devrait se substituer. Mais autant que possible, vous devriez éviter la cryptographie du pauvre homme.
J'ai trouvé https://crypto.stackexchange.com/questions/3883/ utile pour en savoir plus sur les raisons pour lesquelles CBC avec une IV statique peut être problématique (sans doute, les deux questions sont des doublons).
#2
+8
user185
2010-12-10 22:46:27 UTC
view on stackexchange narkive permalink

Utiliser le même IV pour toutes les données équivaut à ne pas utiliser du tout un IV - le premier bloc de texte chiffré sera identique pour un texte clair identique. Je serais intéressé de savoir pourquoi votre fournisseur souhaite utiliser une IV constante, mais ce n'est pas la question. Le fait est que le système est sensible de cette manière: si un attaquant peut définir ses propres informations d'identification et observer le texte chiffré généré, il peut le comparer avec d'autres informations d'identification chiffrées pour trouver des informations sur la clé.

Les 2 premières phrases de cette réponse sont correctes, mais la dernière phrase est fausse. Un IV statique ne révèle pas d'informations sur la clé AES. Il révèle des informations sur le premier bloc de texte en clair, comme vous l'indiquez.
@D.W. Je ne suis pas un cryptanalyste suffisamment expert pour vérifier cela, mais cela signifie que je peux accepter que je me trompe. Si vous pouvez fournir une référence démontrant cela, je modifierai la réponse (ou vous pouvez ;-).
C'est la conséquence d'un fait fondamental: il n'y a aucun moyen possible connu de trouver la clé AES par une attaque de texte chiffré uniquement, de texte en clair connu ou de texte en clair choisi. Je ne saurais pas où vous donner une référence à ce sujet; une bonne classe sur la cryptographie, peut-être, ou peut-être un manuel récent sur la cryptographie. Peut-être [ceci] (http://stackoverflow.com/questions/810533/is-it-possible-to-reverse-engineer-aes256). Si AES était sensible à une attaque en clair choisi qui révélait des informations sur la clé, elle n'aurait pas été choisie par le NIST: c'est l'une des exigences les plus fondamentales pour un chiffrement par bloc.
#3
+2
Steve
2010-12-10 22:32:53 UTC
view on stackexchange narkive permalink

Je ne suis pas un spécialiste de la cryptographie, mais je crois comprendre que si l'IV ne change pas et que la même valeur est rechiffrée, la sortie sera la même. Par conséquent, il serait possible de déduire le contenu en recherchant des valeurs répétitives, telles qu'un identifiant qui est transmis à chaque demande.

Encore une fois, je ne suis pas un crypto, donc je peux me tromper.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...