Il y a plusieurs choses qui peuvent être améliorées dans le système bootable chiffré sur deux clés USB interdépendantes.

C’est un peu technique et aucune solution complète n’est fournie. Si vous voulez les mettre en place, il va falloir gratter par vous même.

Déception

La clé USB contenant le système, intégralement chiffrée (ou avec une partition VFAT résiduelle éventuelle), est inutilisable en l’état et il apparaît rapidement qu’elle cache quelque chose.

La clé USB contenant la partition boot et la partition des données peut être suspecte si on regarde les différentes partitions présentes. Il convient donc d’offusquer toute partition chiffrée. On peut la faire passer pour une partition SWAP par exemple. On modifie juste son type.

Mais cela ne cache pas le début de la partition reconnu comme une partition chiffrée avec LUKS. On peut utiliser à la place dm-crypt.

Nous avons avec dm-crypt une partition qui peut être suspecte si on regarde le début de celle-ci. Elle est en effet illisible et en plus elle a une très forte entropie dès le premier secteur. On peut dans ce cas la pré-formater avec un système de fichier plus classique comme ext4 (mieux vaut éviter le VFAT) puis créer la ‘fausse’ partition plus loin via cryptsetup et dm-crypt en utilisant le paramètre offset. Évidement, on corrompt la partition en ext4, il faudra empêcher son utilisation par le système.

Les deux clés USB ne doivent jamais voyager ensemble.

La clé de déchiffrement de la partition système, stockée dans la partition boot, peut être facilement volée depuis une machine Linux. Si on suspecte ce cas de compromission de clé, il faut la changer, en générer une nouvelle et remplacer la clé existante dans le container LUKS.

Offuscation de clés

Un des risques est la corruption de certaines données du système accessibles en clair. C’est le cas du chargeur de démarrage GRUB et du noyau Linux qui sont stockés dans la partition boot non protégée. Le but peut être de voler la clé nécessaire au déchiffrement de la partition des données, ou les données elles-mêmes.

Il n’y à pas grand chose à faire pour empêcher le vol des données si ce n’est empêcher toute connexion réseau sur la machine et vérifier scrupuleusement les données exportées via la partition d’échange en VFAT ou la partition de boot.

Pour complexifier la possibilité de vol de la clé de chiffrement, il est possible d’utiliser non pas un fichier de clé bien définit comme /boot.pwd mais un fichier perdu dans le système. Ce fichier ne doit pas être généré par l’installation du système sinon il est facilement reproductible. Ce peut être un fichier modifié dans /etc et éventuellement contenant une constante pour augmenter son entropie. Ce peut être une page du man improbable.

Malheureusement, le fichier de mot de passe peut être retrouvé assez simplement. Il est indiqué dans /etc/crypttab.

Pour la clé contenant GRUB et la partition boot, le fichier clé de la partition système peut être un fichier assez banale comme une image JPEG stocké dans /boot/boot.pwd. Pour désactiver la possibilité de démarrage, ce fichier peut être retiré et stocké à un autre endroit plus légitime comme une image au milieu d’une collection de photos de vacances. La collection de photos de vacances peut être sur la clé USB dans la partition VFAT ou sur un des innombrables sites web faisant collection de photos.

Anti-copie

Un des risques est la copie conforme des deux clés USB. Ces clés ne sont réunies que pour être utilisées, elles sont en temps normal séparées et l’une d’entre elle constamment surveillée. Le tout permet de reconstituer le binôme de clés USB et atteindre les données protégées sans alerter le porteur d’un clé parce qu’il n’y a pas vol proprement dit de sa clé USB.

Comment rendre beaucoup plus difficile l’exploitation d’une copie de clé alors que leur contenu est strictement et scrupuleusement recopié?
On peut utiliser pour cela des informations propres à la clé USB, c’est à dire ses méta-données. On retrouve le numéro du constructeur, le numéro du modèle de clé et son numéro de série. Ces informations sont disponibles via la commande lsusb.

Toutes les informations retournées par la commande ne sont pas identiques d’une machine à l’autre. Mais on peut n’en garder qu’un sous-ensemble. Cela permet de générer une valeur unique, infalsifiable et parfaitement reproductible avec, par exemple :

# lsusb -v -d 154b:0048 | grep -A 14 "^Device Descriptor:"
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x154b PNY
  idProduct          0x0048 
  bcdDevice           81.92
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1

# lsusb -v -d 154b:0048 | grep -A 14 "^Device Descriptor:" | sha256sum
b2549024b55fcbeb9e4343406b98253adcfd3c76be0eb9dadb1961b0e0361d3f

Cette dernière ligne de commande renvoie le même résultat avec une clé USB précise pour des machines sous Debian 7.0 et Ubuntu 13.10.

Comme nous avons deux clés USB, nous récupérons deux valeurs que l’on peut simplement mixer avec une clé pré-définie dans un fichier de mot de passe plus classique. Le mot de passe résultant est donc dépendant à la fois d’une valeur secrète mais aussi des deux clés USB et pas de deux autres. On peut protéger la partition des données avec ce mot de passe mais pas la partition système.

Si nous avons une clé de secours pour chaque clé USB, cela fait donc 4 clés USB à connaître, mais surtout 4 combinaisons (et non 6) de mots de passes générés qu’il faut faire reconnaître au niveau du chiffrement de la partition des données. Il vaut mieux aussi dans ce cas utiliser LUKS plutôt que dm-crypt pour la gestion du chiffrement. Cette technique marche aussi avec l’offuscation de clés vu précédemment.

Cette méthode peut cependant être attaqué relativement simplement. Il suffit au moment de la copie d’une clé USB de recopier aussi la sortie de la commande lsusb -v -d 154b:0048. Ensuite, les différentes valeurs peuvent être tranquillement recalculées au chaud pour accéder au contenu de la partition des données.
Dans ce cas, la seule méthode pour réduire ce risque est de prendre en compte l’intégralité du retour de la commande lsusb -v -d 154b:0048 ainsi que des valeurs spécifiques à la machine via par exemple la commande lspci -v | sha256sum. Ainsi la copie de la clé USB doit se faire sur la machine qui les utilises. cela fait que la machine devient en elle-même aussi une clé du système de chiffrement…

Clé USB sur mesure

Celui qui dispose du moyen de concevoir et produire une clé USB peut prévoir d’autres mécanismes d’offuscation et de personnalisation flottants sous condition. On peut ainsi :
– empêcher la copie de l’intégralité d’une des clés USB ;
Рmasquer une partie la cl̩ USB par un banc m̩moire autre ;
– empêcher la récupération du bon numéro de série d’une clé USB.

Mais celui qui dispose de ces moyens peut aussi faire bien d’autres choses intéressantes pour un système de biclé différent… Nous n’avons plus dans ce cas une protection avec du matériel commun dans le commerce.