Le mode CBC (Cipher Block Chaining)

Le mode CBC est l’un des modes d’opération utilisés pour appliquer un algorithme de chiffrement par blocs comme l’AES à des données longues.

Pourquoi le CBC ? — Commençons par le problème de l’ECB

L’AES définit comment chiffrer un seul bloc de 128 bits. Mais les données réelles sont bien plus longues. La façon dont on découpe et enchaîne ces blocs s’appelle le mode d’opération. Le plus simple, l’ECB (Electronic Codebook), chiffre chaque bloc de manière totalement indépendante :

P1 → AES_Enc(K) → C1
P2 → AES_Enc(K) → C2
P3 → AES_Enc(K) → C3

Le problème est immédiat : si P1 = P2, alors C1 = C2. Le même bloc de texte clair produit toujours le même texte chiffré. Les motifs répétitifs dans les données se retrouvent intacts dans le texte chiffré.

Mais au fond, qu’est-ce que ça signifie concrètement que C1 = C2 ?

① C1 = C2 est en soi une fuite d’information. Même sans connaître le contenu, un attaquant qui observe que C1 = C2 sait immédiatement que les blocs 1 et 2 contiennent le même texte clair. C’est suffisant pour lancer une analyse de motifs.

② Attaque par texte clair connu (Known Plaintext Attack). Si l’attaquant connaît une paire (texte clair P, texte chiffré C), alors chaque fois qu’il retrouve ce même C dans d’autres messages, il sait que le texte clair correspondant est P — sans aucun calcul, juste par correspondance directe. C’est exactement ainsi qu’Enigma a été cassée : les équipes de Bletchley Park savaient que les rapports météo allemands contenaient toujours le mot WETTER (météo), et que de nombreux messages se terminaient par une formule fixe. En retrouvant ces motifs dans les textes chiffrés, ils ont pu remonter aux paramètres journaliers d’Enigma. Le mode CBC aurait rendu cette attaque impossible.

③ Analyse statistique des motifs. Les langues naturelles et les données structurées contiennent naturellement des répétitions. En ECB, ces répétitions apparaissent telles quelles dans le texte chiffré. L’exemple classique : chiffrer une image en ECB laisse apparaître les contours de l’image originale, car les zones de couleur uniforme produisent les mêmes blocs chiffrés.

Le mode CBC a précisément été conçu pour résoudre ce problème.

L’idée centrale du CBC — le chaînage

La solution du CBC est simple : avant de chiffrer chaque bloc, on effectue un XOR avec le texte chiffré du bloc précédent.

C1 = AES_Enc(K, P1 ⊕ IV)
C2 = AES_Enc(K, P2 ⊕ C1)
C3 = AES_Enc(K, P3 ⊕ C2)

C’est ce qu’on appelle le chaînage (chaining). Chaque bloc est lié au résultat du bloc précédent : même si P1 = P2, on aura C1 ≠ C2, car C1 est mélangé à P2 avant chiffrement.

Mais le premier bloc P1 n’a pas de « texte chiffré précédent » à XORer. C’est là qu’intervient l’IV.

L’IV (Initialization Vector) — le concept le plus important

L’IV est une valeur aléatoire de 128 bits qui joue le rôle de faux « texte chiffré précédent » pour le premier bloc. On peut résumer son rôle en une phrase : permettre d’obtenir un texte chiffré différent à chaque chiffrement, même avec la même clé et le même texte clair.

Les 3 règles de l’IV

① Il doit être regénéré à chaque chiffrement. Réutiliser le même couple clé + IV est une erreur critique. Si deux messages sont chiffrés avec la même clé et le même IV :

CA = AES(K, PA ⊕ IV)
CB = AES(K, PB ⊕ IV)
→ CA ⊕ CB = PA ⊕ PB  (fuite directe d'information !)

C’est exactement la même erreur qu’Enigma : les Allemands chiffraient chaque jour les mêmes types de messages avec les mêmes paramètres. Les analystes de Bletchley Park ont exploité ces répétitions pour retrouver les clés journalières.

② Il doit être imprévisible. Un simple compteur séquentiel (0, 1, 2, 3…) ne suffit pas. Si l’attaquant peut prédire le prochain IV, certaines attaques (comme BEAST) deviennent possibles. L’IV doit être généré par un générateur de nombres aléatoires cryptographiquement sûr.

③ Il n’a pas besoin d’être secret. L’IV est transmis en clair, généralement en tête du message chiffré. Qu’un attaquant le connaisse ne pose aucun problème — sans la clé, il ne peut rien faire. Ce qui compte avec l’IV, ce n’est pas la confidentialité, mais l’unicité.

Le chaînage en détail

Le chaînage produit trois effets importants.

① Même texte clair → texte chiffré différent selon la position. Le problème de motifs de l’ECB disparaît. Même deux blocs identiques produiront des textes chiffrés différents, car le texte chiffré précédent, mélangé par XOR, est différent à chaque position.

② Chiffrement séquentiel, déchiffrement parallèle. Pour chiffrer, il faut attendre C1 pour traiter P2 : le processus est nécessairement séquentiel. En revanche, pour déchiffrer, tout ce dont on a besoin pour déchiffrer Ci est AES_Dec(K, Ci) et C(i-1) — deux valeurs déjà connues. Le déchiffrement peut donc être parallélisé.

③ Propagation des erreurs. Si un bloc Ci est corrompu en transit, seuls Pi et P(i+1) seront incorrects au déchiffrement. Les blocs suivants sont restaurés normalement. C’est une propriété à double tranchant : utile pour la détection d’erreurs localisées, mais qui signifie aussi qu’une erreur se propage sur deux blocs.

Flux de déchiffrement

Le déchiffrement est l’exact inverse :

P1 = AES_Dec(K, C1) ⊕ IV
P2 = AES_Dec(K, C2) ⊕ C1
P3 = AES_Dec(K, C3) ⊕ C2

Le récepteur n’a besoin que de la clé et de l’IV pour restaurer l’intégralité du texte clair. L’IV est généralement transmis en clair dans les 16 premiers octets du message.

La clé et l’IV — deux rôles complètement différents

Une question naturelle se pose : si l’IV est envoyé en clair avec le texte chiffré, un attaquant qui intercepte les deux ne peut-il pas tout reconstituer ?

La réponse est non — et voici pourquoi. L’IV et la clé ont des rôles fondamentalement différents.

En d’autres termes : la clé est le vrai secret. L’IV est une valeur publique qui change à chaque fois.

En pratique dans un système embarqué :

// ✅ La clé est gravée une fois dans le firmware — jamais transmise
byte key[] = { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, ... };

// ✅ L'IV est généré aléatoirement à chaque envoi
// puis placé en tête du paquet transmis
byte iv[16];
for (int i = 0; i < 16; i++) {
    iv[i] = (analogRead(A0) ^ analogRead(A1) ^ millis()) & 0xFF;
}

// ✅ La clé est gravée une fois dans le firmware — jamais transmise
byte key[] = { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, ... };

// ✅ L'IV est généré aléatoirement à chaque envoi
// puis placé en tête du paquet transmis
byte iv[16];
for (int i = 0; i < 16; i++) {
    iv[i] = (analogRead(A0) ^ analogRead(A1) ^ millis()) & 0xFF;
}

Et la structure du paquet transmis :

┌──────────────────────┬──────────────────────────┐
│   IV  (16 octets)    │   Texte chiffré           │
│   Transmis en clair  │   (résultat AES-CBC)      │
└──────────────────────┴──────────────────────────┘
         ↑
 Même intercepté, inutilisable sans la clé

Le récepteur lit les 16 premiers octets comme IV, et utilise le reste comme texte chiffré à déchiffrer.

Le rembourrage (Padding)

Le CBC traitant les données par blocs de 128 bits, le dernier bloc doit être complété s’il est trop court. C’est ce qu’on appelle le padding. La méthode la plus courante est PKCS#7 : on complète les octets manquants avec leur propre valeur.

Exemple : si le dernier bloc ne contient que 13 octets, les 3 octets manquants sont remplis par 0x03 0x03 0x03.

Une implémentation incorrecte du padding expose le système à l’attaque par oracle de padding (Padding Oracle Attack), l’une des vulnérabilités classiques du mode CBC.

Limites du CBC et état actuel

Le CBC a longtemps été le standard, mais présente des limites structurelles :

① Chiffrement séquentiel — impossible à paralléliser, ce qui peut pénaliser les performances.

② Aucune vérification d’intégrité — le CBC seul ne détecte pas si le texte chiffré a été modifié en transit. Un attaquant peut altérer des blocs sans que le récepteur s’en aperçoive. Il faut ajouter un MAC (Message Authentication Code) séparé.

③ Attaque par oracle de padding — si l’implémentation du padding est incorrecte, un attaquant peut l’exploiter pour déchiffrer le message.

Pour ces raisons, le mode GCM (Galois/Counter Mode) tend aujourd’hui à s’imposer comme référence. Il offre simultanément chiffrement et vérification d’intégrité, et supporte le traitement parallèle. TLS 1.3 a d’ailleurs supprimé le CBC pour ne conserver que les modes de type GCM.