L'attaque à oracle de remplissage (Bleichenbacher)

La dernière grande famille d'attaques ne vise ni les maths ni les clés, mais l'implémentation : ce que le serveur laisse fuir en répondant.

Qu'est-ce qu'un oracle ?

Un oracle est un service qui, sans le vouloir, répond à une question qu'il ne devrait pas. Ici, la question est : « ce déchiffrement a-t-il un remplissage valide ? » Si un serveur qui reçoit un chiffré répond différemment selon que le remplissage PKCS#1 v1.5 obtenu après déchiffrement est correct ou non, il devient un oracle de remplissage.

La fuite peut être grossière (un message d'erreur explicite « bad padding ») ou subtile (un temps de réponse légèrement différent, une connexion coupée plus tôt). Peu importe le canal : un seul bit fuité — valide / invalide — suffit.

L'attaque de Bleichenbacher (1998)

Bleichenbacher a montré comment transformer cet oracle en machine à déchiffrer. L'attaquant ne connaît pas d, mais il exploite la malléabilité de RSA (leçon du chapitre 1) :

Boucle (des milliers, voire des millions de fois) :
  1. choisir un multiplicateur s
  2. calculer  c' = c × s^e mod n       (nouveau chiffré "bricolé")
  3. envoyer c' au serveur
  4. lire la réponse de l'oracle :
        remplissage VALIDE   -> l'info restreint l'intervalle où vit m
        remplissage INVALIDE -> on essaie un autre s
Fin : l'intervalle se resserre jusqu'à un seul m -> message déchiffré

Chaque réponse « valide » apprend à l'attaquant que le message multiplié tombe dans une certaine plage. En répétant, il encadre m de plus en plus finement, jusqu'à le retrouver exactement — sans jamais posséder la clé privée.

Le schéma de l'oracle

   Attaquant                         Serveur (oracle)
      |                                    |
      |----  c' = c × s^e mod n  --------->| déchiffre avec d
      |                                    | teste le remplissage PKCS#1
      |<---  "valide" / "invalide"  -------| (ou : temps de réponse)
      |                                    |
      | resserre l'intervalle de m         |
      |  ... recommence des milliers de fois...
      v
   message m retrouvé

ROBOT : le retour, vingt ans après

En 2017, l'attaque ROBOT (Return Of Bleichenbacher's Oracle Threat) a montré que de nombreux serveurs HTTPS majeurs restaient vulnérables : la faille de 1998 n'avait jamais été vraiment refermée partout. On corrige en ne révélant rien : même réponse et même temps que le remplissage soit valide ou non, et migration vers OAEP plutôt que PKCS#1 v1.5.

La leçon générale

Un chiffrement mathématiquement solide peut être cassé par ce que son implémentation laisse échapper : messages d'erreur distincts, temps de calcul, consommation électrique. Ce sont les attaques par canal auxiliaire. Une bonne implémentation est constante en temps et avare en information.

En résumé

Si un serveur révèle — par une erreur ou un timing — que le remplissage PKCS#1 v1.5 d'un déchiffrement est valide, il devient un oracle. L'attaque de Bleichenbacher (1998), ravivée par ROBOT (2017), déchiffre alors en interrogeant l'oracle des milliers de fois, sans la clé privée. Règle d'or : ne rien laisser fuiter, répondre en temps constant, préférer OAEP.