Особенности NetBSD CGD


Federico Biancuzzi

Перевод: Сгибнев Михаил

NetBSD известна своей многоплатформенностью, с выходом релиза NetBSD 2.0 в системе появились тонны интересных и уникальных особенностей. В свете выхода версии 3.0 Федерико Бианкусси взял интервью у Роланда Доудесвелла, автора системы Crypto-Graphic Disk. Оно должно быть интересно для владельцев ноутбуков и всех, озабоченных безопасностью данных на жестком диске.
Вы не расскажете немного о себе?
Roland Dowdeswell: В настоящее время я работаю в крупном финансовом учреждении в Нью-Йорке. Ранее я занимался консалтингом и, как и многие IT-специалисты моего поколения, работал в Силиконовой Долине. Проектом NetBSD я занимаюсь очень давно но, к сожалению, очень много времени отнимает работа, поэтому я не могу уделять проекту столько внимания, сколько хочу.
Что такое CGD?
RD: CGD представляет собой механизм шифрования данных на диске с использованием специфичного псевдоустройства. Он находится выше уровня диска или раздела и представляет собой виртуальный диск и прозрачен для пользователя и операционной системы. Все записываемые данные проходят через псевдоустройство и сбрасываются на диск уже в зашифрованном виде. Для чтения данных используется обратный порядок. В рамках шифрованного диска возможна вполне обычная работа, даже можно разбить его на разделы. Примерно тот-же подход используется в решениях RAID.
Почему Вы написали именно CGD?
RD: Как и многие открытые проекты, в первую очередь потому, что мне было это интересно. В тоже время, единственной BSD-licensed альтернативой был драйвер svnd из OpenBSD. Который был уязвим для атаки по словарю и поддерживал единственный метод шифрования (blowfish). Поэтому я решил написать собственное решение.
Кто-нибудь финансировал Вашу работу?
RD: Нет. Я выкроил немного времени от занятий консультированием.
Как это работает с пользовательской точки зрения?
RD: Сначала вы должны создать конфигурационный файл. Этот файл содержит информацию как cgdconfig должен конфигурировать диск, включая метод шифрования, алгоритм создания ключей и т.д.:

# cgdconfig -g aes-cbc 256 > /etc/cgd/wd0f

По умолчанию, методом генерирования ключей является PKCS#5 PBKDF2, создающий их из кодовой фразы. Также существует возможность задать n-ступенчатую аутентификацию или просто сохранить ключ в файле.

Как только файл конфигурации создан, проведем начальное конфигурирование диска:

# cgdconfig -V re-enter cgd0 /dev/wd0f
/dev/wd0f's passphrase:
/dev/wd0f's passphrase:

Флаг -V re-enter указывает cgdconfig запрашивать подтверждение кодовой фразы и проверять ее идентичность. В общем случае, cgdconfig проверит наличие на диске или правильной метки диска или файловой системы, подходящей для работы с указанным ключем. Понятно, что при первом запуске это условие не будет соблюдаться.

Теперь мы имеем диск /dev/cgd0[a-h], с которым можем работать, например создать метку диска и файловую систему. Как только диск должным образом настроен, отключим его:

# cgdconfig -u cgd0

Подключить его можно следующей командой:

# cgdconfig cgd0 /dev/wd0f

Система rc-скриптов NetBSD поддерживает конфигурирование дисков CGD с помощью файла /etc/cgd/cgd.conf.

Если вы хотите иметь несколько кодовых фраз для разных системных администраторов, то вы можете создать требуемое число файлов параметров из исходного:

# cgdconfig -G old_params > new_params

Этот же метод может быть использован для смены кодовой фразы при удалении old_params.
Как я могу зашифровать уже имеющийся диск с данными? Я должен использовать для переноса имеющийся пустой раздел?
RD: Да. Для шифрации существующего раздела необходимо создать новый шифрованный раздел, а затем перенести на него данные.
Сколько дискового пространства используется для шифрования? Оно изменяется в зависимости от объема данных или жестко фиксировано для размера диска?
RD: В текущей реализации, объем данных CGD не зависит от размера диска и занимает всего несколько сотен байтов.
Вы можете описать шаги, следуя которым CGD шифрует информацию?
RD: В первую очередь cgdconfig читает параметры конфигурации, такие как метод формарования ключа, алгоритм шифрования и длину ключа.

Как говорилось ранее, используемый по умолчанию метод PKCS#5 PBKDF2 требует кодовой фразы, при этом используется соль пароля, что исключает его взлом методом перебора по словарю. Соль генерируется на основании счетчика итераций, что делает задачу взлома еще более нетривиальной (если нет доступа к файлу конфигурации).

В настоящее время поддерживаются алгоритмы шифрования AES (128-, 192- и 256-bit ключ), blowfish (40-448-bit ключ) и 3DES (192-bit ключ). Наличие нескольких алгоритмов предоставляет возможность выбирать между быстродействием и производительностью, а при обнаружении уязвимости в шифре, пользователь может сменить алгоритм без обновления операционной системы.

Каждый сектор шифруется независимо. Для этого:
Этап первый. Генерируется Вектор Инициализации (Initialization Vector).
Сектор шифруется, используя указанный алгоритм, при этом используется IV, сгенерированный на первом этапе.
Дешифрация происходит аналогичным образом.
Если у меня имеется зашифрованный сектор, я могу сменить шифр или отключить cgd?
RD: Нет, в настоящее время сменить метод шифрования раздела в "горячем режиме" нельзя. Как и в случае с нешифрованным разделом, данные придется перемещать, хотя я планирую написать такого рода инструментарий.
Есть ли возможность взаимодействия с аппаратным/программным RAID?
RD: Нет.
Есть ли возможность использовать аппаратные средства криптографии типа генераторов случайных чисел и ускорителей?
RD: В настоящее время таких планов нет.
Каковы минимальные требования к RAM/CPU?
RD: Особых требований нет, но на совсем уж слабых системах работа будет некомфортной.
Насколько сильно снижается скорость операций ввода/вывода?
RD: Тут все упирается в производительность ЦП и быстродействие дисковой подсистемы. При слишком слабом процессоре данные не будут успевать шифроваться/расшифровываться, но и CGD несколько снизит скорость ввода/вывода, так как перед записью данных на диск они должны зашифроваться.

Для ноутбуков с технологией Speed Step, производительность CGD будет сильно отличаться при работе в различных режимах.
Я думаю, что каждый владелец ноутбука боится его потерять. Если это произойдет, то как CGD может защитить данные, ведь злоумышленник имеет физический доступ к носителю?
RD: Если ноутбук выключен, то необходимо применить brute-force перебор пароля или атаку по словарю.

Атака по словарю является наиболее действенным методом атаки, так как стойкость современных шифров значительно выше стойкости паролей, выбираемых обычными пользователями. CGD использует PKCS#5 PBKDF2 (an iterated salted hash) для предотвращения такой возможности. CGD также обеспечивает механизм для идентификации по двухкомпонентной схеме, где дополнительный ключ может быть сохранен на USB устройстве.

Атака методом "грубой силы" невозможна, так как используемые алгоритмы применяют ключи более 100 битов длиной и среднее число комбинаций превысит 2^100.

В случае, если ноутбук был включен, то ключ можно извлечь из памяти.
Вы говорите, что "CGD также обеспечивает механизм для идентификации по двухкомпонентной схеме, где дополнительный ключ может быть сохранен на USB устройстве". Как это работает?
RD: При установке CGD устройства, создается файл параметров, в котором содержится вся информация о процессе шифрования. Помимо используемого по умолчанию режима генерации ключа PKCS#5 PBKDF2 есть возможность использовать несколько методов создания ключа, при этом для получения ключа будет применяться последовательных XOR. Так, чтобы использовать двухступенчатую идентификацию, необходимо указать два метода генерации ключа, один из которых будет базироваться на кодовой фразе (PKCS#5 PBKDF2), а второй будет обычным ключом, сохраненным в конфигурационном файле. Теперь поместите файл конфигурации на USB-устройство и в результате, даже зная кодовую фразу, но не обладая файлом конфигурации расшифровать данные будет невозможно.
Что случится, если я потеряю свой ключ или забуду кодовую фразу?
RD: Если вы потеряли ключ или кодовую фразу, то вы потеряли ваши данные. Вы, по сути, оказались в той же ситуации, как и злоумышленник, похитивший ваши данные. Если вы обеспокоены данной проблемой, то рекомендую вовремя делать резервные копии (храня их в надежном месте).
cgdconfig обеспечивает несколько методов проверки кодовой фразы. В результате мы получаем расшифрованную метку диска или раздел. Есть ли возможность расшифровать раздел неправильной фразой?
Вероятность этого достаточно мала. Для примера, рассмотрим метку диска. В настоящее время, мы проверяем правильностьчетырех вещей: 32-разрядное магическое число, которое повторяется дважды, 32-разрядная контрольная сумма и число разделов.

Вероятность совпадения хэша правильной и неправильной кодовой фразы составляет 1/2^107. Это очень маленькое число, примерно равное 0.00000000000000000000000000000000616.

Для большей уверенности можно организовать проверку дополнительных битов в метке диска например, размер сектора, число секторов на дорожку и т.д.

Подобный анализ может быть выполнен для суперблока FFS.
Легко ли перенести код на другую ОС?
RD: Большая часть кода CGD находится в пользовательской утилите, портировать которую весьма просто. Ядра имеют большие различия в API, так что код ядра был бы немного более труден к портированию. CGD был перенесен в OpenBSD 3.2 Тэдом Унангстом, но не был интегрирован в главное дерево OpenBSD.
Можете ли Вы назвать другое подобное программное обеспечение, превосходящее Ваше или обладающее возможностями, отсутствующими у CGD?
RD: CGD и зашифрованные псевдо диски вообще типа svnd OpenBSD, GBDE FreeBSD, или Linux Loop-AES предназначены для защиты от весьма специфической угрозы. Для некоторых случаев, использование шифрованной файловой системы типа CFS или nCryptfs является наилучшим выходом. С их помощью вы можете разным пользователям назначать различные ключи, но при этом мы получаем увеличение метаданных файловой системы. Возможно, шифрование для каждого пользователя в отдельности важно для клиентов NFS, но для пользователей ноутбуков это не критичный вопрос. Следует также учитывать, что пользователь root может читать ключи пользователей из памяти машины.
OpenBSD не импортировал CGD, даже когда Тэд Унангст осуществил перенос кода. Думаете ли Вы, что svnd OpenBSD уже предлагает те же самые возможности?
RD: В некотором смысле, svnd OpenBSD, предлагает некоторые из возможностей CGD. Прежде, чем я приступил к разработке CGD, я исследовал svnd и решил, что в нем имеется множество недоработок.

Самый большой недостаток svnd - недостаточная защита. Он уязвим к оффлайновой атаке по словарю, это значит, что можно составить базу данных зашифрованных блоков текста, содержание которых известно и провести декодирование. Что еще хуже, данная база данных будет актуальна для любого диска svnd. Возможно и даже вероятно, что большие агентства типа АНБ создали такую базу данных и могут расколоть большинство дисков svnd в мире меньше чем за секунду. Предотвратить это можно используя соль пароля. Атаки по словарю известны с 70-х годов, поэтому добавление соли к паролю является обычной практикой уже 30 лет.

Решение OpenBSD поддерживает только Blowfish, я же хотел, чтобы CGD предоставлял большую гибкость в плане предоставления алгоритмов шифрации. Это зделано для того, чтобы пользователь сам мог решить, что ему важнее - скорость или надежность, Blowfish значительно быстрее, но, вероятнее, менее стоек чем AES. Как упоминалось ранее, при обнаружении уязвимости шифра можно будет переключиться на другой без обновления операционной системы.
А если сравнить CGD с Linux Loop-AES?
RD: Я сначала ознакомился с cryptoloop на Linux, проблем у которого было даже больше, чем у svnd OpenBSD. Loop-AES устраняет эти ошибки несколько иным, чем CGD способом.
Какие отличия Вы видите между CGD и FreeBSD GBDE?
RD: GBDE FreeBSD был разработан примерно в то же самое время, что и CGD, хотя автор GBDE и я не подозревали друг о друге. Мы выбрали совершенно разные подходы и я с интересом ознакомился с кодом, как только это стало возможным. Мне очень понравилась возможность шифрования данных несколькими кодовыми фразами, поэтому я добавил некоторые функциональные возможности (правда, несколько по другому) в CGD.

GBDE уязвим к онлайн атакам по словарю в случае, если неиспользуется двухступенчатый механизм аутентификации или второй ключ был утерян. Это не настолько серьезная ошибка, как в svnd OpenBSD, так как такая атака должна выполняться для каждого зашифрованного диска отдельно. Это довольно серьезный недостаток, так как большинство пользователей не используют двухступенчатую аутентификацию.

Другая проблема GBDE - нарушение отношений файловой системы с дисками. Когда Вы записываете сектор на диск, GBDE осуществляет две записи, между которыми диск находится в неопределенном состоянии. При отключении питания в этот момент данные будут потеряны. GBDE очень критичен к стабильности ОС и питанию, что ставит под сомнение целесообразность его использования в промышленном варианте.

FreeBSD недавно анонсировала GELI. Я имел возможность только бегло взглянуть на данное средство, но оно производит очень хорошее впечатление. Оно более просто написано и поэтому легче анализируется и в отличие от GBDE использует стандартные криптографические методы понятными способами.
Какие усовершенствования или новые возможности Вы планируете добавить в будущем?
RD: Я планирую добавить поддержку аппаратных средств шифрования и новых методов IV. Стивен Белловин предложил путь относительно дешево обеспечить проверку целостности, что звучит интересно, но это требует поддержание журнала транзакций, так что операции записи существенно замедлятся. Другая возможность, которую я хотел бы реализовать, должна добавить поддержку создания дисков/разделов CGD к нашему инсталлятору.

Обновлено: 13.03.2015