id: Гость   вход   регистрация
текущее время 19:50 28/03/2024
Владелец: SATtva (создано 14/09/2006 22:50), редакция от 04/06/2014 03:57 (автор: Гость) Печать
Категории: софт, pgp, инфобезопасность, защита дисков, truecrypt, сайт проекта, faq
http://www.pgpru.com/FAQ/ЗащитаДиска
создать
просмотр
редакции
ссылки

Криптоконтейнеры и защита диска


Оглавление документа:

В ходе создания нового контейнера PGPdisk мне предлагается на выбор зашифровать его открытым ключом или ключевой фразой. Что более надёжно?

Если выбирать для нового контейнера столь же надёжную ключевую фразу, как и у закрытого ключа, то с точки зрения безопасности разницы практически нет. С другой стороны, выбор зашифрования открытым ключом усложняет взлом контейнера атакой "по словарю" (особенно, при не очень стойкой ключевой фразе), поскольку взломщику придётся раздобыть копию вашего закрытого ключа. В то же время, если вы по какой-то причине утратите свои ключевые пары, то уже и сами не сможете открыть контейнер, что было бы не так, если воспользоваться только ключевой фразой.

Могу ли я дефрагментировать контейнер PGPdisk/TrueCrypt и проводить иные операции по его техническому обслуживанию?

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

Возможно ли создать PGPdisk на USB Flash Drive, CD-RW или ином съёмном носителе? Какие есть рекомендации?

Создайте на жёстком диске новый PGP-контейнер, а затем перенесите его .pgd-файл на внешний носитель информации и всё будет отлично работать. Если это CD-RW, DVD-RW или иное аналогичное устройство, контейнер должен быть отформатирован под файловую систему FAT / FAT32, а подключаться в режиме read-only. Если вы планируете использовать контейнер на нескольких компьютерах (на всех должен быть установлен PGP с компонентом PGPdisk), стоит использовать для его защиты исключительно пароль (а не свою ключевую пару) либо же ключевую пару, размещённую на смарт-карте, если все компьютеры оборудованы считывающими устройствами и соответствующими драйверами.


iВы не должны забывать, что любой чужой компьютер является априори ненадёжной средой исполнения: его владелец может использовать произвольные средства для перехвата введённого пароля, ключа расшифрования либо содержимого контейнера.

Настоятельно рекомендую после всякого открытия контейнера на чужом компьютере менять пароль доступа и мастер-ключ (отключить контейнер, если он подключен, затем: PGPtray > PGPdisk > Edit Disk > выбрать файл-контейнер > File > Properties > Re-Encrypt).

PGPdisk нормально работал, но неожиданно перестал открываться (ошибка "not formatted" / "not a valid PGPdisk" и т.п.).

К ошибке "not formatted" обычно приводит попытка перенести файлы в контейнер, открытый на диске CR-RW или DVD-RW с правами на запись, т.е. не в режиме read-only. Этого не следует делать. Чтобы обновить содержимое контейнера, его нужно скопировать на жёсткий диск, добавить в него нужные файлы, а затем записать обновлённую копию на оптический диск. Также важно заметить, что необходимо отключать контейнер перед любыми манипуляциями с его файлом – копированием или переносом. Копирование подключенного контейнера приводит к повреждению его структуры. К тем же последствиям может привести дефрагментация жесткого диска, на котором размещен криптоконтейнер, если последний не был отключен: отключайте контейнер перед началом дефрагментации жесткого диска либо исключите файл контейнера из обработки утилитой дефрагментации, если она позволяет это сделать.


Любая из описанных проблем не поддаётся решению. Наилучший совет в такой ситуации – восстановить последнюю резервную копию контейнера. Если же у вас её (их) нет, мало чем можно помочь. Пока спецификации и формат контейнеров не будут опубликованы в виде RFC-подобного документа, локализация и решение подобных проблем останутся сильно затруднены.


Контейнер PGPdisk – очень хрупкая структура. Незначительное повреждение в неудачном месте, вызванное сбоем винчестера или некорректной работой ОС, может легко привести к потере симметричного ключа расшифрования или к поломке вложенной файловой системы. Последнее было бы не катастрофично для жёсткого диска, но это не так в связи с тем, что ФС контейнера зашифрована.


Как и с любым ценным материалом, такие проблемы легче предупреждать, чем пытаться разрешить, когда они случились. Не создавайте слишком больших контейнеров – такие более подвержены поломкам и их труднее резервировать, а это обязательная процедура, которую нужно выполнять регулярно, дабы в критической ситуации не пришлось возвращаться к слишком старому материалу. Храните несколько хронологических резервных копий и заменяйте новыми самые старые. Как часто резервировать контейнер и как много резервных копий хранить должны решить вы сами исходя из ценности информации и темпа её обновления / устаревания.


!Каждый пользователь PGP, желающий воспользоваться компонентом PGPdisk, должен отчётливо понимать вышесказанное и соразмерять свои риски. Если вы можете позволить себе потерять всю информацию в системном сбое, но не можете позволить попасть ей в чужие руки, используйте PGPdisk. Если вы будете регулярно делать резервные копии контейнера и можете позволить себе потерять все изменения, сделанные с момента последнего резервирования, но не можете позволить попасть этой информации к посторонним, используйте PGPdisk. Но если сохранность и целостность информации для вас превыше риска компрометации, лучше дважды подумайте, прежде чем помещать её в PGPdisk.

Перенёс / создал в PGP 7.x – 8.x контейнер PGPdisk, пароль на русском, не могу открыть – русские буквы не вводятся.

В PGP 7.x существует баг: при открытии контейнера программа не принимает национальные буквенные символы, хотя их можно вводить в ходе создания контейнера (как коварно! ;-) ). Точная причина проблемы с 8.x, где могут не вводиться лишь некоторые русские буквы, не выявлена по сей день, кроме того, что она проявляется только в Windows NT-совместимых системах. Причём часто получается так, что в разных диалоговых окнах не вводятся различные русские буквы, и вы можете совершенно благополучно создать контейнер, которым после закрытия не сможете открыть. Будет ещё хуже, если прежде чем обнаружить проблему, вы успеете перенести в контейнер все свои ценные файлы (как чаще всего и бывает).


Так или иначе, но единственный способ избежать этой проблемы – просто не использовать кириллицу в паролях. Если же ситуация уже зашла в тупик, и неработоспособность контейнера выяснилась уже после его закрытия со всей ценной информацией, перенесите его на другой компьютер с Windows 98 и установленным PGP 8.x и смените у контейнера пароль. Если контейнер зашифрован вашим открытым ключом, у которого установлена кириллическая ключевая фраза, просто замените её на чисто латинскую. Если контейнер импортировался в 7.x – 8.x из PGP 6.x, верните его на компьютер с ранней версией программы и, опять же, поменяйте пароль контейнера так, чтобы он не содержал кириллических и других национальных буквенных символов.


Запомните: для целей совместимости не рекомендуется использовать в любых паролях и ключевых фразах PGP ничего, кроме латиницы, цифр и служебных печатных символов. Следуя этому совету вы избежите ненужной головной боли от решения подобных проблем.

Контейнер PGPdisk создавался так, чтобы подключать как NTFS-директория, но неожиданно стал подключаться как логический диск.

Каталог, под которым подключается криптоконтейнер, должен быть пуст. Вероятно вы или операционная система сохранили что-то в этом каталоге, что привело к потере ассоциации между ним и контейнером. Чтобы вновь её восстановить, сделайте следующее:


  1. Отключите контейнер, нажав на него правой кнопкой > PGP > Unmount PGPdisk.
  2. Если парольная фраза контейнера находится в кэше, нажмите PGPtray > Purge Caches.
  3. Дважды щёлкните на .pgd-файле контейнера, чтобы вызвать окошко ввода парольной фразы. Нажмите в этом окошке кнопку Options.
  4. Отметьте опцию As a directory on an NTFS volume, укажите каталог, под которым должен подключаться контейнер (этот каталог должен быть пуст) и нажмите OK.

Настройки и прежнее поведение контейнера должны восстановиться.

Забыл пароль к PGPдиску. Как мне теперь его открыть?

Без правильной парольной фразы это невозможно. Если бы PGP имел лазейки или обходные пути, им бы не пользовались десятки и сотни тысяч людей. Единственный совет – постарайтесь вспомнить пароль.

Не удаётся создать новый PGPдиск – процесс прерывается на стадии форматирования.

Причины этой проблемы поражают своим разнообразием. Чаще всего (и это удалось воспроизвести искусственно) она вызвана физическим повреждением жёсткого диска, на котором создаётся контейнер PGP, или повреждением в его файловой системе. Эту причину можно устранить, прогнав полную проверку ФС и поверхности диска с помощью scandisk или подобной утилиты.


Помимо этого было отмечено, что иногда она возникает из-за конфликта драйверов, сервисов и установленного ПО. Так, в одном случае снять проблему позволило обновление драйвера к IDE-контроллеру. Работающее приложение WebWasher также, по-видимому, способно приводить к нестабильности PGPdisk – его закрытие позволяет нормально открывать/закрывать контейнеры и создавать новые. Самое уникальное сообщение, полученное инженерным отделом PGPCorp, связано с конфликтом PGPdisk и некоторых сервисов видео-карт ATI. Снять проблему лёгким хирургическим путём (но без ущерба для видеоподсистемы компьютера) позволила выгрузка фоновых приложений cli и atiptaxx при помощи утилиты msconfig.


Таким образом, если проверка диска scandisk'ом не привела к положительному результату, сделайте следующее:


  1. В панели задач нажмите Пуск > Выполнить (Start > Run), в поле введите msconfig и нажмите OK.
  2. Откройте вкладку Автозагрузка, снимите флажки с нескольких приложений, нажмите OK и перезагрузите компьютер.
  3. Если попытка создать PGPдиск по-прежнему будет безуспешна, повторите шаги 1-2 и отключите ещё несколько приложений (только не отключайте ничего, связанного с PGP, т.е. pgptray, pgpsdksvc и т.д.).
  4. Продолжайте, пока не обнаружите причину конфликта. Определив конкретное приложение, вызывающее сбой в PGPdisk, оставьте его выключенным, остальные верните в прежнее состояние.

Из контейнера PGPdisk, подключенного как папка, не удаляются каталоги и файлы – система говорит Access denied.

Согласно информации из базы знаний Microsoft проблема в том, что Корзина Windows не распознаёт подключенный таким образом логический раздел. В качестве обходного средства вы можете либо отключить Корзину совсем, либо использовать комбинацию Shift+Del, чтобы удалять файлы и папки "мимо" неё.

Мои диски были зашифрованы PGP Whole Disk. После переустановки системы при попытке доступа к этим дискам система сообщает, что они не отформатированы и предлагает отформатировать. Как восстановить ценные файлы?

Если переустановка системы не затронула зашифрованные разделы, ваша информация цела и процесс по ее восстановлению будет достаточно прямолинейным. Во-первых, Вам нужно убедиться, что PGP установлен. А теперь приступим:


  1. Откройте консоль Windows и перейдите в каталог с установленным PGP. Для этого введите что-то вроде cd "c:\program files\pgp corporation\pgp desktop".
  2. Введите команду pgpwde --enum. Она отобразит нумерованный список разделов.
  3. Определите, какие разделы вам надо восстановить и затем введите pgpwde --status --disk 2 (при необходимости вместо цифры 2 подставьте номер нужного раздела).
  4. Если все в порядке, и зашифрованный диск по-прежнему работоспособен, программа выдаст ответ Disk 2 is instrumented by Bootguard. Если ответ будет какой-то другой, все несколько усложнится, но пока будем исходить из положительного ответа.
  5. Введите pgpwde --decrypt --disk 2 --passphrase Ваш_пароль. Это запустит фоновый процесс расшифрования. За прогрессом можно следить с помощью команды pgpwde --status --disk 2 — значение Highwater (число зашифрованных секторов) будет сокращаться.

По завершении проверьте, что содержимое раздела доступно и цело. Затем можете по желанию снова зашифровать диск с помощью Whole Disk.

Контейнер PGPdisk неожиданно перестал открываться: программа сообщает о неверном пароле или неизвестном формате файла. Что можно сделать? Возможно ли восстановить контейнер?

Это возможно, однако, успеха можно достичь лишь в определённых редких обстоятельствах. Краткая инструкция приведена в форуме. В общем случае, единственное решение подобных проблем — это восстановление резервной копии криптоконтейнера (если вы не забывали их делать).

Есть столько программ для дискового шифрования: PGP Whole Disk, TrueCrypt, DiskCryptor, FreeOTFE. Что выбрать, как разобраться в этом разнообразии?

Все названные программы открыты и, за исключением PGP, свободно доступны. Надёжность и безопасность их так же высока. Можно рассмотреть программы с точки зрения их применения в конкретных условиях.


  • DiskCryptor — свободное ПО, распространяемое на условиях лицензии GPL. Программа создана с единственной целью полного шифрования носителей (включая системный раздел), не имеет избыточных элементов. Криптографические алгоритмы реализованы с высочайшей степенью оптимизации, благодаря чему обеспечивается наибольшая, в сравнению с другими средствами, скорость доступа к диску. DiskCryptor более всего подходит для Windows-систем, нуждающихся в максимальной производительности: работа с большими массивами данных при повышенных нагрузках на ЦП, например, работа с крупными базами данных, обработка видео и т.д. До версии 0.4 включительно формат зашифрованных данных DiskCryptor совместим с TrueCrypt, что позволяет читать зашифрованные диски из ОС GNU/Linux с помощью Linux-версии TrueCrypt.
  • TrueCrypt — открытое ПО, выпускается в версиях для Windows, Mac OS X и Linux, поддерживает работу как с полностью зашифрованными носителями, так и с файлами-криптоконтейнерами, что делает его полезным в тех случаях, когда шифрование всего диска излишне. Имеет свойства "отрицаемого шифрования" (в виде скрытых разделов и скрытой ОС), пригодные при правовом давлении на пользователя с целью раскрыть секретные данные (стоит отметить, что при внеправовом воздействии, физическом принуждении "отрицаемое шифрование" может иметь обратный эффект, опасный для пользователя). Программа широко распространена, имеет значительную пользовательскую базу.
  • FreeOTFE — свободная программа (по условиям GPL), совместимая с Windows, включая Windows Mobile, что делает её незаменимой на КПК под управлением этой ОС; не требует инсталляции, можно запускать с флэшки. Возможности программы включают полное шифрование дисков (за исключением системного раздела с ОС) и работу с криптоконтейнерами, при этом FreeOTFE поддерживает формат "родных" Linux-средств, таких как losetup и cryptsetup-luks, обеспечивая доступ к зашифрованным устройствам из Windows, чем весьма ценна. Формат контейнеров FreeOTFE имеет свойства "отрицаемого шифрования": есть поддержка скрытых разделов.
  • PGP Whole Disk — единственная коммерческая программа с открытым исходным кодом для среды Windows и Mac OS X. Поддерживает работу с криптоконтейнерами, полное шифрование носителей и системного раздела диска. Зашифрованные данные легко идентифицируются (нет свойства отрицаемости), что является преимуществом в ряде ситуаций. Наибольшие преимущества достигаются в корпоративной среде за счёт мощнейших средств централизованного развёртывания и управления. За разработкой стоит компания и команда с высочайшей репутацией.

Очень удобно создавать криптоконтейнер в виде файла, ведь это даёт возможность легко делать резервные копии на различных носителях, просто скопировав этот файл. Также его легко отправить на сервер для пересылки или хранения. Почему однако не рекомендуется делать копии контейнеров таким образом?

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


Раньше для шифрования криптоконтейнеров в сответствующих програмах использовался обычный режим CBC (cipher block chaining – режим сцепления блоков, изобретённый для шифрования отдельных файлов) с простой привязкой IV (вектора инициализации) к номеру сектора файловой системы. Позднее выявились вполне практичные атаки multiscan – "атака уборщицы" (обнаружение фрагментов известного открытого текста без знания ключа в нескольких копиях контейнера или при доступе к одному и тому же закрытому контейнеру в разные моменты времени, когда его содержимое поменялось), watermarking (обнаружение подобранного открытого текста – доказательство наличия специально сформированных, незаметно помеченных и подброшенных пользователю файлов в контейнере без знания ключа – например при отправке их по электронной почте или при скачивании со специально созданного подставного сайта) и атаки на подмену (целенаправленная подмена с предсказуемым результатом фрагментов известных файлов путём изменения шифртекста контейнера без знания ключа).


Для борьбы с этими уязвимостями изобрели специальные более продвинутые режимы – CBC-ESSIV, LRW, XTS. В них постарались применить методы доказуемой безопасности для обоснования стойкости против подобных атак. Но эти доказательства пока признаны неполными и ограниченными, а качественный режим шифрования дисков так и не создан. Нет единого мнения – можно ли создать стойкий, но экономичный Narrow block режим шифрования или необходим обязательно Wide block режим.


Медленные Wide block режимы, перешифровывающие каждый раз при измении хотя бы одного бита весь сектор файловой системы, до сих пор практически не применяютя.


Доказательства стойкости Narrow block режимов ограничены. И их стойкость к атакам multiscan не рассматривалась, исследовались только ситуации противодействия атакам watermarking и против подмены. Возможно, в случае multiscan эти режимы будут уязвимы как к подмене и watermarking, так и к другим атакам.


Всё что пока удалось сделать исследователям – перенести эти атаки из достаточно практических в более теоретическую область. Но полноценный доверяемый стандарт на дисковое шифрование так и не создан.


Другая причина – управление ключами. Многие современные программы дискового шифрования предоставляют возможность изменить пароль контейнера или ключ, не перешифровывая весь контейнер (не изменяя его мастер-ключ). Кроме того, есть возможность хранить как дополнительные расшифрующие ключи, так и мастер-ключ в так называемом "хрупком" виде – в виде распределённого массива, большего по размеру чем сам ключ. Повреждение части битов этого массива намеренно усложняет восстановление ключа. Это позволяет сделать более надёжной процедуру смены и уничтожения ключа на винчестерах, флэш-накопителях и накопителях с возможностью восстановления данных (райд-массивах). При наличии нескольких копий одного и того же контейнера, наличии нескольких копий заголовочных блоков файла-контейнера, которые перемещались по файловой системе и других аналогичных ситуациях, этот метод управления ключами теряет свою надёжность.


Третья причина – наличие в некоторых программах вложенных скрытых контейнеров с функцией отрицаемого шифрования (возможность отрицать существование таких контейнеров по причине невозможности постороннему наблюдателю установить их количество). При наличии нескольких копий одного и того же контейнера стойкость отрицаемого шифрования против обнаружения снижается.


Четвёртая причина – при нахождении контейнера на удалённом недоверяемом сервере и регулярных его изменениях без полной перешифровки противник может осуществлять анализ трафика – общую интенсивность и объёмы изменямой информации без знания её содержимого.


На основании многих причин рекомендуется придерживаться следующей стратегии при работе с криптоконтейнерами.


  1. Использовать шифрование, привязанное только к конкретному носителю (физическому или логическому разделу диска), но не в виде файла поверх файловой системы. Современные программы шифрования позволяют изменять размер шифрованных разделов без потери данных.
  2. Не делать побитовые копии контейнеров. При необходимости делать резервную копию содержимого – создать контейнер на другом носителе (можно использовать тот же пароль – мастер-ключ шифрования всё равно сгенерируется другой) и перенести данные в него.
  3. При невозможности создания нового контейнера на самом резервном носителе (CD, DVD, удалённые серверы, отправка по почте) – дополнительно для этой цели создавать новый одноразовый контейнер, каждый раз заново перед записью или отправкой и уничтожать его лишние копии (которые например остались на винчестере после записи или отправки) или использовать другой способ шифрования.
  4. Не монтировать контейнеры с удалённых недоверямых серверов и не размещать их там для этой цели.

Эти требования могут быть ослаблены при наличии у пользователя достаточной квалификации в степени оценки угрозы безопасности его данным.

Как быстро заполнить устройство, раздел, том или файл случайными данными в Linux, чтобы подготовить его к шифрованию?


Поскольку при разметке раздела (а также физического или логического тома в Linux) как шифрованного и создании на нём файловой системы не происходит абсолютного заполнения, то на нём могут остаться обрывки предыдущих данных. Раздел (том) должен быть заполнен случайными данными, что также не даст противнику понять, насколько и в каких местах зашифрованный раздел заполнен полезным открытым текстом (например, чтобы не выявить отдельные файлы по заведомо известным размерам). Использование для генерации криптостойкого генератора случайных чисел /dev/urandom может быть слишком медленным процессом, а утилиты для затирания могут быть ненадёжны: содержать в себе быстрый, но некриптостойкий ГПСЧ или прерывать своё выполнение при генерации слишком больших объёмов случайных данных.

Способ затирания через зануление криптотома

Существует универсальная возможность поднять зашифрованный том, используя /dev/urandom только для генерации временного случайного ключа, не создавая затем файловую систему, а поднятый зашифрованный том заполнить потоком нулей из /dev/zero. При условии, что используемый шифр стоек и близок к идеальному, а режимы дискового шифрования обеспечивают достаточною рэндомизацию, знание противником факта содержания избытка нулей в открытом тексте не поможет криптоанализу.


Использование аппаратной поддержки AES в процессоре и модуля ядра для работы с ним сделает заполнение раздела практически равным скорости записи на носитель. Снаружи контейнер будет заполнен случайными числами с исходной стойкостью использованного шифра и выбранного режима шифрования.


cryptsetup -c aes-xts-plain64 -s 512 -d /dev/urandom create $DeviceName /dev/$DeviceToWipe

При достаточном количестве энтропии в системе можно использовать /dev/random для генерации ключа. $DeviceName — произвольно выбираемое пользователем название для устройства (указатель на имя криптотома, который будет поднят в каталоге /dev/mapper), /dev/$DeviceToWipe — путь к реальному устройству.


Также можно установить утилиту pv и смотреть показания счётчиков прогресса в конвейере команд (возможны индексы размера k, m, g, t).

dd if=/dev/zero bs=1M | pv -s [размер раздела в терабайтах]t > /dev/mapper/$DeviceName


После окончания закроем том:

cryptsetup remove $DeviceName


Примечание: при работе с носителями с избыточностью информации (Flash, SSD, некоторые типы RAID) частичное стирание данных с диска не гарантирует их уничтожение. Для затирания таких устройств рекомендуется выполнить процедуру заполнения случайными данными дважды.

Способ затирания через алгоритм HAVEGE

Алгоритм HAVEGE позволяет генерировать очень быстрые потоки псевдослучайных чисел на основе непредсказуемости колебаний времени исполнения некоторых операций на большинстве процессоров, что связано как с изменением загруженности процессора операционной системой, так и с особенностями внутренней работы самого процессора. Это потенциально позволяет выработать гораздо больше энтропии, чем при обычном перехвате системных прерывании и записи их параметров в пул /dev/random. При этом встроенный аппаратный генератор случайных чисел процессора не используется (во многих случаях ГСЧ в процессоре может отсутствовать или вызывать подозрение на наличие аппаратных закладок), а используется только таймер операций.


Установив соответствующий пакет haveged, а также команду pv для наблюдения за скоростью потока данных, можно быстро заполнить диск псевдослучайными данными:


haveged -n0 | pv -s [размер диска в терабайтах]t > /dev/[имя устройства]


Этот метод нежелательно использовать в виртуальных машинах и при наличии некоторых примитивных типов процессоров без ветвления операций (обычно встречающихся в миниатюрных устройствах). Хотя, с учётом того, что стойкость в плане неразличимости псевдослучайных данных от истинно случайных некритична на практике в процессе заполнения дисков, то этим методом можно пользоваться практически везде, как самым простым и быстрым.


Следует учитывать, что пакет haveged при установке в системе по умолчанию запускает специальный демон, который подкачивает по соответствующему алгоритму процессорную энтропию в пул /dev/random. При недоверии к этому алгоритму пакет можно удалить после заполнения диска, чтобы он больше не использовался системой для других целей.

Какой режим шифрования выбрать в cryptsetup/LUKS?


На данный момент рекомедуется использовать режим шифрования XTS-plain64 с ключом 512 бит (это два ключа по 256 бит: один для шифрования данных, другой для твик-вектора шифрования номеров секторов диска).


cryptsetup -s 512 -h sha512 -c aes-xts-plain64 luksFormat /dev/[имя устройства]


При этом полезно помнить следующее:


  1. Ранее был реализован только режим xts-plain, но он не позволял шифровать данные размером более 2 терабайт, так как это приводило к повторению счётчика и утечке данных об открытом тексте.
  2. Для замены xts-plain ранее предполагался xts-benbi — метод вычисления вектора инициализации сектора, позаимствованный из устаревшего LRW-режима. Сейчас его выбирать не рекомендуется. Помимо него, до появления 64-битного счётчика в plain-режиме мог применяться комбинированный режим xts-essiv, использование которого также не является оправданным.
  3. Хотя режим XTS способен работать с любыми шифрами, у которых размер блока равен 128 бит (напр. Serpent или Twofish), при реализации он корректно проверяется только с шифром AES. Так, при выборе другого шифра возникнет предупреждение, что для данной конфигурации отсутствуют проверенные тестовые векторы, следовательно процедура проверки корректности шифрования выполнена не будет. Также это может вызвать проблемы в будущем, если программная реализация будет изменена, а поддержка расшифровки данных, зашифрованных в XTS не для AES не будет реализована или окажется несовместимой. На данный момент, в более современных версиях ядер поддержка тестовых векторов для разных шифров в XTS-режиме уже включена. Проверьте в своём дистрибутиве отсутствие предупреждений путём просмотра сообщений команды dmesg после инициализации шифрования.
  4. Для режима XTS в настоящее время нужно выбирать ключ в два раза превышающий размер ключа в шифре (т.е. 256, 384 или 512 бит, но не 128 бит).

Альтернативой режиму XTS-plain64 является более старый и устоявшийся режим CBC-ESSIV, в котором устранены недостатки простого CBC путём использования шифрования совместно с хэшированием номера сектора. Этот режим не был создан профессиональными криптографами, не является оптимальным по скорости и др. ресурсам, но он получил широкое распространение, долгое время использовался во многих программах по умолчанию и никаких существенных уязвимостей в нём обнаружено не было. Его реализации без проблем позволяют использовать любой шифр, а не только AES (хотя использование шифров с размером блока 64 бит, таких как 3DES, Blowfish и др. вообще не рекомендуется для дискового шифрования). Ожидается, что он будет поддерживаться в будущем, что снимает проблемы совместимости.


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


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии [скрыть комментарии/форму]
— Ankor (07/04/2014 19:16)   профиль/связь   <#>
комментариев: 8   документов: 0   редакций: 0
На старом Debian, соответствующем дистрибутивном ядре и утилитах тоже всё работало — (рас)/шифровалось, но в dmesg или в syslog при попытке операций с luks выдавались предупреждения об отсутствии тестовых векторов. Ещё раз проверю, пофиксили ли это в стабильной ветке Debian и если даже там всё стабильно, то исправлю FAQ.

У меня в dmesg и /var/log/messages ничего нехорошего не появляется (Fedora 18).

Теперь рекомендуется plain64, остальные были временным выбором и оставлены для обратной совместимости. На будущее лучше их не выбирать.

Так и понял, спасибо, unknown.
— unknown (07/04/2014 20:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Так то Fedora, а текущий стабильный Debian никуда не торопится:





Только AES-XTS-PLAIN64 нормально работает. Пока считаем, что только то, что работает в стабильном Debian — работает везде.
— Ankor (07/04/2014 23:10, исправлен 07/04/2014 23:21)   профиль/связь   <#>
комментариев: 8   документов: 0   редакций: 0
Так то Fedora, а текущий стабильный Debian никуда не торопится

Тогда понятно — у вас, должно быть, ядро 3.2, а векторы добавили как раз в следующей версии.


P.S.: хм, ваш cryptsetup использует крипто ядра, а не libgcrypt?

— unknown (08/04/2014 10:13, исправлен 08/04/2014 10:22)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Точно не скажу, нужно смотреть исходники или доки, но cryptsetup, возможно, использует libgcrypt только для начальной инициализации: вычисления ключа из пароля и пр. Далее он инициализирует dev-mapper, который уже всё прозрачно шифрует через модули ядра (Crypto-API).


Спасибо за проявленное внимание к тонкостям, FAQ частично поправлен.

— Гость (13/04/2014 07:19)   <#>

Я предлагаю послушать unknown'а, но сделать всё по-совему.

Замечания следующие:


  • bs=1M — зачем это указывать? Вроде бы уже давно считается, что система сама умная и автоматически подберёт размер блока под нужный.
  • Конечно, можно брать пустой пароль в надежде, что внутрення кухня LUKS всё сделает правильно и в этом случае, но ведь нам ничего не стоит указать случайный пароль, почему бы тогда этим не воспользоваться? Идеологически я не люблю системы с единой точкой отказа. Если дёшево можно сделать чуть более стандартно и надёжно, то почему бы так не сделать?
  • Главная ключевая претензия: метод должен быть универсальным, а он таким не является. Я хочу получить диск, заполненный рандомом во всех местах, с затёртыми заголовками, сигнатурами и таблицей разделов; один рандом, и ничего кроме него во всех ячейках диска. Как правильно было отмечено выше, у LUKS есть длиннющая сигнатура, которая не охвачивается приведёнными дампами. Я сделал то, как предложил unknown, и увидел следующие 2 интересных момента:
    1. После слотов идёт длинная область нулей, прежде чем начнётся тру рандом на том диске, который так забивали нулями через cryptsetup.
    2. До тех пор, пока не сделал luksClose, не помогает ничего: ни sync, ни ожидание. В конце диска упорно наблюдается следующая картина: последние сектора забиты байтами ff, перед ними некоторое число забито нулями, и только ещё раньше идёт уже чистый рандом. Поначалу я было попенял на bs,* но он вроде как оказался ни при чём.

Итак, я предлагаю тупо скрипт, который делает всё хорошо:



Для USB-устройств и флэшек скрипт следует выполнять дважды. Никаких заголовк и сигнатур на блочном устройстве после работы скрипта не остаётся, т.к. мы завязались на plain mode.

Пояснения:


  • Можно было бы затирать заголовок как-то так, но ни к чему лишние костыли, когда plain mode уже есть и работает искаропки.
  • В dd можно было бы не ждать вылетания с ошибкой, а считывать точный размер блочного устройства через, к примеру, тот же fdisk. Правда, возникают опасения, что может так получится, что из-за ошибок записи/копирования часть байтов будет сглотнута по дороге и до носителя не дойдёт, в итоге конец будет недозаписан. Возможно, опасения безосновательны. Посмотреть, что находится в самом конце, можно через
    # dd if=/dev/DEVICE skip=NUMBER |hexdump -Cv |less
    где NUMBER — число, чуть меньшее того, которое указано в качестве секторов во второй строчке в выводе команды
    # fdisk -l -u /dev/DEVICE
    Из-за того, что dd вылетает с ошибкой «нет места», указывать после неё && смысла нет.
  • sync и sleep добавлены для собственного успокоения на всякий случай.
  • Флэшки и SD/MicroSD-карточки заполняются очень медленно. Даже на приличной качественной SDHC-карте скорость оказалась всего 9MB/s.
  • DeviceToWipe и DeviceName надо указывать правильно, а то может получиться с ололо с случайным затиранием другого подключенного в этот момент раздела.
  • Пример запуска:


  • Параметр -s в pv играет чисто информативную роль, чтобы показывать процент сделанного. Его можно указывать примерно. Поток данных всё равно будет писаться вне зависимости от того, что мы там написали, пока не произойдёт ошибка «нет места».
  • Насчёт 80 для pwgen: номинально это соответствует 512 битам. В «NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE» (см. man cryptsetup):

    From stdin: Reading will continue until a newline (or until the maximum input size is reached), with the trailing newline stripped. The maximum input size is defined by the same compiled-in default as for the maximum key file size and can be overwritten using --keyfile-size option.

    From a terminal: ... The has result will be truncated to the key size of the used cipher, or the size specified with -s.

    Не знаю, что в точности происходит, и можно ли применять комментарий для ввода с терминала к вводу с stdin, но звучит так, что есть некий размер, зависящий от выбора шифра и режима. Если будет дано меньше, он заполнит остаток нулями; если будет дано больше, он обрежет. Теоретически нет смысла брать больше 40 символов (256 бит), но технически, раз там идёт 512, не жалко указать и 80.
  • После затирания диска его разметку, если она кому-то нужна, надо создавать вручную:
    # fdisk /dev/DEVICE
    Удивляет, что fdisk всегда требует ставить начало (offset) 2048 для первого раздела, и это число никак не уменьшить, хотя в норме для дисков offset обычно принято делать равным 63. На HDD/SSD пока не проверял.

    В принципе, дисковые разделы — зло и атавизм, уже давно пора от них отказаться в пользу LVM'а и device mapper'а. Сигнатуры тоже не везде уместны, особенно на том, что смотрит наружу и видно всем. С другой стороны, бессигнатурный plain mode, боюсь, взрывоопасен для неавтоматического ввода паролей. Наверное, надо делать подстраховочный костыль: dd начала диска в память в файл на mfs, дальше цепляем его на losetup и подключаем через plain mode в cryptsetup.** Внутри должен сидеть скрипт, который будет делать всю остальную работу: подключать основное место на диске через device mapper, а потом травить на него LUKS с заголовком (внешний хидер). Если при хранении заголовка отдельно сигнатуры в сам криптотом не пишутся, то всё будет хорошо. Если пишутся, то надо извращаться тоньше. Внутри подключенного основного LUKS-раздела уже можно делать всё как обычно: бьём на части через LVM и подключаем разные «группы логических томов» как отдельные независимые LUKS-тома.

*Вдруг он пишет только целое число блоков, а небольшой остаток в конце диска, не укладывающий в целое число блоков, так и не будет записан?
**Если что-то пошло не так, ничего не будет запорото, просто повторим процедуру считывания с диска и повторно попытаемся расшифровать.
— Гость (13/04/2014 07:52)   <#>

Точнее, там туман. В man dd размер блока по умолчанию не указан, а языки поговаривают, что получается следующее: его умолчальный размер — 512 байт (размер сектора), а запись на флеш может идти только блоками по 128k (?) [а на некоторых, говорят, по 4k], поэтому малый размер блока не только приводит к катастрофическому замедлению операций, но ещё и к износу носителя, в то время как вреда от большого размера блока (в разумных пределах) нет. Добавил параметр размера блока:



За тем, как записался самый конец носителя, лучше следить. Уверенности, что он всегда записывается до конца, у меня пока нет.
— unknown (13/04/2014 13:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Интересно, есть что усовершенствовать. Вообще, метод создания криптотомов. заполняемых нулями, был придуман не совсем для абстрактного затирания. А чтобы на этом же устройстве затем сразу же поднять шифрованный LUKS-том для использования с другим паролем и без попыток сокрытия его сигнатур.

Если нужно просто затереть устройство, то haveged — оптимален (только если не внутри виртуалки!).
— Ankor (13/04/2014 15:16)   профиль/связь   <#>
комментариев: 8   документов: 0   редакций: 0
Когда читал faq, не обратил внимание, что рекомендуется LUKS. У него много преимуществ, когда дело касается использования пароля, но для затирания устройств plain mode ничем не хуже, а за счет отсутствия сигнатур даже лучше.

Гость (13/04/2014 07:19), относительно ваших замечаний:

bs=1M — зачем это указывать? Вроде бы уже давно считается, что система сама умная и автоматически подберёт размер блока под нужный.

Кем это считается, что dd вдруг поумнел? Всегда использовался блок 512 байт, ни о каких изменениях я не слышал. Если бы он брал его с потолка, команда dd count=xxx возвращала бы неизвестное число байт, куда это годится? Если не верите, попробуйте и посмотрите в stderr, сколько байт скопировано.
Так что размер блока стоит указывать обязательно.

Конечно, можно брать пустой пароль в надежде, что внутрення кухня LUKS всё сделает правильно и в этом случае, но ведь нам ничего не стоит указать случайный пароль, почему бы тогда этим не воспользоваться?

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

Главная ключевая претензия: метод должен быть универсальным, а он таким не является. Я хочу получить диск, заполненный рандомом во всех местах, с затёртыми заголовками, сигнатурами и таблицей разделов; один рандом, и ничего кроме него во всех ячейках диска.

Согласен, сигнатуры ни к чему.

Насчет скрипта:
1. Зачем городить echo COMMAND, если достаточно set -x?
2. Про размер блока уже написал, нужно указывать.
3. Зачем pwgen, если можно просто подать /dev/urandom как ключ (с ключом -d)?
4. Зачем спрашивать у пользователя имя устройства, ему заняться больше нечем? Проще сгенерировать случайное (можно с помощью pwgen, или просто head -c 16 /dev/urandom | xxd -p), проверить, нет ли такого уже в системе и использовать смело.
5. Почему бы не выяснить размер устройства, вместо того, чтобы спрашивать? Например, несложно выудить из /proc/partitions.
5. Не вижу смысла в sync без sleep после него, тогда уж наоборот. В любом случае, cryptsetup close не закроет контейнер, пока все не запишется.

Я обычно использую что-то вроде:
Можно пайпить через pv или использовать dd_rescue, чтобы видеть прогресс.

Относительно ваших пояснений:

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

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

DeviceToWipe и DeviceName надо указывать правильно, а то может получиться с ололо с случайным затиранием другого подключенного в этот момент раздела.

Проверку существования $DeviceName выполнить несложно.

unknown, я согласен с тем, что это только перестраховка и, если шифр стоек, все будет в порядке, но, по-моему, все-таки не стоит советовать использовать забитый нулями том. Если предположить, что используемый шифр будет взломан, атакующему придется исхитриться, чтобы заставить ввести нужное количество известного открытого текста — не вижу смысла помогать ему, услужливо забив нулями сотни гигабайт.

ИМХО стоит изменить в faq LUKS на plain mode со случайным ключом, ничего не потеряем, но проще и универсальнее.
— unknown (13/04/2014 17:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Исправил. Некоторые пояснения по ходу дела:

  • Скрипты, которые «делают всё хорошо» — вредны. Например, устройство, подключённое по USB, может отвалиться. А том будет висеть и его будет не закрыть. Для этого нужно уметь пользоваться хитрыми комбинациями команд dmsetup ls и dmsetup remove. И даже в штатных ситуациях нужно уметь просто размонтировать том, например, если нужно прервать выполнение обнуления и заняться этим по какой-то причине позже. В FAQ вносятся примеры команд, а пользователи пусть пишут скрипты, алиасы и пр. сами, запоминают, вносят в закладки или в блокнотики. Главное показать краткий пример, иллюстрирующий принцип. Это же касается определения размера устройства — как пользователь привык, пусть так и делает.
  • Традиционно остаётся bs=1M для зануления. На долгом опыте выяснено, что при большем размере блока ни на каких устройствах скорость записи не растёт.
  • В моей версии cryptsetup нет опции --type, а вместо close можно использовать только remove.
— Ankor (13/04/2014 18:39)   профиль/связь   <#>
комментариев: 8   документов: 0   редакций: 0
Спасибо, unknown. Насчет скриптов согласен, в faq им не место; мои замечания касались его использования гостем лично.

Написано хорошо, но я бы заменил
$DeviceName — имя тома устройства, /dev/$DeviceToWipe — путь к реальному устройству.
на
$DeviceName — имя устройства для зануления (может быть любым), /dev/$DeviceToWipe — путь к реальному устройству.
или что-нибудь в этом роде.
— unknown (13/04/2014 19:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Исправлено с учётом вашего пожелания.
— Ankor (13/04/2014 22:03)   профиль/связь   <#>
комментариев: 8   документов: 0   редакций: 0
Прекрасно, но, если вам не надоело, выбросьте, пожалуйста, -h sha512 из строчки
cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -d /dev/urandom create $DeviceName /dev/$DeviceToWipe

Когда мы подаем файл с параметром -d в режиме plain, его первые S бит (S — длина ключа, заданная нами с помощью -s) используются в качестве ключа без каких-либо преобразований, поэтому указание хэш-функции просто игнорируется.
(Поэтому требования к качеству ключевого файла для plain mode очень высоки; если хочется использовать большой файл с низкой энтропией, нужно использовать stdin.)
— unknown (13/04/2014 23:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Принято.
— Гость (16/04/2014 21:23)   <#>

Затирание блочного устройства в NetBSD


Для примера возьмём раздел wd0e. Создаём конфиг для cgd — файл paramsfile — и кладём в него:
algorithm aes-cbc;
iv-method encblkno;
keylength 256;
verify_method none;
keygen randomkey;
Может быть, параметры стоит подкрутить на лучшие с учётом текущего понимания вопроса, но я не вдавался в эти тонкости, и, по-моему, не всё, что в конфиге, может быть указано из командной строки. Традиционно советуют ставить keygen на randomkey, но это цепляет его на /dev/random, который блокирующий. Обычно это не вызывает больших проблем — достаточно постучать по клавиатуре несколько секунд, и оно сгенерится. Те, кому принципиально нужно автоматическое выполнение, могут переопределить этот параметр на /dev/urandom, заменив randomkey на urandomkey.

Теперь инициализируем блочное устройство как шифрованное:
# cgdconfig cgd0 /dev/wd0e /path/to/paramsfile
и заполяем его нулями через dd:
# dd if=/dev/zero of=/dev/cgd0d bs=1m progress=10
Стоит отметить, что интерфейс BSD dd отличается от Linux dd. Команда будет писать точку после записи каждых 10MB.

По умолчанию ядро поддерживает 4 устройства: cgd0-cgd3. Нужно брать свободное. Просмотреть, какое устройства на какой раздел зацеплены, вроде нельзя, если забыли, какие команды были выполнены (для анонимности самое то ☺). Если требуется одновременная работа с большим, чем 4, cgd, нужно перекомпилить ядро, указав требуемое количество.

Подробности в man cgdconfig:
http://netbsd.gw.com/cgi-bin/man-cgi?cgdconfig++NetBSD-current
— Гость (16/04/2014 21:26)   <#>
P.S. Насколько мне известно, cgd-устройства никогда не создают сигнатур, но в сорсы не смотрел, и ссылкой на респектабельный источник это подтвердить тоже не могу.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3