Início / unix / Perguntas / 684104
Accepted
Semnodime
Asked: 2021-12-28 11:23:45 +0800 CST

Bit Rot dentro da criptografia LUKS

  • 772

Como a podridão de bits afeta um contêiner LUKS e o sistema de arquivos dentro?

Suponha que você tenha um sistema de arquivos adequado para lidar com a podridão de bits. Agora coloque-o dentro de um contêiner LUKS. Caso o bit rot tenha corrompido o contêiner, presumo que o sistema de arquivos descriptografado sofrerá grandes quantidades de bytes / blocos brutos corrompidos.

Como o LUKS protege contra isso?

filesystems luks

2 respostas

  1. Best Answer

    Bitrot no cabeçalho LUKS (chave e material crítico): é *poof* desaparecido.

    (Há um pouco de redundância e soma de verificação para o cabeçalho LUKS2, mas não cobre muito, então as chances são... ainda está desaparecido).

    Bitrot em dados criptografados: depende do modo de criptografia, mas em geral, um único bit flip resultará em 16 bytes errados.

    Configure a criptografia:

    # truncate -s 32M bitrottest.img
# cryptsetup luksFormat bitrottest.img
# cryptsetup luksOpen bitrottest.img bitrottest

    Faça tudo zero:

    # shred -n 0 -z /dev/mapper/bitrottest 
# hexdump -C /dev/mapper/bitrottest 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000000

    Vire um pouco:

    # losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE           DIO LOG-SEC
/dev/loop0         0      0         1  0 bitrottest.img        0    4096
# dd bs=1 count=1 skip=30M if=/dev/loop0 | hexdump -C
00000000  a2                                                |.|
00000001
# printf "\xa3" | dd bs=1 count=1 seek=30M of=/dev/loop0
# dd bs=1 count=1 skip=30M if=/dev/loop0 | hexdump -C
00000000  a3                                                |.|
00000001

    Resultado:

    # hexdump -C /dev/mapper/bitrottest 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00e00000  eb d1 bd b0 2a f5 77 73  35 df 82 40 1e a7 27 11  |....*.ws5..@..'.|
00e00010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000000

    Um bit invertido, 16 bytes malucos.

    Proteção? Nenhum. Para isso, você teria que adicionar integridade (apenas para relatar erros, a redundância ainda é um problema separado disso).

    Você não deve gravar deliberadamente dados corrompidos em seu armazenamento.

    O armazenamento deve relatar erros de leitura em vez de retornar dados falsos. Nesse caso, seus dados ainda desapareceram, mas pelo menos não é um bitrot silencioso .

    • 18

  2. O próprio LUKS não protege contra a podridão de bits. Se você deseja proteção contra a podridão de bits no nível do dispositivo de bloco, você precisa da integridade do DM . O LUKS 2 pode ser combinado com integridade para obter criptografia autenticada ( cryptsetup luksFormatcom --integrity) e com esse sistema será capaz de detectar que os dados foram alterados, mas isso não é realmente útil contra a podridão de bits - o setor simplesmente fornecerá um erro de IO se você tenta ler e não sabe como resolver. (O objetivo do AEAD é detectar que alguém alterou os dados criptografados.)

    Para corrigir os dados, você precisará do RAID 1 e do dispositivo de integridade autônomo sob as pernas do RAID para possibilitar a autocura (isso funciona automaticamente, o RAID obtém o erro de IO de uma perna, lê os dados da outra e corrige (tenta ) o primeiro). O novo systemd 250 adicionou suporte para montagem de dispositivos de integridade durante a inicialização /etc/integritytab(para sistemas de arquivos não raiz) para que você possa tentar isso. Mas tudo isso precisa ser feito "abaixo" do nível LUKS para que funcione como @frostschutz mostrou em sua resposta porque o erro precisa ser corrigido nos dados criptografados.

    • 7

relate perguntas