Discussion :

[chrtophe]

Bonjour,

Je vous présente mon nouveau tutoriel sur :

Tutoriel pour apprendre comment chiffrer vos disques

Cet article va vous expliquer comment chiffrer vos disques sur les différents systèmes d'exploitation.

N'hésitez pas à commenter ou poser des questions.

[Fagus]

merci beau tutoriel.

Une remarque, pour choisir le chiffrage sous veracrypt, un critère est de tester la vitesse. Normalement c'est AES grâce au chiffrage matériel par le CPU.

Bien qu'il faille faire des sauvegardes, par curiosité, est-ce que quelqu'un a de l'expérience de la récupération d'un disque chiffré un peu défectueux ?
De mémoire, depuis truecrypt je crois qu'on peut monter une partition abîmée puis lancer les utilitaires et que "ça va".
Pour LURKS je ne sais pas trop ce que ça vaut en cas de problème.

[chrtophe]

beau tutoriel.

Merci.

Une remarque, pour choisir le chiffrage sous veracrypt, un critère est de tester la vitesse.

Les différents types de chiffrement peuvent effectivement jouer sur la vitesse mais aussi sur la fiabilité de celui-ci, voire sur la facilité de récupération en cas de crash. Je n'ai pas testé les éventuels écarts de vitesse des différents chiffrements proposés.

quelqu'un a de l'expérience de la récupération d'un disque chiffré un peu défectueux ?

Je n'en ai pas perso fait l'expérience, mais il est logique que le chiffrement apporte une couche supplémentaire de complexité. Tout comme pour un RAID logiciel endommagé par exemple. Il faudra tout d'abord monter le conteneur/la partition chiffrée pour la rendre accessible à un éventuel outil de récupération.

La récupération depuis bitLocker devrait être "la plus facile" dans le sens ou c'est le même éditeur qui a créé le filesystem et l'outil de chiffrement.

Selon l'état de "casse", il peut être pertinent d'utiliser des outils de récupération spécialisé. Tout dépend du prob.

[wistiti1234]

Merci pour ce guide, et le tout dernier que vous venez de publier.

3-2. Veracrypt
La version Linux de Veracrypt ne permet pas le chiffrement de la partition système en cours contrairement à la version Windows, vous ne pourrez donc pas l’utiliser sans faire une installation de base. Il reste possible de l’utiliser pour créer des conteneurs montés dans des points de montage. Cet aspect n’a pas été étudié.

En fait, si, j'ai découvert récemment qu'il existait bien un moyen de faire ça. Mais ça n'utilise pas le "logiciel" Veracrypt proprement dit, mais l'implémentation des algos de ce format de conteneur dans dm-crypt/LUCKS (dans le même temps, probable que ce soit aussi un peu plus efficace/performant, puisque Veracrypt sous Linux tourne au travers de FUSE, en espace utilisateur, tandis que dm-crypt est directement intégré au noyau).

La méthode est décrite dans ce guide (voir aussi le premier commentaire, qui renvois vers quelques variantes):
https://www.reddit.com/r/VeraCrypt/c...n_to_standard/

Ça pourrait apporter un plus à vos guides, si vous couvriez également cette technique, en la testant/validant/complétant/commentant, puisque actuellement, peu de gens doit être au courant que c'est possible (même le site officiel dit toujours que ce n'est pas supporté sous Linux. Et effectivement, ça ne passe pas par leur soft à eux).

merci beau tutoriel.

Une remarque, pour choisir le chiffrage sous veracrypt, un critère est de tester la vitesse. Normalement c'est AES grâce au chiffrage matériel par le CPU.

L'utilitaire de Veracrypt propose un outils de benchmarking des algos, dans ses options. Et effectivement, AES est chez moi 5 à 6 fois plus rapide que son premier successeur. En désactivant l’accélération hardware, il se retrouve au même niveau que les autres (2ème ou 3ème), donc on voit effectivement l'utilité des instructions AES-NI.

Avec LUCKS, la commande je crois c'est 'cryptsetup benchmark'

[chrtophe]

Wistiti, par rapport à ta remarque, il suffit de se baser sur le chapitre luks en passant l'option tcrypt pour Truecrypt.

Je ne sais pas si c'est pertinent d'ajouter cet aspectdans le tutoriel.

[wistiti1234]

Oui effectivement, je suis en train de la lire et je remarque que les procédures sont très proches.
Chez eux, ils passent par l'installeur de la session live, ce qui rend la démarche un peu plus simple, que d'utiliser debootstrap. Mais chez vous, vous détaillez bien mieux chaque étapes, c'est très instructif.
Merci.

[chrtophe]

L'installeur Ubuntu permet de faire une installation chiffrée telle que je le fais en mode GUI. la différence c'est qu'il ne gère pas à ma connaissance l'histoire de LUKS2 incompatible avec Grub, ce que je fais en créant un volume /boot en LUKS1 et le reste en LUKS2.

[wistiti1234]

Si je comprends bien, avec votre méthode, /boot est chiffré également, tandis qu'avec l'installeur il reste en claire?
Quel est l'enjeu à protéger /boot? Il contient tout le kernel, qui pourrait donc être altéré, c'est ça? Il n'héberge en tout cas à priori aucune autre donnée sensible ou personnelle. Ou bien ça ouvre une porte d'entrée à des formes attaques potentielles?

[chrtophe]

Si je comprends bien, avec votre méthode, /boot est chiffré également, tandis qu'avec l'installeur il reste en claire?

Je pense que la question concerne ce tutoriel :
https://chrtophe.developpez.com/tuto...tall-luks-lvm/

Il faudrait vérifier, je ne me souviens pas. Il faudrait que je fasses une installation standard pour vérifier.

Si /boot n'est pas protégé, il est effectivement possible de compromettre le noyau. Mais c'est plutôt au niveau de l'initramfs qui contient le fichier de clé pour monter /root que va se situer le prob, sauf à ne pas traiter la partie 7 : "supprimer la demande de clés". Dans ce cas, chaque accès à un point d emontage chifffré demandera le mot de passe au lieu d'avoir une seule demande à partir de Grub

[chrtophe]

Je viens de tester rapidement sur une Ubuntu LTS 18 (donc un peu agée).

La partition /boot est en ext4 et le root dans un ensemble LVM/LUKS. Le code de dévérouillage est demandée au moment du montage de /, après chargement du noyau et de l'intramfs. On peut envisager une attaque par compromission du noyau ou utilisation d'un module compromis dans l'initramfs qui récupèrerait la saisie effectuée, mais d'une part c'est peu probable, et d'autre part dans ce cas on pourrait faire la même chose avec GRUB.

En ayant le secureboot activé, on peut empêcher l’altération de GRUB et forcer l'utilisation d'un noyau signé.

Mais dans l'absolu, rien n'est infaillible. Et la masterkey secureboot a fuité il me semble.

[wistiti1234]

Ok, merci. Donc ça concerne plutôt une infiltration en douce, physique, de la machine, avant qu'on ne s'en resserve, plutôt que d'un vol du matériel.

[chrtophe]

Je dirais oui. En cas de vol de matériel, l'installation standard avec un /boot en ext4 et le root en LUKS conviendra très bien.

Honnêtement, mon tutoriel apporte peu en terme de sécurité par rapport à la complexité que cela ajoute.

L’intérêt sera surtout la compréhension du fonctionnement et de l'imbrication LVM/LUKS/Ext4 et l'installation via debootstrap.