Постквантова криптографія: як підготувати інфраструктуру до переходу на ML-KEM і ML-DSA

NIST уже стандартизував основні постквантові алгоритми: ML-KEM для встановлення спільного секрету, ML-DSA та SLH-DSA для цифрових підписів. Організаціям не потрібно чекати появи великого квантового комп’ютера, щоб почати підготовку. Найдовша частина переходу — не заміна бібліотеки, а пошук усіх місць, де RSA, Diffie–Hellman та еліптичні криві вбудовані в протоколи, пристрої, сертифікати й архіви даних.

Яку загрозу вирішує постквантова криптографія

Сучасна криптографія з відкритим ключем часто спирається на задачі факторизації або дискретного логарифма. Достатньо потужний квантовий комп’ютер із корекцією помилок теоретично зможе виконувати алгоритм Шора й руйнувати безпеку поширених схем RSA та ECC. Наявні квантові системи ще не мають потрібного масштабу, а точну дату його появи ніхто не знає.

Невизначеність не робить ризик нульовим. Дані можуть перехопити сьогодні та зберегти до часу, коли їх стане можливо розшифрувати. Такий сценарій називають harvest now, decrypt later. Він особливо важливий для медичних, державних, промислових і комерційних відомостей, конфіденційність яких має зберігатися багато років.

ML-KEM не є звичайним шифром

FIPS 203 визначає ML-KEM — механізм інкапсуляції ключів, похідний від CRYSTALS-Kyber. Його задача — дозволити двом сторонам встановити спільний секрет через відкритий канал. Далі симетричний алгоритм на кшталт AES захищає основний потік даних. Тому фраза «зашифрувати файл ML-KEM» технічно неточна.

ML-KEM має кілька наборів параметрів із різним балансом безпеки, розміру та продуктивності. Вибір повинен робити протокол або затверджений профіль, а не кожна команда довільно. Самостійне комбінування примітивів без специфікації створює ризик помилки навіть тоді, коли математичний алгоритм правильний.

Підписи потребують окремого переходу

FIPS 204 стандартизує ML-DSA, похідний від Dilithium, а FIPS 205 — хешовий підпис SLH-DSA, похідний від SPHINCS+. Вони вирішують задачу автентичності та цілісності, а не конфіденційності. Компанії повинні окремо інвентаризувати TLS-сертифікати, підпис коду, документів, оновлень прошивки, токенів і довготривалих архівів.

Розміри ключів і підписів відрізняються від традиційних схем. Це впливає на сертифікати, мережеві пакети, смарткарти, HSM, завантажувачі й протоколи з жорсткими лімітами. Успішний мікробенчмарк операції підпису не доводить, що весь виробничий шлях сумісний.

Почніть із криптографічного реєстру

Перший практичний артефакт — Cryptographic Bill of Materials або інший реєстр використання криптографії. Він повинен відповідати не лише на запитання «які бібліотеки встановлено», а й «де алгоритм використовується, для чого, з яким строком життя даних і хто контролює оновлення».

Шукайте TLS-термінацію, VPN, SSH, PKI, підпис контейнерів, мобільні застосунки, резервні копії, бази даних, платіжні модулі, IoT-пристрої та інтеграції партнерів. Частина криптографії прихована у керованих сервісах і мережевому обладнанні. Для них потрібні дорожні карти постачальників, а не припущення за назвою продукту.

Пріоритет визначає не тільки алгоритм

Однаковий RSA може мати різний ризик. Публічна маркетингова сторінка з короткочасним TLS-сеансом менш критична, ніж архів із десятирічною таємницею або кореневий ключ підпису прошивок. Пріоритет залежить від строку конфіденційності, вартості компрометації, складності заміни та ймовірності зберігання перехоплених даних.

Корисна матриця поєднує власника системи, алгоритм, розмір ключа, протокол, дані, зовнішню залежність, дату оновлення та доказ тестування. Без власника реєстр швидко застаріє. Без автоматичного виявлення він пропустить тіньові сервіси й нові залежності.

Навіщо потрібні гібридні схеми

Під час переходу протоколи можуть поєднувати класичний та постквантовий механізми, щоб секрет залишався захищеним, якщо принаймні один із компонентів безпечний і комбінацію побудовано правильно. Це зменшує ризик раннього переходу на новий алгоритм із невиявленою проблемою.

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

Криптографічна гнучкість має бути керованою

Crypto agility означає здатність замінити алгоритм і параметри без повного перепроєктування продукту. Це не довільний перемикач у конфігурації. Система повинна мати дозволений набір профілів, безпечні значення за замовчуванням, телеметрію фактичних домовленостей і процес відключення застарілого варіанта.

Версійність важлива для форматів даних і підписів. Якщо архів зберігається двадцять років, команда має знати, як перевірятиме старий підпис після зміни алгоритмів, сертифікатів та програмного забезпечення. Для довгострокової перевірки можуть знадобитися часові мітки, повторне підписання й збереження контексту довіри.

Пристрої та HSM можуть стати вузьким місцем

Оновити хмарну бібліотеку простіше, ніж мільйони контролерів без надійного механізму прошивки. Обмежена пам’ять, розмір пакета й швидкість процесора можуть ускладнити нові ключі та підписи. Якщо корінь довіри записано в незмінну область, архітектуру переходу потрібно закласти до виробництва наступної партії.

HSM і сертифіковані модулі також потребують підтримки алгоритмів, параметрів, резервного копіювання та політик доступу. Маркетингове «PQC ready» не замінює перевірку конкретної операції через ваш API, версію прошивки та режим відповідності.

Міграція не скасовує класичну безпеку

Постквантовий алгоритм не виправить викрадений адміністративний пароль, уразливий сервер або витік приватного ключа. Реалізації залишаються чутливими до побічних каналів, слабкої випадковості, помилок протоколу й ланцюга постачання. Потрібні ті самі рев’ю, оновлення, ізоляція ключів та реагування на інциденти.

Базові принципи пояснює стаття TechPulse про шифрування й керування ключами. Матеріал про Cyber Resilience Act показує, як інвентар компонентів і процес повідомлення про вразливості доповнюють криптографічну міграцію.

Реалістична послідовність переходу

1. Створіть і постійно оновлюйте реєстр криптографії.
2. Оцініть строк конфіденційності даних та критичність підписів.
3. Визначте системи, які неможливо швидко оновити.
4. Отримайте плани підтримки від постачальників і партнерів.
5. Проведіть лабораторні тести стандартизованих гібридних профілів.
6. Виміряйте розмір, затримку, пам’ять і сумісність наскрізного шляху.
7. Заплануйте поступове ввімкнення, телеметрію та відкат.
8. Документуйте залишковий ризик і дату повторного перегляду.

NIST орієнтує організації на початок міграції вже зараз і в проєкті переходу розглядає виведення квантово-вразливих алгоритмів зі стандартів до 2035 року, причому високоризикові системи потребують ранішої дії. Це горизонт для керованої програми, а не дата, до якої можна нічого не робити.

Першоджерела: проєкт постквантової криптографії NIST, FAQ про міграцію NCCoE та NIST IR 8547 про перехід.