Использование ИИ для планирования нашего перехода на постквантовые технологии29.09.2026 16:00

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

Мы придерживаемся максимально широкого подхода («постквантовым должно быть всё!»): как поставщик инфраструктуры для всего мира, мы хотим дать клиентам уверенность в том, что использование Cloudflare защитит их трафик от квантовых атак в будущем.

Но как провести такую масштабную миграцию в организации наших размеров? Ведь криптография — фундамент почти всех цифровых систем в мире, в том числе программных сервисов и сетевых протоколов, на которых работает наша платформа.

Для перехода на постквантовую криптографию мы поставили перед собой три ключевые задачи.

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

Во-вторых, мы хотим отслеживать ход миграции. Например, можно подсчитывать по каждому репозиторию и продукту случаи использования классической и постквантовой криптографии.

Наконец, мы хотим заранее выявлять необходимые предварительные условия. Если наши продукты или платформа зависят от протоколов, для которых ещё нет плана перехода на постквантовую криптографию — потому что постквантовые варианты системы пока не рассматривались, стандарты ещё не разработаны или по ним нет консенсуса либо программные библиотеки и другие важные компоненты экосистемы пока не поддерживают постквантовую криптографию, — нам нужно знать об этом уже сейчас. Так мы сможем работать с заинтересованными сторонами, органами по стандартизации и участниками экосистемы, помогая им планировать переход на постквантовую криптографию и соблюдая собственный график миграции к 2029 году.

В этой статье мы расскажем, как решаем эти задачи. Мы объясним, как привлекли ИИ, чтобы справиться с некоторыми проблемами, и как разрабатываем внутренний инструмент CryptoLabe. Название CryptoLabe отсылает к морской астролябии — навигационному прибору, усовершенствованному португальскими мореплавателями. Как астролябия помогала морякам определять своё местоположение и прокладывать курс, так CryptoLabe помогает нам находить криптографию в коде, понимать, как она используется, и прокладывать путь к постквантовой миграции.

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

Масштаб проблемы

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

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

• общих библиотеках, подключённых к репозиторию, которые могут фактически использоваться, а могут и нет;
• настройках по умолчанию в вышестоящих системах и протоколах — например, слушателе TLS 1.3, настроенном на согласование классического обмена ключами, такого как X25519, вместо постквантового X25519MLKEM768;
• файлах конфигурации, где алгоритмы выбираются далеко от кода, который их использует, — например, если протоколы обмена ключами для TLS-ответчика заданы в YAML-файле из другого репозитория;
• участках кода, которые не используются, предназначены только для тестирования или готовятся к выводу из эксплуатации.

В-третьих, поиск криптографии — это не просто сопоставление с шаблонами. Поиск по коду названий алгоритмов (например, «RSA» или «X25519») даёт завышенные результаты, поскольку находит криптографические алгоритмы в неиспользуемом коде. Но он же может показать и заниженные результаты, поскольку не учитывает значения по умолчанию и косвенное использование в зависимостях и конфигурациях. И главное — такой поиск не объясняет, как именно применяется криптография. Классическая подпись ECDSA может использоваться в JWT, IPsec, TLS или SSH, и для каждого из этих протоколов нужен совершенно разный план миграции. Кроме того, многие случаи использования зависят от другой стороны соединения: TLS-сервер может поддерживать как постквантовый, так и классический обмен ключами, а выбор одного из них зависит от клиента.

Обращаемся к ИИ

Оказалось, что ИИ умеет гораздо больше, чем просто искать по коду. Модель может изучить кодовую базу, проследить за связями между файлами и выдать структурированный анализ. Она также может дополнить результаты информацией из других источников, например из нашей внутренней документации и систем учёта задач. Более того, ИИ способен объяснить, как используется криптография и что нужно обновить. Проверяя эту идею, мы разрабатываем CryptoLabe.

Как мы уже говорили, первые две наши задачи — (1) находить и понимать случаи применения криптографии в кодовой базе и (2) отслеживать показатели перехода на постквантовую криптографию. Для этого текущая версия CryptoLabe сканирует код в два этапа, как показано на схеме ниже.

На первом этапе — «поиске» — сначала составляется карта репозитория. Затем инструмент ищет криптографию в исходном коде, конфигурациях, манифестах, файлах блокировки зависимостей, скриптах, тестах и документации. Помимо прочего, сканирование выявляет применение криптографии для согласования ключей, создания подписей, асимметричного шифрования, инфраструктуры открытых ключей (PKI), токенов, учётных данных, интеграции с аппаратными модулями безопасности и многого другого. В результате этого этапа формируется набор «первичных наблюдений».

Для каждого первичного наблюдения запускается второй этап. На этапе «анализа» сначала повторно проверяется соответствие наблюдения исходному коду. Затем выясняется, как криптографическая операция используется во время выполнения, какую роль играет репозиторий и от каких внутренних или внешних сторон он зависит. При необходимости анализируется связанный код из других репозиториев. В заключение система перепроверяет собственные выводы и ищет недостающие или противоречащие им сведения — например, переопределения конфигурации, код, используемый только в тестах, или неверные предположения о поведении во время выполнения.

Затем модель присваивает результату классификацию. Если данных недостаточно, чтобы выбрать категорию, модель указывает »Нужны дополнительные данные»,»Внешняя зависимость» или »Неизвестно», а не пытается угадать.

Ниже приведён текущий список классификаций CryptoLabe. Он включает общие категории, которые, вероятно, будут уточняться по мере продвижения миграции. (Например, категорию «шифрование» можно разделить на согласование ключей и HPKE — смысл понятен.)

Наконец, система формирует отчёт для двух аудиторий: (1) менеджеров по продуктам, которым нужно понимать, что миграция означает для их продукта, и (2) инженеров, которым нужны подробности для её проведения.

Вот фрагмент одного из наших отчётов:

Мы постепенно проверяем результаты по исходному коду и вместе с соответствующими инженерами, однако у нас пока нет эталонного набора данных, который позволил бы воспроизводимо сравнивать разные версии запросов для CryptoLabe.

На платформе для разработчиков Cloudflare

Мы создали CryptoLabe на платформе для разработчиков Cloudflare. Вот как она устроена:

CryptoLabe работает на двух Workers Cloudflare: Worker-сканере, который запускает сканирование, и Worker-инвентаризации, который обслуживает панель управления, предоставляет API и хранит данные в базе D1. Они взаимодействуют через привязки сервисов. Сканирование начинается, когда пользователь запускает его через панель управления, а Worker-инвентаризации передаёт запрос сканеру.

Оркестрация сканирования

Нам нужен способ поддерживать сканирование в активном состоянии и контролировать его ход от начала до конца, не создавая собственную систему оркестрации задач. Для этого мы воспользовались Agents SDK. Для каждого репозитория создаётся постоянный координатор на основе Durable Object (DO). Очередь с ограниченной пропускной способностью перед координаторами регулирует количество одновременных сканирований. Когда доходит очередь репозитория, координатор отслеживает ход сканирования и обрабатывает его отмену, повторные попытки и восстановление.

Координатор не анализирует данные самостоятельно. Он передаёт эту работу в Cloudflare Workflows, чтобы они могли сохранять ход выполнения и автоматически повторять неудачные этапы. Координатор перемещает каждый репозиторий по четырём этапам:

1. Workflow поиска — первый этап сканирования, на котором формируются первичные наблюдения;
2. Workflow углублённого анализа — второй этап, запускаемый для каждого первичного наблюдения;
3. Workflow объединения — формирует список результатов для репозитория, в том числе объединяя повторяющиеся или похожие результаты;
4. Workflow публикации — передаёт результаты обратно Worker-инвентаризации.

Для первых двух Workflow модели нужен доступ к коду репозитория. Мы хотим изолировать этот доступ, чтобы не рисковать повредить кодовую базу. Поэтому в начале каждого сканирования CryptoLabe один раз загружает репозиторий на точном коммите и сохраняет этот снимок в R2. Затем каждый Workflow восстанавливает снимок в новой, недолговечной изолированной среде — Cloudflare Sandbox. Модель работает с ней через небольшой набор инструментов, доступных только для чтения, используя неизменяемый снимок кода, даже если кодовая база меняется во время сканирования.

Обращение к модели в больших масштабах

Чтобы просканировать все наши многочисленные репозитории, нужно учитывать как стоимость, так и пропускную способность.

Чтобы снизить затраты, цикл работы модели отправляет запросы через AI Gateway к экономичным моделям с открытыми весами, размещённым на Workers AI. Размещение модели за AI Gateway также упрощает переход на более качественные или дешёвые модели по мере их появления.

Когда мы начали одновременно сканировать множество репозиториев, возникла проблема с пропускной способностью. Резкие всплески запросов к модели стали вызывать от AI Gateway ответы HTTP 429 (превышение лимита запросов), а независимые повторные попытки при сканировании лишь усугубляли ситуацию. Мы решили эту проблему с помощью одного глобального Durable Object, который регулирует все запросы к модели во время всех сканирований, включая повторные попытки. Если при сканировании достигается лимит запросов, период ожидания применяется ко всем задачам: все они одновременно замедляются. Благодаря этому параллельные сканирования совместно используют доступную пропускную способность, а не конкурируют за неё.

Предварительные условия и сложные случаи

Теперь перейдём к третьей задаче — заблаговременно выявлять предварительные условия и сложные случаи.

О готовности экосистемы к переходу на постквантовую криптографию написано уже немало, но мы добавим к этому ещё несколько слов. Как известно, такой переход не происходит в вакууме. Чтобы миграция прошла успешно, постквантовая криптография должна поддерживаться в нужных программных библиотеках (например, BoringSSL) и всеми участниками экосистемы (например, клиентами, браузерами, серверами-источниками, облачными прокси, центрами сертификации и т. д.). Стандарты также служат важным показателем поддержки экосистемы, хотя статус «черновик» сам по себе не означает, что внедрение невозможно. Например, мы внедрили X25519MLKEM768 в TLS 1.3 ещё в 2022 году, когда этот алгоритм оставался «черновиком» в Инженерном совете Интернета (IETF), а окончательно стандарт был утверждён только в 2026 году как RFC 10024.

В любом случае для перехода системы на постквантовую криптографию нам необходимо понимать её зависимости и уровень поддержки в экосистеме.

Поэтому в CryptoLabe мы используем понятие «предварительные условия», чтобы выделять результаты, которые отдельная команда продукта не может устранить самостоятельно и немедленно.

Предварительное условие может быть сформулировано просто: «Переход на постквантовые JWT пока заблокирован». Это простой пример, потому что для постквантовых JWT уже существует стандарт — RFC 9964. Однако если наши программные библиотеки пока не умеют проверять постквантовые JWT или мы используем издателя токенов, который ещё не выпускает такие JWT, нельзя обратиться ко всем командам компании и попросить их начать переводить JWT на постквантовую криптографию. Миграция будет заблокирована, пока мы не устраним её ключевые предварительные условия. CryptoLabe позволяет группировать результаты, для которых, вероятно, требуется одно и то же предварительное условие, — это также помогает определить, какие из них следует устранять в первую очередь.

Например, на снимке ниже показаны шесть результатов CryptoLabe, для которых предварительным условием является постквантовый SAML. (SAML — это протокол единого входа (SSO)).

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

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

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

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

Главное — разные подходы позволяют найти разные вещи, и каждый результат всё равно должны проверять инженеры, которые понимают, как система работает на самом деле.

Делимся нашими запросами

Последние несколько месяцев мы экспериментировали и искали оптимальный способ составлять запросы для CryptoLabe. У нас пока нет эталонного набора данных, который позволил бы сравнить эффективность разных запросов, и мы не уверены, что охватили абсолютно все случаи применения криптографии в нашей кодовой базе. Вместо этого мы совершенствовали запросы, запуская сканирование, обсуждая результаты с инженерами, которые поддерживают репозитории, изучая пропуски, выявленные в ходе проверки, и внося изменения. Тем не менее мы решили опубликовать некоторые запросы, чтобы другие команды могли изучить и адаптировать наш подход. Это отправные точки, а не самостоятельная версия CryptoLabe; качество результатов зависит от доступных моделей, инструментов, контекста и инженерной проверки.

Как продумать собственный переход на постквантовую криптографию

В Cloudflare мы используем максимально широкий подход к переходу на постквантовую криптографию, поскольку стремимся предоставлять её клиентам и всему Интернету. Но большинству организаций не нужно начинать с поиска каждого случая применения криптографии во всех репозиториях всех продуктов. Более того, большинству организаций не следует так поступать: на данном этапе это пустая трата ценных ресурсов.

Прежде чем сканировать хотя бы один репозиторий, по возможности защитите трафик сразу во всех системах. Если ваши сайты работают через Cloudflare, мы уже сегодня защищаем данные при передаче с помощью постквантового шифрования; проверить это можно благодаря нашим новым функциям для контроля постквантовой защиты. Наша SASE-платформа Cloudflare One обеспечивает постквантовое шифрование трафика частной сети. Постквантовое шифрование предоставляется без дополнительной платы, и для его использования не нужно обновлять каждый сервер-источник или каждое частное приложение в корпоративной сети. Это компенсирующая мера защиты, которая позволит вам изучить и понять, как криптография используется в ваших системах.

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

1. Выберите репозиторий одной важной системы. Начните с системы, которая обрабатывает конфиденциальные или долго хранящиеся данные, проверяет подлинность пользователей или программного обеспечения либо доступна из общедоступного Интернета.
2. Найдите случаи применения криптографии в этом репозитории. Надеемся, наше описание CryptoLabe поможет вам в этом!
3. Проверьте результаты. Попросите команду, отвечающую за систему, проверить результаты поиска и подтвердить, что обнаруженная криптография будет нужна в долгосрочной перспективе и её необходимо перевести на постквантовые алгоритмы. Важно помнить, что такой переход может быть не нужен немедленно, если уже действует другая компенсирующая мера защиты.
4. Определите приоритеты. Выясните, что можно обновить уже сейчас, а что пока заблокировано. Зафиксируйте общие предварительные условия, для выполнения которых нужна помощь разработчиков библиотек, поставщиков, групп по стандартизации или других подразделений вашей организации. Расставьте приоритеты и составьте план, в первую очередь охватывающий наиболее важные системы и предварительные условия.

Так вы сможете наметить план перехода на постквантовую криптографию, не составляя полную карту каждой криптографической операции в организации. CryptoLabe продолжает развиваться, но его сканирование и результаты уже помогли нам спланировать миграцию. Надеемся, наш опыт пригодится вам в ходе собственного перехода на постквантовую криптографию.

Благодарности: Многие сотрудники Cloudflare помогали CryptoLabe и делились отзывами о нём, в том числе Davide Marquês, Peter Wu, Phil Schmieder, JP Aumasson, Andrew Galloni, Christopher Patton, Luke Valenta, Mari Galicer, Vânia Gonçalves, а также команды Client, Tunnel и Gateway, проверявшие отчёты, сформированные инструментом.

© Cloudflare Blog