En 1998, Daniel Bleichenbacher a montré qu’un serveur qui veut bien dire « ce remplissage est faux » en laisse assez filtrer pour déchiffrer un message sans détenir la clé. GHSA-5739-39v2-5754 est la même idée, dans un chemin de déchiffrement JWE.
L’oracle
RSACrypt::decryptWithRSA15(), employée par l’algorithme de chiffrement de clé RSA1_5, contrôlait le remplissage PKCS#1 v1.5 et signalait l’échec quand il était mal formé.
Ce seul bit d’information, valable ou non, est l’oracle. Un attaquant soumet des chiffrés fabriqués de façon adaptative et, d’après le motif des réponses, retrouve la clé de chiffrement de contenu. Aucune clé privée nécessaire, seulement de la patience et un serveur qui répond honnêtement.
Le correctif contre-intuitif
Le remède s’appelle le rejet implicite, et il consiste à ne rien rejeter de façon visible.
Quand le remplissage est mal formé, l’implémentation ne lève pas d’erreur. Elle rend une valeur aléatoire de la longueur attendue, dérivée de façon déterministe de la clé et du chiffré. Le déchiffrement se poursuit alors et échoue plus tard, sur l’étiquette d’authentification, exactement comme il le ferait pour n’importe quelle autre mauvaise clé.
L’attaquant voit un seul comportement dans les deux cas. L’oracle a disparu, non parce que le contrôle a disparu mais parce que son issue a cessé d’être observable.
Le temps constant en fait partie
Rendre la même réponse ne suffit pas si elle arrive à un autre moment. Une comparaison qui s’arrête au premier octet faux dit à l’attaquant combien d’octets étaient bons, par le seul chronométrage. Le chemin corrigé compare à temps constant, de sorte que la durée ne révèle rien non plus.
Ce que vous devriez faire
Mettre à jour, bien sûr : 3.4.10, 4.0.7 ou 4.1.7.
Mais le meilleur geste est de cesser complètement d’enregistrer RSA1_5. Son remplissage est une source d’oracles depuis un quart de siècle, et chaque implémentation porte la charge de réussir l’atténuation. RSA-OAEP-256 ou ECDH-ES font le même travail sans le passé.