🚰 Закрытый ключ оказался числом 4. Добро пожаловать в мир серьёзной криптографии Криптография высшей пробы. Берём эллиптическую кривую P-384, обеспечивающую при правильной реализации стойкость порядка 192 бит, и каким-то образом получаем закрытый ключ со значением 115. Или 4. Или 56. У удостоверяющего центра eMudhra восемь закрытых ключей промежуточных центров сертификации оказались обычными числами от 4 до 237. Исследователь Скотт Хелме восстановил все восемь по открытым данным сертификатов менее чем за секунду, просто перебрав возможные значения. Ни взлома серверов, ни компрометации аппаратных модулей безопасности не потребовалось. Сама криптография работала безупречно, просто её стойкость свели к восьми битам. Причём шесть скомпрометированных ключей предназначались для выдачи TLS-сертификатов, а ещё два для подписи программного кода. В результате любой обладатель таких ключей мог выпускать криптографически корректные сертификаты от имени доверенного центра. Самое интересное обнаруживается в истории инцидента. Ещё в мае 2025 года шесть тех же промежуточных центров публиковали списки отзыва сертификатов с некорректными цифровыми подписями. Ошибку тогда исправили и публично разобрали, но главную проблему с ключами не замечали около 17 месяцев. Теперь выяснилось, что всё это время злоумышленник потенциально мог подделывать сертификаты для произвольных доменов. Chrome и Firefox оперативно заблокировали скомпрометированные ключи, а обязательная проверка Certificate Transparency дополнительно защищала браузеры от незарегистрированных подделок. С небраузерным программным обеспечением ситуация хуже. Многие TLS-клиенты, включая распространённые конфигурации curl, Python и Node.js, не проверяют ни журналы CT, ни статус отзыва сертификатов. Хелме продемонстрировал, как такие приложения принимают поддельный сертификат для API Stripe. Для реальной атаки потребовалась бы возможность перехватывать или перенаправлять трафик, но дальше злоумышленник уже мог бы получать токены авторизации и другие конфиденциальные данные. Вся история прекрасно иллюстрирует слабое место инфраструктуры открытых ключей PKI. Можно использовать надёжные алгоритмы, аппаратные криптомодули и многоступенчатые процедуры, а затем испортить результат одной ошибкой в сценарии генерации ключей. По предварительному объяснению eMudhra, скрипт создал дополнительные слабые ключевые пары, а сотрудники перепутали их с полноценными из-за похожих названий. Ошибочные ключи получили сертификаты не только от собственного корневого центра, но и через перекрёстную подпись Sectigo. Теперь Mozilla исключает затронутый корневой сертификат из доверенного хранилища NSS, а Chrome готовит удаление emSign ECC Root CA - G3, из-за чего некоторым законным владельцам сертификатов придётся менять цепочки доверия. Однако главная проблема шире конкретного удостоверяющего центра. Пока приложения полагаются на устаревшие хранилища CA и игнорируют отзыв сертификатов, даже давно скомпрометированный однобайтовый ключ способен оставаться действующим инструментом для подмены доверенных серверов. И никакая математическая стойкость P-384 здесь уже не поможет. #Криптография, #Сертификаты, #Уязвимости @SecLabNews