Usando uma única frase secreta para desbloquear vários discos criptografados na inicialização

Question

Minha máquina tem um SSD, onde instalei o sistema e um HDD, que uso como armazenamento para arquivos grandes e / ou pouco usados. Ambos são criptografados, mas optei por usar a mesma frase secreta para eles. O SSD é montado em / e o HDD em /usr/hdd (cada usuário possui um diretório e pode ligar simbolicamente como quiser no diretório home).

Quando o sistema é inicializado, ele imediatamente pede uma senha para o SSD e apenas alguns segundos depois para o do HDD (ele é montado automaticamente). Dado que ambas as senhas são as mesmas, existe uma maneira de configurar o sistema para perguntar apenas uma vez?

    

Answer 1

Distribuições baseadas no Debian:

Debian e Ubuntu enviam um script de cache de senhas decrypt_keyctl com cryptsetup pacote .

O script

decrypt_keyctl fornece a mesma senha para vários destinos LUKS criptografados, evitando que você o digite várias vezes. Ele pode ser ativado em crypttab com keyscript=decrypt_keyctl opção. A mesma senha é usada para destinos que possuem o mesmo identificador no campo keyfile . Na senha de inicialização para cada identificador é solicitado uma vez.

Um exemplo crypttab :

<target>      <source>         <keyfile>      <options>
part1_crypt   /dev/disk/...    crypt_disks    luks,keyscript=decrypt_keyctl
part2_crypt   /dev/disk/...    crypt_disks    luks,keyscript=decrypt_keyctl

Depois de atualizar seu cryptab , você também terá que atualizar o initramfs para aplicar as alterações. Use update-initramfs -u .

O leia-me completo de decrypt_keyctl está localizado em /usr/share/doc/cryptsetup/README.keyctl

Infelizmente, isso atualmente não funciona em sistemas Debian usando o init systemd devido a um bug (outros sistemas init não devem ser afetados). Debian página de manual do crypttab sugere como uma solução alternativa para use a opção initramfs para forçar o processamento no estágio initramfs de inicialização.

Distribuições que não fornecem script decrypt_keyctl :

Se decrypt_keyctrl não for fornecido pela sua distribuição, o dispositivo poderá ser desbloqueado usando um arquivo-chave no sistema de arquivos raiz criptografado. Isso quando o sistema de arquivos raiz pode ser desbloqueado e montado antes de qualquer outro dispositivo criptografado.

O LUKS suporta vários slots de chaves. Isso permite que você, alternativamente, desbloqueie o dispositivo usando a senha, se o arquivo de chave não estiver disponível / perdido.

1. Gere a chave com dados aleatórios e defina suas permissões para proprietário legíveis apenas para evitar vazamentos. Observe que o arquivo de chave precisa estar na partição raiz que é desbloqueada primeiro.

   dd if=/dev/urandom of=<path to key file> bs=1024 count=1
   chmod u=rw,g=,o= <path to key file>
   

2. Adicione a chave ao seu dispositivo LUKS

   cryptsetup luksAddKey <path to encrypted device> <path to key file>
   

3. Configure o crypttab para usar o arquivo de chaves. A primeira linha deve ser o dispositivo raiz, pois os dispositivos são desbloqueados na mesma ordem listada em crypttab . Use caminhos absolutos para arquivos de chaves.

   <target>      <source>         <keyfile>                  <options>
   root_crypt    /dev/disk/...    none                       luks
   part1_crypt   /dev/disk/...    <path to key file>         luks
   

Answer 2

Aqui está minha solução no debian, dado o bug mencionado acima por @sebasth.

Minha configuração é um pouco diferente. Eu tenho uma partição raiz criptografada e um monte de discos raid. Para mim, tive que adicionar uma opção initramfs ao crypttab:

<target>      <source>         <keyfile>      <options>
part1_crypt   /dev/disk/...    crypt_disks    plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
part2_crypt   /dev/disk/...    crypt_disks    plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs

Isso diz ao update-initramfs que eu quero que essas entradas do crypttab sejam montadas no initramfs. Eu verifiquei meu cryptab rodando

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

Note que meus discos raid são simples dm-crypt. Isso significava que eu não poderia usar o método luks keyfile que funciona ao redor do bug do systemcript. Para o dm-crypt simples, eu teria que armazenar a senha em texto simples.

Os discos criptografados devem ser montados antes que update-initramfs seja executado; caso contrário, isso causará erros. Tive que procurar as seguintes linhas quando meu initramfs foi criado:

update-initramfs -k -u -v | grep 'keyctl'

que mostrou os dois arquivos a seguir:

/bin/keyctl
cryptkeyctl

sendo adicionado ao initramfs.

Finalmente, eu tive que desabilitar o systemd manipulando meu crypttab, para lidar com o bug mencionado acima: systemd não suporta a opção keycript no crypttab. Para isso, adicionei a opção do kernel

GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"     

para / etc / default / grub e execute update-grub . O systemd agora ignora o crypttab e todas as partições criptografadas são carregadas no initramfs.

Como tenho uma partição raiz criptografada, o cryptroot não aparece para armazenar em cache minha chave. Isso significa que eu tenho que digitar minha senha duas vezes; um para a partição raiz e uma vez para o meu array raid.