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

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

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

Для реализации нашей PQ-миграции мы поставили перед собой три ключевые цели.

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

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

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

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

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

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

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

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

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

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

Обращение к ИИ

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

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

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

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

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

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

Классификация

Примеры

Классическое шифрование

Это обобщающая категория, которая находит случаи использования эллиптической кривой обмена ключами Диффи-Хеллмана (ECDHE) (например, X25519, P-256, P-384), согласования ключей RSA или другого использования шифрования с открытым ключом (например, HPKE). Они взламываются квантовым компьютером с помощью алгоритма Шора, что подвергает их риску атак типа «собирай сейчас, расшифровывай потом».

Классическая подпись

Это обобщающая категория, которая находит использование подписи RSA или подписи на эллиптических кривых (ECDSA) в чем угодно, например, в сертификате, рукопожатии TLS или рукопожатии другого протокола. Эти подписи взламываются алгоритмом Шора.

Классический токен

Мы нашли много RS256 or ES256 JWT tokens, поэтому создали для них специальную классификацию. Это JWT, использующие классические подписи RSA и ECDSA; RFC 9964 определяет постквантовую замену с использованием ML-DSA.

Гибридный обмен ключами с поддержкой PQ

Находит гибридный постквантовый обмен ключами в TLS 1.3, т.е. X25519MLKEM768. Это наиболее распространенный случай использования PQ-шифрования в нашей кодовой базе.

Поддержка PQ

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

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

Вот (обрезанный) вид одного из наших отчетов:

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

Построено на платформе разработчиков Cloudflare

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

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

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

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

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

Workflow обнаружения (первый этап сканирования, который создает необработанные наблюдения)
Workflow глубокого анализа (второй этап, выполняемый для каждого необработанного наблюдения)
Workflow слияния (который создает список находок для данного репозитория, включая объединение повторяющихся или похожих находок)
Workflow публикации (который возвращает результаты Worker'у инвентаризации)

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

Вызов модели в масштабе

Если мы хотим просканировать все наши (многочисленные!) репозитории, нам нужно беспокоиться как о стоимости, так и о производительности.

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

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

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

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

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

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

Вот почему CryptoLabe использует концепцию «предварительных требований», чтобы выделить находки, которые не могут быть немедленно устранены отдельной продуктовой командой, работающей в одиночку.

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

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

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

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

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

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

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

Обмен нашими промптами

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

Обдумывание собственного перехода на PQ

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

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

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

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

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

Благодарности: многие сотрудники Cloudflare предоставили отзывы и внесли свой вклад в CryptoLabe, включая Давиде Маркеса, Питера Ву, Фила Шмидера, JP Aumasson, Эндрю Галлони, Кристофера Паттона, Люка Валенту, Мари Галисер, Ваню Гонсалвеш, а также команды Client, Tunnel и Gateway, которые проверяли отчеты, созданные этим инструментом.