Aggiornamento dell'impronta digitale SSL su un dispositivo IoT

Naviga le tue risposte
1

Attualmente sto progettando il modello di sicurezza per un prodotto IoT che la mia azienda sta sviluppando.

Il dispositivo sarà connesso a Internet tramite WiFi e dovrà comunicare solo con il server della nostra azienda.

  • La comunicazione verrà effettuata tramite HTTPS
  • Durante l'assemblaggio del prodotto fisico, l'impronta digitale SSL del server verrà memorizzata sul dispositivo. Il dispositivo utilizza questa impronta digitale per assicurarsi che in realtà comunichi con il proprio server "di casa" ogni volta che stabilisce una connessione

Un problema con questo approccio sorge non appena il certificato SSL del server cambia. A causa di un controllo impreciso delle impronte digitali, tutti i dispositivi sul campo non saranno più in grado di connettersi al server.

Una soluzione parziale sarebbe quella di creare un periodo di tempo in cui il server distribuisse la sua nuova impronta digitale a tutti i dispositivi connessi, insieme al tempo esatto in cui diventa valido. I dispositivi potrebbero memorizzare la nuova chiave e usarla a partire dalla data pubblicizzata. Ma questo non risolve il problema per i dispositivi che non sono online durante il periodo di distribuzione delle impronte digitali.

C'è qualche potenziale soluzione a questo problema che potrei aver trascurato? Qual è la "via giusta" per fare una cosa del genere? (Non posso essere il primo a farlo, posso?)

    
posta Oromis 10.04.2017 - 17:21
fonte

2 risposte

2

Sembra che tu non abbia creato un meccanismo di aggiornamento per il prodotto che stai rilasciando. Ciò è molto più preoccupante dell'aggiornamento delle firme per i certificati aggiunti. Come verrà aggiornato il prodotto nel caso in cui sia necessario apportare miglioramenti alla sicurezza o correggere i bug?

Il prodotto dovrebbe essere rilasciato con una firma iniziale per tutte le connessioni TLS. Il meccanismo di aggiornamento dovrebbe essere in grado di estrarre un'immagine firmware aggiornata e distribuirla sul dispositivo. Il dispositivo deve richiedere questi aggiornamenti solo tramite un canale crittografato TLS. Il codice di implementazione dell'aggiornamento lato server dovrebbe firmare tutti gli aggiornamenti del firmware con una chiave privata. La chiave pubblica utilizzata per la convalida della firma deve essere incorporata nel firmware quando viene rilasciato il dispositivo. In questo modo è possibile aggiornare le firme TLS utilizzando il meccanismo di aggiornamento e le chiavi pubbliche utilizzate per la convalida dell'immagine del firmware.

Assicurati di aggiornare i valori delle firme TLS e le chiavi pubbliche utilizzate per la convalida dell'immagine prima che scadano, questo potrebbe significare che hai un periodo di aggiornamento di 3 mesi prima della scadenza di entrambi. Questo periodo dovrebbe essere definito in base al tempo impiegato dagli utenti per aggiornare il prodotto; vuoi dare a tutti un tempo significativo per aggiornare il loro dispositivo e un metodo per eseguire un download / aggiornamento del firmware manuale nel caso in cui questi valori / chiavi non vengano aggiornati prima della loro scadenza.

    
risposta data 10.04.2017 - 18:20
fonte
1

Perché non utilizzare sul tuo server un certificato attendibile da un'autorità di certificazione, in modo che i tuoi IoT possano utilizzare i meccanismi PKI esistenti per verificare la revoca e puoi cambiare il certificato del server in qualsiasi momento.

    
risposta data 11.04.2017 - 13:06
fonte

Leggi altre domande sui tag

Errore Ettercap - 'L'avvelenamento ARP richiede un elenco di host non vuoto' Perché le società di carte di credito generalmente si limitano all'infrastruttura di dati a 16 cifre? [chiuso]