Por que o LUKS precisa gerar valores de hash?

Question

Se você criar um novo dispositivo LUKS, poderá especificar a opção -hash e -iter-time .

Por exemplo, assim:

 sudo cryptsetup luksFormat --cipher aes-cbc-essiv:sha256 --key-size 256 --iter-time 2100 --hash sha512 /dev/loop0

A partir do manpage do cryptsetup:

--hash, -h

For create action specifies hash to use for password hashing.

For luksFormat action specifies hash used in LUKS key setup scheme and volume key digest.

Por causa da primeira sentença, eu ingenuamente assumi que o hash é usado de maneira similar a um sistema linux padrão, onde um valor de hash é criado por um algoritmo especificado (por exemplo sha512 ). Para tornar mais difícil para um invasor que tem o hash e deseja tentar um ataque de dicionário, o has é salgado e o algoritmo é iterado n vezes para tornar o tempo de computação mais longo. Nesse caso, o valor tem armazenado em /etc/shadow . Se um usuário efetuar login, o hash é calculado e comparado com o valor no arquivo /etc/shadows . Se eles forem iguais, o usuário é aceito para efetuar login. De forma semelhante, um invasor que possui o arquivo /etc/shadow (de onde ele também conhece o valor salt) pode calcular hashes de palavras em um dicionário e compará-lo ao valor no arquivo /etc/shadow até que algumas sequências de caracteres correspondam.

Se o hash no LUKS fosse usado de maneira semelhante, assumi que ele deveria ser armazenado em algum lugar (por exemplo, no cabeçalho da partição) e se o invasor tivesse acesso ao cabeçalho da partição (ou ao arquivo onde ele está armazenado) para algumas razões, ele poderia proceder de maneira semelhante à anterior para descobrir a senha. Isso me leva à pergunta sobre como obter o hash: Como eu posso extrair o valor de hash de um dispositivo LUKS?

Pensando em como o sistema LUKS pode funcionar, acho que não é usado dessa maneira. Em vez disso, acho que a senha é usada apenas para criptografar a chave (e nenhum hash é armazenado em lugar algum), que é armazenado criptografado no cabeçalho. Mas na página man do LUKS eu não encontrei nenhuma dica, qual algoritmo de criptografia é usado para criptografia de chave e como alterá-la. (As opções --cipher aes-cbc-essiv:sha256 --key-size 256 referem-se ao algoritmo real que é usado para criptografar a partição, mas não a chave). Isso indica para mim que esse entendimento também está incorreto.

Então, como tudo isso realmente funciona e qual é o papel do hash descrito acima? Seria ótimo se alguém pudesse esclarecer meus equívocos acima (talvez com algumas referências).

    

Answer 1

O formato LUKS tem vários slots principais, cada um pode conter a chave mestra criptografada usada para criptografia de dados. Essa chave mestra é criptografada usando outra chave que é derivada de sua frase secreta.

Usar hash_function(passphrase) simples para gerar uma chave seria burro, já que hashes como sha1 podem ser calculados rapidamente (SHA-1 é um exemplo de um MAC , para autenticação de uma mensagem, não para ser usada como simples para uma senha).

Para criptografia de dados com base em uma senha, você quer que a função seja lenta para impedir ataques de força bruta. Para este propósito, PBKDF2 (função de derivação de chave baseada em senha) é usada (veja as respostas excelentes em esta questão Sec.SE para motivações e outros exemplos).

derivedKey = PBKDF2(hash_function, passphrase, salt, iterations, derivedKeyLen)

A função hash_ da minha instalação é sha1, como é mostrado em cryptsetup --help :

Default compiled-in key and passphrase parameters:
        Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF2 iteration time for LUKS: 1000 (ms)

Default compiled-in device cipher parameters:
        loop-AES: aes, Key 256 bits
        plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
        LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/urandom

O comprimento da chave derivada depende da codificação usada para criptografia de dados. O número de iterações depende da velocidade do processador.

Estes detalhes podem ser encontrados na página de manual do cryptsetup (pbkdf2 deve tocar uma campainha). Para outros detalhes de segurança, consulte as Perguntas frequentes do cryptsetup .

    

Answer 2

Você está certo, armazenar credenciais para criptografia e armazenar credenciais para autenticação são dois problemas diferentes.

Quando um usuário efetua login, o sistema operacional precisa ter uma cópia de referência de sua senha para comparar com a senha que o usuário digita. Se a senha digitada for idêntica à senha de referência, a autenticação será bem-sucedida. Para dificultar a recuperação de senha, o sistema não armazena a senha, mas um hash disto (um hash lento e salgado para fazer tentativas de força bruta para adivinhar a senha mais difícil).

A criptografia funciona de maneira diferente. O objetivo é proteger contra um invasor que tenha acesso ao armazenamento, portanto, não deve ser possível extrair a chave de criptografia do que está armazenado no dispositivo sozinho. Portanto, a chave não é armazenada no dispositivo, mas é construída a partir de informações armazenadas no dispositivo combinadas com informações fornecidas pelo usuário. Normalmente, a chave é gerada a partir de um sal armazenado no dispositivo combinado com uma senha fornecida pelo usuário. Novamente, para desacelerar as tentativas de força bruta, o processo para combinar esses valores deve ser lento, e o processo usa um valor por dispositivo (o salt) além da senha do usuário para que o uso da mesma senha não leve para a mesma chave.

Acontece que, criptograficamente falando, um hash de senha lenta e uma função de derivação de chave lenta são o mesmo problema, conhecido como alongamento da tecla . O LUKS usa PBKDF2 , uma das funções padrão de alongamento de chaves padrão (embora o progresso tecnológico na quebra de senhas torne o bcrypt ou o scrypt preferível) . Sistemas unix modernos usam um mecanismo similar para hashing de senha (“MD5” ou “SHA-512” são realmente iterados , semelhante em construção ao PBKDF2)

Se o usuário fornecer uma senha incorreta, a descriptografia dos dados retornará lixo.

Como a maioria dos outros mecanismos de criptografia, o LUKS não usa a chave derivada da senha como a chave de criptografia dos dados. Em vez disso, a chave de criptografia de dados é gerada aleatoriamente quando o dispositivo é criado, mas não armazenado diretamente. O LUKS armazena cópias desta chave criptografada com cada uma das chaves derivadas por senha. Na terminologia LUKS, cada chave derivada de senha ocupa um slot no cabeçalho de volume; Cada slot corresponde a uma senha. Você pode ler o artigo TKS1 para obter detalhes sobre o esquema de criptografia de duas camadas.