id: Гость   вход   регистрация
текущее время 17:10 28/05/2020
Владелец: 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 След.
Комментарии [скрыть комментарии/форму]
— unknown (17/04/2014 09:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я так понимаю, что это ихний аналог CBC-ESSIV. Cтранно, что при этом не указано, чем хэшируется или шифруется encrypted block number. Интересно, а XTS там не внедрили?
— Гость (17/04/2014 17:11)   <#>

Мы это обсуждали.


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


В man cgd этого тоже нет? Может быть, есть какие-то умолчания. Не могу ответить на этот вопрос.

Если я помню правильно, cgd был написан в районе 2005-го года, и впервые он появился в NetBSD 3.0. С тех пор, а это уже 9 лет, они ничего не меняли. На момент 2005-го cgd смотрелся не таким плохим на фоне того, как в это же время дела шли в Linux и других BSD (в OpenBSD вроде до сих пор есть только Blowfish), но теперь cgd смотрится устаревшим.
— unknown (17/04/2014 17:33, исправлен 17/04/2014 17:40)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Ну если вернуться к обсуждениям.


IV Methods

Currently, the following IV Methods are supported:

encblkno1 This method encrypts the block number of the physical disk block once with the cipher and key provided and uses the result as the IV for CBC mode. This method should ensure that each block has a different IV and that the IV is reasonably unpredictable. This is the default method used by cgdconfig(8) when configuring a new cgd.

encblkno8 This is the original IV method used by cgd and provided for backward compatibility. It repeatedly encrypts the block number of the physical disk block eight times and uses the result as the IV for CBC mode. This method should ensure that each block has a different IV and that the IV is reasonably unpredictable. The eightfold encryption was not intended and
causes a notable performance loss with little (if any) increase in security over a single encryption.

Сначала они перестраховывались восьмикратным шифрованием номера блока для получения IV. Затем решили, что это никак не повышает безопасность, а только вносит тормоза и остановились на однократном шифровании. В то время как в ESSIV используется подача ключа на хэш для вычисления вектора, а на шифр, собственно, для шифрования. Понятно, это хотя бы разные алгоритмы (ESSIV: {ключ → хэш → шифр} в отличие от ENCBLKNO: {ключ → шифр → шифр}). Хотя, формально режим ESSIV всё равно недоказанный.


В XTS пытались обосновать стойкость формально, но не решили проблему как безопасно можно получить и функцию номера сектора, и шифрование одним блочным шифром из одного ключа. Поэтому решили использовать ключ удвоенного размера (фактически два разных ключа XTS:{{ключ1 → шифр} + {ключ2 → шифр}}).


P.S.: Впервые из-за разметки получил ошибку: OpenSpace Warning: unknown action requested!
:)

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

Вспоминается стандартная дилемма «малораспространённую вещь никто не будет ломать» vs «если окажется, что в малораспространённой вещи есть фатальные ошибки, вы вряд ли о них узнаете», где второе умозаключение выводится из «широкая общественность не будет их анализировать, а взломщики возьмутся», что, в общем-то, тоже спорно. С учётом внимания, прикованного к LUKS, есть уверенность, что в нём нет очевидных проблем (хотя heartbleed ставит под сомнение и этот тезис), но с учётом его тотальной распространённости есть уверенность, что если в LUKS есть хотя бы одна мизерная ошибка, взломщики уже знают, как её проэксплуатировать на всю катушку. Получается парадокс. Что из этого перевешивает?

Я сконен к тому, что в LUKS в среднем всё сделано лучше, хотя у cgd есть ряд полезных фич интерфейса, которыми не обладает LUKS (обратное тоже верно). По крайней мере, их криптографический самопал у меня никого одобрения не вызывает. Почему им нельзя было взять и поступить так же, как команде DragonFly BSD [1],[2]? Оно очень просто и понятно: «мы не изобретаем велосипеды, если понимания, как сделать лучше, нет».

Кажется, я об этом писал, но давно, и искать оригинальный пост пришлось бы непозволительно долго: ОБС (если не изменяет память, это был dilmah) как-то сказал, что в cgd когда-то были ошибки, позволяющие расшифровать диск, поэтому критичные вещи он предпочитает шифровать им дважды (сверху cgd, внутри ещё один cgd). На мою просьбу сообщить хотя бы какие-то детали уязвимости он сказал читать рассылку. Может быть, в то время я был намного менее опытным в плане археогологических раскопок через поисковики, чем сейчас, но мне ничего найти не удалось. Да, теперь больше опыта и у меня и у гугла:

When a cgd(4) pseudo-device is unconfigured, the driver does not clear memory containing key material before freeing it back to other kernel use. A process may later allocate kernel memory and receive chunks with data previously used by the cgd driver which may contain encryption keys.

A cgd(4) device can be unconfigured, which removes the in-kernel configuration structures and prevents any further access to the decrypted contents of the disk via the cgd(4) driver until the key is re-entered. However, the structures containing key material were freed back to the kernel memory pool without having their contents erased first. It was therefore possible that key material could still be present in kernel memory after the user expected it to be destroyed.

Any mechanism that allows kernel memory disclosure poses potential security risks, and care is always taken to avoid disclosing previous memory contents when allocating memory in the kernel and communicating with userland; it is therefore considered unlikely that this problem would expose stale key material to any attacker not otherwise able to read kernel memory.

The potential exposure lies in the user expectation that the keys are destroyed; they may therefore take steps at this time which they might otherwise avoid while key material is live in the kernel, and which may increase the risk of key disclosure. The most significant risk lies in the use of BIOS suspend-to-disk mechanisms, which write out the contents of all physical memory to disk – potentially including uncleared cgd(4) key material.

Note that the use of such suspend-to-disk mechanisms with cgd(4) devices is heavily discouraged for these reasons; even when the device has been unconfigured and the key destroyed, decrypted copies of sensitive information from the disk may remain in physical memory pages from unrecycled kernel buffers or user applications.

Последнее замечение особенно интересно, этот вопрос тут уже поднимался. Видимо, интуиция мне правильно подсказывала, что после работы с критическими данными, строго говоря, должен следовать reboot, а ещё лучше «power off, батарею вынуть, а потом вставить и загрузиться». У меня есть подозрение, что раз гостевые ОС заведомо являются недоверенными, то перед выделением памяти им она обнуляется,1 это создаёт дополнительную страховку против утечек памяти,2 но 100%-ой гарантии, что всё неиспользуемое обнулилось, всё равно нет. Не зря в Tails есть аларм-кнопка принудительного обнуления всей памяти перед тем, как ребутнуться.

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

Six vulnerabilities can be used by a local attacker.
  • An attacker can use ptrace to attach to a privileged process.
  • An attacker can generate an integer overflow using FreeBSD compatibility.
  • An attacker can conduct a denial of service by using fnctl() with F_CLOSEM parameter.
  • An attacker can conduct a denial of service by using SO_LINGER socket option.
  • Sensitive data of cgd is not erased from memory.
  • An attacker can change a file during imake usage.

На тему режимов в рассылке есть уютный срач между Roland C. Dowdeswell'ом, автором cgd,3 и Steven M. Bellovin'ом. Цитировать не буду, дам краткий пересказ:

— (публика): Почему в NetBSD только один CBC, где поддержка LRW?
— (публика): Да-да, в CBC вотермаркинг?
— Bellovin: Я не эксперт в cgd, но к нему, кажется, такая атака вообще неприменима.
— (публика): IV в cgd непубличны и неинкрементальны, поэтому вотермаркинг работать не будет. Если считать, что IV строго рандомны, то CBC строго стойкий.
— (публика): Надо либо интегрировать IV в файловую систему, либо использовать блочные шифры рода «tweakable» и слушать Рогавея, но это всё равно будет давать утечки о том, что происходит с шифрованным диском.
— Dowdeswell: Вотермаркинг работал против Linux'а, cgd — хороший. Может быть, нам стоит перейти на LRW? Как там с благословением LRW НИСТом?
— Bellovin: НИСТ пока не благословляет LRW.

На том и закончили.

Тут пишут, что TrueCrypt 4.0 и более ранних тоже были уязвимы к вотермаркам.

Про утечку через аллокацию памяти в cgd и про итог:

Dowdeswell: I've fixed the problem and will be submitting a pullup request for the next NetBSD release.

Честно говоря, не знаю, что про него сказать и думать. Судя по этому подобию CV, что касается крупных известных проектов, он активно коммитит в Kerberos. Есть профиль на Savannah. Про его образование в CS/Crypto ни слова. Наверно, просто программист.

Вообще, все эти ссылки воходят к 2005-2006 годам. Я эти старые уязвимые версии cgd даже в глаза не видел. В NetBSD 3.0, которая вышла 23/12/2005, этих проблем с cgd уже не было. Думаю, в старых версиях LUKS того же времени дыр также хватало.

Никаких других дыр в cgd помимо перечисленных сходу не гуглится. Наверное, это единственное, что когда-либо было.


Можно просмотреть список используемых на текущий момент, но если эти девайсы не используютя для RAID'ов, то не понять, какой cgd с каким блочным устройством связан.


Движок угадал, кто всему виной!


1Иначе одни юзеры виртуальных хостингов смогут красть информацию других таких же юзеров.
2Контроль как на уровне ОС, так и на уровне гипервизора.
3Сам сайт http://www.imrryr.org доставляет.
— Гость (07/05/2014 07:52)   <#>

Фикс: имелось в виду тестирование на флэшках.


В данном случае — согласен, не подумал просто. А вообще, так гибче просто: можно самому указать, какие команды отражать в echo (и в каком виде), а какие нет. Как видите, в приведённом скрипте всякие sync'и не отображаются, ибо нечего мусор выводить.


Замечание принято. Привык мыслить в терминах паролей, а тут это ни к чему. Кстати, остаётся открытым вопрос, стоит ли указывать /dev/random вместо /dev/urandom.


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


Можно, просто лень было делать идеал. Замечение

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

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


Строго говоря, пока sync не выполнится, приглашение командной строки не возвращается, поэтому «после» я счёл излишним, а «до» происхоит много что, и тут нужно гарантировать, что процесс «закончен». Это всё на уровне народных верований. ☺ Наверное, правильнее sleep убрать отовсюду — он имел бы смысл между командами, которые не есть sync.


open — наверно, устаревшая опция. В man cryptsetup для plain mode есть только 4 операции: create, remove, status и resize. Шифр/режим лучше задать (-c aes-xts-plain64 -s 512), т.к. умолчания cryptsetup нацелены на производительность и массовость применения, а не на максимальную безопасность.


А что она даст? Оба раздела существуют. От ошибки затирания это не страхует. Если вы имели в виду «существования среди подмонтированных», то «не все разделы системы всегда подмонтированы».


Такой взлом шифра — нечто из раздела фантастики. Что вы предлагаете в качестве альтернативы? ГПСЧ того или иного сорта вшивости? Тогда разве что через haveged или openssl, т.к. /dev/urandom слишком медленный. К слову, даже если используется пустой пароль, мастер-ключ всё равно случайный, и после затирания привязки (соли) его не восстановить никак (по крайней мере, в идеале оно должно так быть).


Когда нет скриптов, возникает обратная сторона медали:
  1. Даже прекрасно зная матчасть, вы рано или поздно опечатаетесь или забудете какие-то важные опции. Нужно избавить себя от требования постоянно вводить длинные команды, критичные к ошибкам, да ещё и помнить их наизусть.
  2. Новичку, не чувствующему себя как рыба в воде, трудно скомпилировать из разрозненных команд цельный правильно работающий скрипт.
  3. Форсмажор с внезапным отваливаванием чего-то, требующий ручного вмешательства — не такой частый случай. И, в конце концов, никто не говорил, что не надо пытаться понять скрипт, или что не надо уметь адаптировать его под свой случай. Скрипт — он в помощь, а не вместо головы.
  4. Часто рекомендации, как сделать лучше, разбросаны по всему тексту (а то и по всему сайту). Скрипт собирает их все в одно место. Получается неплохая «отправная точка» для модификаций скрипта под себя.


+1


Тут надо делать так, чтобы это не приведило к путанице. В скриптах (да и не только), лучше сразу возложить ответственность на пользователя за полное корректное название устройства с полным путём к нему. В общем-то, так во всех инструкциях и делают (вспомните, что не обсуждается, как будет указан путь к файлу — везде просто FILE, а вы уже сами думаете, надо ли в конкретном случае указывать путь, и если надо, то какой). Нетрудно представить, что будет, если в системе есть, к примеру, устройства /dev/sdb и /dev/mapper/sdb, и пользователь их перепутает...

В тексте FAQ:
Я уже делал замечание на этот счёт. Запомните: аргумент у luksClose и remove — лейбл конечного LUKS-устройства, а не «он + полный путь к нему». То, что вы написали, насколько я помню, не сработает, причём тихо (можете посмотреть на содержимое /dev/mapper после выполнения этой команды: устройство останется на месте, а мастер-ключ в памяти). Должно быть: cryptsetup remove $DeviceName.


Правильное замечание. Мои примеры изначально были с stdin, и там хэширование может быть использовано (как и для ввода с терминала). Вообще, если вспомнить про применение бессигнатурного шифрования (plain mode), нужно отметить, что хэширования вы не избежите хотя бы по той простой причине, что вы не можете (быстро и легко без промежуточных шагов) ввести в качестве пароля бинарный мастер-ключ — попросту не все символы в случайном мастер-ключе печатные. Тут будет естественный выход — помнить достаточное (по энтропии) количество печатных символов, которые потом будут сконвертированы в хэш и отданы на вход в LUKS. Надеюсь, когда в man cryptsetup пишут про хэширование, имеется в виду, что хэш может быть бинарным (а не только base64, каким мы его всегда видим), иначе было бы совсем плохо. ☺

Объяснения в «NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE» слишком заархивированы и сжаты, но после сотого прочтения смысл начинает доходить.

[дилетантство]
Оба ключа на шифр? Может быть, в одном случае подаётся-таки на хэш? Какое-то нелогичное объяснение: подача ключа на шифр объясняется через подачу ключа на шифр. Если нечто — шифр, он должен требовать и задания IV. Наверное, имеется в виду подача не на шифр, а на какой-то более низкоуровневый примитив типа PRP.
[/дилетантство]
— SATtva (07/05/2014 09:10)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094

Тогда есть смысл использовать функцию-логгер, чтобы не дублировать команды вручную:

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

fileIEEE P1619™/D16 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices. Есть и более новые спецификации, но в этой пэдээфке на пятой странице относительно понятная и наглядная картинка. Может где-то и слайды есть.

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

P.S.: над остальной частью вашего комента нужно думать. По крайней мере публикация полновесных скриптов непосредственно в FAQ, на мой взгляд, не вполне уместна. Разумнее предлагать минимальный набор команд с разъяснением их принципов. Сами скрипты можно выносить в какие-то отдельные документы для желающих. Например, мне их неинтересно будет ни проверять, ни поддерживать (это часто относится даже к скриптам, которые пишутся для своих нужд), а вот исправить команду при смене формата утилит, найти в ней ошибки, обсудить тонкости — гораздо проще. И то, как видите, руки далеко не сразу доходят.
— Нинадёжна (07/05/2014 17:05)   <#>

bash сложнее чем кажется:

— Гость (13/05/2014 10:41)   <#>

А произнесённые в ответе аргументы не касаются ли, случаем, и логических томов LVM? Можно ли гарантировать, что сами по себе extents внутри volume group не переносятся с одного места на physical volume на другое (по аналогии с дефрагментацией ФС)?
— Гость (13/05/2014 10:48)   <#>

Эта проблема как-то фиксится (помимо использования воркэраунда с set)?
— SATtva (13/05/2014 11:03)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Моё bash-foo недостаточно крутое. :( Вероятно, надо как-то заставить его обрабатывать кавычки в сабшелле буквально, но как это сделать (и можно ли) — без понятия.
— unknown (13/05/2014 11:04)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Разумно исходить из того, что этого исключить нельзя. Ведь если я правильно понимаю, LVM-снэпшоты работают по похожему принципу. Значит такой механизм уже предусмотрен by-design.
— Гость (13/05/2014 11:13)   <#>

"$@", в отличие от "$*", развернётся в список аргументов функции, а не в одну строку.
— Гость (13/05/2014 11:36)   <#>

Строго говоря, не знаю, зачем при затирании дисков кому-то в скрипе позарез понадобятся директории с пробелами. Искуственно можно сделать, наверное, пробел, в лейбле, типа '/dev/mapper/link with space', но можно не стрелять себе в ногу.


Проверил, не работает ничего из:
run ls "/test\ dir"
run ls "/test dir"
run ls /'test dir'


Возможно, есть важное отличие. В ФС старые уже записанные данные могут быть перемещены в рамках логики работы самой ФС, в то время как в LVM екстенты куда-то перемещаются только при отдаче специальных команд типа «перенести все экстенты на один физический том, чтобы освобить другие физические тома и отключить их из системы», но пока это только мои предположения.
— Гость (04/06/2014 06:11)   <#>

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


Сделал. Есть косметические замечения:
  1. Если две команды в одной строке соединены через пайп, set -x их считает двумя разными командами и отображает соответственно, а не хотелось бы. Внесение обеих команд в одни круглые скобки (выполнение в локальном шелле) не помогает. Это как-то исправляется?
  2. К самой set +x тоже применяется правило set -x, т.е. сама команда set +x тоже отображается в выводе. Это можно как-то подавить?


Учтено и сделано.


Поставил random. Это вызывает задержку в несколько секунд, но я такую проблему не считаю принципиальной. Те, кому не нравится, могут исправить на urandom.


Поскольку имя генерится случайным образом, вероятность возникновения коллизии считаем исчезающе малой.


Решил статически вписать в скрипт. Вряд ли у кого-то будет желание часто менять этот параметр.


Сам исправил в FAQ.

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

Сам скрипт:
#!/bin/sh
# Script to wipe block device. It was tested with cryptsetup 1.4.3.
 
DeviceToWipe=$1  # Examples: /dev/sdb, /dev/mapper/MyDevice, etc.
DeviceName=`tr -dc "[:alpha:]" < /dev/urandom | head -c 12` 
DeviceSize=`cat /proc/partitions | grep \`readlink -f $DeviceToWipe \
            |sed 's/\/.*\///'\`$ | awk '{print $3}'`k
BlockSize=10M
 
echo Wiping block device $DeviceToWipe 
 
STARTTIME=$(date +%s)
 
set -x
cryptsetup -c aes-xts-plain64 -s 512 -d /dev/random create $DeviceName $DeviceToWipe && \
dd if=/dev/zero bs=$BlockSize | pv -s $DeviceSize > /dev/mapper/$DeviceName 
 
set +x
sync
sleep 1
 
set -x
cryptsetup remove $DeviceName && \
cryptsetup status $DeviceName 
 
set +x
sync
 
ENDTIME=$(date +%s)
echo Elapsed time: $(($ENDTIME - $STARTTIME)) seconds
Вот так выглядит выполнение (тестировал на той версии, когда отображения времени ещё было в коде):
# ./script.sh /dev/sdc
Wiping block device /dev/sdc
+ cryptsetup -c aes-xts-plain64 -s 512 -d /dev/random create ABCDEFGHIJKL /dev/sdc
+ dd if=/dev/zero bs=10M
+ pv -s 12345678k
XXX MB X:XX:XX [ XXXMB/s ] [ ======================>             ] 99% ETA 0:00:00
pv: write failed: No space left on device
+ set +x
+ cryptsetup remove ABCDEFGHIJKL
+ cryptsetup status ABCDEFGHIJKL
/dev/mapper/ABCDEFGHIJKL is inactive.
+ set +x
echo-тесты делал как на обычных дисковых разделах, так и на LVM-томах и на блочных устройствах LUKS. Вроде размер во всех случаях определяется правильно.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3