Sto sviluppando software per un progetto satellite universitario e sto attualmente lavorando sui protocolli di comunicazione. Ecco le restrizioni:
- I pacchetti radio dovrebbero essere considerati non più grandi di 256 byte
- I pacchetti radio dovrebbero incorporare una sorta di correzione degli errori in avanti
- I pacchetti radio devono essere crittografati, se possibile.
Con questo in mente, abbiamo selezionato il Reed-Solomon in avanti il protocollo di correzione degli errori , che fornisce 223 byte di dati per una lunghezza del messaggio di 255, aggiungendo 32 blocchi di parità per un massimo di 16 byte di recupero degli errori.
I contenuti principali delle nostre trasmissioni saranno basati su un protocollo di trasferimento file sviluppato internamente che consente di selezionare il file binario all'interno di un file in "blocchi" per la trasmissione. Questi pezzi sono limitati per essere di lunghezza 223, per Reed-Solomon. I file up-and-down-link saranno archivi tar, contenenti le pianificazioni delle missioni e gli script della shell.
Per permetterci di effettuare il multiplex su più satelliti sulla stessa frequenza (o abbastanza vicino da poter ricevere tutti un determinato pacchetto), e per offrire una certa protezione contro gli attacchi di replay, ad ogni "sessione" viene assegnato un ID di sessione da 1 byte, che deve rientrare nella classe di equivalenza assegnata da un dato satellite affinché il satellite possa prestare attenzione. Deve anche essere il prossimo nella sequenza in base alla dimensione del modulo che assegniamo (16 in questo caso, per consentire 16 sat sulla stessa frequenza). Questo farà parte dei blocchi non in chiaro che trasmettiamo.
Abbiamo anche, per requisiti di missione, l'accesso diretto alla shell attraverso l'uso di pacchetti di "inoltro dei comandi", che essenzialmente riempiono i 223 byte con alcuni metadati e una stringa da passare direttamente nella shell con i permessi di root. Questo è l'enorme buco nella nostra configurazione attuale, ma non può essere reso più restrittivo, poiché abbiamo bisogno del massimo controllo del satellite da terra in situazioni di emergenza.
Recentemente ho ricevuto l'approvazione per far volare AES, che credo utilizzerò per crittografare completamente questi pacchetti e impedire qualsiasi accesso indesiderato. Abbiamo pieno accesso a libcrypto da OpenSSL. Posso includere ulteriori metadati per fornire l'autenticazione e la stringa da eseguire nella shell, ma abbiamo ancora bisogno che detta stringa sia lunga almeno ~ 100 byte. Tutto ciò deve essere contenuto in un solo pacchetto radio, poiché non possiamo essere certi che i pacchetti arrivino tutti alla radio dall'altra parte.
Ho pensato che potremmo usare AES-192, dato che ci avrebbe dato 216 byte cifrati, lasciando gli ultimi 7 byte a testo in chiaro. Potremmo anche far rispettare quelli che devono essere cancellati o riempiti con i dati di un PRNG, ma mi piacerebbe mantenerli pienamente utilizzati se possibile. Il testo in chiaro è probabilmente adatto alla trasmissione di blocchi di file binari, i cui contenuti sono per lo più uniformemente casuali secondo la mia analisi.
Esiste un modo trattabile per proteggere il buco della shell di root mentre ci stiamo ancora fornendo una "downlink" decente?