Оператор дрона виконує розвідувальну місію над спірною місцевістю. Відеопотік H.264 передається через супутниковий канал, зашифрований за допомогою DTLS/SRTP з обміном ключами ECDHE. На землі противник перехоплює та зберігає шифротекст — не для того, щоб розшифрувати його сьогодні, а щоб розшифрувати у 2032 році, коли з'явиться криптографічно значущий квантовий комп'ютер. До того часу відзнятий матеріал розкриє прогалини в покритті сенсорів, геометрію цілевказання та маршрути патрулювання дружніх сил. Розвідувальна цінність того збереженого відео не зменшиться від років, проведених у зашифрованому вигляді.
Це проблема «збери зараз — розшифруй пізніше» (HNDL), застосована до відеопотоків реального часу у військових операціях. Це не гіпотетичний сценарій. Противники, які розуміють квантові терміни, вже збирають та архівують зашифровані ISR-канали, відео з дронів та командний голосовий трафік. Правильна відповідь — не чекати, поки квантові комп'ютери з'являться, перш ніж переходити на постквантову криптографію; вікно для захисту даних у дорозі відкрите зараз, до того як збір даних відбудеться.
Чому відео з дронів та ISR є найціннішою HNDL-ціллю
Розвідка засобів зв'язку (COMINT) має очевидну HNDL-цінність, але відео ISR несе інший клас інформації. Одна місія нешифрованого відео з дрона може розкрити: точні поля зору сенсорів (а отже, і сліпі зони), точні часові параметри та геометрію рішень щодо цілевказання, місцезнаходження та переміщення дружніх сил у кадрі, а також оперативні патерни, що визначають поведінку підрозділу з часом. На відміну від одиночного зашифрованого повідомлення, відео кодує стійку контекстну інформацію — просторову, часову та поведінкову — що винагороджує довгострокове збирання та аналіз.
Термін зберігання відео ISR посилює цей ризик. Багато оборонних програм архівують необроблені відеозаписи з дронів роками — для аналізу після дій, юридичної відповідності, розвідувальної обробки. Противник, який збере зашифроване ISR-відео у 2026 році та розшифрує його у 2032-му, читатиме не застарілі дані; він читатиме структурований історичний запис операцій дружніх сил. Чутливість цього запису не зменшується з часом.
Оцінка поверхні збирання: один дрон MALE за 20-годинну місію при стандартних бітрейтах ISR (4–8 Мбіт/с H.264) виробляє 36–72 ГБ стисненого відео за виліт. Флот, що діє над спірним регіоном, генерує терабайти на день. Це надзвичайно приваблива ціль для збирання для противника, готового інвестувати в довгострокове зберігання та майбутні можливості дешифрування.
Поточний стан: DTLS/SRTP та TLS є класично захищеними, але вразливими до квантових атак
Більшість конвеєрів відео з військових дронів використовують одну з двох моделей транспортної безпеки. Перша — DTLS/SRTP: модель на основі WebRTC, де DTLS 1.3 узгоджує сесійні ключі через UDP, а SRTP використовує ці ключі для шифрування кожного RTP-пакету. Друга — захищений TLS сервер розподілу ключів (KDS): централізована служба, яка видає SRTP майстер-ключі відправнику та отримувачу через захищений TLS API, де SRTP обробляє шифрування на рівні пакетів. Обидві моделі зрештою залежать від класичного обміну ключами Діффі-Хеллмана або еліптичних кривих Діффі-Хеллмана для фази узгодження сесійних ключів.
ECDHE з X25519 (поточна найкраща практика для обміну ключами DTLS/TLS) забезпечує надійну класичну безпеку. Проти квантового противника, що запускає алгоритм Шора, він не забезпечує жодної безпеки. Це не слабкість реалізації алгоритму — це фундаментальна властивість базової математичної задачі (дискретний логарифм на еліптичній кривій), яку алгоритм Шора розв'язує за поліноміальний час. Замінити X25519 більшою кривою (наприклад, P-521) не допоможе; алгоритм Шора ефективно масштабується для всіх розмірів параметрів еліптичних кривих.
Симетричне шифрування AES-256 (яке використовується для фактичного корисного навантаження пакетів SRTP) не зламується квантовими комп'ютерами аналогічним чином. Алгоритм Гровера знижує ефективну безпеку AES-256 до 128 біт проти квантового противника — все ще обчислювально неможливо для перебору. Терміновість стосується обміну ключами, а не симетричного шифру.
ML-KEM для обміну ключами відео: інтеграція постквантових KEM з SRTP
ML-KEM (механізм інкапсуляції ключів на основі модульних решіток), стандартизований як FIPS 203 інститутом NIST на основі алгоритму CRYSTALS-Kyber, є постквантовою заміною для фази обміну ключами DTLS та TLS. KEM працює інакше, ніж Діффі-Хеллман: отримувач генерує пару публічного та приватного ключів і публікує публічний ключ; відправник інкапсулює випадковий спільний секрет за допомогою публічного ключа; отримувач декапсулює для відновлення того самого спільного секрету. Жодна зі сторін не передає спільний секрет відкритим текстом, і противник, який перехопить шифротекст, не зможе відновити спільний секрет без приватного ключа отримувача — задача, яка вважається складною навіть для квантових комп'ютерів.
Інтеграція з SRTP є простою на рівні API. Хендшейк DTLS (або виклик KDS API) формує спільний секрет, як і раніше; єдина зміна полягає в тому, що спільний секрет тепер виводиться з інкапсуляції ML-KEM, а не з обміну ECDHE. Спільний секрет подається до HKDF-SHA-384 для виведення SRTP майстер-ключа та солі, слідуючи тому самому шляху виведення ключа, що й у класичному протоколі. Формат пакетів SRTP, обробка порядкового номера, обчислення тегу автентифікації та масове шифрування AES-256-GCM залишаються незмінними. З точки зору стеку RTP, нічого не змінилось, крім походження майстер-ключа.
Вибір набору параметрів: ML-KEM-768 проти ML-KEM-1024
Визначено три набори параметрів ML-KEM: ML-KEM-512 (рівень безпеки, еквівалентний AES-128), ML-KEM-768 (AES-192) та ML-KEM-1024 (AES-256). Для ISR-застосунків вибір стоїть між ML-KEM-768 та ML-KEM-1024. Мандат CNSA 2.0 від NSA визначає ML-KEM-1024 для систем національної безпеки. ML-KEM-1024 виробляє публічний ключ розміром 1 568 байт та шифротекст розміром 1 568 байт — обидва більші за 32-байтові спільні ключі X25519, але легко вміщуються в хендшейк DTLS або відповідь HTTPS API. Витрати на продуктивність відносно ML-KEM-768 є незначними; для рішення, яке визначатиме безпеку даних на десятиліття, ML-KEM-1024 є правильним вибором для класифікованих ISR-застосунків.
Бюджет затримки: накладні витрати PQC у потоковому стримінгу реального часу
Найпоширенішим запереченням проти PQC у конвеєрах відео реального часу є затримка. Занепокоєння є зрозумілим, але воно виявляється безпідставним, коли розглядаються реальні цифри.
Генерація ключа ML-KEM-1024 на сучасному процесорі x86-64 (оптимізована під AVX2 реалізація, наприклад liboqs або вбудований BoringSSL) займає приблизно 0,3–0,5 мс. Інкапсуляція та декапсуляція займають менше 0,5 мс кожна. Загальні витрати на обмін ключами PQC у двох напрямках становлять менше 2 мс, включно з часом мережевого обходу в мережі з малою затримкою. Для відеопотоків, що вже несуть 100–300 мс затримки кодека та мережевого конвеєра (типово для тактичних супутникових каналів), ці витрати на практиці не вимірюються.
Обмін ключами є одноразовою операцією на сесію, а не операцією на пакет. Відеосесія дрона тривалістю 20 годин виконує одну інкапсуляцію ML-KEM на початку (та невелику кількість періодичних переоформлень ключів). Витрати на пакет дорівнюють нулю — шифрування пакетів SRTP залишається AES-256-GCM на апаратних швидкостях прискорення (кілька Гбіт/с на сучасних процесорах). Постквантовий відеостримінг — це не проблема продуктивності. Це проблема інтеграції.
Розгортання в гібридному режимі: ECDHE + ML-KEM паралельно
Під час перехідного періоду — коли одні кінцеві точки підтримують ML-KEM, а інші ні — гібридні набори шифрів є схваленим стандартом підходом. У гібридному режимі хендшейк DTLS або TLS включає і спільний секрет ECDHE (X25519), і інкапсуляцію ключа ML-KEM (ML-KEM-1024). Сесійний ключ виводиться з обох через HKDF за формулою: session_key = HKDF(X25519_shared_secret || ML-KEM_shared_secret, "hybrid-srtp-key"). Обидва секрети мають бути успішно виведені для продовження сесії.
Ця конструкція забезпечує те, що криптографи називають «подвійною безпекою»: сесія є квантово-захищеною, якщо ML-KEM є надійним, та класично захищеною, якщо X25519 є надійним. Зловмисник повинен зламати обидва, щоб відновити сесійний ключ. NSA схвалює гібридний режим для перехідного періоду у своїх настановах CNSA 2.0; він жодним чином не знижує класичну безпеку.
Практична перевага для ISR-систем полягає в тому, що гібридний режим можна розгорнути по всьому флоту до оновлення всіх наземних станцій. Оновлені наземні станції узгоджують гібридний набір шифрів; застарілі наземні станції відкочуються до лише ECDHE. Найцінніші потоки — ті, що з'єднують C2-вузли, здатні до постквантового захисту, — отримують квантовий захист негайно, тоді як зворотна сумісність зберігається. Детальний інвентар алгоритмів та графік переходу розглянуто в нашій ширшій статті про підхід до міграції CNSA 2.0 для оборонних систем.
Apache Kafka як хребет стримінгу для ISR-розподілу
Точка-до-точки SRTP підходить для одиночних каналів дрон–C2, але оперативний ISR-розподіл є задачею «один до багатьох». Один канал з дрона повинен споживатися одночасно: головним командним постом, групою цілевказання, командою розвідувальної обробки, вузлом запису, що архівує місію, та, можливо, командуваннями вищих ешелонів, що моніторять операцію. Управління N одночасними сесіями SRTP від кодера до кожного споживача є операційно нестійким та криптографічно заплутаним — кожна сесія має незалежний ключовий матеріал, і управління розподілом та ротацією ключів серед N рівнів одночасно створює сценарії збоїв.
Apache Kafka вирішує цю архітектурну проблему. Кожне ISR-джерело публікує в окрему тему Kafka (наприклад, isr.drone.alpha-01.video, isr.sensor.ground.bravo). Групи споживачів — по одній на роль (c2-display, targeting, exploitation, archive) — підписуються незалежно та підтримують власні зміщення. Додавання нового споживача не вимагає переузгодження з виробником; він просто підписується на існуючу тему. Відтворення для споживачів, що приєдналися із запізненням (аналітик, який виходить онлайн у середині місії), є вбудованою можливістю Kafka, а не спеціальною функцією.
Постквантова модель безпеки чисто вписується в цю архітектуру. Кожен виробник автентифікується до брокера Kafka через взаємний TLS з гібридними наборами шифрів ML-KEM, встановлюючи квантово-захищений канал для потоку. Кожен споживач також підключається до брокера через TLS з гібридним ML-KEM. Брокер зберігає зашифровані дані теми на диску під шифруванням AES-256 у стані спокою. Ієрархія ключів — сесійний ключ ML-KEM, що захищає TLS-з'єднання, яке несе зашифровані SRTP відеокадри, збережені в зашифрованих AES-256 сегментах журналу Kafka — забезпечує глибокий захист на кожному рівні.
Партиціонування тем та дизайн груп споживачів
Для розгортань ISR з кількома сенсорами партиціонування в межах теми забезпечує масштабованість. Сенсор з високою пропускною здатністю (повнорухове відео на 8 Мбіт/с) виграє від однієї партиції на джерело для збереження порядку кадрів. Кілька сенсорів з нижчою пропускною здатністю (телеметрія, аудіо, вузькопольна зйомка) можуть ділити тему з партиціонуванням за ідентифікатором сенсора. Групи споживачів мають бути розмежовані за операційними ролями, а не окремими робочими станціями — це дозволяє перемикання при відмові робочої станції в межах ролі без втрати безперервності зміщення. Кожна група споживачів підтримує незалежний стан дешифрування; ротація ключів в одній групі не впливає на інші.
Corvus.Quantum: постквантовий стримінг для оперативної оборони
Corvus.Quantum — це платформа Corvus Intelligence для квантово-захищеного розподілу аудіо та відео в оборонних середовищах. Вона реалізує архітектуру, описану в цій статті — обмін ключами ML-KEM-1024 у гібридному режимі, шифрування пакетів SRTP, розподіл Apache Kafka «один до багатьох» для багаторівневого розподілу — як загартовану, операційно перевірену систему, а не дослідний прототип.
Платформа розгорнута в умовах активного конфлікту в Україні, де вона керує розподілом ISR-відео в реальному часі для командних постів, що діють під тиском радіоелектронної боротьби. Пріоритети дизайну, сформовані цим середовищем — затримка «скло до скла» менше 200 мс, незважаючи на оспорювані канали, коректне зниження якості при від'єднанні споживачів під час потоку, автоматична ротація ключів без переривання потоку та можливість розгортання у повітряному зазорі для класифікованих мереж — перевірені у виробництві, а не змодельовані в лабораторії.
Corvus.Quantum інтегрується з існуючою інфраструктурою C2 на основі ATAK через інтерфейс плагіна, дозволяючи ISR-відео надходити до загальної оперативної картини разом з даними cursor-on-target. Хребет Kafka підтримує як хмарні, так і ізольовані локальні розгортання. Постквантовий обмін ключами увімкнений за замовчуванням; класичне відкочування доступне для застарілих кінцевих точок під час гібридних перехідних періодів. Для організацій, що стикаються з вимогами мереж з нульовою довірою для військових середовищ, взаємна TLS-автентифікація Corvus.Quantum для кожного виробника та споживача задовольняє перевірку ідентифікації пристрою на рівні стримінгу без додаткового проміжного програмного забезпечення.
Шлях закупівлі Corvus.Quantum доступний через ринок оборонних технологій Brave1 та прямий контракт з Corvus Intelligence. Технічна документація з інтеграції надається під NDA для кваліфікованих оборонних організацій та генеральних підрядників.
Ключовий висновок: Накладні витрати на затримку ML-KEM-1024 у реальному потоковому конвеєрі становлять менше 2 мс на встановлення сесії — невимірювані на тлі 100–300 мс затримки, що вже присутня в тактичних супутникових відеоканалах. Інженерна проблема полягає не у продуктивності; вона полягає у виборі бібліотек, змінах шляху виведення ключів та узгодженні гібридних наборів шифрів. Це тижні роботи з інтеграції, а не місяці оптимізації продуктивності.
Corvus.Quantum забезпечує постквантово зашифрований розподіл відео та аудіо для ISR та C2 — на основі Kafka, сумісний з SRTP, перевірений у бойових умовах в Україні. Якщо вашій програмі потрібен квантово-захищений стримінг до дедлайну CNSA 2.0, ми допоможемо досягти цього без повного перебудовування конвеєра.
Дослідити Corvus.Quantum →