id: Гость   вход   регистрация
текущее время 03:12 23/11/2017
Владелец: SATtva (создано 14/09/2006 22:50), редакция от 04/06/2014 03:57 (автор: Гость) Печать
Категории: софт, pgp, инфобезопасность, защита дисков, truecrypt, сайт проекта, faq
https://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 След.
Комментарии [скрыть комментарии/форму]
— Гость (15/02/2010 19:53)   <#>
Меня смущает ответ на этот вопрос. Там много написано про то, что конкретно к криптофс на файле прямого отношения не имеет: вопросы создания копий одной и той же криптофс в разные моменты времени (что, вообще говоря, может быть безотносительно того, в файле ли крипитофс или на дисковом разделе). Допустим, что у меня есть один файл в 20 гигов на обычном дисковом разделе, и в нём криптофс, и я его никогда никуда не копирую, а отрицаемым шифрованием не заморачиваюсь, при этом атака уборщицы будет работать всегда: если кто-то получает доступ к диску в разные моменты времени, то не важно в чём криптофс – файле или разделе. Чем тогда хуже криптофс в файле? С точки зрения того как работает сама ОС с такой структурой, отличий нет. Кроме того, если какая-то шифроФС не позволяет шифровать напрямую дисковые разделы (например, работает в userland), то делается такой обходной путь: создаётся раздел, а на раздел ложится один файл размером с весь раздел, и уже в этом файле наводится криптоФС. Чем, например, этот случай будет хуже (вопросы отрицаемого шифрования опустим пока) обычного шифрования раздела?

Надо бы повысить логическую консистентность раздела: расщепить этот FAQ-вопрос на два.
— unknown (16/02/2010 21:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Атака уборщицы на доступ к файлу в разные моменты времени действительно возможна в любом случае. Но есть нюансы.
Всё-таки нельзя поручиться, что кто-то из пользователей сам рано или поздно не захочит сделать копию или бэкап. Но если атака уборщицы требовала заблаговременного тайного вмешательства до момента X, то при наличие неперешифрованных копий на нескольких носителях сразу у противника появляется возможность получить к ним доступ уже после момента X, если они окажутся в пределах его досягаемости — при похищении, изъятии и т.д.

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

Пусть даже пользователь неточно расчитает размер раздела и округлит его до нескольких килобайт свободного места. Пусть пользователь создаст для экспериментирования и тренировки файл-шифроконтейнер с паролем qwertyuiop. Убедится, что файлы копируются, всё открывается, закрывается и найдёт интересную опцию: сменить пароль.
И решит сменить пароль на более стойкий "Vg6%7HJkk(ml#R25hka5, чтобы с этим контейнером уже можно было работать всерьёз.

Но что при этом произойдёт? Мастер-ключ контейнера останется прежним, сменится только ключ, получаемый из пароля для расшифровки мастер-ключа. Такая смена пароля отчасти полумера, поскольку расчитана на модель угрозы: "противник не успел воспользоваться старым паролем, чтобы извлечь мастер-ключ и продолжать иметь возможность использовать его независимо от всех последующих смен паролей". Ведь мастер-ключ нельзя сменить без полной перешифровки контейнера.

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

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

Автор LUKS по крайней мере предлагал в своей работе твёрдо придерживаться правил: контейнер без побитовых копий и бэкапов (если в нём предполагается дальнейшее изменение содержимого); контейнер, привязанный к тому или разделу, но не файлу поверх FS.

А дальше решайте сами, по своей ситуации, просто помните, что хотя бы теоретические атаки на копии контейнеров без полной перешифровки могут существовать и стойкость режимов именно дискового шифрования в таких условиях формально не доказана.
— Гость (16/02/2010 22:33)   <#>
лучше придерживаться более строгих политик безопасности и руководствоваться принципом
Эти требования могут быть ослаблены при наличии у пользователя достаточной квалификации в степени оценки угрозы безопасности его данным.
что вы для себя и сделали.

Можно сказать, что это попытка осуществить защиту от дурака. Все серьёзные системы безопасности серьёзно на такую защиту не полагаются. Изначально слабый пароль на контейнер – уже диагноз, кроме того мастер-ключ формируется из файла привязки (соли) и собственно пароля. Серьёзная атака подразумевает осуществление двух вещей: угнать файл привязки и расшифровать его (а на нём стоит ещё один пароль), и узнать основной пароль на диск (как правило, в серьёзной системе это можно сделать только с помощью кейлоггера или TEMPEST-технологий). Т.е., казалось бы, FAQ должен быть написан на уровне, доступном для понимания, но в то же время без искажений правды. Можно в перспективе подумать о том, как чётко изложить эти идеи с тем же смыслом, но без неверной расстановки акцентов.

Что же касается разных копий контейнера, не думаю, что здесь всё так уж плохо. В реальной системе я могу допустить существование до 3ёх-5ти копий одного и того же контейнера в разное время, и более чем уверен, что практически это не поможет противнику получить доступ к данным (оставляя теоретические наработки в стороне). Между прочим, это легко показать. Допустим, что это не так, тогда возможность получить доступ к диску с зашифрованным контейнером в моменты времени t1, t2 и t3 позволяет полностью вскрыть данные (хотя бы на уровне вотермаркинга). Но очевидно же, что это не так! – Если сама шифроФС предоставляет защиту от подобных атак (типа вортермаркинг), то и наличие 3х копий здесь не поможет. Эта ситуация ничем не отличается от одновременного овладевания 3мя копиями, о которой вы выше говорили.
— SATtva (16/02/2010 22:42, исправлен 16/02/2010 22:42)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046
мастер-ключ формируется из файла привязки (соли) и собственно пароля. Серьёзная атака подразумевает осуществление двух вещей: угнать файл привязки и расшифровать его (а на нём стоит ещё один пароль), и узнать основной пароль на диск...

Привязка — это [по умолчанию] открытая случайная строка, единственная цель которой — защита от предрассчитанных таблиц ключей/паролей. Если какая-то конкретная СКЗИ допускает хранение привязки отдельно от зашифрованных данных, да ещё и её шифрование (превращающее её по сути в ключевой файл), то это ни коим образом не затрагивает 99% остальных СКЗИ. Так что все дальнейшие выводы, базирующиеся на данной посылке, хоть и не ложны, но весьма и весьма специфичны.

— Гость (16/02/2010 22:56)   <#>
Если какая-то конкретная СКЗИ допускает
Я всегда думал что таких СКЗИ большинство, навскидку приходит в голову geli (FreeBSD), cgdconfig (NetBSD), vnconfig (OpenBSD), loop-aes (Linux, раньше требовались шаманские пляски с gpg) [про dmcrypt не в курсе]. К тому же, раз на сайте отдаётся явное предпочтение нормальным хорошим СКЗИ типа TC/DC/LUKS и прочим, то и FAQ должен бы касаться именно того как шифрование организовано в тех системах, а они позволяют провернуть вышеописанную схему стандартными средствами (более того, она и рекомендуемая).
— unknown (17/02/2010 09:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
кроме того мастер-ключ формируется из файла привязки (соли) и собственно пароля. Серьёзная атака подразумевает осуществление двух вещей: угнать файл привязки и расшифровать его (а на нём стоит ещё один пароль), и узнать основной пароль на диск (как правило, в серьёзной системе это можно сделать только с помощью кейлоггера или TEMPEST-технологий).

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

Кроме соли LUKS может использовать привязку к дополнительному внешнему файлу (например на флэшке).

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



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

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

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

Насколько эти теоретические атаки опасны? Ну может в какой-то системе раскрытие скажем одного блока 128-бит данных открытого текста на терабайт за 264 операций уже критично. А кто-то уже завтра опубликует такого рода атаку.
— unknown (17/02/2010 21:52, исправлен 17/02/2010 22:18)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вот образец вывода комманды cryptsetup luksDump:



Мастер-ключ генерируется не из пароля вообще, а из рэндома. Дайджест для его проверки — открытый. Соль и маленькое число итераций мастер-ключа используются для получения из него дайджеста (PBKDF2). Дайджест используется для проверки ключа перед его использованием для шифрования. поскольку брутфорсить сам рэндомный мастер-ключ бесперспективно, то число итераций мало.


Затем так: ( Пароль || соль) → многократное хэширование (PBKDF2) → ключ слота → шифрование ключом слота мастер-ключа → запись зашифрованного мастер-ключа и соли в слот.


Параметр AF-stripes — растягивание ключа по битам для алгоритма AntiForensic-processing. Работа именно этого алгоритма не гарантируется (или по крайней мере снижается эффективность) при сохранении контейнера в файле за счёт возможных перемещений по блокам файловой системы.


Смена пользовательских ключей в слотах — нормальная процедура менеджмента паролей/пользовательских ключей, а не просто "защита от дурака" (как приведено для самого крайнего примера). Кроме того, в понятие управление паролей входит и их удаление: быстрое и максимально трудновосстановимое уничтожение ключей в слотах, а чтобы не нужно было тратить время на уничтожение всего контейнера — то и последнего используемого слота и соответственно мастер-ключа.


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


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

— Гость (18/02/2010 10:22)   <#>
Всё у вас в Linux как-то сложно, то ли дело тут.
— unknown (18/02/2010 12:58, исправлен 18/02/2010 13:09)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Для пользователя всё просто. А вот разработка не хакерами велась, поэтому дизайн был спроектирован как исследовательская работа с формальным обоснованием стандарта.
Вот работы по LUKS: fileраз, fileдва.
А где можно почитать работы по другим системам шифрования дисков?
Или авторы пишут только код и мануалы?


Там всё ещё используется простой cbc вместо CBC-ESSIV, LRW или XTS?


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

— Гость (18/02/2010 17:23)   <#>
А где можно почитать работы по другим системам шифрования дисков?
Или авторы пишут только код и мануалы?
Вот fileнаучная статья по cgd от её автора. Здесь есть ещё кое-какая информация с аргументацией, а также ссылка на интервью с автором. Делалось это всё ещё в мохнатом 2005ом году. Когда LUKS появился? Автор cgd вот тут в интервью намекает:
How does CGD compare to Linux's Loop-AES?
RD: I first looked at Linux's cryptoloop, which has all of the problems of OpenBSD's svnd and more. Loop-AES addresses these issues in a very different way than CGD does, but from a quick analysis it appears to solve the issues.
Пытался нарыть инфу по режиму в vnconfig, но не нашёл даже указаний на cbc, хотя солевой файл там недавно прикрутили.

Здесь страница о том, как оно выглядело n лет назад. Пишут, что в geli используется CBC-ESSIV. На сайте FreeBSD молчок по этому поводу. Поглядел что пишут в инете – у всех почему-то cbc на geli. Какую-то инфу по системам шифрования можно выудить из wiki, но не ясно насколько можно доверять.

Там всё ещё используется простой cbc вместо CBC-ESSIV, LRW или XTS?
В общем-то да.

Тогда атаки ватермаркинга, мультискана и пр. действительно против таких криптосистем несложны и обсуждать защиту от них смысла нет.
Вроде бы мы договорились до того, что мультискан будет работать в любой из существующих криптоФС, а вот с вотермаркингом интереснее: вы утверждаете что ему подвержены все системы шифрования в BSD (geli, vnconfig, cgd)?
— unknown (18/02/2010 17:42, исправлен 18/02/2010 17:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

loop-aes (и его предшественник cryptoloop) не имеет отношения к связке cryptsetup/dmcrypt/LUKS. Loop-aes как раз критиковали за "хакерские" методы разработки, отсутствие проработанной документации и не включили официальную поддержку в ядро и утилиты. Он включён во многие дистрибутивы, скорее для обратной совместимости, но его текущий статус можно рассматривать как "deprecated".


При использовании простого CBC с шифрами с 64-битным блоком (blowfish, 3-DES) возникает ещё одна интересная проблема. При создании контейнера больше 32 Гб из-за парадокса дней рождения резко возрастает вероятность появления одинаковых блоков шифртекста. Просканировав контейнер на наличие таких блоков можно вычислить xor некоторых блоков открытого текста, не зная ключа (проблема утечки данных об открытом тексте).


что мультискан будет работать в любой из существующих криптоФС

Возможно (но не могу точно сейчас утверждать) разная сложность применимости в зависимости от режима шифрования.

с вотермаркингом интереснее: вы утверждаете что ему подвержены все системы шифрования в BSD (geli, vnconfig, cgd)?

Только с plain-CBC.

— Гость (18/02/2010 17:51)   <#>
A aes-cbc [который как раз в cgd и geli] – это plain-cbc?
— unknown (18/02/2010 17:58, исправлен 18/02/2010 17:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Судя по cgd:

есть ещё кое-какая информация с аргументацией, а также ссылка на интервью с автором

Аргументация сводится к тому, что их режим encrypted-IV-CBC не хуже ESSIV. Скорее всего так и есть.

— Гость (18/02/2010 18:32)   <#>
Там всё ещё используется простой cbc вместо CBC-ESSIV, LRW или XTS?
Тогда атаки ватермаркинга, мультискана и пр. действительно против таких криптосистем несложны и обсуждать защиту от них смысла нет.

Аргументация сводится к тому, что их режим encrypted-IV-CBC не хуже ESSIV. Скорее всего так и есть.

Прям взаимоисключающие параграфы :-) Складывается ощущение подвешенности вопроса, типа "мутно всё, но следует (якобы) считать что крипто в BSD сакс".
— unknown (18/02/2010 21:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
За полчаса трудно разобраться с этим вопросом. Только беглые замечания. Статья, ссылка на которую приведена, мало описывает механизм собственно шифрования и больше рассказывает о том, как реализован драйвер и какое быстродействие.

ESSIV не имеет формальных доказательств стойкости, но более известен и неформально расценен положительно. "encrypted-IV-CBC" — это я уже придумываю такое название для режима cgd. Я так понял, что сами авторы этот режим шифрования даже никак не назвали. Судя по описанной ими идее он не отличается по стойкости от ESSIV и даже может быть лучше в плане ничтожно маловероятных (2-64 — 2-128) утечек открытого текста.

Профессиональными криптографами с формальным доказательством стойкости созданы режимы LRW (найдена специфическая уязвимость), XTS, XEX.

Возможно в каких-то программах даже при использовании CBC используются не основанные на формальных доказательствах трюки для увеличения стойкости (как в loop-aes): счётчики, растянутые ключи и др.

Где-то был профессиональный сравнительный анализ дискового шифрования в Unix. Какая-то система из BSD критиковалась, остальные оценивались на уровне Linux-LUKS, хотя с меньшим числом дополнительных фич, loop-aes даже не стали анализировать (при том, что это тоже неплохой проект, но слишком "хакерский").

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

Конечный пользователь может не лезть в эти теоретические дебри, важнее соблюдать практические меры безопасности (защиту от вредоносного ПО например), но использовать эти советы несложно. Хотя и необязательно, но делайте выводы сами — это разумный и обоснованный перфекционизм или это излишество.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3