Carregadores de inicialização do Linux que suportam criptografia de disco completa?

Há algum carregador de inicialização do Linux que suporte criptografia de disco completa (como TrueCrypt ). Eu sei que havia trabalho para adicionar suporte de criptografia ao GRUB2, mas isso ainda não parece estar pronto. Alguma outra opção?

(Observe que estou realmente me referindo à criptografia completa de disco aqui, incluindo /boot)

A maioria das respostas descreve uma configuração onde /bootnão está criptografada e algumas tentam explicar por que uma não criptografada /bootdeve estar OK.

Sem entrar em uma discussão sobre por que eu realmente preciso que o boot seja criptografado, aqui está um artigo que descreve exatamente o que eu preciso, com base em uma versão modificada do GRUB2:

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

O problema com isso é que essas modificações aparentemente não são suportadas na atual base de código do GRUB2 (ou talvez eu esteja ignorando alguma coisa).

Eu acho que a versão atual do GRUB2 não tem suporte para carregar e descriptografar partições LUKS por si só (contém algumas cifras, mas acho que elas são usadas apenas para suporte à senha). Não consigo verificar o ramo de desenvolvimento experimental, mas há algumas dicas na página do GRUB de que algum trabalho está planejado para implementar o que você deseja fazer.

Atualização (2015) : a versão mais recente do GRUB2 (2.00) já inclui código para acessar partições criptografadas LUKS e GELI. (O link xercestch.com do OP mencionou os primeiros patches para isso, mas agora estão integrados na versão mais recente).

No entanto, se você estiver tentando criptografar o disco inteiro por motivos de segurança, observe que um carregador de inicialização não criptografado (como TrueCrypt, BitLocker ou um GRUB modificado) não oferece mais proteção que uma /bootpartição não criptografada (conforme observado pela JV em um comentário acima) . Qualquer pessoa com acesso físico ao computador pode facilmente substituí-lo por uma versão personalizada. Isso é mencionado no artigo xercestech.com que você vinculou:

Para deixar claro, isso não torna seu sistema menos vulnerável a ataques offline, se um invasor substituir o seu gerenciador de inicialização por um próprio ou redirecionar o processo de inicialização para inicializar seu próprio código, seu sistema ainda poderá estar comprometido.

Observe que todos os produtos baseados em software para criptografia de disco completo têm essa fraqueza, independentemente de usarem um carregador de inicialização não criptografado ou uma partição de inicialização / pré-inicialização não criptografada. Até produtos com suporte para chips TPM (Trusted Platform Module), como o BitLocker, podem ser enraizados sem modificar o hardware.

Uma abordagem melhor seria:

1. descriptografar no nível do BIOS (na placa-mãe ou no adaptador de disco ou no hardware externo [cartão inteligente], com ou sem um chip TPM) ou
2. leve o código PBA (autorização de pré-inicialização) (a /bootpartição neste caso) em um dispositivo removível (como um cartão inteligente ou um pendrive).

Para fazer isso da segunda maneira, você pode verificar o projeto LFDE (Linux Full Disk Encryption) em: http://lfde.org/, que fornece um script pós-instalação para mover a /bootpartição para uma unidade USB externa, criptografando a chave com GPG e armazená-lo no USB também. Dessa forma, a parte mais fraca do caminho de inicialização (a /bootpartição não criptografada ) está sempre com você (você será o único com acesso físico ao código de descriptografia E à chave). ( Nota : este site foi perdido e o blog do autor também desapareceu, no entanto, você pode encontrar os arquivos antigos em https://github.com/mv-code/lfde; observe o último desenvolvimento realizado há 6 anos). Como alternativa mais leve, você pode instalar a partição de inicialização não criptografada em um pendrive enquanto instala o sistema operacional.

Atenciosamente, MV

Faça com que seu disco RAM inicial e a pasta / boot não usem criptografia.

Isso exibirá um kernel "mínimo", com drivers e suporte para mudar para o sistema de arquivos raiz "real" que é criptografado.

Antes de você reivindicar "isto é um hack" - lembre-se - a maioria (se não todas) as distribuições Linux inicializam dessa maneira hoje por padrão. Isso permite explicitamente que o seu sistema inicialize e carregue o FS raiz, usando os módulos que ele precisa carregar de um sistema de arquivos. (Tipo de problema com galinhas e ovos). Por exemplo, se o seu sistema de arquivos raiz estava em um volume RAID de hardware e você precisava carregá-lo antes de montar o FS raiz.

Examinei o link que você postou - embora não exista partição de inicialização, ainda há um carregador de inicialização não criptografado no disco rígido que pode ser acessado e comprometido usando um ataque de empregada doméstica. Eu estive pesquisando uma configuração semelhante, na qual não há dados não criptografados no disco rígido, mas até agora só consegui executar um gerenciador de inicialização a partir de uma unidade removível.

Eu acredito que a maioria deles faz, o que você precisa é de instruções sobre como instalar o sistema operacional com HD criptografado em primeiro lugar.

O Ubuntu tem uma boa página com instruções sobre como fazer partições criptografadas, LMVPs, pastas etc., basta pesquisar no Google sua versão distros ...

Não, acho que não há.

Você realmente precisa criptografar / inicializar? Eu suspeito que não. O restante do sistema de arquivos pode ser criptografado pelo software Linux normal, que reside em um initramfs em / boot e solicita o usuário de acordo.

Você parece estar pedindo algo que é impossível de fazer e comparando-o com uma solução do Windows que esconde a implementação de você, mas na realidade está fazendo o mesmo que o Linux está fazendo.

A solução mais próxima que consigo pensar é usar um disco rígido que implemente uma senha de segurança e criptografia. Alguns dos laptops Thinkpad usam essas soluções de hardware.

A resposta é sugerida pelo artigo. "Isso agora é possível com extensões para o carregador de inicialização GRUB2 da próxima geração, que foi corrigido para suportar não apenas" e "desejamos instalar nossa nova imagem do grub2 habilitada para luks posteriormente" e "Agora compilamos a fonte GRUB2 habilitada para LUKS. " Parece que há um patch ou extensão que você precisa obter e incluir no GRUB2 ou em uma fonte bifurcada do GRUB2.

O Grub2 versão 2.02 ~ beta3 pode fazer muitas coisas que o Grub2 versão 2.02 ~ beta2 não pode fazer, testado por mim:

1. Inicialize usando o disco Super Grub 2
2. Digite a tecla 'c' para ir para a linha de comando
3. Digite comandos para montar a partição criptografada que eu quero
   • insmod luks
   • cryptomount (hd0, #) // onde # representa a partição criptografada
4. Digite a senha e digite alguns comandos mais
   • multiboot (crypto0) /grub/i386-pc/core.img
   • bota

Isso carregará outro Grub2 que está dentro de uma partição criptografada, um ataque maluco não faz sentido aqui ... estou inicializando a partir de um CD (somente leitura) e montando uma partição criptografada (sem a frase secreta, como ousa alguém injete qualquer coisa!), depois inicialize a partir da partição criptografada e carregue um Grub2 com seu próprio menu, etc.

Nota: Essa inicialização do Grub 2.02 ~ beta3 (eu uso o CD Super Grub 2) pode estar em um pendrive, disco rígido USB etc.

Aviso: O Grub2 versão 2.02 ~ beta2 não pode fazer o mesmo, pois possui alguns BUGs (que parecem estar corrigidos no Grub2 versão 2.02 ~ beta3) relacionados ao comando cryptomount ...

bugs beta2, eu falo sobre, são:

1. Ele realmente não monta a partição criptografada, portanto, não permite acessar (crypto0) / *
2. Se houver mais de uma partição criptografada, o uso de cryptomount -aapenas uma senha
3. Depois de executar o cryptomount uma vez, ele é executado novamente e não faz nada

na versão beta 3:

1. Ele realmente monta partição criptografada e permite acessar arquivos através de (crypto0) / * ou (crypto1) / * etc, se houver mais de uma montada ao mesmo tempo
2. Ele pede cada senha (uma por partição criptografada)
3. Permite executá-lo quantas vezes for necessário, você pode montar um, depois outro, etc.

Nota lateral: eu não sabia como desmontá-los, exceto reinicializar ou inicializar outro ou o mesmo grub2 / outro gerenciador de inicialização, etc.

Espero que isso ajude a esclarecer as coisas, e espero que o Grub2 versão 2.02 ~ beta3 seja integrado aos LiveCDs para que todos possamos instalá-lo sem a necessidade de compilá-lo por nós mesmos.

PD: Com o disco Super Grub 2, não vejo como instalar o Grub2 versão 2.02 ~ beta3 na partição MBR / boot etc.