Chapitre 6. Cryptographie appliquée à Vault

Objectifs pédagogiques¶

Distinguer encodage, hachage, HMAC, chiffrement symétrique et asymétrique. Expliquer l'apport du chiffrement authentifié et le rôle du nonce. Décrire le chiffrement par enveloppe. Restituer la hiérarchie complète des clés. Distinguer rotate et rekey, et énoncer leur effet sur les copies passées.

Prérequis¶

Chapitres 4 et 5. Aucune connaissance cryptographique préalable n'est supposée.

Cours¶

6.1 Chiffrement symétrique et chiffrement authentifié¶

Le chiffrement symétrique, une même clé pour chiffrer et déchiffrer, est l'outil du volume : rapide et sûr à tailles de clé raisonnables. Mais il garantit la confidentialité, pas l'intégrité. Un chiffré modifié bit à bit se déchiffre en quelque chose de faux, parfois d'exploitable. Pour un coffre, accepter silencieusement une policy altérée serait pire qu'une panne.

D'où le chiffrement authentifié : chaque opération produit, en plus du chiffré, une étiquette d'authentification vérifiée au déchiffrement. Toute altération fait échouer l'opération franchement. C'est ce que fait la barrière, en AES-256-GCM.

Ce mode a une exigence à connaître même si Vault la gère : le nonce, une valeur jointe à chaque chiffrement, qui doit être unique pour une clé donnée. Ce n'est pas un secret, il est stocké avec le chiffré ; c'est un « jamais deux fois ». Réutiliser un couple clé-nonce est catastrophique : cela révèle la combinaison des clairs et peut permettre des falsifications. C'est l'exemple canonique de la raison pour laquelle on ne fait pas sa propre cryptographie : l'algorithme est irréprochable, et un détail d'utilisation ruine tout.

6.2 Asymétrique et signatures¶

Un couple de clés aux rôles complémentaires : ce que la publique chiffre, seule la privée le déchiffre ; ce que la privée signe, la publique le vérifie. Trois familles que vous croiserez : RSA, historique, 2048 bits en plancher ; ECDSA sur courbes P-256 et P-384, clés plus courtes à sécurité équivalente ; Ed25519, moderne et rapide, souvent le bon choix quand l'écosystème le supporte.

L'asymétrique est lent et limité en taille de message. Son métier est d'établir la confiance : envelopper une clé symétrique qui fera le volume, et signer, c'est-à-dire garantir l'origine et l'intégrité sans cacher le contenu. Les certificats X.509 du moteur PKI sont des clés publiques signées par une autorité ; les certificats SSH appliquent le même motif aux accès machines.

6.3 Hachage et HMAC¶

Une fonction de hachage transforme une donnée en empreinte de taille fixe, à sens unique, sensible à la moindre modification, et sans collision en pratique. Le hachage n'est pas du chiffrement : il n'y a pas de clé, donc rien à déchiffrer ; une empreinte ne se renverse pas, elle se compare. Précision utile : un hachage rapide ne convient pas au stockage de mots de passe humains, qui exige des fonctions lentes et salées.

Le HMAC ajoute une clé au hachage. L'empreinte n'est calculable que par un détenteur de la clé. Deux propriétés en découlent, qui expliquent son rôle dans l'audit : sans la clé, aucune attaque par dictionnaire sur le journal ; avec la clé, l'empreinte est déterministe, ce qui permet de rechercher sans exposer.

6.4 La dérivation de clés¶

Fabriquer, à partir d'un secret de base et d'un contexte, des clés distinctes de manière déterministe et à sens unique. Deux vertus : la démultiplication, un secret bien gardé engendrant autant de clés d'usage qu'il faut sans les stocker ; et le cloisonnement, la clé dérivée pour un contexte ne servant à rien pour un autre, sans que sa compromission remonte au secret de base. Vault en fait un usage interne et un usage que vous piloterez au chapitre 16.

6.5 Le chiffrement par enveloppe¶

Les données sont chiffrées par une clé de données, la DEK, symétrique. La DEK est chiffrée par une clé d'enveloppe, la KEK. On stocke la DEK chiffrée à côté des données et l'on ne garde précieusement que la KEK.

C'est l'industrialisation du constat du chapitre 1 : chiffrer déplace le problème vers une clé plus petite. Trois bénéfices. Rotation économique : changer la KEK ne demande de re-chiffrer que les DEK. Contrôle central : qui peut déchiffrer se décide là où vit la KEK, un point unique à défendre et journaliser. Compartimentage : une DEK par périmètre borne la compromission.

Ce motif est partout : c'est ainsi que fonctionnent les services de clés des clouds, ainsi que Transit servira vos applications, et ainsi, en enveloppes emboîtées, que Vault se protège lui-même.

6.6 La barrière et son keyring¶

La barrière chiffre chaque entrée en AES-256-GCM, nonce unique par écriture. La clé employée vit dans le keyring : non pas une clé, mais une liste versionnée, chaque version étant un term numéroté. Chaque entrée stockée enregistre le term qui l'a chiffrée.

Ce versionnage rend la rotation banale. vault operator rotate ajoute un term : les écritures suivantes l'utilisent, les entrées existantes restent lisibles avec leur term d'origine, et migrent vers la clé courante au fil de leurs réécritures. Re-chiffrement paresseux, sans campagne ni indisponibilité. L'opération est en ligne, immédiate, sans quorum. Une planification automatique de cette rotation existe dans les versions récentes ; le numéro exact se vérifie dans les notes de la version installée.

Le keyring est lui-même une donnée, la plus précieuse du stockage, et il est chiffré à son tour par la clé racine.

6.7 La hiérarchie complète des clés¶

   mecanisme de scellement (seal)          <- racine de confiance
   Shamir : k fragments parmi n              (partie VII)
   Auto Unseal : cle d'un KMS externe
   Transit Seal : cle d'un autre Vault
        |
        |  protege (la reconstitue ou la dechiffre)
        v
   CLE RACINE (root key)                   <- jamais stockee en clair ;
        |                                     n'existe qu'en memoire
        |  chiffre
        v
   KEYRING : cles de la barriere           <- versionnees (terms) ;
        |                                     'operator rotate' ajoute
        |  chiffrent (AES-256-GCM)            un term
        v
   DONNEES : tout ce que Vault persiste

Lecture de bas en haut, avec la question du chapitre 1. Les données sont chiffrées par les clés du keyring. Ces clés sont protégées par la clé racine, qui chiffre le keyring. Et la clé racine est protégée par le mécanisme de scellement, où la chaîne s'arrête. Le seal est la racine de confiance du chapitre 2 : le point dont la sécurité ne se démontre plus mais se décide.

Selon le mécanisme, la racine se déplace. Avec Shamir, la clé racine n'est stockée nulle part : elle se reconstitue en mémoire depuis k fragments détenus par des humains, et la racine, ce sont ces personnes et la garde de leurs fragments. Avec l'Auto Unseal, elle est stockée chiffrée par une clé que détient un service externe. Avec le Transit Seal, ce tiers est un autre Vault, choix qu'Astrea fera en partie VII.

Note de version : la documentation dit aujourd'hui root key là où les textes anciens disaient master key. Ce cours emploie « clé racine ».

Deux précisions valent pour la suite du cursus. Les fragments de Shamir partagent la clé racine, pas la clé de chiffrement des données : entre un fragment et un secret lu, il y a deux étages. Et les moteurs ajoutent leurs propres étages sous cet édifice : le keyring de Transit, les clés d'autorité de PKI sont, du point de vue de la barrière, des données comme les autres.

6.8 `rotate` et `rekey`¶

Deux commandes aux noms cousins qui n'opèrent ni au même étage, ni avec les mêmes exigences.

vault operator rotate agit sur le keyring : nouveau term pour les écritures à venir, anciennes données lisibles et re-chiffrées paresseusement. Opération en ligne, sans quorum, sans effet sur la clé racine ni sur les fragments. Cas d'usage : l'hygiène périodique de la clé qui touche les données.

vault operator rekey agit sur la clé racine et ses parts : nouvelle clé racine, re-chiffrement du keyring par elle, redistribution de nouveaux fragments, avec au besoin un nouveau paramétrage de n et k. L'opération exige un quorum des fragments actuels et se déroule en cérémonie. Ses cas d'usage sont humains : un détenteur part, un fragment est suspecté, la répartition doit changer. Sur un cluster en Auto Unseal, la même commande avec -target=recovery fait l'équivalent pour les recovery keys, qui autorisent des opérations sensibles mais ne descellent pas.

	`rotate`	`rekey`
Objet	clé de chiffrement des données	clé racine et ses parts
Qui	un administrateur autorisé, en ligne	un quorum, en cérémonie
Effet	nouveau term, données anciennes intactes	nouveaux fragments, anciens invalidés sur ce cluster
Données	re-chiffrement paresseux	inchangées, seul le keyring est re-chiffré

Un dernier effet, contre-intuitif : ni l'une ni l'autre n'agit sur les copies passées. Un snapshot d'hier embarque le keyring d'hier, chiffré par la clé racine d'hier. Après un rekey, les anciens fragments, invalidés sur le cluster vivant, reconstituent toujours l'ancienne clé racine et rouvrent l'ancien snapshot. Le rekey protège le présent et l'avenir, il ne périme pas le passé. Rendre d'anciennes sauvegardes inexploitables exige de détruire les anciens snapshots ou les anciens fragments, idéalement les deux, avec registre à l'appui.

6.9 Le HMAC dans l'audit¶

Chaque dispositif d'audit reçoit à sa création un sel propre. Toute valeur sensible est journalisée sous la forme d'une empreinte HMAC calculée avec ce sel.

Le journal ne contient aucun secret : sa compromission n'en livre pas. Il reste interrogeable : l'endpoint sys/audit-hash calcule, pour un dispositif donné, l'empreinte d'une valeur que vous connaissez, et une recherche la retrouve dans l'historique. Enfin, le sel par dispositif cloisonne : les empreintes du fichier et celles du syslog ne se correspondent pas, et un attaquant qui obtient un journal ne peut s'en servir de dictionnaire pour un autre.

6.10 La place de TLS¶

TLS protège les données en transit, entre les clients et le listener, et entre les nœuds sur le port de cluster avec un TLS interne que Vault gère seul. La barrière protège les données au repos. Deux frontières distinctes, deux mécanismes indépendants, et l'un ne rachète jamais l'autre : « le stockage est chiffré » ne justifie aucun tls_disable, et « TLS est partout » ne dispense pas de la barrière.

Réglage à connaître pour le chapitre 7 : Vault exige par défaut TLS 1.2 au minimum, relevable à 1.3. La vraie difficulté ne sera pas le serveur mais la vérification côté clients, que la PKI interne du chapitre 28 rendra systématique.

Exemple : le vol au repos, déroulé étage par étage¶

Un disque de vault-core-01, ou un snapshot, se retrouve entre de mauvaises mains.

L'attaquant y trouve les entrées du stockage : opaques, chiffrées en AES-256-GCM, portant le numéro du term qui les a chiffrées. Pour lire, il lui faut le keyring : il est là, dans le lot, chiffré par la clé racine. La clé racine n'est nulle part sur ce disque, Astrea étant en Shamir à ce stade : elle n'existe qu'en mémoire d'un serveur descellé et se reconstitue depuis trois des cinq fragments. L'attaque s'arrête à l'étage exact prévu par la hiérarchie.

S'il tente d'altérer des entrées avant de rendre discrètement le disque, le chiffrement authentifié rejette la modification au premier déchiffrement.

Second tableau, plus inquiétant : le même disque, volé avec trois fragments obtenus par ailleurs. La hiérarchie se déroule alors intégralement, et le snapshot devient un Vault portable. C'est la démonstration cryptographique de la règle de séparation posée au chapitre 5.

Sécurité : ce que la cryptographie impose¶

La crypto maison est interdite. Le nonce de GCM l'a montré : un usage défaillant ruine un algorithme parfait. On consomme des constructions complètes via des interfaces qui ne permettent pas l'erreur. C'est l'argument de fond du moteur Transit : offrir le chiffrement sans confier ni les clés ni les choix dangereux.

Les clés côté client sont des points d'exfiltration. Tout le chapitre 1 s'applique aux clés comme aux mots de passe. Le motif d'enveloppe permet de ne jamais livrer la KEK.

L'empreinte déterministe est une fonctionnalité et une surface. Elle rend le journal interrogeable ; elle rend aussi observable qu'une même valeur a été utilisée deux fois. Le cloisonnement par sel limite la portée de cette observation.

Le renouvellement se conçoit par étage. Savoir quel étage on renouvelle, et ce que cela laisse intact, est la condition pour qu'une opération de sécurité produise l'effet annoncé plutôt qu'un faux sentiment.

Erreurs fréquentes¶

Confondre rotate et rekey. Lancer un rekey là où une rotation suffisait coûte une mobilisation inutile ; croire qu'un rotate a changé les clés après le départ d'un détenteur laisse ce dernier avec un fragment valide.

Croire qu'un rekey périme les vieilles sauvegardes. Il invalide les anciens fragments sur le cluster vivant ; l'ancien snapshot s'ouvre toujours avec eux. Détruire les couples anciens est un acte séparé, à registre.

Confondre encodage et chiffrement. Le base64 se décode sans clé, et cette confusion revient à chaque chapitre.

Traiter le hachage comme un chiffrement réversible. Une empreinte ne se déchiffre pas, elle se compare ou se recalcule.

Négliger l'unicité du nonce en implémentant soi-même. L'erreur est invisible et fatale.

Croire que TLS dispense de la barrière, ou l'inverse. Deux frontières, deux mécanismes, aucune substitution.

Oublier que les clés des moteurs sont des données. Les clés Transit et les autorités PKI sont protégées par la barrière comme le reste, et leur gestion propre s'ajoute à cet édifice sans le remplacer.

Mise en pratique : voir la différence¶

Réponses commentées en fin de partie.

[Démonstration] Sur votre machine, sans Vault, faire exister la différence entre empreinte, empreinte à clé et encodage.

# Empreinte SHA-256 : deterministe, sans cle. Quiconque peut la recalculer.
# -n : ne pas ajouter de saut de ligne (il changerait l'empreinte du tout au tout)
echo -n 'hvs.EXEMPLE-DE-TOKEN' | openssl dgst -sha256

# HMAC-SHA256 : la meme valeur, deux cles (sels) differentes,
# deux empreintes sans rapport -- le cloisonnement par device de l'audit
echo -n 'hvs.EXEMPLE-DE-TOKEN' | openssl dgst -sha256 -hmac 'sel-du-device-fichier'
echo -n 'hvs.EXEMPLE-DE-TOKEN' | openssl dgst -sha256 -hmac 'sel-du-device-syslog'

# base64 : un encodage. Pas de cle, reversible par n'importe qui, toujours.
echo 'bW90LWRlLXBhc3NlLWVuLWNsYWly' | base64 -d

Sur papier, pour chacune des six situations, décidez : operator rotate, operator rekey, ou ni l'un ni l'autre, en justifiant par l'étage concerné.

a) Un des cinq détenteurs de fragments quitte l'entreprise la semaine prochaine. b) La politique exige que la clé chiffrant les nouvelles écritures change tous les quatre-vingt-dix jours, sans mobiliser personne. c) Une photographie des fragments, prise lors de la cérémonie d'initialisation, a peut-être circulé. d) L'organisation veut passer de cinq fragments avec seuil trois à sept fragments avec seuil quatre. e) Un auditeur demande la preuve que la clé de chiffrement du stockage est renouvelée régulièrement. f) La direction exige que les sauvegardes antérieures à l'an dernier deviennent définitivement inexploitables.

Sur papier, redessinez la hiérarchie de la section 6.7 et annotez chaque maillon avec l'opération qui le renouvelle.

Questions de compréhension¶

Qu'ajoute le chiffrement authentifié au chiffrement seul, et pourquoi est-ce indispensable à la barrière ?
Quel est le rôle du nonce, que provoque sa réutilisation, et qui le gère dans Vault ?
Encodage, hachage, HMAC, chiffrement : définition en une phrase et usage rencontré dans ce cours.
Pourquoi l'audit emploie-t-il un HMAC salé par dispositif plutôt qu'une empreinte nue ? Donnez les deux raisons.
Décrivez le motif DEK et KEK, ses deux bénéfices, et où il se répète dans la conception de Vault.
Déroulez ce que fait operator rotate : écritures nouvelles, données existantes, fragments, disponibilité.
Déroulez ce que fait operator rekey, et ce qu'il exige.
Pourquoi ni l'un ni l'autre ne périme les copies passées, et que faut-il faire à la place ?
Restituez la hiérarchie des clés et dites où se déplace la racine selon les trois mécanismes de scellement.

Synthèse¶

La cryptographie de Vault repose sur une règle et un édifice. La règle : on ne casse pas les algorithmes, on trouve les clés, d'où une conception tournée vers la garde, le cloisonnement et le renouvellement. L'édifice : des enveloppes emboîtées. Les données sous AES-256-GCM, chiffré et authentifié, nonces gérés en interne. Les clés versionnées dans le keyring, que rotate renouvelle en ligne par re-chiffrement paresseux. Le keyring sous la clé racine, jamais stockée en clair. La clé racine sous le mécanisme de scellement, racine de confiance dont le choix est l'affaire de la partie VII. rekey opère à l'étage racine sous quorum, rotate à l'étage du keyring en ligne, et aucun des deux ne périme les copies passées.