Aeromobili a pilotaggio remoto

Nel precedente articolo si è parlato di quali sono i rischi di un utilizzo non corretto degli aeromobili a pilotaggio remoto per la pubblica incolumità intesa come possibilità di arrecare sia direttamente danni alle persone sia indirettamente nei confronti di veicoli/velivoli, strutture pubbliche civili e militari, et similia.

Si è concluso argomentando che non è sufficiente stabilire delle regole senza sapere con certezza chi le fa rispettare (normalmente una legge stabilisce termini, regole, sanzioni e chi è deputato ad irrogarle) o quali sono le regole di ingaggio (un poliziotto che vede un drone sorvolare un’area deve sapere a priori se il drone è autorizzato? E’ autorizzato ad utilizzare l’arma per annientare il velivolo[1]? Deve chiamare l’aeronautica militare? etc).

Si è andati oltre: i droni possono essere facilmente utilizzati per incettare informazioni sul territorio (immagini e video di luoghi di culto, veicoli o caserme militari, case circondariali, etc) da trasmettere all’insaputa del pilota a chicchessia oppure per porre in essere attività illecite come trasportare sostanze stupefacenti, esplosivo, carburante o, peggio, provocare attentati terroristici.

L’approfondimento, questa volta, viene rivolto a due aspetti: come vola un drone e come stabilire se il software che controlla un drone è sicuro.

COME VOLA IL DRONE

La maggior parte dei droni in commercio sono controllati attraverso software:

dell’apparato volante;
del radio comando;
del device (smartphone, tablet, et similia – solitamente attraverso una app iOS o Android).

L’interazione tra questi tre elementi permette il “pieno” controllo del drone.

Figure 1 – Interazione radio commando / device / drone

Il primo problema che si pone afferisce alle possibili intrusioni esterne in questo sistema. Molti droni utilizzano, infatti, come frequenza di controllo device/radio comando, la 2.4 Ghz, che è la stessa frequenza utilizzata spesso per la WiFi domestica[2]. L’encryption WPA2 ed il service set identifier (SSID), ovverosia il nome della rete wifi generata dal radiocomando, è spesso facilmente riconoscibile ai più come un drone. La password, altresì, è quasi sempre la medesima di default, tutti elementi (leggasi vulnerabilità), questi, che lasciano presagire che con qualche nmap e un po’ di (buon!) reverse engineering l’intrusione sia facile e silente[3].

Figure 2 – Analisi del Governo Iraniano di un RQ-170

Altra problematica afferisce all’utilizzo della rete internet da parte del device. Ne è esempio principale la cartografia. Il pilota del drone, infatti, può utilizzare diverse funzionalità che gli permettono il volo su punti fissi o semplicemente di vedere la posizione geografica del drone in modalità live.

Normalmente questa possibilità è data se lo smartphone o il tablet sono connessi alla rete internet. E’ facile pensare, quindi, che la possibilità per l’applicazione device di connettersi alla rete internet possa tranquillamente permettere, seppure potenzialmente, la trasmissione di immagini, video, suoni a soggetti “terzi” rispetto alle operazioni di volo. Tutto questo, evidentemente, all’insaputa del pilota che non rileverebbe alcun’anomalia e potrebbe essere, invece, artefice a titolo di concorso in attività illecite di natura penale o, peggio, terroristica.

L’alternativa, sarebbe, impostare il tablet in “modalità aereo” ma ne deriverebbero evidenti svantaggi[4]. Altresì, terzi potrebbero assumere da remoto il pieno controllo del drone che potrebbe essere diretto contro obiettivi sensibili per schiantarvisi.

Chi ne risponderebbe? Evidentemente il pilota, sotto il profilo civilistico ma anche penale del caso.

STANDARD SOFTWARE PER LA SAFETY E LA SECURITY

Come visto, questi sistemi hanno una forte dipendenza dal software per comando, controllo e comunicazione. Ne deriva che la security è un aspetto molto importante nella progettazione, sviluppo e creazione di un drone. Questo può essere considerato sicuro solo se può essere immunizzato da tentativi di intrusione da parte di terzi.

Nel mondo aeronautico ci sono due tipologie di standard che possono essere adottati per considerare il software di un APR “sicuro” sotto l’aspetto della sicurezza verso i terzi (safety) o della sicurezza sistemistica (security):

gli standard di processo che afferiscono allo sviluppo da seguire per garantire che il prodotto finito sia scritto in modo safe (DO-178) o in modo secure (ISO 14508);
standard di codifica che descrivono un sottoinsieme di linguaggio di programmazione di alto livello e che assicurano che il software sia scritto il più possibile in modo safe (MISRA C) e in modo secure (CERT C).

La ISO 14508 (noto anche come “Common Criteria”) è uno standard internazionale orientato ai processi che definiscono quali debbano essere i requisiti di sicurezza IT. Questi sono classificati in base a sette livelli di garanzia del test di valutazione (EAL), come mostrato nella tabella che segue. EAL 7, evidentemente, rappresenta il sistema più sicuro.

I requisiti funzionali di sicurezza comprendono comunicazioni, crittografia, protezione dei dati, autenticazione, gestione della sicurezza, audit, privacy e protezione degli obiettivi di valutazione (TOE).

Criteri comuni di valutazione del livello di garanzia	Rigore di processo richiesto per lo sviluppo di un prodotto IT
EAL 1	Funzionalmente testato
EAL 2	Strutturalmente testato
EAL 3	Metodicamente testato e verificato
EAL 4	Metodicamente progettato, verificato e riesaminato (cross-check)
EAL 5	Informalmente progettato e testato
EAL 6	Informalmente verificato, progettato e testato
EAL 7	Formalmente progettato e disegnato

Il software sviluppato per l’utilizzo negli APR rientra nelle linee guida di DO-178[5].

Sia DO-178B, che il recentemente approvato DO-178C, forniscono linee guida dettagliate per la produzione di tutti i software di sistema per velivoli (tout court intesi) ed il loro equipaggiamento e ne stabiliscono la criticità sotto l’aspetto safety. Come parte di queste linee guida, i richiamati standard B/C definiscono i livelli di garanzia di progettazione (DAL)[6]. DO-178 traduce questi DAL in livelli software (come mostrato nella tabella che segue). Ciascun livello software ha obiettivi associati che devono essere soddisfatti durante lo sviluppo.

Livello	Condizione di fallimento	Descrizione
A	Catastrofico	Il fallimento ne può causare crash
B	Pericoloso	Il fallimento ha un vasto impatto sulle performance di safety
C	Maggiore	Il fallimento è significativo, ma ha meno impatto del livello B
D	Minore	Il fallimento è evidente, ma ha meno impatto del livello C
E	Senza effetto	Il fallimento non impatta sulla sicurezza delle operazioni del velivolo

Come è dato immaginare, il richiamato standard affronta in modo sistematico l’intero ciclo di sviluppo del software. Per questo, agli sviluppatori occorre:

tracciarne i requisiti;
procedere con
1. progettazione metodica;
2. codifica e convalida;
3. verifica

Questi due ultimi punti, in particolare, garantiscono la fiducia e la correttezza, nonché il controllo del software. Solidi processi di validazione e verifica dello stesso consentono agli sviluppatori di rilevare e correggere gli errori introdotti durante il suo sviluppo.

Quindi, DO-178 si concentra esclusivamente sulla sicurezza del software nel sistema di bordo del velivolo, mentre ISO 14508 si concentra sulla sicurezza del sistema[7]. Non è tuttavia obiettivo di questo articolo quello di scendere nel merito di una tematica la cui conoscenza sarebbe ristretta ai pochi. Riassumendo, quindi, esistono regole e standard internazionali che stabiliscono quali debbano essere i canoni per la scrittura, il controllo e la validazione (cross-check) del software di bordo di un velivolo, sia sotto l’aspetto safety che sotto quello della security[8]. Non è sufficiente, quindi, catechizzare e sottoporre a sanzioni il comportamento non corretto di un pilota di drone se questo liberamente può decidere, sotto altro impulso, di andarsi a fare un giro, ad esempio nella prospicente caserma militare, trasmettendo a chicchessia coordinate, rilevamenti, fotografie, filmati o altre utili informazioni.

CONCLUSIONI

La società moderna è abituata a guardare molto più lontano rispetto ai nostri antenati. La tecnologia fa quotidianamente passi da gigante: quello che è certo e commerciale oggi già domani può essere incerto e fuori dal mercato. In questa tempesta tecnologica, però, è necessario stabilire regole (qualcuno le chiamerebbe standard) per poter guardare al futuro senza dimenticare di preservare la sicurezza delle persone.

Occorre dapprima che le norme identifichino gli APR come velivoli complessi che, prima di essere immessi nel mercato, debbano superare specifici test previsti non dall’azienda madre ma da soggetti certificati europei. Successivamente occorre prevedere strumenti per neutralizzare efficacemente una minaccia proveniente dall’alto.

Nessuno prima dell’11 settembre avrebbe pensato che due aerei di linea sarebbero stati utilizzati per colpire il cuore dell’economia mondiale, così come nessuno avrebbe potuto pensare, il 14 luglio 2016, che un camion a Nizza avrebbe provocato la morte di 84 persone. Ancora, tutti inconsapevolmente si fidavano di Facebook, pubblicando foto, video, messaggi personali e dando la possibilità di recuperare informazioni dalla rubrica, dalla lista chiamate ed SMS, eppure lo scandalo di Cambridge Analytica ha dimostrato quanto labile possa essere il confine tra uso ed abuso.

Occorre, dunque, anticipare gli eventi[9] e pensare che gli APR potrebbero fare ben peggio; occorre sensibilizzare l’opinione pubblica e pensare che i droni non sono giocattoli volanti ma, nonostante le dimensioni, veri e propri velivoli complessi.

Se sia sufficiente un UTM (Unmanned Aerial Vehicles Traffic Management) come di recente annunciato da Enav[10]?

La risposta è assolutamente negativa se trattasi esclusivamente del controllo e gestione del traffico aereo dei velivoli a pilotaggio remoto “cooperanti”, ovverosia registrati, autenticati e identificati (sotto i 25kg).

Ma ognuno, giustamente, risolve i problemi di casa propria.

NOTE

[1] http://www.gazzettadelsud.it/news/catanzaro-crotone-vibo-lamezia/279510/carabinieri-abbattono-drone-ostacolava-operazione.html;
[2] Normalmente,5.725GHz – 5.825GHz tra radio comando e apparato volante;
[3] Basta ricordare, tra i tanti, l’episodio del 4 dicembre 2011 quando un Lockheed Martin RQ-170 Sentinel della CIA fu catturato dalle forze iraniane vicino la città di Kashmar. In quel caso non solo fu perpetrato uno specifico attacco al sistema GPS del UAV ma, una volta a terra, furono effettuate operazioni di reverse engineering. Nell’aprile del 2012, infatti, la IRGC (Islamic Revolutionary Guard Corps) annunciò di essere riuscito non solo nell’estrazione dei dati ma anche di essere pronti a costruire una replica del drone stealth. Nel settembre 2016, l’agenzia di stampa Tasmin annunciò l’ultimazione del Saegheh (“Fulmine”), simile allo RQ-170 in grado di trasportare, tra l’altro, quattro bombe con guida di precisione (presentato in Russia il 27 ottobre 2013). La notizia era data per incerta ma il 10 febbraio 2018, un elicottero Apache della IAF (Israeli Air Force) ha abbattuto un drone iraniano che è stato considerato copia del RQ-170 della CIA.
http://www.ilgiornale.it/news/mondo/israele-luav-abbattuto-copia-drone-cia-1493660.html
[4] E’ tuttavia possibile su alcuni modelli di droni pre-caricare i dati cartografici prima di entrare in modalità aereo caricando la mappa e scorrendo intorno alla zona in cui si volerà. I dati della mappa rimarranno visibili anche se la modalità aereo è abilitata;
[5] Considerazioni sul software nella certificazione di sistemi ed apparecchiature per via aerea;
[6] Design Assurance Levels, il livello A che implica la più rigorosa salvaguardia contro i guasti;
[7] Questi, inoltre, raccomandano l’uso di sottoinsiemi di linguaggio come MISRA C: 2012 per la safety e CERT C o CWE per la security. Questi sottoinsiemi di linguaggio constano principalmente di elenchi di costrutti e pratiche da evitare per gli sviluppatori al fine di garantire un codice sicuro o protetto.
[8] Si parla, pertanto, di standard: non obbligo per alcun produttore di sottoporre a regole così stringenti il proprio gruppo di sviluppatori. Anche perché la sicurezza (safety o security), come tutto, ha un costo e se nessuno la impone: “grasso che cola!”;
[9] Uno studio prospettico condotto dalla Sesar Joint Undertaking, nel contesto del Single European Sky, ha stimato che nel 2035 ci saranno oltre 7 milioni di droni nei cieli europei.
[10] https://www.ilmessaggero.it/tecnologia/scienza/leonardo_droni_accordo_enav_telespazio_ids_traffico_aereo-3755334.html ;

A cura di: Nicola Tigri

Profilo Autore

Nicola Tigri

Già Ufficiale d’Accademia della Guardia di Finanza, congedatosi nel grado di Capitano.
Nell’ultimo incarico è stato al comando della Sezione Sicurezza/Audit e E-Government del Comando Generale del Corpo. Già responsabile del Security Operation Center (SOC) della GDF, membro del Computer Emergency Responce Team del Ministero dell’Economia e delle Finanze (CERT-MEF) in qualità di NaIT, membro del Tavolo permanente interministeriale per gli adeguamenti al GDPR.
Esperto di cybersecurity ed acquisitore/analista forense certificato, è pilota d’ala fissa (PPL-A) e pilota di droni (abilitato per operazioni cd. critiche).