AES : qu'est-ce que c'est, algorithme de chiffrement symétrique et où il est utilisé

Tailles des clés AES et niveaux de sécurité

AES prend en charge trois tailles de clé, chacune correspondant à un niveau spécifique de force cryptographique. Le choix de la taille de la clé affecte la sécurité, les performances et les exigences en ressources de l'appareil.

Règle pratique : pour les applications mobiles, utilisez AES-256 par défaut. La différence de performance entre AES-128 et AES-256 sur les appareils modernes avec prise en charge AES-NI ne dépasse pas 10 à 15 %, mais le niveau de sécurité double. Selon l'analyse quantique (Grassl et al., 2016), casser AES-128 nécessiterait 2^77 opérations quantiques via l'algorithme de Grover, tandis qu'AES-256 en nécessiterait 2^149, rendant AES-256 résistant aux attaques quantiques pour les 20 à 30 prochaines années. Même AES-128 offre une protection suffisante pour la grande majorité des scénarios commerciaux : la force brute d'une clé de 128 bits nécessiterait plus d'énergie que n'en contient l'univers selon l'estimation de Bruce Schneier. Cependant, les normes de sécurité (GDPR, HIPAA, PCI DSS) exigent souvent explicitement AES-256, donc les projets de production doivent utiliser la longueur maximale de clé.

Modes de fonctionnement AES

AES en tant que chiffrement par blocs chiffre des blocs de taille fixe (128 bits). Pour chiffrer des données de longueur arbitraire, des modes de fonctionnement sont utilisés. La sélection du mode affecte de manière critique la sécurité : le mauvais mode peut annuler la force d'AES.

• ECB (Electronic Codebook) — le mode le plus simple et le plus dangereux. Chaque bloc est chiffré indépendamment avec la même clé. Des blocs de texte clair identiques produisent des blocs de texte chiffré identiques, permettant de reconstituer la structure des données. Interdit dans toutes les normes de sécurité modernes. N'utilisez JAMAIS ECB dans les applications mobiles.
• CBC (Cipher Block Chaining) — chaque bloc de texte chiffré précédent est utilisé comme vecteur d'initialisation (IV) pour le suivant. Nécessite un IV aléatoire pour chaque message. Vulnérable aux attaques par oracle de padding lorsqu'il est mal implémenté. Convient au chiffrement de fichiers mais nécessite un MAC (HMAC) pour l'intégrité des données.
• GCM (Galois/Counter Mode) — le mode recommandé pour les applications mobiles. Offre un chiffrement authentifié (AEAD) : chiffrement + vérification d'intégrité en une seule opération. Utilise un compteur pour la génération de flux de clé et une multiplication dans le corps de Galois pour l'authentification. GCM nécessite un nonce unique (12 octets) pour chaque message. Recommandé par le NIST, utilisé dans TLS 1.2/1.3 et Android Keystore.
• CCM (Counter with CBC-MAC) — un mode AEAD alternatif basé sur CTR + CBC-MAC. Plus lent que GCM et ne prend pas en charge le traitement parallèle. Utilisé dans les protocoles ZigBee et 802.11 (Wi-Fi). Pour les applications mobiles, GCM est préférable.

Pour les projets mobiles, utilisez AES-256-GCM avec un nonce de 12 octets. GCM résout deux problèmes simultanément : le chiffrement des données et l'authentification, empêchant les attaques par oracle de padding et par texte chiffré choisi. Android Keystore et iOS CryptoKit prennent en charge AES-GCM nativement sans nécessiter de primitives cryptographiques supplémentaires. Lorsque vous travaillez avec GCM, il est critique de ne jamais réutiliser le nonce avec la même clé — cela détruit complètement la sécurité du chiffrement. Générez un nouveau nonce aléatoire pour chaque chiffrement et stockez-le avec le texte chiffré.

Implémentation d'AES dans les applications mobiles

Examinons un exemple d'implémentation sécurisée d'AES-256-GCM sur Android avec Jetpack Security. Le code ci-dessous montre le cycle complet : création d'une clé AES-256 via MasterKey, chiffrement et déchiffrement d'une chaîne avec des données authentifiées supplémentaires (AAD).

import androidx.security.crypto.MasterKey
import androidx.security.crypto.EncryptedSharedPreferences

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val securePrefs = EncryptedSharedPreferences.create(
    context,
    "secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

fun storeSecureData(key: String, value: String) {
    securePrefs.edit().putString(key, value).apply()
}

fun readSecureData(key: String): String? {
    return securePrefs.getString(key, null)
}

La caractéristique clé de cette solution est qu'AES-256-GCM est utilisé à deux niveaux : pour chiffrer les paires clé-valeur (PrefValueEncryptionScheme) et pour protéger les noms des clés eux-mêmes (PrefKeyEncryptionScheme utilise AES-256-SIV, résistant à la réutilisation du nonce). MasterKey est généré en utilisant l'algorithme AES-256-GCM et stocké dans Android Keystore, protégé matériellement sur les appareils dotés d'un Trusted Execution Environment. Sur les appareils sans support matériel (TEE), la clé est chiffrée via Bouncy Castle, ce qui reste plus sûr que le stockage dans SharedPreferences.

Pour le chiffrement direct de gros volumes de données (par exemple, des images ou des fichiers), utilisez AES-256-GCM via EncryptedFile d'AndroidX Security. Pour l'exportation de clés (par exemple, pour sauvegarde), utilisez un chiffrement supplémentaire avec un mot de passe utilisateur via PBKDF2 avec 100000+ itérations.

AES sur iOS via CryptoKit

Sur iOS, les opérations AES sont organisées via le framework CryptoKit (Swift 5.0+). Une clé AES-256 est créée via SymmetricKey(size: .bits256) et stockée dans le Secure Enclave — un cryptoprocesseur matériel isolé du CPU principal et du système d'exploitation. CryptoKit fournit deux implémentations d'AES : AES.GCM (recommandé) et AES.CBC (pour la rétrocompatibilité avec les formats hérités). Le chiffrement est effectué via la méthode seal(), qui prend les données, la clé et le nonce (12 octets), et retourne AES.GCM.SealedBox — une structure contenant le texte chiffré et le tag d'authentification. Le déchiffrement se fait via open(). Apple recommande fortement de ne pas utiliser CommonCrypto directement : CryptoKit sélectionne automatiquement les paramètres optimaux, protège contre les attaques par canal auxiliaire et utilise l'accélération matérielle AES-NI sur les processeurs Apple Silicon. Sur les appareils avec Secure Enclave, les clés ne quittent jamais le module matériel, empêchant le vol même en cas de compromission totale de l'application. Pour la sérialisation de la clé, utilisez la méthode withUnsafeBytes suivie d'un stockage dans Keychain via SecItemAdd avec l'attribut kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.