Author Topic: Стойкость DiskCryptor  (Read 2850 times)

Dmitriy

  • Newbie
  • *
  • Posts: 6
Стойкость DiskCryptor
« on: October 08, 2008, 10:47:51 pm »
Как я понял пользовательский пароль используется только для шифрования заголовка тома с помощью AES-256. Ключ же шифрования пользовательских данных тома генерируется "ГСЧ для генерации ключей" схема которого приведена в документации.

Нас интересуют именно пользовательские данне.
Стойкость системы определяется стойкостью самого слабого звена. Атака на AES возможна только полным перебором ключей. Это НЕСОПОСТАВИМО с перебором входных значений ГСЧ.

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

"Каждый может создать криптографическое средство, которое он сам не сможет взломать. Это означает, что появляется некто с благими намерениями и с новыми идеями, или по меньшей мере с идеями, о которых он никогда раньше не слышал. Он не может взломать свою систему и уверен, что он только что открыл магический эликсир, которым можно вылечить все проблемы защиты. И даже если все понимают, что магического эликсира не существует, сложность создания по‑настоящему защищенных средств вместе с легкостью внесения ошибок делают плохие криптографические средства правилом, а не исключением." - Брюс Шнайер.

На мой взгляд ключ для пользовательских данных должен быть сгенерирован на основе пароля с помощью признанных алгоритмов. Добавте хотя бы опциональную возможность задания этого ключа вручную.
« Last Edit: October 08, 2008, 10:56:33 pm by Dmitriy »

ntldr

  • Administrator
  • Hero Member
  • *****
  • Posts: 1079
Re: Стойкость DiskCryptor
« Reply #1 on: October 09, 2008, 12:47:38 am »
Quote
Стойкость системы определяется стойкостью самого слабого звена. Атака на AES возможна только полным перебором ключей. Это НЕСОПОСТАВИМО с перебором входных значений ГСЧ.
Блочные шифры в этой схеме самое слабое звено. ГСЧ сделан с большим запасом для того, чтобы полностью исключить атаки с этой стороны даже в случае компрометации большинства источников входных значений.
Одним из входных значений ГСЧ является клавиатурный ввод пользователя, следовательно перебор входных значений ГСЧ заведомо труднее, чем перебор пароля.

Quote
Ваша реализация ГСЧ выдает "истинно случайную последовательность размером до 640 байт" на компьютере изначально спроектированным в терминах детерминированности.
Современный ПК весьма далек от детерминированности. Он просто битком набит устройствами имеющими недетерминированное поведение. Простейший пример: биения частоты системного таймера относительно тактовой частоты процессора приводят к недетерминированности возврата команды rdtsc. Прерывания от других устройств вносят в эту картину еще больше хаоса.

Quote
Даже если эта псевдослучайная последовательность удовлетворяет критериям надежности должно пройти несколько лет для понимания и оценки этого метода, прежде, чем создавать продукты, на нем основанные.
Стойкость ГСЧ полностью основана на стойкости применяемых в нем алгоритмов, а его схема создана по рекомендациям в приведенных в статье ссылках. Приведу несколько тезисов, справедливость которых совершенно очевидна из схемы ГСЧ:
1 - атаки на предсказание как последующих, так и предыдущих выходов гсч однозначно требует обращения функции aes(sha512(x)), так как именно она генерирует финальный вывод.
2 - статистические свойства генерируемой последовательности будут по крайней мере не хуже статистических свойств лучшего из алгоритмов (aes, sha512).
3 - равномерное извлечение энтропии из входных значений гарантируется статистическими свойствами sha512.
Если можете опровергнуть что-либо из этого, то милости просим :)

Quote
"Каждый может создать криптографическое средство, которое он сам не сможет взломать. Это означает, что появляется некто с благими намерениями и с новыми идеями, или по меньшей мере с идеями, о которых он никогда раньше не слышал. Он не может взломать свою систему и уверен, что он только что открыл магический эликсир, которым можно вылечить все проблемы защиты. И даже если все понимают, что магического эликсира не существует, сложность создания по‑настоящему защищенных средств вместе с легкостью внесения ошибок делают плохие криптографические средства правилом, а не исключением." - Брюс Шнайер.
Это было сказано в первую очередь насчет изобретения собственных криптопримитивов. Здесь я согласен с тем, что должны пройти годы, прежде чем можно будет верить в их стойкость. Однако пользуясь готовыми стойкими примитивами и соблюдая правила их безопасного применения можно конструировать криптографические средства, взлом которых сводиться к взлому этих примитивов.


Quote
На мой взгляд ключ для пользовательских данных должен быть сгенерирован на основе пароля с помощью признанных алгоритмов.
Детерминированная генерация ключа на основе пароля делает невозможной смену пароля без полного перешифрования данных. Поэтому во всех системах дискового шифрования принято шифровать пользовательским паролем только ключ для данных.
« Last Edit: October 09, 2008, 12:51:38 am by ntldr »

Dmitriy

  • Newbie
  • *
  • Posts: 6
Re: Стойкость DiskCryptor
« Reply #2 on: October 09, 2008, 01:54:30 am »
Мне нравится DiskCryptor и я с уважением отношусь к большому объему проделанной Вами работы.

Согласен со всеми тремя пунктами относительно ГСЧ. Как мне кажется слабость ГСЧ именно в переборе входных значений. Перебор входных значений ГСЧ на свежеустановленной системе не миллионы лет. Будем исходить из того, что AES признан и проверен временем, в то время как реализация ГСЧ такой проверки не прошла. Это не значит, что она плоха. Но все же сомнительное звено.

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

"Выбор собственного ГСЧ так же опасен, как и выбор собственного криптоалгоритма. В случае малого периода (когда псевдослучайных значений, вырабатываемых датчиком, меньше, чем возможных значений ключа) злоумышленник может сократить время поиска ключа, перебирая не сами ключи, а псевдослучайные значения и генерируя из них ключи. При плохом разбросе датчика злоумышленник также может уменьшить среднее время поиска, если начнет перебор с самых вероятных значений псевдослучайных чисел. Самой распространенной ошибкой, проявляющейся и в случае хорошего ГСЧ, является его неправильная инициализация. В этом случае число, используемое для инициализации, имеет либо меньшее число бит информации, чем сам датчик, либо вычисляется из неслучайных чисел и может быть предсказано стой или иной степенью вероятности." - http://www.password-crackers.ru/articles/15/

Во всяком случае, опциональная возможность задания ключа вручную была бы отличным решением :)
« Last Edit: October 09, 2008, 02:02:57 am by Dmitriy »

ntldr

  • Administrator
  • Hero Member
  • *****
  • Posts: 1079
Re: Стойкость DiskCryptor
« Reply #3 on: October 09, 2008, 03:38:14 am »
Quote
Будем исходить из того, что AES признан и проверен временем, в то время как реализация ГСЧ такой проверки не прошла. Это не значит, что она плоха. Но все же сомнительное звено.
Для сомневающихся в следующей версии добавлю возможность задать ключ вручную.

Quote
Но время набора входных значений поле запуска программы не лимитировано. Пользователь может установить драйвер и сразу же зашифровать диск. За это время входная энтропия не велика.
Она как минимум равна энтропии вводимого пароля. И ещё очень много энтропии собирается в момент загрузки системы. Никто и никаким чудом не сможет угадать время выполнения тысячи запросов ввода/вывода с точностью до одного такта процессора. Это величина недетерминированная.

Quote
В случае малого периода (когда псевдослучайных значений, вырабатываемых датчиком, меньше, чем возможных значений ключа) злоумышленник может сократить время поиска ключа, перебирая не сами ключи, а псевдослучайные значения и генерируя из них ключи
Даже если предположить, что мы контролируем источники энтропии во время генерации ключа, что дает нам полностью детерминированный вывод, то период ГСЧ не может быть меньше 2^512, это обеспечивается свойствами sha512. Но при нормальной работе этого ГСЧ, в его пул постоянно добавляются истинно случайные числа, и период ограничен только размером пула (в данном случае 2^5120).

Quote
Самой распространенной ошибкой, проявляющейся и в случае хорошего ГСЧ, является его неправильная инициализация. В этом случае число, используемое для инициализации, имеет либо меньшее число бит информации, чем сам датчик, либо вычисляется из неслучайных чисел и может быть предсказано стой или иной степенью вероятности." - http://www.password-crackers.ru/articles/15/
Я всё это прекрасно знаю, самому приходилось ломать криптографию со слабой реализацией ГСЧ. Подобные ошибки бывают только из за полного невежества в вопросах криптографии. Например чаще всего встречается использование однократно взятой метки времени (период 2^32), либо использование стандартных ГСЧ языка программирования.
Это всё детские ошибки. Их допускают не только в ГСЧ. Очень часто встречается шифрование нескольких потоков данных на одном ключе в режимах cfb, ofb и ctr, большие блоки данных часто шифруют в режиме ecb, при разворачивании пароля не используют salt. Такие ошибки нужно просто не делать, потому что это позор для разработчика.

Dmitriy

  • Newbie
  • *
  • Posts: 6
Re: Стойкость DiskCryptor
« Reply #4 on: October 09, 2008, 10:10:56 am »
Спасибо :)