Ce soir j’ai joué avec les SED sous Linux. Ce fut laborieux et la documentation est assez rare alors je pose ça ici si jamais ça sert à quelqu’un d’autre.
Chiffrer ses données
Sur mon NAS j’ai des données que je ne veux pas perdre, mais aussi des données que je ne veux pas voir fuiter n’importe où en cas de cambriolage.
Jusqu’à présent j’avais une partition principale en clair pour le système d’exploitation, et une partition chiffrée via LUKS pour les données.
Avantage : Ça fonctionne et je peux monter ma partition à distance pour peu que le NAS ait redémarré suite à un incident électrique.
Désavantage : Parfois le système démarre mais n’a pas ses données. Il faut que je pense à redémarrer certains services (oui, ça aurait pu être ajouté dans un script, je ne l’ai simplement pas fait).
J’ai aussi la désagréable impression que les copies se trainent comme il y a 20 ans alors que le disque est rapide. Il faut dire que j’ai un ancien Celeron J très faiblard et on a beau me dire que le chiffrement ne consomme quasiment rien, mes explorations me laissent penser le contraire.
Les SED
Les SED sont les self encrypting drives. Quasiment tous les SSD modernes sont des SED OPAL.
Le firmware d’un SED sait chiffrer et déchiffer toutes les données à la volée. Il suffit d’initialiser le disque à l’aide d’une pass-phrase. Lui va aller déchiffrer une clef AES 256 bits à l’aide de cette pass-phrase, et ensuite l’utiliser pour chiffrer ou déchiffrer toutes les entrées sorties.
C’est totalement transparent pour l’OS et ça ne consomme aucun CPU. C’est même tellement transparent qu’il le fait même si vous ne lui demandez pas. « Chiffrement désactivé » revient en fait à chiffrer et déchiffrer avec une clef AES stockée en clair, mais on chiffre et déchiffre quand même toutes les données qui transitent (gros avantage : On peut activer le chiffrement à la volée quand on le souhaite sans avoir à toucher les données : Il suffit de chiffrer la clef AES qui était auparavant en clair).
Pour chiffrer le disque d’amorçage il y a une astuce. Le disque a en fait une zone d’amorçage cachée où on charge une image dite PBA (pre-boot authorization). Quand le disque est verrouillé, c’est cette zone qui est vue par la machine et qui est donc amorcée. L’image demande la pass-phrase, initialise la clef AES, désactive la fausse zone d’amorçage et relance la machine comme si de rien n’était. Là aussi c’est totalement transparent, l’OS n’y voit que du feu et a l’impression de travailler avec un disque standard, amorçage inclus.
Sécurité
Les SED ont très mauvaise réputation depuis qu’une étude de sécurité a trouvé que de nombreux constructeurs ont implémenté tout ça avec les pieds (genre : la clef AES n’est pas chiffrée et en manipulant un peu le firmware on peut y avoir accès).
Certains en tirent « il ne faut pas se reposer sur les SED » mais c’est un peu plus complexe que ça. Le standard OPAL 2 est tout à fait solide d’un point de vue théorique. Il fonctionne d’ailleurs de manière très similaire à ce que fait LUKS sous Linux. Il faut juste que ce soit implémenté avec sérieux.
Il se trouve que, justement, la même étude dit que les Samsung EVO récents ont une implémentation sérieuse. C’est ce que j’ai choisi, ça me va tout à fait.
Il reste des attaques possibles, mais rien lié à mon modèle de menace (un simple cambriolage par des gens venus piquer le matériel informatique pour le revendre). La NSA, elle, trouvera de toutes façons moyen d’accéder à mes données que j’utilise LUKS ou un SED.
Configurer un SED
Je n’ai trouvé que deux documentations utiles, celle de ArchLinux et celle de l’utilitaire sedutils. On part d’une installation OS existante, on peut activer le chiffrement après coup.
Activer libata.allow_tpm
Première étape, pour jouer il faudra activer libata.allow_tpm. Sur Debian la seule manière qui m’a semblé fonctionnelle est d’éditer /etc/default/grub et d’ajouter « libata.allow_tpm=1 » à la variable d’environnement GRUB_CMDLINE_LINUX_DEFAULT puis exécuter update-grub2 et relancer la machine.
Installer sedutils
Je n’ai pas trouvé de paquet Debian. J’ai téléchargé la distribution binaire Linux à partir du site officiel et ai copié sedutils-cli dans /usr/local/sbin. Vous aurez besoin qu’il soit dans le PATH plus tard.
Préparer une image PBA
Les documentations proposent de récupérer une image officielle. Chez moi ça n’a pas fonctionné. Le disque est bien déverrouillé mais ensuite la machine ne savait plus identifier l’UEFI du disque pour lancer Linux.
J’ai du créer ma propre image. C’est de toutes façons ce que je vous recommande parce que les images officielles ne gèrent que les claviers US.
Après avoir installé les paquets binutils, net-tools et console-data, télécharger le projet rear puis suivre ce commentaire :
sudo apt install -y binutils net-tools console-data
# aller à la racine du projet
cd rear
echo "OUTPUT=RAWDISK" > ./etc/rear/site.conf
sudo ./usr/sbin/rear -v mkopalpba
# l'image est dans ./var/lib/rear/TCG-OPAL-PBA/*/*.raw
Préparer une clef USB de récupération
Je suis comme tout le monde, j’avais sauté cette étape initialement mais elle vous sera indispensable pour retrouver l’utilitaire sedutils et pouvoir réinitialiser le disque en cas de problème (l’image d’installation de Debian non seulement n’a pas sedutils mais ne lance de toutes façons pas son kernel avec libata.allow_tpm, donc vous ne pourrez rien en faire).
Là vous pouvez prendre l’image rescue 64 bits officielle et initialiser une petite clef USB au cas où.
gunzip RESCUE64.img.gz
# /dev/sdb est ma clef USB
dd if=RESCUE64.img.gz of=/dev/sdb
En cas de difficulté ça permet de désactiver le chiffrement, voire de réinitialiser un nouveau mot de passe si rien d’autre ne fonctionne (si la désactivation se fait sans perte de données, la réinitialisation vous fait repartir avec un disque totalement vierge).
# Désactiver le chiffrement
# Remplacer passphrase par votre passphrase et /dev/sda par votre disque
sudo sedutil-cli --disableLockingRange 0 passphrase /dev/sda
sedutil-cli --setMBREnable off passphrase /dev/sda
Configurer le disque
Désormais on peut suivre la procédure standard, en utilisant l’image PBA obtenue plus haut :
# Confirmer que le disque est utilisable
sudo sedutil-cli --scan
# Remplacer passphrase par votre passphrase et /dev/sda par votre disque
sudo sedutil-cli --initialsetup passphrase /dev/sda
sudo sedutil-cli --loadPBAimage passphrase imagePBA.raw /dev/sda
sudo sedutil-cli --setMBREnable on passphrase /dev/sda
sudo sedutil-cli --enableLockingRange 0 passphrase /dev/sda
Éteindre et rallumer la machine (pas juste redémarrer) devrait suffire à vous demander la passphrase. Une fois celle-ci saisie, la machine redémarre encore. Oui c’est long mais c’est normal.
Chez moi on me demande deux fois la passphrase et j’ai donc deux reboot au lieu d’un seul. C’est très long, agaçant. Si quelqu’un voit quel peut être le problème, ça m’intéresse. Entre temps je fais avec : Je ne devrais pas redémarrer tous les quatre matins.
