Неделю назад нарисовалась нетривиальная задача по определению возможностей использования шифрованных контейнеров или файловых систем на вынесенном untrusted хостинге.
Основные задачи:
— Возможность бекапирования данных в любом виде для аварийного восстановления.
— Исключение доступа к этим данным неавторизованных лиц.
— Невозможность доступа к файлам при аварийном выключении сервера и загрузке с внешнего носителя.
— Прозрачная работа пользователей с файлами и любым содержимым находящемся на сервере.
— OS FreeBSD 7.2 и максимальный простор для фантазии в выборе вариантов реализации.
После энного количества времени сложилась следующая тестовая конфигурация:
GELI — GEOM_ELI (встроенная во FreeBSD подсистема шифрования использующая crypto(9) framework(аппаратное и программное шифрование))
GBDE — GEOM_BDE [Geom Based Disk Encryption] (встроенная во FreeBSD подсистема шифрования)
TrueCrypt — Портированная версия TrueCrypt 6.1a (использует fuse)
cryptofs — cryptofs использующая fuse
encfs — encfs использующая fuse
UPD: Таблица сравнения скоростей чистой и шифрованной файловых систем.
Начнем с классификации используемых систем шифрования.
Первые две системы используют любое устройство определяемое через GEOM. Это может быть физический накопитель(da0), партиция(da0s1), слайс(da0s1a), а также любое другое синтетическое устройство созданное скажем через mdconfig или ggatel.
mdconfig — утилита использующая geom_md и формирующая виртуальное устройство из имеющейся у Вас оперативной памяти или файла на диске или любом другом носителе.
ggatel — это утилита которая позволяет перевести любое устройство или файл, которое не может быть отнесено к классу GEOM в этот класс.
TrueCrypt — автономная кроссплатформенная система шифрования криптоконтейнеров.
fuse_cryptofs — подсистема парольного шифрования данных на диске шифрующая имена файлов и их содержимое при помощи алгоритмов заданных в конфигурационном файле.
fuse_encfs — подсистема парольно-ключевого шифрования данных на диске шифрующая имена файлов и их содержимое с контролем изменений в файлах.
Все тесты проводились на системе имеющей следующие характеристики P4 2.8HT/1GB RAM/40GB IDE/.
Для оценки скорости работы использовались dd и bonnie.
Временные файлы криптоконтейнеров и директории с файлами были размещены на разделе /var.
Первым делом нужно было оценить какую скорость линейной записи на жёсткий диск мы можем получить в пике.
Т.е. максимально мы можем рассчитывать примерно на 27 мегабайт/с при потоковой записи.
Для анализа скорости работы GEOM провайдеров был создан файл размером 4GB, который по очереди подключался к mdconfig и ggatel(размер сектора был определен в 4Кб). Далее по тексту я постараюсь максимально исключить лишнюю служебную информацию из вставок кода.
Мы проверили линейную скорость записи через GEOM провайдеров.
Как видно из тестов скорость записи упала почти в 2 раза и ggate провайдер оказался немного медленнее чем md, но в принципе это не особо критично, хотя ggate немного больше грузит систему чем md.
Следующий шаг это проверка нагрузочной способности для файловых систем работающих через GEOM провайдеров. Первым тестировался md.
Как мы видим скорость работы с файлами возросла и составила 17.1 мегабайт/сек.
Вторым тестировали ggate.
При прочих равных условиях ggate показал увеличение скорости по сравнению с md — 17.6 мегабайт/сек.
Настало время потестировать связку crypto и geom провайдеров. Для этого создали случайный ключ, который будет использоваться в дальнейших тестах.
Инициализируем криптоконтейнер geli
Как видно из вывода time, geli init довольно долго просчитывает связку ключа шифрования с паролем и записывает его на диск.
Криптоконтейнер создан и сформировано новое устройство с суффиксом .eli, которое можно использовать как обычное блочное устройство. Размечать его, создавать партиции и файловые системы.
Создаём новую файловую систему на криптоконтейнере и тестируем скорость.
Как мы видим, скорость упала до 14.5 мегабайт/сек. Я пропущу блок разметки и тестирования скорости связки ggate+geli, так как он идентичен блоку geli+md. Так как мы не можем оценивать скорость работы только по циклу записи, мы запускаем bonnie для дополнительного анализа.
Сводные результаты работы bonnie на всех связках будут приведены в конце статьи.
Как мы видим ggate медленнее работает на циклах записи, но намного быстрее работает на циклах чтения. Возможно это связано с буферизацией записи и различных методах сброса буферов в md и ggate. Если попробовать ввести неверный файл ключа или пароль, то geli не создаёт устройство для доступа к файловой системе, а так как файл контейнера внутри напоминает содержимое /dev/random, то расшифровать его просто нереально. Ни пофайлово, ни целиком. Одним из преимуществ geli является возможность использования нескольких ключей шифрования, скажем мастер ключа и ключа пользователей.
Инициализируем контейнер GBDE.
gbde при создании устройства использует файл блокировки в котором находятся текущие ключи для инициализации криптоконтейнера. Система инициализации криптоконтейнера не имеет реверсивной процедуры восстановления данных, поэтому если вы забыли пароль или потеряли файл блокировки, то вы потеряли все данные которые находились в криптоконтейнере. После инициализации криптоконтейнера gbde создаёт устройство с суффиксом .bde с которым можно обращаться так же как и c .eli.
Подробное руководство по использованию обоих систем можно найти тут. Запускаем bonnie для тестирования связки gbde+md и gbde+ggate.
Подсистема gbde показала довольно скудные значения быстродействия, хотя как видно из таблицы процессорное время практически не использовалось в отличии от geli. С чем это связано я так до конца и не выяснил.
Найдя в сети неофициальный порт TrueCrypt 6.1a на FreeBSD, было решено испытать его в работе.
TrueCrypt должен работать на FreeBSD через fuse, но на деле всё оказалось не совсем так.
Попытка скомпилить данный порт привела к тому, что в систему были затащены xorg, glib, gtk, gnome, wxWidgets и куча другого барахла. Детальный анализ выявил, что виной всему GUI интерфейс сделанный на wxWidgets. Нам GUI был ненужен и поэтому путём проб и ошибок были найдены магические последовательности для gmake которые таки собрали TrueCrypt на нашей тестовой системе.
TrueCrypt запустился весело сообщив:
Ругань относилась к тому, что TrueCrypt не смог конвертнуть help из LANG=C в en_US.UTF-8, который жестко зашит в исходниках.
Созданный раздел без проблем смонтировался.
Но нас постигло жестокое разочарование. Вопреки ожидаемому использованию fusefs, TrueCrypt стал использовать трансляцию своего endpoint файла через md. Таким образом мы получили еще один лишний стык в преобразовании криптоконтейнера. Разочарование стало еще большим когда при попытке записи данных на примонтированный TrueCrypt Volume мы получили deadlock после того как исчерпались буфера записи для vfs. Танцы с бубном вокруг TrueCrypt, настроек vfs и многого другого ни к чему не привели и мы забросили идею нормального тестирования TrueCrypt. К сожалению текущая сборка TrueCrypt может создавать только две файловые системы независимо от OS, FAT и NTFS, это жестко запрограммировано в исходных кодах. Создание файловой системы на отмонтированном Volume вполне решает проблему использования msdosfs, но не решает проблему deadlock.
Так как тестируемые криптоконтейнеры у нас закончились, мы попытались реализовать какуюнибудь схему резервного копирования этих контейнеров. В общем тут нас ожидало не менее грустное обстоятельство, чем проблемы с TrueCrypt. Мы попытались сделать snapshot на файловой системе на которой находится подмонтированный криптоконтейнер и выцепив оттуда файл контейнера посмотреть на его содержимое. Но тут же поймали проблему. При активных файловых операциях с криптоконтейнером попытка сделать snapshot приводит к deadlock. Система вроде бы живая, но в тоже время обратиться к примонтированному контейнеру нельзя, а впоследствии умирает доступ ко всем системным разделам :(
При отсутствии операций с криптоконтейнером snapshot происходит нормально, но вероятность последующего deadlock тоже не исключена. Причем с md устройствами проблема проявляется раньше чем с ggate. После deadlock и последующей принудительной dirty(reboot -qn) перезагрузки, криптоконтейнер необходимо сначала проверить через fsck, иначе он не примонтируется. Выдернутый же криптоконтейнер из snapshot на поверку оказывается битым, с отсутствующей файловой системой и без наших данных. Что очень и очень грустно. Ну да ладно, нельзя использовать online бекап, значит 100% можно использовать offline бекап. На этом с криптоконтейнерами и остановимся.
Вторая часть тестирования связана с использованием fusefs.
Для тестирования были выбраны cryptofs и encfs. Разница между системами небольшая и основное отличие заключается в том, что encfs поддерживает параноидальный режим безопасности проверяющий целостность файлов.
cryptofs создаёт шлюз который шифрует проходящие через него данные при помощи пароля заданного пользователем, используя обычную файловую систему на машине. Для работы системы требуется поместить в директорию, которая будет домашней, файл с настройками .cryptofs
Настройки — это список алгоритмов шифрования, которые будут использоваться в работе. К сожалению месторасположение файла изменить нельзя :(
Система очень легка в использовании, но имеет один недостаток. Если Вы случайно ошиблись буквой или цифрой при вводе пароля — система зашифрует данные именно тем паролем который Вы набрали. Велика вероятность того, что Вы заметите это не сразу, а пользователи уже нальют файлов которые будут зашифрованы новым паролем. Файловая система после ввода неверного пароля выглядит примерно вот так.
encfs данной проблемы лишён, но имеет уже намного более широкие настройки по шифрованию, а также в конфигурационном файле создаёт уникальный ключ. При помощи этого ключа encfs определяет корректность ввода пароля, правильность шифрования файлов, а также определяет какие файлы показывать или не показывать(имеется ввиду — шифрованные именно этим ключом). Если Вы забыли пароль, то можете смело удалять все данные, восстановлению они не подлежат. Процесс работы выглядит следующим образом.
Бекапирование данных можно осуществлять методом обычного снятия снепшотов с раздела, а также прямым копированием файлов в требуемое место, главное сохранить ключи для возможности обратной расшифровки ;)
Выводы: Все исследуемые в данной статье методы шифрования данных на дисках имеют право на использование в повседневной жизни. В зависимости от используемых систем шифрования, Вы можете получить нужный Вам функционал за короткий промежуток времени. Из тестируемых мною систем я бы всё таки остановил свой выбор на geli и encfs. Первая система очень привлекательна с точки зрения использования аппаратных модулей шифрования, при использовании которых не будет затрачиваться процессорное время на шифрование данных, а также возможностью шифрования разделов целиком. Вторая система интересна режимами контроля целостности шифруемых файлов и возможностями изменения множества параметров. При всём уважении к encfs хочется отметить зависимость системы от нескольких внешних библиотек которые придётся таскать с собой. Опять же с geli могут возникнуть проблемы с резервным копированием массивов большого объёма. Ну вот в общем-то и всё. Спасибо за уделённое время на прочтение данного материала.
Сравнительная таблица тестов bonnie по всем системам.
UPD: Таблица сравнения скоростей чистой файловой системы и шифрованной. С включенными и выключенными softupdates.
Основные задачи:
— Возможность бекапирования данных в любом виде для аварийного восстановления.
— Исключение доступа к этим данным неавторизованных лиц.
— Невозможность доступа к файлам при аварийном выключении сервера и загрузке с внешнего носителя.
— Прозрачная работа пользователей с файлами и любым содержимым находящемся на сервере.
— OS FreeBSD 7.2 и максимальный простор для фантазии в выборе вариантов реализации.
После энного количества времени сложилась следующая тестовая конфигурация:
GELI — GEOM_ELI (встроенная во FreeBSD подсистема шифрования использующая crypto(9) framework(аппаратное и программное шифрование))
GBDE — GEOM_BDE [Geom Based Disk Encryption] (встроенная во FreeBSD подсистема шифрования)
TrueCrypt — Портированная версия TrueCrypt 6.1a (использует fuse)
cryptofs — cryptofs использующая fuse
encfs — encfs использующая fuse
UPD: Таблица сравнения скоростей чистой и шифрованной файловых систем.
Начнем с классификации используемых систем шифрования.
Первые две системы используют любое устройство определяемое через GEOM. Это может быть физический накопитель(da0), партиция(da0s1), слайс(da0s1a), а также любое другое синтетическое устройство созданное скажем через mdconfig или ggatel.
mdconfig — утилита использующая geom_md и формирующая виртуальное устройство из имеющейся у Вас оперативной памяти или файла на диске или любом другом носителе.
ggatel — это утилита которая позволяет перевести любое устройство или файл, которое не может быть отнесено к классу GEOM в этот класс.
TrueCrypt — автономная кроссплатформенная система шифрования криптоконтейнеров.
fuse_cryptofs — подсистема парольного шифрования данных на диске шифрующая имена файлов и их содержимое при помощи алгоритмов заданных в конфигурационном файле.
fuse_encfs — подсистема парольно-ключевого шифрования данных на диске шифрующая имена файлов и их содержимое с контролем изменений в файлах.
Все тесты проводились на системе имеющей следующие характеристики P4 2.8HT/1GB RAM/40GB IDE/.
Для оценки скорости работы использовались dd и bonnie.
Временные файлы криптоконтейнеров и директории с файлами были размещены на разделе /var.
# dmesg | grep ad0<br/>ad0: 38166MB <Seagate ST340014A 3.06> at ata0-master UDMA100<br/># mount | grep var<br/>/dev/ad0s1g on /var (ufs, local, soft-updates) <br/>Первым делом нужно было оценить какую скорость линейной записи на жёсткий диск мы можем получить в пике.
<br/>testcrypt# /usr/bin/time dd if=/dev/random of=testfile.dump bs=1m count=4096<br/>4096+0 records in<br/>4096+0 records out<br/>4294967296 bytes transferred in 151.801076 secs (28293392 bytes/sec)<br/> 151.82 real 0.00 user 132.96 sys <br/>Т.е. максимально мы можем рассчитывать примерно на 27 мегабайт/с при потоковой записи.
Для анализа скорости работы GEOM провайдеров был создан файл размером 4GB, который по очереди подключался к mdconfig и ggatel(размер сектора был определен в 4Кб). Далее по тексту я постараюсь максимально исключить лишнюю служебную информацию из вставок кода.
Мы проверили линейную скорость записи через GEOM провайдеров.
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/dev/md0 bs=1m<br/>4294967296 bytes transferred in 306.514082 secs (14012300 bytes/sec)<br/> 306.55 real 0.02 user 120.03 sys<br/>testcrypt# mdconfig -d -u 0<br/> <br/>testcrypt# ggatel create -s 4096 -u 0 /var/test/testfile.dump<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/dev/ggate0 bs=1m<br/>4294967296 bytes transferred in 319.859650 secs (13427662 bytes/sec)<br/> 319.91 real 0.02 user 133.34 sys<br/>testcrypt# ggatel destroy -u 0 <br/>Как видно из тестов скорость записи упала почти в 2 раза и ggate провайдер оказался немного медленнее чем md, но в принципе это не особо критично, хотя ggate немного больше грузит систему чем md.
Следующий шаг это проверка нагрузочной способности для файловых систем работающих через GEOM провайдеров. Первым тестировался md.
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0<br/>testcrypt# newfs /dev/md0<br/>/dev/md0: 4096.0MB (8388608 sectors) block size 16384, fragment size 4096<br/> using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.<br/>super-block backups (for fsck -b #) at:<br/> 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312,<br/>6211456, 6901600, 7591744, 8281888<br/>testcrypt# mount /dev/md0 /mnt<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m<br/>4220518400 bytes transferred in 235.262614 secs (17939605 bytes/sec)<br/> 235.28 real 0.03 user 136.49 sys<br/>testcrypt# umount /mnt<br/>testcrypt# mdconfig -d -u 0<br/>Как мы видим скорость работы с файлами возросла и составила 17.1 мегабайт/сек.
Вторым тестировали ggate.
<br/>testcrypt# ggatel create -s 4096 -u 0 /var/test/testfile.dump<br/>testcrypt# newfs /dev/ggate0<br/>/dev/ggate0: 4096.0MB (8388608 sectors) block size 16384, fragment size 4096<br/> using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.<br/>super-block backups (for fsck -b #) at:<br/> 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888<br/>testcrypt# mount /dev/ggate0 /mnt<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m<br/>4220518400 bytes transferred in 228.256445 secs (18490249 bytes/sec)<br/> 228.29 real 0.00 user 137.80 sys<br/>testcrypt# umount /mnt<br/>testcrypt# ggatel destroy -u 0<br/>При прочих равных условиях ggate показал увеличение скорости по сравнению с md — 17.6 мегабайт/сек.
Настало время потестировать связку crypto и geom провайдеров. Для этого создали случайный ключ, который будет использоваться в дальнейших тестах.
testcrypt# dd if=/dev/random of=/var/test/my.key bs=4k count=1 Инициализируем криптоконтейнер geli
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0<br/>testcrypt# /usr/bin/time geli init -s 4096 -K my.key /dev/md0<br/>Enter new passphrase:<br/>Reenter new passphrase:<br/> 13.34 real 9.61 user 0.00 sys<br/>Как видно из вывода time, geli init довольно долго просчитывает связку ключа шифрования с паролем и записывает его на диск.
testcrypt# geli list<br/>Geom name: md0.eli<br/>EncryptionAlgorithm: AES-CBC<br/>KeyLength: 128<br/>Crypto: software<br/>UsedKey: 0<br/>Flags: NONE<br/>Providers:<br/>1. Name: md0.eli<br/> Mediasize: 4294963200 (4.0G)<br/> Sectorsize: 4096<br/> Mode: r0w0e0<br/>Consumers:<br/>1. Name: md0<br/> Mediasize: 4294967296 (4.0G)<br/> Sectorsize: 4096<br/> Mode: r1w1e1<br/>Криптоконтейнер создан и сформировано новое устройство с суффиксом .eli, которое можно использовать как обычное блочное устройство. Размечать его, создавать партиции и файловые системы.
Создаём новую файловую систему на криптоконтейнере и тестируем скорость.
testcrypt# newfs /dev/md0.eli<br/>/dev/md0.eli: 4096.0MB (8388600 sectors) block size 16384, fragment size 4096<br/> using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.<br/>super-block backups (for fsck -b #) at:<br/> 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m<br/>4220518400 bytes transferred in 277.940331 secs (15184980 bytes/sec)<br/> 277.96 real 0.03 user 145.50 sys<br/>Как мы видим, скорость упала до 14.5 мегабайт/сек. Я пропущу блок разметки и тестирования скорости связки ggate+geli, так как он идентичен блоку geli+md. Так как мы не можем оценивать скорость работы только по циклу записи, мы запускаем bonnie для дополнительного анализа.
Сводные результаты работы bonnie на всех связках будут приведены в конце статьи.
testcrypt# bonnie -s 1024<br/>File './Bonnie.1145', size: 1073741824<br/>
Sequential Output
Sequential Input
Random
Per Char
Block
Rewrite
Per Char
Block
Seeks
Machine
MB
K/sec
%CPU
K/sec
%CPU
K/sec
%CPU
K/sec
%CPU
K/sec
%CPU
/sec
%CPU
geli+md
1024
17178
25.7
18324
8.4
5684
2.2
14492
15.1
15185
2.3
139.8
0.7
geli+ggate
1024
13855
20.6
12018
5.2
6388
2.7
19021
21.8
22473
4.2
136.5
0.7
Как мы видим ggate медленнее работает на циклах записи, но намного быстрее работает на циклах чтения. Возможно это связано с буферизацией записи и различных методах сброса буферов в md и ggate. Если попробовать ввести неверный файл ключа или пароль, то geli не создаёт устройство для доступа к файловой системе, а так как файл контейнера внутри напоминает содержимое /dev/random, то расшифровать его просто нереально. Ни пофайлово, ни целиком. Одним из преимуществ geli является возможность использования нескольких ключей шифрования, скажем мастер ключа и ключа пользователей.
Инициализируем контейнер GBDE.
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0<br/>testcrypt# gbde init /dev/md0 -i -K my.key -L /var/tmp/md0.lock -P testcrypt<br/>testcrypt# ll /var/tmp/md*<br/>md0.lock<br/>testcrypt# gbde attach /dev/md0 -l /var/tmp/md0.lock -k my.key -p testcrypt<br/>testcrypt# ll /dev/md*<br/>crw-r----- 1 root operator 0, 98 Apr 21 13:25 /dev/md0<br/>crw-r----- 1 root operator 0, 100 Apr 21 10:15 /dev/md0.bde<br/>crw------- 1 root wheel 0, 78 Apr 21 10:15 /dev/mdctlgbde при создании устройства использует файл блокировки в котором находятся текущие ключи для инициализации криптоконтейнера. Система инициализации криптоконтейнера не имеет реверсивной процедуры восстановления данных, поэтому если вы забыли пароль или потеряли файл блокировки, то вы потеряли все данные которые находились в криптоконтейнере. После инициализации криптоконтейнера gbde создаёт устройство с суффиксом .bde с которым можно обращаться так же как и c .eli.
Подробное руководство по использованию обоих систем можно найти тут. Запускаем bonnie для тестирования связки gbde+md и gbde+ggate.
testcrypt# bonnie -s 1024<br/>File './Bonnie.1145', size: 1073741824<br/>
Sequential Output
Sequential Input
Random
Per Char
Block
Rewrite
Per Char
Block
Seeks
Machine
MB
K/sec
%CPU
K/sec
%CPU
K/sec
%CPU
K/sec
%CPU
K/sec
%CPU
/sec
%CPU
gbde+md
1024
4436
5.3
4349
1.7
2695
1.2
12920
13.7
17078
2.9
130.1
0.7
gbde+ggate
1024
1971
2.2
1970
0.8
1480
0.6
13812
15.2
17206
3.0
120.3
0.6
Подсистема gbde показала довольно скудные значения быстродействия, хотя как видно из таблицы процессорное время практически не использовалось в отличии от geli. С чем это связано я так до конца и не выяснил.
Найдя в сети неофициальный порт TrueCrypt 6.1a на FreeBSD, было решено испытать его в работе.
TrueCrypt должен работать на FreeBSD через fuse, но на деле всё оказалось не совсем так.
Попытка скомпилить данный порт привела к тому, что в систему были затащены xorg, glib, gtk, gnome, wxWidgets и куча другого барахла. Детальный анализ выявил, что виной всему GUI интерфейс сделанный на wxWidgets. Нам GUI был ненужен и поэтому путём проб и ошибок были найдены магические последовательности для gmake которые таки собрали TrueCrypt на нашей тестовой системе.
gmake NOGUI=1 WX_ROOT=/usr/local/tmp/wx wxbuild<br/>gmake NOGUI=1 WXSTATIC=1 PKCS11_INC=/usr/local/include/pkcs11/<br/>TrueCrypt запустился весело сообщив:
testcrypt# truecrypt<br/>13:35:34: Error: Cannot convert from the charset 'US-ASCII'!Ругань относилась к тому, что TrueCrypt не смог конвертнуть help из LANG=C в en_US.UTF-8, который жестко зашит в исходниках.
testcrypt# /usr/bin/time truecrypt -c --filesystem=ufs -k /var/test/my.key --random-source=/dev/random /var/test/truecrypt.dump /mnt<br/>Volume type:<br/> 1) Normal<br/> 2) Hidden<br/>Select [1]:<br/> <br/>Enter volume size (sizeK/size[M]/sizeG): 4G<br/> <br/>Encryption algorithm:<br/> 1) AES<br/> 2) Serpent<br/> 3) Twofish<br/> 4) AES-Twofish<br/> 5) AES-Twofish-Serpent<br/> 6) Serpent-AES<br/> 7) Serpent-Twofish-AES<br/> 8) Twofish-Serpent<br/>Select [1]:<br/> <br/>Hash algorithm:<br/> 1) RIPEMD-160<br/> 2) SHA-512<br/> 3) Whirlpool<br/>Select [1]:<br/> <br/>Filesystem:<br/> 1) FAT<br/> 2) None<br/>Select [1]:<br/> <br/>Enter password:<br/>WARNING: Short passwords are easy to crack using brute force techniques!<br/>We recommend choosing a password consisting of more than 20 characters. Are you sure you want to use a short password? (y=Yes/n=No) [No]: y<br/>Re-enter password:<br/>Done: 100,000% Speed: 31 MB/s Left: 0 s<br/>The TrueCrypt volume has been successfully created.<br/> 139,42 real 204,75 user 13,80 sysСозданный раздел без проблем смонтировался.
testcrypt# truecrypt -k /var/test/my.key --mount /var/test/truecrypt.dump /mnt<br/>Enter password for /var/test/truecrypt.dump:<br/>Protect hidden volume? (y=Yes/n=No) [No]:<br/> <br/>testcrypt# mount<br/>...<br/>/dev/fuse0 on /var/tmp/.truecrypt_aux_mnt1 (fusefs, local, synchronous)<br/>/dev/md0 on /mnt (msdosfs, local)<br/> <br/>testcrypt# mdconfig -l -v<br/>md0 vnode 4.0G /var/tmp/.truecrypt_aux_mnt1/volume<br/>testcrypt# ll /var/tmp/.truecrypt_aux_mnt1/<br/>total 0<br/>-rw------- 1 root wheel 1522 21 апр 15:51 control<br/>-rw------- 1 root wheel 4294705152 21 апр 15:51 volumeНо нас постигло жестокое разочарование. Вопреки ожидаемому использованию fusefs, TrueCrypt стал использовать трансляцию своего endpoint файла через md. Таким образом мы получили еще один лишний стык в преобразовании криптоконтейнера. Разочарование стало еще большим когда при попытке записи данных на примонтированный TrueCrypt Volume мы получили deadlock после того как исчерпались буфера записи для vfs. Танцы с бубном вокруг TrueCrypt, настроек vfs и многого другого ни к чему не привели и мы забросили идею нормального тестирования TrueCrypt. К сожалению текущая сборка TrueCrypt может создавать только две файловые системы независимо от OS, FAT и NTFS, это жестко запрограммировано в исходных кодах. Создание файловой системы на отмонтированном Volume вполне решает проблему использования msdosfs, но не решает проблему deadlock.
Так как тестируемые криптоконтейнеры у нас закончились, мы попытались реализовать какуюнибудь схему резервного копирования этих контейнеров. В общем тут нас ожидало не менее грустное обстоятельство, чем проблемы с TrueCrypt. Мы попытались сделать snapshot на файловой системе на которой находится подмонтированный криптоконтейнер и выцепив оттуда файл контейнера посмотреть на его содержимое. Но тут же поймали проблему. При активных файловых операциях с криптоконтейнером попытка сделать snapshot приводит к deadlock. Система вроде бы живая, но в тоже время обратиться к примонтированному контейнеру нельзя, а впоследствии умирает доступ ко всем системным разделам :(
При отсутствии операций с криптоконтейнером snapshot происходит нормально, но вероятность последующего deadlock тоже не исключена. Причем с md устройствами проблема проявляется раньше чем с ggate. После deadlock и последующей принудительной dirty(reboot -qn) перезагрузки, криптоконтейнер необходимо сначала проверить через fsck, иначе он не примонтируется. Выдернутый же криптоконтейнер из snapshot на поверку оказывается битым, с отсутствующей файловой системой и без наших данных. Что очень и очень грустно. Ну да ладно, нельзя использовать online бекап, значит 100% можно использовать offline бекап. На этом с криптоконтейнерами и остановимся.
Вторая часть тестирования связана с использованием fusefs.
Для тестирования были выбраны cryptofs и encfs. Разница между системами небольшая и основное отличие заключается в том, что encfs поддерживает параноидальный режим безопасности проверяющий целостность файлов.
testcrypt# cryptofs -r /var/crypto/<br/>Enter password:<br/>testcrypt# mount_fusefs /dev/fuse0 /mnt<br/>testcrypt# df -h | grep mnt<br/>Filesystem Size Used Avail Capacity Mounted on<br/>/dev/fuse0 18G 5.1G 12G 30% /mntcryptofs создаёт шлюз который шифрует проходящие через него данные при помощи пароля заданного пользователем, используя обычную файловую систему на машине. Для работы системы требуется поместить в директорию, которая будет домашней, файл с настройками .cryptofs
# See README for details on each parameter<br/> <br/>[CryptoFS]<br/>cipher=AES256<br/>md=MD5<br/>blocksize=2048<br/>salts=256Настройки — это список алгоритмов шифрования, которые будут использоваться в работе. К сожалению месторасположение файла изменить нельзя :(
testcrypt# cp /etc/defaults/* /mnt<br/>testcrypt# ls /mnt/<br/>bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf<br/>testcrypt# ls /var/crypto/<br/>.cryptofs JuSxlpX8BzEtClI= MuKkkZS2WycuAUc= IO2ylZK9GjApQUWQR697gAD3Valf MOLpk4m8Ew== MuS1mYm2HCdvDE6bVw==Система очень легка в использовании, но имеет один недостаток. Если Вы случайно ошиблись буквой или цифрой при вводе пароля — система зашифрует данные именно тем паролем который Вы набрали. Велика вероятность того, что Вы заметите это не сразу, а пользователи уже нальют файлов которые будут зашифрованы новым паролем. Файловая система после ввода неверного пароля выглядит примерно вот так.
testcrypt# cryptofs -r /var/crypto<br/>Enter password:<br/>testcrypt# mount_fusefs /dev/fuse0 /mnt<br/>testcrypt# ls /mnt/<br/>i+???F9&??tg? i-???F~&T?} k-???L6 {"???M?1SA?l?????y??? }+????"0W?h<br/> <br/>encfs данной проблемы лишён, но имеет уже намного более широкие настройки по шифрованию, а также в конфигурационном файле создаёт уникальный ключ. При помощи этого ключа encfs определяет корректность ввода пароля, правильность шифрования файлов, а также определяет какие файлы показывать или не показывать(имеется ввиду — шифрованные именно этим ключом). Если Вы забыли пароль, то можете смело удалять все данные, восстановлению они не подлежат. Процесс работы выглядит следующим образом.
testcrypt# encfs /var/crypto /mnt<br/>Creating new encrypted volume.<br/>Please choose from one of the following options:<br/> enter "x" for expert configuration mode,<br/> enter "p" for pre-configured paranoia mode,<br/> anything else, or an empty line will select standard mode.<br/>?><br/> <br/>Standard configuration selected.<br/> <br/>Configuration finished. The filesystem to be created has<br/>the following properties:<br/>Filesystem cipher: "ssl/aes", version 2:1:1<br/>Filename encoding: "nameio/block", version 3:0:1<br/>Key Size: 192 bits<br/>Block Size: 1024 bytes<br/>Each file contains 8 byte header with unique IV data.<br/>Filenames encoded using IV chaining mode.<br/> <br/>Now you will need to enter a password for your filesystem.<br/>You will need to remember this password, as there is absolutely<br/>no recovery mechanism. However, the password can be changed<br/>later using encfsctl.<br/> <br/>New Encfs Password:<br/>Verify Encfs Password:<br/>testcrypt# mount | grep mnt<br/>/dev/fuse0 on /mnt (fusefs, local, synchronous)<br/>testcrypt# cp /etc/defaults/* /mnt<br/>testcrypt# ls /mnt<br/>bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf<br/> <br/>testcrypt# ls /var/crypto/<br/>.cryptofs Nq2IBppvuCpNNHuYS1k5dn-q wiNUtxqXvJqCLs3s-u1qwJrA<br/>.encfs6.xml gNsHASsB,5N2H1TZlWTJjldR<br/>B7rx58O9WjTGrjeTaiFXjREamAQzW7u3oK3NOK1KuN4Rp- sTZaWdYP4B-oXrW1d1COMMNVБекапирование данных можно осуществлять методом обычного снятия снепшотов с раздела, а также прямым копированием файлов в требуемое место, главное сохранить ключи для возможности обратной расшифровки ;)
Выводы: Все исследуемые в данной статье методы шифрования данных на дисках имеют право на использование в повседневной жизни. В зависимости от используемых систем шифрования, Вы можете получить нужный Вам функционал за короткий промежуток времени. Из тестируемых мною систем я бы всё таки остановил свой выбор на geli и encfs. Первая система очень привлекательна с точки зрения использования аппаратных модулей шифрования, при использовании которых не будет затрачиваться процессорное время на шифрование данных, а также возможностью шифрования разделов целиком. Вторая система интересна режимами контроля целостности шифруемых файлов и возможностями изменения множества параметров. При всём уважении к encfs хочется отметить зависимость системы от нескольких внешних библиотек которые придётся таскать с собой. Опять же с geli могут возникнуть проблемы с резервным копированием массивов большого объёма. Ну вот в общем-то и всё. Спасибо за уделённое время на прочтение данного материала.
Сравнительная таблица тестов bonnie по всем системам.
| Sequential Output | Sequential Input | Random | |||||||||||
| Per Char | Block | Rewrite | Per Char | Block | Seeks | ||||||||
| Machine | MB | K/sec | %CPU | K/sec | %CPU | K/sec | %CPU | K/sec | %CPU | K/sec | %CPU | /sec | %CPU |
| geli+md | 1024 | 17178 | 25.7 | 18324 | 8.4 | 5684 | 2.2 | 14492 | 15.1 | 15185 | 2.3 | 139.8 | 0.7 |
| geli+ggate | 1024 | 13855 | 20.6 | 12018 | 5.2 | 6388 | 2.7 | 19021 | 21.8 | 22473 | 4.2 | 136.5 | 0.7 |
| gbde+md | 1024 | 4436 | 5.3 | 4349 | 1.7 | 2695 | 1.2 | 12920 | 13.7 | 17078 | 2.9 | 130.1 | 0.7 |
| gbde+ggate | 1024 | 1971 | 2.2 | 1970 | 0.8 | 1480 | 0.6 | 13812 | 15.2 | 17206 | 3.0 | 120.3 | 0.6 |
| fusefs+cryptofs | 1024 | 17207 | 23.8 | 21015 | 10.7 | 6494 | 3.5 | 16202 | 17.1 | 16829 | 3.2 | 70.1 | 1.2 |
| fusefs+encfs | 1024 | 19073 | 25.3 | 23250 | 11.4 | 7676 | 3.9 | 16402 | 18.4 | 19187 | 3.5 | 70.3 | 1.2 |
UPD: Таблица сравнения скоростей чистой файловой системы и шифрованной. С включенными и выключенными softupdates.
| Sequential Output | Sequential Input | Random | |||||||||||
| Per Char | Block | Rewrite | Per Char | Block | Seeks | ||||||||
| Machine | MB | K/sec | %CPU | K/sec | %CPU | K/sec | %CPU | K/sec | %CPU | K/sec | %CPU | /sec | %CPU |
| fusefs+cryptofs | 1024 | 17207 | 23.8 | 21015 | 10.7 | 6494 | 3.5 | 16202 | 17.1 | 16829 | 3.2 | 70.1 | 1.2 |
| fusefs+encfs | 1024 | 19073 | 25.3 | 23250 | 11.4 | 7676 | 3.9 | 16402 | 18.4 | 19187 | 3.5 | 70.3 | 1.2 |
| cleanfs+su_on | 4096 | 33745 | 33.5 | 32517 | 12.8 | 10681 | 4.4 | 34911 | 35.9 | 39035 | 7.7 | 80.1 | 0.5 |
| cleanfs+su_off | 4096 | 34918 | 33.4 | 35108 | 12.9 | 11188 | 4.5 | 37268 | 38.3 | 39513 | 7.6 | 84.6 | 0.5 |
(C) Aborche 2009
