Класифікація документа: Публічна технічна специфікація

Сфера: Криптографічна архітектура транспортного рівня

Політика перегляду: Оновлюється з еволюцією криптографічних стандартів

Формальний документ із безпеки

Постквантова сегментована
транспортна архітектура

Версія: 1.1

Автор: Stanislav Kurmanov

Статус: Розгортання в production

Тип: Архітектурна специфікація безпеки

Огляд архітектури

Рис. 1 — Сегментована постквантова транспортна анклава. Класична сумісність на краю; суворе застосування лише PQ всередині межі.

1.Термінологія та нормативна мова

Ключові слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT та MAY у цьому документі інтерпретуються як описано в RFC 2119.

Нормативні розділи

Обов'язкові архітектурні вимоги

Інформативні розділи

Обґрунтування рішень та операційні коментарі

2.Архітектурна класифікація

Тип архітектуриСегментована постквантова транспортна анклава

Модель розгортанняГібридний край сумісності + суворе PQ-ядро

Операційний статусProduction

3.Нормативні вимоги

3.1Транспортний протокол

3.1.1Публічний край

▸MUST підтримувати лише TLS 1.3
▸MUST NOT підтримувати TLS 1.2 або старіші
▸MUST NOT вмикати застарілі набори шифрів
▸MAY підтримувати класичні механізми обміну ключами для сумісності

Обґрунтування: обмеження поточного браузерного середовища виключають зовнішні кінцеві точки лише PQ.

3.1.2Внутрішній постквантовий сегмент

▸MUST працювати виключно на TLS 1.3
▸MUST застосовувати ML-KEM (mlkem768) як єдину дозволену групу обміну ключами
▸MUST NOT дозволяти X25519, P-256 або будь-яку класичну групу
▸MUST вимагати перевірку підпису на основі ML-DSA
▸MUST завершувати handshake при невідповідності групи
▸MUST завершувати handshake при невідповідності підпису
▸MUST завершувати handshake при спробі пониження протоколу

Гібридний відкат всередині PQ-анклави явно заборонено.

3.2Стійкість до пониження

Всередині PQ-анклави:

▸Класичного відкату обміну ключами MUST NOT існувати
▸Узгодження набору шифрів MUST NOT включати класичні альтернативи
▸Узгодження версії протоколу MUST відхиляти будь-яку версію, крім TLS 1.3
▸Збій handshake MUST логируватися та розглядатися як подія безпеки

3.3Криптографічна межа

Криптографічна межа SHALL визначається між Edge (nginx) та PQ Gate. Весь транспорт через цю межу MUST відповідати політиці застосування лише PQ.

4.Модель загроз (формалізована)

4.1 Зберегти-зараз-розшифрувати-пізніше

Можливості

•Пасивне перехоплення
•Архівування трафіку
•Майбутня спроба квантового дешифрування

Ціль пом'якшення

Внутрішній транспорт MUST захищатися ML-KEM для квантостійкої forward secrecy.

4.2 Активний атакуючий на пониження

Можливості

•Втручання в узгодження TLS
•Маніпуляція шифрами
•Підміна групи

Ціль пом'якшення

Спроби пониження MUST призводити до завершення handshake.

4.3 Внутрішній спостерігач мережі

Можливості

•Пасивне прослуховування
•Частковий доступ до мережі

Ціль пом'якшення

Весь міжкомпонентний трафік через межу MUST залишатися шифрованим під транспортом лише PQ.

5.Інформативний розділ — Обґрунтування рішень

5.1Чому сегментація замість повного PQ

Станом на 2026 основні браузери не підтримують ML-KEM, а компоненти екосистеми (БД, кеші, service mesh) не мають нативного PQ TLS. Повністю PQ зовнішня кінцева точка призвела б до повної втрати сумісності.

Операційне застосування PQ

Зворотна сумісність

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

Контрольований криптографічний перехід

6.Метрики продуктивності (спостережені)

Значення відображають виміряну поведінку в поточному розгортанні; оновлюються періодично.

6.1Накладені витрати handshake

~8–15 %

Збільшення затримки порівняно з X25519

~2–4×

Збільшення розміру сертифіката (ML-DSA vs ECDSA)

Не спостерігалося

Деградація сервісу під навантаженням

6.2Вплив на пропускну здатність

▸Продуктивність масової передачі не змінена (симетричний AES-GCM без змін)
▸Накладені витрати обмежені фазою handshake
▸Накладені витрати PQ-транспорту передбачені та амортизуються на постійних з’єднаннях

6.3Характеристики відмов

▸Явна відмова handshake при спробі класичної групи
▸Явна відмова при невідповідності алгоритму підпису
▸Тихого відкату не спостерігалося

7.Додаток криптографічної конфігурації

7.1Конфігурація внутрішнього PQ-сегмента

Увімкнено

ПротоколTLS 1.3

Група KEMmlkem768

Підписmldsa44

Набір шифрівTLS_AES_256_GCM_SHA384

Вимкнено

✕X25519

✕secp256r1

✕secp384r1

✕TLS 1.2

✕Усі застарілі шифри

7.2Підсумок конфігурації краю

Увімкнено

✓TLS 1.3

✓Строгі класичні групи

✓Сучасні AEAD набори шифрів

Вимкнено

✕TLS 1.2

✕Слабкі набори шифрів

✕Обмін ключами RSA

8.Стратегія міграції (формалізована)

Фаза 1ПОТОЧНА

Гібридний публічний край + сувора внутрішня PQ-анклава

Поточний операційний стан.

Фаза 2

Гібридна зовнішня підтримка

Коли браузери реалізують гібридний KEM:

Зовнішній край SHOULD увімкнути гібридний KEM.

Внутрішнє застосування PQ SHALL залишатися суворим.

Фаза 3

Опційна кінцева точка лише PQ

Коли браузерна екосистема стабілізується:

Зовнішню кінцеву точку лише PQ MAY може бути впроваджено.

Кінцеву точку сумісності MAY може залишатися тимчасово.

Фаза 4

Розширене впровадження PQ

Коли підтримується екосистемою:

Транспорт PQ сервіс-сервіс.

Підключення до БД з підтримкою PQ.

Service mesh з підтримкою PQ.

9.Принципи керування безпекою

Без перебільшених заяв про квантовий захист

Без тихих механізмів відкату

Без недокументованих гібридних винятків

Явна політика пониження

Явне визначення межі довіри

Вимірюване криптографічне застосування

10.Архітектурна позиційна заява

Ця система не претендує на повну постквантову інтернет-експозицію.

Вона працює як анклава постквантового транспорту в production, стійка до пониження, у зовнішній екосистемі, обмеженій сумісністю.

Архітектура відображає усвідомену стратегію криптографічного переходу, а не маркетингове вирівнювання.

Історія версій

1.1Нормативна формалізація та уточнення політики пониженняПОТОЧНА

1.0Початковий випуск

Завантажити

Той самий вміст, що й на цій сторінці, у форматі PDF.

PDF доступний лише англійською.