Российская криптография: так ли всё грустно?

© 2000-2015 КРИПТО-ПРО
Российская криптография: так ли всё грустно?
Смышляев Станислав Витальевич, к.ф.-м.н.,
начальник отдела защиты информации
Алексеев Евгений Константинович, к.ф.-м.н.,
ведущий инженер-аналитик
Агафьин Сергей Сергеевич,
инженер-программист
Смышляев, Алексеев, Агафьин () 1 / 128

Расхожее мнение о российской криптографии
Морально устаревшие решения.
Проблемы с быстродействием.
Проблемы со стойкостью.
Ориентированность на
”
бумажную“ безопасность и
соответствие требованиям, а не на реальную защищенность.
Следствие 1: Нередка позиция
”
когда требуется показать
сертификат ФСБ, используем ГОСТ, а в иных случаях
переключаемся на RSA/AES“.

Следствие 2: Критика российских решений зачастую не
конструктивна, а шаблонна, полна клише.
Многие
”
и так знают“, что все плохо — всякая критика охотно
подхватывается аудиторией без апробации и верификации.
У специалистов по практической безопасности — меньше выбор
доступных криптографических механизмов, продуктов для
встраивания.
У российских криптографов — априорно пыльноватая
репутация.
У разработчиков и интеграторов российских криптосредств —
меньше конструктивной критики, информации о реальных
уязвимостях.

Российские криптографические алгоритмы
1 Российские криптоалгоритмы: стандарты, мифы, перспективы
Стойкость алгоритмов ГОСТ
Производительность алгоритмов ГОСТ
2 Криптография на ГОСТ и реальная защищенность
Безопасность
”
бумажная“ и реальная
Уязвимости при небезопасном выборе IV в CBC, CFB
Уязвимости при небезопасном использовании паддинга
Уязвимости при перекрытии гаммы
Уязвимости при превышении нагрузки на ключ
Выбор алгоритма хэширования
Рекомендации по стандартизации ТК 26
3 Практическое использование
Решаемые задачи
Ключевые носители
Генераторы случайных чисел
Встраивание отечественной криптографии

Российские криптографические алгоритмы Стойкость алгоритмов ГОСТ
”

Стойкость ГОСТ 28147-89 (блоковый шифр)
ГОСТ 28147-89, атаки Куртуа
Октябрь 2010 года: начат процесс рассмотрения включения
ГОСТ 28147-89 в международный стандарт ISO/IEC 18033-3.
В мае 2011 года на ePrint статья Николя Куртуа:
использование алгебраических методов и дифференциальных
(работа от мая 2011 и последующие 5 работ).
По алгебраическим: нет детального описания и анализа
трудоемкости второго и главного этапа определения ключа,
есть только экспериментальные данные на аналогах меньшей
размерности (не верифицируемые).
По дифференциальным: анализ для узлов замены, отличных от
действующих и от предложенных в ISO.
Рудской, Дмух (см. ePrint): даже если принять необоснованные
”
факты“ Куртуа и провести анализ ГОСТ 28147-89 с другими
узлами замены, то атака не лучше полного перебора.

ГОСТ 28147-89, атаки Исобе и Динура–Данкельмана–Шамира
Корректные, математически строгие описания атак.
Показано, что некоторые свойства алгоритма ГОСТ 28147-89
позволяют находить пути анализа, не учтенные создателями
алгоритма.
Трудоемкость атаки Исобе составляет 2224 операций
зашифрования, атаки ДДШ — 2192.
Для метода Исобе требуется 232 пар открытых и шифрованных
текстов, для метода ДДШ — 264.
При материале 232 уже с вероятностью ≈ 0.5 появляются
повторяющиеся блоки шифртекста, при 264 ключ вовсе более не
нужен (есть полная таблица зашифрования).
Не произошло снижения даже теоретической стойкости.

Стойкость ГОСТ Р 34.11-94 (функция хэширования)
ГОСТ Р 34.11-94, атаки Менделя-Прамшталлера-Рехбергера
Нахождение коллизии: 2105 вместо априорных 2128.
Нахождение (второго) прообраза: 2192 вместо априорных 2256.
Корректные, математически строгие описания атак.

Переход на ГОСТ Р 34.11-2012 и ГОСТ Р 34.10-2012
2012 год: стандарт функции хэширования ГОСТ Р 34.11-2012
(
”
Стрибог“).
Документ ФСБ России № 149/7/1/3-58 от 31.01.2014.
ТЗ после 31 декабря 2012 года — должна быть реализация
ГОСТ Р 34.10-2012 (и ГОСТ Р 34.11-2012).
Использование ГОСТ Р 34.11-94 для использования при
формировании подписи после 31 декабря 2018 года не
допускается.

Стойкость ГОСТ Р 34.11-2012 (функция хэширования)
AlTawy R., Youssef A. M. – Preimage Attacks on reduced-round
Stribog.
AlTawy R., Kircanski A., Youssef A. M. – Rebound attacks on
Stribog.
Kazymyrov O., Kazymyrova V. – Algebraic aspects of the russian
hash standard GOST R 34.11-2012.
Ma B., Li B., Hao R., Li X. – Improved cryptanalysis of
reduced-round GOST and Whirlpool hash function.
Zou J., Wu W., Wu S. – Cryptanalysis of the round-reduced
GOST hash function.
AlTawy R., Youssef A. M. – Integral distinguishers for
reduced-round. Stribog.
AlTawy R., Youssef, A. M. – Watch your Constants: Malicious
Streebog.

Стойкость ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012
(электронная подпись)
С точки зрения структуры (и стойкости) ГОСТ Р 34.10-2001 и
ГОСТ Р 34.10-2012 предельно близки к ECDSA: стойкость
определяется:
выбором эллиптических кривых;
гарантией случайности одноразовых случайных величин в
процессе подписи (вспомним уязвимость 2010 года в Sony
PlayStation 3 из-за проблем в реализации ECDSA).

Российские криптографические алгоритмы Производительность алгоритмов ГОСТ
”

Производительность ГОСТ 28147-89 (блоковый шифр)
Шифрование: ГОСТ 28147-89, режим гаммирования
без SSE/AVX: 28 тактов/байт (120 МБ/с/ядро 3.3 GHz);
с AVX: 8.7 тактов/байт (390 МБ/с/ядро 3.3 GHz).

без SSE/AVX: 28 тактов/байт (120 МБ/с/ядро 3.3 GHz);
с AVX: 8.7 тактов/байт (390 МБ/с/ядро 3.3 GHz).

Реализация на GPU (OpenCL): 1300 МБ/с (AMD Radeon HD
6970).

Производительность ГОСТ Р 34.11 (хэш-функции)
Хэширование: ГОСТ Р 34.11-94 и ГОСТ Р 34.11-2012
ГОСТ Р 34.11-94: 40 тактов/байт (85 МБ/с/ядро 3.3 GHz);
ГОСТ Р 34.11-2012: 30 тактов/байт (110 МБ/с/ядро 3.3 GHz).

Производительность ГОСТ Р 34.10-2001 и ГОСТ Р
34.10-2012
С точки зрения совокупности математических операций (и,
следовательно, производительности) ГОСТ Р 34.10-2001 и ГОСТ Р
34.10-2012 предельно близки к ECDSA: производительность
определяется выбором используемых полей, эллиптических кривых
(параметров алгоритма подписи), а также проработкой реализаций
операций в конечных полях и эллиптических кривых в реализациях.
Сравнение с RSA
Сравнимая стойкость ГОСТ Р 34.10-2001/2012-256 (по NIST SP
800-57): RSA-3072.
Сравнимая стойкость ГОСТ Р 34.10-2012-512 (по NIST SP
800-57): между RSA-7680 и RSA-15360.

34.10-2012 (проверка подписи)
Проверка ЭП: ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012
ГОСТ Р 34.10-2001/2012-256: 9700 проверок в секунду;
ГОСТ Р 34.10-2012-512: 1850 проверок в секунду.

34.10-2012 (формирование подписи)
Формирование ЭП: ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012
ГОСТ Р 34.10-2001/2012-256: 15800 формирований в секунду;
ГОСТ Р 34.10-2012-512: 3400 формирований в секунду.

34.10-2012
Криптосистема с открытым ключом
В России нет стандарта для криптосистем с открытым ключом.
Решение задачи
”
зашифровать данные с использованием открытого
ключа PubKA“ (зафиксировано в Рекомендациях по
стандартизации ТК 26):
породить эфемерный ключ β (с открытым ключом PubKβ),
случайную величину UKM;
вычислить SK = H(UKM · β · PubKA);
зашифровать вход (как правило, ключ шифрования основных
данных) на SK, передать шифртекст вместе с PubKβ и UKM.
Время шифрования/расшифрования ≈ время проверки подписи.

Криптография на ГОСТ и реальная защищенность
”

Криптография на ГОСТ и реальная защищенность Безопасность
”
”

”
”
Требования ФСБ России к шифровальным
(криптографическим) средствам.
Требования к средствам электронной подписи.
Приказ ФСБ России N 378
”
Об утверждении . . . мер по
обеспечению безопасности персональных данных при их
обработке в информационных системах персональных данных с
использованием СКЗИ . . .“
Требования к средствам удостоверяющего центра.

”
”
Критика
Формальные модели нарушителя, не имеющие отношения к
реальности.
Проверяется безопасность к
”
бумажным“ моделям, а не к
реальным нарушителям.
При возникновении проблем безопасности разработчики дают
ответы
”
в такой-то формальной модели все хорошо“.
Из-за закрытости требований возникает (справедливо)
ощущение непрозрачности при анализе защищенности.

”
”
КС1:
”
проведение атаки, находясь вне контролируемой зоны“
КС2:
”
проведение атаки при нахождении в пределах
контролируемой зоны“

”
”
КС1:
”
проведение атаки, находясь вне контролируемой зоны“
— атаки на криптографические протоколы через сеть
КС2:
”
проведение атаки при нахождении в пределах
контролируемой зоны“ — нарушитель в непосредственной
близости, анализ секторов диска после удаления данных

”
”
КС3:
”
возможность располагать аппаратными компонентами
СКЗИ и СФ, ограниченная мерами, реализованными в
информационной системе, в которой используется СКЗИ, и
направленными на предотвращение и пресечение
несанкционированных действий“
KB:
”
создание способов, подготовка и проведение атак с
привлечением специалистов в области анализа сигналов,
сопровождающих функционирование СКЗИ и СФ, и в области
использования для реализации атак недокументированных
(недекларированных) возможностей прикладного ПО“

”
”
КС3:
”
возможность располагать аппаратными компонентами
СКЗИ и СФ, ограниченная мерами, реализованными в
информационной системе, в которой используется СКЗИ, и
направленными на предотвращение и пресечение
несанкционированных действий“ — возможность атак при
доступе к системе из-под другого аккаунта
KB:
”
создание способов, подготовка и проведение атак с
привлечением специалистов в области анализа сигналов,
сопровождающих функционирование СКЗИ и СФ, и в области
использования для реализации атак недокументированных
(недекларированных) возможностей прикладного ПО“
— возможность атак по побочным каналам

”
”
Пример: ключевой носитель
Пассивный носитель.
Активный автономный вычислитель.
Функциональный ключевой носитель.

”
”
Пассивный носитель
Использование ключа основным криптосредством: вычисления
в оперативной памяти машины.

”
”
Активный автономный вычислитель
Все вычисления на самом устройстве, ключ в память не
попадает.

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

”
”
Доступ нарушителя к пользовательскому процессу в системе в
любом случае (даже в случае HSM) означает компрометацию
доступа к ключу.
Защищенность пассивного и автономного носителей
Доступ нарушителя к каналу от системы к носителю означает
неминуемую компрометацию доступа к ключу.
В случае пассивного носителя нарушитель потенциально
извлекает из памяти ключ.
В случае автономного вычислителя нарушитель потенциально
перехватывает пароль и возможность подписи произвольных
данных.
В случае автономного вычислителя несоизмеримо опаснее
атаки по побочным каналам (потребление, время).
Уровень защищенности (без дополнительных орг. мер) — КС1.

”
Функциональный ключевой носитель

”
”
Функциональный ключевой носитель
На аутентифицированном на пароле ключе согласования
устанавливается защищенный канал связи между системой и
носителем.
Все дальнейшие пересылки между носителем производятся
посредством защищенного канала.
За счет распределения вычислений возможно уменьшение
опасности атак по побочным каналам.
Сам пароль также защищен от оффлайного перебора пароля с
опробованием по полученным в канале данным (после действий
нарушителя в канале).
Оценочный уровень защищенности — КС3.

”
”
Анализируемые проблемы
Уязвимости в базовых криптографических алгоритмах.
Уязвимости в сопутствующих криптографических алгоритмах.
Уязвимости в криптографических протоколах.
Уязвимости при встраивании криптографических протоколов.
Ошибки в реализации.
Отсутствие в реализации достаточных мер противодействия
предполагаемому нарушителю.

”
”
Анализируемые проблемы
Уязвимости в базовых криптографических алгоритмах.
Уязвимости в сопутствующих криптографических алгоритмах.
Уязвимости в криптографических протоколах.
2010:
«Ха-ха, теоретические проблемы стойкости протоколов не влияют
на реальную защищенность»
2015:
TLS: BEAST, POODLE, Lucky13...

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

Криптография на ГОСТ и реальная защищенность Выбор IV в CBC, CFB
”

Режимы CBC, CFB: уязвимости при небезопасном
выборе синхропосылок
Ошибку в проектировании системы защиты информации,
связанную с непродуманным механизмом выбора синхропосылок,
могут совершить даже опытные криптографы. Ярким примером
такого рода ошибки стала особенность протокола TLS 1.0, в
котором при использовании блоковых шифров в режиме CBC в
качестве синхропосылки очередного пакета выбирается последний
блок шифртекста предыдущего пакета.
Для эксплуатации данной уязвимости Дуонгом и Риззо в 2011 году
был создан модуль BEAST, позволявший дешифровывать
передаваемые cookie-файлы пользователя.
Описание теоретической уязвимости было предложено еще за 7 лет
до этого в работе Грегори Барда.

При работе блокового шифра в режиме CBC фиксируется
синхропосылка C0 = IV, для получения каждого блока Ci
шифртекста вычисляется значение Ci = EK(Mi ⊕ Ci−1), где EK —
функция зашифрования блока текста на ключе K.
Атака с выбором ОТ при известном IV.
Проверяется, что для полученного ранее шифртекста
C = (C1|C2| . . . |Cm) блок Mi ОТ M = (M1|M2| . . . |Mm) равен M∗.
Таким образом, перебирая различные значения M∗, нарушитель
может узнать содержимое блока ОТ.

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

Криптография на ГОСТ и реальная защищенность Использование паддинга
”

Пример
Паддинг PKCS #5: сообщение дополняется ненулевым числом
байтовых констант PADLEN до конца блока, где PADLEN — число
требуемых байт паддинга.
Например, при длине блока 8 байт сообщение (0x0A, 0x0B, 0x0C)
будет дополнено до (0x0A, 0x0B, 0x0C, 0x05, 0x05, 0x05, 0x05, 0x05).
При непродуманном выборе процедуры проверки паддинга
возможно появление уязвимостей к атакам с выбором ШТ.

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

POODLE attack: Padding Oracle On Downgraded Legacy Encryption.
Смена ключа после каждой ошибки на приеме не полностью
устраняет проблему — соответствующая уязвимость в протоколе
TLS версии 1.0 для использующих CBC наборов шифрования
описана в 2001 году в работе Сержа Воденея.
Заметим, что данная уязвимость в TLS с российскими
алгоритмами, утвержденном ТК 26, отсутствует, так как в данной
версии используется режим гаммирования, паддинг вовсе не
используется.

Криптография на ГОСТ и реальная защищенность Уязвимости при перекрытии гаммы
”

Для стойкой криптосистемы (формально — IND-CPA–стойкой)
в режиме гаммирования наличие у противника шифртекста
при отсутствии ключа вовсе не уменьшает для него
неопределенности открытого текста.
В случае переиспользования гаммы неопределенность падает
до значений, позволяющих провести практическую атаку.
Элементарный пример
Пусть биты a, b независимы Pr(a = 1) = Pr(b = 1) = 0.6. Тогда
неопределенность (энтропия) при наличии битов шифртекста
ca = a ⊕ ka и cb = b ⊕ kb составляет 1.942 бита.
Если же ka = kb, энтропия падает в среднем до 0.945 бит —
такой же она была бы, если бы каждый бит принимал бы
некоторое значение с вероятностью ≈ 90%.

Известный пример: режимы ECB и гаммирования

Пример: режим гаммирования при перекрытии гаммы

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

Криптография на ГОСТ и реальная защищенность Уязвимости при превышении нагрузки на ключ
”

При шифровании без смены ключа текста длиннее допустимых
значений могут становиться практически осуществимыми атаки по
побочным каналам (напряжение, акустика, радиоволны и пр.).
При существенном превышении допустимых значений всякий
алгоритм шифрования теряет положительные криптографические
качества.
При шифровании ГОСТ 28147-89 более 32 ГБ информации
вероятность совпадения выходных блоков алгоритма
шифрования достигает 50%.

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

Организация работы с сессионными ключами
Решение
При шифровании использовать режим преобразования ключа
(реализуется в криптосредстве, прозрачно для приложений):
RFC 4357: 2.3.2: Key Meshing.
Но: сохраняется ограничение на количество шифруемых сообщений
на одном ключе (T · 1024 сообщений произвольной длины).
Без преобразования ключей: шифровать не более T МБ на
одном ключе.
С преобразованием ключей: шифровать не более T · 1024
независимых сообщений на одном ключе.

Необходимо проектировать процедуры работы с сессионными
ключами по принципу использования каждого ключа для весьма
небольшого числа сообщений.
Недопустимое решение
for(QWORD i = 0; i < qwTotalDataBlocks; i++)
{
CryptDuplicateKey(hKey, 0, 0, &hTmpKey);
CryptEncrypt(hTmpKey, 0, TRUE, 0, ppbData[i], &(pdwLen[i]), pdwBufLen[i]);
CryptDestroyKey(hTmpKey);
}

Вариант решения: IPsec ESP
”
Техническая спецификация по использованию ГОСТ 28147-89 при
шифровании вложений в протоколе IPsec ESP“, раздел 5.6.
Преобразование ESP_GOST-4M-IMIT.
RootKey
Divers( RootKey , i&Mask1)
Divers( Divers( RootKey , i&Mask1) , i&Mask2)
Key[i] = Divers( Divers( Divers( RootKey , i&Mask1) , i&Mask2) , i&Mask3)
Mask1 = 0xffffffff00000000, Mask2 = 0xffffffffffff0000, Mask3 = 0xffffffffffffffc0.

Алгоритмы диверсификации
CALG_PRO_DIVERS: RFC 4357, раздел 7.
Алгоритм Secret Key Diversiﬁcation;
CALG_PRO12_DIVERS: ТК 26,
”
Рекомендации по
стандартизации. Использование криптографических
алгоритмов...“. Алгоритм KDF_TREE_GOSTR3411_2012_256.

Криптография на ГОСТ и реальная защищенность Выбор алгоритма хэширования
”

Уязвимости при использовании стойкого алгоритма
подписи со слабым алгоритмом хэширования
Не запрещено использовать MD5 + RSA или даже MD5 + ГОСТ Р
34.10-2001 как усиленную неквалифицированную подпись.
Миф: даже поломанные с точки зрения теории хэш-функции
можно использовать с ЭП
Частично правда: если подписать MD5-хэш документа,
подделать подписанный документ на практике невозможно
(стойкость MD5 к нахождению прообраза/второго прообраза
снижена с 2128 только на 5 порядков).
При ошибке проектирования систем документооборота с
использованием такой подписи уязвимость становится
эксплуатируемой на практике.

Рассмотрим систему, в которой документы подписываются
следующим образом
Signature(Key, Src) = SignRSA−2048 (Key, hSHA3 (hMD5(Src)|Attrs))
Аналогичная процедура формирования подписи (с вариабельностью
алгоритмов) используется в Microsoft Authenticode.

Подписывающая сторона
Интересы честной подписывающей стороны удовлетворены:
модифицировать документ, снабдив его поддельной подписью,
текущее состояние криптоанализа не позволяет (слабое звено —
второй прообраз для хэш-значения MD5 — 2123, около десяти
миллиардов лет работы миллиардов 3ГГц–процессорных ядер).

Проверяющая сторона
Ввод в заблуждение: стойкий алгоритм подписи RSA-2048
используется в паре со стойкой хэш-функцией SHA3.
Но: вычисление основного хэша документа производит
быстрая, но обладающая практическими уязвимостями MD5
(коллизии строятся за 224 — одна-две секунды).
Для ряда форматов существуют практически осуществимые
атаки с созданием пары документов (pdf, djvu, исполняемых
файлов) с различным (осмысленным, запланированным
нарушителем) содержанием, но одним значением хэша MD5, а
следовательно, и значением Signature(K, Src).

Усиленная квалифицированная электронная подпись может быть
сформирована только с помощью:
ГОСТ Р 34.11-94 + ГОСТ Р 34.10-2001.
ГОСТ Р 34.11-2012 (256 бит) + ГОСТ Р 34.10-2012 (256 бит).
ГОСТ Р 34.11-2012 (512 бит) + ГОСТ Р 34.10-2012 (512 бит).
В стандартах электронной подписи явным образом прописан
алгоритм хэширования, с которым можно использовать подпись.
Известные уязвимости существуют только у ГОСТ Р 34.11-94,
однако носят сугубо теоретический характер: построение
коллизии за 2105 — миллион лет работы миллиарда 3-ГГц
процессорных ядер (против секунды на одном ядре для MD5).
Известных уязвимостей у ГОСТ Р 34.11-2012, ГОСТ Р
34.10-2001, ГОСТ Р 34.10-2012 нет.

Криптография на ГОСТ и реальная защищенность Рекомендации по стандартизации ТК 26
”

Технический комитет по стандартизации
”
Криптографическая защита информации“
Росстандарта (ТК 26)
Производительность и стойкость ГОСТ Р 34.10-2001 и ГОСТ Р
34.10-2012 определяется, в частности, выбором параметров
эллиптических кривых.
"Рекомендации по стандартизации. Задание параметров
эллиптических кривых в соответствии с ГОСТ Р 34.10-2012".

”
Доверие к выбору параметров: принцип
”
проверяемой случайности“.
Выработка параметров с помощью односторонней функции.
На практике, с помощью некоторого
”
трудно“ обратимого
преобразования: на основе хэш-функции ГОСТ Р 34.11-2012.
На вход данного преобразования — случайные строки.
Разные алгебраические структуры — даже специальный подбор
входных строк не позволяет осуществлять выбор
окончательных параметров для принадлежности классу
заведомо "слабых".

”
Стойкость ГОСТ 28147-89 определяется, в частности, выбором
узлов замены.
"Рекомендации по стандартизации. Задание узлов замены блока
подстановки алгоритма шифрования ГОСТ 28147-89".

”
Для использования в протоколах описанных в стандартах
алгоритмов необходимы происследованные безопасные конструкции
на их основе.
"Рекомендации по стандартизации. Использование
криптографических алгоритмов, сопутствующих применению
стандартов ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012".

”
Для работы российских криптоалгоритмов в протоколах
необходимы происследованные безопасные процедуры работы.
"Техническая спецификация по использованию ГОСТ 28147-89,
ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2001 при согласовании
ключей в протоколах IKE и ISAKMP".
"Техническая спецификация по использованию ГОСТ 28147-89
при шифровании вложений в протоколе IPsec ESP".
"Техническая спецификация по использованию ГОСТ Р
34.11-94 при обеспечении целостности в протоколах IPsec AH и
ESP".

”
"Техническая спецификация использования алгоритмов ГОСТ
Р 34.10, ГОСТ Р 34.11 в профиле сертификата и списке отзыва
сертификатов (CRL) инфраструктуры открытых ключей
X.509".
"Рекомендации по стандартизации. Использование алгоритмов
ГОСТ 28147-89, ГОСТ Р 34.11 и ГОСТ Р 34.10 в
криптографических сообщениях формата CMS".
"Рекомендации по стандартизации. Использованию наборов
алгоритмов шифрования на основе ГОСТ 28147-89 для
протокола безопасности транспортного уровня (TLS)".

Практическое использование
”

Практическое использование Решаемые задачи
”

Практическое использование Решаемые задачи
Решаемые нетривиальные задачи при реализации
Диспетчеризация смарт-карт
Минимизация обращений к устройствам.
Кэширование: паролей и контекстов.
Синхронизация: отдельные блокировки для каждой ОС.
Защита криптографических ключей
Если ключ окажется в памяти в открытом виде, обязательно
найдется уязвимость, через которую его можно достать (см.
HeartBleed). Иногда достаточно даже простого аппаратного сбоя.
Хранение ключей под маскирующим преобразованием: как на
смарт-картах, так и в ОЗУ.
Выполнение операций над преобразованными данными.
Нормализация времени выполнения операций для исключения
атак по энергопотреблению.

Практическое использование Ключевые носители
”

Хранение криптографических ключей
Подходы к хранению ключей
Флешки / файлы / реестр.
Пассивные ключевые носители.
Активные ключевые носители.
Ключевые носители с протоколами нового поколения.

Пассивные токены

Активные токены

Биометрические токены
Использование вносит третий фактор аутентификации: наличие
самого пользователя.
Плюсы:
Защита даже при компрометации ПИН-кода.
Потенциальная возможность встраивания в существующие
системы.
Минусы:
Усложнение архитектур пользовательских приложений.
Повышение сложности программного обеспечения токенов.

Защищенный обмен сообщениями

Протоколы защиты с сервером

Протоколы защиты с сервером
Примеры:
Универсальная электронная карта (УЭК).
Электронные паспорта РФ (проект).
Плюсы:
Защита практически от любого нарушителя в канале.
Использование простых протоколов (DH) и структур данных
(CV-сертификаты).
Минусы:
Требуется подключение к Интернет с определенными
разрешениями.
Высокий порог вхождения даже для продвинутого
пользователя.

Защищенные считыватели: визуализация данных

Защищенные считыватели: Подпись на телефоне

Практическое использование Генераторы случайных чисел
”

ГСЧ, ДСЧ, ГПСЧ
Случайные числа – важнейший аттрибут любой
криптографической системы.
Зачем изобретать велосипед? Можно взять любой надежный
западный ДСЧ!
Dual EC DRBG: продвижение скрытно проплачивается АНБ
(Сноуден, 2013).
Intel Secure Key: потенциальный рай для аппаратных закладок
(Becker, 2013).
Linux RNG: вся энтропия основана на теоретически
необоснованных утверждениях.
Windows RNG: проприетарный.
...?

Отечественные ГСЧ
Вид Представители
Высокая
скорость
Широкая
применимость
Аппаратные
датчики
"Соболь";
"Аккорд"; ...
+ –
Биологические
датчики
КриптоПро CSP – +
Перспективные
датчики
Попов-Смышляев
"РусКрипто’2013";
Агафьин
"РусКрипто’2015";
+ +

Практическое использование Встраивание отечественной криптографии
”

Встраивание
Это всё здорово, но...
Западные решения и алгоритмы есть по умолчанию везде. Что же
нужно, чтобы работали отечественные?
А почти ничего!

Встраивание в Microsoft Windows
Microsoft Oﬃce: Outlook, Word, Excel
Шифрование писем.
Подпись писем.
Подпись документов.
Winlogon
Аутентификация на локальной машине по смарт-карте.
Аутентификация по RDP.
TLS
Клиентские и серверные приложения, функционирующие через
стандартные WinAPI-функции.

Встраивание в Microsoft Windows
Высокая модульность Windows
CryptoAPI – интерфейс из нескольких десятков функций,
реализовав которые в наборе библиотек (криптографическом
провайдере), можно путем изменения нескольких аргументов
добиться корректного применения любых криптографических
алгоритмов.
SSPI API – интерфейс, благодаря которому можно создавать
собственные реализации протоколов безопасности, в т.ч.
сетевого обмена (TLS).

А как же Unix?
Поддержка в библиотеках
OpenSSL.
LibreSSL.
Следовательно, поддержка на серверах
nginx.
Apache.

А как же Unix?
ПО, использующее криптографию, с помощью CryptoAPI под
Windows писать просто.
Как портировать на Unix, где нет системного обработчика
CryptoAPI?
Реализовать данный обработчик. Либо использовать бесплатную
библиотеку, которая уже это делает (capilite).

Как работать с криптографией через интерфейсы?
CryptoAPI 1.0
Базовые простые функции.
Работа с байтовыми массивами.
CryptoAPI 2.0
Расширенные функции.
Работа с ключами через сертификаты.
Большое количество функций под различные задачи.
Например, CryptSignMessage() позволяет подписать сообщение
ключом из заданного открытого контекста.

Пример CryptoAPI 1.0: Как выполнить протокол
Диффи-Хеллмана?
Alice
CryptGetUserKey(AliceProv, AT_KEYEXCHANGE, &AliceKey, ...)
CryptExportKey(AliceKey, PUBLICKEY_BLOB, pbAlicePublicKey,...)
Bob
CryptGetUserKey(BobProv, AT_KEYEXCHANGE, &BobKey, ...)
CryptExportKey(BobKey, PUBLICKEY_BLOB, pbBobPublicKey,...)
Alice
CryptImportKey(AliceKey, pbBobPublicKey, &DHKeyA, ...)
CryptSetKeyParam (DHKeyA, KP_ALGID, pbAlgId28147, ...)
Bob
CryptImportKey(BobKey, pbAlicePublicKey, &DHKeyB, ...)
CryptSetKeyParam (DHKeyB, KP_ALGID, pbAlgId28147, ...)

Браузеры
Internet Explorer работает через интерфейсы MS ⇒ алгоритмы
доступны из коробки при наличии CSP.
Возможна сборка с алгоритмами
Mozilla.
Chromium.
При наличии бесплатного плагина CADES
Google Chrome.
Mozilla.
Opera.

Спасибо за внимание!
Вопросы?
Материалы, вопросы, комментарии:
svs@cryptopro.ru;
alekseev@cryptopro.ru;
sagafyin@cryptopro.ru.

Отправитель −→ (C1| . . . |Cm) = EK(M1| . . . |Mm) −→ Получатель
↓
Нарушитель
Нарушителем проверяется гипотеза: блок Mi равен M∗.

Отправитель −→ . . . −→ Получатель
↑
M ←− Нарушитель ←−
error:
incorrect padding
Отправителю навязывается зашифрование сообщения,
начальный блок которого равен M = Ci−1 ⊕ IV ⊕ M∗.

Отправитель −→ EK(M |M2| . . . |Mq) −→ Получатель
↑ ↓
M’ ←− Нарушитель ←−
error:
incorrect padding
Первый блок ШТ будет равен
C = EK(M ⊕ IV) = EK(Ci−1 ⊕ IV ⊕ M∗ ⊕ IV) = EK(Ci−1 ⊕ M∗).
Mi = M∗ тогда и только тогда, когда C = Ci.

Пусть по каналу связи пересылается сообщение, зашифрованное в
режиме CBC с паддингом PKCS #5 и снабженное имитовставкой.
Предположим, что процедура приема и проверки сообщения
организована следующим образом.
. . .
BYTE* pbMAC = pbData + dwLen;
DWORD dwPaddedDataLen = dwLen;
. . .
CryptCreateHash(hProv, CALG_G28147_IMIT, hKey, 0, &hVerifyMAC);
if(!CryptDecrypt(hKey, 0, TRUE, 0, pbData, &dwLen))
SendErrorCodeToChannel("error: incorrect padding");
CryptHashData(hVerifyMac, pbData, dwPaddedDataLen, 0);
CryptGetHashParam(hMAC, HP_HASHVAL, pbVerMAC, &dwVerifyMACLen, 0);
if(memcmp(pbMAC, pbVerifyMAC, dwVerifyMACLen))
SendErrorCodeToChannel("error: incorrect MAC");
else
SendErrorCodeToChannel("success");

Отправитель −→ C = (EK(M)|MACK(M)) −→ Получатель
↓
EK(M) = (C1|C2| . . . |CdwLen
8
)
Ci = EK(Ci−1 ⊕ Mi) = (c1
i |c2
i | . . . |c8
i )
Mi = (m1
i |m2
i | . . . |m8
i )
Цель нарушителя: дешифровать последний байт Ci.

Отправитель (Tj|Ci|Incorrect_MAC) −→ Получатель
↑
Формируются случайные блоки Tj = (t1
j | . . . |t8
j ), j = 1, 2, . . ..
Вместе с Ci и произвольным (заведомо неверным) значением
имитовставки блоки Tj отправляются в канал.

Отправитель (Tj|Ci|Incorrect_MAC) −→ Получатель
↑
Получатель: обработка второго блока сообщения
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
j |t2
j | . . . |t8
j )
?
=
(. . . |0x01)
или (. . . |0x02|0x02)
или (. . . |0x03|0x03|0x03)
. . .

Отправитель (T1|Ci|Incorrect_MAC) −→ Получатель
↑
Нарушитель ←−
error:
incorrect padding
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
1|t2
1| . . . |t8
1)
=

↑ ↓
error:
incorrect padding
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
1|t2
1| . . . |t8
1)
=
(0xF3|0xAD|0x3D|0x71|0x1D|0xAA|0x01|0x31)

↑
error:
incorrect padding
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
2|t2
2| . . . |t8
2)
=

↑ ↓
error:
incorrect padding
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
2|t2
2| . . . |t8
2)
=
(0x32|0x3D|0x13|0x8D|0xC5|0x81|0x7C|0xA5)

↑
error:
incorrect padding
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
130|t2
130| . . . |t8
130)
=

↑ ↓
error:
incorrect padding
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
130|t2
130| . . . |t8
130)
=
(0x48|0xFA|0xD0|0x3E|0x01|0x4C|0x86|0xD1)

↑
error:
incorrect MAC
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
131|t2
131| . . . |t8
131)
=

↑ ↓
error:
incorrect MAC
DK(c1
i |c2
i | . . . |c8
i )
⊕
(t1
131|t2
131| . . . |t8
131)
=
(0x89|0x12|0x84|0x0C|0x01|0xAB|0x86|0x01)

(m1
i |m2
i | . . . |m8
i )
=
(c1
i−1|c2
i−1| . . . |c8
i−1)
⊕
(t1
131|t2
131| . . . |t8
131)
⊕
(0x??|0x??|0x??|0x??|0x??|0x??|0x??|0x01)
При возникновении кода ошибки на этапе проверки
имитовставки (после успешной проверки паддинга)
нарушитель вычисляет m8
i .

Решение
Отсекать побочный канал по коду ошибки при
расшифровании/проверке имитовставки.
. . .
. . .
SendErrorCodeToChannel("error: incorrect padding");
SendErrorCodeToChannel("error: incorrect MAC");
else

Решение
. . .
. . .
SendErrorCodeToChannel("error");
else

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

Решение
. . .
. . .
bErrorOnDecrypt = TRUE;
if(memcmp(pbMAC, pbVerifyMAC, dwVerifyMACLen) || bErrorOnDecrypt)
else

Российская криптография: так ли всё грустно?

More Related Content

More from Positive Hack Days

Российская криптография: так ли всё грустно?