Chiffrement symétrique : AES, modes et clés

Le chiffrement symétrique utilise une seule et même clé secrète pour chiffrer et pour déchiffrer : l'expéditeur et le destinataire doivent tous deux la posséder. C'est le chiffrement le plus rapide, celui qui protège en réalité presque toutes les données, du disque de ton portable aux pages HTTPS. Ce chapitre présente AES, l'algorithme standard, les modes de chiffrement (et pourquoi le mode ECB est à bannir), le code pour chiffrer en PHP et en Node.js, et la grande limite du symétrique : l'échange des clés.

Le principe : une seule clé partagée

Le laboratoire Hélianthe chiffre les comptes rendus qu'il archive. Le même programme, avec la même clé, sert à chiffrer à l'archivage et à déchiffrer à la consultation :

clair ──[ AES + clé K ]──▶ chiffré ──[ AES + clé K ]──▶ clair

On parle aussi de chiffrement à clé secrète, par opposition au chiffrement à clé publique du chapitre 4. Ses forces et ses faiblesses tiennent en un tableau :

AES, le standard depuis 2001

AES (Advanced Encryption Standard) est l'algorithme de chiffrement symétrique standardisé par le NIST américain en 2001 (norme FIPS 197), à l'issue d'un concours public international. L'algorithme retenu, Rijndael, a été conçu par deux cryptologues belges, Joan Daemen et Vincent Rijmen. Il remplaçait DES (1977), dont la clé de 56 bits était devenue trop courte.

AES est un chiffrement par bloc : il découpe les données en blocs de 128 bits (16 octets) et chiffre chaque bloc par une suite de tours de substitutions, de permutations et de mélanges avec la clé.

Deux autres noms à connaître :

• ChaCha20-Poly1305, un chiffrement par flot conçu par Daniel J. Bernstein. Il est aussi sûr qu'AES-GCM et plus rapide sur les processeurs sans instructions AES (vieux téléphones, objets connectés). TLS 1.3, SSH et le VPN WireGuard l'utilisent.
• 3DES (Triple DES), qui applique trois fois DES. Il est obsolète : le NIST en interdit l'usage pour chiffrer depuis fin 2023, et l'ANSSI le juge non conforme. Si tu le croises dans une configuration (un vieux VPN, une suite TLS), c'est une non-conformité à signaler.

Chiffrement par bloc : les modes ECB, CBC, CTR et GCM

AES seul ne chiffre que 16 octets. Pour un message plus long, il faut un mode opératoire, qui dit comment enchaîner les blocs. Le choix du mode compte autant que celui de l'algorithme.

Le mode ECB (Electronic Code Book) chiffre chaque bloc indépendamment, avec la même clé. Résultat : deux blocs de clair identiques donnent deux blocs chiffrés identiques. Voici trois blocs de 16 octets chiffrés en AES-128-ECB, puis en AES-128-CBC, avec la même clé :

Clair (3 blocs)        Chiffré ECB                         Chiffré CBC
statut=NEGATIF;;       2678b0c7a2d6d43c9f0ebb2e650cfd00    92bb39d04664ce79bddda69448ac60a0
statut=NEGATIF;;       2678b0c7a2d6d43c9f0ebb2e650cfd00    1640a847058972ce1f12e5fd8dabf0e8
statut=POSITIF;;       fe677a936bbc28a44495e8af456b4061    4b22961b1f6b2ca8e2d64e5f4ec9bb63

En ECB, un espion qui ne connaît pas la clé voit que les deux premiers patients ont le même résultat et que le troisième est différent. S'il apprend un seul résultat, il connaît tous ceux qui ont le même chiffré. C'est l'analyse de fréquences des chiffrements historiques, appliquée à des blocs.

Le mode CBC (Cipher Block Chaining) combine chaque bloc clair, par XOR, avec le bloc chiffré précédent, avant de le chiffrer. Le premier bloc est combiné avec un vecteur d'initialisation (IV) de 16 octets, tiré au hasard à chaque message et transmis en clair avec le chiffré. Deux messages identiques donnent ainsi deux chiffrés différents.

Le mode CTR (compteur) chiffre un compteur (nonce + numéro de bloc) et combine le résultat au message par XOR, comme un masque. Il se parallélise bien, mais un même nonce réutilisé sous la même clé produit le même masque : c'est l'erreur du masque jetable réutilisé.

Le mode GCM (Galois/Counter Mode) est le mode CTR auquel on ajoute un calcul d'étiquette d'authentification (tag, 16 octets). Au déchiffrement, si un seul bit du chiffré, de l'IV ou du tag a été modifié, l'étiquette ne correspond plus et le déchiffrement échoue. GCM apporte donc la confidentialité et l'intégrité.

Le chiffrement authentifié : confidentialité et intégrité ensemble

Un chiffrement sans contrôle d'intégrité laisse une porte ouverte : l'attaquant ne peut pas lire, mais il peut modifier. En mode CTR, inverser un bit du chiffré inverse le même bit du clair déchiffré ; sur un champ dont il connaît la position (un montant, un code de statut), il peut changer la valeur sans connaître la clé. En mode CBC, des attaques dites « par oracle de remplissage » ont permis de déchiffrer des cookies entiers en observant simplement si le serveur répondait « remplissage invalide ».

La réponse moderne est le chiffrement authentifié (AEAD, Authenticated Encryption with Associated Data) : AES-GCM, ChaCha20-Poly1305. Il chiffre et calcule l'étiquette en une seule opération. Il peut aussi authentifier des données associées qui restent en clair, par exemple l'identifiant du patient auquel appartient un compte rendu : impossible de déplacer le chiffré d'un dossier à un autre sans que le déchiffrement échoue. Le guide de l'ANSSI le dit sans détour : il est recommandé « de ne pas employer isolément un mode opératoire de chiffrement n'offrant pas d'intégrité ».

Chiffrer en pratique : OpenSSL, PHP et Node.js

En ligne de commande, openssl enc chiffre un fichier à partir d'une phrase de passe. L'option -pbkdf2 dérive la clé de la phrase de passe avec une fonction volontairement lente, et -iter fixe le nombre d'itérations. openssl enc ne sait pas faire de chiffrement authentifié (il refuse GCM avec le message AEAD ciphers not supported) : on l'utilise en CBC, et on vérifie l'intégrité par une empreinte ou une signature.

# Chiffrer (AES-256-CBC, clé dérivée de la phrase de passe, sel aléatoire)
openssl enc -aes-256-cbc -salt -pbkdf2 -iter 600000 \
  -in compte-rendu.pdf -out compte-rendu.pdf.enc

# Déchiffrer (mêmes options, plus -d)
openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 \
  -in compte-rendu.pdf.enc -out compte-rendu.pdf

En PHP, l'extension OpenSSL fournit AES-GCM. La clé de 32 octets (256 bits) n'est pas dans le code : elle est lue dans une variable d'environnement, encodée en Base64. Le paquet stocké contient l'IV, l'étiquette et le chiffré.

<?php
// Clé de 32 octets générée une fois par : php -r "echo base64_encode(random_bytes(32));"
$cle = base64_decode(getenv('HELIANTHE_CLE_DONNEES'));

function chiffrer(string $clair, string $cle): string
{
    $iv = random_bytes(12);                       // nonce unique de 12 octets
    $chiffre = openssl_encrypt($clair, 'aes-256-gcm', $cle, OPENSSL_RAW_DATA, $iv, $tag);
    return base64_encode($iv . $tag . $chiffre);  // IV (12) + étiquette (16) + chiffré
}

function dechiffrer(string $paquet, string $cle): string|false
{
    $brut = base64_decode($paquet);
    $iv = substr($brut, 0, 12);
    $tag = substr($brut, 12, 16);
    $chiffre = substr($brut, 28);
    // Renvoie false si le chiffré, l'IV ou l'étiquette ont été modifiés
    return openssl_decrypt($chiffre, 'aes-256-gcm', $cle, OPENSSL_RAW_DATA, $iv, $tag);
}

PHP propose aussi l'extension Sodium (sodium_crypto_aead_xchacha20poly1305_ietf_encrypt()), plus difficile à mal utiliser, avec des nonces de 24 octets qu'on peut tirer au hasard sans crainte de collision.

En Node.js, le module intégré crypto fait la même chose :

import { randomBytes, createCipheriv, createDecipheriv } from 'node:crypto';

const cle = Buffer.from(process.env.HELIANTHE_CLE_DONNEES, 'base64'); // 32 octets

export function chiffrer(texte) {
  const iv = randomBytes(12);
  const cipher = createCipheriv('aes-256-gcm', cle, iv);
  const chiffre = Buffer.concat([cipher.update(texte, 'utf8'), cipher.final()]);
  const tag = cipher.getAuthTag();
  return Buffer.concat([iv, tag, chiffre]).toString('base64');
}

export function dechiffrer(paquet) {
  const tout = Buffer.from(paquet, 'base64');
  const decipher = createDecipheriv('aes-256-gcm', cle, tout.subarray(0, 12));
  decipher.setAuthTag(tout.subarray(12, 28));
  // Lève l'erreur « Unsupported state or unable to authenticate data » si le paquet a été modifié
  return Buffer.concat([decipher.update(tout.subarray(28)), decipher.final()]).toString('utf8');
}

Chiffre deux fois le même numéro de sécurité sociale : tu obtiens deux paquets différents, puisque l'IV change. Modifie un seul caractère du paquet : le déchiffrement échoue. C'est exactement ce qu'on attend.

Le problème de l'échange des clés

Le chiffrement symétrique suppose que les deux correspondants possèdent déjà la même clé. Comment la transmettre ? Pas par courriel, que n'importe quel serveur intermédiaire peut lire ; pas dans le même message que les données chiffrées. Et le problème grossit vite : si chaque personne d'un groupe de n personnes veut pouvoir échanger en secret avec chacune des autres, il faut une clé par paire, soit n(n − 1)/2 clés.

Le chiffrement asymétrique résout ce problème : chacun publie une clé publique, et deux inconnus peuvent convenir d'une clé secrète sur un réseau espionné (Diffie-Hellman). En pratique, on combine les deux : l'asymétrique échange la clé, le symétrique chiffre les données. C'est le chiffrement hybride de TLS, de SSH et de PGP.

Une fois la clé en place, il faut la garder. Une clé de chiffrement ne s'écrit jamais dans le code source ni dans un dépôt Git (cours Git et GitHub) : elle vit dans une variable d'environnement du serveur, un coffre de secrets, ou un module matériel (HSM, TPM). Une clé perdue rend les données irrécupérables : elle se sauvegarde, à part des données qu'elle protège.

À l'E7 : comment la notion est demandée

• Chiffrer une colonne dans le SGBD. Le sujet SLAM 2026 (cas NDV) fait chiffrer les adresses électroniques des contacts avec AES_ENCRYPT(), en passant la colonne en VARBINARY(200), puis corriger une requête préparée pour réafficher l'adresse en clair avec AES_DECRYPT(), la clé étant lue dans une variable d'environnement. Le sujet SLAM 2024 (cas Gsic) fait chiffrer des colonnes sensibles d'une base SQL Server avec une clé symétrique AES_256 protégée par un certificat. Le cours SQL déroule les deux syntaxes (chiffrer une colonne sensible).
• Justifier un paramètre de sécurité. Le sujet SISR 2025 (cas Blanca) demande d'expliquer les deux paramètres qui sécurisent SNMPv3 dans la commande snmpv3 user <username> auth sha <password> priv aes <priv password> : priv aes active le chiffrement symétrique AES des messages, donc leur confidentialité ; auth sha assure l'authentification et l'intégrité (HMAC).
• Proposer un scénario de risque qui rend le chiffrement pertinent : une sauvegarde volée, un administrateur de base curieux, une injection SQL qui exfiltre la table. Le chiffrement protège la confidentialité si la clé n'est pas au même endroit que les données.

En SLAM, le réflexe : AES-256-GCM, clé hors du code, IV aléatoire stocké avec le chiffré. En SISR, le réflexe : désactiver les suites et protocoles à 3DES ou RC4, préférer AES-GCM ou ChaCha20 dans les VPN et les services.

Pour aller plus loin. Les erreurs de chiffrement côté application (clé dans le code, mode ECB, algorithme maison) sont classées dans l'OWASP Top 10 : voir le chapitre Défaillances cryptographiques (A04) du cours Sécurité applicative.

Exercices

$cle = 'helianthe2026';
$iv = '0000000000000000';
$chiffre = openssl_encrypt($nss, 'aes-256-cbc', $cle, 0, $iv);