dxdt.blog: занимательный интернет-журнал

Напишу, пожалуй, несколько общих змечаний, касающихся компрометации ключей УЦ eMudhra.

Секретные ключи ECDSA, соответствующие нескольким промежуточным сертификатам данного УЦ, оказались угадываемыми. Буквально – их можно угадать, перебрав любым простым способом менее 255 натуральных чисел. Секретный ключ в ECDSA – это обычное натуральное число. При этом открытый ключ, соответствующий угадываемому секретному, на вид ничем не отличается от стойкого ключа. Потому что открытый ключ в ECDSA это точка на кривой (P-256, в данном случае), то есть, ещё пара натуральных чисел из определённого множества.

Однако утилиты, проверяющие нестойкие ключи, были и есть, но их, как мы видим, далеко не всегда используют (УЦ TLS из “коробочных версий” браузеров, в теории, должны использовать такие утилиты, но практика – далека от теории). Таким образом, ничего необычного в угадываемых ключах, вообще говоря, нет: ошибки, к сожалению, случаются, не следует переоценивать возможности “коробочного” TLS-окружения в вебе, как это принято делать.

Сертификаты промежуточных УЦ eMudhra с нестойкими ключами были опубликованы в прошлом году, такие сертификаты не являются секретными, а наоборот – о них УЦ должны заявлять. Но никто долгое время не замечал, что с ключами в данных сертификатах что-то не так (в том числе, и внутри УЦ никто не замечал). С одной стороны – это странно. С другой – мало кто следит за подобным, не удивляйтесь, такова реальность инфраструктуры TLS в вебе, тут уж ничего не поделать (зато есть квантовостойкие криптосистемы и хеш-деревья, да).

Угадываемый ключ означает, что можно взять открытый ключ из сертификата УЦ, найти за полсекунды секретный ключ, а потом начать самостоятельно выпускать доверенные TLS-сертификаты – то есть, сертификаты, в которые будет верить обычный браузер, в том числе, Chrome или “Яндекс.Браузер”; см. ниже про Certificate Transparency (CT). (И ещё тут всё будет работать, но за некоторыми исключениями: для ряда TLS-узлов может использоваться так называемый key pinning – то есть, привязка по ключам сервера или УЦ в цепочке, но это редкие детали.)

Если у вас есть доверенный сертификат, то можно активно перехватывать TLS-соединение: подменять практически любой HTTPS-узел, потому что дополнительной привязки ключей к именам, фактически, в вебе нет (DANE не используется, HPKP – запретили, и т.д.). Но для такого перехвата нужно контролировать канал. Расшифровать чужой, “не подменённый”, трафик доверенный сертификат не позволяет. Как только что отмечено, для особо важных узлов, типа некоторых сервисов Google, может использоваться упомянутый key pinning на уровне браузера, и тогда активная подмена сессии будет обнаружена браузером (и об этом может быть автоматически заявлено в Google, например).

В современных браузерах, в общем случае, доверие TLS-сертификату требует, чтобы в сертификате были доверенные SCT-метки, которые выдают операторы CT-логов. Метки подписаны. И подписаны они другими ключами, ключами оператора лога. Эти ключи – в другой цепочке доверия, которая никак к сертификатам УЦ не привязана. Поэтому компрометация ключа УЦ “от сертификатов” не позволяет подделать SCT-метку (для этого нужен секретный ключ лога; насколько “секретны” эти ключи – другой вопрос).

Однако в процессе выпуска сертификата можно предъявить соответствующий пресертификат оператору лога и получить доверенную SCT-метку, которую уже потом добавить в сам сертификат. Операторы логов принимают все подходящие по интервалу валидности сертификаты, выпущенные в цепочке от доверенных корней. Это доверие примерно эквивалентно доверию в браузере. Соответственно, если скомпрометирован ключ такого доверенного УЦ, то можно просто штатным образом предъявлять пресертификат с валидной подписью и получать SCT-метку (да, тут не оговорены разные возможные ограничения доступа к размещению пресертификатов, но это другая история; обычно, ограничений нет – главное, чтобы было доверие корню). Таким образом, получить SCT-метки и сделать сертификат доверенным с точки зрения браузера – возможно. Но останется отметка в CT-логе (в общем случае).

Следов сертификатов от скомпрометированных ключей eMudhra в CT-логах пока выявить не удалось. Это не означает, что сертификаты не были выпущены и использованы в приложениях, которые, в отличие от браузеров, не требуют SCT-меток при валидации. Таких приложений тоже немало: это разные утилиты для работы с вебом, почтовые системы и т.д. Кто, как и где использовал такие сертификаты, если использовал, – неизвестно. И это речь шла про TLS. Хуже всего, что есть сертификаты ключей подписи кода, и доверие там выстраивается похожим способом.

Ключи eMudhra были кросс-подписаны Sectigo. Это означает, что доверие распространялось от корней УЦ Sectigo. Кросс-подпись, в смысле доверия, зависит от ключа, а не от сертификата, так что с точки зрения компрометации – лучше не делает. Почему Sectigo не проверяли стойкость ключей, которые находятся в “их цепочке доверия”? Это тоже “большая загадка”. Но, опять же, таковы реалии инфраструктуры TLS-сертификатов в вебе.

Сертификаты скомпрометированных ключей можно и нужно отозвать. Это сделано. Проблема в том, что отзыв работает плохо, а CRL (списки отзыва) мало какие клиенты проверяют. Chrome – не проверяет. Однако в браузерах типа Chrome есть инструменты исключения доверия по отпечаткам ключей, новые отпечатки – распространяются с обновлением браузера. Именно так доверие данным ключам и было “снято” на днях. Однако тривиальный секретный ключ означает, что его, этот ключ, невозможно удержать в секрете.

Почему в браузеры (например) сразу не встроены подобные тривиальные ключи как недоверенные? Причин две. Первая – мало кто верил, что угадываемый ключ может быть использован полноценным УЦ, а каждая проверка по списку – это дополнительные такты процессора в программе, реализующей TLS-стек. Вторая причина – непонятно, на каком количестве ключей нужно остановиться: 128? 256? 2^16? И каждая итерация – довольно большие затраты вычислительного ресурса.

Вот.

Адрес записки: https://dxdt.blog/2026/10/21/19467/