Os dados da soma de verificação ecryptfs (talvez implicitamente)?

Question

Estou planejando configurar um NAS com ecryptfs usados para criptografia. Eu estou querendo saber se o ecryptfs vai me dizer se um arquivo foi silenciosamente corrompido (por exemplo, um disco rígido com defeito), ou se eu ainda estaria dependente do sistema de arquivos subjacente para fazer a verificação de dados para mim?

Eu posso usar o btrfs como o sistema de arquivos subjacente para obter o recurso de snapshot, mas eu ainda estaria interessado em saber se, por exemplo, ext4 + ecryptfs forneceria as mesmas garantias de corrupções de arquivos ocultos como btrfs simples (ou btrfs + ecrypts) seria, por causa das características de checksum do btrfs.

    

Answer 1

A resposta acima está incorreta. A implementação real do eCryptFS não inclui dados de soma de verificação por padrão ou de forma alguma. Demonstração simples:

$ mkdir /tmp/front /tmp/back
$ sudo mount -o key=passphrase:passwd=Test,ecryptfs_hmac,ecryptfs_enable_filename_crypto=no,ecryptfs_passthrough=no,ecryptfs_unlink_sigs,ecryptfs_key_bytes=16,ecryptfs_cipher=aes -t ecryptfs /tmp/back/ /tmp/front/
$ echo HelloWorld > /tmp/front/HelloWorld.txt
$ cat /tmp/front/HelloWorld.txt
HelloWorld
$ sudo umount /tmp/front
$ printf "deadbeaf" | dd  of=/tmp/back/HelloWorld.txt  bs=1 seek=8192 count=8 conv=notrunc
$ sudo mount -o key=passphrase:passwd=Test,ecryptfs_hmac,ecryptfs_enable_filename_crypto=no,ecryptfs_passthrough=no,ecryptfs_unlink_sigs,ecryptfs_key_bytes=16,ecryptfs_cipher=aes -t ecryptfs /tmp/back/ /tmp/front/
$ cat /tmp/front/HelloWorld.txt
<garbage>

Além disso:

$ ecryptfs-stat /tmp/back/HelloWorld.txt 
File version: [3]
Decrypted file size: [11]
Number of header bytes at front of file: [8192]
Metadata in the header region
Encrypted
HMAC disabled

O eCryptfs não apresenta um erro de leitura ou qualquer indicação de que algo está errado. Note que isto é par com a opção ecryptfs_hmac , que deveria habilitar checksum, mas aparentemente não. O código-fonte real do ecryptfs contém código HMAC, então não sei por que isso não está funcionando. Pesquisa rápida no Google indica que o código HMAC pode estar incompleto. Ainda não olhei mais fundo nisso.

    

Answer 2

eCryptFS faz os dados da soma de verificação. Existe um um documento que descreve como o eCryptFS funciona . Uma das coisas que o eCryptFS faz é proteger contra adulteração do arquivo por adversários, e para isso ele calcula um HMAC e o armazena com o arquivo criptografado. Como um bônus, isso obviamente também protege contra "adulterações" acidentais, como por raios cósmicos, ruído eletrônico ou simples desgaste (descrito coletivamente por bit rot ).

No entanto, btrfs faz uma coisa adicional que eu tenho certeza que eCryptFS não faz: espelhamento / replicação e paridade. Com o espelhamento (RAID1) ou paridade (RAID5 ou RAID6), o btrfs é capaz de encontrar automaticamente uma boa cópia de um pedaço de arquivo, caso ele detecte corrupção na peça sendo lida atualmente. A Ars Technica tem um artigo muito bom sobre corrupção e como utilizar melhor o recurso do btrfs ou do ZFS para manter os dados seguros.

Se você usar o ext4 e o eCryptFS , na melhor das hipóteses você saberá que algo foi corrompido ou adulterado, mas você precisará intervir manualmente para lidar com o problema. Eu recomendaria ficar com btrfs e eCryptFS , que fornece soma de verificação (contanto que você não desative o copy-on-write) e também possa manter cópias redundantes de dados (usando RAID1, RAID5, RAID6, ou RAID10).