шифрование неразмеченного дискового пространства
Подскажите пожалуйста, какая программа может зашифровать, а потом расшифровать свободное ( неразмеченное ) дисковое пространство на винчестере?
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||||
комментариев: 1060 документов: 16 редакций: 32
Странно, Kubuntu 10.04 при установке спросила, шифровать ли /home, это был не alternate CD. Или это свойство именно Kubuntu CD?
комментариев: 9796 документов: 488 редакций: 5664
Неполнодисковое, но уже прогресс.
Убунтосрач полностью отменяется?
комментариев: 1060 документов: 16 редакций: 32
Да, полного нету. Да и вообще-то в дефолтном CD ubuntu это тоже должно быть. Это спрашивается при вводе настроек первого пользователя.
Кстати, кто-нибудь исследовал, что под капотом у этой настройки?
Всё смешнее :) Винда не может читать разделы Linux хотя бы даже потому, что по умолчанию там нет драйверов для поддержки зоопарка Linux'овых файловых систем. Причём для большего части этого зоопарка таких драйверов, емнип, вообще нет в природе, да и если есть – пользуются ими одни гики.
Не знаю. Недавно присутствовал при установке убунты, версию не помню – 10x какая-то... Про шифрование /home не заметил ни слова. Спрашивала только пароль и логин для пользователя. Да и шифрование папки пользователя (там именно это подразумевается, судя по всему) – не ясно как сделано. Если специального раздела под это дело нет, то как? EcryptFS какая-нить? Пофайловое шифрование со всеми его минусами?
среднестатистическую
Уж поверьте мне, автору DiskCryptor, есть целая куча ситуаций, когда это не так. Например у меня есть нетбук eeepc 900, процессор Celeron 900, лучшая скорость AES, какой мне удалось на нём добиться – 24 мб/с. Скорость встроенного SSD – порядка 40 мб/с, замедление по итогам дискового бенчмарка – порядка 3х раз. Если взять eeepc с ноутбучным винтом, скорость которого доходит до 60мб/с, то замедление дойдет до обещанных 5 раз.
Учтите, что скорость ввода-вывода не вычисляется как min(disk_speed, encryption_speed), а всегда меньше, причем для некоторых типов накопителей (SSD и быстрые RAID) может наблюдаться падение производительности в несколько раз, притом, что скорость шифрования в памяти в 2-3 раза больше, чем скорость накопителя.
Пример: процессор Core i7, скорость AES порядка 600мб/с, накопитель SSD Intel X-25M, скорость чтения без шифрования 250 мб/с, с шифрованием – 140мб/с. Падение весьма неслабое, и оно наблюдается, правда в меньшей мере, и при использовании процессоров с аппаратным AES. Это связано с тем, что при последовательном чтении незашифрованного диска следующий запрос ввода-вывода поступает сразу по окончании обработки предыдущего, а при использовании шифрования приложение ждет расшифрования предыдущего запроса, прежде чем даст следующий. Давайте посчитаем: пусть за секунду было прочитано 250мб данных, на расшифровку у най уйдет 250/600=0.41 секунды, итого 1.41 секунды на 250мб, что даёт 177 мб/с. Прибавьте сюда неизбежную латентность обработки запросов, работу других программ, и.т.п., и получим 140 мб/с измеряемых бенчмарком. Всё вышесказанное касается HDD в гораздо меньшей мере, там на топовых процессорах будет замедление порядка 5%, но SSD и быстрые рейды уже не экзотика.
Идём далее. Скорость записи SSD накопителей может упасть ещё больше от самого факта шифрования, независимо от процессора. Это связано с тем, что при записи SSD проводит цикл стирания данных в ячейках памяти, который занимает длительное время. Большинство SSD хранят список свободных ячеек памяти, в которые можно производить запись без стирания, а само стирание осуществляется в фоне. Список свободных ячеек SSD получают двумя способами: все сектора заполненные нулями считаются свободными, либо свободные сектора должны передаваться командой TRIM (многие накопители TRIM не поддерживают, и полагаются только на нули). Включение шифрования убивает этот механизм, что дополнительно замедляет запись в 2 раза и сокращает срок службы накопителя на порядки, т.к. убивается и механизм выравнивания износа.
Все эти проблемы я сейчас решаю в DiskCryptor 1.0. Замедление чтения/записи на SSD можно победить хитрой параллелизацией ввода/вывода и шифрования (причем трудно сделать так, чтобы не стало хуже). Замедление записи и повышенный износ можно победить только отказавшись от "правдоподобного отрицания" и разрешив накопителю обрабатывать TRIM. Если накопитель не поддерживает TRIM, то ничего нельзя сделать без существенного ухудшения скорости шифрования (т.к. чтобы не шифровать нули понадобится добавлять лишнюю проверку).
Что касается dm-crypt в Linux, то такими оптимизациями там и не пахнет. Там до сих пор нет даже параллельного шифрования больших блоков данных на нескольких процессорах, т.е. реальная скорость во многих случаях будет ограничена скоростью одного ядра. К тому-же универсальный CryptoAPI не может обеспечить максимальную производительность в специфических режимах дискового шифрования. Приведу пример бенчмарка на ноутбуке VIA с аппаратным AES (из письма одного пользователя):
Здесь мы видим, что 96.8 MB/s которые даёт диск, после cryptsetup --cipher aes-xts-plain превращаются в 30.1 MB/s, а после DiskCryptor в 65.1 MB/s. Преимущество специально оптимизированного кода очевидно, как и настоящая цена дискового шифрования.
Вот такие вот дела, с шифрованием всё отнюдь не так просто, как хотелось бы.
комментариев: 9796 документов: 488 редакций: 5664
Спасибо, интересно. Кстати при шифровании надо перезаписывать весь блок целиком. Если не пользоваться интенсивной обработкой данных, то оно действительно незаметно, но для потребностей разных пользователей (перекодирование видео, базы данных и пр.) значит всё ещё может быть критично по скорости.
В dm-crypt сознательно отказываются от оптимизации (в отличии от loop-aes). Грубо говоря — скорость неважна, лишь бы чистота и ясность кода.
SSD — это вообще больная тема с точки зрения безопасности. Там можно гарантировано затереть заголовок контейнера, например?
В моделях поддерживающих TRIM можно. Только нужно учесть, что минимальный стираемый блок = 128кб, и TRIM на область меньшего размера не приведет к стиранию данных. Если поддержки TRIM нет, то чтобы что-либо стереть, надо 2 раза перезаписать накопитель случайными числами.
комментариев: 9796 документов: 488 редакций: 5664
LUKS и многие другие сразу оказываются в пролёте. Размер заголовка меньше.
То есть весь накопитель? Следовательно смена или уничтожение пароля в заголовке, которым шифруется ключ смысла не имеет? Нужно пересоздавать контейнеры заново на перезатёртом носителе? А какие-нибудь резервные области, в которые контроллер прячет информацию тоже могут наличествовать в большом объёме?
М. б. всвязи с широким распространением накопителей с непрямым доступом к данным придётся придумывать какую-то схему, в которой заголовок размазан в хрупком виде "всё-или-ничего" почти по всему объёму контейнера (например отбирая 5% его ёмкости)?