Chiffrer un disque VPS avec LUKS

Le chiffrement n’est pas un réglage de confidentialité universel. Il répond à une seule question : quelqu’un peut-il lire ces blocs sans la clé ? Tout le reste — qui sait que vous avez loué ce serveur, si le trafic vous est attribuable, si un tribunal peut contraindre quoi que ce soit — relève d’autre chose.

Sur un VPS, LUKS défend réellement contre :

• Le matériel retiré du service ou défaillant. Les disques NVMe sont remplacés. L’effacement sécurisé d’un disque défaillant n’est pas toujours possible — parfois l’appareil est mort au point que le contrôleur n’accepte plus aucune commande, et il quitte quand même la baie.
• Une image hors ligne. Un volume copié pendant que le serveur est éteint — lors d’une saisie, d’une migration, d’une erreur — est du texte chiffré et le reste.
• Les sauvegardes et instantanés qui voyagent. Tout ce qui quitte la machine part chiffré si c’est extrait de la couche bloc en dessous de votre contrôle, et devrait être chiffré côté client si c’est extrait au-dessus.
• Les blocs résiduels. Quand vous détruisez un serveur, les extents sous-jacents finissent par être réutilisés. Le chiffrement transforme ce qui reste en bruit plutôt qu’en données.

Il ne défend pas contre une machine en fonctionnement. Tant que votre serveur tourne, la clé maîtresse réside en mémoire noyau, et quiconque peut extraire cette mémoire lit votre disque quelle que soit la phrase de passe. Sur une infrastructure louée, cela désigne l’opérateur de l’hyperviseur. Nous le disons dans notre politique de confidentialité et nous le répétons ici : aucune fonctionnalité de chiffrement de disque, chez aucun hébergeur, y compris chez nous, n’y change quoi que ce soit — et tout hébergeur prétendant le contraire fait du marketing, pas de la cryptographie.

Avant de toucher à un terminal, choisissez le modèle. Ils diffèrent énormément en effort, et la plupart des gens ont besoin du premier.

1. Un volume de données chiffré. Le système démarre normalement, non chiffré ; une seule arborescence — un maildir, une base de données, une archive — vit dans un conteneur LUKS que vous ouvrez à la main après chaque démarrage. Dix minutes de travail, pas de mode rescue, aucun risque de vous verrouiller dehors. Si ce qui compte pour vous est un jeu de données plutôt que la machine entière, arrêtez-vous là ; vous obtenez l’essentiel du bénéfice pour presque aucune fragilité. C’est le schéma que nous recommandons sur la page serveur mail anonyme.

2. Un volume racine chiffré avec déverrouillage à distance. Tout sauf /boot est chiffré, et chaque démarrage marque une pause dans l’initramfs jusqu’à ce que vous vous connectiez en SSH et fournissiez la phrase de passe. C’est le modèle que construit le reste de ce guide. Cela coûte une heure la première fois puis une commande SSH par redémarrage, et c’est le seul modèle où les journaux, les caches de paquets, l’historique du shell et le swap sont couverts eux aussi — les endroits où les données fuient sans que personne ne l’ait décidé.

3. Une racine chiffrée qui se déverrouille elle-même auprès d’un serveur de clés que vous contrôlez. Comme le modèle 2, mais Clevis récupère le matériel de déverrouillage auprès d’un serveur Tang situé sur une machine dans une autre juridiction, si bien que les redémarrages se font sans surveillance. Le compromis est précis et mérite d’être compris : le serveur peut désormais se déchiffrer lui-même tant que votre serveur de clés dit oui, ce qui signifie que vous avez déplacé le secret plutôt que de le supprimer — mais vous avez aussi gagné un interrupteur d’arrêt à distance. Traité plus loin.

Beaucoup d’hébergeurs annoncent le « chiffrement au repos » comme une simple case à cocher. Il vaut la peine de préciser ce que cette expression signifie en général, car deux choses très différentes se cachent derrière.

Un chiffrement dont l’hébergeur détient la clé protège contre le vol d’un disque et rien d’autre. Si l’hébergeur peut démarrer votre serveur sans vous demander quoi que ce soit, il peut aussi le déchiffrer sans vous demander quoi que ce soit — et quiconque peut contraindre l’hébergeur le peut également. C’est une protection réelle contre le vol et purement décorative face à une procédure judiciaire.

Un chiffrement dont vous détenez la clé est la version qui compte, et elle rend le redémarrage sans surveillance impossible par construction. Ce n’est pas un défaut à corriger ; c’est la propriété qui fait le travail.

Nous ne proposons que la seconde option, non configurée, et vous laissons décider. Ce que nous détenons de notre côté est plus restreint et documenté : les mots de passe root des serveurs sont stockés chiffrés en AES-256-CBC au niveau de la ligne, nous ne conservons aucun journal de flux ni capture de paquets, et un warrant canary signé est publié selon un calendrier fixe. Rien de tout cela ne remplace votre propre clé — c’est simplement ce dont nous répondons en attendant.

Les valeurs par défaut sont bonnes. Deux d’entre elles méritent d’être modifiées.

Chiffrement. aes-xts-plain64 avec une clé de 512 bits est la valeur par défaut et la bonne réponse — les 512 bits correspondent à deux clés de 256 bits, donc il s’agit bien d’AES-256 en mode XTS, et chaque CPU que nous exploitons dispose d’AES-NI. Sur une machine sans accélération AES, vous préféreriez xchacha20,aes-adiantum-plain64, mais ce n’est pas notre matériel, et probablement pas le vôtre non plus.

Dérivation de clé. LUKS2 utilise par défaut Argon2id, qui est volontairement gourmand en mémoire. cryptsetup teste les capacités de votre machine au moment du formatage et choisit un coût mémoire à partir de la RAM qu’il détecte — et voici le piège à l’origine de la plupart des rapports du type « mon serveur chiffré ne démarre plus » : l’initramfs dispose de moins de mémoire utilisable que le système une fois démarré, et si vous avez formaté le volume dans un environnement rescue disposant de plus de RAM que le plan cible, le déverrouillage peut échouer ou être tué au démarrage. Fixez la valeur explicitement. 1 GiB de mémoire Argon2 représente un coût sérieux pour un attaquant, et reste confortablement à la portée d’un S1 disposant de 4 Go :

cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 --hash sha256 \
  --pbkdf argon2id --pbkdf-memory 1048576 --pbkdf-parallel 4 \
  /dev/vda2

--pbkdf-memory s’exprime en KiB, donc 1048576 correspond à 1 GiB. Vérifiez ensuite ce qui a réellement été inscrit dans l’en-tête avec cryptsetup luksDump /dev/vda2 — la section de l’emplacement de clé affiche la mémoire et le nombre d’itérations qui seront utilisés, et une lecture rapide coûte bien moins cher qu’un démarrage raté.

La phrase de passe. Argon2 fait gagner du temps face à une phrase de passe faible ; il n’en rattrape pas une. Utilisez une phrase diceware d’au moins six mots. C’est le seul secret du système, et aucune fonction de dérivation de clé ne compense une phrase de passe médiocre.

Un démarrage Linux avec une racine chiffrée pose un problème de l’œuf et de la poule : le noyau et l’initramfs doivent se charger avant que quoi que ce soit puisse demander une phrase de passe, et ils résident sur le disque que vous essayez justement de déverrouiller. La réponse standard est une petite partition /boot non chiffrée contenant le noyau, l’initramfs et le chargeur de démarrage. Tout le reste va dans LUKS.

L’initramfs marque alors une pause et demande la phrase de passe. Sur un ordinateur portable, vous la tapez. Sur un serveur situé à trois mille kilomètres, il vous faut l’une de ces deux choses :

• La console. Chaque serveur de votre tableau de bord dispose d’une console noVNC, et elle fonctionne — mais les frappes clavier traversent notre infrastructure, ce qui est précisément la partie que votre clé est censée exclure. Très bien pour une récupération ponctuelle, à éviter en routine.
• Un serveur SSH dans l’initramfs. dropbear-initramfs pèse environ 200 Ko, active le réseau, écoute sur un port de votre choix, accepte l’une de vos clés publiques, et vous dépose directement sur l’invite de déverrouillage. La phrase de passe est chiffrée de bout en bout depuis votre ordinateur portable jusqu’à l’initramfs. C’est la bonne réponse.

Deux détails piègent souvent les gens. Le Dropbear de l’initramfs a sa propre clé d’hôte, donc son empreinte diffère de celle de votre démon SSH habituel — c’est normal, ce n’est pas une attaque de l’homme du milieu, et cela mérite son propre fichier known_hosts plutôt que l’habitude de taper yes. Et le nom de l’interface doit être le bon : les cartes réseau virtio sous Debian 13 apparaissent en général comme ens3 ou enp1s0, pas eth0. Vérifiez avec ip -br link avant d’écrire la configuration, car se tromper signifie un initramfs sans réseau et un aller-retour par la console.

Si la machine doit revenir seule — après une mise à jour du noyau, un redémarrage de l’hôte, une coupure de courant — taper une phrase de passe n’est pas viable. Clevis lie un emplacement de clé LUKS à une politique externe, et Tang est un minuscule serveur d’échange de clés qui met en œuvre la plus simple des politiques utiles.

# on a small server you control, elsewhere
apt install -y tang
systemctl enable --now tangd.socket

# on the encrypted VPS
apt install -y clevis clevis-luks clevis-initramfs
clevis luks bind -d /dev/vda2 tang '{"url":"http://tang.internal:7500"}'
update-initramfs -u -k all

Au démarrage, l’initramfs effectue un échange McCallum-Relyea avec Tang et récupère la clé sans que le serveur Tang ne l’apprenne jamais ni ne voie la phrase de passe. Ces propriétés méritent d’être énoncées précisément :

• Le VPS se déchiffre lui-même uniquement tant qu’il peut joindre Tang. Coupez Tang, ou faites tourner ses clés, et le démarrage suivant s’arrête net. C’est un véritable interrupteur d’arrêt à distance — inhabituel et utile.
• Tang ne doit pas être exposé sur l’internet public. Passez par WireGuard ou par un service onion Tor ; nous couvrons le tunnel dans le guide WireGuard.
• Placez Tang dans une juridiction différente de celle des données. Nos pages sur les juridictions existent précisément pour ce genre de séparation.
• Conservez une phrase de passe dans un autre emplacement de clé. Clevis est une couche de confort, pas votre seul moyen d’entrer.

Comprenez bien ce que vous avez construit : une machine sans surveillance détient sa propre clé par procuration, si bien qu’un adversaire qui saisit le VPS pendant qu’il tourne, ou qui peut joindre votre serveur Tang, obtient les données. C’est un réel affaiblissement comparé à une phrase de passe gardée dans votre tête. Choisissez cette option quand la disponibilité compte plus que le dernier degré de secret, pas par défaut.

Une racine chiffrée couvre l’essentiel de la surface, mais quelques chemins écrivent en dehors ou lui survivent.

• Le swap. Tout ce qui est en RAM peut être paginé sur disque — clés, corps de messages, tampons déchiffrés. Si le swap réside dans le volume chiffré sous forme de swapfile, il est couvert. Une partition de swap séparée ne l’est pas, sauf si vous l’ajoutez à /etc/crypttab avec une clé aléatoire qui change à chaque démarrage : cryptswap /dev/vda3 /dev/urandom swap,cipher=aes-xts-plain64,size=256. Sur un VPS, le swapfile est plus simple et rien ne justifie de préférer la partition.
• /tmp. Montez-le en tmpfs (tmpfs /tmp tmpfs defaults,nosuid,nodev,size=512M 0 0) pour qu’il ne touche jamais le disque. Plus rapide, en prime.
• L’hibernation. Elle écrit toute la RAM, y compris votre clé maîtresse, sur le périphérique de swap. Ne l’activez pas. Elle est désactivée par défaut sur nos images.
• Le /boot non chiffré. Les noyaux, les images d’initramfs et la configuration de GRUB sont lisibles et, plus grave, modifiables par quiconque a un accès hors ligne au disque. LUKS vous donne la confidentialité, pas l’intégrité du démarrage. Si votre modèle de menace inclut quelqu’un qui altère le chargeur de démarrage, le chiffrement seul ne le détectera pas — enregistrez les empreintes de /boot après chaque mise à jour du noyau et vérifiez-les depuis l’extérieur, ou acceptez cette lacune en connaissance de cause.
• Les instantanés existants et les anciens volumes. Chiffrer aujourd’hui ne fait rien pour une image prise hier. Si le serveur a déjà tourné sans chiffrement avec des données qui comptent pour vous, considérez ces données comme exposées et faites tourner tout ce qui en dérive.

La surcharge est assez faible pour ne pas dicter la décision, mais elle n’est pas nulle. Mesurez avant de spéculer :

cryptsetup benchmark

Sur nos nœuds EPYC, aes-xts avec une clé de 512 bits se situe, au benchmark, dans les quelques gigaoctets par seconde et par cœur — largement au-dessus de ce qu’un seul volume NVMe exigera. Le coût qui se manifeste réellement porte sur la latence et le CPU lors de petites écritures aléatoires, pas sur le débit.

Deux options de LUKS2 comptent sur NVMe, là où les files d’attente de travail de dm-crypt dans le noyau ajoutent de la latence au lieu d’en retirer. Activez-les et rendez-les persistantes dans l’en-tête :

cryptsetup refresh cryptroot \
  --perf-no_read_workqueue --perf-no_write_workqueue --persistent

La troisième option, --allow-discards, transmet le TRIM au périphérique sous-jacent. Elle limite l’amplification d’écriture sur la durée de vie du volume, au prix de révéler quels blocs sont inutilisés — ce qui laisse fuir la taille et la forme approximatives de vos données à quiconque lit le périphérique brut. Activez-la pour un serveur généraliste ; laissez-la désactivée si le fait qu’un volume soit rempli à 3 % est en soi sensible. Il n’existe pas de réponse universellement juste, seulement une décision que vous devez prendre consciemment.

L’en-tête LUKS fait environ 16 Mo en tête de la partition, et il contient les copies chiffrées de la clé maîtresse. Endommagez-le — un dd mal tapé, un outil de partitionnement qui réécrit gentiment le début du périphérique — et tout ce qui se trouve derrière disparaît. Il n’existe aucun service de récupération. Nous n’en avons pas de copie.

# back it up, off the server, before you put data on the volume
cryptsetup luksHeaderBackup /dev/vda2 \
  --header-backup-file luks-header-$(date +%F).img

# add a second passphrase while you still have the first
cryptsetup luksAddKey /dev/vda2

# see what is in the header
cryptsetup luksDump /dev/vda2

Deux choses à savoir sur cette sauvegarde. Elle est aussi sensible que le disque : elle contient les emplacements de clé, si bien qu’un ancien en-tête restauré après un changement de phrase de passe acceptera avec plaisir l’ancienne. Conservez-la comme vous conservez la phrase de passe, et détruisez les copies périmées à chaque rotation. Ensuite, LUKS2 vous offre 32 emplacements de clé — utilisez-en au moins deux, le second étant une longue phrase de passe aléatoire conservée ailleurs que votre phrase de passe quotidienne. La panne que cela évite est banale et fréquente : vous faites tourner la phrase de passe, vous la tapez deux fois de façon identique mais erronée, et vous ne le découvrez qu’au redémarrage suivant plutôt qu’à la prochaine connexion.

Ayez aussi un moyen de rentrer. Le mode rescue démarre le serveur depuis notre ISO avec vos clés SSH injectées et le volume chiffré intact, ce qui veut dire que vous pouvez faire cryptsetup open /dev/vda2 rescue && mount /dev/mapper/rescue /mnt et réparer un crypttab cassé ou un mauvais initramfs sans perdre les données. Testez cela une fois, délibérément, pendant que tout va bien.

La chose la plus utile qu’un guide comme celui-ci puisse faire, c’est de tracer ses propres limites.

• Il ne protège pas un serveur en fonctionnement. La clé maîtresse reste en mémoire noyau du déverrouillage jusqu’à l’arrêt. Un accès mémoire au niveau de l’hyperviseur le met en échec. Le chiffrement de la mémoire — AMD SEV-SNP et équivalents — est la seule technologie qui change réellement la donne, et nous ne la proposons pas aujourd’hui ; un hébergeur qui prétend que votre VM en fonctionnement lui est opaque, sans SEV, se trompe ou ment.
• Il ne vous rend pas anonyme. Un disque chiffré à Zürich a quand même une IP, une trace de facturation et une session SSH qui a bien démarré quelque part. C’est un problème différent, et nous avons détaillé les façons dont cela tourne mal dans les erreurs qui vous déanonymisent.
• Il ne change rien à ce qu’un tribunal peut ordonner. La juridiction régit la contrainte ; le chiffrement régit la lisibilité. Dans certaines juridictions, vous pouvez être personnellement sommé de divulguer une phrase de passe. Notre guide sur les procédures judiciaires couvre ce que nous appliquons et ce que nous n’appliquons pas.
• Il ne survit pas à une phrase de passe perdue. C’est voulu, et cela mérite d’être répété, car le ticket de support nous demandant de l’aide arrive environ une fois par mois, et la réponse est toujours la même.
• Il n’authentifie pas la chaîne de démarrage. La confidentialité n’est pas l’intégrité. /boot est lisible et modifiable hors ligne.

Ce qu’il fait vraiment, c’est supprimer toute une classe d’exposition — tout ce qui arrive à un disque quand il ne tourne pas, ce qui représente l’essentiel de ce qui arrive aux disques. Cela vaut bien une heure. Combinez-le avec une inscription no-KYC, un paiement en Monero et une juridiction choisie exprès, et chaque couche couvre une défaillance différente. Aucune ne les couvre toutes.