Sicurezza modulare per un UAV fotografico?

Quando il modulo principale comunica solo con il modulo radio attraverso il modulo di sicurezza, il modulo di sicurezza potrebbe fare tutte le comunicazioni con il server di base firmato e crittografato senza che il modulo principale ne se ne accorga.

Ma la comunicazione tra server di base e UAV non è l'unico vettore di attacco a cui si potrebbe pensare.

Gli UAV sono spesso equipaggiati con diversi tipi di sensori. Quando si ha una vulnerabilità nell'interpretazione dei dati del sensore nel modulo principale, ciò sarebbe sfruttabile (esempio: innescare un overflow di un intero quando si interpreta il livello di luminosità di un sensore fotografico puntando un laser su di esso). E puoi anche dimenticare di filtrare i dati del sensore attraverso il modulo di sicurezza, perché il modulo di sicurezza non può sapere quale tipo di ingresso del sensore attiverà un errore nel modulo principale.

Lo stesso vettore di attacco si applica quando sono presenti dati dannosi che provengono dal server di base stesso. Quando il server di base non è affidabile, il modulo di sicurezza non sarà in grado di fare nulla al riguardo perché non sa quale attività malevola cercare. Questo vettore di attacco potrebbe anche manifestarsi quando il server di base riceve informazioni da una fonte esterna e lo inoltra al filtro non filtrato.

Inoltre, non protegge dall'accesso fisico. Un utente malintenzionato con accesso fisico sarebbe in grado di posizionare un terzo chip tra il modulo principale e il modulo di crittografia per MITM la comunicazione non crittografata tra questi due chip (presupponendo che stiamo parlando di due moduli che sono separati fisicamente e non solo caratteristiche logicamente separate dello stesso chip )

either remote attacks or physical attack to a single UAV which can give control over a fleet of similar UAV's

Se questo è il tuo unico obiettivo, l'architettura di sicurezza dello stesso UAV è irrilevante. Tutto ciò di cui hai bisogno è di evitare segreti di classe, cioè non avere nulla che tu voglia tenere segreta e includere in ogni dispositivo. Qualsiasi buona architettura di sicurezza evita i segreti di classe. Ciò significa che non si basa sulla sicurezza dell'oscurità e, per qualsiasi crittografia, usa chiavi diverse in ogni dispositivo. Ogni UAV genera le proprie chiavi segrete per uso interno e ha le proprie chiavi private per la comunicazione con l'esterno.

Tuttavia, se sei preoccupato per gli attacchi, allora presumibilmente gli UAV hanno risorse (e probabilmente sono beni in sé stessi). Per questo, l'architettura di sicurezza del dispositivo ovviamente conta.

Contro gli attacchi software portati dall'esterno, ha senso un modulo di sicurezza dedicato. Chiedi di mediare tutte le comunicazioni e di essere il repository delle chiavi crittografiche utilizzate per la comunicazione. Inoltre, è responsabile di garantire l'integrità e l'esecuzione degli aggiornamenti software su altri componenti, forse memorizza il firmware per tutti gli altri componenti.

Tuttavia, dovrai comunque assicurarti che i singoli componenti siano privi di errori. Il modulo dedicato funge da firewall contro le richieste maligne dall'esterno, ma se gli altri moduli si comportano male su comandi validi, il gioco viene perso. Se un bug in un servocomando fa sì che l'UAV scenda invece di alzarsi e si blocchi, il modulo di sicurezza non può aiutarti.

Devi pensare alla base attendibile del tuo dispositivo. Quali parti del dispositivo sono fondamentali per il suo corretto funzionamento? Come spiega Philipp , la risposta è lotti . Sono necessari molti sensori, motori, ecc. Affinché l'UAV funzioni correttamente (a partire da: non si blocca). Se il modulo controller riceve dati errati o se i motori non girano alla velocità richiesta dal controller, il dispositivo si comporta in modo anomalo; quindi tutti i sensori e i motori sono parte della base attendibile.

Il meglio che puoi sperare è un'architettura in cui la maggior parte dei componenti può influenzare solo se stessi, ad es. un sensore che non funziona correttamente non può modificare le letture di un altro sensore o impedire che l'altro sensore segnali. Questo esempio richiede un corretto isolamento sui bus di dati e un'autenticazione corretta di ciascun sensore nel proprio controller.

Contro gli attacchi hardware, questo modello si rompe ancora di più. Se qualcuno ha accesso fisico al dispositivo, allora avrà un accesso abbastanza facile a molti bus di dati. Ciò che il sensore riporta non è necessariamente ciò che riceve il controllore: potrebbe essere un'iniezione di dati da parte dell'aggressore. Per evitare ciò, è necessario portare la crittografia in tutti i sensori. Ciò solleva la barra per un aggressore, ma non è una panacea. Un utente malintenzionato con accesso fisico può sempre perturbare le letture del sensore, facendo sì che il sensore effettui rapporti accurati di informazioni inutili, ad es. oscurando una fotocamera, tenendo una fonte di calore vicino a un termometro, ecc.