Оператор дрона виконує розвідувальну місію над спірною місцевістю. Відеопотік 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 мс затримки, що вже присутня в тактичних супутникових відеоканалах. Інженерна проблема полягає не у продуктивності; вона полягає у виборі бібліотек, змінах шляху виведення ключів та узгодженні гібридних наборів шифрів. Це тижні роботи з інтеграції, а не місяці оптимізації продуктивності.
Часті запитання
+Чому живе відео з дрона є ціллю атаки «збери зараз — розшифруй пізніше»?
Відео з дронів та ISR-систем перехоплюється під час передачі по радіо- або супутниковому каналу, зберігається противником та розшифровується пізніше — щойно стане доступний криптографічно значущий квантовий комп'ютер. Відзнятий матеріал може розкрити позиції сенсорів, геометрію цілевказання та маршрути розвідки — розвідані дані, які зберігають оперативну цінність роками. На відміну від одиночних повідомлень, відео містить стійкі контекстні дані, що робить його особливо цінним для довгострокового збору. Поточний обмін ключами DTLS/SRTP та TLS 1.3 (ECDHE) буде зламано алгоритмом Шора на квантовому комп'ютері, що зробить весь зібраний шифротекст ретроспективно читабельним.
+Як ML-KEM інтегрується з SRTP для відео в реальному часі?
ML-KEM замінює або доповнює фазу обміну ключами в DTLS 1.3 (який використовується у WebRTC) або на спеціалізованому сервері розподілу ключів. Саме шифрування медіа залишається як AES-128/256 GCM у межах SRTP — ML-KEM захищає лише узгодження сесійного ключа, а не кожен пакет. Відправник інкапсулює спільний секрет за допомогою публічного ключа ML-KEM отримувача; отримувач декапсулює, відновлюючи спільний секрет; обидві сторони виводять SRTP майстер-ключ через HKDF. Цей обмін ключами є одноразовою операцією на сесію, тому його накладні витрати (близько 1,5 КБ для публічного ключа ML-KEM-1024, субмілісекундна інкапсуляція на сучасному обладнанні) не впливають на затримку для окремих пакетів.
+Яке накладне навантаження по затримці створює ML-KEM-1024 у потоковому конвеєрі?
Генерація ключа ML-KEM-1024 займає приблизно 0,3–0,5 мс на сучасному процесорі x86-64; інкапсуляція та декапсуляція — менше 0,5 мс кожна. Публічний ключ займає 1 568 байт, а шифротекст — 1 568 байт; обидва вміщуються в один типовий MTU з фрагментацією або в дещо збільшений хендшейк. Додаткова затримка на встановлення сесії становить менше 2 мс на типовому обладнанні. Обробка кожного пакета залишається незмінною порівняно зі стандартним SRTP, оскільки симетричний шифр AES не зачіпається. Для відеопотоків, які вже допускають 100–300 мс затримки «скло до скла», накладні витрати ML-KEM є незначними.
+Від чого захищає гібридний режим ML-KEM + ECDHE?
У гібридному режимі хендшейк TLS або DTLS включає і спільний секрет ECDHE, і інкапсуляцію ключа ML-KEM; сесійний ключ виводиться з обох через HKDF. Це означає, що зловмисник повинен зламати як класичну криптографію на еліптичних кривих, так і постквантову задачу на решітках, щоб відновити сесійний ключ. Гібридний режим захищає від двох різних сценаріїв відмови: квантового комп'ютера, що ламає ECDHE (вирішується ML-KEM), та нерозкритої математичної слабкості в ML-KEM (вирішується ECDHE). NSA схвалює гібридний режим для перехідного періоду; він не послаблює класичну безпеку.
+Як Apache Kafka вписується в постквантову архітектуру ISR-стримінгу?
Kafka виступає надійним хребтом «один до багатьох» між вузлами прийому даних з дронів/ISR та споживачами на командних пунктах. Кожне ISR-джерело (дрон, наземний сенсор, супутниковий канал) публікує в окрему тему Kafka; командні пости та вузли запису підписуються як групи споживачів. Постквантовий обмін ключами захищає з'єднання між виробником (вузол кодування) та брокером Kafka, а також між брокером та кожним споживачем. Оскільки Kafka зберігає повідомлення на диску, шифрування даних теми на диску за допомогою AES-256 також є обов'язковим — сесійний постквантовий ключ захищає виведення ключа для шифрування на диску. Ця архітектура розв'язує пропускну здатність прийому від затримки відображення та підтримує багаторівневий розподіл без перекодування.
Corvus.Quantum забезпечує постквантово зашифрований розподіл відео та аудіо для ISR та C2 — на основі Kafka, сумісний з SRTP, перевірений у бойових умовах в Україні. Якщо вашій програмі потрібен квантово-захищений стримінг до дедлайну CNSA 2.0, ми допоможемо досягти цього без повного перебудовування конвеєра.
Дослідити Corvus.Quantum →