Как я факторизовал RSA-ключи центра сертификации из эпохи Netscape
Безопасность RSA основана на предположении, что разложить большое составное число на два простых множителя практически невозможно. Однако это утверждение справедливо только при достаточно большой длине ключа и корректной генерации параметров. История раннего Web PKI показывает, что в 1990-е годы эти условия соблюдались далеко не всегда.
Сегодня для RSA обычно используют ключи длиной не менее 2048 бит. Ключи на 1024 бита давно считаются устаревшими, а 512-битные были признаны небезопасными еще в начале 2000-х. При этом появление квантовых компьютеров в будущем может поставить под вопрос и более длинные RSA-ключи: алгоритм Шора теоретически позволяет эффективно факторизовать числа, лежащие в основе RSA.
Мне стало интересно, насколько легко взламываются старые сертификаты, которые когда-то считались надежными. В первые годы существования Web PKI не было единых требований к длине ключей, а браузеры распространялись вместе с собственными наборами доверенных центров сертификации. Netscape добавила поддержку SSL в 1994 году, а вскоре аналогичная возможность появилась в Internet Explorer. На тот момент криптографию также ограничивали экспортные правила, поэтому слабые ключи встречались заметно чаще.
Для поиска подходящих образцов были использованы архивные установочные файлы старых версий Netscape и Internet Explorer. Из них удалось извлечь наборы корневых сертификатов, после чего сертификаты были отсортированы по длине RSA-модуля. Такой подход быстро показал, что среди исторических центров сертификации действительно встречаются ключи, которые можно факторизовать на обычном современном компьютере.
Целью стали два 512-битных сертификата E-Certify, поставлявшиеся с Netscape 4.51 в марте 1999 года. Один предназначался для SSL-соединений, другой - для S/MIME. Оба принадлежали канадскому удостоверяющему центру, который давно прекратил работу.
К тому времени 512-битный RSA уже находился на грани практической непригодности. В том же 1999 году был факторизован ключ RSA-155, имевший сопоставимый размер. Поэтому сертификаты E-Certify, вероятно, не следовало включать в поставку браузера даже с учетом технологических возможностей той эпохи. Netscape окончательно удалила их из набора доверенных сертификатов в 2002 году.
Факторизация публичного ключа позволяет получить два простых множителя числа N. Зная их, можно вычислить закрытую экспоненту и восстановить приватный ключ удостоверяющего центра. Для расчетов использовался пакет CADO-NFS - набор инструментов для факторизации крупных целых чисел методом числового решета общего поля.
На компьютере с процессором Ryzen 9 5950X факторизация первого ключа заняла примерно 32 часа. Второй ключ потребовал еще около 29 часов. Для 512-битного RSA это уже не мгновенная операция, однако затраты выглядят незначительными по сравнению с ценностью доверия, которое браузер автоматически оказывал такому центру сертификации.
Практически процесс сводится к нескольким этапам. Сначала из сертификата извлекается RSA-модуль. Затем полученное число передается CADO-NFS для факторизации. После нахождения простых множителей вычисляются параметры приватного ключа, который затем можно использовать для подписи новых сертификатов.
Однако в современном интернете эти ключи почти бесполезны. Срок действия корневых сертификатов E-Certify истек 16 октября 2003 года, а современные браузеры давно удалили их из доверенных хранилищ. Единственным исключением может стать старая копия Netscape 4.51, запущенная с системной датой, установленной до окончания срока действия сертификатов.
Проверка такого сценария оказалась сложнее самой факторизации. TLS в Netscape 4.51 настолько отличается от современных реализаций, что обычный сервер не может установить с ним соединение. Для эксперимента пришлось создать отдельный ретро-сервер на Go, поддерживающий старые версии протокола и наборы шифров, которые еще понимал браузер конца 1990-х.
В результате удалось организовать тестовый сайт, доступный только из соответствующей исторической среды. В современном браузере он не открывается - не из-за проблем с DNS или сертификатом, а потому что современные TLS-стеки намеренно отказываются от устаревших протоколов, слабых алгоритмов и небезопасных параметров обмена ключами.
Интересно, что аналогичный пример нашелся и среди компонентов Internet Explorer. Версия 3.02 поставлялась с тестовым центром сертификации для подписи программного обеспечения - `OU=Test VeriSign Commercial Software Publisher CA`. Его RSA-ключ также оказался достаточно маленьким для относительно простой факторизации.
Эти эксперименты хорошо показывают, почему длина ключа сама по себе не является гарантией безопасности. Важны не только количество битов, но и качество генерации случайных чисел, корректность параметров, срок действия сертификата, алгоритмы подписи и правила проверки цепочки доверия.
Особенно опасными являются корневые сертификаты. Если злоумышленник получает их приватный ключ, он теоретически может выпускать новые сертификаты для любых доменов, которым доверяет соответствующий браузер. В эпоху Netscape это могло привести к подмене сайтов, перехвату защищенных соединений и созданию поддельных сертификатов для электронной почты.
Правда, эксплуатация подобной уязвимости требовала бы совпадения множества условий: наличия старого браузера, сохраненного доверия к конкретному центру сертификации, подходящей даты на компьютере и поддержки устаревших TLS-механизмов. Поэтому речь идет скорее об историческом исследовании, чем о практической атаке на современных пользователей.
Главный вывод остается актуальным: криптографические стандарты нельзя считать надежными навсегда. Ключ, который в 1990-е выглядел приемлемым, спустя несколько лет мог стать доступной целью для исследователя с обычным персональным компьютером. По этой причине сертификаты должны своевременно перевыпускаться, слабые алгоритмы - выводиться из эксплуатации, а доверенные корневые центры - регулярно пересматриваться.
Старые корневые сертификаты также представляют интерес для цифровой археологии. Они позволяют увидеть, как менялись требования к Web PKI, какие центры сертификации считались надежными и насколько быстро развивались методы факторизации. Но использовать восстановленные ключи против реальных пользователей или сервисов недопустимо: подобные эксперименты должны проводиться только в изолированной лабораторной среде и на системах, созданных специально для тестирования.