Индийский удостоверяющий центр eMudhra отозвал ещё восемь промежуточных CA eMudhra, которые месяц назад называл незатронутыми инцидентом с ключами. На этот раз криптография не сломалась: компания не смогла доказать, что закрытые RSA-ключи при переносе между HSM обрабатывались по правилам собственной политики. Для команд, отвечающих за TLS и подпись кода, это очередное напоминание: «ключ не утёк» и «мы можем это подтвердить аудитору» — две разные вещи.
Как сообщает The Hacker News, проблема тянется к церемонии генерации ключей 30 апреля 2025 года. eMudhra создавала 16 ключей CA на HSM Utimaco, а затем готовила их для переноса в устройства Crypto4A в площадках США и ЕС. Поскольку перенос ключевого материала между HSM разных производителей ограничен, PKI-команда написала внутренний Python-скрипт: он должен был завернуть ключ для транспортировки и развернуть его на другой стороне.
В октябре компания уже отозвала восемь CA с ECDSA-ключами. Одна строка в скрипте при обратном чтении обрезала закрытое значение каждого ключа до первого байта. Из-за почти одинаковой метки слабая копия прошла дальше по процессу и получила сертификат. Исследователи смогли восстановить такие ключи из публичных сертификатов: значения оказались в диапазоне от 4 до 237. Несмотря на очевидно катастрофическую энтропию, слабые ключи создавали формально валидные подписи, проходили lint-проверки и два цикла аудита WebTrust.
Восемь новых отзывов касаются RSA CA: шести центров для TLS-сертификатов и двух для подписи кода. В октябре eMudhra утверждала в баг-трекере Mozilla, что эти центры прошли иной путь и потому не затронуты. Теперь выяснилось, что скрипт всё же считывал их закрытые части из HSM в память Python-процесса на компьютере, где проводилась церемония. RSA-ключи не были укорочены, а подписи по-прежнему соответствуют сертифицированным открытым ключам. Но журналов и файлов с этого компьютера недостаточно, чтобы надёжно восстановить обращение с материалом.
Именно это изменило оценку инцидента. По собственной политике eMudhra должна контролировать перенос ключей в HSM и из него; теперь компания признаёт, что не может положительно подтвердить соблюдение этого требования. Отзыв прошёл в конце прошлой недели с причиной cessationOfOperation, а не keyCompromise, которую использовали для октябрьских CA. Участники обсуждения в Mozilla уже спрашивают, почему выбран более мягкий код причины, если компания не может исключить нарушение режима хранения закрытых ключей.
Всего в опубликованном списке числятся 195 сертификатов, выданных этими промежуточными CA eMudhra: 130 — через EM DV TLS CA - G2C, 63 — через EM OV TLS CA - G2C и ещё два — через EM OV CS CA - G2C. Среди владельцев есть не только домены самой компании, но и университеты, колледжи, органы местной власти и другие организации. Самый свежий сертификат был выпущен за несколько дней до отзыва. eMudhra заявляет, что все владельцы уже переведены на новые сертификаты.
Для разработчиков и инфраструктурных команд практический вывод прост: нужно проверить цепочки сертификатов, особенно если в инвентаре есть emSign или сертификаты, выпущенные через отозванные G2C-центры. Нельзя ограничиваться проверкой срока действия в браузере: сертификат мог использоваться в CI/CD, для подписи артефактов, на API-шлюзе, в старом Java-хранилище или в устройствах с собственной базой доверия. Автоматизированная инвентаризация сертификатов и тесты цепочки доверия после замены здесь полезнее, чем ручной обход панелей управления.
Инцидент развивается на фоне выхода eMudhra из публично доверенного TLS-бизнеса. Компания говорит, что этот способ wrap-and-unwrap применялся только один раз, а остальные церемонии создавали ключи сразу в целевом HSM. Независимую проверку проводит KPMG, её завершение ожидается к 4 декабря; инвентаризация всех ключей CA должна быть готова к 30 ноября. Главный вопрос теперь не в том, допустил ли HSM ошибку — eMudhra винит собственный скрипт и контроль процесса, — а в том, почему столь чувствительная операция обходилась без проверки силы ключа и сверки созданного ключа с тем, который в итоге сертифицировали.
