Una password preimpostata in un sistema embedded è sufficientemente sicura?

Bene, la preoccupazione principale qui è che un utente malintenzionato potrebbe intercettare il traffico tra la società di chipset e il tuo server.

Come fa il dispositivo a sapere che sta parlando al server corretto? Se ho intercettato il traffico tra il dispositivo e il server e ho fatto finta di essere il server, il dispositivo mi avrebbe dato felicemente la sua password?

Il modo "corretto" per farlo è usare SSL autenticato dal client. Ciò significa che invece di una "password", ogni dispositivo riceve un RSA o ECC coppia di chiavi e un certificato corrispondente dal server (che è un Autorità di certificazione in questo caso). Ciò ti consente di utilizzare il TLS handshake autenticati dal client bidirezionale

Esistono modi sicuri per fare l'autenticazione usando un segreto precondiviso noto sia al server che al client, ma "ecco la mia password, assicurati che corrisponda!" non è uno di questi (almeno non senza risolvere autonomamente il problema "come faccio a sapere che sto parlando al server corretto?"). Un modo è quello di avere entrambi i fini MAC il massaggio con una chiave derivata dal segreto condiviso. Quindi l'altra parte può calcolare lo stesso MAC usando la loro copia del segreto condiviso e assicurarsi che venga fornito con lo stesso MAC. Un altro modo è utilizzare AES nella modalità di crittografia autenticata (AE) .

... Oppure, come @SEJPM sottolinea, salta l'intera cosa "rolling your own" e usa uno dei Codice di sicurezza cifrature precondivise (TLS-PSK) .

Senza il client che verifica il server, qualsiasi schema come questo è vulnerabile alla rappresentazione. Specificamente, implementando un falso server e costringendo il client a connettersi ad esso (magari attraverso una regola del firewall), il server falso riceverà i dettagli inviati dal client e potrebbe quindi utilizzarli per inviare ulteriori contenuti dannosi al server legittimo .

Per proteggersi da questo, il client potrebbe confrontare il certificato del server legittimo con quello del server a cui si sta connettendo e inviare solo i dati se corrisponde. Tuttavia, ciò richiederebbe al client di conoscere il certificato pubblico corrispondente alla parte privata utilizzata dal server, che non è sempre possibile nei dispositivi integrati (ad esempio, tendono ad essere privi della capacità di aggiornamento in caso di modifiche del certificato).

Pertanto, sarebbe possibile utilizzare altri metodi che consentono a entrambe le estremità di verificare l'altro: forse un nonce, generato dal server e inviato al client, hash con un metodo predefinito (ad es. concatenare un pre stringa definita al nonce, quindi hashing con un algoritmo di hashing crittografico) e restituita. Poiché la stringa predefinita non viene mai inviata, questo dovrebbe essere difficile da interrompere senza l'accesso al dispositivo o al server (entrambi i quali devono conoscere la stringa), anche se si conosce il nonce per una determinata richiesta.

In sostanza, è necessario verificare che si stia comunicando con l'altro dispositivo previsto, da entrambe le estremità, per essere sicuri che i dati non possano essere manomessi. Questo però comporta più passaggi.

A rischio di essere eccessivamente generosi, la tua soluzione è sicura salvo due circostanze.

"Each device has its own copy of the Particle cloud public key"

Ciò significa che (salvo un bug del software che consente a qualcosa come l'ingannare il client di utilizzare una versione debole di TLS / SSL) il dispositivo sarà semplicemente in grado di parlare con il server che ha la chiave privata corretta, ovvero il "Particle cloud" ospite. Pertanto, il server e il dispositivo hanno una forma di autenticazione a due vie ed è fatto in segreto, quindi c'è riservatezza e non ripudio.

L'altra estremità libera è, cosa succede se la chiave privata di Particle Cloud dovesse essere compromessa? Una corretta gestione dei certificati (tramite CA) consente questa inevitabilità invalidando una chiave e sostituendola con una nuova. Se la chiave è hardcoded, sembra che sia possibile solo tramite un aggiornamento del firmware.

Gli aggiornamenti del firmware sono disponibili in-band? fuori dalla band? solo come parte di questa meccanizzazione del cloud? Affatto? La risposta potrebbe essere ciò che determina quanto sei a tuo agio nel credere che il canale di comunicazione sia pronto per le applicazioni di sicurezza della vita. Qualsiasi problema con questi due avvertimenti potrebbe lasciare i dispositivi tristemente non protetti fino a quando un aggiornamento del firmware per correggere il problema viene fatto a tutti i dispositivi, in modo sicuro (non posso fidarci del cloud per spingerlo di più se la chiave è compromessa, eh?)