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

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:

• http://xercestech.com/full-system-encryption-for-linux.geek

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).

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

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.

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.

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 ...

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.

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.

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.

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.