LUKS por Baixo do Capô: Arquitetura de Criptografia no Linux, dm-crypt e Recuperação Forense

Criptografia de disco parece simples até você precisar recuperar um volume quebrado, explicar por que uma senha nova não recriptografou terabytes de dados, ou descobrir que aquele backup do header que você “faria depois” era literalmente a diferença entre recuperar tudo e aceitar o luto.

No Linux, a combinação mais comum para proteger dados em repouso é LUKS com dm-crypt. Muita gente fala “LUKS criptografa o disco”, mas isso é uma meia verdade conveniente. O LUKS não é exatamente o motor criptográfico. Ele é o formato, o cabeçalho, a estrutura de metadados e o gerenciamento de chaves. Quem faz o trabalho pesado de cifrar e decifrar blocos é o dm-crypt, no kernel, usando o Device Mapper.

Essa separação importa porque evita uma confusão bem comum: tratar criptografia de disco como se fosse uma camada mística de segurança absoluta. Não é. É uma peça muito boa para um problema específico: proteger dados em repouso contra acesso offline ao dispositivo, roubo de mídia, descarte malfeito de disco, perda de notebook, snapshot bruto de volume e outras situações em que alguém tem acesso aos blocos, mas não à chave.

Quando o sistema está ligado, desbloqueado e comprometido, o jogo é outro. LUKS não é antivírus, não é EDR, não é firewall, não é controle de acesso e não salva servidor onde alguém já virou root. Chato, mas necessário dizer.

LUKS é o formato; dm-crypt é o motor

O dm-crypt é um alvo do Device Mapper que fornece criptografia transparente de dispositivos de bloco usando a Crypto API do kernel. A própria documentação do kernel descreve o crypt target como uma camada de criptografia transparente para block devices, com algoritmos como aes-xts-plain64 sendo usados na prática em muitos setups modernos.

Já o cryptsetup é a ferramenta de espaço de usuário que você usa para criar, abrir, fechar, consultar e administrar esses volumes. Segundo a man page do cryptsetup, ao desbloquear um volume criptografado, a ferramenta cria um novo mapeamento de dispositivo, enquanto a criptografia e descriptografia ficam a cargo do driver dm-crypt no kernel.

Na prática, o fluxo é este:

1. você cria um contêiner LUKS em um dispositivo;
2. o LUKS armazena metadados, parâmetros e keyslots;
3. o cryptsetup valida a senha ou keyfile;
4. o kernel cria um dispositivo virtual em /dev/mapper/;
5. o sistema de arquivos passa a enxergar esse dispositivo como um bloco normal.

A aplicação não sabe se está escrevendo em disco criptografado. O PostgreSQL, o SQLite, o Vim, o cp, o rsync e o resto da turma só veem um sistema de arquivos montado. A criptografia acontece abaixo disso, na camada de blocos.

Isso é elegante porque não exige que cada aplicação implemente criptografia. Também é perigoso para a cabeça do usuário, porque a transparência da camada faz parecer que nada está acontecendo. E quando segurança parece invisível demais, sempre aparece alguém para esquecer qual problema ela realmente resolve.

A senha não cifra os dados diretamente; ela libera um keyslot que protege a chave de volume usada pelo dm-crypt.

O que existe dentro de um volume LUKS

Um volume LUKS não é só “um disco com senha”. Ele tem uma estrutura.

Em um volume LUKS, existe um cabeçalho com metadados sobre o contêiner: versão do formato, algoritmo, UUID, parâmetros de derivação de chave, área de keyslots e informações necessárias para abrir corretamente o dispositivo. A man page do cryptsetup resume bem a diferença: volumes em modo plain têm criptografia básica sem metadados, enquanto volumes LUKS incluem um header padronizado que permite keyslots múltiplos e gerenciamento de chaves.

A parte mais importante é esta: os dados do disco não são criptografados diretamente com a sua senha.

A senha serve para liberar uma chave de volume. Essa chave de volume é a chave usada para criptografar os dados. Os keyslots armazenam cópias protegidas dessa chave, cada uma derivada de uma senha, keyfile ou mecanismo de autenticação compatível.

É por isso que trocar a senha de um volume LUKS não exige recriptografar o disco inteiro. Você não está reescrevendo todos os blocos de dados. Você está alterando a forma como uma chave de volume é protegida em um keyslot.

Bonito no README, importantíssimo no desastre.

Keyslots: múltiplas portas para a mesma chave

Keyslot é um daqueles conceitos que parecem detalhe até você precisar remover o acesso de alguém sem formatar um volume de alguns terabytes.

No LUKS, vários keyslots podem desbloquear a mesma chave de volume. Isso permite ter, por exemplo, uma senha de uso diário, uma senha de emergência guardada em local seguro e um keyfile usado por automação. Cada entrada pode ser adicionada, alterada ou removida sem recriptografar os dados.

Para ver a estrutura de um volume, o comando mais útil é:

sudo cryptsetup luksDump /dev/sdb1

Ele mostra informações do header, versão do LUKS, UUID, cipher, keyslots ativos e parâmetros de derivação. É um comando de inspeção, não de desbloqueio.

Para adicionar uma nova senha ou keyfile:

sudo cryptsetup luksAddKey /dev/sdb1

Para remover uma senha conhecida:

sudo cryptsetup luksRemoveKey /dev/sdb1

E para matar um slot específico:

sudo cryptsetup luksKillSlot /dev/sdb1 2

Esse último exige cuidado. Remover o slot errado pode não destruir o volume, desde que existam outros slots válidos, mas pode destruir o seu acesso se você não souber exatamente quais credenciais ainda funcionam. O Linux entrega ferramentas afiadas. A parte de não sair correndo pela casa com a faca na mão continua sendo sua.

Criando e montando um volume LUKS manualmente

Para criar um volume LUKS em um dispositivo, o comando clássico é:

sudo cryptsetup --type luks2 luksFormat /dev/sdb1

Use /dev/sdb1 como exemplo, não como conselho universal. Conferir o dispositivo antes de rodar luksFormat não é frescura; é sobrevivência. Esse comando inicializa o contêiner LUKS e pode destruir dados existentes no alvo. Se você rodar no disco errado, não existe argumento filosófico que desfaça a besteira.

Depois de criar o contêiner, você abre o volume:

sudo cryptsetup open /dev/sdb1 dados_criptografados

Isso cria um mapeamento em:

/dev/mapper/dados_criptografados

A partir daí, você cria um sistema de arquivos dentro do dispositivo mapeado:

sudo mkfs.ext4 /dev/mapper/dados_criptografados

E monta normalmente:

sudo mkdir -p /mnt/dados
sudo mount /dev/mapper/dados_criptografados /mnt/dados

Tudo que for escrito em /mnt/dados será escrito no sistema de arquivos, que por sua vez escreverá no dispositivo mapeado, que por sua vez passará pelo dm-crypt antes de atingir o dispositivo físico.

Para encerrar corretamente:

sudo umount /mnt/dados
sudo cryptsetup close dados_criptografados

Repare na ordem. Primeiro desmonta o sistema de arquivos. Depois fecha o mapeamento criptográfico. Fechar o mapeamento com o filesystem ainda em uso é pedir para o sistema reclamar - com razão.

O header é pequeno, mas manda no destino do disco inteiro

O header do LUKS é uma das partes mais importantes do volume. Ele não contém os seus arquivos em texto claro, mas contém os metadados necessários para chegar até a chave de volume protegida pelos keyslots.

Se o header for destruído, corrompido ou sobrescrito, o restante do disco vira ruído criptográfico. Não é drama. É o design fazendo exatamente o que se espera de criptografia: sem os metadados e a chave correta, os dados não devem ser recuperáveis.

A própria man page do cryptsetup avisa que, se o header de um volume LUKS for danificado, os dados podem ser permanentemente perdidos sem um backup de header. Também explica que o luksHeaderBackup salva uma cópia binária do header e da área de keyslots.

Faça o backup:

sudo cryptsetup luksHeaderBackup /dev/sdb1 \
  --header-backup-file luks-header-sdb1.bin

E, em caso de desastre, a restauração usa:

sudo cryptsetup luksHeaderRestore /dev/sdb1 \
  --header-backup-file luks-header-sdb1.bin

Mas tem uma pegadinha importante: backup de header não é item decorativo para jogar no mesmo disco e esquecer. Ele precisa ficar fora do dispositivo protegido, preferencialmente em mídia separada, com backup e controle de acesso.

Também não trate o arquivo como completamente inofensivo. Um backup de header não abre o volume sozinho sem senha ou chave válida, mas ele contém keyslots e metadados suficientes para permitir tentativas offline contra as credenciais. Além disso, restaurar um header antigo pode reverter mudanças de keyslot: senhas removidas podem voltar, senhas adicionadas depois do backup podem desaparecer, e o estado do volume pode ficar inconsistente em cenários mais complexos.

Backup bom é aquele que você sabe restaurar. Backup de header que nunca foi testado é fé com extensão .bin.

LUKS protege confidencialidade, não integridade por padrão

Um ponto que muita explicação sobre LUKS deixa escapar: criptografia de disco tradicional protege confidencialidade. Ela impede que alguém leia os dados sem a chave. Isso não significa, automaticamente, que ela impeça adulteração detectável dos blocos.

Em setups comuns com dm-crypt, um atacante com acesso ao dispositivo offline pode alterar blocos cifrados. Ele talvez não saiba produzir uma alteração útil, mas ainda pode causar corrupção. Dependendo do sistema de arquivos, da aplicação e da área alterada, o resultado pode variar de “arquivo quebrado” até “boa sorte entendendo esse comportamento estranho”.

Existem modos e arquiteturas que adicionam integridade autenticada, como combinações envolvendo dm-integrity e recursos do LUKS2, mas isso não vem de graça. Há custo de espaço, desempenho, complexidade operacional e compatibilidade. O ponto não é sair ligando tudo porque parece mais seguro. O ponto é entender que LUKS comum não é uma assinatura criptográfica gigante do disco inteiro.

Segurança sem modelo de ameaça vira decoração.

TRIM, SSD e vazamento de padrão de uso

Outro detalhe que costuma ser tratado com pressa é o descarte de blocos, também conhecido como TRIM em SSDs.

O dm-crypt pode permitir que operações de discard atravessem a camada criptografada. Isso pode ajudar SSDs e thin provisioning, mas também pode revelar padrões de uso: quais áreas estão alocadas, quais foram liberadas, como o volume evolui ao longo do tempo. A documentação do kernel sobre dm-crypt alerta que permitir discards em dispositivos criptografados pode vazar informações sobre o dispositivo cifrado, como tipo de sistema de arquivos e espaço utilizado.

Não significa que allow-discards é sempre proibido. Significa que não é uma opção neutra.

Em notebook pessoal, servidor com SSD, ambiente virtualizado, storage thin-provisioned ou banco de dados com padrão de escrita específico, a decisão muda. Segurança real quase sempre é trade-off. Quem promete solução sem custo geralmente está vendendo curso, não arquitetura.

Performance: AES-NI ajuda, mas “desprezível” é palavra perigosa

Em CPUs modernas com aceleração de hardware, como AES-NI, o overhead de criptografia pode ser baixo em muitos cenários. Em alguns desktops e servidores, a diferença prática é quase invisível para uso comum.

Mas escrever “o overhead é desprezível” como regra geral é exagero.

O impacto depende do algoritmo, do modo de operação, do tamanho dos blocos, do dispositivo, da CPU, do scheduler, da carga de I/O, do uso de discard, da presença de integridade autenticada e do tipo de workload. Um desktop com NVMe e AES-NI não é a mesma coisa que um servidor velho, uma VM limitada, um ARM barato ou um storage saturado.

Antes de cravar, rode ao menos:

cryptsetup benchmark

E, mais importante, teste a carga real. Benchmark sintético é útil para entender limite criptográfico, mas não substitui medir o comportamento da aplicação que vai rodar em cima do volume.

Criptografia total de disco e o problema do boot remoto

Full Disk Encryption é ótimo até o servidor reiniciar às três da manhã e ficar parado esperando uma senha no console que ninguém tem aberto.

Esse é o problema clássico de criptografar a raiz do sistema em máquinas remotas. Se tudo que importa está atrás do LUKS, alguém precisa desbloquear o volume antes do sistema subir completamente. Em notebook, isso é normal. Em servidor remoto, vira operação.

Uma abordagem comum é colocar um SSH mínimo no initramfs, muitas vezes com Dropbear, para permitir desbloqueio remoto antes da montagem da raiz. Funciona, mas adiciona superfície de ataque justamente no estágio mais delicado do boot. Você passa a depender de rede, configuração do initramfs, chaves SSH, política de acesso e atualização correta dessa mini infraestrutura.

Outra abordagem é separar o sistema operacional dos dados. A raiz sobe sem criptografia completa, o SSH normal inicia, e os volumes sensíveis ficam em LUKS separados. Depois do boot, um operador ou automação controlada desbloqueia apenas os volumes de dados.

Isso não é “mais seguro” ou “menos seguro” universalmente. É uma escolha de ameaça.

Se o risco principal é roubo físico de discos de dados, descarte de mídia ou snapshot bruto de volume, criptografar apenas dados sensíveis pode ser suficiente e mais operável. Se o risco inclui acesso ao disco do sistema, manipulação de binários, alteração de initramfs, persistência no boot ou exposição de segredos em /etc, talvez a raiz também precise entrar na conta.

Arquitetura boa começa com uma pergunta sem glamour: contra quem exatamente eu estou me defendendo?

LUKS em análise forense: trabalhe em cópia e monte read-only

Em resposta a incidentes, CTFs ou análise forense autorizada, é comum encontrar imagens brutas contendo partições LUKS. O procedimento correto não é sair montando a imagem original com escrita liberada como se fosse pendrive de música.

Primeiro, trabalhe em cópia. Segundo, prefira loop device somente leitura. Terceiro, abra o volume em modo read-only quando o objetivo for análise.

Um fluxo mais conservador seria:

sudo losetup --read-only --find --show imagem.raw

O comando retorna algo como:

/dev/loop0

Se a imagem tiver tabela de partições, pode ser necessário usar ferramentas como parted, fdisk, kpartx ou losetup -P para expor as partições internas. Depois, com a partição correta identificada, o volume pode ser aberto em modo somente leitura:

sudo cryptsetup open --readonly --type luks /dev/loop0p2 volume_analise

E montado também como somente leitura:

sudo mount -o ro /dev/mapper/volume_analise /mnt/analise

Ferramentas como binwalk podem ajudar a encontrar assinaturas em arquivos binários, mas não devem virar muleta mental. Em disco real, tabela de partição, offsets, headers e alinhamento importam. Se você não sabe onde começa o contêiner LUKS, o problema não é o cryptsetup; é a análise do layout.

E vale repetir: análise forense pressupõe autorização. Sem isso, muda de “investigação” para “problema jurídico com terminal aberto”.

O que LUKS não resolve

LUKS é excelente dentro do escopo certo. Fora dele, vira amuleto.

Ele não protege seus dados quando o volume já está desbloqueado e alguém comprometeu o sistema. Não impede exfiltração por malware rodando com permissão do usuário. Não protege contra senha fraca. Não substitui backup. Não corrige servidor mal configurado. Não faz controle de acesso por arquivo. Não impede que alguém apague o disco. Não garante integridade por padrão. Não salva uma máquina onde o atacante consegue alterar o boot sem que você perceba.

Também não resolve o velho problema da disponibilidade. Criptografia pode transformar falhas pequenas em desastres definitivos. Um header perdido, uma senha esquecida, um keyslot removido errado ou um backup inexistente podem ser mais eficientes que muito ransomware.

Isso não é argumento contra criptografia. É argumento contra usar criptografia sem operação.

Checklist mínimo antes de confiar em um volume LUKS

Algumas práticas simples evitam boa parte da tragédia:

sudo cryptsetup luksDump /dev/sdb1

Verifique o volume, os keyslots ativos e os parâmetros antes de mexer.

sudo cryptsetup luksHeaderBackup /dev/sdb1 \
  --header-backup-file luks-header-sdb1.bin

Faça backup do header e guarde fora do disco.

sudo cryptsetup open /dev/sdb1 teste_restore
sudo cryptsetup close teste_restore

Teste se a credencial esperada realmente abre o volume.

cryptsetup benchmark

Meça o básico de performance criptográfica, mas valide com carga real.

E, principalmente, mantenha backup dos dados. Header backup não substitui backup de conteúdo. Ele só preserva a chance de acessar o volume caso os metadados quebrem. Se o SSD morrer, se o filesystem corromper, se alguém apagar os arquivos ou se você formatar o dispositivo errado, o header backup não vira máquina do tempo.

LUKS é simples. A operação em volta dele não é.

O LUKS faz uma coisa muito bem: padroniza como o Linux gerencia volumes criptografados, múltiplas credenciais e metadados para criptografia de disco. O dm-crypt faz o trabalho pesado no kernel. O cryptsetup entrega a interface administrativa. Juntos, eles formam uma das soluções mais sólidas para proteger dados em repouso no ecossistema Linux.

Mas a parte difícil nunca foi apenas rodar luksFormat.

A parte difícil é saber qual dispositivo você está formatando. É guardar o header. É ter backup. É entender o que acontece quando troca uma senha. É saber que TRIM pode vazar padrão de uso. É lembrar que criptografia sem integridade tem limites. É planejar boot remoto. É aceitar que volume desbloqueado é dado acessível para o sistema.

Criptografia de disco não é um botão mágico de segurança. É uma ferramenta de engenharia.

E como toda ferramenta de engenharia no Linux, ela funciona muito bem — até alguém usar sem entender e depois culpar o kernel.