Chargeurs de démarrage Linux prenant en charge le chiffrement complet du disque?

28

Existe-t-il des chargeurs de démarrage Linux prenant en charge le chiffrement complet du disque (à la TrueCrypt ). Je sais qu'il y avait du travail pour ajouter la prise en charge du chiffrement à GRUB2, mais cela ne semble pas encore prêt. D'autres options?

(Notez que je fais vraiment référence au chiffrement complet du disque ici, y compris /boot)

La plupart des réponses décrivent une configuration où /bootn'est pas chiffré, et certaines d'entre elles essaient d'expliquer pourquoi un non chiffré /bootdevrait être OK.

Sans entrer dans une discussion sur les raisons pour lesquelles j'ai réellement besoin que / boot soit chiffré, voici un article qui décrit exactement ce dont j'ai besoin, basé sur une version modifiée de GRUB2:

Le problème avec cela est que ces modifications ne sont apparemment pas prises en charge dans la base de code GRUB2 actuelle (ou peut-être que j'oublie quelque chose).

linux encryption Grodriguez
la source
oui, il y a un excellent howto ici: wiki.archlinux.org/index.php/…
ebal

Réponses:

20

Je pense que la version actuelle de GRUB2 ne prend pas en charge le chargement et le décryptage des partitions LUKS par elle-même (elle contient des chiffres mais je pense qu'ils ne sont utilisés que pour la prise en charge des mots de passe). Je ne peux pas vérifier la branche de développement expérimental, mais il y a quelques indices dans la page GRUB que certains travaux sont prévus pour implémenter ce que vous voulez faire.

Mise à jour (2015) : la dernière version de GRUB2 (2.00) inclut déjà du code pour accéder aux partitions chiffrées LUKS et GELI. (Le lien xercestch.com fourni par l'OP mentionne les premiers correctifs pour cela, mais ils sont désormais intégrés dans la dernière version).

Cependant, si vous essayez de chiffrer le disque entier pour des raisons de sécurité, veuillez noter qu'un chargeur de démarrage non chiffré (comme TrueCrypt, BitLocker ou un GRUB modifié) n'offre pas plus de protection qu'une /bootpartition non chiffrée (comme l'a noté JV dans un commentaire ci-dessus) . Toute personne disposant d'un accès physique à l'ordinateur peut tout aussi facilement le remplacer par une version personnalisée. Cela est même mentionné dans l'article de xercestech.com que vous avez lié:

Pour être clair, cela ne rend en rien votre système moins vulnérable aux attaques hors ligne, si un attaquant devait remplacer votre chargeur de démarrage par le sien, ou rediriger le processus de démarrage pour démarrer son propre code, votre système pourrait toujours être compromis.

Notez que tous les produits logiciels pour le chiffrement complet du disque présentent cette faiblesse, qu'ils utilisent un chargeur de démarrage non chiffré ou une partition de démarrage / pré-démarrage non chiffrée. Même les produits prenant en charge les puces TPM (Trusted Platform Module), comme BitLocker, peuvent être enracinés sans modifier le matériel.

Une meilleure approche serait de:

  1. déchiffrer au niveau du BIOS (dans la carte mère ou l'adaptateur de disque ou le matériel externe [carte à puce], avec ou sans puce TPM), ou
  2. transporter le code PBA (autorisation de pré-démarrage) (la /bootpartition dans ce cas) dans un périphérique amovible (comme une carte à puce ou une clé USB).

Pour le faire de la deuxième façon, vous pouvez vérifier le projet Linux Full Disk Encryption (LFDE) à: http://lfde.org/ qui fournit un script de post-installation pour déplacer la /bootpartition vers un lecteur USB externe, en chiffrant la clé avec GPG et le stocker également sur l'USB. De cette façon, la partie la plus faible du chemin de démarrage (la /bootpartition non chiffrée ) est toujours avec vous (vous serez le seul à avoir un accès physique au code de déchiffrement ET à la clé). ( Remarque : ce site a été perdu et le blog de l'auteur a également disparu, mais vous pouvez trouver les anciens fichiers sur https://github.com/mv-code/lfde juste noter que le dernier développement a été fait il y a 6 ans). Comme alternative plus légère, vous pouvez installer la partition de démarrage non chiffrée sur une clé USB lors de l'installation de votre système d'exploitation.

Cordialement, MV

MV.
la source
1
Le décryptage au niveau du BIOS serait en effet une très bonne solution (j'ai considéré cela comme une option) ...
1
Je ne connais aucune implémentation fonctionnelle, mais EFI / UEFI a la possibilité d'inclure un gestionnaire de démarrage EFI personnalisé pour remplacer un chargeur de démarrage commun, peut-être en ajoutant une couche de déchiffrement pour déchiffrer les données (bien sûr, vous aurez besoin d'une plate-forme EFI ). Ou peut-être que certains des projets liés à CoreBoot (ADLO, SeaBIOS, OpenBIOS, etc.) peuvent être modifiés pour ce faire. Juste des idées.
4
Juste pour ajouter plus d'informations sur la faiblesse de l'utilisation d'une partition de démarrage / non chiffrée (mais cela s'applique également à un chargeur de démarrage non chiffré): twopointfouristan.wordpress.com/2011/04/17/… (comment modifier le démarrage partition en 10 minutes d'accès physique, pour récupérer la phrase secrète de montage ainsi que tout autre fichier de la partition chiffrée)
1
@MV .: Merci. Je peux le tester moi-même et ajouter une réponse ici avec des étapes plus détaillées pour utiliser des /bootpartitions chiffrées avec GRUB2.
Peque
1
@ 에이 바: non, c'est lié (en utilisant LUKS avec un TPM) mais ce n'est pas le même projet précédemment hébergé sur lfde.org (qui est maintenant un site sur un aéroclub).
MV.
4

Assurez-vous que votre disque RAM initial et le dossier / boot n'utilisent pas le chiffrement.

Cela fera apparaître un noyau "minimal", avec des pilotes et une prise en charge pour basculer vers le système de fichiers racine "réel" qui est chiffré.

Avant de prétendre que «c'est un hack» - rappelez-vous - la plupart (sinon la totalité) des distributions Linux démarrent de cette façon aujourd'hui par défaut. Cela permet explicitement à votre système de démarrer et de charger votre FS racine, à l'aide de modules qu'il doit charger à partir d'un système de fichiers. (Sorte d'un problème de poulet et d'oeuf). Comme par exemple, si votre système de fichiers racine était sur un volume RAID matériel, et que vous deviez charger son pilote avant de pouvoir monter votre FS racine.

Brad
la source
3

J'ai passé en revue le lien que vous avez publié - bien qu'il n'y ait pas de partition de démarrage, il y a toujours un chargeur de démarrage non chiffré sur le disque dur qui peut être consulté et compromis à l'aide d'une attaque malveillante. J'ai étudié une configuration similaire, dans laquelle il n'y a pas de données non chiffrées sur le disque dur, mais jusqu'à présent, je n'ai trouvé que l'exécution d'un chargeur de démarrage à partir d'un lecteur amovible.


la source
Oui, il existe toujours un chargeur de démarrage non chiffré. Ce serait acceptable pour moi.
La femme de chambre maléfique peut infecter le chargeur de démarrage pour faire une fausse invite de mot de passe pour vous tromper, puis charger simplement le noyau de cheval de Troie non chiffré. Le chiffrement du noyau gagne très peu sans chiffrer le chargeur de démarrage.
Skaperen
1

Je crois que la plupart d'entre eux le font, ce dont vous avez besoin est d'instructions sur la façon d'installer le système d'exploitation avec HD crypté en premier lieu.

Ubuntu a une belle page avec des instructions sur la création de partitions cryptées, LMVP, dossiers, etc., il suffit de google votre version de distributions de cela ...

JV
la source
2
La plupart des distributions Linux, y compris Ubuntu, incluent une sorte de prise en charge du chiffrement des partitions, mais elles nécessitent que / boot ne soit pas chiffré. Ce que je recherche, c'est un chargeur de démarrage capable de gérer un disque entièrement crypté.
1
Au moins une partie du chargeur de démarrage doit être non chiffrée, sinon le CPU ne pourrait pas l'exécuter. Y a-t-il un problème particulier que vous ayez à laisser / boot non chiffré?
2
Le chargeur de démarrage et / boot sont des choses différentes. Je recherche un chargeur de démarrage capable de démarrer un disque entièrement crypté. TrueCrypt peut le faire pour Windows, mais pas pour Linux.
La différence est que le chargeur de démarrage Windows est contenu dans le mbr lui-même tandis que sur linux, le mbr est simplement lié aux fichiers / boot nécessaires.
JV
1
"L'authentification de pré-démarrage est gérée par le chargeur de démarrage TrueCrypt, qui réside dans la première piste du lecteur de démarrage" - c'est-à-dire que sur Windows, il crée un mini-démarrage. Encore une fois, grub lui-même est contenu dans / boot, le mbr n'est que de 512 octets, pas assez pour stocker un algorithme de déchiffrement. Quoi qu'il en soit, une partie du disque dur doit être fournie non chiffrée. Vous pourriez être en mesure de démarrer grub sur une partition chiffrée à partir d'un chargeur de démarrage sur une partition complètement différente, mais cela nécessiterait un code très salissant ...
JV
0

Non, je pense que non.

Avez-vous vraiment besoin de chiffrer / démarrer? Je suppose que non. Le reste du système de fichiers peut être chiffré par un logiciel Linux normal qui réside sur un initramfs dans / boot et invite l'utilisateur en conséquence.

MarkR
la source
2
Oui, je dois chiffrer / démarrer. Tout doit être chiffré sauf le chargeur de démarrage lui-même.
Veuillez expliquer pourquoi vous pensez qu'aucun chargeur de démarrage ne prend en charge le chiffrement intégral du disque.
this.josh
@Grodriguez: si vous considérez / boot comme faisant partie du chargeur de démarrage, alors tout est crypté - tous les binaires utilisés à l'exécution, toutes les données utilisateur, etc.
MarkR
2
Comme indiqué dans un commentaire sur une autre réponse: je sais qu'il doit toujours y avoir "quelque chose" qui n'est pas chiffré - j'ai juste besoin de ce "quelque chose" pour être le chargeur de démarrage (MBR + secteur de démarrage), au lieu d'une partition / boot .
0

Vous semblez demander quelque chose d'impossible à faire et le comparer à une solution Windows qui vous cache l'implémentation mais qui fait en réalité la même chose que Linux.

La solution la plus proche à laquelle je peux penser est d'utiliser un disque dur qui implémente un mot de passe de sécurité et un cryptage. Certains ordinateurs portables Thinkpad utilisent ces solutions matérielles.

Zan Lynx
la source
2
Désolé, mais je ne vois pas pourquoi cela devrait être "impossible". L'article auquel je renvoie dans ma question prouve que cela peut être fait. Une preuve de concept a été implémentée à l'aide d'une version modifiée de GRUB 2. Je sais qu'il doit toujours y avoir "quelque chose" qui n'est pas chiffré - j'ai juste besoin de ce "quelque chose" pour être le chargeur de démarrage (MBR + secteur de démarrage), à ​​la place d'une partition / boot.
@Grodriguez: Votre exigence n'a aucun sens. Votre exigence est-elle satisfaite lors de l'utilisation d'une machine virtuelle dans un autre système d'exploitation? Si c'est le cas, démarrez le système d'exploitation un, déchiffrez le lecteur et lancez la machine virtuelle.
Zan Lynx
2
Avez-vous réellement essayé de lire l'article auquel j'ai lié? Le fait que vous ne compreniez pas l'exigence ne signifie pas que «cela n'a aucun sens». J'ai des raisons valables à cela (dans lesquelles je ne veux pas entrer).
L'article indique clairement au paragraphe 3 qu'il n'améliore pas la situation. Donc, cela n'a aucun sens pour moi de suivre le reste, qui se concentre sur la façon de le configurer, plutôt que sur la façon dont cela fonctionne. Réfléchissez à ce qui va vous dire que j'ai remplacé votre noyau, ou l'ensemble / boot, par le mien (en agissant comme une mauvaise fille).
Skaperen
0

La réponse est suggérée par l'article. "Ceci est désormais possible avec les extensions du chargeur de démarrage GRUB2 de nouvelle génération, qui a été corrigé pour prendre en charge non seulement" et "nous souhaitons installer notre nouvelle image grub2 activée par luks plus tard" et "Maintenant, nous compilons la source GRUB2 compatible LUKS. " Il semble qu'il y ait un correctif ou une extension que vous devez obtenir et inclure avec GRUB2, ou une source GRUB2 fourchue.

Skaperen
la source
0

Grub2 version 2.02 ~ beta3 peut faire beaucoup de choses que Grub2 version 2.02 ~ beta2 ne peut pas faire, testé par moi:

  1. Démarrage à l'aide du disque Super Grub 2
  2. Tapez la touche «c» pour accéder à la ligne de commande
  3. Tapez les commandes pour monter la partition chiffrée que je veux
    • insmod luks
    • cryptomount (hd0, #) // où # représente la partition chiffrée
  4. Tapez la phrase secrète et tapez quelques commandes plus
    • multiboot (crypto0) /grub/i386-pc/core.img
    • démarrage

Cela chargera un autre Grub2 qui est à l'intérieur d'une partition cryptée, une attaque folle maléfique n'a pas de sens ici ... je démarre à partir d'un CD (support en lecture seule), puis je monte une partition cryptée (sans la phrase secrète comment oser quelqu'un peut-il oser injectez quoi que ce soit!), puis démarrez à partir de la partition chiffrée et chargez un Grub2 avec son propre menu, etc.

Remarque: un tel démarrage Grub 2.02 ~ beta3 (j'utilise Super Grub 2 cd) peut être sur une clé USB, un disque dur USB, etc.

Avertissement: Grub2 version 2.02 ~ beta2 ne peut pas faire la même chose car il y a quelques BUG (qui semblent être corrigés sur Grub2 version 2.02 ~ beta3) liés à la commande cryptomount ...

Les bogues beta2, je parle, sont:

  1. Il ne monte pas vraiment la partition chiffrée, il ne vous permet donc pas d'accéder à (crypto0) / *
  2. S'il y a plusieurs partitions chiffrées, l'utilisation cryptomount -ane demande qu'une seule phrase secrète
  3. Après avoir exécuté cryptomount une fois, il est à nouveau exécuté ne fait rien

sur beta 3:

  1. Il monte vraiment la partition chiffrée et vous permet d'accéder aux fichiers via (crypto0) / * ou (crypto1) / * etc si plusieurs sont montés en même temps
  2. Il demande chaque phrase secrète (une par partition chiffrée)
  3. Il vous permet de l'exécuter autant de fois que nécessaire, vous pouvez en monter un, puis un autre, etc.

Note latérale: Je n'ai pas compris comment les démonter, sauf redémarrer ou démarrer un autre ou le même chargeur de démarrage grub2 / autre, etc.

J'espère que cela aide à clarifier les choses et j'espère que Grub2 version 2.02 ~ beta3 sera intégré sur les LiveCD afin que nous puissions l'installer sans avoir besoin de le compiler par nous-mêmes.

PD: Avec le disque Super Grub 2, je ne vois aucun moyen d'installer Grub2 version 2.02 ~ beta3 sur la partition MBR / boot, etc.

Claudio
la source