Серийный номер сертификата ЭЦП, где посмотреть
Обновлено: 30.06.2024
В 2007 году Марк Стивенс представил настоящий поддельный сертификат X.509, основанный на коллизии выбранного префикса MD5. В этом методе злоумышленникам необходимо было предсказать серийный номер сертификатов X.509, сгенерированных центрами сертификации, помимо создания пар коллизий MD5. После этого требуется случайность серийного номера. Тогда, в этом случае, как мы можем предсказать случайный серийный номер? Таким образом, был пересмотрен способ генерации серийного номера в OpenSSL. Уязвимость была обнаружена в том, что значение поля «не раньше» сертификатов X.509, сгенерированных OpenSSL, пропускало время генерации сертификатов. Поскольку время является начальным числом для генерации серийного номера в OpenSSL, мы можем ограничить начальное значение узким диапазоном и получить ряд серийных номеров-кандидатов и использовать эти серийные номера-кандидаты для создания поддельных сертификатов X.509 с помощью метода Стивенса. Хотя алгоритм MD5 был заменен CA, такая атака будет возможна, если в будущем будет обнаружена коллизия выбранного префикса текущих хеш-функций. Кроме того, мы исследуем способ создания серийных номеров сертификатов в других библиотеках с открытым исходным кодом, таких как EJBCA, CFSSL, NSS, Botan и Fortify.
1. Введение
Цифровые сертификаты широко используются в Интернете, что является основным средством обеспечения безопасности. Многие участники, такие как клиенты и серверы, зависят от цифровых сертификатов для аутентификации друг друга. Если злоумышленник может подделать чужой цифровой сертификат, он/она может выдать себя за чужую личность и получить доступ к конфиденциальной информации. Это одна из серьезных угроз для общества.
Безопасность цифровых сертификатов основана на алгоритмах цифровой подписи и алгоритмах хеширования. Если произойдет атака на эти алгоритмы, цифровые сертификаты, основанные на этих алгоритмах, больше нельзя будет доверять. Среди атак коллизия хеш-алгоритмов является одной из самых серьезных угроз. Поскольку первая настоящая коллизионная атака MD5 была представлена Ваном [1, 2] в 2004 году, стало возможным создавать поддельные сертификаты на основе коллизионной атаки MD5.
На выставке Eurocrypt 2007 Стивенс впервые создал различные сертификаты с одинаковой подписью на основе атаки с коллизией выбранного префикса MD5 [3–5]. Это стало большим событием для коммерческих ЦС и их пользователей, потому что такие поддельные сертификаты могут быть успешно проверены. После этого многие компании объявили об уязвимости MD5 для цифровых сертификатов, например, Verisign, Microsoft, Mozilla, TC TrustCenter, RSA, US-CERT и Cisco [6]. Кроме того, в 2012 году была обнаружена супервредоносная программа Flame [7], которая использует этот метод для подделки сертификата Microsoft [8].
Метод Стивенса не может подделать сертификат из существующего сертификата, потому что вторая атака прообраза MD5 пока сложна. Этот метод должен создать два сертификата на основе атаки коллизии выбранного префикса MD5 перед отправкой одного из них для подачи заявки на сертификат в ЦС. Реализация процесса имеет две ключевые проблемы: одна связана с построением пары коллизий MD5, а другая связана с некоторыми полями, контролируемыми ЦС, такими как серийный номер в сертификатах, которые злоумышленники должны предсказать перед отправкой приложения. В отношении этой угрозы Стивенс дал два предложения для ЦС: первое — заменить алгоритм MD5 другими безопасными алгоритмами хеширования (такими как SHA-256), поскольку в настоящее время не происходит коллизии выбранного префикса с другими алгоритмами хеширования; другой — добавить достаточное количество свежей случайности в соответствующие поля (например, серийный номер), чтобы злоумышленники не могли предсказать, нельзя ли сразу заменить MD5 [5]. Однако в реальных условиях многие действительные сертификаты по-прежнему используют MD5 [9]. Кроме того, мы захватили более 180 000 сертификатов из Интернета, а более 5000 сертификатов основаны на MD5, то есть 2,8% сертификатов.
В этой статье мы сосредоточимся на том, достаточно ли случайности некоторых полей в сертификатах, чтобы злоумышленники не могли предсказать. Поскольку подробные коды бизнес-центров сертификации не являются общедоступными, мы рассмотрим способ создания сертификатов с помощью программного обеспечения с открытым исходным кодом OpenSSL, чтобы узнать, как предсказать значения некоторых полей в сертификатах. OpenSSL использует генератор псевдослучайных чисел (PRNG) для вывода случайных чисел. Были предложены некоторые литературные источники, связанные с безопасностью PRNG [10–15]. Безопасность OpenSSL PRNG в Android и Debian описана в [10, 14]. Теоретический анализ PRNG OpenSSL был представлен в [10]. Однако неясно, как работает PRNG в процедуре генерации сертификатов X.509. Кроме того, мы также исследовали создание сертификатов в других библиотеках с открытым исходным кодом, таких как EJBCA, CFSSL, NSS, Botan и Fortify.
В этой статье у нас есть три дополнения: (1) мы обнаружили уязвимость OpenSSL, заключающуюся в том, что поле «не раньше» в сертификатах пропускает время создания сертификатов, которое является начальным значением для создания поля «серийный номер». », чтобы можно было предсказать значение «серийного номера». (2) Даем метод прогнозирования для поля «серийный номер» и подделываем сертификаты на основе предложенного метода и метода Стивенса. (3) Мы исследовали пять других библиотек с открытым исходным кодом и обнаружили аналогичную уязвимость в двух библиотеках, EJBCA и NSS.
Доклад организован следующим образом. В разделе 2 вводятся некоторые предварительные сведения и определяются задачи, решаемые в статье. В разделе 3 рассматриваются исходные коды OpenSSL о создании сертификатов X.509. Затем в разделе 4 предлагается метод прогнозирования ключевых полей сертификатов. Некоторые контрмеры приведены в разделе 5, а в разделе 6 исследуются другие библиотеки с открытым исходным кодом. Наконец, Раздел 7 завершает статью.
2. Предварительные сведения
В сертификатах X.509 подпись ЦС является наиболее важной частью для предотвращения подделки. Любое изменение содержимого сертификатов приведет к изменению подписи центра сертификации, другими словами, к изменению значения хэша. Если сертификат пользователя A существовал, мы не можем подделать сертификат напрямую, потому что он должен создать второй прообраз хеш-значения сертификата. Однако мы можем использовать идентификатор другого пользователя B, чтобы применить сертификат для CA и создать пару коллизий с выбранным префиксом, которая может подделать сертификат A.
Читайте также: