Desde o Linux 6.9, a suspensão do LUKS deixou de apagar as chaves de criptografia de disco da memória

Natureza da regressão

• Desde o Linux 6.9, cryptsetup luksSuspend deixou de apagar de forma confiável as chaves de volumes LUKS da RAM ao suspender, embora os usuários continuassem sendo solicitados a informar a senha ao retomar.
• O bug veio de uma mudança no tempo de vida do keyring do kernel: esperava-se que chaves armazenadas em um thread keyring desaparecessem quando a thread terminasse, mas isso deixou de acontecer, mantendo uma cópia extra da chave do volume na memória do kernel.
• Isso tornou menos seguros os sistemas que acreditavam estar “extra seguros ao suspender”, embora parecessem funcionar normalmente.

Suspensão vs hibernação e modelo de ameaça

• Suspend-to-RAM: a RAM (incluindo as chaves do disco) permanece alimentada; a maioria dos sistemas não limpa as chaves LUKS, então a criptografia de disco protege principalmente discos desligados ou removidos.
• Hibernate-to-disk: o conteúdo da RAM (incluindo as chaves) é gravado em um swap/imagem criptografado e a RAM é desligada; ao retomar, os usuários digitam as senhas novamente.
• Alguns argumentam que apenas a hibernação (ou desligar sempre) realmente protege contra ataques de cold boot; outros observam que a viabilidade do ataque depende muito do modelo de ameaça.

Cold boot e acesso físico

• Com acesso físico a um laptop suspenso e bloqueado, atacantes podem:
  • Realizar ataques de cold boot (reinicialização rápida em um SO personalizado, ou congelamento e transferência da RAM).
  • Usar DMA ou técnicas semelhantes em sistemas mal configurados.
• Vários comentários enfatizam que isso é relevante בעיקרamente para alvos de alto valor ou estatais, não para ladrões comuns.

Contornos e mitigação

• Mitigações recomendadas discutidas:
  • Usar hibernação em vez de suspensão; alguns usuários do Fedora hibernam automaticamente após um tempo limite de suspensão.
  • Ativar criptografia de memória da CPU (recursos Intel/AMD) quando disponível, embora isso combata principalmente ataques físicos à RAM, e não o uso lógico indevido das chaves.
  • Usar recursos EFI/TPM como MemoryOverwriteRequest para garantir que a RAM seja apagada na reinicialização.

Escopo e particularidades das distribuições

• luksSuspend está a montante no cryptsetup; o Debian adicionou integração que o conecta à suspensão, e esse método teria sido portado para outras distribuições.
• A regressão afetou configurações que dependem da semântica de luksSuspend, não instalações padrão de “apenas suspender”.

Comparações e temas mais amplos de segurança

• Longa digressão comparando BitLocker, FileVault, LUKS e VeraCrypt:
  • Empresas preferem a gerenciabilidade do BitLocker, especialmente com TPM+PIN e escrow de chaves.
  • Usuários preocupados com privacidade desconfiam de criptografia proprietária e de escrow de chaves na nuvem.
• Vários comentários destacam:
  • Código aberto é mais auditável, mas não é automaticamente auditado.
  • A falta de testes de integração robustos permitiu essa regressão; adicionar um teste dedicado é visto como a verdadeira correção de longo prazo.