7 A7. Détecter les modifications

7.1 modifications "innocentes"

Il est traditionnel, lors de l'envoi d'un flot de données, de calculer "au vol" le XOR de tous les mots-machine qui sont transmis et de le transmettre à son tour, de sorte que, à la réception, on puisse contrôler que le XOR de tous les mots reçus (checksum compris) est nul. Il est clair que ce protocole a le grand mérite de pouvoir être implémenté de façon transparente dans le hardware des couches basses.

Mais il est clair aussi que ce protocole repose sur le postulat que le taux d'erreur est tellement faible que l'on est certain qu'il ne se produira qu'une seule erreur sur chaque série de bits homotopes dans le message : s'il s'en produisait deux, on ne s'en rendrait pas compte. Une situation dans laquelle ce protocole est bien adapté est celle d'un lecteur de disque ou de disquettes relié par bus à la mémoire principale.

Pour un protocole de transport à haut débit, il est préférable de disposer de l'équivalent de la somme de tous les mots (deux erreurs sur le même locus produisent une retenue, dont on garde trace). Mais cette somme dépend de la taille du mot machine, ou doit être implémentée par logiciel et devient lente à calculer. Le protocole XTP [36] utilise pour sa part un RXOR, rotate and xor, en plus du simple XOR, ce qui détecte mieux les erreurs qui se produisent en rafales.

7.2 modifications malicieuses

Si l'on désire maintenant se protéger non pas seulement contre des "erreurs innocentes" mais de plus garantir la non-modification d'un message par un intrus actif, le problème se complique. Désignant par MM le texte clair et par CHS l'opérateur de checksum, il faut obtenir la quasi-certitude de détecter dès la réception toute modification d'un message du genre : $\left\langle \left\{ MM\right\} _{k}, CHS\left( MM\right) \right\rangle$ ou $\left\langle \left\{ MM, CHS\left( MM\right) \right\} _{k}\right\rangle$. Et en particulier être certain de ce qu'un intrus ne pourra pas profiter de la structure de blocs des algorithmes DES ou RSA pour intercaler des "faux blocs" de telle sorte que l'on ne s'en rende pas compte à la réception, mais seulement à l'utilisation.

Le simple XOR ne répond pas à la question : il suffit d'introduire, à une limite de blocs, deux blocs identiques adjacents : peu importe comment ils seront décodés car les deux seront décodés de la même façon et leur contribution au XOR sera neutre.

Pour le DES, si le mode de chaînage de blocs (CBC-DES) est utilisé, le sabotage précédent sera découvert, mais pas celui qui consiste à permuter deux blocs adjacents [11].

Le chiffrement DES d'un vecteur fixé d'avance par, successivement, tous les blocs du texte en clair donne un checksum plus difficile à "tromper". Une technique serait d'intercaler deux fois de suite un bloc dont on aurait pu inférer qu'il code pour l'une des 16 clefs faibles du DES, comme par exemple le bloc composé uniquement de zéros, puisque ces 16 clefs donnent une transformation involutive de l'espace des messages [29].

On pourrait contrer cette menace par un XOR de chaque bloc avec son numéro d'ordre avant de s'en servir comme clef pour le calcul du checksum : cela donne en tout cas un calcul très lent, sauf si l'on utilise un deuxième composant DES, calculant le CHK en vol, pendant que le premier procède au chiffrement en vol du message.

D'autres techniques de checksum cryptographique sont connues, reposant sur des algorithmes quadratiques. Leur défaut est dans leur lenteur.

7.3 ne pas rendre vérifiable

Quel que soit le procédé choisi, il convient de bien comprendre que le mécanisme de checksum peut présenter un effet pervers. Il permet certes au destinataire d'avoir la certitude pratique de ce que le message reçu est bien, après déchiffrement, identique au texte clair que l'émetteur voulait lui envoyer. Mais il ne faudrait pas pour autant permettre à un intrus d'utiliser le même mécanisme pour se rendre compte de ce qu'il a bien réussi à décrypter le message chiffré.

En effet un procédé de chiffrement résiste incomparablement mieux si le cryptanalyste ne dispose que de la version chiffrée du texte ("attaque à chiffre seul"). Tandis que la connaissance simultanée de la version chiffrée et d'une fraction, même minime du texte d'origine constitue une arme redoutable ("attaque à texte connu").

Et disposer d'un critère simple pour vérifier si l'on a trouvé la bonne clef constitue une version à peine atténuée de cette menace ("attaque à texte vérifiable" [23]). On peut par exemple savoir que tel champ est un petit entier étendu par des zéros pour remplir la zone. Ou bien que le message est en bon anglais, et donc obéit à des lois de fréquences pour les apparitions des caractères, et en particulier en exclut un certain nombre (la Table 19 en donne un exemple).

Table: Un texte vérifiable.

Il ne faut donc pas que le checksum constitue un point faible du chiffrement : s'il constitue la seule partie vérifiable du message, il est alors préférable de le chiffrer avec une clef indépendante (il serait pittoresque d'utiliser une autre clef dérivée du même mot de passe...) et d'envoyer le message : $\left\langle \left\{ MM\right\} _{k1}, \left\{ CHK\left( MM\right) \right\} _{k2}\right\rangle$.

Si l'on souhaite au contraire que le message soit vérifiable à l'aide du checksum (ainsi au paragraphe 4), il faut utiliser une méthode de chiffrement particulièrement résistante aux tentatives systématiques, comme DES-EDE ou RSA. (On remarquera qu'il n'est pas connu si la complexité assurée par une clef DES-EDE sur 2*56 bits est à peu près équivalente au carré de celle du DES simple, ou bien si elle est notablement inférieure).