Attaque de l'oracle de rembourrage

En cryptographie, une attaque par oracle de remplissage est une attaque qui utilise la validation de remplissage d'un message cryptographique pour déchiffrer le texte chiffré. En cryptographie, les messages en texte clair de longueur variable doivent souvent être remplis (développés) pour être compatibles avec la primitive cryptographique sous-jacente . L'attaque repose sur la présence d'un « oracle de remplissage » qui répond librement aux requêtes pour savoir si un message est correctement rempli ou non. Les informations peuvent être fournies directement ou divulguées via un canal auxiliaire .

La première attaque connue utilisant un oracle de remplissage est l'attaque de Bleichenbacher de 1998, qui attaque RSA avec un remplissage PKCS #1 v1.5 . Le terme « oracle de remplissage » est apparu dans la littérature en 2002, après l'attaque de Serge Vaudenay sur le déchiffrement en mode CBC utilisé dans les chiffrements par blocs symétriques . Des variantes des deux attaques continuent de rencontrer du succès plus d'une décennie après leur publication originale.

Cryptographie asymétrique

En 1998, Daniel Bleichenbacher a publié un article fondateur sur ce qui est devenu connu sous le nom d'attaque de Bleichenbacher (également connue sous le nom d'« attaque par million de messages »). L'attaque utilise un oracle de remplissage contre RSA avec un remplissage PKCS #1 v1.5 , mais elle n'inclut pas le terme. Les auteurs ultérieurs ont classé son attaque comme une attaque d'oracle de remplissage.

Manger (2001) signale une attaque sur le remplacement du remplissage PKCS #1 v1.5, PKCS #1 v2.0 « OAEP ».

Cryptographie symétrique

En cryptographie symétrique, l' attaque par oracle de remplissage peut être appliquée au mode de fonctionnement CBC . Les données divulguées sur la validité du remplissage peuvent permettre aux attaquants de déchiffrer (et parfois de chiffrer) des messages via l'oracle à l'aide de la clé de l'oracle, sans connaître la clé de chiffrement.

Comparée à l'attaque de Bleichenbacher sur RSA avec PKCS #1 v1.5, l'attaque de Vaudenay sur CBC est beaucoup plus efficace. Les deux attaques ciblent les systèmes de cryptographie couramment utilisés à l'époque : CBC est le mode d'origine utilisé dans Secure Sockets Layer (SSL) et a continué à être pris en charge dans TLS.

Un certain nombre de mesures d'atténuation ont été mises en œuvre pour empêcher le logiciel de décryptage d'agir comme un oracle, mais de nouvelles attaques basées sur le timing ont à plusieurs reprises ravivé cet oracle. TLS 1.2 introduit un certain nombre de cryptages authentifiés avec des modes de données supplémentaires qui ne reposent pas sur CBC.

Attaque de type oracle de remplissage sur le chiffrement CBC

L'implémentation standard du déchiffrement CBC dans les chiffrements par blocs consiste à déchiffrer tous les blocs de texte chiffré, à valider le remplissage, à supprimer le remplissage PKCS7 et à renvoyer le texte en clair du message. Si le serveur renvoie une erreur « remplissage non valide » au lieu d'une erreur générique « échec du déchiffrement », l'attaquant peut utiliser le serveur comme un oracle de remplissage pour déchiffrer (et parfois chiffrer) les messages.

La formule mathématique pour le décryptage CBC est

{\displaystyle P_{i}=D_{K}(C_{i})\oplus C_{i-1}, <semantics> <mrow> <mstyle> <msub> <mi>P</mi> <mrow> <mi>je</mi> </mrow> </msub> <mo>=</mo> <msub> <mi>D</mi> <mrow> <mi>K</mi> </mrow> </msub> <mo>(</mo> <msub> <mi>C</mi> <mrow> <mi>je</mi> </mrow> </msub> <mo>)</mo> <mo>⊕</mo> <msub> <mi>C</mi> <mrow> <mi>je</mi> <mo>−</mo> <mn>1</mn> </mrow> </msub> <mo>,</mo> </mstyle> </mrow> <annotation>{\displaystyle P_{i}=D_{K}(C_{i})\oplus C_{i-1},}</annotation> </semantics> </math></span><img src=

{\displaystyle C_{0}=IV. <semantics> <mrow> <mstyle> <msub> <mi>C</mi> <mrow> <mn>0</mn> </mrow> </msub> <mo>=</mo> <mi>je</mi> <mi>V</mi> <mo>.</mo> </mstyle> </mrow> <annotation>{\displaystyle C_{0}=IV.}</annotation> </semantics> </math></span><img src=

Comme illustré ci-dessus, le déchiffrement CBC effectue un XOR pour chaque bloc de texte en clair avec le bloc précédent. Par conséquent, une modification d'un seul octet dans block entraînera une modification correspondante sur un seul octet dans . ${\displaystyle C_{1 <semantics> <mrow> <mstyle> <msub> <mi>C</mi> <mrow> <mn>1</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle C_{1}}</annotation> </semantics> </math><img src=$ ${\displaystyle P_{2 <semantics> <mrow> <mstyle> <msub> <mi>P</mi> <mrow> <mn>2</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle P_{2}}</annotation> </semantics> </math><img src=$

Supposons que l'attaquant dispose de deux blocs de texte chiffré et souhaite déchiffrer le deuxième bloc pour obtenir le texte en clair . L'attaquant modifie le dernier octet de (création de ) et l'envoie au serveur. Le serveur renvoie ensuite si le remplissage du dernier bloc déchiffré ( ) est correct ou non (un remplissage PKCS#7 valide). Si le remplissage est correct, l'attaquant sait maintenant que le dernier octet de est , les deux derniers octets sont 0x02, les trois derniers octets sont 0x03, …, ou les huit derniers octets sont 0x08. L'attaquant peut modifier l'avant-dernier octet (inverser n'importe quel bit) pour s'assurer que le dernier octet est 0x01. (Alternativement, l'attaquant peut retourner les octets précédents et rechercher binairement la position pour identifier le remplissage. Par exemple, si la modification de l'avant-dernier octet est correcte, mais que la modification de l'avant-dernier octet est incorrecte, alors les deux derniers octets sont connus comme étant 0x02, ce qui permet aux deux d'être déchiffrés.) Par conséquent, le dernier octet de est égal à . Si le remplissage est incorrect, l'attaquant peut changer le dernier octet de à la valeur possible suivante. Au maximum, l'attaquant devra faire 256 tentatives pour trouver le dernier octet de , 255 tentatives pour chaque octet possible (256 possibles, moins un par principe de casier ), plus une tentative supplémentaire pour éliminer un remplissage ambigu. ${\displaystyle C_{1},C_{2 <semantics> <mrow> <mstyle> <msub> <mi>C</mi> <mrow> <mn>1</mn> </mrow> </msub> <mo>,</mo> <msub> <mi>C</mi> <mrow> <mn>2</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle C_{1},C_{2}}</annotation> </semantics> </math><img src=$ ${\displaystyle P_{2 <semantics> <mrow> <mstyle> <msub> <mi>P</mi> <mrow> <mn>2</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle P_{2}}</annotation> </semantics> </math><img src=$ ${\displaystyle C_{1 <semantics> <mrow> <mstyle> <msub> <mi>C</mi> <mrow> <mn>1</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle C_{1}}</annotation> </semantics> </math><img src=$ ${\displaystyle C_{1}' <semantics> <mrow> <mstyle> <msubsup> <mi>C</mi> <mrow> <mn>1</mn> </mrow> <mo>′</mo> </msubsup> </mstyle> </mrow> <annotation>{\displaystyle C_{1}'}</annotation> </semantics> </math><img src=$ ${\displaystyle (IV,C_{1}',C_{2}) <semantics> <mrow> <mstyle> <mo>(</mo> <mi>je</mi> <mi>V</mi> <mo>,</mo> <msubsup> <mi>C</mi> <mrow> <mn>1</mn> </mrow> <mo>′</mo> </msubsup> <mo>,</mo> <msub> <mi>C</mi> <mrow> <mn>2</mn> </mrow> </msub> <mo>)</mo> </mstyle> </mrow> <annotation>{\displaystyle (IV,C_{1}',C_{2})}</annotation> </semantics> </math><img src=$ ${\displaystyle P_{2}' <semantics> <mrow> <mstyle> <msubsup> <mi>P</mi> <mrow> <mn>2</mn> </mrow> <mo>′</mo> </msubsup> </mstyle> </mrow> <annotation>{\displaystyle P_{2}'}</annotation> </semantics> </math><img src=$ ${\displaystyle D_{K}(C_{2})\oplus C_{1}' <semantics> <mrow> <mstyle> <msub> <mi>D</mi> <mrow> <mi>K</mi> </mrow> </msub> <mo>(</mo> <msub> <mi>C</mi> <mrow> <mn>2</mn> </mrow> </msub> <mo>)</mo> <mo>⊕</mo> <msubsup> <mi>C</mi> <mrow> <mn>1</mn> </mrow> <mo>′</mo> </msubsup> </mstyle> </mrow> <annotation>{\displaystyle D_{K}(C_{2})\oplus C_{1}'}</annotation> </semantics> </math><img src=$ ${\displaystyle \mathrm {0x01} <semantics> <mrow> <mstyle> <mrow> <mn>0</mn> <mi>x</mi> <mn>01</mn> </mrow> </mstyle> </mrow> <annotation>{\displaystyle \mathrm {0x01} }</annotation> </semantics> </math><img src=$ ${\displaystyle D_{K}(C_{2}) <semantics> <mrow> <mstyle> <msub> <mi>D</mi> <mrow> <mi>K</mi> </mrow> </msub> <mo>(</mo> <msub> <mi>C</mi> <mrow> <mn>2</mn> </mrow> </msub> <mo>)</mo> </mstyle> </mrow> <annotation>{\displaystyle D_{K}(C_{2})}</annotation> </semantics> </math><img src=$ ${\displaystyle C_{1}'\oplus \mathrm {0x01} <semantics> <mrow> <mstyle> <msubsup> <mi>C</mi> <mrow> <mn>1</mn> </mrow> <mo>′</mo> </msubsup> <mo>⊕</mo> <mrow> <mn>0</mn> <mi>x</mi> <mn>01</mn> </mrow> </mstyle> </mrow> <annotation>{\displaystyle C_{1}'\oplus \mathrm {0x01} }</annotation> </semantics> </math><img src=$ ${\displaystyle C_{1}' <semantics> <mrow> <mstyle> <msubsup> <mi>C</mi> <mrow> <mn>1</mn> </mrow> <mo>′</mo> </msubsup> </mstyle> </mrow> <annotation>{\displaystyle C_{1}'}</annotation> </semantics> </math><img src=$ ${\displaystyle P_{2 <semantics> <mrow> <mstyle> <msub> <mi>P</mi> <mrow> <mn>2</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle P_{2}}</annotation> </semantics> </math><img src=$

Après avoir déterminé le dernier octet de , l'attaquant peut utiliser la même technique pour obtenir l'avant-dernier octet de . L'attaquant définit le dernier octet de à en définissant le dernier octet de à . L'attaquant utilise ensuite la même approche décrite ci-dessus, en modifiant cette fois l'avant-dernier octet jusqu'à ce que le remplissage soit correct (0x02, 0x02). ${\displaystyle P_{2 <semantics> <mrow> <mstyle> <msub> <mi>P</mi> <mrow> <mn>2</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle P_{2}}</annotation> </semantics> </math><img src=$ ${\displaystyle P_{2 <semantics> <mrow> <mstyle> <msub> <mi>P</mi> <mrow> <mn>2</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle P_{2}}</annotation> </semantics> </math><img src=$ ${\displaystyle P_{2 <semantics> <mrow> <mstyle> <msub> <mi>P</mi> <mrow> <mn>2</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle P_{2}}</annotation> </semantics> </math><img src=$ ${\displaystyle \mathrm {0x02} <semantics> <mrow> <mstyle> <mrow> <mn>0</mn> <mi>x</mi> <mn>02</mn> </mrow> </mstyle> </mrow> <annotation>{\displaystyle \mathrm {0x02} }</annotation> </semantics> </math><img src=$ ${\displaystyle C_{1 <semantics> <mrow> <mstyle> <msub> <mi>C</mi> <mrow> <mn>1</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle C_{1}}</annotation> </semantics> </math><img src=$ ${\displaystyle D_{K}(C_{2})\oplus \mathrm {0x02} <semantics> <mrow> <mstyle> <msub> <mi>D</mi> <mrow> <mi>K</mi> </mrow> </msub> <mo>(</mo> <msub> <mi>C</mi> <mrow> <mn>2</mn> </mrow> </msub> <mo>)</mo> <mo>⊕</mo> <mrow> <mn>0</mn> <mi>x</mi> <mn>02</mn> </mrow> </mstyle> </mrow> <annotation>{\displaystyle D_{K}(C_{2})\oplus \mathrm {0x02} }</annotation> </semantics> </math><img src=$

Si un bloc est composé de 128 bits ( AES , par exemple), soit 16 octets, l'attaquant obtiendra le texte en clair en 256⋅16 = 4096 tentatives maximum. C'est nettement plus rapide que les tentatives nécessaires pour forcer une clé de 128 bits. ${\displaystyle P_{2 <semantics> <mrow> <mstyle> <msub> <mi>P</mi> <mrow> <mn>2</mn> </mrow> </msub> </mstyle> </mrow> <annotation>{\displaystyle P_{2}}</annotation> </semantics> </math><img src=$ ${\displaystyle 2^{128 <semantics> <mrow> <mstyle> <msup> <mn>2</mn> <mrow> <mn>128</mn> </mrow> </msup> </mstyle> </mrow> <annotation>{\displaystyle 2^{128}}</annotation> </semantics> </math><img src=$

Cryptage des messages avec l'attaque Padding Oracle (CBC-R)

CBC-R transforme un oracle de décryptage en un oracle de cryptage et est principalement démontré par rapport aux oracles de remplissage.

En utilisant l'attaque Oracle de remplissage, CBC-R peut créer un vecteur d'initialisation et un bloc de texte chiffré pour n'importe quel texte en clair :

décrypter tout texte chiffré P _i = PODecrypt( C _i ) XOR C _i−1 ,
sélectionner librement le bloc de chiffrement précédent C _x−1 ,
produire une paire texte chiffré/texte en clair valide C _x-1 = P _x XOR PODecrypt( C _i ) .

Pour générer un texte chiffré d' une longueur de N blocs, l'attaquant doit effectuer N attaques de type oracle de remplissage. Ces attaques sont enchaînées de manière à ce que le texte en clair approprié soit construit dans l'ordre inverse, de la fin du message ( C _N ) au début du message ( C ₀ , IV). À chaque étape, l'attaque de type oracle de remplissage est utilisée pour construire l'IV du texte chiffré choisi précédemment.

L'attaque CBC-R ne fonctionnera pas contre un schéma de cryptage qui authentifie le texte chiffré (à l'aide d'un code d'authentification de message ou similaire) avant le décryptage.

Attaques utilisant des oracles de remplissage

L'attaque originale contre CBC a été publiée en 2002 par Serge Vaudenay . Des exemples concrets de l'attaque ont été réalisés plus tard contre SSL et IPSec. Elle a également été appliquée à plusieurs frameworks Web , notamment JavaServer Faces , Ruby on Rails et ASP.NET ainsi qu'à d'autres logiciels, tels que le client de jeu Steam . En 2012, elle s'est avérée efficace contre les jetons cryptographiques PKCS 11.

Bien que ces attaques antérieures aient été corrigées par la plupart des implémenteurs TLS après son annonce publique, une nouvelle variante, l' attaque Lucky Thirteen , publiée en 2013, a utilisé un canal auxiliaire de temporisation pour rouvrir la vulnérabilité même dans les implémentations qui avaient été corrigées auparavant. Début 2014, l'attaque n'est plus considérée comme une menace dans les opérations réelles, bien qu'elle soit toujours réalisable en théorie (voir le rapport signal/bruit ) contre une certaine classe de machines. En 2015 , le domaine de développement le plus actif pour les attaques sur les protocoles cryptographiques utilisés pour sécuriser le trafic Internet est celui des attaques de déclassement , telles que les attaques Logjam et Export RSA/FREAK , qui incitent les clients à utiliser des opérations cryptographiques moins sécurisées fournies pour la compatibilité avec les clients existants lorsque des opérations plus sécurisées sont disponibles. Une attaque appelée POODLE (fin 2014) combine une attaque de rétrogradation (vers SSL 3.0) avec une attaque de type padding oracle sur l'ancien protocole non sécurisé pour permettre la compromission des données transmises. En mai 2016, il a été révélé dans CVE - 2016-2107 que le correctif contre Lucky Thirteen dans OpenSSL a introduit un autre oracle de remplissage basé sur le temps.

TLS et SSL