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

Artigo original ↗ Discussão no Hacker News ↗

Uma regressão introduzida no kernel Linux 6.9 fez com que, por mais de dois anos, sistemas usando o recurso `luksSuspend` do LUKS pudessem parecer bloquear discos criptografados ao suspender enquanto secretamente deixavam a chave de decriptação na RAM. Os comentaristas examinam como isso enfraquece a proteção contra cold boot para usuários que dependem de suspend-to-RAM por segurança, contrastam isso com hibernação e com abordagens baseadas em TPM ou criptografia de memória por hardware, e debatem quais são modelos de ameaça realistas para usuários comuns versus alvos de alto valor. O incidente também provoca críticas mais amplas sobre testes, invariantes e auditabilidade em grandes codebases em C, além de comparações com soluções proprietárias como BitLocker e FileVault.

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.