Self Encryp­ting Disk

Ce soir j’ai joué avec les SED sous Linux. Ce fut labo­rieux et la docu­men­ta­tion est assez rare alors je pose ça ici si jamais ça sert à quelqu’un d’autre.

Chif­frer 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’im­porte où en cas de cambrio­lage.

Jusqu’à présent j’avais une parti­tion prin­ci­pale en clair pour le système d’ex­ploi­ta­tion, et une parti­tion chif­frée via LUKS pour les données.

Avan­tage : Ça fonc­tionne et je peux monter ma parti­tion à distance pour peu que le NAS ait redé­marré suite à un inci­dent élec­trique.

Désa­van­tage : Parfois le système démarre mais n’a pas ses données. Il faut que je pense à redé­mar­rer certains services (oui, ça aurait pu être ajouté dans un script, je ne l’ai simple­ment pas fait).

J’ai aussi la désa­gréable impres­sion 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 Cele­ron J très faiblard et on a beau me dire que le chif­fre­ment ne consomme quasi­ment rien, mes explo­ra­tions me laissent penser le contraire.

Les SED

Les SED sont les self encryp­ting drives. Quasi­ment tous les SSD modernes sont des SED OPAL.

Le firm­ware d’un SED sait chif­frer et déchif­fer toutes les données à la volée. Il suffit d’ini­tia­li­ser le disque à l’aide d’une pass-phrase. Lui va aller déchif­frer une clef AES 256 bits à l’aide de cette pass-phrase, et ensuite l’uti­li­ser pour chif­frer ou déchif­frer toutes les entrées sorties.

C’est tota­le­ment trans­pa­rent pour l’OS et ça ne consomme aucun CPU. C’est même telle­ment trans­pa­rent qu’il le fait même si vous ne lui deman­dez pas. « Chif­fre­ment désac­tivé » revient en fait à chif­frer et déchif­frer avec une clef AES stockée en clair, mais on chiffre et déchiffre quand même toutes les données qui tran­sitent (gros avan­tage : On peut acti­ver le chif­fre­ment à la volée quand on le souhaite sans avoir à toucher les données : Il suffit de chif­frer la clef AES qui était aupa­ra­vant en clair).

Pour chif­frer 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 autho­ri­za­tion). Quand le disque est verrouillé, c’est cette zone qui est vue par la machine et qui est donc amor­cée. L’image demande la pass-phrase, initia­lise la clef AES, désac­tive la fausse zone d’amorçage et relance la machine comme si de rien n’était. Là aussi c’est tota­le­ment trans­pa­rent, l’OS n’y voit que du feu et a l’im­pres­sion de travailler avec un disque stan­dard, amorçage inclus.

Sécu­rité

Les SED ont très mauvaise répu­ta­tion depuis qu’une étude de sécu­rité a trouvé que de nombreux construc­teurs ont implé­menté tout ça avec les pieds (genre : la clef AES n’est pas chif­frée et en mani­pu­lant un peu le firm­ware on peut y avoir accès).

Certains en tirent « il ne faut pas se repo­ser sur les SED » mais c’est un peu plus complexe que ça. Le stan­dard OPAL 2 est tout à fait solide d’un point de vue théo­rique. Il fonc­tionne d’ailleurs de manière très simi­laire à ce que fait LUKS sous Linux. Il faut juste que ce soit implé­menté avec sérieux.

Il se trouve que, juste­ment, la même étude dit que les Samsung EVO récents ont une implé­men­ta­tion 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 cambrio­lage par des gens venus piquer le maté­riel infor­ma­tique pour le revendre). La NSA, elle, trou­vera de toutes façons moyen d’ac­cé­der à mes données que j’uti­lise LUKS ou un SED.

Confi­gu­rer un SED

Je n’ai trouvé que deux docu­men­ta­tions utiles, celle de ArchLi­nux et celle de l’uti­li­taire sedu­tils. On part d’une instal­la­tion OS exis­tante, on peut acti­ver le chif­fre­ment après coup.

Acti­ver libata.allow_tpm

Première étape, pour jouer il faudra acti­ver libata.allow_tpm. Sur Debian la seule manière qui m’a semblé fonc­tion­nelle est d’édi­ter /etc/default/grub et d’ajou­ter « libata.allow_tpm=1 » à la variable d’en­vi­ron­ne­ment GRUB_CMDLINE_LINUX_DEFAULT puis exécu­ter update-grub2 et relan­cer la machine.

Instal­ler sedu­tils

Je n’ai pas trouvé de paquet Debian. J’ai télé­chargé la distri­bu­tion binaire Linux à partir du site offi­ciel et ai copié sedu­tils-cli dans /usr/local/sbin. Vous aurez besoin qu’il soit dans le PATH plus tard.

Prépa­rer une image PBA

Les docu­men­ta­tions proposent de récu­pé­rer une image offi­cielle. Chez moi ça n’a pas fonc­tionné. Le disque est bien déver­rouillé mais ensuite la machine ne savait plus iden­ti­fier 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 recom­mande parce que les images offi­cielles ne gèrent que les claviers US.

Après avoir installé les paquets binu­tils, net-tools et console-data, télé­char­ger le projet rear puis suivre ce commen­taire :

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épa­rer une clef USB de récu­pé­ra­tion

Je suis comme tout le monde, j’avais sauté cette étape initia­le­ment mais elle vous sera indis­pen­sable pour retrou­ver l’uti­li­taire sedu­tils et pouvoir réini­tia­li­ser le disque en cas de problème (l’image d’ins­tal­la­tion de Debian non seule­ment n’a pas sedu­tils mais ne lance de toutes façons pas son kernel avec libata.allow_tpm, donc vous ne pour­rez rien en faire).

Là vous pouvez prendre l’image rescue 64 bits offi­cielle et initia­li­ser 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 diffi­culté ça permet de désac­ti­ver le chif­fre­ment, voire de réini­tia­li­ser un nouveau mot de passe si rien d’autre ne fonc­tionne (si la désac­ti­va­tion se fait sans perte de données, la réini­tia­li­sa­tion vous fait repar­tir avec un disque tota­le­ment 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

Confi­gu­rer le disque

Désor­mais on peut suivre la procé­dure stan­dard, en utili­sant l’image PBA obte­nue 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 rallu­mer la machine (pas juste redé­mar­rer) devrait suffire à vous deman­der la pass­phrase. 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 pass­phrase 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’in­té­resse. Entre temps je fais avec : Je ne devrais pas redé­mar­rer tous les quatre matins.