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éé 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.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.