У вересні 2022 року Директорат з кібербезпеки NSA опублікував Комерційний набір алгоритмів національної безпеки 2.0 (CNSA 2.0) — директиву, що зобов'язує всі Національні системи безпеки перейти від класичної криптографії з відкритим ключем до постквантових алгоритмів за визначеним графіком. Для оборонних організацій це не дослідницьке питання і не пункт майбутнього планування: вимоги до закупівель вже включають критерії готовності до CNSA 2.0, а нові системи, розгорнуті з 2025 року, мають підтримувати обов'язкові алгоритми з першого дня.

Завдання міграції є суттєвим. Класична криптографія з відкритим ключем — RSA, еліптична криптографія (ECC) і Diffie-Hellman — вбудована у всю оборонну ІТ-інфраструктуру: TLS-ендпоінти, VPN-шлюзи, центри сертифікації PKI, системи управління ключами, конвеєри підписання прошивок та зашифровані архіви даних. Заміна цих залежностей у великій організації — це багаторічна програма, що потребує ретельного послідовного виконання, координації з постачальниками та управління ризиками в період, коли класичні та постквантові системи повинні взаємодіяти.

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

Що вимагає CNSA 2.0 і чому

Криптографічна загроза, що стоїть за CNSA 2.0, — це алгоритм Шора: квантовий алгоритм, який при запуску на достатньо великому квантовому комп'ютері зламує математичні задачі, що лежать в основі RSA (розкладання на множники), ECC (дискретний логарифм на еліптичній кривій) та Diffie-Hellman (дискретний логарифм). Квантовий комп'ютер, здатний запустити алгоритм Шора проти 2048-бітного RSA або 256-бітного ECC, вимагатиме мільйонів логічних кубітів з низьким рівнем помилок. Такої можливості сьогодні не існує, але достовірні публічні оцінки розміщують «криптографічно значущий квантовий комп'ютер» (CRQC) десь у вікні 2030–2035 років.

Загроза «збери зараз — розшифруй пізніше» (HNDL) скорочує цей часовий горизонт для оборонних цілей. Супротивники, що збирають зашифрований трафік сьогодні — стратегічні комунікації, розвідувальні звіти, оцінки можливостей — можуть зберігати його і розшифровувати, як тільки стане доступним CRQC. Таким чином, конфіденційність даних, зашифрованих сьогодні класичними алгоритмами, має ефективну дату закінчення, пов'язану з доступністю CRQC. Для даних із вимогами до конфіденційності, що вимірюються десятиліттями, ця дата закінчення вже є поточним операційним занепокоєнням.

CNSA 2.0 вирішує це, встановлюючи конкретний набір постквантових алгоритмів для NSS з графіком переходу, розробленим для забезпечення завершення міграції до появи CRQC. Ключові вимоги:

  • ML-KEM (FIPS 203 / CRYSTALS-Kyber) — замінює RSA і ECDH для встановлення всіх ключів. CNSA 2.0 вимагає ML-KEM-1024 (набір параметрів найвищої безпеки) для застосувань NSS.
  • ML-DSA (FIPS 204 / CRYSTALS-Dilithium) — замінює RSA-PSS та ECDSA для цифрових підписів у більшості застосувань. Забезпечує швидке підписання та верифікацію при прийнятних розмірах ключів і підписів.
  • SLH-DSA (FIPS 205 / SPHINCS+) — альтернативний алгоритм підпису на основі хеш-функцій, а не решітчастої математики. Використовується там, де потрібна різноманітність щодо алгоритмів на основі решіток, або де такі алгоритми не дозволені. Підписи значно більші, ніж у ML-DSA, але безпека базується на добре зрозумілих властивостях хеш-функцій.
  • LMS та XMSS — схеми підпису на основі хеш-функцій зі збереженням стану, затверджені для конкретних випадків використання, зокрема підписання прошивок у обмежених середовищах. Вимагають ретельного управління станом для уникнення повторного використання ключів.
  • AES-256 і SHA-384 — збережені з CNSA 1.0 для симетричного шифрування та хешування; вони не є вразливими до квантових комп'ютерів у практичному масштабі.

Застарілі алгоритми, які повинні бути поступово виведені з обігу відповідно до CNSA 2.0, включають: RSA (усі розміри ключів, усі застосування), ECDH і ECDSA (усі криві), Diffie-Hellman (класичний і на еліптичних кривих) та SHA-256 для застосувань NSS (де тепер вимагається SHA-384). AES-128 і AES-192 також виводяться на користь AES-256 для NSS.

Ключовий висновок: Багато ІТ-команд оборонного сектору зосереджуються на дедлайні 2030 року для міграції існуючих систем і не беруть до уваги вимогу 2025 року для нових систем. Від програмного продукту або платформи, що поставляється замовнику DoD після січня 2025 року, очікується підтримка алгоритмів CNSA 2.0. Продукти, побудовані на криптографічних бібліотеках тільки для класичних алгоритмів, не пройдуть перевірку відповідності CNSA 2.0 в момент поставки, а не в момент матеріалізації квантової загрози.

Затверджені алгоритми докладно

ML-KEM (механізм інкапсуляції ключів на основі модульних решіток) базується на складності задачі Module Learning With Errors (MLWE) — решітчастої задачі, яку жоден відомий квантовий або класичний алгоритм не вирішує ефективно. ML-KEM працює як механізм інкапсуляції ключів: відправник інкапсулює спільний секрет під відкритим ключем одержувача; одержувач деінкапсулює для відновлення спільного секрету. Спільний секрет потім служить основою для функції виведення симетричного ключа. ML-KEM-1024 генерує відкриті ключі розміром 1 568 байт, шифротексти 1 568 байт і спільні секрети 32 байти — більші, ніж ключі RSA-2048 (256 байт), але прийнятні для більшості контекстів протоколів.

ML-DSA (алгоритм цифрового підпису на основі модульних решіток) базується на складності задач Module Short Integer Solution (MSIS) та MLWE. ML-DSA-87 (найвищий рівень безпеки, що відповідає безпеці AES-256) генерує відкриті ключі розміром 2 592 байти і підписи 4 627 байт. Для порівняння, ECDSA P-256 генерує підписи 64 байти. Більші розміри підписів вимагають коригування в протоколах і системах зберігання, що передбачали компактні підписи — ланцюжки сертифікатів, образи прошивок і канали з обмеженою пропускною здатністю потребують планування ємності.

SLH-DSA (алгоритм цифрового підпису на основі хеш-функцій без збереження стану) не має алгебраїчної структури, яку могли б експлуатувати ні класичні, ні квантові алгоритми, крім загальних атак на хеш-функції; його безпека повністю зводиться до стійкості до колізій базової хеш-функції. Компромісом є продуктивність і розмір: підписи SLH-DSA-SHA2-256s становлять 29 792 байти при найменшому наборі параметрів, а підписання на порядки повільніше, ніж у ML-DSA. SLH-DSA підходить як допоміжний алгоритм підпису для забезпечення різноманітності безпеки, особливо для підписання прошивок і програмного забезпечення, де розмір підпису та частота підписання є керованими.

Чотири фази міграції

Добре структурована міграція на CNSA 2.0 проходить через чотири фази. Організації можуть перебувати на різних фазах одночасно для різних типів систем — велика оборонна організація зазвичай матиме міграцію PKI на Фазі 2, поки тактичні крайові системи ще перебувають на Фазі 1.

Фаза 1 — Криптографічна інвентаризація. Перш ніж можна буде спланувати будь-яку міграційну роботу, організація повинна знати, що вона має. Криптографічна інвентаризація охоплює: кожен TLS-ендпоінт і його узгоджені набори шифрів; кожен сертифікат в обігу (користувача, пристрою, сервісу, підписання коду) та його алгоритм ключа і термін дії; кожен VPN-шлюз та його конфігурацію обміну ключами IKEv2; кожну систему управління ключами, HSM і криптографічний токен; кожен конвеєр підписання прошивок та тип ключа підписання; і кожен архів даних, де потрібна довгострокова конфіденційність і алгоритм ключа шифрування.

Автоматизовані інструменти допомагають — TLS-сканери (SSLyze, testssl.sh), SBOM-аналіз криптографічних залежностей бібліотек і платформи управління сертифікатами зі звітністю про алгоритми. Але автоматизовані інструменти пропускають власні реалізації протоколів, вбудовану криптографію прошивок і криптографію прикладного рівня поза стандартними бібліотеками. Для повноти необхідний ручний огляд архітектурної документації та вихідного коду.

Фаза 2 — Пріоритизація на основі ризиків. Не всі криптографічні залежності несуть однаковий ризик HNDL. Пріоритизація повинна відображати два виміри: тривалість і чутливість захищених даних та можливість міграції в найближчій перспективі. Пріоритетними цілями є системи, що захищають довговічні секретні дані, де вразливість до HNDL є найвищою: кореневі та видавальні CA PKI (чиї ключі захищають якір довіри для всієї організації), інфраструктура управління ключами (HSM, що зберігають майстер-ключі для зашифрованих архівів), стратегічні канали зв'язку та будь-яка система, що шифрує дані з вимогою конфіденційності, що перевищує п'ять років.

Нижчий пріоритет — але все ще обов'язковий до 2030 року — мають системи з частими циклами оновлення обладнання (тактичні платформи, кінцеві пристрої користувачів), де можливості PQC можна включити при наступному природному оновленні, та внутрішні системи, що захищають несекретні дані, де квантовий ризик нижчий.

Фаза 3 — Гібридна робота. Під час міграції системи взаємодіятимуть як із аналогами CNSA 1.0 (класичними), так і з аналогами CNSA 2.0 (постквантовими). Гібридна криптографія — поєднання класичних і постквантових алгоритмів в одному протокольному обміні — забезпечує квантовий захист поточного трафіку без вимоги до всіх ендпоінтів одночасно підтримувати постквантові алгоритми.

При гібридному TLS 1.3-з'єднанні клієнт включає в ClientHello і обмін ключами ECDHE, і обмін ключами ML-KEM; сервер відповідає обома. Фінальний сесійний ключ отримується з обох спільних секретів за допомогою функції виведення ключа. Зловмисник повинен зламати і класичний, і постквантовий алгоритми, щоб скомпрометувати сесію. Цей підхід «ременів і підтяжок» явно схвалений NSA для перехідного періоду.

Ключовий висновок: Гібридна робота — це не просто перехідна зручність; це дисципліна управління ризиками. Поки постквантові алгоритми не накопичать роки криптоаналітичного вивчення, порівнянного з RSA і ECC, їх паралельний запуск з класичними алгоритмами гарантує, що непередбачений криптоаналітичний прогрес проти решітчастої математики не скомпрометує одразу всі захищені комунікації.

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

Пріоритетні системи та послідовність міграції

У пріоритизованому беклозі міграції певні типи систем стабільно з'являються як пріоритетні практично для всіх оборонних організацій і повинні бути розміщені на початку черги незалежно від організаційної специфіки.

Інфраструктура управління ключами. HSM та служби управління ключами (KMS) є залежностями для міграції майже кожної іншої системи — постквантові ключі повинні десь генеруватися, зберігатися та управлятися. Оновлення прошивки HSM для підтримки операцій ML-KEM і ML-DSA та перевірка того, що API управління ключами надають постквантові типи ключів споживаючим застосункам, є роботою Фаз 1–2 у кожній програмі міграції. Це також місце, де взаємодія з постачальниками є найбільш критичною: постачальники HSM суттєво різняться в своїх дорожніх картах PQC, і деякі апаратні покоління не можуть бути оновлені на місці.

Кореневі та видавальні CA PKI. Ієрархія довіри PKI лежить в основі автентифікації на основі сертифікатів у всій організації. Встановлення постквантових кореневих CA — і розповсюдження їхніх якорів довіри всім залежним сторонам (браузерам, операційним системам, TLS-клієнтам, валідаторам OCSP) — є передумовою для видачі постквантових сертифікатів будь-якій системі. Це повинно відбутися до того, як постквантові сертифікати можна буде розгорнути де-небудь ще. Модель подвійної видачі, де той самий CA видає і класичні, і постквантові сертифікати для кожного суб'єкта, дозволяє поступову міграцію залежних сторін без порушення існуючих відносин довіри.

VPN-шлюзи та зашифровані комунікаційні платформи. VPN-шлюзи, що захищають периметри секретних мереж, є першочерговими цілями HNDL. IKEv2, протокол обміну ключами, що використовується в більшості корпоративних VPN-рішень, повинен бути оновлений для узгодження ML-KEM при встановленні ключів та ML-DSA для автентифікації. Більшість корпоративних постачальників VPN (Cisco, Palo Alto, Juniper, Check Point) мають пункти дорожньої карти PQC, але доступність функцій і відповідність параметрам CNSA 2.0 суттєво варіюються — це критичне питання кваліфікації постачальника при закупівлях.

Зашифровані комунікаційні та месенджерські платформи. Системи, що використовуються для стратегічного командного зв'язку, розповсюдження розвідки та координації виконання місій, є пріоритетними цілями через високу чутливість і тривалість трафіку. Corvus.Quantum, стримінгова платформа Corvus Intelligence для оборони, розроблена для відповідності CNSA 2.0 — включає ML-KEM для встановлення ключів і ML-DSA для підписання повідомлень у своїй стримінговій та месенджерській архітектурі, підтримуючи гібридну роботу в перехідний період.

Конвеєри підписання прошивок. Системи озброєння та апаратні платформи збройних сил використовують цифрові підписи для верифікації цілісності прошивок. Ці підписи є довготривалими — ключ підписання може охоплювати весь виробничий термін платформи, що триває десятиліття і більше — і тому безпосередньо піддаються ризику HNDL. Нові платформи, що надходять у виробництво, повинні поставлятися з підписанням прошивок ML-DSA або SLH-DSA з першої поставки. Платформи у строю потребують кампанії повторного підписання образів прошивок там, де архітектура завантаження підтримує ротацію ключів; платформи, де ключі підписання вплавлені при виробництві, вимагають явної документації ризиків.

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

Як інвентаризувати криптографічні залежності

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

Комплексна стратегія інвентаризації поєднує чотири підходи. По-перше, виявлення на мережевому рівні: пасивний аналіз TLS-трафіку та активне сканування всіх доступних ендпоінтів з використанням інструментів, що відбирають узгоджені набори шифрів і алгоритми ключів сертифікатів. Це охоплює веб-сервери, API-ендпоінти, балансувальники навантаження і сервісно-мережеві комунікації, що використовують стандартний TLS. По-друге, перерахування платформ управління сертифікатами: запит до ієрархії CA організації та будь-яких публічних журналів Certificate Transparency (CT) для сертифікатів, що містять назви організації, з витягуванням алгоритму ключа і терміну дії для кожного. По-третє, SBOM-аналіз: витягування специфікацій програмного забезпечення (Software Bill of Materials) з розгорнутих застосунків і сканування криптографічних залежностей бібліотек (OpenSSL, BoringSSL, libgcrypt, NSS, постачальники Java-криптографії) та їхніх версій. Версії криптографічних бібліотек визначають, які алгоритми доступні і які є стандартними. По-четверте, огляд архітектурної документації: ідентифікація власних реалізацій протоколів, внутрішньопроцесного виведення ключів, зашифрованих стовпців баз даних і криптографії прикладного рівня, яку мережеве сканування не може спостерігати.

Результатом інвентаризації повинен бути структурований реєстр з як мінімум: назвою системи, типом криптографічної залежності (TLS, сертифікат, KEM, підпис, симетричний), алгоритмом і розміром ключа, бібліотекою або реалізацією, класифікацією даних захищених даних та оцінкою складності міграції. Цей реєстр є основою для пріоритизації Фази 2 та забезпечує базовий рівень для відстеження прогресу відповідності.

Питання постачальникам при закупівлях

Оборонні організації, що закуповують комерційне програмне забезпечення та обладнання, повинні оцінювати готовність до CNSA 2.0 як частину закупівель. Наступні питання дозволяють відрізнити постачальників із реальними можливостями PQC від тих, хто обмежується обіцянками дорожньої карти:

Специфіка підтримки алгоритмів. «Чи підтримує ваш продукт ML-KEM-1024, ML-DSA-87 і SLH-DSA-SHA2-256s відповідно до FIPS 203, 204 і 205?» Постачальники, які відповідають загальними заявами про «підтримку постквантових алгоритмів» без конкретних позначень FIPS і рівнів параметрів, навряд чи відповідатимуть конкретним вимогам CNSA 2.0. Підтримка алгоритмів на нижчих рівнях параметрів (ML-KEM-512, ML-DSA-44) не задовольняє рівні безпеки NSS, встановлені CNSA 2.0.

Доступність гібридних наборів шифрів. «Чи підтримує ваша реалізація TLS гібридний обмін ключами ML-KEM + ECDHE в одному рукостисканні?» Підтримка гібридних режимів дозволяє організації починати отримувати вигоду від квантового захисту наявного трафіку без вимоги до всіх взаємодіючих сторін одночасно завершити міграцію на PQC.

Адаптація до розмірів ключів. «Як ваша система обробляє більші розміри ключів і підписів постквантових алгоритмів?» Підписи ML-DSA-87 становлять приблизно 4,6 КБ порівняно з 64 байтами ECDSA P-256. Системи з буферами фіксованого розміру для сертифікатів або підписів, схемами баз даних із фіксованою довжиною криптографічних полів або мережевими протоколами зі суворими обмеженнями MTU можуть потребувати архітектурних змін для розміщення матеріалу ключів PQC.

Походження криптографічної бібліотеки. «Яка криптографічна бібліотека лежить в основі вашої реалізації PQC, і яка частота оновлень версій?» Реалізації постквантових алгоритмів в OpenSSL, BoringSSL і Bouncy Castle ще дозрівають; частота оновлень постачальника визначає, наскільки швидко виправлення безпеки досягають розгорнутих продуктів.

Дорожня карта після 2030 року. «Який ваш план для чистої PQC-роботи після 2030 року, коли гібридний режим і класичні алгоритми будуть виведені з обігу?» Постачальники без конкретної дорожньої карти після 2030 року становлять ризик відповідності, що вимагатиме керованих переходів у найгірший момент — коли дедлайн є неминучим.

Шестиетапний процес планування міграції на CNSA 2.0

Наступні кроки дистилюють вищезазначені фази міграції в послідовність дієвого планування для ІТ-команд і команд з безпеки оборонних організацій, що починають програму відповідності CNSA 2.0.

Крок 1 — Проведіть криптографічну інвентаризацію. Розгорніть TLS-сканування, звіти платформ управління сертифікатами, SBOM-аналіз і огляд архітектурної документації для всіх систем. Складіть структурований реєстр кожної криптографічної залежності: тип, алгоритм, розмір ключа, бібліотека, класифікація даних та оцінка складності міграції. Очікуйте, що цей крок займе 2–6 місяців для середньо-великої оборонної організації. Не переходьте до планування без достатньо повної інвентаризації — плани міграції, побудовані на частковій інвентаризації, пропустять пріоритетні системи.

Крок 2 — Оцініть ризики та визначте пріоритети систем. Оцінюйте кожен пункт інвентаризації за двома осями: ризик HNDL (чутливість і тривалість захищених даних) та можливість міграції (можливості команди, готовність постачальника, архітектурна складність). Складіть пріоритизований беклог міграції з оцінкою трудомісткості, залежностями між пунктами та призначенням відповідальних. Пункти, що захищають довговічні секретні дані з низькою складністю міграції, повинні бути на першому місці незалежно від організаційних пріоритетів.

Крок 3 — Спочатку оновіть інфраструктуру управління ключами та PKI. Мігруйте HSM на прошивку з підтримкою CNSA 2.0. Видайте постквантові кореневі сертифікати CA. Встановіть можливість подвійної видачі. Розповсюдьте оновлені якорі довіри залежним сторонам. Цей крок є залежністю для всіх наступних міграцій на основі сертифікатів і повинен бути забезпечений ресурсами та розпочатий одразу після завершення інвентаризації.

Крок 4 — Розгорніть гібридні набори шифрів на пріоритетних мережевих шляхах. Увімкніть гібридні набори шифрів ML-KEM на VPN-шлюзах, секретних мережевих периметрах і комунікаційних платформах. Цей крок забезпечує негайне зниження ризику HNDL для поточного трафіку без вимоги повної готовності до PQC для всіх ендпоінтів. Відстежуйте частоту узгодження для відстеження прийняття.

Крок 5 — Мігруйте підписання прошивок і ланцюжок постачання ПЗ. Переведіть конвеєри підписання прошивок на ключі ML-DSA або SLH-DSA для всіх платформ, що надходять у виробництво. Проводьте кампанії повторного підписання для платформ у строю там, де це архітектурно можливо. Оновіть конвеєри підписання коду в CI/CD. Задокументуйте обмежені платформи як керований криптографічний технічний борг з явним прийняттям ризику.

Крок 6 — Виконайте повний перехід та виведіть класичні алгоритми з обігу. Після того, як усі пріоритетні системи підтримуватимуть постквантові алгоритми і гібридна робота буде стабільною, починайте виведення класичних наборів шифрів і типів сертифікатів за скоординованим графіком з взаємодіючими організаціями. Встановіть панель відповідності. Цільовий повний вивід класичних алгоритмів до 2030 року відповідно до настанов NSA.

Для глибшого розгляду базових постквантових алгоритмів та їхніх оборонних наслідків дивіться Постквантова криптографія для оборони: посібник CNSA 2.0. Для ознайомлення з інфраструктурою управління ключами та секретами, що лежить в основі міграції на PQC, дивіться Управління секретами в оборонних CI/CD-конвеєрах: Vault, HSM і ротація ключів. Для ознайомлення з архітектурою нульової довіри як додатковим рівнем безпеки дивіться Архітектура нульової довіри для військових мереж: принципи та реалізація.