id: Гость   вход   регистрация
текущее время 09:48 29/03/2024
Автор темы: Гость, тема открыта 30/05/2007 14:42 Печать
https://www.pgpru.com/Форум/ПрактическаяБезопасность/ШифрованиеНеразмечЕнногоДисковогоПространства
создать
просмотр
ссылки

шифрование неразмеченного дискового пространства


Подскажите пожалуйста, какая программа может зашифровать, а потом расшифровать свободное ( неразмеченное ) дисковое пространство на винчестере?


 
На страницу: 1, 2, 3 След.
Комментарии
— sentaus (01/06/2010 14:36, исправлен 01/06/2010 14:36)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
В Ubuntu умолчальный инсталляционный диск не позволяет включить шифрование диска, и даже не упоминает про такую возможность. Чтобы включить шифрование во время инсталла, нужно воспользоваться диском для "альтернативно одарённых" (alternate install CD), про существование которого знают только те, кто итак уже в теме

Странно, Kubuntu 10.04 при установке спросила, шифровать ли /home, это был не alternate CD. Или это свойство именно Kubuntu CD?

— unknown (01/06/2010 14:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Неполнодисковое, но уже прогресс.
Убунтосрач полностью отменяется?
— sentaus (01/06/2010 14:59)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Неполнодисковое, но уже прогресс.


Да, полного нету. Да и вообще-то в дефолтном CD ubuntu это тоже должно быть. Это спрашивается при вводе настроек первого пользователя.


Кстати, кто-нибудь исследовал, что под капотом у этой настройки?
— Гость (01/06/2010 18:48)   <#>
Судя по экспериментам с полным шифрованием ещё на старых 300 MHz компах (где-то 20% проца) не может быть в 4-5 раз.
Да, и стоит напомнить, что типичный нетбук – это 1 ГГц-проц.

Чтение разделов Lin из Win? Можно завести отдельный раздел для перекидывания данных, а вообще такая совместимость нужна?
Всё смешнее :) Винда не может читать разделы Linux хотя бы даже потому, что по умолчанию там нет драйверов для поддержки зоопарка Linux'овых файловых систем. Причём для большего части этого зоопарка таких драйверов, емнип, вообще нет в природе, да и если есть – пользуются ими одни гики.

Странно, Kubuntu 10.04 при установке спросила, шифровать ли /home, это был не alternate CD. Или это свойство именно Kubuntu CD?
Не знаю. Недавно присутствовал при установке убунты, версию не помню – 10x какая-то... Про шифрование /home не заметил ни слова. Спрашивала только пароль и логин для пользователя. Да и шифрование папки пользователя (там именно это подразумевается, судя по всему) – не ясно как сделано. Если специального раздела под это дело нет, то как? EcryptFS какая-нить? Пофайловое шифрование со всеми его минусами?
— Гость (01/06/2010 21:21)   <#>
Я не знаю как там во всяких виндах (это другая такая ОС что ли?)
Тонко! А какую из BSD-систем можете порекомендовать для среднестатистического ноутбука? Ну, и естественно, его среднестатистического юзера.
— Гость (01/06/2010 21:24)   <#>
Поглядел "сабж" в user-friendly-дистрах Linux. В Ubuntu умолчальный инсталляционный диск не позволяет включить шифрование диска
А в каких дистрах это хорошо реализовано?
— Гость (01/06/2010 23:36)   <#>
А какую из BSD-систем можете порекомендовать для среднестатистического ноутбука? Ну, и естественно, его среднестатистического юзера.

среднестатистическую
— Гость (01/06/2010 23:38)   <#>
А какую из BSD-систем можете порекомендовать для среднестатистического ноутбука? Ну, и естественно, его среднестатистического юзера.
Разные BSD слишком разные :) Среднестатистическому юзеру вообще не стоит ставить BSD – это профессиональная система, и смысл ставить такую ОС (равно как и всякие дебианы с гентами) есть только при условии, что чел планирует начать разбираться в UNIX лучше, чем секретарши в гномоубунте. Дальше зависит от подготовки пользователя и возможности получить консультацию при необходимости у гуру – во-первых, и от задачи – во-вторых. Полнодисковое шифрование поддерживается только во фре, в нэтке корень шифровать не получится, потому, если хочется иметь полностью шифрованный диск, корень с ядром надо вынести на внешний носитель. В опёнке вообще не ясно, можно ли шифровать разделы, а не только ФС на файле, и, к тому же, шифрование системных разделов искаропки не поддерживается (пляски с бубном не в счёт, и то не уверен что помогут). Новичкам советуют ставить Free из-за её большей "дружелюбности", фич, лучшей поддержки железа и некоторых продвинутых фич, по ней также проще получить консультацию на форумах. Но на мой вкус фря – слишком Linux, такая же громоздкая, с кучей сложных фич, много легко включаемой автоматики с очень нетривиальной логикой в стиле винды, срач в конфигах /etc и т.д. На простую систему, где понятно всё, и где каждый шаг старта системы можно просмотреть и скорректировать она всё меньше становится похоже. Короче, "нет идеальной системы".
— Гость (01/06/2010 23:41)   <#>
Очень смешно... Но слишком ТОЛСТО. Подождем когда spinore заглянет.
— Гость (01/06/2010 23:43)   <#>
Извините, это не Вам, а ранее высказавшемуся.
— Гость (02/06/2010 03:07)   <#>
Подождем когда spinore заглянет
Было. Тоньше не смог, уж извините.
— Гость (02/06/2010 04:17)   <#>
На многоядерниках — десятые доли процента нагрузки на одно ядро процессора (и это даже без аппаратной поддержки AES в новых процах), скорость работы с диском соответственно тоже практически не меняется. Судя по экспериментам с полным шифрованием ещё на старых 300 MHz компах (где-то 20% проца) не может быть в 4-5 раз.

Уж поверьте мне, автору 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. Преимущество специально оптимизированного кода очевидно, как и настоящая цена дискового шифрования.

Вот такие вот дела, с шифрованием всё отнюдь не так просто, как хотелось бы.
— unknown (02/06/2010 09:17, исправлен 02/06/2010 09:17)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Спасибо, интересно. Кстати при шифровании надо перезаписывать весь блок целиком. Если не пользоваться интенсивной обработкой данных, то оно действительно незаметно, но для потребностей разных пользователей (перекодирование видео, базы данных и пр.) значит всё ещё может быть критично по скорости.
В dm-crypt сознательно отказываются от оптимизации (в отличии от loop-aes). Грубо говоря — скорость неважна, лишь бы чистота и ясность кода.
SSD — это вообще больная тема с точки зрения безопасности. Там можно гарантировано затереть заголовок контейнера, например?

— Гость (02/06/2010 10:44)   <#>
Там можно гарантировано затереть заголовок контейнера, например?

В моделях поддерживающих TRIM можно. Только нужно учесть, что минимальный стираемый блок = 128кб, и TRIM на область меньшего размера не приведет к стиранию данных. Если поддержки TRIM нет, то чтобы что-либо стереть, надо 2 раза перезаписать накопитель случайными числами.
— unknown (02/06/2010 10:54, исправлен 02/06/2010 10:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

LUKS и многие другие сразу оказываются в пролёте. Размер заголовка меньше.


То есть весь накопитель? Следовательно смена или уничтожение пароля в заголовке, которым шифруется ключ смысла не имеет? Нужно пересоздавать контейнеры заново на перезатёртом носителе? А какие-нибудь резервные области, в которые контроллер прячет информацию тоже могут наличествовать в большом объёме?


М. б. всвязи с широким распространением накопителей с непрямым доступом к данным придётся придумывать какую-то схему, в которой заголовок размазан в хрупком виде "всё-или-ничего" почти по всему объёму контейнера (например отбирая 5% его ёмкости)?

На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3