LUKS armazenando o arquivo-chave na unidade usb criptografada

Question

Eu já perguntei sobre o desbloqueio LUKS de vários HDDs em Linux: LUKS e vários discos rígidos .

Agora eu gostaria de saber como proteger o armazenamento do arquivo de chaves usado para o desbloqueio automático das partições associadas.

Meu plano é (se possível):

• Criptografar uma pequena unidade USB com o LUKS que requer uma frase secreta

• Desbloqueie-o na inicialização como a primeira unidade usando a frase secreta

• Monte-o em um determinado ponto de montagem, por exemplo / test (isso é possível?)

• Agora, o arquivo de chaves pode ser lido com segurança: / test / keyfile

• Use o arquivo de chaves para desbloquear outras unidades sem precisar perguntar a senha para elas

• LuksFeche a unidade USB para garantir um certo grau de segurança assim que outras unidades forem desbloqueadas

• Automount /, / usr, / var e outros pontos de montagem, como de costume

Isso pode funcionar? Basicamente, eu armazeno o arquivo de chaves LUKS em uma unidade USB LUKS criptografada por senha que só pede uma senha uma vez, enquanto todas as outras unidades podem ser desbloqueadas sem outras ações. Não tenho certeza se existe alguma forma de desbloquear a unidade USB primeiro, depois montá-la e somente depois as outras unidades tentarem acessar o arquivo de chaves. Além disso, no que diz respeito à automação, suponho que / etc / fstab e / etc / crypttab devam ser acessíveis ANTES que as outras unidades possam ser montadas, mas isso não é possível se o sistema / arquivo inteiro for criptografado pelo LUKS.

A menos que haja a possibilidade de configurar totalmente manualmente como o LUKS funciona :

• LuksOpen / dev / sdc1 usb_keyfile

• monte / dev / mapper / usb_keyfile / keyfile (isso é possível?)

• LuksOpen - arquivo-chave / arquivo-chave / chave / dev / sda1 disco1

• LuksOpen - arquivo-chave / arquivo-chave / chave / dev / sdb1 disco2

• LuksClose / dev / sdc1

Basicamente, ser capaz de executar um script de shell logo após os módulos necessários terem sido carregados e desabilitar o prompt automático de senha LUKS.

Detalhes adicionais

• Distribuição usada: Gentoo GNU / Linux (amd64) ou Debian GNU / Linux (amd64) porque gostaria de aplicar este procedimento a várias instalações

Answer 1

Sua abordagem parece boa. Algumas observações embora:

• Se você deseja criptografar o rootfs, você precisará usar o initrd (para ter um sistema mínimo não criptografado que processará as partições criptografadas).

  Se o dispositivo USB for removível, tanto o initrd quanto o kernel podem ser armazenados no USB para aumentar a resistência a adulterações (supondo que você tenha certeza de que o USB não entrará em mãos não-autorizadas) - que geralmente criptografa rootfs. Quando o kernel e o initrd estiverem em uma mídia removível, você pode garantir que ninguém altere o kernel (ou initrd) do sistema em execução simplesmente removendo a mídia.

  Isto obviamente não é uma opção se você quiser tê-lo dentro de um servidor, mas, novamente, a questão é se faz sentido ter tal dispositivo e não usar uma pequena partição em um disco rígido. -drives. Se, por exemplo, todas as unidades da máquina estiverem em RAID, provavelmente também se deseje colocar rootfs no USB. Uma alternativa interessante para um dispositivo flash USB conectado internamente pode ser um cartão CompactFlash conectado à interface ATA através de um adaptador, por sinal.

  Algumas distribuições oferecem soluções preparadas para a raiz criptografada, outras não - mas principalmente é questão de colocar algumas linhas no script initrd antes de tentar montar a raiz "real" (veja por exemplo man pages para pivot_root , geralmente nas seções 2 (syscall) e 8 (bonary), se você não estiver familiarizado com o processo).

• lembre-se de fazer o backup das chaves e senhas caso a sua unidade USB morra. O LUKS segue uma abordagem unilateral quando se trata de danificar seu cabeçalho - uma vez que um único setor de seu cabeçalho (slot-chave, para ser mais preciso) morre, você é incapaz de montá-lo. Isso é para garantir que o apagamento do cabeçalho não seja efetivamente afetado pela realocação de bloco executada pelo próprio dispositivo (porque é isso que os dispositivos baseados em memória flash fazem muito) - a chave é distribuída por todo o slot da chave e é necessário os dados para reconstruí-lo - não há redundância. Veja o site do Clemens Fruwirth para uma discussão mais profunda.

  Dito isto, talvez um dispositivo criptografado simples no USB seja suficiente (verifique a seção PLAIN MODE in man cryptsetup ). Ou um arquivo criptografado com, e. %código%. O primeiro pode ser uma opção, mesmo para as próprias partições criptografadas.