Frontières : cacher, coder, compresser et détruire

Frontières : cacher, coder, compresser et détruire

Beaucoup de transformations rendent des données illisibles à l’œil nu sans les protéger le moins du monde. Une chaîne en Base64 a l’air mystérieuse, un fichier compressé ressemble à du bruit, une image peut transporter un message invisible, un fichier supprimé a disparu de l’explorateur. Aucune de ces opérations n’est du chiffrement, et certaines n’offrent aucune garantie. Cette fiche trace la frontière entre ce qui cache un contenu, ce qui cache son existence, ce qui ne cache rien, et ce qui détruit vraiment. Elle évite ainsi à un inventaire de sécurité de compter comme « chiffrés » des champs qu’un stagiaire décode en trente secondes.

Explication de la marmotte

Écrire un message à l’encre invisible, le traduire en morse ou le plier tout petit dans une enveloppe, ce n’est pas la même chose que l’enfermer dans un coffre. Ce chapitre fait le tri entre ce qui cache vraiment un contenu, ce qui cache seulement son existence et ce qui ne cache rien du tout, même quand cela en a l’air.

→ Lire l’explication complète de la marmotte

Cacher le contenu ou cacher l’existence

Le chiffrement protège contre la lecture. Sans la clé, le contenu est inintelligible, mais tout le reste demeure visible : qu’un message existe, sa taille, son expéditeur, son destinataire, son heure d’envoi. Ces métadonnées suffisent souvent à l’adversaire. Savoir qu’un service juridique échange chaque nuit 2 Go avec un cabinet d’avocats renseigne déjà beaucoup, sans lire un octet.

La stéganographie protège contre la détection. Elle dissimule l’existence même du message dans un support anodin : une image, un son, un texte, l’espacement de paquets réseau. La technique la plus connue remplace le bit de poids faible de chaque composante de couleur d’une image par un bit du message ; l’œil ne voit pas la différence entre une teinte de valeur 200 et une de 201. Mais une stéganographie détectée ne protège plus rien si le message n’a pas été chiffré au préalable. Et elle viole volontiers le principe de Kerckhoffs : sa sécurité repose souvent sur le secret de la méthode, que la stéganalyse statistique finit par trahir, car modifier les bits de poids faible altère la distribution des valeurs d’une façon mesurable. En pratique, on chiffre d’abord, on dissimule ensuite.

Le canal caché (covert channel) applique la même idée aux systèmes : faire passer de l’information par un moyen non prévu pour cela. Des données exfiltrées dans des requêtes DNS (Domain Name System), dans des champs d’en-tête inutilisés ou dans le rythme d’émission de paquets échappent aux contrôles qui ne regardent que les flux attendus. Les risques opérationnels existent dans les deux sens : un défenseur doit savoir que ces canaux existent, et une organisation qui en utilise un pour contourner sa propre politique fabrique un angle mort que le premier attaquant venu exploitera aussi.

Dernier cas, la dissimulation de chiffré dans du chiffré. Les volumes cachés de VeraCrypt placent un second volume chiffré dans l’espace libre d’un premier, rempli de données aléatoires : sous la contrainte, l’utilisateur livre le mot de passe du volume extérieur, et rien ne prouve mathématiquement l’existence du second. Ce déni plausible reste fragile : traces dans le système d’exploitation, fichiers récents, instantanés de disque ou simple invraisemblance d’un volume de 500 Go contenant trois photos de vacances.

Coder n’est pas protéger

Un encodage change la représentation des données sans secret. Il est réversible par quiconque connaît la convention, c’est-à-dire tout le monde.

L’hexadécimal écrit chaque octet avec deux caractères : bonjour devient 62 6f 6e 6a 6f 75 72, et la taille double. Le Base64 regroupe trois octets en quatre caractères pris dans un alphabet de 64 symboles, ce qui augmente la taille d’un tiers : bonjour devient Ym9uam91cg==, le == final complétant le dernier groupe. Le binaire n’est que la forme brute. Aucun de ces formats ne protège. L’authentification HTTP (HyperText Transfer Protocol) de type Basic transmet admin:secret sous la forme YWRtaW46c2VjcmV0, ce qui protège à peu près autant qu’un cadenas dessiné au feutre ; seul le TLS (Transport Layer Security) du canal, traité dans Sécuriser un canal: TLS, HTTPS et mTLS, en assure la confidentialité.

La compression supprime la redondance. Un texte français se compresse bien, un chiffré pas du tout : un bon chiffrement produit une sortie indiscernable de l’aléa, donc sans redondance exploitable. D’où la règle d’ordre : si l’on veut compresser, il faut compresser avant de chiffrer, l’inverse ne gagnant rien.

Cette règle a un prix : les fuites par taille. Après compression, la longueur du chiffré dépend du contenu. Si un attaquant peut injecter ses propres données à côté d’un secret et observer la taille du résultat, il devine le secret caractère par caractère : une supposition correcte se compresse mieux, car elle répète le secret. C’est le principe des attaques CRIME (2012), contre la compression au niveau TLS, et BREACH (2013), contre la compression HTTP des réponses. La compression TLS a été désactivée puis retirée de TLS 1.3 ; pour HTTP, les parades consistent à ne pas compresser les réponses qui mêlent secrets et données contrôlées par l’utilisateur, ou à masquer les jetons à chaque réponse. Même sans compression, la taille trahit : la longueur d’une requête chiffrée vers un site d’information juridique peut suffire à identifier la page consultée. Le remplissage (padding) réduit ce signal sans le supprimer.

Enfin, les formats reconnaissables signent leur nature dès les premiers octets, ce qui est une métadonnée de plus. Un fichier commençant par Salted__ a été produit par openssl enc ; age-encryption.org/v1 annonce un fichier age ; -----BEGIN PGP MESSAGE----- un message OpenPGP ; un en-tête LUKS un volume chiffré Linux. Un ZIP commence par PK, un gzip par les octets 1f 8b.

Effacer, archiver, perdre

Supprimer un fichier retire en général son entrée dans le répertoire et marque ses blocs comme libres, sans les écraser. Un outil de récupération les retrouve tant qu’ils n’ont pas été réutilisés. Sur un disque SSD (Solid-State Drive), l’écrasement logiciel est lui-même incertain : le contrôleur répartit les écritures sur des cellules différentes (wear leveling) et garde des zones de réserve inaccessibles au système. Il faut donc distinguer l’effacement logique (le système ne voit plus la donnée), l’effacement physique (le support ne la contient plus) et la destruction du support. Le guide NIST SP 800-88 (National Institute of Standards and Technology, Special Publication) les classe en trois niveaux : Clear, Purge et Destroy.

La destruction par effacement de clé (crypto-shredding, ou effacement cryptographique) contourne le problème : si les données n’ont jamais été écrites qu’en chiffré, détruire la clé les rend illisibles partout, y compris sur les copies oubliées. Le SP 800-88 reconnaît l’effacement cryptographique comme méthode de purge, à condition que la clé ait été correctement générée et que toutes ses copies soient détruites. La technique est détaillée dans Comment détruire une clé pour effacer des données chiffrées. La condition « toutes ses copies » est la plus difficile : clé dans un module matériel, dans sa sauvegarde, dans un séquestre, dans la mémoire d’un processus, dans un fichier de configuration versionné.

L’archivage chiffré inverse la préoccupation : il faut pouvoir relire dans dix ans. Perdre la clé d’une archive revient à la détruire, avec moins d’élégance. Une archive chiffrée exige donc une politique de conservation des clés aussi longue que celle des données, et des tests de restauration réels, pas seulement de sauvegarde. Le sujet est développé dans Protéger les données au repos : disque, base, sauvegarde.

Les données résiduelles sont le dernier piège : fichiers temporaires, espace d’échange (swap), journaux applicatifs, caches de navigateur, instantanés de systèmes de fichiers à copie sur écriture, réplicas de base de données, exports CSV envoyés par courriel. Une politique d’effacement qui ignore ces copies détruit l’original et préserve tout le reste. Elle doit en outre composer avec le droit : le RGPD (Règlement général sur la protection des données) prévoit un droit à l’effacement à son article 17, tandis que d’autres textes imposent des durées de conservation minimales. Les durées exactes dépendent du secteur et de la juridiction, et relèvent d’un juriste plutôt que d’un administrateur système.

Reconnaître un objet cryptographique

Comment savoir si un fichier est chiffré ? Le premier indice est l’entropie apparente, mesurée en bits par octet : environ 4 à 5 pour un texte, proche de 8 pour un chiffré. Le second, plus fiable, est l’en-tête : les formats cités plus haut s’annoncent eux-mêmes.

Les faux positifs abondent. Un fichier compressé, une image JPEG, une vidéo ou un fichier de nombres aléatoires affichent tous une entropie proche de 8 bits par octet. Du texte chiffré ressemble à du bruit aléatoire, mais du bruit aléatoire n’est pas forcément du chiffré : une partition remplie d’aléa avant installation est indiscernable d’un volume chiffré sans en-tête. Les faux négatifs existent aussi : un chiffré encodé en Base64 tombe à environ 6 bits par caractère, et un chiffrement qui préserve le format produit des numéros de carte d’apparence ordinaire.

Les limites de la détection sont donc structurelles. Un outil de prévention des fuites qui bloque « tout ce qui a l’air chiffré » bloquera des archives ZIP légitimes et laissera passer un chiffré soigneusement déguisé. La détection d’objets cryptographiques est un indice d’enquête, pas une preuve.

Exemples et ateliers

Encodage contre chiffrement. La démonstration tient en deux commandes :

printf 'admin:secret' | base64          # YWRtaW46c2VjcmV0
printf 'YWRtaW46c2VjcmV0' | base64 -d   # admin:secret, sans aucune clé

Aucun secret n’a été nécessaire pour revenir en arrière : c’est la définition d’un encodage.

Compresser puis chiffrer. Sur un texte de licence de 35 149 octets, avec gzip -9 et openssl enc -aes-256-cbc -pbkdf2 :

Opération	Taille obtenue
Fichier d’origine	35 149 octets
Compressé seul	12 130 octets
Chiffré seul	35 168 octets (en-tête de 16 octets et remplissage)
Chiffré puis compressé	35 202 octets, plus gros que l’entrée
Compressé puis chiffré	12 160 octets

Le chiffré ne se compresse pas, il grossit même légèrement sous l’effet des en-têtes gzip. Le mode CBC (Cipher Block Chaining) de openssl enc ne sert ici qu’à la mesure : il n’authentifie rien, et n’a pas sa place dans un vrai système.

Politique de destruction par effacement de clé. Pour une base de dossiers clients conservés trois ans : une clé de chiffrement de données par client, elle-même chiffrée par une clé maîtresse dans un service de gestion de clés ; les sauvegardes ne contiennent que des données chiffrées et des clés enveloppées ; à l’échéance, la clé du client est supprimée, et la suppression est journalisée. Les services de gestion de clés imposent souvent un délai avant destruction effective (de 7 à 30 jours chez AWS KMS, Key Management Service) : c’est une protection contre l’erreur, qu’il faut intégrer au délai annoncé. Il reste à s’assurer que la clé n’a jamais été exportée en clair, ni écrite dans un journal.

Pièges classiques

Vendre un encodage comme une protection, généralement sous la forme d’un champ « mot de passe chiffré » en Base64. Compresser des données sensibles dans un protocole où l’attaquant peut injecter du contenu et observer les tailles. Croire que supprimer un fichier détruit l’information, alors qu’il vient seulement de perdre son nom. Oublier les sauvegardes, qui conservent fidèlement tout ce qu’on croit avoir effacé.

À ne pas confondre

La stéganographie cache l’existence d’un message ; le chiffrement cache son contenu. La compression réduit la taille ; elle n’apporte aucune confidentialité, et peut même en retirer. L’effacement logique supprime une référence ; l’effacement physique supprime les données. Un texte chiffré ressemble à du bruit aléatoire, mais la réciproque est fausse.

FAQ

Base64 est-il une forme faible de chiffrement ?
Non, ce n’est pas du chiffrement du tout. Aucune clé n’intervient, et la transformation est publique.

Faut-il compresser avant de chiffrer ?
Pour des fichiers au repos, oui, c’est le seul ordre qui gagne de la place. Pour un protocole interactif où un attaquant peut mêler ses données aux secrets, la compression ouvre une fuite par la taille.

Effacer la clé suffit-il à détruire les données ?
Oui, si les données n’ont jamais existé en clair ailleurs et si aucune copie de la clé ne subsiste. Ce sont deux conditions fortes, à contrôler plutôt qu’à supposer.

Conclusion

Chiffrer, cacher, coder, compresser et effacer sont cinq opérations distinctes, aux garanties distinctes. Le chiffrement protège le contenu et laisse voir les métadonnées ; la stéganographie cache l’existence sans protéger le contenu découvert ; l’encodage et la compression ne protègent rien ; l’effacement n’efface que ce qu’on a pensé à effacer. Nommer correctement chaque opération est la première protection, et la moins coûteuse.

🐝 Ce qui arrive si on s’en passe

Confondre ces frontières produit des protections qui n’existent que dans le cahier des charges. Un champ « chiffré » qui n’est qu’encodé se lit avec le premier décodeur venu, tout en figurant comme protégé dans l’inventaire, si bien que personne ne le cherche le jour d’une fuite. Une politique de destruction qui supprime les fichiers sans effacer les clés ni purger les sauvegardes laisse l’information à quiconque restaure une ancienne copie : l’organisation croit s’être débarrassée de données qu’elle détient toujours, et ne peut donc pas garantir leur effacement à ceux qui le demandent. Enfin, un contenu chiffré mais de taille variable continue de trahir ce qu’il contient par son seul volume.

🦫 Explication de la marmotte 🍫

Plusieurs techniques transforment des données sans offrir les mêmes garanties que le chiffrement. Le chiffrement rend le contenu illisible sans la clé, mais laisse voir qu’un message existe, sa taille, son expéditeur et son heure. La stéganographie cache au contraire l’existence du message, par exemple dans une image, sans forcément le protéger une fois découvert. L’encodage, comme Base64 ou l’hexadécimal, réécrit simplement les données avec d’autres caractères : n’importe qui peut revenir en arrière sans secret. La compression réduit la taille en supprimant les répétitions. Si l’on compresse avant de chiffrer, la taille du résultat dépend du contenu ; dans un protocole où un attaquant peut ajouter ses propres données et observer la taille obtenue, il peut deviner des secrets morceau par morceau. Détruire l’information est aussi délicat. Supprimer un fichier retire souvent seulement son nom, et les données restent sur le disque ou dans les sauvegardes. Quand les données sont chiffrées, effacer la clé suffit à les rendre illisibles partout, à condition qu’aucune copie de cette clé ne subsiste. Enfin, des données chiffrées ressemblent à du hasard, mais du hasard n’est pas forcément du chiffré : les outils qui repèrent les objets chiffrés d’après leur aspect ou leurs en-têtes se trompent parfois, dans un sens comme dans l’autre.

À lire aussi

• Protéger une information en environnement hostilePoser les quatre garanties cryptographiques de base, distinguer primitive et système, et délimiter ce que la cryptographie ne répare jamais.
• Parler le langage des clés, des messages et des attaquantsDonner un vocabulaire stable pour lire tout le reste du site et éviter les confusions récurrentes entre clé, nonce, sel, tag, certificat et secret.
• Du chiffre manuel au chiffrement moderneUtiliser les systèmes classiques comme support pédagogique, puis montrer pourquoi les constructions modernes exigent modèles, clés, modes et authentification.
• Créer, vérifier et utiliser les clés dès le départInstaller les réflexes de génération, vérification, usage séparé et protection de clés avant d’aborder les primitives qui les consomment.

Pages voisines

La citent

• Choisir, combiner et migrer les algorithmes symétriques
• Équité, vote, contrats et divulgation contrôlée
• JWE : chiffrer un jeton JSON sans se tromper
• JWS : signer et sécuriser vos échanges JSON

Frontières : cacher, coder, compresser et détruire

Elle cite

• Comment détruire une clé pour effacer des données chiffrées
• Protéger les données au repos : disque, base, sauvegarde
• Sécuriser un canal: TLS, HTTPS et mTLS
• Ce que le bout en bout laisse voir
• L'effacement impossible
• Pourquoi supprimer un fichier ne l'efface pas