Назад | Перейти на главную страницу

Имеет ли ecryptfs (возможно, неявно) данные контрольной суммы?

Я планирую настроить NAS с использованием ecryptfs для шифрования. Мне интересно, сообщит ли ecryptfs мне, был ли файл поврежден незаметно (например, неисправным жестким диском), или я все еще буду зависеть от базовой файловой системы, чтобы выполнить контрольную сумму данных для меня?

Я могу использовать btrfs в качестве базовой файловой системы в любом случае, чтобы получить функцию моментального снимка, но мне все равно было бы интересно узнать, предоставит ли, например, ext4 + ecryptfs те же гарантии от повреждения скрытых файлов, что и обычные btrfs (или btrfs + ecrypts), потому что функций контрольной суммы btrfs.

Приведенный выше ответ неверен. Фактическая реализация eCryptFS делает не данные контрольной суммы по умолчанию или вообще. Простая демонстрация:

$ 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>

Также:

$ 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

eCryptfs не выдает ошибок чтения или каких-либо указаний на то, что что-то не так. Обратите внимание, что это даже с ecryptfs_hmac опция, которая должна включать контрольную сумму, но, по-видимому, не работает. Фактический исходный код ecryptfs действительно содержит код HMAC, поэтому я не уверен, почему это не работает. Быстрый поиск в Google показывает, что код HMAC может быть неполным. Еще не заглянул в это глубже.

eCryptFS делает данные контрольной суммы. Есть документ, описывающий, как работает eCryptFS. Одна из функций eCryptFS - защита от несанкционированного доступа к файлу злоумышленниками. Для этого она вычисляет HMAC и сохраняет его вместе с зашифрованным файлом. В качестве бонуса это, очевидно, также защищает от случайного «вмешательства», например, космическими лучами, электронным шумом или простым износом (в совокупности описываемым немного гнить).

Тем не мение, btrfs делает еще одну вещь, в которой я уверен eCryptFS не делает: зеркалирование / репликация и четность. Благодаря зеркалированию (RAID1) или четности (RAID5 или RAID6) btrfs может автоматически найти хорошую копию фрагмента файла, если обнаружит повреждение фрагмента, который в данный момент читается. Ars Technica имеет очень хорошая статья о коррупции и о том, как наилучшим образом использовать функцию btrfs или ZFS для обеспечения безопасности данных.

Если вы идете с ext4 и eCryptFS, в лучшем случае вы будете знать только, что что-то было повреждено или подделано, но вам придется вручную вмешаться, чтобы решить проблему. Я бы порекомендовал придерживаться btrfs и eCryptFS, который обеспечивает как контрольную сумму (при условии, что вы не отключите копирование при записи), так и может поддерживать избыточные копии данных (с использованием RAID1, RAID5, RAID6 или RAID10).