Аутентифікація у контексті БПЛА — підтвердження того, що команди надходять саме від легального оператора, а не від противника що намагається захопити управління. На відміну від шифрування (яке захищає конфіденційність), аутентифікація захищає цілісність і походження команд.
Найпростіший метод аутентифікації — спільний секрет (bind phrase в ELRS). Складніший — challenge-response: борт надсилає випадкове число, оператор підписує його відомим лише йому ключем і відправляє назад. Ohne знання ключа відтворити підпис неможливо. Найскладніший — PKI (Public Key Infrastructure) з сертифікатами і CRL (Certificate Revocation Lists).
Реальна «захоплення» БПЛА — рідкісна, але задокументована подія. Іранський RQ-170 зупинений у 2011 (GPS spoof, не командний hijack). FPV-дрони ЗСУ не були масово захоплені через командний канал — більш поширена атака через jamming. Але з ростом автономності БПЛА і вартістю бортів — захист від hijacking стає критичнішим.
Взаємна аутентифікація: схема challenge-response
Типи атак на аутентифікацію БПЛА
| Тип атаки | Ціль | Метод | Захист |
|---|---|---|---|
| Bind Attack | Прив'язати новий TX як «легальний» | Перехоплення bind sequence | Encrypted bind + PIN |
| Replay Attack | Відтворити старі легальні команди | Записати і відтворити пакети | Rolling nonce / timestamp |
| Impersonation | Підробити ідентичність GCS | Відправити пакети у форматі протоколу | HMAC / mutual auth |
| MitM / Relay | Перехопити і модифікувати команди | Посередник між GCS і дроном | E2E шифрування + cert pinning |
| Key Compromise | Вкрасти ключ аутентифікації | Hardware theft, side channel | HSM, key rotation, revocation |
Часті запитання
Що таке «bind attack» на RC-системи і як його запобігти?
Bind Attack — спроба примусити БПЛА прийняти ворожий TX як легальний: Як відбувається binding у RC-системах: RX (приймач на дроні) і TX (пульт управління) «зв'язуються» через спеціальну bind-процедуру. У більшості протоколів binding відбувається при фізичному натисканні кнопки BIND на RX у відповідний момент. При binding обміняються ідентифікаторами і токенами аутентифікації. Вразливість: якщо bind-процедура не захищена → противник може підбудуватись і відправити свій TX у bind-моді → RX може «переприв'язатись» до ворожого TX. Реальна небезпека: потрібна або фізична близькість під час bind (тобто, коли оператор виконує bind), або вразливість у самому протоколі. Більшість RC-систем вимагають фізичного натискання кнопки → важко атакувати дистанційно. Захист для ELRS: 1) Bind phrase: унікальна фраза-пароль яку знають тільки легальні TX/RX цієї пари. Bind прийнятий тільки від TX з правильним bind phrase. 2) Encrypted bind sequence: навіть сам bind-пакет зашифрований → без знання phrase його неможливо відтворити. 3) Never re-bind у польоті: RX у польоті ігнорує bind запити. Тільки при явному power cycle + bind button. Практика ЗСУ: унікальний bind phrase для кожного борту (не загальний для всього підрозділу). Регулярна ротація bind phrases у діючих підрозділах. Ніколи не проводити bind у відкрити місці поруч з активним фронтом.
Як MAVLink v2 signing захищає від command injection і чим відрізняється від шифрування?
MAVLink v2 Message Signing — цифровий підпис кожного пакету: Що підписується: кожен пакет MAVLink v2 містить 13-байтовий signing trailer: 1) Link ID (1 байт): ідентифікує радіоканал. 2) Timestamp (6 байт): монотонно зростаючий лічильник (250 мкс одиниця). 3) Signature (6 байт): перші 48 біт HMAC-SHA-256 (key || header || payload || timestamp). Захист що надається: 1) Аутентифікація відправника: тільки той хто знає secret_key може створити валідний підпис. 2) Захист цілісності: зміна будь-якого байту в пакеті → підпис невалідний. 3) Anti-replay: timestamp монотонно зростає → старий пакет відхиляється. Що НЕ забезпечує MAVLink signing: 4) Конфіденційність (шифрування): вміст пакету читабельний для перехоплювача. Mission coordinates, waypoints — видимі. Тобто: signing = «я можу довіряти командам» + «команди не підроблено». Але: «я приховую координати від спостерігача» — для цього потрібне шифрування. Комбінований підхід для максимального захисту: MAVLink over TLS tunnel (mTLS): TLS забезпечує шифрування, MAVLink signing — додатковий шар аутентифікації на протокольному рівні. Або WireGuard VPN + MAVLink (менш складна конфігурація). Практичне налаштування: Mission Planner→Advanced→MAVLink Signing. Потрібен однаковий signing key на GCS і борту. Зберігання ключа → secure storage (не відкрито).
Що таке GPS spoofing і чому він є різновидом «захоплення» БПЛА?
GPS Spoofing — підміна GPS-сигналу для введення БПЛА в оману щодо власного місцезнаходження: Механізм: GPS сигнали — відкриті і незахищені (принаймні цивільні L1 C/A). Спуфер генерує фальшивий GPS-сигнал з вищою потужністю ніж справжній. БПЛА «думає» що він в іншому місці. Результат: якщо БПЛА налаштований на RTH → летить до «home» який спуфер визначив у нові координати → борт приземлюється у потрібне для атакуючого місце. Приклад: RQ-170 Sentinel 2011 (ймовірно), іранська заява про GPS spoof. Захист від GPS spoofing: 1) Multi-constellation: БПЛА приймає GPS (США) + GLONASS (Росія) + Galileo (ЄС) + BeiDou (Китай). Спуфити всі одночасно — значно складніше. 2) GPS/INS інтеграція: якщо GPS стрибає нереалістично → порівняння з IMU dead reckoning → виявлення аномалії. 3) Dual-frequency (L1+L5): L5 GPS — більш захищений. Спуфити обидві частоти одночасно складніше. 4) Signal strength monitoring: реальний GPS сигнал has known power level. Надто сильний GPS → можливий спуфер. 5) Anti-spoofing algorithms у ArduPilot: EKF GPS glitch detection → відхиляє нереалістичні стрибки. Обмеження: без криптографічного захисту GPS (як у GPS M-Code для військових) → спуфінг завжди можливий. БПЛА ЗСУ: поєднання GPS + optical flow + barometer + terrain matching для перехресної валідації.
Чи є БПЛА ЗСУ вразливими до захоплення через command hijacking і були реальні випадки?
Реальна загроза command hijacking vs поширені уявлення: Реальні задокументовані випадки command hijacking FPV у конфлікті: Відсутні публічні підтвердження успішного hijacking RC командного каналу FPV ЗСУ. Більш поширені атаки: jamming (глушіння), не hijacking (захоплення). Чому hijacking складніший ніж jamming: 1) Потрібно знати binding sequence. 2) Потрібно передати пакети у точному форматі протоколу. 3) Потрібна синхронізація з FHSS послідовністю. 4) Потрібна вища потужність ніж легальний TX. Jamming = просто «залити шумом» → простіше. Відомі вразливості що використовувались: 1) DJI Mavic series: деякі ранні версії мали вразливий bind. DJI в результаті закрив під оновлення. 2) FrSky D8 (старий): знаний алгоритм bind → теоретично вразливий. 3) Spektrum DSM2: вразливий до bind attacks (задокументовано у дослідженнях). DSSS, не FHSS. РЕБ РФ focus: за оцінками аналітиків, РЕБ РФ фокусується переважно на GPS-jam і RC-jam, а не на command injection/hijack. Захист ЗСУ: 1) Більшість бойових FPV — одноразові → навіть при hypothetical hijack, БПЛА вже виконує удар. 2) Розвідувальні борти (Mavic) — DJI OcuSync AES захист. 3) Великі розвідувальні БПЛА — MAVLink signing + encrypted транспорт. Висновок: command hijacking — теоретично можливий для застарілих протоколів. Для ELRS + AES-128/256 binding — практично нереалістичний без ресурсів ФСБ/ГРУ рівня.
Як реалізувати PKI-аутентифікацію для флоту БПЛА і де це доцільно?
PKI (Public Key Infrastructure) для флотів БПЛА — масштабований підхід для аутентифікації: Коли PKI доцільний: не для FPV (занадто складний і дорогий для одноразових), але для: великих розвідувальних БПЛА що багаторазово використовуються, автономних систем де потрібна верифікація без постійного оператора, мульти-vehicle систем де GCS управляє десятками бортів. PKI архітектура для БПЛА-флоту: 1) Root CA (Certificate Authority): довірений центр що підписує сертифікати. Може бути operated in-house (HW security module — HSM). 2) Device Certificates: кожен БПЛА отримує унікальний X.509 сертифікат при виробництві/конфігурації. Містить: public key, serial number, validity period, signed by Root CA. 3) GCS Certificates: GCS теж має свій сертифікат. 4) Mutual TLS (mTLS): БПЛА і GCS при з'єднанні обмінюються сертифікатами. Кожен верифікує CA-підпис → mutual authentication без pre-shared secrets. Переваги для флоту: Централізоване управління: revoke сертифікат скомпрометованого борту → більше не може підключитись до жодного GCS флоту. Масштабованість: не потрібно конфігурувати окремі shared secrets для кожної GCS-БПЛА пари. Audit trail: всі підключення логуються з ідентифікатором сертифікату. Обмеження: 1) Розмір сертифікатів (1–2 KB) → overhead для низькошвидкісних radio links. 2) Потрібен час для TLS handshake → неприйнятно для <50 мс latency RC FPV. PKI доцільний для MAVLink over TCP/UDP links (LTE, WiFi) але не для real-time RC FHSS.
Чому ключове управління (key management) є найскладнішою частиною аутентифікації БПЛА?
Key Management — найслабша ланка будь-якої криптографічної системи: Якщо шифрування — «замок», то ключове управління — «де зберігати ключ і як не втратити його». Типові проблеми key management у БПЛА-контексті: 1) Ключі у відкритому тексті у прошивці: деякі FC (особливо дешеві клони) зберігають signing keys у flash без захисту. Фізичний доступ до борту → ключ витягується. 2) Один ключ для всього підрозділу: зручно, але компрометація одного борту → всі борти вразливі. Принцип: unique key per UAV. 3) Ротація ключів: ключі треба регулярно змінювати. Але як оновити ключ на 50 бортах у польових умовах? → потрібен secure update channel. 4) Backup/recovery: ключ загублено → борт недоступний. Потрібен secure backup. Hardware Security Modules (HSM) для БПЛА: Secure element (SE) чіп на FC → зберігає ключ у захищеному hardware. Ключ ніколи не залишає SE у відкритому вигляді. DJI FlightHub для enterprise: централізоване key management для флотів. ELRS підхід: bind phrase як спільний секрет. Зберігається у TX і RX firmware. Ризик: якщо TX захоплено → bind phrase відомий і борти вразливі. Militarily sound підхід: per-aircraft unique keys, HSM storage, regular rotation (щотижнева для FPV, щомісячна для розвідувальних), automated revocation при захопленні борту. Складно реалізувати у польових умовах → компроміс між безпекою і оперативністю.