Não consigo abrir uma das minhas partições LUKS no Raspberry PI devido à restrição de memória. Já descobri que a sugestão neste caso érecrie a partição no dispositivo mais lento, que irá acessá-la(neste caso o Raspberry PI).
No entanto, estou preocupado com a possível diminuição do nível de segurança (provavelmente, com menos poder de computação, uma chave mais fraca será usada).
Isto é o que a documentação do cryptsetup diz sobre o problema:
Nota: A iteração da senha é determinada pelo cryptsetup dependendo da potência da CPU. Em um dispositivo lento, isso pode ser menor do que você deseja. Recentemente, comparei isso em um Raspberry Pi e o resultado foi cerca de 1/15 da contagem de iterações de um PC típico. Se a segurança for fundamental, você pode querer aumentar o tempo gasto na iteração, ao custo de um desbloqueio mais lento posteriormente. Para o Raspberry Pi, usando
cryptsetup luksFormat -i 15000 <target device>fornece uma contagem de iterações e um nível de segurança iguais a um PC médio para iteração de senha e iteração de chave mestra. Em caso de dúvida, verifique a contagem de iterações com
cryptsetup luksDump <target device>e ajuste a contagem de iterações de acordo criando o contêiner novamente com um tempo de iteração diferente (o número após '-i' é o tempo de iteração em milissegundos) até que seus requisitos sejam atendidos.
Agora, não tenho certeza do que acontecerá se eu seguir o conselho acima.
- A partição será tão segura quanto em um PC?(se o número de iterações estiver correto), apenas mais lento?
- Se for mais lento, apenas o desbloqueio é mais lento ou as leituras/gravações posteriores são tão rápidas quanto sem a iteração extra? (Se sim, por quê? É porque ao desbloquear apenas descriptografamos a chave que será usada posteriormente para descriptografar o conteúdo da partição?)
- Ainda consumirá menos memória do que a partição criada em um PC rápido? (Em outras palavras: quero recriar a partição para poder usá-la com Raspberry PI. Com os valores padrão ela será utilizável, mas menos segura. Ainda será utilizável com o aumento da contagem de iterações, ou seria novamente consumir muita memória?)
Responder1
Primeiro, observe que a documentação do LUKS que você estava lendo foi escrita para o LUKS1 e está um tanto desatualizada agora. Tudo o que você citou (por exemplo, contagem de iterações) é específico para o algoritmo PBKDF2, que sua partiçãona verdade não usa.
LUKS2 suporta dois algoritmos para converter sua senha em uma chave: o PBKDF2 tradicional e também o Argon2 mais recente. Este último é o que o LUKS agora usa por padrão e é o único que possui uma quantidade mínima (ajustável) de memória necessária. Isso não é a mesma coisa que "contagem de iterações".
No entanto, estou preocupado com a possível diminuição do nível de segurança (provavelmente, com menos poder de computação, uma chave mais fraca será usada).
Você não está ajustando a força da tecla, você está ajustando a tonalidadeproteção.
Os parâmetros que você está ajustando têm como objetivo proteger contra alguém que tente atacar a senha que você está inserindo – eles evitam ataques de força bruta (ou seja, tentar várias senhas seguidas), tornando o processo de derivação de chave incrivelmente lento.
No entanto, a chave produzida é sempre igualmente forte por si só (é tão boa quanto qualquer outra chave AES) e ninguém se incomodaria em atacá-la diretamente.
Se for mais lento, apenas o desbloqueio é mais lento ou as leituras/gravações posteriores são tão rápidas quanto sem a iteração extra? (Se sim, por quê? É porque ao desbloquear apenas descriptografamos a chave que será usada posteriormente para descriptografar o conteúdo da partição?)
Cada vez que você desbloqueia o volume, o LUKS converte sua senha em uma chave de criptografia usando uma "função de derivação de chave" (um KDF) para que o processo seja mais resistente a ataques de força bruta - o LUKS1 sempre usou 'PBKDF2', que é resistente por significa ser lento para calcular (mas não impõe nenhum requisito de memória), enquanto o LUKS2 suporta adicionalmente 'Argon2', que requer uma certa quantidade de RAM.
A derivação da chave acontece apenas uma vez no momento do desbloqueio; o resto (criptografia de dados real) não precisa envolver senhas.
(Em outras palavras: quero recriar a partição para poder usá-la com Raspberry PI. Com os valores padrão ela será utilizável, mas menos segura. Ainda será utilizável com o aumento da contagem de iterações, ou seria novamente consumir muita memória?)
Você não precisa recriar a partição, porque mesmo a chave derivada da senha não é usada para criptografar seus dados diretamente: ela criptografa apenas omestrechave armazenada no cabeçalho do volume LUKS.
É por isso que é possível alterar rapidamente a senha sem a necessidade de criptografar novamente todo o disco (ou mesmo ter múltiplas senhas), e da mesma forma o LUKS permite que você altere os parâmetros KDF com a mesma facilidade.
Se os parâmetros padrão do Argon2 usarem muita memória, diga isso ao LUKS:
cryptsetup luksConvertKey --pbkdf "argon2i" --pbkdf-memory <num_kilobytes> <device>Se você não puder usar o Argon2, ainda poderá dizer ao LUKS para usar o PBKDF2:
cryptsetup luksConvertKey --pbkdf "pbkdf2" --iter-time <milliseconds> <device>Em vez de milissegundos (que dependem do dispositivo), você pode especificar diretamente o número de PBKDF2iteraçõesque você deseja (que sempre dá o mesmo resultado, não importa em qual dispositivo você faça isso) – o padrão em um PC é algo em torno de um milhão:
cryptsetup luksConvertKey --pbkdf "pbkdf2" --pbkdf-force-iterations <count> <target>
As mesmas opções são aceitas por luksChangeKey(ao alterar a senha), na verdade parece que elasprecisara ser especificado sempre que você alterar a senha.