Угадываемые ключи eMudhra: компрометация и последствия для доверия

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

Секретные ключи от нескольких промежуточных сертификатов индийского УЦ eMudhra оказались легко угадываемыми, так как из-за нарушения процедур работы с ключами их значения лежали в интервале от 1 до 255: то есть использовался только один младший байт — эффективная разрядность всех этих ключей не превысила восьми битов. Ключи данного УЦ входили в типовой доверенный набор и распространённых браузеров, и ОС. При этом соответствующие промежуточные сертификаты УЦ были выпущены ещё в 2025 году, но заметили «странность» только 17 октября этого, 2026, года. То есть долгое время на заведомо некорректные ключи не обращали внимания ни разработчики браузеров, ни сами УЦ, ни операторы логов Certificate Transparency. Кроме того, ключи данного УЦ были удостоверены другим хорошо известным УЦ — Sectigo.

Зная секретный ключ от доверенного сертификата УЦ, можно выпускать доверенные оконечные сертификаты, которые будут приниматься различными программами, в том числе «коробочными» веб-браузерами. Это позволяет подменять TLS-узлы (например, HTTPS для веба).

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

В некоторых случаях экстренные меры реагирования оказались чрезмерными: например, в стандартной библиотеке популярного языка Go для работы с X.509-сертификатами (TLS-сертификатами) была внезапно изменена внутренняя логика работы и добавлена функция блокирования ключей сертификатов по отпечатку внутри самой библиотеки, в обход средств ОС и штатных механизмов валидации. В качестве первых отпечатков непосредственно в исходный код библиотеки внесены отпечатки нестойких ключей упомянутого УЦ. Формально причиной является экстренное реагирование на событие компрометации, однако на практике в популярную библиотеку разработчиками среды Go оказался внедрён механизм, который в будущем позволит блокировать любые другие ключи в сертификатах на уровне исходного кода. Это противоречит логике построения низкоуровневых криптографических библиотек — обычно принимается, что логика работы с конкретными ключами и их отпечатками находится выше уровня подобной библиотеки и реализуется на стороне вызывающего кода. Какой-то открытой политики, регулирующей списки заблокированных ключей, в Go нет (и не должно быть). Такой шаг вызывает опасения, что в Go появится непрозрачный процесс блокирования ключей УЦ в исходном коде на низком уровне.