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

28

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:

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

linux encryption Grodriguez
fonte
sim, há um excelente manual de
instruções

Respostas:

20

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

MV.
fonte
1
Descriptografar no nível do BIOS seria uma solução muito boa, na verdade (eu ter considerado isso como uma opção) ...
1
Não conheço nenhuma implementação em funcionamento, mas o EFI / UEFI tem a opção de incluir um EFI Boot Manager personalizado para substituir um carregador de inicialização comum, talvez adicionando uma camada de descriptografia para descriptografar os dados (é claro que você precisará de uma plataforma EFI ) Ou talvez parte do projeto relacionado ao CoreBoot (ADLO, SeaBIOS, OpenBIOS etc.) possa ser modificado para fazer isso. Apenas ideias.
4
Apenas para adicionar mais informações sobre a fraqueza de usar uma partição de inicialização não criptografada (mas também se aplica a um carregador de inicialização não criptografado): twopointfouristan.wordpress.com/2011/04/17/… (como modificar a inicialização partição em 10 minutos de acesso físico, para recuperar a senha de montagem mais qualquer outro arquivo na partição criptografada)
1
@MV .: Obrigado. Eu mesmo posso testá-lo e adicionar uma resposta aqui com etapas mais detalhadas para usar /bootpartições criptografadas com o GRUB2.
Peque
1
@ 에이 바: não, isso está relacionado (usando LUKS com um TPM), mas não é o mesmo projeto hospedado anteriormente em lfde.org (que agora é um site sobre um aeroclube).
MV.
4

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.

Brad
fonte
3

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.


fonte
Sim, ainda há um carregador de inicialização não criptografado. Isso seria aceitável para mim.
A empregada malvada pode infectar o carregador de inicialização para fazer um prompt de senha falsa para enganá-lo e, em seguida, basta carregar o kernel trojanizado não criptografado. Criptografar o kernel ganha muito pouco sem criptografar o carregador de inicialização.
Skaperen
1

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

JV
fonte
2
A maioria das distribuições Linux, incluindo o Ubuntu, inclui algum tipo de suporte para criptografar partições, mas elas exigem que / boot não seja criptografado. O que estou procurando é um carregador de inicialização que possa lidar com um disco completamente criptografado.
1
Pelo menos uma parte do carregador de inicialização precisa ser descriptografada, caso contrário, a CPU não poderá executá-lo. Existe algum problema específico em deixar / inicialização não criptografada?
2
O carregador de inicialização e / boot são coisas diferentes. Estou procurando um carregador de inicialização que possa inicializar um disco totalmente criptografado. O TrueCrypt pode fazer isso no Windows, mas não no Linux.
A diferença é que o gerenciador de inicialização do Windows está contido no mbr, enquanto no linux o mbr apenas vincula os arquivos / boot necessários.
JV
1
"A autenticação pré-inicialização é gerenciada pelo TrueCrypt Boot Loader, que reside na primeira faixa da unidade de inicialização" - ou seja, no Windows, ela cria uma mini- / inicialização. Novamente, o grub em si está contido em / boot, o mbr tem apenas 512 bytes, não o suficiente para armazenar um algoritmo de descriptografia. No entanto, uma parte do disco rígido deve ser fornecida sem criptografia. Você pode ser capaz de começar grub em uma partição criptografada a partir de um gerenciador de inicialização em um completamente diferente, mas isso exigiria algum código seriamente confuso ...
JV
0

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.

MarkR
fonte
2
Sim, preciso criptografar / inicializar. Tudo deve ser criptografado, exceto o próprio carregador de inicialização.
Explique por que você acredita que não há gerenciadores de inicialização compatíveis com a criptografia de disco completa.
this.josh
@Grodriguez: se você considerar / boot para ser parte do carregador de boot, então tudo é criptografado - todos os binários usados em tempo de execução, todos os dados do usuário, etc
MarkR
2
Como observado em um comentário em outra resposta: Eu sei que sempre deve haver "algo" que não é criptografado - só preciso desse "algo" para ser o carregador de inicialização (setor de inicialização MBR +), em vez de uma partição / boot .
0

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.

Zan Lynx
fonte
2
Desculpe, mas não vejo por que isso deve ser "impossível". O artigo ao qual vinculo minha pergunta prova que isso pode ser feito. Uma prova de conceito foi implementada usando uma versão modificada do GRUB 2. Sei que sempre deve haver "algo" que não é criptografado - só preciso desse "algo" para ser o carregador de inicialização (setor de inicialização MBR +). de uma partição / boot.
@Grodriguez: Sua exigência não faz sentido. Seu requisito foi atendido ao usar uma máquina virtual dentro de outro sistema operacional? Nesse caso, inicialize o SO um, descriptografe a unidade e inicie a VM.
precisa
2
Você já tentou ler o artigo ao qual vinculei? O fato de você não entender o requisito não significa que "não faz sentido". Tenho razões válidas para isso (nas quais não quero entrar).
O artigo deixa claro no parágrafo 3 que não melhora a situação. Portanto, não faz sentido seguir o resto, que se concentra em como configurá-lo e não em como ele funciona. Pense no que lhe dirá que substituí o seu kernel, ou o todo / boot, pelo meu (ao agir como empregada do mal).
Skaperen
0

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.

Skaperen
fonte
0

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.

Claudio
fonte