Publié à l’origine sur Hacking Lord Sutch
Voici un article d’un anarchiste français décrivant comment son ordinateur portable (chiffré) a été saisi après son arrestation, et le matériel de la partition cryptée a depuis été enregistré comme preuve contre lui. Son mot de passe de cryptage était censé être supérieur à 20 caractères et comprenait un mélange de lettres, de chiffres et de caractères spéciaux, donc en l’absence de toute sorte d’échec d’opsec, cela implique que même des mots de passe relativement complexes peuvent maintenant être forcés brutalement, et nous devrions passer à des phrases secrètes encore plus sécurisées.
PS : En réalité, cette histoire de mot de passe décrypté est litigieuse et il y a anguille sous roche. Avec un mot de passe correctement formé et un chiffrement réalisé sur un système correctement mis à jour, il n’y aurait pas assez de la durée de vie de l’univers pour décrypter en brute force. Le plus probable est soit qu’il a utilisé un moyen mnémotechnique et que le chiffrement a été cassé par une méthode stochastique, soit que son système n’était pas à jour. Il ne faut jamais utiliser de moyen mnémotechnique et toujours apprendre les mots de passe par cœur, et il faut faire quotidiennement les mises à jour du système. Cependant, nous avons quand même publié l’article sur la mise à niveau, par principe il faut toujours utiliser le moyen le plus sûr et toujours faire les mises à jour.
Que se passe-t-il ? Voyons ce que LUKS fait en premier lieu. Les données réelles sont généralement chiffrées avec AES, un algorithme de cryptage extrêmement populaire et bien testé. AES n’a pas de faiblesses majeures connues et n’est pas considéré comme pratiquement brutal – du moins, en supposant que vous ayez une clé aléatoire. Malheureusement, il n’est pas vraiment pratique de demander à un utilisateur de saisir 128 bits de binaire à chaque fois qu’il souhaite déverrouiller son lecteur. Une autre approche doit donc être adoptée.
Ceci est géré à l’aide de ce qu’on appelle une « fonction de dérivation de clé », ou KDF. Un KDF est une fonction qui prend une entrée (dans ce cas, le mot de passe de l’utilisateur) et génère une clé. Comme exemple extrêmement simple, pensez à MD5 – il prend une entrée et génère une sortie 128 bits, nous pourrions donc simplement MD5 le mot de passe de l’utilisateur et utiliser la sortie comme clé AES. Bien que cela puisse techniquement être considéré comme un KDF, ce serait extrêmement mauvais ! Les MD5 peuvent être calculés extrêmement rapidement, donc quelqu’un essayant de forcer brutalement une clé de chiffrement de disque pourrait simplement générer le MD5 de chaque mot de passe plausible (probablement sur beaucoup de machines en parallèle, utilisant probablement des GPU) et tester chacun d’eux pour voir s’il déchiffre le lecteur.
(les choses sont en fait légèrement plus compliquées que cela – votre mot de passe est utilisé pour générer une clé qui est ensuite utilisée pour chiffrer et déchiffrer la clé de chiffrement réelle . Ceci est nécessaire pour vous permettre de changer votre mot de passe sans avoir à chiffrer à nouveau le lecteur entier – à la place, vous rechiffrez simplement la clé de chiffrement avec la nouvelle clé dérivée du mot de passe. Cela vous permet également d’avoir plusieurs mots de passe ou mécanismes de déverrouillage par lecteur) Les bons KDF réduisent ce risque en étant ce que l’on appelle techniquement « coûteux ». Plutôt que d’effectuer un simple calcul pour transformer un mot de passe en clé, ils effectuent beaucoupde calculs. Le nombre de calculs effectués est généralement configurable, afin de vous permettre de faire un compromis entre le niveau de sécurité (le nombre de calculs que vous forcerez un attaquant à effectuer lorsqu’il tente de générer une clé à partir d’un mot de passe potentiel) et les performances (le niveau de temps que vous êtes prêt à attendre que votre ordinateur portable génère la clé après avoir tapé votre mot de passe pour qu’il puisse réellement démarrer). Mais, évidemment, ce compromis change avec le temps – les défauts qui avaient du sens il y a 10 ans ne sont pas nécessairement de bons défauts aujourd’hui. Si vous avez configuré votre partition cryptée il y a quelque temps, le nombre de calculs requis peut ne plus être considéré comme à la hauteur.
Et bien, certaines de ces hypothèses sont plutôt mauvaises en premier lieu ! Le simple fait de rendre les choses coûteuses en calcul n’aide pas beaucoup si votre adversaire a la capacité de tester un grand nombre de mots de passe en parallèle. Les GPU sont extrêmement efficaces pour effectuer le type de calculs que les KDF utilisent généralement, de sorte qu’un attaquant peut « juste » obtenir tout un tas de GPU et les lancer sur le problème. Les KDF qui sont coûteux en calcul ne font pas grand-chose pour se protéger contre cela. Cependant, il existe un autre axe de dépense qui peut être pris en compte : la mémoire. Si l’algorithme KDF nécessite une quantité importante de RAM, la mesure dans laquelle il peut être exécuté en parallèle sur un GPU est massivement réduite. Une Geforce 4090 peut avoir 16 384 unités d’exécution, mais si chaque tentative de mot de passe nécessite 1 Go de RAM et que la carte n’a que 24 Go à bord,
Ainsi, à l’heure où les attaquants ont accès à une pile de GPU, un KDF purement coûteux en calcul n’est tout simplement pas un bon choix. Et, malheureusement, le sujet de cette histoire en utilisait presque certainement un. Ubuntu 18.04 utilisait le format d’en-tête LUKS1 et le seul KDF pris en charge dans ce format est PBKDF2 . Ce n’est pas un KDF coûteux en mémoire, et il est donc vulnérable aux attaques basées sur le GPU. Mais même ainsi, les systèmes utilisant le format d’en-tête LUKS2 utilisaient par défaut argon2i , encore une fois pas un KDF coûteux en mémoire qui est fort en mémoire, mais pas conçu pour résister aux attaques GPU (grâce aux commentaires soulignant mon malentendu ici). Les nouvelles versions utilisent par défaut argon2id, qui est.
Vous voulez utiliser argon2id.
Ce qui aggrave la situation, c’est que les distributions ne mettent généralement pas à jour cela de quelque manière que ce soit. Si vous avez installé votre système et qu’il vous a donné pbkdf2 comme KDF, vous utilisez probablement toujours pbkdf2 même si vous avez mis à niveau vers un système qui utiliserait argon2id lors d’une nouvelle installation. Heureusement, tout cela peut être réparé sur place. Mais notez que si quelque chose ne va pas ici, vous pourriez perdre l’accès à toutes vos données cryptées, donc avant de faire quoi que ce soit, assurez-vous qu’elles sont toutes sauvegardées (et découvrez comment garder ladite sauvegarde sécurisée afin que vos données ne soient pas simplement saisies de cette façon ).
Tout d’abord, assurez-vous que vous exécutez une version de votre distribution aussi à jour que possible. Avoir des outils prenant en charge le format LUKS2 ne signifie pas que votre distribution intègre tout cela, et les anciennes versions de distribution peuvent vous permettre de mettre à jour votre configuration LUKS sans réellement prendre en charge le démarrage à partir de celui-ci. De plus, si vous utilisez un /boot crypté, arrêtez maintenant – les versions très récentes de grub2 prennent en charge LUKS2, mais elles ne prennent pas en charge argon2id, ce qui rendra votre système impossible à démarrer.
Ensuite, déterminez quel périphérique sous /dev correspond à votre partition chiffrée. Exécutez
lsblk
et recherchez les entrées qui ont un type de « crypte ». Le périphérique au-dessus de celui-ci dans l’arborescence est le périphérique chiffré réel. Enregistrez ce nom et exécutez
sudo cryptsetup luksHeaderBackup /dev/whatever –header-backup-file /tmp/luksheader
et copiez-le sur une clé USB ou autre. Si quelque chose ne va pas ici, vous pourrez démarrer une image en direct et exécuter
sudo cryptsetup luksHeaderRestore /dev/whatever –header-backup-file luksheader
pour le restaurer.
(Modifier pour ajouter : une fois que tout fonctionne, supprimez cette sauvegarde ! Elle contient l’ancienne clé faible, et quelqu’un qui la possède peut potentiellement l’utiliser pour forcer brutalement votre clé de chiffrement de disque à l’aide de l’ancien KDF, même si vous avez mis à jour le disque KDF.)
Ensuite, exécutez
sudo cryptsetup luksDump /dev/whatever
et recherchez la ligne Version:. S’il s’agit de la version 1, vous devez mettre à jour l’en-tête vers LUKS2. Exécuter
sudo cryptsetup convert /dev/whatever –type luks2
et suivez les invites. Assurez-vous que votre système démarre toujours, et si ce n’est pas le cas, revenez en arrière et restaurez la sauvegarde de votre en-tête. En supposant que tout va bien à ce stade, exécutez à nouveau
sudo cryptsetup luksDump /dev/whatever
et recherchez la ligne PBKDF: dans chaque emplacement de clé (faites attention uniquement aux emplacements de clé, ignorez toutes les références à pbkdf2 qui viennent après la ligne Digests :). Si le PBKDF est « pbkdf2 » ou « argon2i », vous devez le convertir en argon2id. Exécutez ce qui suit :
sudo cryptsetup luksConvertKey /dev/whatever –pbkdf argon2id
et suivez les invites. Si vous avez plusieurs mots de passe associés à votre lecteur, vous aurez plusieurs emplacements de clés et vous devrez répéter cela pour chaque mot de passe.
Distributions ! Vous devriez vraiment gérer ce genre de chose lors de la mise à niveau. Les personnes qui ont installé leurs systèmes avec vos paramètres de cryptage par défaut il y a plusieurs années sont maintenant beaucoup moins sécurisées que les personnes qui effectuent une nouvelle installation aujourd’hui. S’il vous plaît, s’il vous plaît, faites quelque chose à ce sujet.
SOURCE