Chiffrement AES expliqué : fonctionnement et bonnes pratiques

AES (Advanced Encryption Standard) est l'algorithme de chiffrement symétrique le plus utilisé au monde. C'est la norme adoptée par le gouvernement américain pour protéger les informations classifiées, et elle est utilisée quotidiennement par des milliards de personnes sans qu'elles le sachent — de la sécurisation des réseaux Wi-Fi au chiffrement des messages dans les applications de messagerie.

En Europe, le chiffrement n'est plus seulement une bonne pratique technique : c'est aussi un sujet de conformité. Le RGPD, la CNIL et l'ANSSI en font une mesure de protection attendue pour les données personnelles sensibles. Comprendre AES permet donc à la fois de mieux sécuriser une application et de répondre aux exigences d'un audit.

Qu'est-ce que le chiffrement AES ?

AES est un chiffrement par bloc symétrique : il découpe les données en blocs fixes de 128 bits et utilise la même clé pour chiffrer et déchiffrer. Cette symétrie rend AES rapide et efficace pour les gros volumes de données, contrairement aux algorithmes asymétriques comme RSA, beaucoup plus lents.

La clé doit rester secrète et être partagée de manière sûre entre l'émetteur et le destinataire. C'est le principal point de vigilance : AES est solide, mais si la clé fuit, le chiffrement ne protège plus rien.

L'algorithme a été développé par les cryptographes belges Joan Daemen et Vincent Rijmen sous le nom de Rijndael. En 2001, le NIST l'a sélectionné comme standard officiel de chiffrement pour les États-Unis (FIPS 197). Il a ensuite été adopté par l'ISO, l'IEEE et la quasi-totalité des bibliothèques cryptographiques modernes.

AES en France et en Europe : RGPD, CNIL et ANSSI

Le chiffrement AES est directement cité dans les recommandations de sécurité européennes. Quelques repères utiles :

• RGPD (article 32) : le chiffrement est mentionné parmi les mesures techniques appropriées pour garantir un niveau de sécurité adapté au risque. Il peut aussi réduire l'impact d'une violation de données.
• CNIL : la Commission recommande de chiffrer les données sensibles, en particulier lors de leur stockage ou de leur transmission. Elle insiste aussi sur la gestion des clés, qui doit être séparée des données chiffrées.
• ANSSI : le Référentiel Général de Sécurité (RGS) et les guides de l'Agence nationale de la sécurité des systèmes d'information recommandent AES-256 pour les données sensibles et AES-GCM pour l'authentification.
• Secteurs réglementés : les données de santé (hébergement HDS), les données bancaires (DSP2), les dossiers RH et les bases clients sont des cas d'usage typiques où AES-256 est attendu.

Attention : AES ne rend pas une application conforme à lui seul. Il faut aussi gérer les accès, les journaux, la rotation des clés, les sauvegardes et la protection contre les fuites. Le chiffrement est une brique, pas une garantie globale.

Tailles de clés AES : 128, 192 et 256

AES prend en charge trois tailles de clés. La taille détermine le nombre de tours de chiffrement et influence directement la marge de sécurité :

Le nombre après « AES » indique la longueur de la clé en bits. AES-256 utilise une clé de 256 bits, ce qui offre la plus grande marge de sécurité. Il est plus lent qu'AES-128 en raison des tours supplémentaires, mais sur du matériel moderne la différence est négligeable pour la plupart des applications web.

En pratique :

• AES-256 est le choix par défaut pour les données sensibles, les secrets applicatifs et les systèmes exposés à long terme.
• AES-128 reste largement suffisant pour des données peu sensibles ou des contextes à forte contrainte de performance.
• AES-192 est rarement nécessaire ; il est surtout utile pour respecter une exigence d'interopérabilité particulière.

Comment fonctionne le chiffrement AES

AES opère sur une grille de 4 × 4 octets appelée « état » (state). Le chiffrement répète plusieurs transformations sur cette grille :

1. Expansion de la clé

La clé originale est étendue en plusieurs clés de tour, une pour chaque tour. Ce calendrier de clés permet de dériver des sous-clés sans changer la clé maîtresse.

2. Tour initial

Le premier tour combine l'état avec la première clé de tour via un XOR. C'est l'opération AddRoundKey.

3. Tours principaux

Chaque tour principal applique quatre opérations :

SubBytes : chaque octet est remplacé par un octet d'une table de substitution fixe (la S-box). Cela apporte la non-linéarité nécessaire à la sécurité.

ShiftRows : les lignes de l'état sont décalées cycliquement. La première ligne reste inchangée, la deuxième se décale d'un octet, la troisième de deux et la quatrième de trois.

MixColumns : chaque colonne est transformée par une opération mathématique qui mélange les octets. Cette étape assure la diffusion : modifier un octet d'entrée affecte plusieurs octets de sortie.

AddRoundKey : la clé de tour courante est combinée à l'état par XOR.

4. Tour final

Le dernier tour est identique aux tours principaux, mais sans l'étape MixColumns.

Déchiffrement

Le déchiffrement applique les opérations inverses dans l'ordre inverse : InvShiftRows, InvSubBytes, AddRoundKey et InvMixColumns.

Les modes de chiffrement AES

AES chiffre des blocs de 128 bits. Un mode de chiffrement définit comment enchaîner ces blocs pour traiter des données plus longues :

Pourquoi éviter le mode ECB

ECB ne doit jamais être utilisé pour des données significatives. Des blocs de texte clair identiques produisent des blocs chiffrés identiques : les motifs de l'image ou du fichier restent visibles. C'est la célèbre démonstration du « pingouin ECB », où l'image chiffrée laisse apparaître la silhouette du pingouin.

Le mode CBC

CBC est un mode classique pour le chiffrement général. Il nécessite un vecteur d'initialisation (IV) aléatoire et unique pour chaque chiffrement. L'IV n'a pas besoin d'être secret, mais il ne doit jamais être réutilisé avec la même clé. CBC n'authentifie pas les données : il faut le combiner avec un HMAC pour détecter les altérations.

Le mode GCM

GCM fournit le chiffrement et l'authentification en une seule opération. Il produit un texte chiffré et une étiquette d'authentification (tag) qui permet de vérifier que les données n'ont pas été modifiées. C'est le mode recommandé pour la plupart des applications modernes, notamment TLS 1.2 et TLS 1.3.

Avec GCM, le nonce (l'équivalent de l'IV) doit être unique pour chaque message chiffré avec la même clé. Réutiliser un nonce GCM est une faute critique : cela peut permettre de retrouver du texte clair et de falsifier des messages.

AES, RSA et hachage : ne pas confondre

Ces trois familles d'algorithmes répondent à des besoins différents :

• AES est symétrique : une seule clé pour chiffrer et déchiffrer. Il est rapide et adapté aux volumes importants.
• RSA est asymétrique : une clé publique pour chiffrer, une clé privée pour déchiffrer. Il est plus lent et sert surtout à échanger des clés ou à signer.
• Les fonctions de hachage (SHA-256, SHA-3, etc.) sont irréversibles : elles servent à vérifier l'intégrité, pas à récupérer le contenu. Un hachage n'est pas un chiffrement.
• HMAC combine un hachage et une clé secrète pour authentifier un message. Il ne chiffre pas les données.

En pratique, TLS combine les trois approches : une poignée de main asymétrique pour échanger une clé, puis AES pour chiffrer le trafic, et des mécanismes de hachage/HMAC pour vérifier l'intégrité.

Pour aller plus loin, consultez notre guide sur HMAC, notre explication du hachage SHA-256 et notre article sur le décodage des jetons JWT.

Comment chiffrer et déchiffrer avec AES

Outil en ligne

L'outil AES Encryption / Decryption de Help2Code permet de chiffrer et déchiffrer du texte directement dans le navigateur. Il prend en charge AES-256-CBC et AES-256-GCM, affiche le résultat en Base64 et permet de copier facilement le texte chiffré.

Pour un usage réel, ne collez jamais de secrets de production dans un outil en ligne : utilisez-le pour des tests, des démonstrations ou des données fictives.

Exemple en JavaScript (Node.js)

const crypto = require('crypto');

// La clé doit être stockée de manière sécurisée, pas générée à chaque requête.
const key = crypto.randomBytes(32); // 32 octets = AES-256

function chiffrer(texte) {
  const iv = crypto.randomBytes(12); // nonce de 96 bits recommandé pour GCM
  const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);

  const donnees = Buffer.concat([cipher.update(texte, 'utf8'), cipher.final()]);

  return {
    iv: iv.toString('base64'),
    donnees: donnees.toString('base64'),
    tag: cipher.getAuthTag().toString('base64'),
  };
}

function dechiffrer({ iv, donnees, tag }) {
  const decipher = crypto.createDecipheriv(
    'aes-256-gcm',
    key,
    Buffer.from(iv, 'base64')
  );

  decipher.setAuthTag(Buffer.from(tag, 'base64'));

  return Buffer.concat([
    decipher.update(Buffer.from(donnees, 'base64')),
    decipher.final(),
  ]).toString('utf8');
}

Le tag est indispensable : sans lui, decipher.final() échoue ou les données ne sont pas authentifiées. Le nonce (iv) doit être généré pour chaque message, puis stocké à côté du texte chiffré.

Exemple en PHP

$key = random_bytes(32); // clé AES-256, à conserver dans un gestionnaire de secrets
$iv = random_bytes(12);  // nonce GCM
$tag = '';

$chiffre = openssl_encrypt(
    $texte,
    'aes-256-gcm',
    $key,
    OPENSSL_RAW_DATA,
    $iv,
    $tag
);

// On stocke l'IV et le tag avec le texte chiffré.
$payload = base64_encode($iv . $tag . $chiffre);

// Déchiffrement
$raw = base64_decode($payload);
$iv = substr($raw, 0, 12);
$tag = substr($raw, 12, 16);
$chiffre = substr($raw, 28);

$texte = openssl_decrypt(
    $chiffre,
    'aes-256-gcm',
    $key,
    OPENSSL_RAW_DATA,
    $iv,
    $tag
);

En PHP, openssl_encrypt retourne false en cas d'échec. Vérifiez toujours le retour et ne comparez jamais les tags avec == : utilisez hash_equals() pour éviter les attaques temporelles.

Bonnes pratiques pour AES

• Utilisez un générateur aléatoire cryptographique (crypto.randomBytes, random_bytes, SecureRandom) pour les clés, IV et nonces. N'utilisez jamais Math.random() ou un générateur non cryptographique.
• Dérivez les clés à partir des mots de passe avec Argon2id, scrypt ou PBKDF2. Un mot de passe ne doit jamais être utilisé directement comme clé AES.
• Ne réutilisez jamais un IV ou un nonce avec la même clé. Pour GCM, un nonce réutilisé peut casser toute la sécurité du message.
• Préférez GCM pour bénéficier de l'authentification intégrée. Si vous utilisez CBC, ajoutez un HMAC séparé.
• Stockez les clés ailleurs que dans le code : gestionnaire de secrets, KMS, HSM ou coffre-fort de clés. Ne les mettez pas dans Git, dans un fichier .env partagé ou dans les journaux.
• Limitez l'accès aux clés au strict nécessaire et journalisez les usages sensibles.
• Rotatez les clés régulièrement et prévoyez une procédure de déchiffrement des anciennes données.
• Sauvegardez les clés de manière sécurisée : sans clé, les données sont définitivement perdues.
• Testez la procédure de restauration avant d'en avoir besoin.

Erreurs fréquentes

1. Utiliser ECB parce que c'est plus simple : les motifs restent visibles.
2. Réutiliser un IV en CBC ou un nonce en GCM.
3. Utiliser un mot de passe comme clé sans dérivation.
4. Coder une clé en dur dans le code source ou dans une image Docker.
5. Utiliser CBC sans HMAC et croire que les données sont authentifiées.
6. Comparer les tags avec == au lieu d'une comparaison à temps constant.
7. Écrire la clé ou le texte clair dans les logs lors d'une erreur.
8. Croire que le chiffrement suffit à lui seul pour être conforme au RGPD.

FAQ

AES-256 est-il inviolable ?

Non. AES-256 est considéré comme très solide contre les attaques par force brute, mais il peut être contourné par une mauvaise gestion des clés, une implémentation défectueuse, une attaque par canal auxiliaire ou une fuite d'accès. La cryptographie protège les données, pas les erreurs d'architecture.

Quelle est la différence entre chiffrement et hachage ?

Le chiffrement est réversible : avec la bonne clé, on retrouve le texte clair. Le hachage est irréversible : on ne peut pas revenir au message d'origine. On chiffre pour protéger la confidentialité ; on hache pour vérifier l'intégrité ou stocker des mots de passe.

AES-128 ou AES-256 ?

AES-256 est recommandé pour les données sensibles et les systèmes exposés à long terme. AES-128 reste suffisant pour beaucoup d'usages et légèrement plus rapide. Si vous avez un doute, choisissez AES-256.

Peut-on chiffrer avec un mot de passe ?

Oui, mais pas directement. Il faut dériver une clé à partir du mot de passe avec une fonction de dérivation (Argon2id, scrypt, PBKDF2) et un sel aléatoire. Utiliser le mot de passe brut comme clé AES est une mauvaise pratique.

Le chiffrement AES suffit-il pour être conforme au RGPD ?

Non. Le chiffrement est une mesure importante, mais la conformité implique aussi la gestion des clés, les contrôles d'accès, la journalisation, les analyses d'impact, les sauvegardes et les procédures de notification en cas de violation.

Que faire si je perds la clé de chiffrement ?

Les données sont irrécupérables, sauf si vous avez une sauvegarde de la clé ou un mécanisme d'escrow. C'est pourquoi la sauvegarde et la rotation des clés doivent être planifiées dès le départ.

Conclusion

AES est l'épine dorsale de la sécurité moderne des données. Comprendre ses tailles de clés, ses modes et ses bonnes pratiques permet de protéger efficacement les données sensibles, y compris dans un contexte RGPD. Retenez surtout trois choses : utilisez AES-256 pour les données sensibles, préférez GCM, et protégez la clé autant que les données.

Pour tester rapidement un chiffrement, utilisez notre outil AES Encryption / Decryption. Pour l'authentification des messages, consultez notre générateur HMAC. Et pour l'encodage des données chiffrées, notre outil Base64 vous sera utile.