Valutazione della sicurezza di un'implementazione SSL/TLS legacy su un dispositivo IoT
Sto effettuando una valutazione della sicurezza sulla sicurezza delle comunicazioni di un dispositivo IoT legacy. L'obiettivo è valutare e trovare lacune di sicurezza nell'attuale progettazione/implementazione.
La modalità di valutazione è manuale, principalmente con riferimento al progetto e al codice esistenti. Questo è solo lato client sul dispositivo; mentre il server è un server basato su cloud. Il dispositivo utilizza un modulo GSM (SIMCom SIM900) ed effettua la comunicazione HTTPS con il server su Internet utilizzando i comandi GSM AT.
Sulla base delle mie conoscenze su SSL/TLS, sto prendendo in considerazione i seguenti parametri o criteri per questa valutazione:
un. Versione del protocollo TLS
b. Suite di cifratura utilizzate
c. certificato e gestione delle chiavi
d. Root CA installate sul dispositivo
e. Aspetto PKI integrato per la gestione dell'identità del dispositivo
f. Aspetto crittografico hardware (SHE/TPM)
Lo sto facendo nel modo giusto? Anche se penso che l'elenco di parametri sopra non sia specifico per la piattaforma HW/SW del dispositivo; piuttosto generico. ma immagino che sia così che dovrebbe essere! Voglio dire, l'elenco dei parametri sarà praticamente lo stesso; tuttavia la valutazione effettiva su questi dipenderà dai requisiti di sicurezza e da altri aspetti come l'impronta del dispositivo e la sua piattaforma, ecc.
L'elenco dei parametri di valutazione che sto considerando è buono e adeguato?
Risposte
Questo è un buon inizio, ma una valutazione approfondita dovrebbe andare molto più in profondità di così. Per esempio:
In che modo il client genera numeri casuali? Usa un CSPRNG ? Oppure utilizza un debole generatore di numeri casuali, come quello utilizzato nelle prime versioni di Netscape Navigator , in cui un utente malintenzionato passivo era in grado di indovinare i numeri casuali generati per le chiavi di sessione e quindi decrittografare il testo cifrato che attraversava la rete.
Il client perde informazioni quando incontra un errore di riempimento? In tal caso, potrebbe essere suscettibile a un attacco Oracle di riempimento , come nel caso di Steam Gaming Client .
In che modo il cliente implementa ECDSA ? Il client genera una nuova k casuale per ogni firma che crea? In caso contrario, potrebbe essere possibile per un utente malintenzionato passivo calcolare la chiave di firma privata dopo aver osservato alcune firme, come nel caso della Sony Playstation 3 .
Questi sono solo alcuni esempi. Ma, come puoi vedere, piccoli errori nell'implementazione della crittografia possono avere conseguenze disastrose. Questo è il motivo per cui la crittografia è così difficile da ottenere correttamente.