Best practice per implementare HTTPS nei dispositivi embedded

Question

Best practice per implementare HTTPS nei dispositivi embedded

#1 da (1 voti)
#2 da (0 voti)

7

I dispositivi integrati, come router, telecamere IP, in genere forniscono l'accesso HTTPS all'interfaccia di amministrazione. Queste implementazioni HTTPS generalmente hanno molti problemi (certificati non univoci, certificati autofirmati, ecc.), Che rendono insicure le connessioni. Quindi, sto cercando le migliori pratiche, in che modo un dispositivo integrato può implementare HTTPS in modo sicuro, che soddisfa i seguenti requisiti:

Il browser che accede al dispositivo tramite HTTPS (sia da remoto che da LAN) non visualizza alcun avviso per l'utente. Pertanto il browser è in grado di convalidare correttamente il certificato inviato dal dispositivo.
Se la chiave privata del dispositivo è stata compromessa, un utente malintenzionato non dovrebbe essere in grado di utilizzare questa chiave per eseguire l'attacco MitM contro un altro dispositivo o un'altra pagina Web.
Se fosse possibile, gli utenti non dovrebbero installare alcun certificato o accettare alcuna eccezione nei loro browser.

tls certificates embedded-system

posta ebux 26.04.2016 - 10:26

fonte

2 risposte

Leggi altre domande sui tag tls certificates embedded-system

Quanto dovrei andare lontano nel creare l'anonimato? Come attrarre traffico verso un honeypot

score 1 · Answer 1

È possibile che un dispositivo rimanga non venduto / inutilizzato per un paio di anni dopo la sua data di produzione e la maggior parte (se non tutte) le CA probabilmente non saranno disposte a emettere certificati di dispositivo con lunghe scadenze, quindi una scala la soluzione avanzata è forse poco pratica.

Tuttavia, propongo la seguente alternativa:

Utilizza un metodo alternativo per stabilire la fiducia iniziale tra il dispositivo e il client. Ad esempio, questa può essere una VPN IPSec / L2TP con un PSK per dispositivo. Il trasferimento fuori banda di PSK impedisce MitM (a meno che il PSK non sia noto all'attore).
Utilizza HTTP (tramite VPN) per scaricare una CSR dal dispositivo. Il dominio può essere un sottodominio casuale di un dominio controllato dal produttore / fornito dall'utente.
Utente / cliente invia il CSR a una CA per conto del dispositivo e ritrasmette il certificato firmato al dispositivo tramite HTTP. La CA dovrebbe invitare le regole a non emettere nuovamente certificati per un sottodominio.
Il dispositivo applica i certificati e i parametri di comunicazione a HTTPS.
Quando il certificato sta per scadere, il dispositivo invia una richiesta di rinnovo firmata alla CA (tramite il client / l'utente, se necessario).

Ovviamente, la suddetta "danza" è meglio automatizzata da un programma.

Analisi di sicurezza

L'identità del dispositivo è stabilita dalla conoscenza di PSK.
MitM e intercettazioni sono impediti dal protocollo VPN (con PSK)
La chiave privata del dispositivo non viene mai rivelata (e può essere generata su richiesta anziché programmata in fabbrica) a causa del modo in cui CSR funziona
È possibile utilizzare un certificato valido per dispositivo che soddisfi tutti i requisiti
Sottodominio casuale, non specifico del dispositivo impedisce a un impostore di registrare preventivamente un certificato

score 0 · Answer 2

I punti 1 e 2 sono indirizzati acquistando un certificato da una CA affidabile.

Per quanto riguarda il tuo secondo punto -

If the private key of the device was compromised, an attacker should not be able to use this key to perform MitM attack against another device

Se riesci a trovare un modo per farlo, sarai molto ricco.

or another web page.

Eh? Non capisco.

Mentre i dispositivi di questo tipo che ho usato in passato sono stati spediti senza certificato, forniscono un mezzo per distribuire il certificato (e la chiave privata) sul dispositivo. Certamente non puoi fidarti di un certificato fornito con l'hardware a meno che tu non abbia inviato la richiesta di canto del certificato al fornitore (e abbia mantenuto la chiave privata).