шифрование неразмеченного дискового пространства
Подскажите пожалуйста, какая программа может зашифровать, а потом расшифровать свободное ( неразмеченное ) дисковое пространство на винчестере?
Ссылки
[link1] https://www.pgpru.com/forum/prakticheskajabezopasnostj/truecrypt
[link2] https://www.pgpru.com/comment39593
[link3] https://www.pgpru.com/comment37449
[link4] https://www.pgpru.com/forum/tehnicheskievoprosy/ugrozavosstanovlenijaperezapisannyhdannyhsfleshekissdestjlianalogiismsmdljavinchesterov
[link5] http://www.ubuntu.com/desktop/get-ubuntu/alternative-download#mirrors
[link6] http://www.ubuntu.com/desktop/get-ubuntu/download
[link7] https://help.ubuntu.com/community/FullDiskEncryptionHowto
[link8] http://security.unt.edu/resources/ubuntuencryption
[link9] http://www.mail-archive.com/grub-devel@gnu.org/msg09787.html
[link10] http://www.linux.org.ru/jump-message.jsp?msgid=4744202&cid=4745316
[link11] https://www.pgpru.com/novosti/2009/inficirovaniezagruzchikadljaobhodashifrovannyhfajjlovyhsistem
[link12] https://www.pgpru.com/comment82946
[link13] https://www.pgpru.com/biblioteka/rukovodstva/zaschitadiska/tailsotricaemoehraneniedannyh
Где-то (здесь?[link1]) у нас высказывалось предложение по выполнению такого трюка с помощью TrueCrypt. Деталей, к сожалению, не помню. Поищите сами или ждите, чтобы кто-нибудь напомнил, в какой теме это обсуждалось.
С помощью TrueCrypt 4.3 можно такое сделать, если есть отдельный (не системный) полностью пустой диск (без mbr, без разделов) – только что так отформатировал флэшку.
Еще можно сделать сделать скрытый контейнер на обычном fat32 разделе – те система будет видеть партицию как обычный раздел (там могут быть какие-то файлы и с ними можно работать как обычно), а при монтировании раздела в TrueCrypt будет открываться доступ к скрытому разделу. При этом явных следов скрытого контейнера в разделе не будет – обычный раздел с файлами и все.
Делается так:
1. создается на диске раздел нужного размера, не форматируется
2. в TrueCrypt создается обычный зашифрованый раздел с fat32
3. в обычном зашифрованом разделе создается скрытый раздел, на 20-30% меньшего объема, можно fat32, можно NTFS
4. теперь из под виндового менеджера дисков форматируем весь раздел в fat32 обязательно использую БЫСТРОЕ форматирование!
5. получаем раздел, который система видит как обычный раздел, на который можно записать в начало файлы (15-25%, чтобы с запасом).
ИМХО этот вариант имеет определенные плюсы, тк наличие в системе неразмеченного раздела или диска вызывет ненужные подозрения даже у простого человека.
PS этот метод придумал не я, оригинал смотреть здесь https://www.pgpru.com/Comment11193
Я не знаю как там во всяких виндах (это другая такая ОС что ли?) но обычно программа
не может лезть в обход ОС по самой конструкции последней, по самой идеологии.
Чтобы ОС обратилась к какому-то месту на диске, это место на диске должно принадлежать
ОС, то есть должно быть помечечно как таковое с точки зрения самой ОС – обычно это
реализуется посредством прописывания заголовка в разделе диска где должна быть указана
как минимум геометрия раздела (а пожеланию можно ещё указать какой ОС принадлежит и какая
ФС там если имеется таковая). Основная проблема состоит в том, что эту информацию
о геометрии нельзя загрузить сразу в память ядра в BSD не записывая её предварительно на
диск в указанное место. Скорей всего, такое же положение дел и с линуксом и с "виндой"(?).
В данном случае проблема сводится не к принципиальной невозможности а ктому что пока
не реализовали этот функционал. С другой стороны, если оппонент не дурак, он всегда
может произвести экспертизу свободного дискового пространства и заявить что с такой-то
(довольно большой) вероятностью данное место на диске есть криптораздел или криптотом.
Если речь идёт о мизерных объёмах то можно списать на то что там был записан фильм,
но если никаких стандартных сигнатур диска не найдётся на разделе в 40 гигабайт, то
говорить уже будет не о чем. Умные люди потому изобрели стратегию трукрипт с "двойным дном",
но, как подсказывает мне интуиция, получи широкое распространение эта технология –
проблема останется той же – нет стегоОС, стегоОС in mind. А пока само наличие трукрипта
на диске может быть легко расценено как средство использования его двойного дна.
Я здесь не касаюсь правового поля (налчие шифрованной информации само по себе не является
обвинением, но может поспособствовать подозрениям суда). Итак, чтобы решать проблему
основательно нужно создавать стегоОС, которая будет комплексно стегонаграфической
во всех смыслах: распространена, её налчиие не вызывает подозрений, по умолчанию
логи, которые потенциально могли бы в некоторых случаях дискредитировать
анонимность не пишутся и т. п. А поскольку большинство не понимает зачем вообще
что-либо шифровать, то огромной птребности в стегоОС нет. Для тех же, кому она
нужна, единственный способ жить есть изобретать костыли под вид "шифровать свободное
место на диске" или что-то в этом роде.
Разве нельзя обращаться к блочному стройству, как к raw-data с параметром offset?
Когда то с гуру обсуждал этот вопрос и сошлись на том что нельзя. Задача состояла в использовании ФС на свободном месте на диске. Её там можно каким-то раком нарезать и использовать? Не трогая disklabel, имеется в виду.
ЭЭЭ? Да это стандартная возможность losetup. Там только криво реализовано, больше 4 гигов оффсет не делает.
spinore
Не понял о какой геометрии идет речь. Из ОС можно обратиться к любому произвольному сектору диска (физическому сектору), и не имеет значения размечен диск на разделы или нет, отформатированы разделы или нет. Не вижу в этом ничего особенного.
Здесь https://www.pgpru.com/Comment11193 по сути получается обратный порядок действия – сначала создаем криптоконтейнер на разделе с некоторым смещением от начала, а потом прописываем разделу заголовок так, чтобы он был виден как отформатированный в fat32.
И почему бы этому не быть? Или я не улових ход мысли?
ent, вохможно вы правы. Я в этом не специалист и мне пока надо обсудить этот
топик с тем кто утверждал обратное – не более того.
Поглядел "сабж" в user-friendly-дистрах Linux. В Ubuntu умолчальный инсталляционный диск не позволяет включить шифрование диска, и даже не упоминает про такую возможность. Чтобы включить шифрование во время инсталла, нужно воспользоваться диском для "альтернативно одарённых" (alternate install CD), про существование которого знают только те, кто итак уже в теме. Т.о., типичному пользователю даже такой альтернативы не предложат (да и многие ли вчерашние пользователи win знают, что можно шифровать диск целиком, а не пофайлово?). В Linux MINT всё ещё лучше: шифрование при инсталляции включить вообще нельзя. На форумах предлагают установить убунту с альтернативного CD, а потом отMINTить её. Ужас. А так, если подумать, сколько пользователей Ubuntu по всему миру... Если б было шифрование дефолтом, меньше бы выделялись те, кто "мануально шифрует". На десктопе нет критичности с скорости работы с диском как на файлопомойке – почему бы не включить шифрование диска паролем администратора по дефолту? Если от фичи нет вреда, а лишь польза... Заговор? Или недальновидность девов? В качестве аргументации пишут "среднему пользователю это не нужно, потому и нет такой фичи" – действительно, зачем среднему пользователю защищаться и замок на двери вешать :-( Сайты с авторизацией без https, видимо, аргументируются аналогично.
[Ubuntoсрач] А что еще можно ожидать от Шатлворта, который единолично занят утверждением перестановок кнопок в Убунтогноме на левую сторону, переманиванием пользователей с MacOS и прочими "вау!-фичами"?
А шифрование и безопасность: сделаешь хорошо — рядовые пользователи не заметят, сделаешь плохо — эксперты по безопасности расковыряют, это пройдёт горячей новостью, смысл которой рядовые пользователи хотя и не поймут, но негативное мнение сформируют. Неблагодарная будет работа.
Интересно, там хотя бы gpg-подписи пакетов при инсталле проверяются или "среднему пользователю это не нужно"?
[/Ubuntoсрач]
Может быть потому, что разработчики не хотят удовлетворять потребности меньшинства ценой значительного ухудшения для большинства? Даже на очень мощном десктопе бенчмарки видят разницу между незашифрованными и зашифрованными дисками, а на каких-нибудь нетбуках эта разница может достигать 4-5 раз. Для большинства, которому не нужно шифрование, это принесет кучу геморроя с потерями данных после забывания пароля, это вызовет несовместимость с другими линуксами и виндой, это вызовет катастрофическое замедление работы на нетбуках и резкое уменьшение времени автономной работы ноутбуков, это вызовет проблемы при смене пароля (я сменил пароль, старый забыл, потом достал с полки диск который юзал год назад и обнаружил сюрприз...). Причин достаточно или продолжать?
Если разработчики будут включать полное дисковое шифрование по-умолчанию, то пользователи их без соли съедят, и будут правы.
На многоядерниках — десятые доли процента нагрузки на одно ядро процессора (и это даже без аппаратной поддержки AES в новых процах), скорость работы с диском соответственно тоже практически не меняется. Судя по экспериментам с полным шифрованием ещё на старых 300 MHz компах (где-то 20% проца) не может быть в 4-5 раз.
CryptoAPI находятся в дефолтном ядре Linux. Уже давно. Набор утилит для работы с ними также. С версиями cryptsetup-LUKS/CryptoAPI теоретически могут быть проблемы совместимости, если кто-то вручную залезет в самые продвинутые опции и выберет самый последний недефолтный режим шифрования.
Чтение разделов Lin из Win? Можно завести отдельный раздел для перекидывания данных, а вообще такая совместимость нужна?
И вообще о какой совместимости речь? Зачем другим Linuxам физически подцепляться к винчестеру? Если надо восстановить шифрованные данные, то можно взять LiveCD с последними версиями CryptoAPI и утилит. Расшаривают и передают файлы на другие системы по сетевым протоколам, на которые дисковое шифрование никак не влияет. Флэшки и съёмные накопители — хотите шифруйте, хотите нет.
Про проблемы с обращением с шифрованием вообще и пофигизмом пользователей понятно, поэтому:
Только предложение выбора такого шифрования при инсталляции, как в других дистрибутивах, не более.
Точно срач :)
тут же совсем недавно была тема с гневным сообщением от пользователя, у которого проверка подписи провалилась
Вообще да, apt у них общий :) Им бы пришлось специально выпиливать эту возможность. Про подписи конечно совсем не в тему.
Странно, Kubuntu 10.04 при установке спросила, шифровать ли /home, это был не alternate CD. Или это свойство именно Kubuntu CD?
Неполнодисковое, но уже прогресс.
Убунтосрач полностью отменяется?
Да, полного нету. Да и вообще-то в дефолтном CD ubuntu это тоже должно быть. Это спрашивается при вводе настроек первого пользователя.
Кстати, кто-нибудь исследовал, что под капотом у этой настройки?
Да, и стоит напомнить, что типичный нетбук – это 1 ГГц-проц.
Всё смешнее :) Винда не может читать разделы Linux хотя бы даже потому, что по умолчанию там нет драйверов для поддержки зоопарка Linux'овых файловых систем. Причём для большего части этого зоопарка таких драйверов, емнип, вообще нет в природе, да и если есть – пользуются ими одни гики.
Не знаю. Недавно присутствовал при установке убунты, версию не помню – 10x какая-то... Про шифрование /home не заметил ни слова. Спрашивала только пароль и логин для пользователя. Да и шифрование папки пользователя (там именно это подразумевается, судя по всему) – не ясно как сделано. Если специального раздела под это дело нет, то как? EcryptFS какая-нить? Пофайловое шифрование со всеми его минусами?
Тонко! А какую из BSD-систем можете порекомендовать для среднестатистического ноутбука? Ну, и естественно, его среднестатистического юзера.
А в каких дистрах это хорошо реализовано?
среднестатистическую
Разные BSD слишком разные :) Среднестатистическому юзеру вообще не стоит ставить BSD – это профессиональная система, и смысл ставить такую ОС (равно как и всякие дебианы с гентами) есть только при условии, что чел планирует начать разбираться в UNIX лучше, чем секретарши в гномоубунте. Дальше зависит от подготовки пользователя и возможности получить консультацию при необходимости у гуру – во-первых, и от задачи – во-вторых. Полнодисковое шифрование поддерживается только во фре, в нэтке корень шифровать не получится, потому, если хочется иметь полностью шифрованный диск, корень с ядром надо вынести на внешний носитель. В опёнке вообще не ясно, можно ли шифровать разделы, а не только ФС на файле, и, к тому же, шифрование системных разделов искаропки не поддерживается (пляски с бубном не в счёт, и то не уверен что помогут). Новичкам советуют ставить Free из-за её большей "дружелюбности", фич, лучшей поддержки железа и некоторых продвинутых фич, по ней также проще получить консультацию на форумах. Но на мой вкус фря – слишком Linux, такая же громоздкая, с кучей сложных фич, много легко включаемой автоматики с очень нетривиальной логикой в стиле винды, срач в конфигах /etc и т.д. На простую систему, где понятно всё, и где каждый шаг старта системы можно просмотреть и скорректировать она всё меньше становится похоже. Короче, "нет идеальной системы".
Очень смешно... Но слишком ТОЛСТО. Подождем когда spinore заглянет.
Извините, это не Вам, а ранее высказавшемуся.
Было[link2]. Тоньше не смог, уж извините.
Уж поверьте мне, автору 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. Преимущество специально оптимизированного кода очевидно, как и настоящая цена дискового шифрования.
Вот такие вот дела, с шифрованием всё отнюдь не так просто, как хотелось бы.
Спасибо, интересно. Кстати при шифровании надо перезаписывать весь блок целиком. Если не пользоваться интенсивной обработкой данных, то оно действительно незаметно, но для потребностей разных пользователей (перекодирование видео, базы данных и пр.) значит всё ещё может быть критично по скорости.
В dm-crypt сознательно отказываются от оптимизации (в отличии от loop-aes). Грубо говоря — скорость неважна, лишь бы чистота и ясность кода.
SSD — это вообще больная тема с точки зрения безопасности. Там можно гарантировано затереть заголовок контейнера, например?
В моделях поддерживающих TRIM можно. Только нужно учесть, что минимальный стираемый блок = 128кб, и TRIM на область меньшего размера не приведет к стиранию данных. Если поддержки TRIM нет, то чтобы что-либо стереть, надо 2 раза перезаписать накопитель случайными числами.
LUKS и многие другие сразу оказываются в пролёте. Размер заголовка меньше.
То есть весь накопитель? Следовательно смена или уничтожение пароля в заголовке, которым шифруется ключ смысла не имеет? Нужно пересоздавать контейнеры заново на перезатёртом носителе? А какие-нибудь резервные области, в которые контроллер прячет информацию тоже могут наличествовать в большом объёме?
М. б. всвязи с широким распространением накопителей с непрямым доступом к данным придётся придумывать какую-то схему, в которой заголовок размазан в хрупком виде "всё-или-ничего" почти по всему объёму контейнера (например отбирая 5% его ёмкости)?
Почему, можно стирать 128кб и потом восстанавливать нужное. Хотя это всё усложняет.
Накопитель обычно содержит 5-20% дополнительного флеша (скрытый объем) для выравнивания износа. Поэтому для надёжности стоит перезаписывать 2 раза. Никто не станет делать больше половины скрытого объема, это слишком дорого.
ИМХО это только усложняет код, делает слишком сложными хитрые оптимизации и усложняет анализ такой схемы. Лучше сделать поддержку TRIM в нужных местах и забить на устаревшие накопители, благо TRIM есть во всех новых SSD. Старые накопители, которые даже не умеют определяться как SSD, пусть используют на свой страх и риск.
Это вопрос привычки. И по сею пору уже много лет задаются вопросы типа "закрыла MS Word, не сохранила – как теперь восстановить квартальный отчёт?", потому не стоит на них равняться. Вместо этого стоило бы писать предупреждение большими красными буквами о том, что в случае забытия пароля все данные будут утеряны. Собственно, включать ли крипто по умолчанию – тонкий вопрос, может вы и правы, что не стоило бы торопиться, но саму такую возможность добавить в умолчальный инсталлятор стоило бы (не забывая вывести все предупреждающие окошки).
В контексте дискуссий при падение скорости работы при шифровании диска хотел бы отметить ещё один момент. Даже если скорость падает в 4-5 раз, но остаётся вполне достаточной, чтобы пользователь не видел падения производительности десктопной системы, то пользы от шифрования больше, чем проигрыш от производительности. Современные десктопные сетевые карты редко держут больше 10 мегабайт в секунду, а скорость соединения с инетом редко у кого превышает несколько мегов в сек. Т.о., падение производительности будет видно лишь при копировании больших объёмов данных с одного шифрованного раздела на другой, что не есть такая уж частая операция.
А если смена блока для выравнивание износа происходит только при достижении определённого числа ошибок чтения-записи, а на самом этом bad-блоке информация так и остаётся и при большом желании может быть прочитана?
/comment37449[link3]: решение уже предлагалось. Также, вопросы стирания информации с флэшек уже обсуждались здесь[link4].
Нет, накопитель просто старается равномерно распределять запись по всем свободным блокам. Т.е. есть список блоков в котором есть число их стираний, для записи всегда выбирается наименее изношенный блок, а блок, бывший на его месте ставится в очередь на стирание (на старых SSD не ставиться, и старые данные могут храниться еще долго). Что происходит когда предельное число стираний для блока достигнуто не знаю, жалко убивать новый и дорогой накопитель ради такого эксперимента, да и чтобы убить Intel X-25M надо полгода непрерывно на него писать с максимальной скоростью.
Рекомендация простая – покупайте только Intel и топовые OCZ, они поддерживают TRIM и самый современный вариант выравнивания износа. С другими могут быть проблемы. Дешевые Kingston до сих пор даже как SSD не определяются.
Могу подлить
убунтусрачамасла в огонь. С официальной страницы[link5], где рекомендации к тому, что загружать для инсталляции:Жаль, нет у них советского опыта – они бы ещё написали, что это диск особого назначения для специальных целей: незачем быдлу знать про существование дискового шифрования (откуда эти паразиты "особый" и "специальный" в русском языке?). А на стандартной официальной странице[link6] – так вообще глухо:
Страница с какой-никакой информацией[link7] – вообще дело рук юзерского community, а не разработчиков, причём вменяемое изложение того, что делать – вообще дано на стороннем[link8] сайте. Заговор тупости или... Например, и фрёый и NetBSD'шный официальные хандбуки содержат главу по шифрованию дисков, где всё (по крайней мере, с точки зрения юзерского интерфейса, а не internals) описано в деталях.
Параллельный вопрос – про шифрование boot-раздела (где лежит ядро и всякое подобное). Если я понял правильно, сам Linux этого не умеет, и нужна поддержка на стороне загрузчика: т.е. grub должен уметь расшифровывать boot-раздел и грузить ядро. Пишут, что поддержка LUKS есть в grub2, но она, возможно, сырая[link9]? Каков статус сабжа – кто-нибудь пользуется?
http://www.linux.org.ru/jump-m.....=4744202&cid=4745316[link10]
Понятно, что это полумера. По-хорошему надо выносить загрузчик на сторонний носительно и хранить под подушкой, грузиться только с него.
В итоге это намного проще и надёжной, нежели ставить девелоперскую версию загрузчика с риском вообще распрощаться с системой.
Загрузчик LUKS в GRUB тоже можно протроянить и даже BIOS. От атаки активной уборщицы всё равно мало что спасёт. Джоанна Рутковска подтверждает это[link11].
А мы пол в квартире сами моем :)
Хоть тред и старый, но поскольку ответ так и не был дан, дам его: это умеет[link12] связка из dmsetup (см. tables) + cryptsetup.
К сказанному, хотелось добавить сюда ссылку на Инструкцию[link13]