Миграция на постквантовую криптографию: разбор инженерных ловушек

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

С чем мы переходим: базис и сроки

Начнём с терминов, которые превратились в мантры. Постквантовые алгоритмы, это не алгоритмы для квантового компьютера. Это классические алгоритмы, которые устойчивы к атаке с его использованием. Грубо говоря, это математика, которую (предположительно) не взломает даже квантовый компьютер. Криптографическая гибкость (crypto-agility) — ключевой термин. Это способность системы заменить один криптографический алгоритм на другой без переписывания половины кода.

Сроки перехода условны, но не бесконечны. Регулятор ФСТЭК России пока не выпустил директивных указаний с конкретными датами, в отличие от западных NIST или BSI. Но это вопрос времени. Принятие новых национальных стандартов ГОСТ — процесс бюрократический и долгий, а миграция инфраструктуры — ещё дольше. Если начать после выхода стандарта, есть риск не успеть до появления реальной угрозы. Угроза «собрать сейчас и расшифровать позже» уже сегодня заставляет пересмотреть сроки хранения шифрованных данных. Если у вас есть архив, зашифрованный RSA-2048, который должен храниться 25 лет, то через 15 лет его могут расшифровать.

Архитектурные ловушки: где спрятан непереходимый код

Основная проблема — не в серверах. Мигрировать OpenSSL на новую библиотеку с PQ-алгоритмами — задача для системного администратора. Настоящая мина замедленного действия — встроенные системы и прошивки. Сетевое оборудование (маршрутизаторы, межсетевые экраны), HSM, смарт-карты, аппаратные ключи. Их микропрограммы часто пишутся один раз и забываются на десятилетия. Аппаратная реализация алгоритмов (например, ECC в чипе смарт-карты) физически не может быть заменена без замены самого устройства.

Второй слой — проприетарные протоколы и закрытые API. Старые СУБД со встроенным шифрованием, системы документооборота, промышленные SCADA. Разработчик может прекратить поддержку, а исходного кода для модификации нет. Эти системы становятся криптографическими чёрными дырами.

Третий, менее очевидный слой — юридический и организационный. Сертифицированные по старым требованиям ФСТЭК средства защиты информации (СЗИ). Замена алгоритма внутри сертифицированного VPN-шлюза автоматически аннулирует его сертификат. Значит, нужно проходить долгую и дорогую процедуру пересертификации. Это создаёт паралич: нельзя обновить, потому что нет сертификата, а сертификата нет, потому что не на чем тестировать обновление.

Стратегия 1: Криптографическая инвентаризация (Crypto-inventory)

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

Активное сканирование: Использование инструментов вроде testssl.sh или nmap с NSE-скриптами для анализа TLS-сервисов. Но это только верхушка айсберга.
Анализ трафика (пассивный): Захват и разбор сетевого трафика для выявления не-TLS протоколов, использующих собственные схемы шифрования (например, старые версии протоколов удалённого доступа).
Статический анализ кода и конфигураций: Поиск по кодовым базам, конфигурационным файлам (например, openssl.cnf, конфиги Apache/Nginx), Docker-образам на наличие хардкоженных алгоритмов (строки вроде ECDHE-RSA-AES256-GCM-SHA384).
Анализ зависимостей (SBOM): Составление реестра компонентов программного обеспечения (Software Bill of Materials) для всех используемых библиотек, особенно криптографических (OpenSSL, Bouncy Castle, libsodium).

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

Стратегия 2: Гибридные схемы — мост в никуда или страховка?

Самый популярный совет на ближайшие годы — использовать гибридные режимы. Например, TLS 1.3 с поддержкой kyber768 поверх классического ECDH. Или подписывать документ одновременно алгоритмом Ed25519 и алгоритмом на решётках Dilithium. Идея проста: если один из алгоритмов будет взломан (квантовым компьютером или математической атакой), второй останется.

Но гибридность, это не панацея, а компромисс с побочными эффектами:

Накладные расходы: Удваивается размер подписи и время на её верификацию. Увеличивается размер служебных данных при установлении сеанса (размер ключей KEM). Для интернет-трафика это приемлемо, для IoT-устройств с ограниченным каналом — критично.
Сложность реализации: Нужно корректно реализовать логику «и», а не «или». Ошибка в коде может сделать проверку подписи успешной, если сработал хоть один алгоритм, что сводит гибридность на нет.
Регуляторная неопределённость: Будет ли гибридная подпись считаться соответствующей требованиям 152-ФЗ, если один из её компонентов (классический) уже признан нестойким? Требует ли она двойной сертификации? Ответов пока нет.

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

Стратегия 3: Поэтапный переход и фазирование

Переход «big bang» — за одну ночь заменить всё — невозможен. Нужна фазировка, похожая на смену шин у движущегося поезда.

Фаза 0 (Подготовка): Создание криптографической карты, оценка рисков, выбор кандидатов PQ-алгоритмов (например, из набора стандартизируемых ГОСТ Р). Внедрение инструментов управления ключами (KMS), поддерживающих криптографическую гибкость.
Фаза 1 (Периметр и внешние коммуникации): Обновление внешних веб-сервисов, VPN-шлюзов, почтовых серверов. Внедрение гибридных режимов в TLS и протоколы подписи для документооборота. Это публичная часть, которая демонстрирует прогресс.
Фаза 2 (Внутренняя инфраструктура): Миграция внутренних сервисов, баз данных, систем аутентификации (например, переход с RSA на алгоритмы на решётках для SSH-ключей). Здесь можно экспериментировать с чисто постквантовыми режимами для непубличных каналов. [КОД: пример конфигурации OpenSSH сервера для поддержки post-quantum KEX]
Фаза 3 (Встроенные системы и легаси): Самый сложный этап. Для критичных встроенных систем — плановая замена железа. Для непереходимого легаси — изоляция в сегменте сети с контролируемым доступом и мониторингом всего исходящего от него трафика (криптографический карантин).

Практика: инструменты и первые шаги сегодня

Что можно сделать прямо сейчас, не дожидаясь новых ГОСТов?

Проанализировать и обновить цепочки TLS: Отключить устаревшие протоколы (SSLv3, TLS 1.0/1.1) и слабые шифры. Настроить серверы на приоритет ECDHE и современные AEAD-шифры. Это повысит криптографическую культуру и подготовит почву.
Экспериментировать с PQ-библиотеками: Интегрировать в тестовые стенды библиотеки вроде liboqs (Open Quantum Safe) или российские реализации кандидатов. Собрать и протестировать PQ-версии OpenSSL или сторонние TLS-библиотеки.
Начать диалог с вендорами: Запросить у поставщиков сетевого оборудования, СЗИ, HSM их дорожные карты по переходу на постквантовую криптографию. Отсутствие ответа — сам по себе фактор риска.
Внедрить управление криптографическими активами: Начать вести реестр криптоключей с пометкой об используемом алгоритме и сроке жизни. Создать политику, запрещающую выпуск новых долгосрочных ключей на алгоритмах RSA или ECC.

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