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

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


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

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

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

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

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

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

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


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

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

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

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


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


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


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


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

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

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


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


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

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

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


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

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

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

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

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

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


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


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


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

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

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

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

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


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

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

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

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

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

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


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

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

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


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


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


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


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


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


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


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


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


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


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

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

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


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

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

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


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


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

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


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

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


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

cryptsetup remove $DeviceName


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

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

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


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


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


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


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

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


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


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


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


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

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


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


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии [скрыть комментарии/форму]
— unknown (29/10/2013 21:35, исправлен 29/10/2013 21:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Значит вы, как небезызвестный тут всем spinore, воспринимаете энтропию слишком, как он говорит, физично


А в выч.-стойком крипто взяли 128-бит реальной энтропии на входе, а сколько промежуточной псевдоэнтропии из неё выжали — неважно (в пределах допустимой области использования). При правильно сконструированном протоколе его стойкость останется 128-бит.


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


Проще пояснить на примере. Когда команда Шнайера создала шифр Twofish, то там были претензии к такому свойству: только половина ключа уходила на раундовое ключевое расписание, а вторая половина — на формирование зависимых от ключа S-блоков. Возникло сомнение, что если такая конструкция плохо обоснована, то теоретически могут действительно быть созданы "divide and conquer"-атаки («разделяй и властвуй»), когда ключ можно подобрать по половине, что для 128-битного ключа было бы фатально.


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


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


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


Хотя и в Израиле, и в Европе, и в США есть обоснованная критика такой мейнстримной школы, но там хотя бы что-то взамен с претензией на более прогрессивное пытаются предложить.



Построением формальной модели всего протокола в рамках доказуемой безопасности в ROM.



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

— Гость (30/10/2013 08:30)   <#>
Зафлудили с вами весь форум, мешаем людям высказаться, из-за нас никто писать сюда не хочет. ☺


Нам за это деньги платят. ☺


Мы их тут уже 4-ый раз формулируем и обсуждаем. Первое обсуждение, второе, третье. В голове сидят немного другие конструкции, поэтому время от времени забывается, и получается очередное хождение всё по тому же кругу (но радиус круга со временем сокращается, скоро будет сингулярность это радует). В общем, это нормально. Вы же тоже пытаетесь на своём уровне понимания «нае*ть систему», вот и мне приходится, хотя со стороны это может выглядеть полным дилетантством, не спорю.


В общем, да, т.к. в ROM считается, что все составляющие идеальны, а если неидеальны, то примитив надо браковать полностью, а не искать к нему подпорки. Эта мысль в топиках про KeccaK и в топике про то, как обезопасить себя от слежки АНБ, чётко произносилась.


… цельно тянутый из такой области CS как теория (алгоритмической) сложности?


В общем, да, как и всю CS. Правда, читая работы по CS, самого бесит степень неформальности, и я понимаю, почему математики не любят CS. Авторы не утруждаются чётким формулированием своих определений, заключений, всё оговаривается в общем виде в духе «все должны знать, что имеем в виду». Напомнило один недавний случай.*


Мне пришла в голову тривиальная мысль: классическая вычислительно-стойкая криптография — это просто CS, наука под названием «теория сложности». Ну, или её прикладная часть. Гипотетически для любого алгоритма после произнесения всех оговорок можно доказать, какое минимальное число шагов он требует (этим и занимается теория сложности). Это число шагов, определённое для худших сценариев, и было бы оценкой на безопасность криптопримитива. Если разумно считать, что возможности по брутфорсу у человечества никогда не будут бесконечны, это даёт твёрдую формально обоснованную классическую криптографию, которую (в предположении неравенства нужных классов сложности) можно будет считать математикой.

*Я недавно тут накаркал лишнего, после чего прилетел аист машина времени и перебросила pgpru.com на 15 лет вперёд (надеюсь, что до НИСТ дело всё же не дойдёт). В общем, пока я ругался на PC и поминал Голдрайха, мне предложили побыть мудаком по ту сторону баррикад. Работа была достаточно близкой к нашим темам, плюс человека знаю, который попросил, отказываться было неудобно. Насколько представляю расхожие правила по предыдущим конференциям, там три рецензента, и если хоть один поставит не высшую оценку работе, комитет её денониминирует с докладов на постеры. По всему QCS это топ-1 в мире, желающих туда попасть хоть жопой жуй, поэтому с критериями отбора не церемонятся. Короче, моя интуиция мне подсказывает, что работа высший балл не получит несмотря на то, что один из соавторов — безусловный топ, а другой хорошо известен но публикует нереально много слабых работ. Тем временем, вполне возможно, что они сейчас также сидят и судят на принятие мою работу. ☺

В общем, сижу, читаю эту работу, ругаюсь на их нечёткую терминологию, а тут приходит коллега с какого-то засдения и говорит «Прикинь, они считают, что перед внешним жюри (т.е. не имеющем никакого отношения к CS) вообще не надо конкретизировать, где речь идёт о нижней границе, а где о врехней. Типа, это и так понятно, что если речь об алгоритмической теории сложности, то под границей имеется в виду верхняя, а если о коммуникационной сложности, то нижняя» (если не путаю). Ремарка: В оценке коммуникационной сложности надо по постановке задачи найти минимальную из верхних границ (каково минимальное число битов, которые надо передать между хостами, для параллельного решения задачи), а в алгоритмической — оценить, сколько, максимум, нужно операций для решения задачи. По единой логике вроде и та и эта — нижние границы, но нижнюю границу на алгоритмическую сложность можно трактовать и как «этот алгоритм имеет максимум такую-то сложность», поэтому это «верхняя граница». В общем, бред какой-то. А вы тут про энтропию пишете. Да псевдо/вычислительная/настоящая энтропия по сравнению с этим — вообще чёткие ортогональные понятия. ☺

Unknown, а вам доводилось рецензировать работы на предмет их принятия на Crypto конференции?
— unknown (30/10/2013 13:31, исправлен 30/10/2013 15:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


Возможно, вы в этом и ряде других коментов неправильно употребили термин «безопасность через неясность». Вродя и я, и SATtva где-то поправляли «неверное» упоминание термина. В классическом понимании он значит лишь попытку утаить от противника детали алгоритма в нарушении принципа Керхгоффса. А вы часто применяли его в значении, наподобие — «безопасность через недоказанность, преднамеренную запутанность при отсутствии обоснованности», когда алгоритм не скрывают, а делают его как можно более неприятным для анализа за счёт лишних бездоказательных наворотов.


А на конференции CRYPTO-2013 на слайдах упоминается "security by obscurity" именно в вашем понимании. Хотя до этого нигде такого официально не встречалось!



Практически, да.



От таких ответов будет только ФПП переполняться в одном пункте

— Гость (31/10/2013 02:41)   <#>

Впрочем, дословно там написано

оно мне напоминает "безопасность через неясность".

«Напоминает» ≠ «является».


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

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

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


Почему в одном? Если информации будет много, то можно будет разбить на несколько подпунктов для информативности. ☺

Более того, изначально там был не один, а три пункта, по одному на участника, но потом я решил, что аналогичная информация по другим пользователям малоинтересна, да и редко кто спрашивает о них, чтобы стоило специально отдельно куда-то вынести готовый ответ.
— unknown (16/11/2013 23:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Описание метода зануления криптотома упрощено. Нет смысла генерировать случайный одноразовый пароль, а затем затирать заголовок через /dev/urandom. Перед заполнением нулями можно использовать пароль qwerty или подобное, мастер-ключ шифротома всё равно генерируется случайный. Повторная команда luksFormat корректно сотрёт этот ключ, сгенерируется новый ключ, который будет защищён уже стойким паролем. В новом формате LUKS заголовок имеет копию в конце тома, поэтому смысла затирать его через urandom нет. Cryptsetup luksFormat всё должен делать сам наиболее корректным образом в плане стирания ключей.

Так проще и понятнее. Ну или используйте HAVEGE.
— Гость (16/11/2013 23:36)   <#>

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


s/luksFormat/luksKillSlot/, не так ли?
— unknown (17/11/2013 00:52, исправлен 17/11/2013 00:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Для luksKillSlot потребуется вспомнить и ввести пароль, который вводили для зануления. Это лишне, даже если он qwerty.


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


Для параноиков напоминаем, что все ключи хранятся в слотах в хрупком виде, аналоге AONT.

— Гость (17/11/2013 11:53)   <#>

Отсюда не следует, что luksFormat полностью перезаписывает всё то место, которое отведено форматом LUKS под заголовки. Тем не менее, в man cryptsetup пишут

WARNING: Doing a luksFormat on an existing LUKS container will make all data the old container permanently irretrievable, unless you have a header backup.

Эту цитату можно понять не как надёжное затирание, а как почти точное повреждение (нельзя будет восстановить данные обычным образом). Unknown, вы уверены, что вы правильно понимаете то, что делает luksFormat?


Можно хранить в хрупком виде ключи per slot, а можно master key и т.д. Что именно там хранится в хрупком виде и что именно затирается при luksFormat? И зачем команде luksFormat что-то прицельно затирать? Не тот же ли это случай, когда говорят, что форматирование диска уничтожает данные на нём? Про форматирование тоже пишут, что «ваши данные будут утеряны» и ещё предупреждение выдают перед запуском форматирования.


Вместо
# cryptsetup luksOpen /dev/mapper/Group_T /dev/mapper/Group_T_crypt
обычно пишут
# cryptsetup luksOpen /dev/mapper/Group_T Group_T_crypt
Кроме того, команда
# cryptsetup luksClose /dev/mapper/Group_T_crypt
(если мне не изменяет память) вообще ничего не делает, она только возвращает приглашение командной строки. Её можно повторять сколь угодно много раз, и никаких ошибок писаться не будет. Чтобы закрыть LUKS, надо писать
# cryptsetup luksClose Group_T_crypt
В этом случае при повторном выполнении команды она, как и должно, напишет, что нет такого устройства.

Честно говоря, меня эта особенность luksClose немало удивляет. Она нарушает весь дух UNIX (если ошибок не пишется, значит, успешно выполнено, а тут не так).
— unknown (17/11/2013 13:46, исправлен 17/11/2013 13:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Можно попытаться осилить исходники. Можно провести эксперимент.


Собственно только что проверил: создал файл из нулей. И посмотрел, что происходит с его копиями. Отформатил по умолчанию, получилось:



После luksKillSlot — слот с ключом убивается, остаются только объявления криптопараметров алгоритмов, соль и серийный номер тома:



Если вместо luksKillSlot на ту же копию файла натравить luksFormat, то все заголовки со слотами перетираются:



Вернёмся к первому варианту файла, который был отформатирован luksFormat.
Добавим второй слот через luksAddkey:



Попробуем и на нём luksFormat. Все заголовки пересоздаются заново, второй слот затирается, комбинация байтов 0xdead:



Эксперимент, подтверждающий смежный вопрос, можете провести сами :)


Остальное поправил в соответствии с вашим коментарием.

— Гость (02/12/2013 04:19)   <#>

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


А что это за комбинация? Если вы создавали файл из нулей, то почему там постоянно через несколько позиций повторяются dead, 0fa0, 0708, 0608 и т.д.? Вы все эти вставки изначально руками добавили в файл из нулей, чтобы получить «разметку» для отсчёта?
— unknown (02/12/2013 09:36, исправлен 02/12/2013 09:36)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Unknown, вы на этот вопрос так и не ответили, а он всё-таки важный, поскольку связан с вопросом об отрицаемом шифровании и наличии сингатур у LUKS-разделов.

Пока этого нет. Возможно было где-то обсуждение в рассылке, когда появится — посмотрим.


А что это за комбинация? Если вы создавали файл из нулей, то почему там постоянно через несколько позиций повторяются dead, 0fa0, 0708, 0608 и т.д.? Вы все эти вставки изначально руками добавили в файл из нулей, чтобы получить «разметку» для отсчёта?

LUKS сам создаёт такую структуру: сначала основной заголовок, после которого идут поля для восьми слотов. Они нумеруются в конце поля как {00080708} — 0000 0fa0. Пустой слот отмечается в начале поля как 0000 dead.

— Ankor (06/04/2014 23:31)   профиль/связь   <#>
комментариев: 8   документов: 0   редакций: 0
Хотя режим XTS способен работать с любыми шифрами, у которых размер блока равен 128 бит (напр. Serpent или Twofish), при реализации он корректно проверяется только с шифром AES. Так, при выборе другого шифра возникнет предупреждение, что для данной конфигурации отсутствуют проверенные тестовые векторы, следовательно процедура проверки корректности шифрования выполнена не будет. Также это может вызвать проблемы в будущем, если программная реализация будет изменена, а поддержка расшифровки данных, зашифрованных в XTS не для AES не будет реализована или окажется несовместимой.

В последних версиях ядра есть тестовые векторы и для других шифров, никаких предупреждений я не замечал.
При компиляции cryptsetup make check проверяет AES, Twofish и Serpent в т. ч. в режимах XTS-plain, plain64, benbi и essiv:sha256. Так что, по-моему, предупреждение устарело.

Есть ли какой-то смысл в xts-essiv?

Можно провести эксперимент.
Собственно только что проверил: создал файл из нулей. И посмотрел, что происходит с его копиями.

Стоит заметить, что приведенные восемь слотов — только для служебной информации о паролях (число итераций, соль...), а ключевой материал хранится дальше, в "растянутом" виде и в эти дампы он не вошел (ключ по ним не восстановить).
— Гость (07/04/2014 03:49)   <#>

Он затирается при luksFormat и luksKillSlot?
— Ankor (07/04/2014 09:06, исправлен 07/04/2014 09:07)   профиль/связь   <#>
комментариев: 8   документов: 0   редакций: 0
Он затирается при luksFormat и luksKillSlot?

Да, для этого и есть luksKillSlot. Как надежно — не знаю, есть подозрение, что при luksFormat новый материал просто пишется поверх без многократной перезаписи, но, учитывая AF-split, вполне возможно, что этого вполне достаточно — вряд ли получится восстановить сотню килобайт без ошибок.
luksKillSlot затирает по Гутману, это уж наверняка.

— unknown (07/04/2014 10:18)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
При компиляции cryptsetup make check проверяет AES, Twofish и Serpent в т. ч. в режимах XTS-plain, plain64, benbi и essiv:sha256. Так что, по-моему, предупреждение устарело.

На старом Debian, соответствующем дистрибутивном ядре и утилитах тоже всё работало — (рас)/шифровалось, но в dmesg или в syslog при попытке операций с luks выдавались предупреждения об отсутствии тестовых векторов. Ещё раз проверю, пофиксили ли это в стабильной ветке Debian и если даже там всё стабильно, то исправлю FAQ.


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


Какая-то перестраховка — гибрид из двух режимов. По опыту давнего использования CryptoAPI — туда иногда пихают не совсем понятную экзотику, а затем внезапно прекращают её поддержку.

Даже потому, что правдоподобно ответили здесь и здесь, XTS-ESSIV — это от незнания матчасти, он не нужен. Или когда не могли воткнуть 64-битный счётчик, пытались так выкрутиться по шифрпанковски. Для XTS нужен простой счётчик блоков, увеличение его размера до 64-бит — адекватно и достаточно. Если бы он оказался уязвимым, пришлось бы создавать другой режим, а не городить поверх него припарки.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3