Cyber-Resilience and Trust-Aware Command Authorization for Autonomous UAV Swarms in GPS-Denied Environments

Immaginate uno stormo di droni che vola insieme senza GPS, navigando grazie alla percezione dell'ambiente circostante e comunicando tra loro. In questo ambiente ad alto rischio, un singolo drone deve decidere se obbedire a un comando inviato da un operatore umano o da un drone vicino. La sfida centrale non è solo verificare che il messaggio provenga da una fonte nota, ma determinare se sia sicuro seguire quel messaggio proprio in quel momento. Un comando può essere perfettamente autentico — firmato con la corretta chiave digitale — ma può comunque essere pericoloso se i sensori di posizione del drone stanno fallendo, se la batteria è bassa o se la persona che ha inviato il comando non è più considerata affidabile. Questo articolo affronta il divario tra sicurezza crittografica e sicurezza fisica, proponendo un sistema che tratta ogni ordine in entrata come un potenziale rischio finché non supera un rigoroso controllo multistrato. I ricercatori hanno costruito un framework che funge da guardiano, garantendo che un drone non esegua mai un'istruzione remota a meno che l'intero contesto del suo volo, la sua salute e la sua fiducia nel mittente non siano perfettamente allineati.

Il lavoro si concentra su sciami di droni autonomi che operano in ambienti privi di GPS, dove la normale navigazione satellitare non è disponibile. In queste condizioni, i droni si affidano alla comunicazione peer-to-peer e ai sensori di bordo per mantenere la formazione e l'integrità della missione. L'autore sostiene che i modelli di sicurezza tradizionali, che spesso si fermano alla verifica di una firma digitale, siano insufficienti per le macchine fisiche. Una firma prova chi ha inviato un messaggio, ma non prova che il messaggio sia sicuro da attuare. Per risolvere questo problema, i ricercatori hanno sviluppato un supervisore di runtime "fail-closed" (a chiusura sicura). Si tratta di un pezzo di software che monitora costantemente lo stato interno del drone e il suo ambiente esterno. Esso analizza nove fattori distinti, tra cui la qualità della connessione wireless, la confidenza nella stima della propria posizione, il livello della batteria e l'affidabilità dell'entità che emette il comando. In base a questi input, il sistema assegna il drone a uno di nove stati di sicurezza specifici, che vanno dal pieno affidamento all'isolamento immediato.

Il sistema opera secondo un principio di stretta gerarchia. Se il drone rileva un guasto critico, come una batteria che scende sotto una soglia di sicurezza o una perdita improvvisa di comunicazione, entra immediatamente in uno stato in cui ignora tutti i comandi remoti ed esegue una manovra di sicurezza preprogrammata, come l'atterraggio o il ritorno alla base. Questa decisione è automatica e non può essere sovrascritta da un operatore remoto, anche se quest'ultimo è autenticato. I ricercatori hanno implementato questa logica in una piattaforma software in C++ e l'hanno testata contro vari scenari. Hanno scoperto che il sistema ha respinto con successo comandi tecnicamente validi ma contestualmente non sicuri. Ad esempio, se la confidenza della posizione del drone scendeva sotto una soglia specifica, il sistema rifiutava un comando di mantenimento della formazione, anche se il comando proveniva da un leader affidabile ed era recente. Allo stesso modo, se il sistema rilevava segni di un attacco di replay — in cui un vecchio comando valido viene inviato nuovamente per confondere il drone — esso passava a uno stato di sospetto e bloccava il controllo remoto.

Un risultato chiave dello studio è che un singolo punteggio composito di "salute" non è sufficiente per prendere queste decisioni. I ricercatori hanno dimostrato che affidarsi a una media ponderata di diversi fattori potrebbe essere pericoloso. Per esempio, un drone con un'ottima batteria e un'alta fiducia nel mittente potrebbe comunque avere una connessione wireless pessima. Se il sistema guardasse solo un punteggio medio, potrebbe permettere il passaggio di un comando nonostante il collegamento interrotto. Inveve, questo framework utilizza soglie rigide. Se il collegamento wireless scende sotto una certa qualità, o se il punteggio di fiducia del mittente scende sotto un numero specifico, il sistema restringe immediatamente l'autorità, indipendentemente da quanto siano buoni gli altri parametri. Ciò assicura che un fallimento in un'area critica non possa essere mascherato da un successo in un'altra. Il sistema traccia anche le "prove di manomissione", accumulando punti per diversi tipi di anomalie come messaggi riprodotti (replay) o discrepanze temporali. Se le prove accumulate sono sufficienti, il drone passa a uno stato in cui si affida solo ai propri sistemi di sicurezza locali.

I ricercatori hanno testato il loro framework software utilizzando un repository di unit test e simulazioni di scenari. Hanno confermato che il sistema ha correttamente respinto messaggi manomessi, comandi riprodotti e istruzioni da parte di mittenti con bassi punteggi di fiducia. Hanno inoltre misurato il tempo impiegato dal software per elaborare questi controlli di sicurezza. I risultati hanno mostrato che il percorso di autenticazione ha avuto una mediana di 12,219 millisecondi, con una media di 22,603 millisecondi. Sebbene questo sia abbastanza veloce per molte applicazioni software, l'autore sottolinea con cautela che questi numeri derivano da una simulazione su computer locale e non rappresentano una garanzia di tempo reale certificata per l'hardware di volo effettivo. Lo studio dichiara esplicitamente di non includere test di volo fisico, esperimenti di jamming radio o prove matematiche formali della perfezione del codice. Invece, fornisce un modello basato sul software e matematicamente esplicito su come le evidenze di sicurezza debbano essere convertite in autorità di controllo fisico.

Il framework include anche un'eccezione speciale per i comandi di emergenza. Se un comando viene contrassegnato come atterraggio di emergenza, il sistema permette di bypassare alcuni dei normali controlli di fiducia e di freschezza, a condizione che il messaggio abbia superato la verifica crittografica iniziale. Questa scelta di progettazione dà priorità alla sicurezza fisica immediata rispetto all'aderenza rigorosa al protocollo, riconoscendo che in una crisi un comando verificato di atterraggio è più importante di un comando di attendere ulteriori conferme. Tuttavia, questa eccezione è strettamente controllata; funziona solo se il messaggio passa attraverso il canale sicuro e autenticato. I ricercatori enfatizzano che questo override di emergenza è un confine di fiducia deliberato che deve essere gestito con cura.

In definitiva, questo lavoro dimostra che per le macchine autonome, la sicurezza non riguarda solo l'impedire l'accesso agli hacker; riguarda l'assicurarsi che la macchina sappia quando dire di no. Il sistema proposto crea una catena di difesa in profondità in cui un comando deve passare attraverso l'autenticazione, i controlli di freschezza, la valutazione della fiducia e i vincoli di sicurezza prima di poter influenzare i motori del drone. Separando la domanda "chi ha inviato questo" dalla domanda "dovremmo farlo", i ricercatori hanno creato un modello che potrebbe rendere gli sciami autonomi più resilienti sia agli attacchi informatici che ai guasti fisici. Lo studio conclude che, sebbene la logica del software sia solida e il rifiuto dei comandi non sicuri sia deterministico, la piena validazione di questo approccio richiede lavori futuri che coinvolgano test sull'hardware e scenari avversariali reali. Per ora, esso rappresenta un chiaro schema basato sul software di come i sistemi autonomi possano mantenere la sicurezza quando il mondo intorno a loro diventa incerto.