Forum Linux.général Deux systèmes de chiffrement cote à cote pour un système dual boot

Posté par  . Licence CC By‑SA.
Étiquettes :
1
26
jan.
2021

Bonjour,

Sur ma machine portable je fait cohabiter un windows 10 et un Linux (mint).

Petite subtilité, la partition windows 10 en question est chiffrée par bitlocker
(J'avais désactivé bitlocker avant le repartitionnement et l'installation du Linux puis l'avait réactivé une fois terminé)

Les partitions sur le disque (dans l'ordre):
- EFI system de 2.1GB /boot/efi
- Microsoft Reserved de 134MB
- Basic Data (partition windows chiffrée par bitlocker)
- Filesystem (partition linux) Ext4

Je suppose que la puce TPM de l’ordinateur est utilisée par bitlocker car aucune clef n'est demandée au démarrage tant que l'on ne modifie pas trop de chose (cela m'est arrivé une fois en mettant à jour le kernel de la partition Linux)

Cela fonctionne sans problème mais m’apprêtant à réinstaller le Linux, j'aimerais compliquer les choses et chiffrer aussi la partition qui lui est dédiée.
Je souhaite ne pas toucher à la partition de windows et la manière dont elle est chiffrée avec bitlocker. Les deux systèmes de chiffrement seraient donc voisins.

L'ordinateur portable est relativement récent et dispose d'un bios EFI, le disque est un SSD nvme (je prévois d'adjoindre un disque mécanique pour du stockage complémentaire mais sans besoin de le chiffrer)

Mes questions:

  1. Quelle solution de chiffrement (libre/open-source) avec une communauté toujours active conviendrait le mieux pour ce cas de figure? Cryptsetup, LUKS, Veracrypt, dm-crypt, autre ?

  2. Comment ne pas commettre d'erreur avec les pièges que je sens venir: Le bios EFI ; le MBR ; Grub ; Windows ; bitlocker ; le chiffrement éventuel du /boot ; autre ? A quoi faut-il particulièrement faire attention?

  3. J'ai vu dans ce commentaire qu'il était possible de faire en sorte que le système démarre sans rien demander sur windows si rien n'est branché et que si une clef USB était branchée le système démarre en donnant le choix pour permettre de déchiffrer et lancer le Linux. Comment procéder pour arriver à ceci?

  4. Pour cette réinstallation je pense passer au système de fichier BtrFS pour la partition Linux, pas de contre-indication dans ce cas de figure? (Dommage que BtrFS ne gère pas encore le chiffrement)

Merci de m'avoir lu.

  • # Pour le point 3 une piste

    Posté par  . Évalué à 1 (+0/-0).

    Hello ROUGEXIII,

    Pour le point 1. Je n'utilises que LUKS donc je ne peux pas te donner d'avis comparatif.

    Pour le point 2. Sur le forum, j'ai lu un commentaire récemment qui proposait d'utiliser une partition EFI pour chaque OS si la carte mère le permet ça peut simplifier la cohabitation (toutefois je ne suis pas un spécialiste de l'EFI)

    Pour le point 3. Une piste est d'insérer une seconde clé USB lors de l'installation et de choisir d'installer /boot dessus (à combiner avec un tuto qui indique comment chiffrer /boot également) - penser a la laisser branchée lors des mises à jour qui touchent au /boot

    Pour le point 4. pas d'expérience significative avec ce système de fichier

    :-)

    Julien_c'est_bien (y'a pas que Seb)

  • # À propos de cryptsetup / dm-crypt / LUKS

    Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

    Quelle solution de chiffrement (libre/open-source) avec une communauté toujours active conviendrait le mieux pour ce cas de figure? Cryptsetup, LUKS, Veracrypt, dm-crypt, autre ?

    Alors en gros, cryptsetup, LUKS, et dm-crypt, c’est plus ou moins la même chose, ou plus exactement ça désigne différents composants d’un même système.

    dm-crypt, c’est la couche au sein du noyau Linux qui s’occupe du chiffrement des volumes.

    LUKS (Linux Unified Key Setup) est une sorte de « surcouche » à dm-crypt. En gros c’est un volume dm-crypt associé à un en-tête contenant la clef de chiffrement du volume, l’en-tête étant lui-même chiffré par un ou plusieurs mots de passe. Le principal intérêt de LUKS est ainsi de séparer le chiffrement proprement dit du volume de la gestion des mots de passe : on peut ainsi par exemple changer de mot de passe sans toucher au volume chiffré et utiliser plusieurs mots de passe pour un seul et même volume.

    cryptsetup, c’est l’outil en espace utilisateur permettant de créer et manipuler des volumes dm-crypt ou LUKS.

    Donc en l’espèce, le choix est entre :

    • le chiffrement de volume natif de Linux (dm-crypt, avec ou sans l’extension LUKS — en pratique je ne vois pas de raison d’éviter LUKS qui est très pratique — et mis en place avec cryptsetup) ;
    • le chiffrement de volume par une solution tierce comme VeraCrypt.

    L’utilisation de VeraCrypt peut être pertinente pour un volume externe (clef USB ou assimilé) que l’on souhaite utiliser à partir de plusieurs systèmes différents (VeraCrypt est portable et un volume VeraCrypt créé par exemple sous GNU/Linux est déchiffrable avec VeraCrypt sous Windows). Pour un volume système, je ne vois pas de raison de ne pas utiliser le chiffrement natif (dm-crypt donc).

  • # Mon avis

    Posté par  (site Web personnel) . Évalué à 3 (+0/-0).

    Quelle solution de chiffrement (libre/open-source) avec une communauté toujours active conviendrait le mieux pour ce cas de figure? Cryptsetup, LUKS, Veracrypt, dm-crypt, autre ?

    LUKS, sans hésiter. Comme dit plus haut, cryptsetup et dm-crypt désignent grosso modo la même chose.

    Le point à prendre en compte est que pour démarrer un système GNU/Linux, on lance un noyau Linux, pour lequel on a chargé en mémoire un système de fichier racine initial, qu'on appelle l'initrd. Dans cet initrd, il y a un programme init, et tout ce qu'il faut comme pilotes, outils et bibliothèques pour pouvoir accéder au périphérique sur lequel se trouve le vrai système de fichiers racine, et monter ce dernier.

    Toi, tu veux chiffrer ce système de fichiers. Il faut donc une prise en charge de ce chiffrement dans l'initrd. Et ça, je pense que ça ne laisse qu'un seul candidat, LUKS, qui est certainement intégré à l'initrd prévu par ta distribution (en installant au besoin un paquet spécifique), et probablement le seul qui soit ainsi intégré.

    Comment ne pas commettre d'erreur avec les pièges que je sens venir: Le bios EFI ; le MBR ; Grub ; Windows ; bitlocker ; le chiffrement éventuel du /boot ; autre ? A quoi faut-il particulièrement faire attention?

    Pour l'EFI, aucun problème, il n'a rien à voir avec le système de fichiers chiffré qui servira de / ou de /home sous GNU/Linux. Tout ce qu'il faut, c'est que la partition système EFI, sur laquelle se trouve ton chargeur de démarrage, soit lisible par l'EFI, donc pas chiffrée.

    Pour GRUB, là c'est plus particulier. Il a apparemment une prise en charge de LUKS, mais je ne sais pas ce qu'elle vaut. Généralement, dans ce genre de cas, il me semble qu'on met en place un /boot non chiffré. C'est là que GRUB ira chercher le noyau et l'initrd à lancer. Il n'y a pas de problème à ne pas chiffrer ce système de fichiers, puisqu'il ne contient que des informations publiques, à savoir un noyau Linux et un initrd assemblé selon les règles d'une distribution GNU/Linux connue.

    Windows n'est en aucun cas concerné par le chiffrement d'un système de fichier utilisé exclusivement par un système GNU/Linux. Pareil pour Bitlocker.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.