Есть ли в ecryptfs (возможно, неявно) данные контрольной суммы?
Я планирую настроить NAS с ecryptfs, используемым для шифрования. Мне интересно, скажет ли мне ecryptfs, был ли файл незаметно поврежден (например, из-за неисправного жесткого диска), или я все еще зависел бы от базовой файловой системы, чтобы выполнить контрольную сумму данных для меня?
В любом случае я могу использовать btrfs в качестве базовой файловой системы для получения функции моментального снимка, но мне все равно было бы интересно узнать, будет ли, например, ext4 + ecryptfs обеспечивать те же гарантии против скрытых повреждений файлов, что и обычные btrfs (или btrfs + ecrypts), потому что контрольных сумм функций btrfs.
2 ответа
Приведенный выше ответ неверен. Реальная реализация 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).