Se um cabeçalho LUKS antigo com uma chave comprometida for recuperado, ele pode ser usado para ler dados?

Question

Pelo que entendi, mesmo quando os dados são sobrescritos no disco, existe a possibilidade de serem recuperados. Pelo que eu também entendo, a substituição / exclusão de uma chave LUKS é rápida / trivial e não leva a que todos os dados sejam reescritos. Isso sugere que há uma "chave secundária" importante em algum lugar no cabeçalho, o que sugere ainda que, se uma chave tiver sido comprometida e substituída, mas um invasor puder recuperar um estado PREVIOUS do cabeçalho LUKS que usou essa chave, eles poderiam ainda acessar os dados. Estou errado ou isso é uma preocupação de segurança?

    

Answer 1

A resposta curta: essa é uma preocupação de segurança se você não conseguir manter o controle físico da mídia e / ou escolher frases-senha inadequadas.

Resposta mais longa:

Se um invasor obtiver acesso ao disco rígido no momento A, duplicá-lo e comprometer a chave como estava no momento A, todos os dados presentes no momento A serão comprometidos (mas você sabia disso) .

No melhor de meu conhecimento, existe uma 'chave mestra' à qual cada senha lhe dará acesso. Além disso, não há como encontrar facilmente a chave mestra sem criar uma nova partição para a nova chave mestra (seria difícil fazer isso mesmo se fosse possível).

O que isto significa é que, a menos que você limpe o disco rígido e inicie novamente entre os tempos A e B, o invasor que comprometeu a chave no tempo A e também obtém acesso à mesma unidade no momento B acesso aos dados como está no momento B.

Mitigação:

Educação do usuário e resposta adequada a ameaças de segurança. Se o usuário perder o controle da mídia criptografada e, em seguida, recuperar o controle posteriormente, será necessário informá-lo sobre isso e você precisará limpar a máquina e criptografá-la novamente usando uma frase-senha diferente.

Além disso, conte a informação que estava no laptop (no momento A) como perdida ou potencialmente perdida se houver alguma chance de um invasor sofisticado ter acesso a ela e a frase secreta não ser strong.

    

Answer 2

Como um breve resumo das partes do cabeçalho LUKS que são relevantes aqui (não necessariamente pretendem ser 100% tecnicamente precisas):

• Um cabeçalho LUKS contém "slots de chaves"

• Cada slot chave contém a "chave mestra" para o contêiner

• Cada slot de chave é criptografado independentemente usando uma chave derivada da frase secreta

• Cada slot de chave tem suas próprias configurações de função de senha e derivação de chave associadas

Quando você cria um contêiner LUKS, uma chave mestra aleatória é gerada. Essa é a chave de criptografia usada para criptografar os dados na unidade. Você também recebe uma senha, que é usada para derivar uma chave de criptografia para o primeiro slot de chave. A chave de criptografia do slot da chave, por sua vez, é usada para proteger os dados no slot da chave, incluindo a chave mestra.

Até pouco tempo atrás, o LUKS não tinha uma maneira conveniente de alterar a chave mestra; foi essencialmente "queimado" no contêiner no momento da criação. Este era um problema, por exemplo, se a criação de contêiner acontecesse em uma situação de falta de entropia, como no início da instalação inicial do sistema. Hoje em dia (desde o cryptsetup 1.5), há cryptsetup-reencrypt que é fornecido por padrão em distribuições modernas , que entre outras coisas permitem que você altere a chave mestra do contêiner, criptografando novamente todos os dados no contêiner.

Um backup de cabeçalho LUKS contém todos os dados que o cabeçalho LUKS contém. Em outras palavras, a chave mestra, protegida por (possivelmente um conjunto de diferentes) frases-chave (s). É igualmente possível para um invasor atacar o contêiner LUKS através de um backup de cabeçalho ou uma cópia de um cabeçalho desanexado, como por meio do acesso direto ao contêiner.

Portanto, se um invasor tiver acesso ao cabeçalho LUKS de um contêiner, ele poderá atacar os slots principais quando desejar. Uma vez que eles conseguirem abrir um dos slots de chave, eles terão a chave que será usada quando o cabeçalho for despejado para descriptografar os dados no container. Se o cabeçalho ao qual o invasor tem acesso estiver protegido por uma senha fraca ou com configurações PBKDF fracas (particularmente a contagem de iterações), isso pode ser um problema.

Novamente, a menos que você criptografe novamente o contêiner usando uma chave diferente (você pode ficar com as mesmas configurações de cifra e cifra), esse invasor pode usar a chave mestra que agora conhece para acessar os dados no contêiner em algum momento posterior.

Para mitigar essa ameaça, não é suficiente alterar a frase secreta; você precisa re-criptografar o contêiner.

É claro que, se o invasor puder duplicar não apenas o cabeçalho LUKS, mas também o conteúdo do contêiner em si, e o invasor conseguir erguer um espaço-chave aberto, os dados serão imediatamente comprometidos.