Procedure di sicurezza per i produttori di dispositivi Azure IoT

  • Articolo

Man mano che più produttori rilasciano dispositivi IoT, è utile identificare le indicazioni sulle procedure comuni. Questo articolo riepiloga le procedure di sicurezza consigliate da considerare quando si producono dispositivi da usare con il servizio Device Provisioning di Azure IoT.

  • Selezione delle opzioni di autenticazione del dispositivo
  • Installazione dei certificati nei dispositivi IoT
  • Integrazione di un modulo TPM (Trusted Platform Module) nel processo di produzione

Selezione delle opzioni di autenticazione del dispositivo

L'obiettivo finale di qualsiasi misura di sicurezza dei dispositivi IoT è creare una soluzione IoT sicura. Tuttavia, problemi quali limitazioni hardware, costi e livello di esperienza di sicurezza influisce tutte sulle opzioni scelte. Inoltre, l'approccio alla sicurezza influisce sul modo in cui i dispositivi IoT si connettono al cloud. Anche se esistono diversi elementi di sicurezza IoT da considerare, un elemento chiave che ogni cliente rileva è il tipo di autenticazione da usare.

Tre tipi di autenticazione ampiamente usati sono certificati X.509, TPM (Trusted Platform Modules) e chiavi simmetriche. Sebbene esistano altri tipi di autenticazione, la maggior parte dei clienti che creano soluzioni in Azure IoT usa uno di questi tre tipi. Il resto di questo articolo rileva vantaggi e svantaggi dell'uso di ogni tipo di autenticazione.

Certificato X.509

I certificati X.509 sono un tipo di identità digitale che è possibile usare per l'autenticazione. Lo standard di certificato X.509 è documentato in IETF RFC 5280. In Azure IoT esistono due modi per autenticare i certificati:

  • Identificazione personale. Un algoritmo di identificazione personale viene eseguito su un certificato per generare una stringa esadecimale. La stringa generata è un identificatore univoco per il certificato.
  • Autenticazione DELLA CA basata su una catena completa. Una catena di certificati è un elenco gerarchico di tutti i certificati necessari per autenticare un certificato di entità finale (edizione Enterprise). Per autenticare un certificato edizione Enterprise, è necessario autenticare ogni certificato nella catena, inclusa una CA radice attendibile.

Pro per X.509:

  • X.509 è il tipo di autenticazione più sicuro supportato in Azure IoT.
  • X.509 consente un elevato livello di controllo ai fini della gestione dei certificati.
  • Molti fornitori sono disponibili per fornire soluzioni di autenticazione basate su X.509.

Cons per X.509:

  • Molti clienti potrebbero dover affidarsi a fornitori esterni per i certificati.
  • La gestione dei certificati può essere costosa e aggiunge al costo totale della soluzione.
  • La gestione del ciclo di vita dei certificati può essere difficile se la logistica non è ben ponderata.

Trusted Platform Module (TPM)

TPM, noto anche come ISO/IEC 11889, è uno standard per generare e archiviare in modo sicuro le chiavi crittografiche. TPM si riferisce anche a un dispositivo di I/O virtuale o fisico che interagisce con i moduli che implementano lo standard. Un dispositivo TPM può esistere come hardware discreto, hardware integrato, un modulo basato su firmware o un modulo basato su software.

Esistono due differenze principali tra i TPM e le chiavi simmetriche:

  • I chip TPM possono anche archiviare certificati X.509.
  • L'attestazione TPM nel servizio Device Provisioning usa la chiave di verifica dell'autenticità TPM (EK), una forma di autenticazione asimmetrica. Con l'autenticazione asimmetrica, viene usata una chiave pubblica per la crittografia e viene usata una chiave privata separata per la decrittografia. Al contrario, le chiavi simmetriche usano l'autenticazione simmetrica, in cui la chiave privata viene usata sia per la crittografia che per la decrittografia.

Professionisti per TPM:

  • I TPM sono inclusi come hardware standard in molti dispositivi Windows, con supporto predefinito per il sistema operativo.
  • L'attestazione TPM è più semplice da proteggere rispetto all'attestazione della chiave simmetrica basata su token di firma di accesso condiviso( SAS).
  • È possibile scadere e rinnovare, o eseguire il roll, le credenziali del dispositivo. Dps esegue automaticamente il rollback delle credenziali hub IoT ogni volta che un dispositivo TPM è dovuto al provisioning.

Contro per TPM:

  • I TPM sono complessi e possono essere difficili da usare.
  • Lo sviluppo di applicazioni con TPM è difficile, a meno che non si disponga di un TPM fisico o di un emulatore di qualità.
  • Potrebbe essere necessario riprogettare la scheda del dispositivo per includere un TPM nell'hardware.
  • Se si esegue il rollback dell'EK in un TPM, l'identità del TPM viene eliminata e ne viene creata una nuova. Anche se il chip fisico rimane invariato, ha una nuova identità nella soluzione IoT.

chiave simmetrica

Con le chiavi simmetriche, la stessa chiave viene usata per crittografare e decrittografare i messaggi. Di conseguenza, la stessa chiave è nota sia per il dispositivo che per il servizio che lo autentica. Azure IoT supporta le connessioni a chiave simmetrica basate su token di firma di accesso condiviso. L'autenticazione con chiave simmetrica richiede una responsabilità significativa del proprietario per proteggere le chiavi e ottenere un livello di sicurezza uguale con l'autenticazione X.509. Se si usano chiavi simmetriche, la procedura consigliata consiste nel proteggere le chiavi usando un modulo di protezione hardware .If you use a symmetric keys, the recommended practice is to protect the keys by using a hardware security module (HSM).

Vantaggi per la chiave simmetrica:

  • L'uso di chiavi simmetriche è il modo più semplice e più basso per iniziare a usare l'autenticazione.
  • L'uso di chiavi simmetriche semplifica il processo perché non c'è niente di più da generare.

Contro per la chiave simmetrica:

  • Le chiavi simmetriche richiedono un notevole livello di impegno per proteggere le chiavi. La stessa chiave viene condivisa tra il dispositivo e il cloud, il che significa che la chiave deve essere protetta in due posizioni. Al contrario, la sfida con i certificati TPM e X.509 sta dimostrando il possesso della chiave pubblica senza rivelare la chiave privata.
  • Le chiavi simmetriche semplificano l'esecuzione di procedure di sicurezza non appropriate. Una tendenza comune con le chiavi simmetriche consiste nel impostare come hardcoded le chiavi non crittografate nei dispositivi. Anche se questa pratica è conveniente, lascia le chiavi vulnerabili. È possibile ridurre alcuni rischi archiviando in modo sicuro la chiave simmetrica nel dispositivo. Tuttavia, se la priorità è in definitiva la sicurezza anziché la comodità, usare certificati X.509 o TPM per l'autenticazione.

Chiave simmetrica condivisa

Esiste una variante dell'autenticazione con chiave simmetrica nota come chiave simmetrica condivisa. Questo approccio prevede l'uso della stessa chiave simmetrica in tutti i dispositivi. È consigliabile evitare di usare chiavi simmetriche condivise nei dispositivi.

Pro per la chiave simmetrica condivisa:

  • Semplice da implementare e poco costoso da produrre su larga scala.

Contro per la chiave simmetrica condivisa:

  • Altamente vulnerabile agli attacchi. Il vantaggio di un'implementazione semplice è molto superiore al rischio.
  • Chiunque può rappresentare i dispositivi se ottiene la chiave condivisa.
  • Se si fa affidamento su una chiave simmetrica condivisa compromessa, è probabile che si perde il controllo dei dispositivi.

Fare la scelta giusta per i dispositivi

Per scegliere un metodo di autenticazione, assicurarsi di considerare i vantaggi e i costi di ogni approccio per il processo di produzione univoco. Per l'autenticazione del dispositivo, in genere esiste una relazione inversa tra la sicurezza di un determinato approccio e la praticità.

Installazione dei certificati nei dispositivi IoT

Se si usano certificati X.509 per autenticare i dispositivi IoT, questa sezione offre indicazioni su come integrare i certificati nel processo di produzione. Dovrai prendere diverse decisioni. Queste includono decisioni sulle variabili di certificato comuni, quando generare i certificati e quando installarli.

Se si usano password, è possibile chiedere perché non è possibile usare lo stesso certificato in tutti i dispositivi, allo stesso modo in cui si potrebbe usare la stessa password in tutti i dispositivi. Prima di tutto, usare la stessa password ovunque è pericoloso. La pratica ha esposto le aziende a gravi attacchi DDoS, incluso quello che ha abbattuto DNS sulla costa orientale degli Stati Uniti diversi anni fa. Non usare mai la stessa password ovunque, anche con account personali. In secondo luogo, un certificato non è una password, è un'identità univoca. Una password è come un codice segreto che chiunque può usare per aprire una porta in un edificio protetto. È qualcosa che sai, e potresti dare la password a chiunque per ottenere l'ingresso. Un certificato è come una patente di guida con la tua foto e altri dettagli, che puoi mostrare a una guardia per entrare in un edificio protetto. È legato a chi sei. A condizione che la guardia corrisponda accuratamente alle persone con patenti di guida, è possibile usare solo la patente (identità) per ottenere l'ingresso.

Variabili coinvolte nelle decisioni relative ai certificati

Considerare le variabili seguenti e il modo in cui ognuno influisce sul processo di produzione complessivo.

Da dove proviene la radice del certificato di attendibilità

Può essere costoso e complesso gestire un'infrastruttura a chiave pubblica (PKI). In particolare se l'azienda non ha esperienza nella gestione di un'infrastruttura a chiave pubblica. Le opzioni disponibili sono:

  • Usare un'infrastruttura a chiave pubblica di terze parti. È possibile acquistare certificati di firma intermedi da un fornitore di certificati di terze parti. In alternativa, è possibile usare un'autorità di certificazione (CA) privata.
  • Usare un'infrastruttura a chiave pubblica autogestito. È possibile gestire il proprio sistema PKI e generare certificati personalizzati.
  • Usare il servizio di sicurezza di Azure Sphere . Questa opzione si applica solo ai dispositivi Azure Sphere.

Dove vengono archiviati i certificati

Esistono alcuni fattori che influiscono sulla decisione sulla posizione in cui vengono archiviati i certificati. Questi fattori includono il tipo di dispositivo, i margini di profitto previsti (se è possibile concedere l'archiviazione sicura), le funzionalità dei dispositivi e la tecnologia di sicurezza esistente nel dispositivo che è possibile usare. Valutare le opzioni seguenti:

  • In un modulo di protezione hardware (HSM). È consigliabile usare un modulo di protezione hardware. Controllare se nella scheda di controllo del dispositivo è già installato un modulo di protezione hardware. Se si sa che non si ha un modulo di protezione hardware, rivolgersi al produttore dell'hardware per identificare un modulo di protezione hardware che soddisfi le proprie esigenze.
  • In una posizione sicura su disco, ad esempio un ambiente di esecuzione attendibile (T edizione Enterprise).
  • Nel file system locale o in un archivio certificati. Ad esempio, l'archivio certificati di Windows.

Connessione ivity in fabbrica

Connessione ivity in factory determina come e quando si otterranno i certificati da installare nei dispositivi. Connessione opzioni di Connessione ivity sono le seguenti:

  • Connettività. La connettività è ottimale, semplifica il processo di generazione di certificati in locale.
  • Nessuna connettività. In questo caso, si usa un certificato firmato da una CA per generare i certificati del dispositivo in locale e offline.
  • Nessuna connettività. In questo caso, è possibile ottenere i certificati generati in anticipo. In alternativa, è possibile usare un'infrastruttura a chiave pubblica offline per generare certificati in locale.

Requisito di controllo

A seconda del tipo di dispositivi prodotti, potrebbe essere necessario un requisito normativo per creare un audit trail della modalità di installazione delle identità dei dispositivi nei dispositivi. Il controllo aggiunge costi di produzione significativi. Quindi nella maggior parte dei casi, farlo solo se necessario. Se non si è certi che sia necessario un controllo, rivolgersi al reparto legale della società. Le opzioni di controllo sono:

  • Non è un settore sensibile. Non è necessario alcun controllo.
  • Settore sensibile. I certificati devono essere installati in una sala sicura in base ai requisiti di certificazione di conformità. Se è necessaria una sala sicura per installare i certificati, è probabile che si sia già a conoscenza del modo in cui i certificati vengono installati nei dispositivi. E probabilmente hai già un sistema di controllo.

Lunghezza della validità del certificato

Analogamente alla licenza di un driver, i certificati hanno una data di scadenza impostata al momento della creazione. Ecco le opzioni per la durata della validità del certificato:

  • Rinnovo non obbligatorio. Questo approccio usa un periodo di rinnovo lungo, quindi non dovrai mai rinnovare il certificato durante la durata del dispositivo. Anche se un approccio di questo tipo è conveniente, è anche rischioso. È possibile ridurre il rischio usando l'archiviazione sicura, ad esempio un modulo di protezione hardware nei dispositivi. Tuttavia, la procedura consigliata consiste nell'evitare l'uso di certificati di lunga durata.
  • Rinnovo obbligatorio. Sarà necessario rinnovare il certificato durante la durata del dispositivo. La durata della validità del certificato dipende dal contesto e sarà necessaria una strategia per il rinnovo. La strategia deve includere la posizione in cui si ottengono i certificati e il tipo di funzionalità over-the-air che i dispositivi devono usare nel processo di rinnovo.

Quando generare certificati

Le funzionalità di connettività Internet nella factory influiranno sul processo per la generazione di certificati. Sono disponibili diverse opzioni per quando generare i certificati:

  • Certificati precaricati. Alcuni fornitori di moduli di protezione hardware offrono un servizio Premium in cui il fornitore del modulo di protezione hardware installa i certificati per il cliente. Prima di tutto, i clienti assegnano al fornitore del modulo di protezione hardware l'accesso a un certificato di firma. Il fornitore del modulo di protezione hardware installa quindi i certificati firmati da tale certificato di firma in ogni modulo di protezione hardware acquistato dal cliente. Tutto quello che il cliente deve fare è installare il modulo di protezione hardware nel dispositivo. Anche se questo servizio aggiunge costi, consente di semplificare il processo di produzione. E risolve la domanda di quando installare i certificati.
  • Certificati generati dal dispositivo. Se i dispositivi generano i certificati internamente, è necessario estrarre il certificato X.509 pubblico dal dispositivo per registrarlo nel servizio Device Provisioning.
  • Connessione factory. Se la factory ha connettività, è possibile generare i certificati del dispositivo ogni volta che sono necessari.
  • Factory offline con l'infrastruttura a chiave pubblica (PKI) personalizzata. Se la factory non dispone di connettività e si usa un'infrastruttura PKI personalizzata con supporto offline, è possibile generare i certificati quando sono necessari.
  • Factory offline con infrastruttura a chiave pubblica di terze parti. Se la factory non dispone di connettività e si usa un'infrastruttura a chiave pubblica di terze parti, è necessario generare i certificati in anticipo. Sarà inoltre necessario generare i certificati da una posizione con connettività.

Quando installare i certificati

Dopo aver generato i certificati per i dispositivi IoT, è possibile installarli nei dispositivi.

Se si usano certificati precaricati con un modulo di protezione hardware, il processo è semplificato. Dopo aver installato il modulo di protezione hardware nel dispositivo, il codice del dispositivo può accedervi. Si chiameranno quindi le API del modulo di protezione hardware per accedere al certificato archiviato nel modulo di protezione hardware. Questo approccio è il più conveniente per il processo di produzione.

Se non si usa un certificato precaricato, è necessario installare il certificato come parte del processo di produzione. L'approccio più semplice consiste nell'installare il certificato nel modulo di protezione hardware contemporaneamente all'immagine del firmware iniziale. Il processo deve aggiungere un passaggio per installare l'immagine in ogni dispositivo. Dopo questo passaggio, è possibile eseguire controlli di qualità finali e qualsiasi altro passaggio, prima di creare il pacchetto e spedire il dispositivo.

Sono disponibili strumenti software che consentono di eseguire il processo di installazione e il controllo qualità finale in un unico passaggio. È possibile modificare questi strumenti per generare un certificato o per eseguire il pull di un certificato da un archivio certificati pregenerato. Il software può quindi installare il certificato in cui è necessario installarlo. Gli strumenti software di questo tipo consentono di eseguire la produzione di qualità di produzione su larga scala.

Dopo aver installato i certificati nei dispositivi, il passaggio successivo consiste nell'apprendere come registrare i dispositivi con DPS.

Integrazione di un TPM nel processo di produzione

Se si usa un TPM per autenticare i dispositivi IoT, questa sezione offre indicazioni. Le linee guida riguardano i dispositivi TPM 2.0 ampiamente usati che dispongono del supporto della chiave HMAC (Hash-Based Message Authentication Code). La specifica TPM per i chip TPM è uno standard ISO gestito dal gruppo trusted computing. Per altre informazioni su TPM, vedere le specifiche per TPM 2.0 e ISO/IEC 11889.

Acquisizione della proprietà del TPM

Un passaggio critico nella produzione di un dispositivo con un chip TPM consiste nell'assumere la proprietà del TPM. Questo passaggio è obbligatorio in modo da poter fornire una chiave al proprietario del dispositivo. Il primo passaggio consiste nell'estrarre la chiave di verifica dell'autenticità (EK) dal dispositivo. Il passaggio successivo consiste nell'rivendicare effettivamente la proprietà. Il modo in cui si esegue questa operazione dipende dal TPM e dal sistema operativo usato. Se necessario, contattare il produttore del TPM o lo sviluppatore del sistema operativo del dispositivo per determinare come richiedere la proprietà.

Nel processo di produzione è possibile estrarre l'EK e la proprietà delle attestazioni in momenti diversi, che aggiunge flessibilità. Molti produttori sfruttano questa flessibilità aggiungendo un modulo di protezione hardware (HSM) per migliorare la sicurezza dei dispositivi. Questa sezione fornisce indicazioni su quando estrarre l'EK, quando rivendicare la proprietà del TPM e considerazioni sull'integrazione di questi passaggi in una sequenza temporale di produzione.

Importante

Le indicazioni seguenti presuppongono l'uso di un TPM discreto, firmware o integrato. Nelle posizioni in cui è applicabile, le indicazioni aggiungono note sull'uso di un TPM non discreto o software. Se si usa un TPM software, potrebbero essere necessari passaggi aggiuntivi che non includono queste indicazioni. I TPM software hanno un'ampia gamma di implementazioni che esulano dall'ambito di questo articolo. In generale, è possibile integrare un TPM software nella sequenza temporale generale di produzione seguente. Tuttavia, mentre un TPM emulato software è adatto per la creazione di prototipi e test, non può fornire lo stesso livello di sicurezza di un TPM discreto, firmware o integrato. Come pratica generale, evitare di usare un TPM software nell'ambiente di produzione.

Sequenza temporale generale della produzione

La sequenza temporale seguente illustra come un TPM esegue un processo di produzione e finisce in un dispositivo. Ogni processo di produzione è unico e questa sequenza temporale mostra i modelli più comuni. La sequenza temporale offre indicazioni su quando eseguire determinate azioni con le chiavi.

Passaggio 1: TPM è prodotto

  • Se si acquistano TPM da un produttore per l'uso nei dispositivi, verificare se estraggono automaticamente le chiavi di verifica dell'autenticità pubblica (EK_pubs). È utile se il produttore fornisce l'elenco di EK_pubs con i dispositivi spediti.

    Nota

    È possibile concedere al produttore del TPM l'accesso in scrittura all'elenco di registrazioni usando i criteri di accesso condiviso nel servizio di provisioning. Questo approccio consente di aggiungere i TPM all'elenco di registrazioni. Ma questo è all'inizio del processo di produzione e richiede fiducia nel produttore TPM. Farlo a proprio rischio.

  • Se si producono TPM da vendere ai produttori di dispositivi, prendere in considerazione la possibilità di fornire ai clienti un elenco di EK_pubs insieme ai TPM fisici. Fornire ai clienti EK_pubs salva un passaggio nel processo.

  • Se si producono TPM da usare con i propri dispositivi, identificare quale punto del processo è il più comodo per estrarre il EK_pub. È possibile estrarre il EK_pub in uno qualsiasi dei punti rimanenti nella sequenza temporale.

Passaggio 2: TPM è installato in un dispositivo

A questo punto del processo di produzione, è necessario sapere con quale istanza del servizio Device Provisioning verrà usato il dispositivo. Di conseguenza, è possibile aggiungere dispositivi all'elenco di registrazioni per il provisioning automatizzato. Per altre informazioni sul provisioning automatico dei dispositivi, vedere la documentazione del servizio Device Provisioning.

  • Se la EK_pub non è stata estratta, è il momento giusto per farlo.
  • A seconda del processo di installazione del TPM, questo passaggio è anche un buon momento per acquisire la proprietà del TPM.

Passaggio 3: Il dispositivo ha firmware e software installato

A questo punto del processo, installare il client DPS insieme all'ambito ID e all'URL globale per il provisioning.

  • Ora è l'ultima possibilità di estrarre il EK_pub. Se una terza parte installerà il software nel dispositivo, è consigliabile estrarre prima il EK_pub.
  • Questo punto nel processo di produzione è ideale per assumere la proprietà del TPM.

    Nota

    Se si usa un TPM software, è possibile installarlo ora. Estrarre il EK_pub contemporaneamente.

Passaggio 4: Il dispositivo viene in pacchetto e inviato al magazzino

Un dispositivo può talvolta trovarsi in un magazzino per un massimo di un anno prima di essere distribuito e sottoposto a provisioning con DPS. Se un dispositivo si trova in un magazzino per molto tempo prima della distribuzione, i clienti che distribuiscono il dispositivo potrebbero dover aggiornare il firmware, il software o le credenziali scadute.

Passaggio 5: Il dispositivo viene installato nel percorso

Dopo che il dispositivo arriva alla posizione finale, passa attraverso il provisioning automatizzato con DPS.

Per altre informazioni, vedere Provisioning e attestazione TPM.

Risorse

Oltre alle procedure di sicurezza consigliate in questo articolo, Azure IoT fornisce risorse utili per la selezione di hardware sicuro e la creazione di distribuzioni IoT sicure: