Une sauvegarde restaurée contient un enregistrement JSON chiffré pour user-1842 ; pourtant, l’application l’accepte après qu’un attaquant a modifié les octets stockés, transformant le role récupéré en admin. L’attaquant n’a eu besoin ni de la clé de chiffrement ni d’un accès à l’API ; un simple accès en écriture à la sauvegarde de la base de données ou à ses métadonnées a suffi. Notre système repose sur un module Python qui protège cet enregistrement — composé des champs id, email, role et created_at — lors de ses transferts entre un client, une API, une base de données et une sauvegarde. Le chiffrement symétrique utilise une clé secrète unique pour convertir le texte en clair en texte chiffré, puis pour retrouver le texte en clair ultérieurement. Ce procédé dissimule l’enregistrement, mais la simple dissimulation ne garantit pas l’intégrité d’octets ayant été altérés.
La question qui se pose au défenseur est donc plus spécifique que le simple choix de l’algorithme de chiffrement le plus réputé. Lorsque la valeur role=admin est récupérée depuis le stockage, comment l’API peut-elle prouver que ces octets et le contexte de l’enregistrement correspondent exactement à ceux qui ont été protégés à l’origine ? Les limites définies pour user-1842 indiquent où le texte en clair doit s’arrêter, où la clé doit rester isolée et où un attaquant peut modifier le texte chiffré sans en connaître le contenu. Suivons le parcours de l’enregistrement à travers ces limites :
Ce schéma montre que la base de données et la sauvegarde nécessitent le texte chiffré, un nonce et certaines métadonnées, mais jamais la clé de chiffrement. Un nonce est une valeur utilisée une seule fois avec une clé donnée pour garantir que les opérations de protection répétées ne réutilisent pas les mêmes entrées cryptographiques. Le nonce peut être stocké aux côtés du texte chiffré ; sa fonction n’est pas d’assurer la confidentialité. La clé doit rester secrète et provenir de la configuration protégée de l’application plutôt que de l’enregistrement ou de la sauvegarde.
Comme un attaquant peut modifier les octets stockés, le contrat de l’enregistrement exige à la fois confidentialité et intégrité. Le chiffrement authentifié chiffre les octets JSON et vérifie que ni ces octets ni le contexte sélectionné n’ont été modifiés avant de restituer le texte en clair. Pour user-1842, l’API authentifiera user_id=user-1842 et schema_version=1 en tant que données associées (ou données supplémentaires), c’est-à-dire des métadonnées vérifiées par l’opération cryptographique mais laissées en clair. Ainsi, un texte chiffré copié ne peut pas être réétiqueté silencieusement comme l’enregistrement d’un autre utilisateur, et une valeur de schéma ne peut pas être modifiée sans provoquer l’échec de la vérification.
Le texte en clair expose directement l’adresse e-mail et le rôle. AES-CTR et AES-CBC permettent de masquer ces champs, mais aucun des deux ne rejette une modification de manière autonome. AES-GCM offre le contrat de chiffrement authentifié requis lorsqu’il est utilisé avec un nonce unique pour chaque opération de chiffrement effectuée avec une même clé. Un mode de chiffrement seul peut-il détecter qu’un octet de la sauvegarde a été modifié avant que l’API n’analyse le champ role ? La comparaison suivante évalue les options de stockage au regard de cette exigence :
Cette comparaison concrétise le choix de conception. AES-GCM rejette tout texte chiffré, nonce, clé ou donnée associée ayant été modifié, en signalant un échec d’authentification, alors que les solutions assurant uniquement la confidentialité privent l’application de cette garantie. AES-GCM ne permet pas de remédier à la réutilisation d’un nonce. La réutilisation d’un nonce avec la même clé compromet la sécurité ; par conséquent, la génération du nonce doit s’intégrer au processus de protection plutôt que de reposer sur des métadonnées fournies par l’appelant.
Règle relative à l’enregistrement Stockez le nonce, le texte chiffré et les données associées avec l’enregistrement. Stockez la clé AES séparément et veillez à ce que chaque nonce soit unique pour une clé donnée.
Une fois le contrat établi, le module peut protéger user-1842 sans exposer un enregistrement partiellement vérifié à l’appelant. Le sérialiseur JSON produit des octets, car la méthode AESGCM.encrypt opère sur des octets. Pour cet exemple, le module génère une clé AES de 256 bits, crée un nouveau nonce de 12 octets et stocke un ensemble structuré comme suit : {nonce, ciphertext, ad}. En phase de déploiement, la génération et la conservation de la clé sont transférées vers le périmètre approuvé de gestion des clés de l’application, tandis que l’ensemble de données chiffrées peut être stocké en toute sécurité dans la base de données et les sauvegardes.
Voici le processus complet minimal de protection et de récupération :