User:Mxzcabel/drafts/dm-crypt/device (Português)

Esta página mostra como utilizar dm-crypt pela linha de comando para criptografar um sistema.

Preparação

Antes de usar cryptsetup, tenha certeza que o módulo de kernel dm_crypt está carregado.

Utilização do cryptsetup

cryptsetup(8) é uma ferramenta da linha de comando para o dm-crypt criar, acessar e gerenciar dispositivos criptografados. Ela foi expandida para suportar diferentes tipos de encriptação que dependem do mapeador de dispositivos e módulos criptografados (device-mapper and the cryptographic modules). A expansão mais notável foi o LUKS (Linux Unified Key Setup), que guarda todas as informações necessárias para o dm-crypt no próprio disco e abstrai a partição e gerenciamento de chaves com o objetivo de facilitar o uso. Dispositivos acessados via o mapeador de dispositivos são chamados de dispositivos de bloco, do inglês block devices. Para mais informações veja Criptografia de dados em repouso#Encriptação de dispositivo de bloco.

A ferramenta é usada da seguinte forma:

# cryptsetup ação opções dispositivo nome do dm

Existem opções e modo de encriptação padrão, que serão usados se nenhuma outra opção for especificada. Veja

$ cryptsetup --help

Todos os parâmetros, opções e ações padrão serão listados. A lista completa das opções pode ser encontrada na página man. Parâmetros podem ser opcionais ou não, dependendo do modo de encriptação e ação escolhidas, as seções a seguir possuem mais informação sobre elas. A encriptação do dispositivo de bloco é rápida, porém a velocidade de desencriptação é também algo a considerar-se, portanto deve-se escolher com cuidado o algoritmo que vai utilizar. Mudar a cifra criptográfica de um dispositivo de bloco já criptografado é difícil, por isso é importante verificar a performance do dm-crypt com diferentes parâmetros antes de instalar o sistema:

$ cryptsetup benchmark 

Lhe ajudará a decidir qual algoritmo e tamanho de chave você quer usar. Se algumas cifras AES se destacarem com uma grande diferença, estas provavelmente devem ter suporte de hardware na CPU.

Dica: Se desejar, você pode praticar a encriptação de dispositivos em uma máquina virtual enquanto ainda estiver aprendendo.

Senhas e chaves do cryptsetup

Um dispositivo de bloco criptografado é protegido por uma chave, da qual pode ser:

• uma frase secreta (passphrase), veja Segurança#Senhas.
• um segredo em um arquivo-chave (keyfile), veja #Arquivos-chave/keyfiles.

Ambos os tipos de chave possuem tamanhos padrões máximos: senhas podem ser até 512 caracteres e arquivos-chave até 8192 KiB.

Uma importante distinção do LUKS a se notar é que a chave é usada para desbloquear a chave mestre do dispositivo criptografado com LUKS, e a mesma pode mudar com acesso pelo root. Outros modos de encriptação não suportam mudança na chave depois de definida, pois não há a utilização de uma chave mestre na encriptação por estes modos. Veja Criptografia de dados em repouso#Encriptação de dispositivo de bloco para detalhes.

Opções de encriptação

Cryptsetup suporta diferentes modos de operações de encriptação com o uso pelo dm-crypt:

• --type luks para usar a versão padrão do LUKS (LUKS1 com cryptsetup < 2.1.0, LUKS2 com cryptsetup ≥ 2.1.0),
• --type luks1 para usar LUKS1, a versão anterior do LUKS,
• --type luks2 para usar LUKS2, a atual versão do LUKS que introduz extensões adicionais,
• --hw-opal-only para encriptação baseada em hardware em dispositivos com suporte ao padrão TCG OPAL. Veja sobre na página em inglês: Dispositivos de encriptação própria#Usando cryptsetup e cryptsetup(8) § SED (SELF ENCRYPTING DRIVE) OPAL EXTENSION.
• --hw-opal para encriptação de hardware OPAL com uma camada de criptografia em software com dm-crypt.
• --type plain para usar o modo plain do dm-crypt,
• --type loopaes para o modo legado loopaes,
• --type tcrypt para o modo de compatibilidade com TrueCrypt.
• --type bitlk para modo de compatibilidade com BitLocker. Veja cryptsetup(8) § BITLK (WINDOWS BITLOCKER COMPATIBLE) EXTENSION.

As opções básicas de criptografia para as cifras e hashes disponíveis podem ser usadas em todos os modos e dependem das funcionalidades de encriptação na infraestrutura do kernel. Todas as que foram carregadas e estão disponíveis para uso como opções no tempo de execução do kernel podem ser vistas com:

$ less /proc/crypto 

Dica: Se a lista é pequena, execute $ cryptsetup benchmark, do qual irá ativar a busca de módulos disponíveis.

Os tópicos a seguir introduzem as opções de encriptação para os modos luks, luks1, luks2 e plain. Note que o conteúdo disposto lista as opções utilizadas em seus respectivos artigos e não todas as disponíveis.

Opções de encriptação para o modo LUKS

A ação do cryptsetup para configurar um novo dispositivo do dm-crypt no modo de encriptação LUKS é luksFormat. Diferente do que o nome implica, não formata o dispositivo, mas configura o cabeçalho do dispositivo LUKS e criptografa a chave mestre com as opções criptografadas desejadas.

Ao fim de criar um novo container do LUKS, juntamente com o conjunto de parâmetros padrões listados pelo cryptsetup --help, simplesmente execute:

# cryptsetup luksFormat dispositivo

Desde a versão 2.4.0 de cryptsetup o comando acima é o equivalente a:

# cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase luksFormat dispositivo

Um comparativo das opções padrões com as especificações criptográficas mais bem discriminadas, acompanhado de comentários, foi feito nos exemplos da tabela abaixo:

Opções	Padrão do cryptsetup 2.1.0	Exemplo	Comentários
--cipher -c	aes-xts-plain64	aes-xts-plain64	A versão 1.6.0 mudou o padrão para uma cifra do AES no modo XTS (veja o item 5.16 do FAQ). Não é recomendado o uso da cifra padrão anterior --cipher aes-cbc-essiv devido a seus conhecidos problemas e ataques práticos contra eles.
--key-size -s	256 (512 for XTS)	512	Por padrão uma chave com tamanho de 512 bit é usada para cifras XTS. Note no entanto que XTS divide a chave no meio, resultando no uso do AES-256.
--hash -h	sha256	sha512	O algoritmo de Hash usado para derivação de chave. A versão 1.7.0 mudou o padrão de sha1 para sha256 "não por segurança [mas] principalmente para previnir problemas de compabilidade em sistemas onde SHA1 já estava [em] desuso "[1]. O antigo padrão do sha1 pode ainda ser usado por compatibilidade com versões mais velhas do cryptsetup desde que é considerada segura (veja o item 5.20).
--iter-time -i	2000	5000	Número de milisegundos a serem esperados com o processamento da senha PBKDF. A versão 1.7.0 mudou o padrão de 1000 para 2000 com o objetivo de "tentar manter a contagem da interação do PBKDF2 alta o bastante e também ainda aceitável pelos usuários."[2]. Esta opção é somente relevante para operações do LUKS que definem ou mudam senhas, tais como luksFormat ou luksAddKey. Especificando 0 como parâmetro seleciona o padrão compilado.
--use-urandom	--use-urandom	--use-random	Seleciona qual gerador de números randômicos vai ser utilizado. Note que a blocking pool, ou seja, o bloqueio para gerar mais entropia com /dev/random, foi removido. Portanto a flag --use-random é agora equivalente ao --use-urandom.
--verify-passphrase	Yes	-	Habilitado por padrão no Arch Linux para luksFormat e luksAddKey.
--sector-size	512 ou 4096 (dependente do dispositivo)	4096	Configura o tamanho do setor em bytes para o uso com encriptação de disco. O padrão é 4096 para dispositivos de bloco que anunciam a si mesmos como 4Kn ou 512e e 512 é para aqueles que anunciam a si próprios como 512n. Aumentar o tamanho do setor de 512 bytes para 4096 bytes pode melhorar desempenho na maioria dos dispositivos de armazenamentos modernos. Veja em Advanced Format#dm-crypt.

As propriedades das funcionalidades e opções do LUKS são descritas nas especificações do LUKS1 (pdf) e LUKS2 (pdf).

Dica: A apresentação dos desenvolvedores do projeto devconfcz2016 resume as motivações das principais atualizações das especificações do LUKS2. Veja também as principais mudanças do cryptsetup (v2) nas anotações publicadas da segunda versão.

Tempo de iteração

Retirado de cryptsetup FAQ§2.1 e §3.4:

O tempo de desbloqueio para um espaço de chave (keyslot) [...] é calculado ao configurar a senha. Por padrão é em torno de 1 segundo (2 segundos para LUKS2). [...]

A iteração da senha é baseada no tempo, e portanto o nível de segurança depende do poder da CPU no sistema do qual o container do LUKS foi criado. [...]

Se você configurar uma senha em uma máquina rápida e então desbloqueá-la em uma máquina lenta, o tempo para destravamento pode ser bem maior.

Levando isso em consideração, é então sempre melhor criar um container na máquina que será acessada com mais frequência.

Acesse os links e veja o resto das seções mencionadas acima para dicas de como ajustar corretamente o tempo de iteração, em caso de surgir a necessidade para tal.

Opções de encriptação para o modo plain

No modo plain do dm-crypt, não existe chave mestre no dispositivo, consequentemente não é necessário defini-lá. As opções de encriptação são empregadas diretamente para criar a mapeação entre o disco criptografado e um dispositivo nomeado. O mapeamento pode ser criado na partição ou no dispositivo todo. Nesse último caso não é necessário uma tabela de partição.

O mapeamento do modo plain com os parâmetros padrão do cryptsetup pode ser feito com:

# cryptsetup open --type plain opções  dispositivo dmnome

Ao executar o comando será solicitada a senha, que deve possuir uma entropia muito alta, e a opção --verify-passphrase pode ser usada, mas não é um padrão. Em geral é recomendável anotar as opções de encriptação usadas durante a criação, pois tais opções não são derivadas do dispositivo criptografado, ou de um arquivo-chave (keyfile) opcional, além disso o código que define as opções padrões pode mudar.

Logo abaixo há uma comparação dos parâmetros definidos como padrão com o exemplo em dm-crypt/Criptografando todo um sistema#dm-crypt plain:

Opção	Padrão do cryptsetup 2.7.0	Exemplo	Comentário
--hash -h	sha256	-	O hash é usado para criar a chave com a senha; não é usado em uma keyfile.
--cipher -c	aes-xts-plain64	aes-xts-plain64	As cifras consistem de três pares: geradores cifra-modo_de_opeação-IV. Veja Criptografia de dados em repouso#Cifras e modos de operação para uma explicação dessas configurações, e a documentação do DMCrypt para os modos disponíveis.
--key-size -s	256	512	O tamanho da chave (em bits). O tamanho dependerá da cifra utilizada e do chainmode em uso. O modo XTS requer o dobro de tamanho de chave do CBC.
--size -b	Tamanho real do disco alvo	- (utilizado o padrão)	Limita o tamanho máximo do dispositivo (em setores de 512-byte).
--offset -o	0	0	O quanto pular do inicio do disco alvo (setores de 512-byte) antes de começar o mapeamento
--skip -p	0	2048 (512B×2048=1MiB serão pulados)	O número de setores de 512-byte de dados criptografados a pular para o cálculo de vetor de inicialização (IV).
--key-file -d	A senha será usada por padrão	/dev/sdZ (ou, por exemplo, /boot/keyfile.enc)	O dispositivo ou arquivo a ser usado como chave. Veja #Keyfiles para mais detalhes.
--keyfile-offset	0	0	Distância do início do arquivo onde a chave começa (em bytes). Esta opção é suportada a partir da versão 1.6.7 do cryptsetup.
--keyfile-size -l	8192kB	- (utilizado o padrão)	Limita os bytes lidos da keyfile. Esta opção é suportada a partir da versão 1.6.7 do cryptsetup.
--sector-size	512	4096	Configura o tamanho do setor em bytes com o uso de encriptação no disco. O padrão é 512 para tudo exceto em dispositivos de bloco 4kn. AUmentar o tamanho do setor de 512 bytes para 4096 bytes pode proporcionar melhor desempenho na maior parte dos dispositivos de armazenamento modernos. Veja a página em inglẽs em Advanced Format#dm-crypt.

Ao usar o dispositivo /dev/sdX, o exemplo da coluna acima da direita resulta em:

# cryptsetup open --type plain --cipher=aes-xts-plain64 --offset=0 --skip=2048 --key-file=/dev/sdZ --key-size=512 --sector-size 4096 /dev/sdX enc

Atenção: Diferentemente de criptografar com LUKS, o comando acima deve ser executado de maneira completa, independentemente de quais sejam as necessidades de mapeamento a serem restabelecidas, então é importante lembrar detalhes sobre a cifra, hash e de arquivo-chave (keyfile). Não dependa do padrão do cryptsetup, pois tais parâmetros mudam entre versões.

Nós podemos checar se o mapeamento foi feito com:

# fdisk -l

O dispositivo mapeado deve aparecer como /dev/mapper/enc.

Criptografando dispositivos com cryptsetup

Esta seção mostra como empregar as opções para criar novos dispositivos de bloco criptografados e acessá-los manualmente.

Atenção: O suporte de LUKS2 para o GRUB é limitado; veja GRUB (Português)#/boot criptografado para detalhes. Use LUKS2 com PBKDF2 (crypsetup luksFormat --pbkdf pbkdf2) para partições que o GRUB precisará abrir.

Criptografando dispositivos com o modo LUKS

Formatando partições LUKS

Para configurar uma partição criptografada LUKS, execute:

# cryptsetup luksFormat dispositivo

Lhe será solicitado uma senha e também a verificação desta.

Veja #Opções de encriptação para o modo LUKS para opções da linha de comando.

Você pode checar os resultados com:

# cryptsetup luksDump dispositivo

Note que a saída vai mostrar a informação do cabeçalho da cifra criptográfica, como também as chaves em uso da partição LUKS.

O seguinte exemplo criará uma partição raiz criptografada no /dev/sda1 usando a cifra AES padrão no modo XTS com uma efetiva encriptação de 256-bit

# cryptsetup luksFormat -s 512 /dev/sda1

Usando LUKS para formatar partições com um arquivo-chave

Na criação de uma partição criptografada LUKS, uma keyfile pode ser associada usando:

# cryptsetup luksFormat dispositivo /caminho/para/keyfile

Veja #Arquivos-chave/keyfiles para instruções de como gerar e gerenciar keyfiles.

Abrindo/Mapeando partições LUKS com o mapeador de dispositivos

Uma vez que os containers LUKS foram criados, eles podem ser abertos.

Para abrir um container LUKS voce precisa definir o nome do novo dispositivo mapeado. Isto alerta o kernel que dispositivo está criptografado e deve ser acessado através do LUKS usando o /dev/mapper/dm_nome para nao sobrescrever os dados criptografados. Para se proteger deste tipo de acidente, leia sobre como fazer backup do cabeçalho criptografado depois de terminar a configuração.

Para abrir um container LUKS criptografado execute:

# cryptsetup open dispositivo dm_nome

Será solicitada a senha para abrir o container. Normalmente o nome do dispositivo mapeado é uma breve descrição da função do container mapeado. Por exemplo, o comando a seguir abre uma partição root /dev/sda1 com LUKS, mapeia com o mapeador de dispositivos (device mapper) e nomeia-a como root:

# cryptsetup open /dev/sda1 root

Uma vez aberto, a nomeação da partição root é definida como /dev/mapper/root, ao invés de ser o nome da partição (como por exemplo /dev/sda1).

Para configurar um LVM em cima da camada de criptografia, o arquivo do dispositivo definido para o grupo de volume descriptografado será algo semelhante a /dev/mapper/root, ao invés de /dev/sda1. O LVM então fornecerá nomes adicionais para todos os volumes lógicos criados, como por exemplo /dev/lvmpool/root e /dev/lvmpool/swap.

Para escrever dados criptografados dentro da partição a mesma deve ser acessada pelo nome do dispositivo mapeado. O primeiro passo para o acesso tipicamente será ao criar um sistema de arquivos. Por exemplo:

# mkfs.ext4 /dev/mapper/root

O dispositivo /dev/mapper/root então pode ser montado como qualquer partição.

Para fechar o container do LUKS, desmonte a partição e execute:

# cryptsetup close root

Usando TPM para armazenar chaves

Veja a página em inglês: Trusted Platform Module#LUKS encryption.

Criptografando dispositivos com o modo plain

Ambas as operações de criação e do acesso subsequente ao dm-crypt criptografado no modo plain não precisam mais do que o uso da ação cryptsetup open com os parâmetros corretos. A seguir é mostrado dois exemplos de dispositivos que não são root, mas com a adição de um truque para empilhar ambos (ou seja, o segundo é criado dentro do primeiro). Obviamente, colocar mais camadas de criptografia dobra o uso de recursos. O caso de uso ilustrado abaixo é somente um outro exemplo da utilização das opções de cifra.

O primeiro mapeamento é criado com as opções padrões do modo plain do cryptsetup, como descrito na coluna esquerda da tabela acima.

# cryptsetup --type plain -v open /dev/sdxY plain1

WARNING: Using default options for cipher (aes-xts-plain64, key size 256 bits) that could be incompatible with older versions.
WARNING: Using default options for hash (sha256) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/sdxY:
Command successful.

A mensagem de forma traduzida:

AVISO: Usar opções padrões para a cifra (aes-xts-plain64, chave com tamanho 256 bits) que pode ser incompatível com versões mais antigass.
AVISO: Usar opções padrões para o hash (sha256) que pode ser incompatível com versões antigas.
Para o modo plain, sempre use as opções --cipher, --key-size e se nenhuma keyfile for usada, então inclua também --hash.
Digite a senha para /dev/sdxY:
Comando bem sucedido.

Agora por dentro do bloco nós podemos adicionar um segundo dispositivo de bloco, do qual usará parâmetros diferentes de criptografia e (opcionalmente) um offset. Crie um sistema de arquivos e monte-o.

# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10  open /dev/mapper/plain1 plain2

Enter passphrase for /dev/mapper/plain1:

# lsblk -p

 NAME
 /dev/sda
 ├─/dev/sdxY
 │ └─/dev/mapper/plain1
 │   └─/dev/mapper/plain2
 ...

# mkfs -t ext2 /dev/mapper/plain2
# mount -t ext2 /dev/mapper/plain2 /mnt
# echo "Dispositivo empilhado. Uma senha para cada macaco no seu galho" > /mnt/empilhado.txt

Feche o dispositivo para checar se o acesso funciona:

# cryptsetup close plain2
# cryptsetup close plain1

Primeiro, vamos tentar abrir o sistema de arquivos diretamente:

# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sdxY plain2

# mount -t ext2 /dev/mapper/plain2 /mnt

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/plain2, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

A mensagem de forma traduzida:

montagem: /mnt/: tipo errado de fs (sistema de arquivos), opção ruim, superbloco ruim em /dev/mappper/plain2, codepage ou programa ajudante em falta, ou outro erro.
       dmesg(1) talvez tenha mais informações após a falha da chamada de sistema da montagem.

Por que não deu certo? O ponto de início de "plain2" (10) ainda está criptografado com a cifra do "plain1". Ele só pode ser acessado através do mapeamento de dispositivos empilhados. O erro, no entanto, é arbitrário, então tentar acessar com uma senha incorreta ou com opções erradas, irá resultar no mesmo. Para o modo plain do dm-crypt, a ação open não apresentará erros por si só.

Tentando novamente, mas agora na ordem correta:

# cryptsetup close plain2    # dispositivo mapeado disfuncional da tentativa anterior

# cryptsetup --type plain open /dev/sdxY plain1

WARNING: Using default options for cipher (aes-xts-plain64, key size 256 bits) that could be incompatible with older versions.
WARNING: Using default options for hash (sha256) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/mapper/sdxY:

# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2

Enter passphrase for /dev/mapper/plain1:

# mount /dev/mapper/plain2 /mnt && cat /mnt/empilhado.txt

Dispositivo empilhado. Uma senha para cada macaco no seu galho.

dm-crypt irá cuidar da criptografia empilhada com alguns modos misturados também. Por exemplo o modo LUKS poderia ser empilhado no dispositivo mapeado "plain1". Seu cabeçalho deve estar criptografado dentro do "plain1".

A opção --shared está somente disponível para o modo plain. Com esta um dispositivo pode ser segmentado em diferentes dispositivos mapeados sem sobreposição. Isto será exemplificado a seguir, usando um modo de cifra compatível com loopaes para o "plain2":

# cryptsetup --type plain --offset 0 --size 1000 open /dev/sdxY plain1

WARNING: Using default options for cipher (aes-xts-plain64, key size 256 bits) that could be incompatible with older versions.
WARNING: Using default options for hash (sha256) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/sdxY:

# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sdxY plain2

WARNING: Using default options for cipher (aes-xts-plain64, key size 256 bits) that could be incompatible with older versions.
WARNING: Using default options for hash (sha256) that could be incompatible with older versions.
For plain mode, always use options --cipher, --key-size and if no keyfile is used, then also --hash.
Enter passphrase for /dev/sdxY:

# lsblk -p

NAME
dev/sdxY
├─/dev/sdxY
│ ├─/dev/mapper/plain1
│ └─/dev/mapper/plain2
...

Como a árvore de dispositivos mostra, ambos residem no mesmo nível, elas não estão empilhadas e "plain2" pode ser aberto individualmente.

Ações específicas do cryptsetup para o LUKS

Gerenciamento de chaves

É possível definir chaves adicionais para um container LUKS. Permitindo a criação do acesso a chaves para backup de dados seguro: Na prática conhecida como key escrow, uma chave é usada para utilização diária, outra guardada para ganhar acesso ao container caso a senha seja esquecida ou a keyfile foi perdida/danificada. Um diferente espaço de chave também pode ser usado para garantir acesso de um container para um usuário ao adicionar uma segunda chave e mais tarde removê-la.

Uma vez que o container criptografado foi criado, o espaço de chave (key slot) 0 é criado (se nenhum outro foi definido manualmente). Espaços de chave adicionais são numerados de 1 a 7. Os espaços de chave utilizados podem ser vistos com:

# cryptsetup luksDump /dev/dispositivo

Onde dispositivo é o dispositivo de bloco que contém o cabeçalho do LUKS. Este e todos os seguintes comandos nesta seção funcionam em backups de cabeçalho também.

Adicionando chaves do LUKS

Para adicionar novos slots de chave use a ação luksAddKey. Por segurança, será sempre solicitada, mesmo que o dispositivo já esteja destrancado, uma chave preexistente válida ("any existing passphrase") antes que a nova senha seja solicitada:

# cryptsetup luksAddKey /dev/dispositivo [/caminho/para/keyfile_adicional]

Enter any existing passphrase:
Enter new passphrase for key slot:
Verify passphrase: 

Se /caminho/para/keyfile_adicional for dado, cryptsetup adicionará a keyfile_adicional. Se não, o comando pedirá uma nova senha. Para autorizar a ação com uma keyfile existente, a opção --key-file ou -d seguida pela "antiga" keyfile irá tentar destrancar o dispositivo passando por todos os espaços de chave (keyslots) com arquivo-chaves (keyfile) registrados:

# cryptsetup luksAddKey /dev/dispositivo [/caminho/para/keyfile_adicional] -d /caminho/para/keyfile

Se é desejado usar múltiplas chaves e mudar ou remover elas, a opção --key-slot ou -S pode ser usada para especificar o slot:

# cryptsetup luksAddKey /dev/dispositivo -S 6

AVISO: O parâmetro --key-slot é usado para um novo número de keyslot.
Enter any existing passphrase:
Enter new passphrase for key slot: 
Verify passphrase:

# cryptsetup luksDump /dev/device

...
Keyslots: 
...
6: luks2
      Key: 	     512 bits
      Priority:  normal
...

Dica: Com LUKS2 é possível designar prioridades para keyslots individuais, veja cryptsetup-config(8). Por exemplo, se o slot acima 6 pretende abrir um dispositivo ao inicializar o sistema, execute cryptsetup config --priority prefer --key-slot 6 /dev/device como root.

Para mostrar uma ação associada neste exemplo, nós decidimos aproveitar para mudar a chave:

# cryptsetup luksChangeKey /dev/dispositivo -S 6

Enter passphrase to be changed: 
Enter new passphrase:
Verify passphrase:

Antes de removê-la.

Removendo chaves do LUKS

Existem três diferentes ações para remover chaves do cabeçalho:

• luksRemoveKey é usado para remover uma chave por especificar sua senha/kefile.
• luksKillSlot pode ser usado para remover uma chave específica (usando outra chave). Isto é extremamente útil se você esqueceu uma senha, perdeu uma keyfile ou não tem acesso a ela.
• luksErase é usado para rapidamente remover todas as chaves ativas.

Atenção:

• Todas as ações acima podem ser usadas para apagar irrevogavelmente a última chave ativa de um dispositivo criptografado!
• O comando erase não irá solicitar por uma senha válida! Isto não irá apagar o cabeçalho do LUKS, mas sim todos os espaços de chave (keyslots) de uma vez só, então você não conseguirá mais acessar a menos que você tenha um backup válido do cabeçalho do LUKS.
• Ao usar o comando erase em uma partição criptografada por hardware OPAL, o cabeçalho do LUKS será apagado juntamente com todo o conjunto de travamento criptografado pelo OPAL. Diferentemente de criptografia por software, esta ação torna o dispositivo irrecuperável, mesmo que seja usado um backup de um cabeçalho LUKS válido.

Considerando os avisos acima, é essencial que a chave que desejamos manter seja válida. Uma forma fácil de checar é abrir o dispositivo com a opção -v, do qual irá especificar o espaço que a chave ocupa:

# cryptsetup --test-passphrase -v open /dev/dispositivo 

No usable token is available.
Enter passphrase for /dev/dispositivo: 
Key slot 1 unlocked.
Command successful.

Agora sim podemos remover a chave adicionada na subseção anterior ao usar a devida senha:

# cryptsetup luksRemoveKey /dev/dispositivo

Enter LUKS passphrase to be deleted:

Se for usada a mesma senha para dois espaços, a primeira ocorrência de espaço que tiver a senha vai ser apagado. Somente executando novamente a segunda vai ser apagada.

Alternativamente, é possível especificar o espaço de chave:

# cryptsetup luksKillSlot /dev/dispositivo 6

Enter any remaining LUKS passphrase:

Note que em ambos os casos nenhuma confirmação é necessária.

Reiterando o que foi falado acima: Se a mesma senha foi usada para o espaço 1 e 6, ambos os espaços com a senha devem ter sido apagados agora.

Backup e restauração

Se o cabeçalho de um container criptografado com LUKS é destruído, você não vai conseguir descriptografar seus dados. Tão problemático quanto esquecer a senha ou modificar/perder a keyfile. Danos podem acontecer por sua própria responsabilidade ao particionar novamente o disco depois ou por programas de terceiros que interpretam errado a tabela de partições. Então, ter um backup do cabeçalho e guardá-lo em outro lugar pode ser uma boa ideia.

Nota: Se uma das senhas das partições criptografadas com LUKS for revelada, você deve retirá-la em todas as cópias do cabeçalho, até mesmo estes que você fez o backup. De outro modo, uma cópia do cabeçalho criptografado que a usa pode ser utilizado para determinar a chave mestre que pode ser usada para abrir o container relacionado (até mesmo o seu atual, não somente o do backup). Se a chave mestre for descoberta, você vai ter que re-criptografar todo seu container. Veja o PAQ do LUKS para mais detalhes.

Backup usando o cryptsetup

A ação luksHeaderBackup do cryptsetup faz o backup do cabeçalho LUKS e os espaços de chave:

# cryptsetup luksHeaderBackup /dev/dispositivo --header-backup-file /mnt/backup/arquivo.img

Onde dispositivo é a partição que contém o volume LUKS.

Você poderá também criar um backup do cabeçalho em texto puro dentro de um tmpfs e criptografá-lo, com por exemplo: GPG, antes de escrevê-lo em um armazenamento persistente:

# mount --mkdir -t tmpfs -o noswap tmpfs /root/tmp/
# cryptsetup luksHeaderBackup /dev/dispositivo --header-backup-file /root/tmp/arquivo.img
# gpg --recipient User ID --encrypt /root/tmp/arquivo.img 
# cp /root/tmp/arquivo.img.gpg /mnt/backup/
# umount /root/tmp

Dica: A opção noswap garante que o sistema de arquivos não será colocado em swap no disco.

Restauração usando o cryptsetup

Atenção: Restaurar o cabeçalho errado ou restaurar para uma partição não criptografada pode resultar em perda de dados! A ação não pode fazer uma verificação se o cabeçalho é o correto para dado dispositivo.

Para evitar a restauração de um cabeçalho errado, você pode antecipadamente verificar se funciona ao usá-lo como um cabeçalho remoto, ou seja, com a opção --header:

# cryptsetup -v --header /mnt/backup/arquivo.img open /dev/dispositivo test

No usable token is available.
Enter passphrase for /dev/dispositivo:
Key slot 0 unlocked.
Command successful.

# mount /dev/mapper/test /mnt/test && ls /mnt/test 
# umount /mnt/test 
# cryptsetup close test 

Agora que a verificação foi bem sucedida, a restauração pode ser feita:

# cryptsetup luksHeaderRestore /dev/dispositivo --header-backup-file ./mnt/backup/arquivo.img

Todos os espaços de chave (keyslots) foram sobrescrevidos; agora, logo após terminada a ação do comando, somente os espaços de chave ativos do arquivo de backup devem estar disponíveis.

Re-criptografando dispositivos

A ação reencrypt do cryptsetup permite re-criptografar dispositivos LUKS. Para dispositivos em LUKS2, a re-criptografia talvez possa ser feita online, isto é, com o dispositivo montado. O mesmo possui suporte para múltiplos processos de re-criptografia em paralelo e é resiliente a falhas de sistema. Uma re-criptografia de dispositivos em LUKS1 só pode ser feita offline (dispositivo desmontado), com apenas um único processo e é menos resiliente.

Veja cryptsetup-reencrypt(8) para conhecer os modos de operação e as opções.

É possível mudar #Opções de encriptação para o modo LUKS. Isto também pode ser usado para converter um sistema de arquivos não encriptado preexistente para um criptografado com LUKS, ou para permanentemente remover a criptografia de um dispositivo (usando a opção --decrypt); veja a página em inglês Removendo a criptografia do sistema para mais informações. Uma re-criptografia também é viável para cabeçalhos LUKS desanexados, mas tenha em mente o aviso anterior sobre a opção --header. Uma re-criptografia para outros modos sem ser o LUKS (por exemplo, modo plain) não é suportado.

Criptografar novamente pode ser usado com a função de preservar a segurança dos dados, logo após que uma senha ou uma keyfile foi comprometida e não há como ter certeza se alguma cópia do cabeçalho foi adquirida. Por exemplo, se houve somente o conhecimento de alguma senha por alguém sem autorização (shoulder-surfed), mas nenhum acesso físico/lógico ocorreu, então alterar a respectiva senha/chave deverá ser o bastante (#Gerenciamento de chaves).

Atenção: Sempre tenha um backup adequado e de confiança disponível e verifique duas vezes as opções especificadas antes de usar a ferramenta!

As demonstrações a seguir são exemplos de como criptografar uma partição com um sistema de arquivos não encriptado anteriormente, como também sobre como re-criptografar um dispositivo LUKS já existente.

Criptografando um sistema de arquivos preexistente não encriptado

Dica: Se você está tentando criptografar uma partição root preexistente, talvez seja melhor criar uma partição boot separada sem criptografia, do qual será montada em /boot (veja Dm-crypt/Encrypting an entire system#Preparing the boot partition). Não é algo estritamente necessário, mas possui algumas vantagens:

• Se /boot estiver localizado dentro de uma partição root criptografada, o sistema pedirá a senha duas vezes quando a máquina for ligada. A primeira vez acontecerá quando o gerenciador de boot tentar ler os arquivos dentro da partição criptografa /boot. A segunda vez é quando o kernel tentar montar a partição criptografada [4]. Provavelmente este não é o comportamento que você deseja e o mesmo pode ser evitado ao separar a partição de boot e não criptografá-la.
• Alguns aplicativos de restauração de sistema (por exemplo, timeshift) não irão funcionar se /boot estiver dentro de uma partição criptografada [5].

Em resumo, crie uma partição com um tamanho de pelo menos 260MiB, se necessário. Veja como em Particionamento#/boot.

Um cabeçalho do LUKS sempre é armazenado no início do dispositivo. Já que usualmente um sistema de arquivos preexistente usa todos os setores da partição, o primeiro passo é diminuir o espaço alocado para o cabeçalho do LUKS.

O cabeçalho padrão do LUKS2 precisa de 16MiB. Se o sistema de arquivos atual ocupa todo o espaço disponível, nós teremos que diminuí-lo para ao menos este tamanho. Para diminuir um sistema de arquivos ext4 preexistente em /dev/sdaxY para o atual menor espaço possível:

# umount /mnt

# e2fsck -f /dev/sdxY

e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
...
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks

# resize2fs -p -M /dev/sdxY

resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/sdaxY to 26347 (4k) blocks.
The filesystem on /dev/sdaX is now 26347 (4k) blocks long.

Dica: Diminuir para o mínimo de espaço com -M pode demorar um bom tempo. Você talvez prefira calcular um tamanho de somente 32MiB menor que o tamanho atual ao invés de usar -M.

Atenção: O sistema de arquivos deve ser encolhido ao passo que o dispositivo subjacente (por exemplo, uma partição) se mantenha com o tamanho original. Algumas ferramentas gráficas (por exemplo, Gparted) talvez redimensionem tanto o sistema de arquivos quanto a partição, e com isso pode ocorrer perda de dados depois da encriptação.

Agora vamos criptografá-la. Ao usar a cifra padrão não há necessidade de especificá-la:

# cryptsetup reencrypt --encrypt --reduce-device-size 32M /dev/sdxY

WARNING!
========
This will overwrite data on LUKS2-temp-12345678-9012-3456-7890-123456789012.new irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for LUKS2-temp-12345678-9012-3456-7890-123456789012.new:
Verify passphrase:

O aviso traduzido seria:

ATENÇÃO!
========
Isto irá sobrescrever os dados em LUKS2-temp-12345678-9012-3456-7890-123456789012.new irrevogavelmente.

Tem certeza? (Digite 'yes' em letras maiúsculas): YES
Digite a passphrase para LUKS2-temp-12345678-9012-3456-7890-123456789012.new:
Verifique a passphrase:

Depois que acabar, toda a partição /dev/sdxY estará criptografada, não somente o espaço que o sistema de arquivos foi diminuído. Para finalizar, estenda o sistema de arquivos original ext4 para ocupar todo o espaço disponível novamente, do qual agora reside a partição criptografa:

# cryptsetup open /dev/sdxY recrypt

Enter passphrase for /dev/sdxY:
...

# resize2fs /dev/mapper/recrypt

resize2fs 1.43-WIP (18-May-2015)
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.

# mount /dev/mapper/recrypt /mnt

O sistema de arquivos agora está pronto para uso. Você talvez possa querer agora adicioná-lo no seu crypttab.

Dica: Se você somente criptografou sua partição root, talvez você precise realizar alguns ajustes pós-encriptação.

1. Configure mkinitcpio e os parâmetros de kernel. Veja na página em inglês dm-crypt/System configuration#Unlocking in early userspace.
2. Atualizar a entrada de / em fstab para o uso do especificador de volume do dispositivo destravado (por exemplo, UUID).

Re-criptografando uma partição LUKS preexistente

Neste exemplo um dispositivo LUKS que já existe é criptografado novamente.

Atenção: Nunca re-criptografe sem um 'backup adequado e de confiança! Se você estiver re-criptografando por conta de um vazamento de senha (por exemplo, após ser vigiado pela tática do shoulder-surfing), use luksChangeKey antes de re-criptografar e/ou de criar um backup.

Para encriptar novamente um dispositivo juntamente com as opções de encriptação utilizadas atualmente, tais opções não precisam ser especificadas:

# cryptsetup reencrypt /dev/sdxY

Chaves existentes permanecem ao re-criptografar um dispositivo com uma outra cifra e/ou hash diferente.

Outro caso de uso para a re-criptografia seria para aqueles dispositivos LUKS que não possuem as atuais opções de encriptação. Nestes casos, você deve especificar as novas opções desejadas. Note que um cabeçalho LUKS2 permite encriptação por espaço de chave individual, portanto a re-criptografia será aplicada apenas para o segmento do dado.

A habilidade de mudar o cabeçalho do LUKS talvez seja limitada pelo tamanho. Por exemplo, se o dispositivo era inicialmente criptografado com LUKS1 usando o modo CBC de cifra e 128 bit de tamanho de chave, o cabeçalho do LUKS será metade do tamanho dos já mencionados 4096 setores:

# cryptsetup luksDump /dev/sdxY | grep -e "mode" -e "Payload" -e "MK bits"

Cipher mode:   	cbc-essiv:sha256
Payload offset:	2048
MK bits:       	128

Para atualizar as opções de encriptação de tal dispositivo, considere primeiramente converter o cabeçalho para LUKS2 e só assim re-criptografar. Se a conversão falhar por conta de um tamanho de cabeçalho inadequado, você provavelmente precisará criptografar novamente com a opção --reduce-device-size, da qual disponibilizará mais espaço para o cabeçalho maior. Porém, este processo deve ser feito antes de re-criptografar com as novas opções de encriptação almejadas. Da mesma forma, mantenha em mente que ambos os métodos possuem riscos, que são inerentes de seus processos: tanto para o cabeçalho durante a conversão, quanto para os dados do sistema de arquivos se os mesmos estiverem em uso e você precisar liberar espaço.

Convertendo de LUKS1 para LUKS2 e revertendo

A ferramenta do cryptsetup possui a ação convert para conversão de cabeçalhos no formato LUKS1 e LUKS2. É aconselhável criar um backup do cabeçalho antes de fazer a conversão. Neste processo o argumento --type é um requerimento.

Migração do LUKS1 para LUKS2:

# crytpsetup convert --type luks2 /dev/sdxY

Nota: O tamanho do cabeçalho do LUKS será de 16MiB ao invés de 2MiB.

Para retroceder ao LUKS1 (por exemplo, para inicializar o sistema pelo GRUB com criptografia em /boot):

# cryptsetup convert --type luks1  /dev/sdxY

Nota: Conversão do LUKS2 para LUKS1 não é sempre possível. Você talvez presencie o seguinte erro:

Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible. 

De forma traduzida:

Não é possível converter para o formato LUKS1 - espaço de chave 0 não é compatível com LUKS1.

Se o container estiver usando Argon2, então é preciso converter para PBKDF2, de forma que seja compatível com LUKS1.

# cryptsetup luksConvertKey --pbkdf2 /dev/sdxY

Redimensionando os dispositivos criptografados

Se um dispositivo de armazenamento criptografado com dm-crypt está sendo clonado (com uma ferramenta como o dd) para outro dispositivo maior, ou se a partição estiver sendo expandida ou encolhida, o sistema de arquivos subjacente precisará ser redimensionado. Para dispositivos baseados em LUKS, este é o único passao necessário, pois LUKS não armazena nenhuma informação sobre o tamanho da partição e usa o tamanho total como padrão, ou seja, quando nenhum parâmetro --size é passado. Para este fim, siga os passos habituais necessários na página em inglês: resize a partition. Um exemplo para o dispositivo LUKS criptografado /dev/sdX2 que contém um sistema de arquivos ext4 que precisa ser expandido seria:

Primeiramente, redimensione a partição subjacente com Parted ou fdisk. Um detalhe importante: ao encolher uma partição, isto precisa ser feito por último. Agora, abra o seu dispositivo e redimensione o sistema de arquivos:

Atenção: Considere fazer um backup dos seus dados antes de redimensionar e não monte o respectivo sistema de arquivos.

# cryptsetup luksOpen /dev/sdX2 sdX2
# e2fsck /dev/mapper/sdX2
# resize2fs /dev/mapper/sdX2  # Usa todo o espaço disponível da partição LUKS alargada.

Depois de montar o dispositivo LUKS mapeado que aumentou de tamanho, ele pode ser usado da mesma forma como antes.

# mount /dev/mapper/sdX2 /mnt/sdX2_expandido

Nota: cryptsetup-resize é um comando para redimensionar uma partição mapeada ativamente e normalmente não é preciso usar ao redimensionar um sistema de arquivos ext2/3/4.

LVM em LUKS

Veja a página em inglês: Resizing LVM on LUKS.

Sistema de arquivos de loopback

Assuma que um sistema de arquivos de loopback criptografado está no arquivo grande_segredo, ligado ao /dev/loop0, mapeado como segredo e montado em /mnt/segredo, como no exemplo presente em dm-crypt/Criptografando um sistema de arquivos não raiz#Dispositivo de loop.

Se o container está mapeado e/ou montado, o desmonte e/ou feche:

# umount /mnt/segredo
# cryptsetup close segredo
# losetup -d /dev/loop0

Depois, expanda o arquivo do container com o tamanho dos dados que você deseja adicionar. Neste exemplo, o arquivo será expandido em 1MiB × 1024, que é 1GiB.

Atenção: Tenha a absoluta certeza e confirme que você está usando as opções oflag=append conv=notrunc, senão você irá sobrescrever o arquivo ao invés de adicionar os dados ao final dele. Fazer um backup antes desse passo é fortemente recomendado.

# dd if=/dev/urandom of=/grande_segredo bs=1M count=1024 iflag=fullblock oflag=append conv=notrunc status=progress

Agora mapeie o container para o dispositivo de loop:

# losetup /dev/loop0 grande_segredo
# cryptsetup open /dev/loop0 segredo

Depois disso, redimensione a parte criptografada do container para o novo tamanho máximo do arquivo container:

# cryptsetup resize segredo

Finalmente, cheque o sistema de arquivos e, se está ok, o redimensione (exemplo para ext2/3/4):

# e2fsck -f /dev/mapper/segredo
# resize2fs /dev/mapper/segredo

É possível, então, montar o container novamente:

# mount /dev/mapper/segredo /mnt/segredo

Dispositivo com integridade protegida

Se o dispositivo foi formatado com suporte a integridade (por exemplo, --integrity hmac-sha256) e o dispositivo de bloco não volátil foi encolhido, então ele não poderá ser aberto. O resultado é o seguinte erro: device-mapper: reload ioctl on failed: Invalid argument, ou de forma traduzida: mapeador-dispositivos: recarregar ioctl falhou: Argumento inválido.

Para consertar esse problema sem ter que limpar os dados do dispositivo novamente, ele pode ser formatado com a chave mestre criada anteriormente (mantendo assim as tags por setor válidas).

# cryptsetup luksDump /dev/sdX2 --dump-master-key --master-key-file=/tmp/chave-mestre-em-tmpfs.key
# cryptsetup luksFormat /dev/sdX2 --type luks2 --integrity hmac-sha256 --master-key-file=/tmp/chave-mestre-em-tmpfs.key --integrity-no-wipe
# rm /tmp/chave-mestre-em-tmpfs.key

Arquivos-chave/keyfiles

Nota: Esta seção descreve o uso de um arquivo-chave em texto puro. Se deseja criptografar o arquivo para conseguir autentificação de dois fatores, veja a página em inglês: Using GPG, LUKS or OpenSSL encrypted keyfiles para saber mais detalhes. De toda forma, considere ler esta seção.

O que é um arquivo-chave/keyfile?

Um arquivo-chave, também denominado como "keyfile", é um arquivo cujo os dados são usados como senha para abrir um volume criptografado. Significa que se tal arquivo é perdido ou modificado, destrancar e abrir o volume pode não ser mais possível.

Dica: Adicione uma senha em texto simples (passphrase) além da keyfile para evitar a situação citada acima.

Por que usar um arquivo-chave/keyfile?

Existem muitos tipos de keyfiles. Cada tipo possui suas vantagens e desvantagens, dos quais estão resumidos abaixo:

Tipos de arquivo-chave

Texto simples (passphrase)

Este é um arquivo-chave que contém uma senha em texto simples, também denominado como "passphrase". O benefício deste tipo de arquivo-chave é que se caso o arquivo for perdido, o dado contido nele é conhecido e foi facilmente memorizado pelo proprietário do volume criptografado. Todavia, isto não trás nenhuma segurança extra ao digitar e confirmar a senha durante o começo da inicialização do sistema.

Exemplo:

correct horse battey staple

Também poderia ser:

correto cavalo bateria grampo

Nota: A keyfile que contém a senha não deve ter quebra de linha, ou seja, uma newline dentro dela. Uma opção é criá-la usando:

# printf '%s' 'sua_senha' | install -m 0600 /dev/stdin /etc/cryptsetup-keys.d/arquivo-chave.key

Se o arquivo contém caracteres especiais, como aspas ou barras invertidas, ao invés de espaçar estes caracteres, é recomendado simplesmente editar o arquivo-chave, digitando diretamente ou copiando e colando a senha, e então remover a quebra de linha com um comando útil em perl de uma linha:

# perl -pi -e 'chomp if eof' /etc/cryptsetup-keys.d/arquivo-chave.key

Caracteres aleatórios

Este tipo de keyfile contém um bloco de texto randômico. O benefício deste tipo de arquivo-chave é que é muito mais resistente a ataques de dicionário do que uma senha em texto simples. Um ponto forte a considerar em situações em que há a possibilidade de usá-la, é o comprimento de dado criado. Por não ser uma string feita para ser memorizada por uma pessoa como senha, é algo trivial criar arquivos contendo milhares de caractetes aleatórios como uma chave. A desvantagem é que se este arquivo é perdido ou modificado, muito provavelmente o acesso ao volume criptografado será igualmente perdido, se caso também não houver uma senha de backup.

Um arquivo-chave com texto randômico pode usar qualquer tipo de conjunto de caracteres, porém manter a portabilidade para letras em ASCII e em números pode facilitar as coisas; como em ocasiões que o layout do teclado ou o suporte para Unicode é precário, como ao digitar uma senha de emergência no estágio de destravamento na inicialização do LUKS, ou ao mensurar arquivos-chaves com utilitários de POSIX antigos com Unicode primitivo. Nestes casos, você pode gerar uma string desta forma:

$ tr -dc [:alnum:]' </dev/urandom | head -c64

Exemplo: rTCBW6j1dI2aYC5KcD6Ar38rBGN2DkWyang3RT7pdMGpdf1kRuMXi8EBHKu0BJ8X

Alternativamente, um arquivo-chave de caracteres aleatórios em Unicode (UTF-8) pode se aparentar de tal maneira:

Exemplo: W‰[�5ODó?Oéµ»9���…¬hjT}­�›DЧíŽ�uLÝæ•�Ýœ�§aþ�óx±)Ñ)l­éeð��•ú=èe

Binário

É um arquivo binário que foi definido como keyfile. Quando identificar candidatos para uma keyfile, é recomendado que escolha fotos relativamente estáticas como fotos, músicas, vídeos. A vantagem, esses arquivos tem outras funções que dificultam a sua identificação como keyfile. Ao invês de ter um arquivo de texto com uma grande quantidade de texto randômico, a keyfile vai ser considerada como um arquivo de mídia normal. A desvantagem, se o arquivo for perdido ou mudado, provavelmente não será mais possível acessar o volume criptografado sem outra chave. Adicionalmente, existe teoricamente uma perda de aleatoriedade se comparado com um arquivo de texto randômico. Isto é devido ao fato que imagens, vídeos e músicas tem uma relação intríseca entre bits de dados vizinhos que não existe num texto randômico. No entanto isto é controverso e nunca foi publicamente explorado.

Exemplo: imagens, texto, video ...

Criando um arquivo-chave com caracteres aleatórios

Armazenando o arquivo-chave em um sistema de arquivos

Um arquivo-chave pode ser de conteúdo e tamanho arbitrários.

Aqui é utilizado o dd para gerar um arquivo-chave de 2048 bytes aleatórios, e então armazenando no arquivo /etc/cryptsetup-keys.d/minhakeyfile.key:

# dd bs=512 count=4 if=/dev/random iflag=fullblock | install -m 0600 /dev/stdin /etc/cryptsetup-keys.d/minha_keyfile.key

Se você planeja guardar a keyfile em um dispositivo externo, você pode simplesmente mudar o arquivo de saída para o diretório correspondente:

# dd bs=512 count=4 if=/dev/random of=/run/media/usuário/pendrive/minha_keyfile.key iflag=fullblock

Sobrescrevendo com segurança os arquivos-chave armazenados

Se você guardou a sua keyfile temporária em uma unidade de armazenamento e quer deletá-la, use algo parecido com isso:

# shred --remove --zero minha_keyfile

Para sobrescrever com segurança, em sistemas de arquivos arcaicos, como FAT ou ext2, isto deve bastar, considerando que são sistemas de arquivos com journaling (ou seja, sistemas de arquivos que rastreiam e registram os eventos antes mesmo de serem efetivados na parte principal de gravação). Ao usar hardware de memória em flash e em outros casos é recomendado apagar o dispositivo inteiro.

Armazenando o arquivo-chave no tmpfs (com swapping desativado)

Alternativamente, você pode montar um tmpfs com a função de swapping desativada para guardar a keyfile temporariamente:

# mount --mkdir -t tmpfs -o noswap tmpfs /root/meu_tmpfs
# cd /root/meu_tmpfs

A vantagem é que ela reside na RAM e não em um disco físico, portanto o arquivo-chave não pode ser recuperado depois de desmontar o tmpfs. Depois de copiar a keyfile para outro sistema de arquivos seguro e persistente, desmonte o tmpfs novamente com:

# umount /root/meu_tmpfs

Configurando o LUKS para utilizar o arquivo-chave

Adicione um espaço de chave (keyslot) para a keyfile no cabeçalho do LUKS:

# cryptsetup luksAddKey /dev/sda2 /etc/cryptsetup-keys.d/minha_keyfile.key

Enter any existing passphrase:

Manualmente abrindo uma partição com um arquivo-chave

Use a opção --key-file quando for abrir um dispositivo LUKS:

# cryptsetup open /dev/sda2 dm_nome --key-file /etc/cryptsetup-keys.d/minha_keyfile.key

Com um aquivo-chave em um dispositivo externo

Configurando o mkinitcpio

Você deve adicionar o módulo de kernel usado pelo sistema de arquivos junto com o conjunto de módulos em /etc/mkinitcpio.conf. Por exemplo, adicione ext4 se o sistema de arquivos for Ext4 ou vfat no caso de um em FAT:

MODULES=(vfat)

Se houver menssagens sobre um "bad superblock" e "bad codepage" na inicialização, é necessário então que o sistema carregue um módulo de codepage extra. Você talvez precise do módulo nls_iso8859-1 para a codepage iso8859-1.

Gere novamente o initramfs.

Configurando os parâmetros de kernel

• Para um initramfs baseado em busybox que usa o hook encrypt, veja dm-crypt/Configuração de Sistema#cryptkey.
• Para um initramfs baseado em systemd que usa o hook sd-encrypt, veja dm-crypt/Configuração de Sistema#rd.luks.key.

Com um arquivo-chave embutido em initramfs

Atenção: Use uma keyfile dentro do initramfs somente se você proteger a keyfile suficientemente com:

• Alguma forma de autenticação prévia no processo de inicialização. De outro modo, o dispositivo vai ser aberto automaticamente, e com isso destruir totalmente o propósito da criptografia.
• /boot é criptografado. De outro modo, a raiz de outra instalação (incluindo o ambiente live) pode extrair sua chave do initramfs, e decriptografar o dispositivo sem qualquer outro meio de autentificação.

Este método permite o uso de um arquivo-chave escolhido especialmente para ser incorporado ao initramfs e pego pelo hook encrypt para abrir o sistema de arquivos raiz (cryptdevice) automaticamente. Pode ser útil ao usar o recurso de encriptação cryptodisk na inicialização do GRUB, e com isso evitar a digitação e confirmação de duas senhas durante a inicialização.

Gere um arquivo-chave, defina permissões apropriadas e a adicione como uma chave do LUKS:

# dd bs=512 count=4 if=/dev/random iflag=fullblock | install -m 0600 /dev/stdin /etc/cryptsetup-keys.d/root.key
# cryptsetup luksAddKey /dev/sdX# /etc/cryptsetup-keys.d/root.key

Nota: O initramfs é gerado pelo mkinitcpio com as permissões configuradas em 600 por padrão, então usuários comuns do sistema não conseguem ler o conteúdo da keyfile através do initramfs gerado.

Inclua a chave no arranjo de arquivos do mkinitcpio:

/etc/mkinitcpio.conf

FILES=(/etc/cryptsetup-keys.d/root.key)

Gere novamente o initramfs.

Para o hook encrypt, o arquivo-chave é especificado com o parâmetro de kernel cryptkey=: no caso do initramfs, a sintaxe é rootfs:caminho/para/arquivo-chave. O nome padrão e caminho definido é: /crypto_keyfile.bin. É possível omitir cryptkey se o initramfs conter uma chave válida neste caminho. Veja dm-crypt/Configuração de Sistema#cryptkey.

Para o exemplo acima, configure o seguinte parâmetro de kernel ao usar um initramfs baseado em busybox com o hook encrypt:

# cryptkey=rootfs:/etc/cryptsetup-keys.d/root.key

Se, caso o contrário, for usado o hook sd-encrypt, o arquivo-chave é especificado com o parâmetro de kernel rd.luks.key=: no caso do initramfs, a sintaxe é /caminho/para/arquivo-chave. O nome padrão e caminho definido é: /etc/cryptsetup-keys.d/nome.key (o nome é o mesmo que dm_nome, ou seja, o nome do dispositivo mapeado para descriptografar em #Criptografando dispositivos com o modo LUKS). É possível omitir rd.luks.key se o initramfs conter uma chave válida neste caminho. Veja dm-crypt/Configuração do sistema#rd.luks.key.

Na próxima inicialização, você deverá somente precisar entrar com a senha de desencriptação do container uma vez.

(fonte)