Início / unix / Perguntas / 746513
Accepted
Philipp Claßen
Asked: 2023-05-21 15:36:55 +0800 CST

cryptsetup: a verificação no luksOpen é não determinística ao ler a senha de um arquivo

  • 772

Estou depurando um comportamento estranho do cryptsetup:

Suponha que a senha correta esteja armazenada no arquivo pw. Eu esperava agora que --test-passphrasesempre teria sucesso (ou seja, não imprimindo nenhuma saída) se fosse passado como stdin. Mas acontece que ele falha aleatoriamente:

# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
No key available with this passphrase.
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
No key available with this passphrase.
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
No key available with this passphrase.
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
# cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2 < pw
No key available with this passphrase.

Percebi isso, pois falho constantemente várias vezes para desbloquear minha partição na inicialização (no GRUB). Primeiro, pensei que estava digitando errado, mas agora tenho a impressão de que pode ser um bug no cryptsetup. Também não consigo desbloqueá-lo consistentemente mais tarde (não no GRUB), mesmo se estiver copiando e colando a senha correta.

Observe que também difere quando passo por esta maneira (principalmente equivalente):

# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.
# cat pw | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
No key available with this passphrase.

Aqui, todas as tentativas falharam, exceto uma. Enquanto a outra abordagem é bem-sucedida com mais frequência. Esse comportamento é reproduzível para mim: sempre falha com mais frequência.

# cryptsetup --version
cryptsetup 2.6.1 flags: UDEV BLKID KEYRING KERNEL_CAPI

# cryptsetup luksDump /dev/nvme0n1p2
LUKS header information
Version:        2
Epoch:          5
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           2372e472-ef96-428f-b971-f68fb0c35b63
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
    offset: 16777216 [bytes]
    length: (whole device)
    cipher: aes-xts-plain64
    sector: 512 [bytes]

Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2id
    Time cost:  13
    Memory:     1048576
    Threads:    4
    Salt:       ea b0 88 ... 
                f3 f9 72 ... 
    AF stripes: 4000
    AF hash:    sha256
    Area offset:32768 [bytes]
    Area length:258048 [bytes]
    Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
    Hash:       sha256
    Iterations: 334367
    Salt:       f0 ac 44 ... 
                f3 6f d5 ... 
    Digest:     cd a8 ... 
                23 2a ... 

$ uname -a
Linux amd12 6.3.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 11 May 2023 16:40:42 +0000 x86_64 GNU/Linux

(OS: Arch Linux)

Eventualmente, sempre posso desbloquear, mas preciso de muitas tentativas, o que é irritante. Parece que o código de verificação ou o mecanismo para ler a entrada é inconsistente.

Eu me pergunto se é um problema conhecido (embora eu não tenha encontrado nada sobre isso)? Se não, existe uma maneira de depurar? Infelizmente, não vi nenhuma opção para obter feedback visual (acho que é considerado uma falha de segurança revelar o tamanho da senha).

Atualização: acabei de perceber que existe uma --debugopção. Embora a saída de uma execução bem-sucedida e com falha seja idêntica até o ponto em que o cálculo ocorre. Todos os cabeçalhos e somas de verificação no log de depuração são os mesmos.

Além disso, mostra o mesmo comportamento com o cryptsetup 2.4.3 em um Linux Mint Live CD.

luks

1 respostas

  1. Best Answer

    @frostschutz estava correto. Acontece que a memória da minha máquina mostra erros em uma execução do Memtest86+.

    A explicação mais provável é que a computação funciona ou falha dependendo de qual parte da RAM está sendo usada. E Argon2 - agora o padrão para derivação de chave - usa muita memória durante a computação.

    Mas não é culpa do cryptsetup. Agora, testei novamente com apenas um bloco de memória que passou em pelo menos uma execução do Memtest86+. Não é mais reproduzível. Ambas as versões ( < pwe cat pw |) agora estão sempre passando.

    Atualização: fiz mais testes com a remoção de slots de RAM. Curiosamente, funciona com slots individuais, mas em combinação torna-se pouco confiável. A máquina em si é nova, mas vi que o XMP (Extreme Memory Profile) estava habilitado. Pelo que li, é um padrão razoavelmente seguro no novo hardware, mas na minha máquina parece causar problemas. Depois de desativá-lo, ele funciona agora.

    Talvez eles devessem incluir Argon2 no memtest86+. No meu sistema, é ótimo detectar problemas de memória.

    • 12

relate perguntas