Le coffre de la bijouterie

Au cœur de la galerie des Arcades, la bijouterie possède un coffre. Le bijoutier y range les pièces les plus précieuses chaque soir. Personne ne discute l'utilité de l'objet : ce qui a de la valeur se protège derrière une serrure.

Mais une serrure soulève toujours les mêmes questions. Qui détient la clé ? Comment la confier à un collègue sans qu'elle traîne dans la nature ? Et quand le coffre est ouvert le matin, comment être certain que personne n'a touché au contenu pendant la nuit ?

La cryptographie répond à ces trois questions avec trois familles de mécanismes distincts. Les confondre coûte cher, on le verra avec un incident réel à la fin de ce billet.

La cryptographie ne se résume pas à « rendre illisible ». C'est une boîte à outils où chaque outil répond à un besoin précis : garder un secret, prouver une identité, ou détecter une modification.

Ce que la cryptographie garantit

Avant les algorithmes, les objectifs. Trois propriétés reviennent en permanence.

La confidentialité empêche un tiers de lire une donnée. C'est le coffre fermé : le contenu existe, mais reste inaccessible sans la clé.

L'intégrité garantit qu'une donnée n'a pas été modifiée, par accident ou par malveillance. C'est le sceau de cire sur un pli : s'il est brisé, on le sait.

L'authenticité prouve l'origine d'une donnée ou l'identité d'un correspondant. C'est la signature du notaire : elle relie un document à une personne.

Ces objectifs recoupent la triade de sécurité (confidentialité, intégrité, disponibilité) vue dans les premiers billets de la série. La cryptographie outille surtout les deux premiers piliers, et joue un rôle clé dans la défense en profondeur : même si un attaquant atteint la donnée, elle reste protégée.

Pour les couvrir, on dispose de trois grandes familles : le chiffrement symétrique, le chiffrement asymétrique et le hachage. Le tableau de fin de billet les met côte à côte. On les prend une par une.

Chiffrement symétrique : une seule clé pour fermer et ouvrir

Reviens au coffre de la bijouterie. La même clé le ferme le soir et l'ouvre le matin. C'est exactement le principe du chiffrement symétrique : une clé unique sert à chiffrer et à déchiffrer.

Le mécanisme est rapide et économe. C'est pour cela qu'il protège l'essentiel des données au repos (disques chiffrés, sauvegardes, bases de données) et le gros du trafic en transit.

L'algorithme de référence est AES (Advanced Encryption Standard), normalisé par le NIST dans FIPS 197. Il chiffre les données par blocs, avec des tailles de clé de 128, 192 ou 256 bits.

AES n'opère pas un bloc isolément sans contexte : il s'utilise dans un mode opératoire (CBC, CTR, GCM…). Le choix du mode compte autant que l'algorithme. On y revient avec le cas Adobe.

Le chiffrement symétrique a un défaut structurel : la distribution de la clé. Si deux correspondants veulent échanger en sécurité, ils doivent d'abord partager la même clé secrète. Comment la transmettre par un canal qui n'est pas encore sécurisé, sans qu'un tiers l'intercepte ? C'est le problème de l'œuf et de la poule du secret partagé.

Dans la galerie, cela revient à dupliquer la clé du coffre pour chaque employé qui doit y accéder. Plus il y a de copies en circulation, plus le risque qu'une clé soit perdue ou volée augmente. Et confier cette clé à un nouveau prestataire sans la lui glisser sous le manteau relève du casse-tête.

Chiffrement asymétrique : la boîte aux lettres à fente publique

Le chiffrement asymétrique résout précisément ce problème de distribution. Au lieu d'une clé unique, il en utilise deux, liées mathématiquement : une clé publique et une clé privée.

L'image qui colle : une boîte aux lettres dans le hall des Arcades. La fente est publique, visible de tous. N'importe qui peut y déposer un courrier. Mais seul le propriétaire, avec sa clé privée, peut ouvrir la boîte et lire ce qu'elle contient.

Concrètement :

  • Ce qui est chiffré avec la clé publique ne peut être déchiffré qu'avec la clé privée correspondante. Cela assure la confidentialité : tout le monde peut t'écrire, toi seul peux lire.
  • L'opération inverse sert la signature. Ce qui est chiffré (signé) avec la clé privée se vérifie avec la clé publique. Comme seul le propriétaire détient la clé privée, cela prouve l'origine : c'est l'authenticité.

La clé publique se diffuse librement, sans précaution. Le problème de distribution disparaît : plus besoin de transmettre un secret partagé au préalable.

Les algorithmes connus sont RSA, fondé sur la difficulté de factoriser de grands nombres, et la cryptographie sur courbes elliptiques (ECC), qui atteint une sécurité comparable avec des clés plus courtes.

La contrepartie est la lenteur. Les opérations asymétriques sont nettement plus coûteuses en calcul que les opérations symétriques. Chiffrer un gros volume de données uniquement en asymétrique serait impraticable.

Symétrique : rapide, mais comment partager la clé ? Asymétrique : règle le partage, mais trop lent pour de gros volumes. Aucun des deux ne suffit seul.

L'approche hybride : le meilleur des deux

La solution n'est pas de choisir, mais de combiner. C'est ce que fait TLS, le protocole derrière le cadenas du https://.

Le principe tient en deux temps. L'asymétrique sert à établir la confiance et à convenir d'un secret. Le symétrique prend ensuite le relais pour chiffrer la conversation, parce qu'il est rapide.

1. Le client vérifie l'identité du serveur (clé publique du certificat).
2. Les deux parties négocient une clé de session symétrique,
   protégée par l'asymétrique.
3. Toute la suite des échanges est chiffrée en symétrique (AES),
   avec cette clé de session jetable.

L'asymétrique fait le travail délicat d'amorçage (établir la confiance et transporter le secret), puis s'efface au profit du symétrique pour le débit. La gestion de ces clés publiques et des certificats qui les accompagnent forme un sujet à part entière, la PKI, qui fera l'objet du billet suivant.

flowchart LR A["Donnée en clair"] --> B{"Quel besoin ?"} B -->|"Confidentialité, gros volume"| C["Symétrique
une clé partagée
AES"] B -->|"Échange de clé, signature"| D["Asymétrique
clé publique + privée
RSA / ECC"] C --> E["Donnée chiffrée
réversible"] D --> E E -->|"avec la bonne clé"| F["Donnée en clair"] classDef sym fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef asym fill:#2c3338,stroke:#1f2428,color:#f5f2ec; classDef data fill:#f5f2ec,stroke:#b5651d,color:#1a1a1a; class C sym; class D asym; class A,E,F data;

Le hachage : un sceau, pas une serrure

Le hachage rompt avec ce qui précède. Le chiffrement est réversible : ce qui est chiffré se déchiffre. Le hachage est à sens unique : on ne revient jamais en arrière.

Une fonction de hachage prend une donnée de taille quelconque et produit une empreinte de taille fixe (le condensat, ou hash). La même entrée donne toujours la même empreinte. Mais à partir de l'empreinte, retrouver l'entrée d'origine est calculatoirement infaisable.

Reprends le pli scellé à la cire. Le sceau est une empreinte du contenu. Il ne cache rien, il ne ferme rien : il prouve que le pli n'a pas été ouvert. Si la lettre change, l'empreinte change. Le sceau ne te permet pas de reconstituer la lettre, seulement de vérifier qu'elle est intacte.

Le hachage n'est pas du chiffrement. Il ne sert pas à cacher, mais à vérifier. Pas de clé, pas de déchiffrement, pas de retour en arrière. Confondre les deux est l'erreur de sécurité la plus coûteuse de ce billet.

Une bonne fonction de hachage a deux propriétés essentielles. La moindre modification de l'entrée change radicalement l'empreinte (effet d'avalanche). Et il doit être impraticable de trouver deux entrées différentes produisant la même empreinte (résistance aux collisions).

La famille de référence est SHA-2, normalisée par le NIST dans FIPS 180-4, qui regroupe notamment SHA-256 et SHA-512. Les usages typiques : vérifier l'intégrité d'un fichier téléchargé, indexer du contenu, et servir de brique aux signatures numériques.

flowchart LR A["Contrat (1 page)"] --> H["Fonction de hachage
SHA-256"] B["Contrat (1 page + 1 virgule)"] --> H H --> C["empreinte abc123..."] H --> D["empreinte 7f9e2d..."] C -.->|"impossible de revenir"| A classDef fn fill:#a0413e,stroke:#8a4d16,color:#f5f2ec; classDef out fill:#2c3338,stroke:#1f2428,color:#f5f2ec; classDef in fill:#f5f2ec,stroke:#b5651d,color:#1a1a1a; class H fn; class C,D out; class A,B in;

Les trois familles en un coup d'œil

Mécanisme Clé(s) Réversible ? Usage type
Chiffrement symétrique Une clé partagée Oui (déchiffrement) Données au repos, trafic en masse (AES)
Chiffrement asymétrique Paire publique / privée Oui (déchiffrement) Échange de clé, signature, identité (RSA, ECC)
Hachage Aucune Non (sens unique) Intégrité, empreintes, stockage de secrets (SHA-2)

La ligne « réversible » est celle qui sépare les usages. Tout ce qui doit être relu un jour se chiffre. Tout ce qui ne doit jamais être relu en clair se hache.

Stocker des mots de passe : hachage, sel et lenteur volontaire

Le mot de passe est le cas d'école. Une application n'a aucune raison de relire un mot de passe en clair : à la connexion, elle compare l'empreinte du mot de passe saisi avec l'empreinte stockée. Le mot de passe se hache, jamais ne se chiffre.

Mais le hachage seul ne suffit pas. Deux personnes avec le même mot de passe obtiennent la même empreinte. Un attaquant peut donc précalculer les empreintes des mots de passe courants (tables arc-en-ciel) et comparer en masse.

C'est là qu'intervient le sel. Le sel est une valeur aléatoire, unique par compte, ajoutée au mot de passe avant le hachage. Deux mots de passe identiques produisent alors deux empreintes différentes, et les tables précalculées deviennent inutiles. Le NIST détaille la dérivation de clé à partir d'un mot de passe et le rôle du sel dans SP 800-132.

Dans la galerie, c'est l'idée d'ajouter une marque unique à chaque sceau de cire. Deux plis au contenu identique portent alors des empreintes distinctes : impossible de deviner l'un en observant l'autre.

Dernier ingrédient : la lenteur. SHA-256 est conçu pour être rapide, ce qui est une qualité pour vérifier un fichier mais un défaut pour stocker un mot de passe (un attaquant teste des milliards de combinaisons par seconde). On utilise donc des fonctions délibérément lentes et coûteuses en mémoire, conçues pour cet usage : bcrypt, scrypt et Argon2. L'OWASP Password Storage Cheat Sheet en fait la recommandation centrale.

Le bon réflexe pour un mot de passe : une fonction lente (bcrypt, scrypt ou Argon2), un sel unique par compte. Jamais de chiffrement, jamais un simple SHA-256 nu.

Le contre-exemple : la fuite Adobe de 2013

En 2013, Adobe a subi une compromission massive de sa base d'utilisateurs. L'ordre de grandeur rapporté dépasse les 150 millions de comptes. L'incident est devenu un cas d'école, non pour la taille de la fuite, mais pour la manière dont les mots de passe étaient protégés.

Adobe avait chiffré les mots de passe, au lieu de les hacher et saler. Le chiffrement employé était symétrique par blocs, en mode ECB (Electronic Codebook). Ce mode chiffre chaque bloc indépendamment, avec la même clé, sans le lier aux blocs voisins. Conséquence : deux mots de passe identiques produisent exactement le même bloc chiffré.

L'analyse de Sophos Naked Security a détaillé l'enchaînement. Le chiffrement étant réversible, la sécurité reposait entièrement sur le secret de la clé, et non sur une propriété mathématique à sens unique. Pire, les indices de mot de passe étaient stockés en clair à côté. En regroupant tous les comptes partageant le même bloc chiffré et en croisant leurs indices, beaucoup de mots de passe devenaient devinables sans même casser le chiffrement.

C'est l'illustration exacte de la confusion combattue dans ce billet :

  • Chiffrement (réversible) : choisi à tort. Si la clé fuite, tous les mots de passe tombent. Le mode ECB a aggravé le tout en laissant transparaître les répétitions.
  • Hachage et sel (sens unique) : ce qu'il aurait fallu. Pas de clé à protéger, et un sel unique par compte aurait rendu les empreintes incomparables entre elles.
Un mot de passe correctement stocké ne peut pas « fuiter en clair » même si la base entière est volée, parce qu'il n'existe nulle part en clair ni sous une forme réversible. C'est toute la différence entre chiffrer et hacher.

Points clés

  • Trois familles, trois besoins. Chiffrement symétrique pour la confidentialité rapide (AES), asymétrique pour l'échange de clé et la signature (RSA, ECC), hachage pour l'intégrité (SHA-2).
  • Réversible ou non, c'est la frontière. Ce qui doit être relu se chiffre. Ce qui ne doit jamais l'être (un mot de passe) se hache.
  • Le hachage n'est pas du chiffrement. Pas de clé, pas de retour en arrière. Un sceau qui prouve, pas une serrure qui cache.
  • Mots de passe : hachage + sel + lenteur. Une fonction lente (bcrypt, scrypt, Argon2) et un sel unique par compte, jamais un chiffrement.
  • Adobe 2013 a payé la confusion. Mots de passe chiffrés en mode ECB plutôt que hachés et salés, indices en clair : des millions de comptes exposés.

Dans la série

Palier 2 : Verrouiller les accès. Domaine : Cryptographie.

Pour aller plus loin