Создание постквантового центра сертификации с помощью сертификатов на основе деревьев Меркла29.09.2026 16:00

Когда вы вводите адрес в браузере, как понять, что вы подключаетесь к нужному сайту? Инфраструктура открытых ключей веба (Web PKI) — это сложная распределённая экосистема политик, протоколов и операторов инфраструктуры, которая помогает убедиться, что вас не перенаправляют на неправильный или вредоносный сайт. За последние несколько десятилетий эта экосистема значительно изменилась. Одно из изменений — появление прозрачности: теперь обязательно регистрировать все сертификаты в общедоступных журналах прозрачности сертификатов. Теперь перед ней стоит новый вызов — скорое появление квантового компьютера, из-за которого нам необходимо перейти на постквантовую (PQ) криптографию к 2029 году.

Этот переход не будет простым: простая замена криптографии в сертификатах на постквантовую в масштабах всего интернета привела бы к неприемлемому снижению производительности. Сейчас нужен новый подход к Web PKI, который позволит считать прозрачность не дополнением, а неотъемлемым свойством системы, и создать новую систему, эффективно масштабируемую для постквантовых подписей.

Получив широкую поддержку в отрасли, сертификаты на основе дерева Меркла (MTC) стали перспективным решением. В этом году, после успешного экспериментального развёртывания с Chrome, Cloudflare активно внедряет MTC.

После сегодняшнего объявления о том, что Cloudflare становится центром сертификации (CA), мы рады сообщить, что этот CA будет выпускать MTC. Мы рассчитываем, что в начале 2027 года их включат в недавно запущенное хранилище корневых сертификатов с квантовой устойчивостью Chrome. В рамках нашей миссии по созданию лучшего интернета и следуя традиции Cloudflare предоставлять самую надёжную из доступных криптографию бесплатно, мы будем выпускать стандартные MTC без какой-либо платы. Наличие CA, который выпускает как классические сертификаты, так и MTC, позволит нам по умолчанию использовать наиболее безопасный доступный способ аутентификации и обеспечить простую и эффективную возможность перехода на постквантовую криптографию для значительной части интернета.

Современная экосистема доверия

Чтобы понять, как MTC меняют правила игры, сначала разберёмся, как сегодня работает доверие в интернете.

На стороне клиента браузеры — в данном случае «TLS-клиенты» — поддерживают программы корневых сертификатов, в которых определён набор правил, которым должны следовать CA, чтобы им доверяли. На стороне сервера CA выступают доверенными привратниками: они обеспечивают работу инфраструктуры выпуска сертификатов, проверяют право владения доменом и подтверждают связь доменного имени с открытым ключом, который доказывает право на этот домен.

Но как проверить, что CA соблюдают правила? Здесь на помощь приходит прозрачность сертификатов (CT), благодаря которой выпуск сертификатов можно публично проверять. Выпуская сертификат, CA должен также отправить его как минимум в два общедоступных журнала. С 2016 года Cloudflare поддерживает семейство журналов CT Nimbus, а теперь запускает новое семейство статических журналов CT под названием Raio.

Хотя благодаря экосистеме CT сертификаты доступны для публичного просмотра, это не означает, что они выпущены правильно или безопасны в использовании. Мониторинг помогает выявлять проблемы, сопоставляя записи в журналах с ожиданиями владельцев доменов и сообщая о подозрительной активности. Cloudflare запустила сервис мониторинга прозрачности сертификатов в 2019 году, а недавно сделала его общедоступным. Мы также публикуем масштабные данные о сертификатах на странице прозрачности сертификатов в Radar (ранее — Merkle Town).

По мере того как организации начинают обновлять серверы для использования постквантовой аутентификации, мониторинг прозрачности сертификатов будет играть ещё более важную роль в обнаружении возможных откатов с постквантовых механизмов. Владельцам доменов, перешедшим на постквантовую аутентификацию, следует отслеживать журналы CT и выявлять неожиданные записи устаревших сертификатов, чтобы клиенты не переходили на вредоносный вариант с пониженным уровнем защиты.

Одна из проблем современной системы заключается в том, что прозрачность была реализована как дополнение, что привело к трудностям при масштабировании. Сертификаты часто регистрируются многократно, в разных форматах и в нескольких журналах, поэтому мониторинговым системам приходится загружать и обрабатывать каждый журнал, чтобы не пропустить выпуск сертификата. Это может быть дорого — и затрудняет привлечение разнообразных операторов журналов в масштабах всего интернета. Согласно нашим оценкам, постквантовые подписи увеличат объём данных, которые должны хранить журналы CT, в 40 раз. Именно эта проблема масштабирования и последующее отсутствие правильных стимулов лежат в основе сложностей с масштабированием постквантовой криптографии.

Проблема масштабирования постквантовой криптографии

Мы подробно писали о сложностях масштабирования постквантовой криптографии, но, вкратце, для поддержки аутентификации серверов в масштабах всего интернета Web PKI должна обеспечивать аутентификацию примерно миллиарда TLS-серверов, не загружая открытый ключ каждого сервера заранее на каждый клиент. Традиционно CA решали эту задачу, используя цепочки сертификатов для распределения доверия. Но со временем такие дополнения, как проверка отзыва ключей и прозрачность сертификатов, добавили больше открытых ключей и подписей — в типичном TLS-рукопожатии используются пять подписей и два ключа. Постквантовые подписи примерно в 40 раз больше классических, что создаёт дополнительную нагрузку, которую клиентам, CA, журналам и системам мониторинга было бы дорого обрабатывать в масштабах всего интернета.

На помощь приходят сертификаты на основе дерева Меркла (MTC) — проект спецификации рабочей группы IETF PLANTS, описывающий архитектуру компактных и эффективных постквантовых сертификатов. MTC объединяют сертификаты в дополняемое дерево Меркла, позволяя CA подписать корень этого дерева вместо множества отдельных сертификатов. Благодаря этому браузеры и другие клиенты могут проверять сертификат по компактному доказательству включения — последовательности криптографических хешей — относительно подписанного заголовка дерева, а не проверять каждый сертификат отдельно. Ключевая идея MTC — «не регистрируй выпущенное, а выпускай посредством регистрации». Объединяя выпуск сертификатов с их регистрацией, система делает прозрачность обязательным условием работы, а не дополнением.

Роль центра сертификации в переосмысленной PKI

Мы развиваем возможность выпуска MTC как неотъемлемую часть создания центра сертификации Cloudflare. Это означает, что нам нужно следить за новыми требованиями программы корневых сертификатов PQ и одновременно разрабатывать программный стек для выпуска и зеркалирования, а также создавать инфраструктуру, налаживать операционные процессы и выполнять требования соответствия для традиционного CA — задача не из простых!

Преимущество в том, что мы с самого начала можем определить требования и архитектуру новой постквантовой PKI и создать систему, которая соответствует ценностям Cloudflare и особенностям нашей глобальной сети. Мы стремимся к максимальной прозрачности на этом новом пути.

Рассмотрим обновлённую для MTC архитектуру:

Если сравнить её с традиционной экосистемой CA, заметно, что обязанности CA в основном не изменились: проверять контроль над доменом, связывать его с открытым ключом и выпускать сертификаты. Главное отличие в том, что в экосистеме MTC CA не подписывает сертификаты напрямую, а затем регистрирует их. Вместо этого он ведёт журнал прозрачности на основе дерева Меркла, а доказательство включения, подтверждающее, что сертификат действительно находится в дереве, служит якорем доверия. CA также будут управлять зеркальными со-подписантами, которые хранят копию журналов выпуска, проверяют их согласованность с принципом только добавления записей и обеспечивают прозрачность и доступность журналов для всей экосистемы.  

Выпуск MTC

MTC бывают двух видов, и оба можно кодировать в формате сертификата X.509, который уже распознают клиентские программы, — просто с «необычным» алгоритмом подписи. В автономном формате значение подписи сертификата содержит совместно подписанный заголовок дерева журнала выпуска и доказательство включения (последовательность хешей), показывающее, что сертификат содержится в этом журнале. Если клиенты могут получать совместно подписанные заголовки дерева по альтернативному каналу (например, через механизм обновления браузера), сертификат можно передавать в формате относительно контрольной точки. В этом случае значение подписи состоит из лёгкого доказательства включения и не содержит громоздких постквантовых подписей.

Для простоты рассмотрим пример выпуска автономного сертификата. Когда сайту нужен сертификат для своего домена, он может запросить его у CA по протоколу Automatic Certificate Management Environment (ACME), который обрабатывает запросы сертификатов, проверку контроля над доменом и процедуры выпуска. Инфраструктура ACME Cloudflare будет основана на форке Boulder — широко используемого и проверенного ПО ACME, на котором работает Let’s Encrypt. Команда Let’s Encrypt активно разрабатывает поддержку MTC в Boulder. Мы планируем поддерживать собственный форк, включив в него эти изменения из основного проекта и дополнения для Cloudflare, а где возможно — передавать изменения обратно в основной проект.

Получив запрос на выпуск MTC, сервер ACME центра сертификации проверяет, действительно ли сервер контролирует домен. Если проверка пройдена, CA сериализует эти данные и добавляет их в дополняемый журнал.

Добавив запись MTC в журнал выпуска, CA вычисляет обновлённое состояние журнала, а затем подписывает контрольную точку для этого состояния. Эта контрольная точка подтверждает, что CA выпустил каждую запись, включённую в дерево Меркла журнала к этому моменту.

Затем CA передаёт обновлённое состояние журнала и новую контрольную точку доверенному со-подписанту. Тот надёжно хранит копию журнала выпуска CA и проверяет, что каждое новое состояние дополняет предыдущий журнал, согласуется с предыдущим деревом и сформировано правильно. Эта дополнительная совместная подпись позволяет клиентам и системам мониторинга быть уверенными, что другая доверенная сторона видела то же состояние журнала и проверила, что CA не показывает разным участникам экосистемы разные версии сведений о выпущенных сертификатах. Кроме того, она гарантирует доступность выпущенных сертификатов для мониторинга, даже если журнал выпуска CA недоступен.

В проекте политики программы корневых сертификатов Chrome с квантовой устойчивостью требуются как минимум две совместные подписи: одна — от зеркального со-подписанта, признанного Chrome и управляемого отдельной организацией, другая — от самого CA, выпустившего MTC. Поэтому мы будем зеркалировать журналы других пилотных CA и требовать как минимум одну независимую совместную подпись для выпущенных нами сертификатов.

Cloudflare реализует зеркального со-подписанта в Azul — нашем журнале прозрачности с открытым исходным кодом на Rust. Для максимальной совместимости он будет использовать протокол tlog mirror от c2sp.

Наконец, после успешного получения совместной подписи от зеркального со-подписанта CA формирует MTC, включающий совместные подписи, открытый ключ сервера и доказательство включения. Затем CA отправляет MTC серверу, который сможет использовать его для TLS!

Эффективная доставка постквантовых подписей: оптимизация с контрольными точками

Автономные сертификаты работоспособны, но при TLS-рукопожатии они по-прежнему передают крупные постквантовые подписи, что снижает их эффективность. Настоящий прирост производительности благодаря архитектуре MTC обеспечивают сертификаты в формате относительно контрольной точки.

Вместо того чтобы включать совместные подписи в каждый сертификат, CA могут выбрать последовательность поддеревьев, охватывающих все действующие сертификаты в журнале, и использовать её как контрольную точку. Эти поддеревья вместе с данными для их аутентификации можно передавать клиентам через службу обновлений по альтернативному каналу. Во время TLS-рукопожатия браузер проверяет, что данные сертификата сервера — в том числе доменное имя и открытый ключ — присутствуют в доверенном поддереве журнала CA. Если доказательство включения связывает сертификат с совместно подписанной контрольной точкой, а открытый ключ подтверждает право владения им во время TLS-рукопожатия, клиент может быть уверен, что подключился к нужному серверу.

Если периодически передавать TLS-клиентам по альтернативному каналу эти подписи и метаданные дерева, небольшой набор пакетных подписей MTC сможет эффективно охватить миллиарды сертификатов, выпущенных тем или иным CA. Контрольные точки эффективнее в больших масштабах, но они не отменяют необходимости в автономных MTC: клиенты могут быть только что установлены, отключены от сети или не получить нужное обновление контрольной точки. Поэтому серверам важно сохранять возможность перейти на автономный сертификат.

MTC в действии: результаты эксперимента с Chrome

В этом году мы провели эксперимент с Chrome, чтобы проверить, можно ли использовать MTC между клиентом и сервером. Мы запустили «тестовый CA» (фиктивный центр сертификации с упрощённым конвейером выпуска), который выпускал MTC, подкреплённые традиционной цепочкой сертификатов, для ряда доменов Cloudflare на бесплатном тарифе и передавал их 50% пользователей Chrome Beta 146. За время эксперимента мы успешно передали миллиарды MTC.

В случае TLS мы обнаружили, что при обычном сценарии всё работает достаточно эффективно: с сертификатом относительно контрольной точки при рукопожатии нужно передать лишь один открытый ключ, одну подпись и одно доказательство включения размером менее 1 КБ. Во время эксперимента, если нам не удавалось согласовать с клиентом сертификат относительно контрольной точки, мы использовали традиционную цепочку сертификатов вместо автономного сертификата. MTC также меняют масштабирование прозрачности на стороне CT: журналу достаточно хранить хеши открытых ключей, подписи для отдельных записей не нужны, а подпись заголовка дерева охватывает весь журнал. Это предотвращает лавинообразный рост числа сертификатов: журнал выпуска CA служит источником достоверных сведений обо всех выпущенных CA сертификатах, а потребителям журнала достаточно загружать по одной копии каждого сертификата.

Итог: MTC действительно работают! В медианном случае использование MTC с контрольными точками на 9% быстрее, чем классической цепочки подписей (справедливости ради, большая часть выигрыша в производительности обусловлена исключением промежуточных сертификатов). А поскольку мы тестировали MTC с классическими подписями, мы ожидаем ещё большего прироста при использовании постквантовых подписей. Удовлетворившись результатами и уровнем межотраслевого сотрудничества в рамках работы над MTC в рабочей группе PLANTS IETF, в прошлом месяце — августе 2026 года — мы начали сворачивать эксперимент.

Что ждёт MTC дальше

Мы рады, что эксперимент с Chrome показал: MTC можно использовать на практике. Особенно приятно, что теперь мы сможем выпускать сертификаты как настоящий CA.

Однако остаются более широкие вопросы, на которые можно ответить, только проведя этот масштабный эксперимент в рамках всей экосистемы PKI. Смогут ли независимые системы мониторинга получать и проверять журналы выпуска MTC при производственной нагрузке? Появится ли достаточно CA и со-подписантов, чтобы обеспечить необходимое для устойчивости разнообразие системы? Как браузерам найти баланс между преимуществами компактных MTC с контрольными точками и необходимостью предусмотреть запасные варианты для клиентов, у которых нет актуальных контрольных точек? MTC стали основополагающей архитектурой для постквантовой аутентификации, но для проверки их работоспособности в масштабах всего интернета потребуется участие самых разных программ корневых сертификатов, разработчиков браузеров, CA, зеркал, систем мониторинга и всего сообщества.

Мы считаем за честь принять участие в следующем этапе развития Web PKI и серьёзно относимся к ответственности за работу инфраструктуры CA. CA занимают привилегированное положение в экосистеме доверия: браузеры, владельцы доменов и обычные пользователи полагаются на них в проверке идентификаторов, защите ключей подписи, соблюдении правил и надёжной работе. Прежде чем браузеры смогут доверить CA Cloudflare выпуск MTC, нам предстоит подать заявку на включение в хранилище корневых сертификатов Chrome с квантовой устойчивостью и пройти строгую проверку. Мы приветствуем такой контроль и намерены соответствовать тем же высоким требованиям, что и любой другой CA, которому доверяют защиту интернета. Мы надеемся, что появятся и другие CA, готовые поддержать внедрение MTC, и будем рады сотрудничать с любым браузером, который захочет развернуть эту технологию.

© Cloudflare Blog