Шифрування даних під час передачі — вирішена проблема, доки у зловмисника немає квантового комп'ютера. Симетричні шифри на кшталт AES-256 витримують квантову загрозу. RSA та обмін ключами на еліптичних кривих — ні: алгоритм Шора, запущений на достатньо великому відмовостійкому квантовому процесорі, розкладає ключі RSA та вирішує задачу дискретного логарифмування за поліноміальний час, роблячи будь-який сесійний ключ, узгоджений за допомогою класичної криптографії з відкритим ключем, ретроспективно читабельним. Практична загроза — це не майбутня атака, а нинішня: зловмисники перехоплюють і зберігають зашифрований оборонний трафік сьогодні, розраховуючи на те, що квантове обладнання врешті-решт дозволить його розшифрувати. Атака «перехопи зараз — розшифруй пізніше» не має захисту, окрім постквантової криптографії, застосованої в точці початкового обміну ключами.
Corvus.Quantum — це квантово-стійка стримінгова платформа, побудована для засекречених оборонних комунікацій. Вона поєднує розподілену стримінгову основу Apache Kafka з постквантовою криптографією на основі ґраток — зокрема NTRUEncrypt та CRYSTALS-Kyber — і накладає повну архітектуру Zero Trust на всю топологію. У цій статті розбирається, як взаємодіють ці компоненти, як працює механізм подвійного розподілу ключів і як команда оборонних інженерів інтегрує Python SDK в існуючий стримінговий конвеєр.
Чому криптографія на основі ґраток
Постквантова криптографія охоплює декілька сімейств алгоритмів: на основі ґраток, на основі хешів, на основі кодів та на основі ізогеній. Corvus.Quantum використовує алгоритми на основі ґраток, оскільки вони забезпечують найкращий компроміс між продуктивністю та безпекою для навантажень стримінгу з високою пропускною здатністю. Базова важка задача — задача найкоротшого вектора (SVP) та задача навчання з помилками (LWE) — не має відомого поліноміального квантового алгоритму. NIST завершив процес стандартизації постквантової криптографії у 2024 році, обравши CRYSTALS-Kyber (нині стандартизований як ML-KEM відповідно до FIPS 203) як основний механізм інкапсуляції ключів. NTRUEncrypt, більш давня система на основі ґраток, зберігається як вторинний алгоритм для інкапсуляції ключів у сценаріях, де потрібні альтернативи FIPS 203.
Процес інкапсуляції ключів у Corvus.Quantum працює так: вузол-продюсер генерує ефемерну пару ключів ML-KEM для кожної сесії. Він надсилає відкритий ключ (ключ інкапсуляції) на сервер керування ключами через канал, захищений QKD або mTLS. Сервер інкапсулює симетричне початкове значення сесії за допомогою відкритого ключа та повертає шифротекст. Обидві сторони виводять ідентичний сесійний ключ AES-256 із початкового значення за допомогою HKDF. Цей сесійний ключ шифрує корисне навантаження повідомлення Kafka — класичний алгоритм Діффі-Хеллмана або RSA не задіяний жодного разу під час узгодження ключів.
Ключовий висновок: Інкапсуляція ключів CRYSTALS-Kyber на рівні квантової безпеки 128 біт (Kyber-768) додає приблизно 1,1 КБ накладних витрат на кожне встановлення сесії та завершується менш ніж за 1 мілісекунду на звичайному серверному обладнанні. Для стримінгових навантажень, де сесії тривають хвилини або години, ці накладні витрати є незначними. Вузьке місце в квантово-безпечному обміні ключами — не продуктивність алгоритму, а інфраструктура керування ключами та мережева затримка до сервера ключів.
Zero Trust застосований до стримінгових комунікацій
Кластер Kafka без контролю доступу є плоским широкомовним середовищем: будь-який вузол, що може дістатися до брокера, може продукувати або споживати будь-який топік. Zero Trust усуває це припущення про неявну довіру, вимагаючи безперервної перевірки сутностей у кожній точці топології стримінгу — продюсери, споживачі, брокери та сервер керування ключами — всі беруть участь у ланцюжку взаємної автентифікації та авторизації.
Площина управління Zero Trust у Corvus.Quantum слідує моделі NIST SP 800-207 із трьома компонентами. Рушій політик оцінює кожний запит на доступ — запит продюсера на запис до топіка, запит споживача на підписку, запит брокера на ключ від сервера керування ключами — щодо набору політик, що кодує мітки класифікації, членство в організаційних підрозділах та обмеження за часом доби. Адміністратор політик перетворює рішення політики на короткочасні облікові дані: надання прав Kafka ACL, маркери доступу до ключів із обмеженим TTL та сертифікати mTLS із вбудованими заявками авторизації. Точка виконання політики знаходиться всередині брокера Kafka та клієнта SDK — вона перевіряє кожне вхідне з'єднання щодо представлених облікових даних та відхиляє з'єднання, що несуть прострочені або невідповідні політиці облікові дані.
Жоден вузол у топології не довіряє іншому за місцем його розташування в мережі. Вузол-продюсер всередині того самого центру обробки даних, де знаходиться брокер, представляє свій сертифікат mTLS при кожному з'єднанні; брокер перевіряє ланцюжок сертифікатів, витягує заявки авторизації та перевіряє їх щодо рушія політик перед прийняттям будь-якого запиту на продукування. Скомпрометований брокер не може видавати себе за сервер керування ключами, оскільки сервер ключів незалежно перевіряє сертифікат брокера. Горизонтальна довіра між вузлами стримінгу дорівнює нулю — доступ кожного вузла обмежений саме тими топіками та ідентифікаторами ключів, на які він був явно авторизований.
Ключовий висновок: Zero Trust у стримінгових архітектурах закриває конкретний вектор атаки, який периметровий захист пропускає: скомпрометований вузол-споживач. У кластері Kafka, захищеному периметром, скомпрометований вузол, що вже знаходиться всередині мережі, може підписатися на будь-який топік, до якого може маршрутизуватися. У моделі Zero Trust Corvus.Quantum сертифікат скомпрометованого вузла відкликається у рушії політик, а всі ACL на стороні брокера для цього сертифіката анулюються в межах TTL кешованого рішення політики — зазвичай менш ніж за 60 секунд. Зловмисник втрачає доступ до стримінгу до того, як зможе ексфільтрувати повний обсяг даних сесії.
Топологія Apache Kafka: локальне розгортання проти Azure Event Hubs
Corvus.Quantum підтримує дві конфігурації брокерів. У локальному розгортанні Apache Kafka працює у фізичному об'єкті оператора — захищеному серверному приміщенні, тактичному оперативному центрі або ізольованій засекреченій мережі. Усі вузли брокера, координатори ZooKeeper (або KRaft) та сервер керування ключами працюють у межах об'єкта. Мережевий трафік між вузлами передається через фізично контрольоване середовище. Це конфігурація, що використовується в активних розгортаннях на бойових ділянках України, де засекречені аудіо- та відеопотоки маршрутизуються через оспорювану територію.
У розгортанні Azure Event Hubs основою стримінгу є керована служба Azure Event Hubs, яка надає сумісну з Kafka поверхню протоколу. Абстракція брокера SDK означає, що клієнтський код ідентичний в обох конфігураціях — відрізняються лише адреса початкового сервера та параметри автентифікації. Azure Event Hubs у орендарі Government Community Cloud (GCC High) забезпечує відповідність FedRAMP High, що робить його придатним для федеральних оборонних програм США. У цій конфігурації постквантове шифрування Corvus.Quantum гарантує, що навіть якщо рівень TLS Azure буде скомпрометований, перехоплений шифротекст залишиться непрозорим без сесійних ключів на основі ґраток, що зберігаються сервером керування ключами Corvus.
Вибір між двома топологіями визначається вимогами до з'єднання та відповідності, а не безпекою — рівні шифрування та Zero Trust забезпечують еквівалентний захист в обох конфігураціях. Організації, що не можуть прийняти жодної хмарної залежності для своїх найбільш чутливих навантажень, використовують локальне розгортання. Організації, що запускають засекречені, але не ізольовані навантаження на урядовій хмарній інфраструктурі, використовують Event Hubs для зниження операційного навантаження.
Подвійний розподіл ключів: QKD та фізично неклоновані функції
Сесійні ключі в Corvus.Quantum не виводяться з єдиного джерела. Платформа використовує два взаємодоповнюючі механізми, і кінцевий сесійний ключ є комбінацією обох — тому компрометація будь-якого каналу не компрометує сесійний ключ.
Квантовий розподіл ключів (QKD) використовує квантові оптичні канали — як правило, поляризовані фотони, що передаються по виділеному оптичному волокну — для обміну симетричним ключовим матеріалом із теоретико-інформаційною безпекою. Будь-яка спроба перехопити або виміряти квантовий канал порушує стани фотонів і вводить виявлені помилки; протокол переривається та переузгоджується, коли рівень помилок перевищує порогове значення. QKD є, таким чином, єдиним механізмом обміну ключами з фізичним механізмом виявлення перехоплення типу «людина посередині». Його обмеження пов'язане з інфраструктурою: QKD вимагає виділеного оптичного волокна та наразі обмежений точка-точка-ліній завдовжки до кількох сотень кілометрів без квантових повторювачів. У розгортаннях Corvus.Quantum із QKD-здатною інфраструктурою QKD забезпечує основний внесок ентропії ключів.
Фізично неклоновані функції (PUF) виводять криптографічний ключовий матеріал із власних фізичних виробничих варіацій кремнієвого пристрою — варіацій порогових напруг транзисторів, затримок дротів та поведінки комірок пам'яті, що є унікальними для кожного пристрою і не можуть бути клоновані або вилучені програмними засобами. PUF-здатний апаратний модуль безпеки надає інтерфейс виклику-відповіді: задаючи вхідний виклик, пристрій видає фізично визначену відповідь, стабільну між циклами живлення, але унікальну для цього фізичного пристрою. Corvus.Quantum використовує відповіді PUF як друге джерело ентропії ключів, застосовуючи операцію XOR з матеріалом, отриманим від QKD (або, де QKD недоступний, з початковим значенням, отриманим від CRYSTALS-Kyber), для отримання сесійного ключа. Оскільки матеріал PUF прив'язаний до фізичного обладнання, клонування сесійного ключа вимагає фізичного клонування обладнання — значно вища планка, ніж компрометація програмного сховища ключів.
AES-256 для даних у стані спокою
Постквантове шифрування захищає дані під час передачі. AES-256 захищає дані у стані спокою в сховищі брокера. Corvus.Quantum реалізує конвертне шифрування для сегментів журналів брокера: кожен сегмент журналу Kafka шифрується унікальним ключем шифрування даних (DEK), що генерується для кожного сегмента. Потім DEK загортається у ключ шифрування ключів (KEK) орендаря за допомогою AES-256-GCM та зберігається разом із сегментом. KEK зберігається на сервері керування ключами, а не на вузлі брокера — зловмисник, що отримав фізичний доступ до носіїв брокера, отримує зашифровані сегменти журналів та загорнуті DEK, але не може розгорнути DEK без доступу до сервера керування ключами.
Для засекречених стримінгових навантажень це розділення відповідальності безпосередньо відображає вимоги триади CIA: Конфіденційність забезпечується шифруванням DEK за допомогою AES-256 у стані спокою та постквантовим шифруванням під час передачі; Цілісність гарантується тегами автентифікації GCM для кожного зашифрованого сегмента, що виявляють підробку; Доступність підтримується коефіцієнтом реплікації Kafka та здатністю брокера повторно надавати сегменти з реплік у разі відмови первинного вузла. Сервер керування ключами є єдиною точкою довіри, але не єдиною точкою відмови — він працює у реплікованій конфігурації з підтримкою апаратного модуля безпеки (HSM).
Інтеграція Corvus.Quantum в оборонний стримінговий конвеєр: огляд Python SDK
Наступні кроки охоплюють інтеграцію за допомогою Python SDK. Java SDK надає ідентичну поверхню API. Кроки посилаються на схему HowTo, вбудовану у структуровані дані цієї сторінки.
Крок 1: Встановлення та налаштування облікових даних. SDK автентифікується за допомогою mTLS. Ваш постачальник ідентифікаційних даних Zero Trust видає клієнтський сертифікат, що служить одночасно обліковими даними TLS та ідентифікатором авторизації. Налаштуйте QuantumClient, вказавши шлях до сертифіката, шлях до ключа, пакет CA для ланцюжка сертифікатів брокера та кінцеву точку сервера керування ключами. Ніякі API-ключі або спільні секрети не використовуються — сертифікат є обліковими даними.
Крок 2: Реєстрація у рушії політик. Під час ініціалізації SDK виконує виклик реєстрації у рушії політик, що перевіряє сертифікат, перевіряє ACL топіків та повертає короткочасний маркер доступу. Це відбувається прозоро при першому використанні клієнта. Якщо реєстрація не вдається — недійсний сертифікат, прострочений ACL, зміна політики — SDK генерує AuthorizationError до того, як будь-яка операція стримінгу розпочнеться. Це забезпечує поведінку закритого відмовлення: ненастроєні або неправильно налаштовані клієнти не можуть випадково передавати незашифровані дані.
Крок 3: Вибір профілю розподілу ключів. Доступні три профілі. KD_QKD_PRIMARY використовує QKD для початкового обміну ключами та переходить на ML-KEM для не-QKD-ліній. KD_PUF_PRIMARY використовує апаратний PUF як основне джерело ентропії та вимагає PUF-здатного HSM. KD_KYBER_ONLY — лише програмне забезпечення, підходить для середовищ без QKD-інфраструктури. Встановіть TTL сесійного ключа та поведінку при безпечному відмовленні (FAIL_CLOSED або CONTINUE_WITH_CACHED_KEY) для сценарію втрати з'єднання.
Крок 4: Продукування зашифрованих повідомлень. Загорніть стандартний продюсер Kafka за допомогою QuantumProducer. Інтерфейс відправки ідентичний стандартному продюсеру Kafka — назва топіка, ключ, значення, заголовки. SDK шифрує значення за допомогою AES-256-GCM із використанням сесійного ключа, вбудовує ідентифікатор ключа у зарезервоване поле заголовка та доставляє зашифроване навантаження брокеру. Зміни схеми не потрібні. Стиснення застосовується до шифрування, щоб уникнути того, щоб розширення шифротексту зводило нанівець переваги стиснення.
Крок 5: Споживання та розшифрування. Загорніть стандартний споживач Kafka за допомогою QuantumConsumer. Споживач отримує ідентифікатор ключа із заголовка повідомлення, витягує відповідний сесійний ключ із локального кешу ключів (або повторно отримує з сервера керування ключами, якщо прострочений) та розшифровує навантаження. Групи споживачів, фіксація зсувів та перебалансування розділів функціонують ідентично стандартному Kafka. Код обробки повідомлень застосунку отримує відкритий текст — розшифрування є прозорим.
Крок 6: Увімкнення шифрування у стані спокою. Встановіть at_rest_key_id у конфігурації клієнта для активації шифрування журналів на стороні брокера. SDK автоматично підготовляє ієрархію DEK/KEK. Цей крок вимагає, щоб на вузлах брокера був встановлений плагін зберігання Corvus.Quantum — перехоплювач рівня зберігання Kafka, що обробляє шифрування/розшифрування сегментів журналів перед введенням-виведенням з диска.
Крок 7: Моніторинг та ротація. Увімкніть експортер телеметрії для пересилання подій доступу, рішень політики та подій отримання ключів до вашої SIEM. Налаштуйте сповіщення для помилок розшифрування (потенційна невідповідність ключів або атака відтворення), збоїв перевірки політики (потенційний неавторизований доступ) та затримки отримання ключів, що перевищує порогове значення TTL (попередження про деградацію з'єднання). Заплануйте ротацію ключів на 24-годинному кордоні або при переходах між фазами місії.
Ключовий висновок: Сім кроків інтеграції, описаних вище, можуть бути виконані за один інженерний спринт командою з наявним досвідом Kafka. Філософія проектування SDK — сумісність API зі стандартними клієнтськими бібліотеками Kafka: QuantumProducer та QuantumConsumer є взаємозамінними замінниками KafkaProducer та KafkaConsumer. Постквантові та Zero Trust рівні є інфраструктурними, а не прикладними проблемами. Інженери застосунків не повинні розуміти решіткову криптографію для інтеграції SDK — вони налаштовують профіль, обробляють AuthorizationError та пишуть стандартний код Kafka.
Поведінка в умовах деградованих мережевих умов
Оборонний стримінг не працює в ідеальних мережевих умовах. Corvus.Quantum спеціально розроблений для оспорюваних та деградованих мережевих середовищ — вимога, підтверджена його оперативним розгортанням на бойових ділянках України, де комунікації дронів проходять через заглушені та переривчасто доступні лінії.
При втраті з'єднання з сервером керування ключами кешовані сесійні ключі продовжують функціонувати протягом тривалості їх TTL. 30-хвилинний TTL означає 30-хвилинне вікно відключення, під час якого стримінговий конвеєр продовжує нормально працювати. Коли TTL закінчується без відновлення з'єднання, поведінка визначається політикою безпечного відмовлення: FAIL_CLOSED зупиняє стримінг, щоб запобігти незашифрованому відступу; CONTINUE_WITH_CACHED_KEY продовжує дію ключа, використовуючи матеріал, отриманий від PUF (доступний на PUF-здатному обладнанні), як вхідне значення для офлайн-виведення ключів, продовжуючи зашифрований стримінг без контакту з сервером ключів. При відновленні з'єднання повторний обмін ключами є автоматичним — SDK виявляє відновлення з'єднання, виконує нову інкапсуляцію ключів ML-KEM з сервером ключів та відновлює стримінг з новим сесійним ключем.
Докладніше про шаблони розгортання в ізольованих та відключених середовищах для засекречених навантажень, включаючи підходи до керування ключами в офлайн-режимі, дивіться у нашому спеціальному розгляді цієї архітектури. Стаття про Zero Trust для військових мереж детально охоплює повну модель рушія політик і стовпів, включаючи адаптації для відключених мереж, що доповнюють дизайн безпечного відмовлення Corvus.Quantum.
Часті запитання
+Що робить Corvus.Quantum стійким до атак квантових комп'ютерів?
Corvus.Quantum використовує криптографічні алгоритми на основі ґраток — зокрема NTRUEncrypt та CRYSTALS-Kyber — які математично несприйнятливі до алгоритму Шора, що є квантовим алгоритмом, здатним зламати RSA та криптографію на еліптичних кривих. Задачі на ґратках (задача найкоротшого вектора, навчання з помилками) не мають відомих квантових прискорень, що робить шифрування захищеним як проти класичних, так і проти квантових зловмисників. NIST стандартизував CRYSTALS-Kyber як ML-KEM у 2024 році, забезпечивши додатковий рівень відповідності стандартам.
+Як Zero Trust взаємодіє з постквантовим рівнем шифрування у Corvus.Quantum?
Zero Trust керує ідентифікацією та контролем доступу — він відповідає на питання про те, кому дозволено продукувати або споживати певний топік Kafka. Постквантова криптографія забезпечує конфіденційність — вона гарантує, що перехоплений шифротекст не може бути розшифрований навіть майбутнім квантовим зловмисником. Два рівні є взаємодоповнюючими: Zero Trust запобігає приєднанню неавторизованих вузлів до топології стримінгу, тоді як постквантове шифрування захищає дані під час передачі від атак типу «перехопи зараз — розшифруй пізніше» незалежно від того, чи перехопив зловмисник сесію TLS.
+Що відбувається зі стримінгом Corvus.Quantum при втраті з'єднання з сервером ключів?
Corvus.Quantum розроблений для середовищ із деградованими мережами. Платформа кешує сесійні ключі локально з налаштовуваним часом життя (TTL). Під час перебою у з'єднанні повідомлення, що перебувають у процесі передачі, продовжують шифруватися та розшифровуватися з використанням кешованих ключів до закінчення TTL. Коли TTL закінчується без відновлення з'єднання, платформа або переходить на заздалегідь підготовлені аварійні ключі (для платформ із апаратними функціями фізичного клонування), або переходить у налаштовуваний режим безпечного відмовлення. Повторний обмін ключами відбувається автоматично після відновлення з'єднання.
+Чи може Corvus.Quantum працювати локально без хмарних залежностей?
Так. Corvus.Quantum розгортає Apache Kafka локально без обов'язкових хмарних компонентів. Сервер керування ключами, рушій політик і всі стримінгові брокери можуть працювати цілком в межах ізольованого об'єкта. Azure Event Hubs підтримується як альтернативний брокер для організацій, що надають перевагу керованій хмарній інфраструктурі, але не є обов'язковим. SDK для Python та Java абстрагують вибір брокера, тому клієнтський код ідентичний в обох моделях розгортання.
+Як працює подвійний розподіл ключів — що таке фізично неклоновані ключі?
Corvus.Quantum використовує два взаємодоповнюючі механізми розподілу ключів. Квантовий розподіл ключів (QKD) використовує квантові оптичні канали (зазвичай оптичне волокно) для обміну симетричними ключами з теоретико-інформаційною безпекою — будь-яке перехоплення фізично порушує квантовий стан і є виявленим. Ключі на основі фізично неклонованих функцій (PUF) виводять криптографічний матеріал із виробничих варіацій кремнію апаратного пристрою, створюючи відбиток, який неможливо клонувати або отримати. Для кожної сесії обидва механізми вносять вклад у виведення сесійного ключа, тому компрометація одного каналу не компрометує сесійний ключ.