Protéger une information en environnement hostile

La cryptographie ne protège pas des fichiers : elle protège des relations entre acteurs qui ne se font pas confiance a priori. Cette nuance décide de tout le reste. Poser « il faut chiffrer » avant d’avoir nommé qui est l’adversaire, ce qu’il observe et ce qu’il peut modifier produit systématiquement un système où la primitive est correcte et la garantie inexistante. Le compromis central de cette page : plus les garanties recherchées sont fortes, plus le nombre de dépendances externes augmente, clés, horloge, annuaire d’identités, source d’aléa, canal de mise à jour, et chacune de ces dépendances devient un nouveau point de rupture. La position assumée ici est qu’il vaut mieux deux garanties tenues qu’un empilement de quatre garanties dont aucune n’est vérifiable en production.

→ Lire l’explication complète de la marmotte

Nommer l’objectif avant de choisir l’algorithme

Quatre garanties structurent le domaine, et elles sont indépendantes. La confidentialité empêche la lecture du contenu. L’intégrité permet de détecter toute modification, y compris d’un seul bit. L’authenticité rattache le message à une clé, donc à un détenteur de clé. La non-répudiation empêche ce détenteur de nier ensuite, mais uniquement si une procédure organisationnelle atteste que la clé était sous son contrôle exclusif au moment de la signature. Sans cette procédure, une signature reste une preuve technique qu’une clé a agi, jamais qu’une personne a voulu.

Le piège le plus coûteux tient au chiffrement seul. Un chiffrement sans authentification ne protège pas l’intégrité : en mode CBC (Cipher Block Chaining) ou CTR (Counter), un attaquant qui connaît ou devine le clair peut retourner des bits choisis du chiffré et provoquer une modification prévisible du clair déchiffré. C’est la raison pour laquelle les modes AEAD (Authenticated Encryption with Associated Data) comme AES-GCM ou ChaCha20-Poly1305 sont aujourd’hui le défaut, et pourquoi tout usage de CBC sans MAC (Message Authentication Code) vérifié avant déchiffrement doit être traité comme un défaut de conception, pas comme un choix legacy acceptable. Le détail est développé dans chiffrer et authentifier en une seule opération.

La séparation données / métadonnées / contexte se traite au même moment. Le chiffrement protège le contenu ; il ne masque ni les adresses, ni les tailles, ni les horaires, ni la fréquence. Sur TLS (Transport Layer Security), le nom d’hôte demandé fuit par SNI (Server Name Indication) sauf déploiement d’ECH (Encrypted Client Hello), et les résolutions DNS restent observables sans DoH ou DoT. Une architecture qui promet « communications chiffrées » sans qualifier ce point promet moins qu’elle ne croit.

Primitive, schéma, protocole, système : où les garanties se perdent

Une primitive est une fonction élémentaire : AES, SHA-256, l’exponentiation modulaire. Un schéma l’habille de règles d’usage : RSA-OAEP, ECDSA sur P-256, HMAC-SHA-256. Un protocole orchestre plusieurs schémas entre acteurs avec des messages ordonnés : TLS 1.3, Signal, Kerberos. Un système ajoute les clés réelles, les identités réelles, l’exploitation et les humains. Les défaillances observées en production ne se situent presque jamais au niveau de la primitive : AES n’est pas cassé, mais les implémentations le sont, padding oracle, réutilisation de nonce, comparaison de MAC non constante en temps, secret dérivé d’un générateur pseudo-aléatoire non cryptographique.

Cinq dépendances méritent d’être inventoriées explicitement pour tout système cryptographique. L’aléa : un générateur mal initialisé au démarrage d’une machine virtuelle ou d’un objet embarqué produit des clés collisionnables, et le problème est structurel, pas anecdotique. Les clés : leur cycle de vie complet, génération, stockage, rotation, révocation, destruction, conditionne la valeur des garanties, comme détaillé dans exploiter des clés et gérer la rotation. L’horloge : une validation de certificat ou de jeton dépend d’un temps de référence, et une dérive suffit à accepter un élément expiré ou à rejeter un élément valide. L’identité : lier une clé à un acteur est un problème distinct de la cryptographie elle-même. La mise à jour : sans canal de déploiement authentifié, aucune correction de vulnérabilité n’est déployable de façon fiable.

Ce que la cryptographie ne répare pas

Le chiffrement de bout en bout protège le transit, pas les extrémités. Sur un poste compromis, l’attaquant lit le clair après déchiffrement légitime ; toute la chaîne cryptographique fonctionne nominalement pendant que la confidentialité est nulle. De même, un chiffrement au repos protège contre le vol de support physique ou de snapshot de volume, presque jamais contre une injection SQL : l’application dispose de la clé et déchiffre à la demande, y compris pour la requête de l’attaquant.

Trois autres angles morts reviennent constamment. La révocation n’est pas instantanée : révoquer un certificat n’interrompt pas les sessions TLS déjà établies, et un jeton JWT (JSON Web Token) auto-porté reste valide jusqu’à son expiration puisque sa vérification ne consulte aucun état serveur, d’où la règle de durées de vie courtes plutôt que de listes de révocation espérées, développée dans JWS et jetons signés. L’autorisation ensuite : une authentification cryptographique prouve qui parle, jamais ce qu’il a le droit de faire. Enfin les procédures de récupération : un compte protégé par une clé matérielle mais réinitialisable par un code envoyé par SMS a la sécurité du SMS, pas celle de la clé. Le niveau de sécurité d’un système est celui de son chemin le plus faible, et ce chemin est presque toujours le chemin de secours.

Vérifier plutôt que supposer

Distinguer chiffrement, encodage et compression est la première vérification à faire sur un artefact présenté comme protégé. Un base64 n’est pas un secret, et un entropie élevée n’implique pas un chiffrement correct.

# Encodage réversible sans clé : aucune confidentialité
echo "mot_de_passe_admin" | base64
# bW90X2RlX3Bhc3NlX2FkbWluCg==

# Chiffrement authentifié : AES-256-GCM, clé et nonce distincts
openssl enc -aes-256-gcm -pbkdf2 -iter 600000 \
  -in secret.txt -out secret.enc -pass file:./passphrase

# Vérifier l'intégrité : toute modification d'un octet du chiffré
# doit provoquer un échec de déchiffrement, pas un clair corrompu
printf '\x00' | dd of=secret.enc bs=1 seek=10 conv=notrunc 2>/dev/null
openssl enc -d -aes-256-gcm -pbkdf2 -iter 600000 \
  -in secret.enc -pass file:./passphrase
# Attendu : erreur d'authentification, aucune sortie en clair

# Ce que TLS révèle malgré le chiffrement : le nom d'hôte en clair via SNI
openssl s_client -connect example.org:443 -servername example.org 2>/dev/null \
  | grep -i "Server certificate" -A2

Le troisième bloc est le test qui compte : si un octet modifié produit un clair partiellement lisible au lieu d’une erreur, le mode n’est pas authentifié et l’intégrité n’est pas garantie, quelle que soit la taille de clé annoncée.

FAQ

Chiffrer une base de données protège-t-il contre une fuite applicative ?

Non dans le cas général. Le chiffrement transparent au niveau du volume ou du moteur (TDE) protège les supports au repos. Une requête légitime, ou injectée, reçoit du clair. Seul un chiffrement applicatif par champ, avec une clé que le service de requêtage ne détient pas, réduit ce périmètre, au prix de la perte des recherches et des tris sur les champs concernés.

Une signature vaut-elle un engagement juridique ?

Techniquement, elle prouve qu’une clé privée a produit une empreinte. La portée juridique dépend du dispositif entourant la clé : conditions de génération, contrôle exclusif, horodatage qualifié, séquestre éventuel. Voir signer et produire une preuve publique.

Faut-il un modèle de menace avant de choisir les algorithmes ?

Oui, et l’ordre n’est pas négociable. Ajouter une primitive sans adversaire nommé produit du coût opérationnel sans réduction de risque mesurable, et déplace souvent le point faible vers la gestion de clés nouvellement introduite.

🐝 Ce qui arrive si on s’en passe

Sans objectif nommé ni dépendances inventoriées, un système cryptographique ne peut pas être contrôlé : l’audit constate la présence d’un algorithme réputé, faute de pouvoir vérifier une garantie que personne n’a écrite, et le rapport conclut à la conformité d’un dispositif dont la propriété réelle reste inconnue. En incident, la même absence coûte la reprise : lorsqu’une clé, une horloge ou une source d’aléa est mise en cause, rien ne dit quelles garanties tombaient avec elle ni quelles données il faut relire. Un déchiffrement qui répond différemment selon la forme d’un message altéré achève le tableau, comme le montre la brèche « la question qui rend le module bavard ».

🦫 Explication de la marmotte 🍫

Protéger une information, c’est d’abord décider ce qu’on veut obtenir. Quatre choses différentes sont possibles : que personne ne lise le message, qu’on détecte s’il a été modifié, qu’on sache de qui il vient, et que l’expéditeur ne puisse pas nier l’avoir envoyé. Chacune demande un mécanisme distinct : brouiller le message ne dit rien sur son origine, et vérifier son origine ne le cache pas.

Le brouillage utilise une clé, un très grand nombre secret. Sans elle, le message brouillé est illisible. Mais si le procédé ne fait que brouiller, quelqu’un peut modifier le message brouillé au hasard, et le destinataire obtiendra un message abîmé sans s’en apercevoir. Les procédés modernes ajoutent donc une marque de contrôle : si un seul caractère change, le déchiffrement refuse de fonctionner et signale une erreur. C’est exactement ce qu’on teste dans les commandes plus haut.

Ensuite viennent les fragilités. Le brouillage ne cache pas qui parle à qui, ni quand, ni combien de fois : ces traces restent visibles. Il ne protège pas non plus un ordinateur déjà infecté, puisque le message y redevient lisible à l’arrivée. Il ne remplace pas les règles qui décident qui a le droit de faire quoi. Et quand une clé est déclarée compromise, les échanges déjà en cours continuent souvent jusqu’à leur fin. La solidité de l’ensemble est celle de son maillon le plus faible, qui est presque toujours la procédure de secours quand on a perdu sa clé.

Pages voisines

La citent

Protéger une information en environnement hostile

Elle cite

Protéger une information en environnement hostile

Protéger une information en environnement hostile

Nommer l’objectif avant de choisir l’algorithme

Primitive, schéma, protocole, système : où les garanties se perdent

Ce que la cryptographie ne répare pas

Vérifier plutôt que supposer

FAQ

Chiffrer une base de données protège-t-il contre une fuite applicative ?

Une signature vaut-elle un engagement juridique ?

Faut-il un modèle de menace avant de choisir les algorithmes ?

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines