Autenticare le identità con certificati X.509

L'hub IoT usa certificati X.509 per autenticare i dispositivi. L'autenticazione X.509 consente l'autenticazione di un dispositivo IoT come parte dell'impostazione della connessione standard TLS (Transport Layer Security).

Un certificato della CA X.509 è un certificato digitale che può firmare altri certificati. Un certificato digitale è considerato un certificato X.509 se è conforme allo standard di formattazione del certificato prescritto dallo standard RFC 5280 di IETF. Un'autorità di certificazione (CA) indica che il titolare può firmare altri certificati.

Questo articolo descrive come usare i certificati dell'autorità di certificazione X.509 per autenticare i dispositivi che si connettono all'hub IoT, che include i passaggi seguenti:

• Come ottenere un certificato della CA X.509
• Come registrare il certificato della CA X.509 all'hub IoT
• Come firmare i dispositivi con i certificati della CA X.509
• Come vengono autenticati i dispositivi firmati con i certificati della CA X.509

La funzionalità CA X.509 consente l'autenticazione del dispositivo all'hub IoT usando un'autorità di certificazione (CA). Questa procedura consente di semplificare il processo di registrazione iniziale dei dispositivi e la logistica della catena di fornitura durante la produzione dei dispositivi stessi.

Autenticazione e autorizzazione

L'autenticazione è un processo che consente di verificare che l'utente è chi dice di essere. L'autenticazione verifica l'identità di un utente o di un dispositivo nell'hub IoT. In lingua inglese, il termine autenticazione viene talvolta abbreviato in AuthN. L'autorizzazione è il processo di conferma delle autorizzazioni per un utente o un dispositivo autenticato nell'hub IoT. Specifica le risorse e i comandi a cui è consentito l'accesso e le operazioni che è possibile eseguire con tali risorse e comandi. In lingua inglese, il termine autorizzazione viene talvolta abbreviato in AuthZ.

Questo articolo descrive l'autenticazione tramite certificati X.509. È possibile usare qualsiasi certificato X.509 per autenticare un dispositivo con l'hub IoT caricando un'identificazione personale del certificato o un'autorità di certificazione (CA) nell'hub IoT di Azure.

I certificati X.509 vengono usati per l'autenticazione nell'hub IoT, non per l'autorizzazione. A differenza di Microsoft Entra ID e delle firme di accesso condiviso, non è possibile personalizzare le autorizzazioni con certificati X.509.

Applicare l'autenticazione X.509

Per maggiore sicurezza, un hub IoT può essere configurato per non consentire l'autenticazione SAS per dispositivi e moduli, lasciando X.509 come unica opzione di autenticazione accettata. Attualmente, questa funzionalità non è disponibile nel portale di Azure. Per configurarla, impostare disableDeviceSAS e disableModuleSAS su true nelle proprietà delle risorse dell'hub IoT:

az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --set properties.disableDeviceSAS=true properties.disableModuleSAS=true

Vantaggi dell'autenticazione del certificato della CA X.509

L'autenticazione dell'autorità di certificazione X.509 è un approccio per l'autenticazione dei dispositivi nell'hub IoT usando un metodo che semplifica notevolmente la creazione dell'identità del dispositivo e la gestione del ciclo di vita nella catena di alimentazione.

Un attributo distintivo dell'autenticazione dell'autorità di certificazione X.509 è una relazione uno/molti che un certificato dell'autorità della CA possiede con i dispositivi di downstream. Questa relazione consente la registrazione di qualsiasi numero di dispositivi nell'hub IoT registrando un certificato CA X.509 una sola volta. In caso contrario, i certificati univoci devono essere preregistrati per ogni dispositivo prima che un dispositivo possa connettersi. Questa relazione uno-a-molti semplifica anche le operazioni di gestione del ciclo di vita dei certificati dei dispositivi.

Un altro attributo importante dell'autenticazione dell'autorità di certificazione X.509 è una semplificazione della logistica della catena di alimentazione. L'autenticazione sicura dei dispositivi richiede che ogni dispositivo usi un segreto univoco come ad esempio chiave come base per essere considerato attendibile. Nell'autenticazione basata sui certificati il segreto è una chiave privata. Un tipico flusso di produzione del dispositivo prevede più passaggi e responsabili. La gestione sicura delle chiavi private del dispositivo in più responsabili e il mantenimento dell'attendibilità è un'operazione complessa e costosa. Usando le autorità di certificazione si risolve questo problema, poiché ogni responsabile firma in una catena di crittografia considerata attendibile invece che dimostrarsi attendibile con delle chiavi private del dispositivo. Ogni responsabile firma i dispositivi nel rispettivo passaggio del flusso di produzione. Il risultato complessivo è una catena di alimentazione ottimale con una responsabilità incorporata tramite l'uso della catena di crittografia di attendibilità.

Questo processo produce maggiore protezione quando i dispositivi proteggono le chiavi private univoche. A questo scopo, è consigliabile usare moduli HSM (Hardware Secure Modules) in grado di generare internamente chiavi private.

Il servizio Device Provisioning in hub IoT di Azure semplifica il provisioning di gruppi di dispositivi negli hub. Per altre informazioni, vedere Esercitazione: Effettuare il provisioning di più dispositivi X.509 usando gruppi di registrazione.

Ottenere un certificato della CA X.509

Il certificato della CA X.509 rappresenta l'elemento superiore della catena di certificati per ciascuno dei dispositivi disponibili. È possibile acquistarne o crearne uno, a seconda di come si intende usarlo.

Per gli ambienti di produzione, è consigliabile acquistare un certificato della CA X.509 da un provider di servizi di certificazione professionale. Il vantaggio dell'acquisto di un certificato della CA risiede nel fatto che la CA radice funge da terze parti attendibili a garanzia della legittimità dei dispositivi in uso. Prendere in considerazione questa opzione se i dispositivi fanno parte di una rete IoT aperta in cui interagiscono con prodotti o servizi di terze parti.

È anche possibile creare un certificato della CA X.509 autofirmato a scopo di test. Per altre informazioni sulla creazione di certificati per il test, vedere Creare e caricare certificati per il test.

Indipendentemente dalla modalità di acquisizione del certificato della CA X.509, assicurarsi di non divulgare mai la corrispondente chiave privata. Questa precauzione è necessaria per creare attendibilità nell'autenticazione della CA X.509.

Firmare i dispositivi nella catena di certificati

Il proprietario di un certificato della CA X.509 può firmare a livello di crittografia una CA intermedia, che a sua volta firma un'altra CA intermedia e così via, finché l'ultima CA intermedia conclude il processo firmando un certificato di dispositivo. Il risultato è una catena di certificati a cascata definita catena di certificati. Questa delega di attendibilità è importante perché definisce una catena variabile di protezione a livello di crittografia che impedisce la condivisione delle chiavi di firma.

Il certificato del dispositivo (detto anche certificato foglia) deve avere il nome comune (CN) impostato sull'ID dispositivo (CN=deviceId) usato durante la registrazione del dispositivo IoT nell'hub IoT di Azure. Questa impostazione è obbligatoria per l'autenticazione.

Per i moduli che usano l'autenticazione X.509, il certificato del modulo deve avere il nome comune (CN) formattato come CN=deviceId/moduleId.

Informazioni su come creare una catena di certificati simile a quella creata durante il processo di firma dei dispositivi.

Registrare il certificato della CA X.509 nell'hub IoT

Registrare il certificato della CA X.509 nell'hub IoT in cui viene usato per autenticare i dispositivi durante la connessione e la registrazione. La registrazione del certificato della CA X.509 è un processo in due passaggi che include il caricamento del file del certificato e la definizione della prova di possesso.

Il processo di caricamento comporta il caricamento di un file che contiene il certificato. Questo file non deve contenere mai le chiavi private.

Il passaggio relativo all'uso del token proof-of-possession prevede un processo basato sulla crittografia e sullo scambio della richiesta di verifica e della relativa risposta tra il dispositivo e l'hub IoT. Dato che il contenuto di un certificato digitale è pubblico e pertanto suscettibile all'intercettazione, l'hub IoT deve verificare l'effettiva titolarità del possesso del certificato della CA. È possibile scegliere di verificare automaticamente o manualmente la proprietà. Per la verifica manuale, l'hub IoT di Azure genera una richiesta casuale che si firma con la chiave privata corrispondente del certificato della CA. Se la chiave privata non è stata divulgata ed è stata conservata in un luogo protetto come consigliato, solo l'utente proprietario sarà in grado di completare questo passaggio. In questo metodo il fattore determinante della relazione di attendibilità è dato dalla riservatezza delle chiavi private. Dopo aver firmato la richiesta di verifica, completare questo passaggio e verificare manualmente il certificato caricando un file contenente i risultati.

Informazioni su come registrare il certificato della CA.

Autenticare i dispositivi firmati con certificati della CA X.509

A ogni hub IoT è associato un registro delle identità in cui sono archiviate le informazioni sui dispositivi e i moduli a cui è consentito connettersi all'hub IoT. Prima che un dispositivo o modulo possa connettersi, è necessario che sia presente una voce relativa al dispositivo o al modulo nel registro delle identità dell'hub IoT. Un dispositivo o un modulo deve autenticarsi anche con l'hub IoT in base alle credenziali archiviate nel registro delle identità.

Con il certificato della CA X.509 registrato e i dispositivi connessi a una catena di certificati di attendibilità, il passaggio finale è l'autenticazione del dispositivo quando il dispositivo si connette. Al momento della connessione, un dispositivo firmato con un certificato della CA X.509 carica la relativa catena di certificati per la convalida. La catena include tutti i certificati della CA intermedi e i certificati del dispositivo. L'hub IoT userà queste informazioni per autenticare il dispositivo in un processo che si articola in due passaggi. L'hub IoT convalida a livello di crittografia la catena di certificati per la verifica della coerenza interna e quindi genera una richiesta di verifica del token proof-of-possession per il dispositivo. L'hub IoT dichiara quindi autentico il dispositivo alla ricezione di una risposta valida a fronte del token proof-of-possession dal dispositivo. Questa dichiarazione presuppone che la chiave privata del dispositivo sia protetta e che solo il dispositivo sia in grado di rispondere a questa richiesta di verifica. Per proteggere le chiavi private nei dispositivi, è consigliabile usare chip sicuri quali, ad esempio, i moduli di protezione hardware.

Una connessione riuscita del dispositivo all'hub IoT completa il processo di autenticazione e indica un'installazione corretta. Ogni volta che un dispositivo si connette, l'hub IoT rinegozia la sessione TLS e verifica il certificato X.509 del dispositivo.

Revocare un certificato del dispositivo

L'hub IoT non controlla gli elenchi di revoche di certificati dall'autorità di certificazione durante l'autenticazione dei dispositivi con autenticazione basata su certificato. Se si dispone di un dispositivo che deve essere bloccato dalla connessione all'hub IoT a causa di un certificato potenzialmente compromesso, è necessario disabilitare il dispositivo nel registro delle identità. Per altre informazioni, vedere Disabilitare o eliminare un dispositivo.

Scenario di esempio

L'azienda X produce widget smart X progettati per l'installazione professionale. La Società-X affida in outsource sia la produzione sia l'installazione. La factory Y produce i widget smart X e il tecnico Z li installa. L'azienda X vuole che i widget smart X siano forniti direttamente dalla factory Y al tecnico Z per l'installazione e quindi per la connessione diretta all'istanza dell'hub IoT dell'azienda X. A tale scopo, la Società-X deve completare alcune operazioni di installazione singole per preparare lo Smart-X-Widget alla connessione automatica. Questo scenario end-to-end include i passaggi seguenti:

1. Acquisire il certificato della CA X.509

2. Registrare il certificato della CA X.509 nell'hub IoT

3. Firmare i dispositivi in una catena di certificati

4. Connettere i dispositivi

Questi passaggi sono illustrati in Esercitazione: Creare e caricare certificati per il test.

Acquisire il certificato

L'azienda X può acquistare un certificato della CA X.509 da un'autorità di certificazione radice pubblica o crearne uno tramite un processo autofirmato. Entrambe le opzioni comportano due passaggi di base: la generazione di una coppia di chiavi pubblica/privata e la firma della chiave pubblica in un certificato.

Dettagli su come l'esecuzione di questi passaggi cambi con provider di servizio diversi.

Acquistare un certificato

Il vantaggio dell'acquisto di un certificato della CA risiede nell'avere un atto della CA radice ben noto che funge da terza parte attendibile a garanzia della legittimità dei dispositivi IoT quando si connettono i dispositivi. Scegliere questa opzione se i dispositivi interagiscono con prodotti o servizi di terze parti.

Per acquistare un certificato della CA X.509, scegliere un provider di servizi di certificati radice. Il provider di CA radice illustra come creare la coppia di chiavi pubblica/privata e come generare una richiesta di firma del certificato per i servizi. Una richiesta di firma del certificato è il processo formale di richiesta di un certificato da parte di un'autorità di certificazione. Il risultato dell'acquisto è un certificato da usare come certificato di autorità. Data la grande diffusione di certificati X.509, è probabile che il certificato sia stato formattato correttamente in relazione allo standard IETF RFC 5280.

Creare un certificato autofirmato

Il processo di creazione di un certificato della CA X.509 autofirmato è simile all'acquisto di un certificato, ad eccezione del fatto che non implica un firmatario di terze parti come l'autorità di certificazione radice. In questo esempio, sarà l'azienda X a firmare il certificato dell'autorità anziché un'autorità di certificazione radice.

È possibile scegliere questa opzione per il test fino a quando non si è pronti per acquistare un certificato dell'autorità. È anche possibile usare un certificato della CA X.509 autofirmato nell'ambiente di produzione se i dispositivi non si connettono a servizi di terze parti all'esterno dell'hub IoT.

Registrare il certificato nell'hub IoT

L'azienda X deve registrare l'autorità di certificazione X.509 sull'hub IoT in cui verrà usata per autenticare i widget smart X al momento della connessione. Si tratta di un processo unico che offre la possibilità di autenticare e gestire un numero qualsiasi di dispositivi widget smart X. La relazione uno-a-molti tra certificati della CA e certificati del dispositivo è uno dei principali vantaggi dell'uso del metodo di autenticazione della CA X.509. L'alternativa consisterebbe nel caricare le identificazioni personali del certificato singolo per ogni dispositivo widget smart X aggiungendo così dei costi operativi.

La registrazione del certificato della CA X.509 è un processo in due passaggi: caricare il certificato e quindi fornire la prova di possesso.

Caricare il certificato

Il processo di caricamento del certificato della CA X.509 è proprio quello di caricare il certificato della CA nell'hub IoT. Hub IoT si aspetta il certificato in un file.

Il file del certificato non deve in nessuna circostanza contenere chiavi private. Le procedure consigliate dagli standard che regolano l'infrastruttura a chiave pubblica (PKI) impongono che la conoscenza della chiave privata dell'azienda X in questo caso risieda esclusivamente all'interno dell'azienda X.

Dimostrare il possesso

Il certificato della CA X.509, come qualsiasi certificato digitale, contiene informazioni pubbliche che sono soggette a intercettazione. Di conseguenza, un utente malintenzionato può intercettare un certificato e provare a caricarlo come proprio. In questo esempio, l'hub IoT deve assicurarsi che il certificato della CA che l'azienda X ha caricato appartenga realmente all'azienda X. Lo fa richiedendo all'azienda X di dimostrare di essere realmente in possesso del certificato tramite un flusso di proof-of-possession (PoP).

Il flusso di proof-of-possession comporta che la generazione di un numero casuale da parte dell'hub IoT sia firmata dall'azienda X con la propria chiave privata. Se l'azienda X ha seguito le procedure consigliate dell'infrastruttura a chiave pubblica e ha protetto la propria chiave privata, allora è l'unica in grado di poter rispondere correttamente alla richiesta di proof-of-possession. L'hub IoT prosegue per registrare il certificato della CA di X.509 al momento di una risposta con esito positivo della richiesta di proof-of-possession.

Una risposta corretta alla richiesta di proof-of-possession da parte dell'hub IoT completa la registrazione dell'autorità di certificazione X.509.

Firmare i dispositivi in una catena di certificati

IoT richiede un'identità univoca per ogni dispositivo che si connette. Per l'autenticazione basata su certificati, queste identità sono sotto forma di certificati. In questo esempio, l'autenticazione basata su certificato significa che ogni widget smart X deve possedere un certificato univoco del dispositivo.

Un modo valido ma inefficiente per fornire certificati univoci in ogni dispositivo consiste nel pre-generare certificati per widget smart X e considerare attendibili i partner della supply chain con le chiavi private corrispondenti. Per l'azienda X, ciò significa conferire attendibilità alla factory Y e al tecnico Z. Questo metodo presenta sfide che devono essere superate per garantire l'attendibilità, come indicato di seguito:

• La necessità di condividere delle chiavi private del dispositivo con i partner della catena di alimentazione, oltre a ignorare le procedure consigliate dell'infrastruttura PKI di non condividere mai le chiavi private, rende costosa la costruzione dell'attendibilità nella catena di alimentazione. Richiede sistemi come sale sicure per ospitare chiavi private del dispositivo e processi come controlli di sicurezza periodici. Entrambi comportano dei costi aggiuntivi per la catena di alimentazione.

• Considerando in modo sicuro i dispositivi nella catena di alimentazione e gestendoli in un secondo momento nella distribuzione diventa un'attività di uno a uno per ogni coppia di chiave nel dispositivo dalla generazione del punto del certificato univoco del dispositivo (e della chiave privata) al ritiro del dispositivo. Ciò preclude la gestione del gruppo di dispositivi a meno che il concetto di gruppi sia in qualche modo integrato in modo esplicito nel processo. La gestione della contabilità e del ciclo di vita del dispositivo, pertanto, diventa un onere difficile di operazioni.

L'autenticazione del certificato della CA X.509 offre soluzioni eleganti a queste sfide tramite catene di certificati. Una catena di certificati è il risultato di una CA che firma una CA intermedia che a sua volta firma un'altra CA intermedia e così via fino a che una CA intermedia finale non firma un dispositivo. In questo esempio, la Società-X firma l'Azienda-Y, che a sua volta firma il Tecnico-Z che infine firma lo Smart-X-Widget.

Questa sequenza di certificati nella catena presenta la logica consegna dell'autorità. Molte catene di alimentazione seguono questa consegna logica in base alla quale ogni autorità di certificazione intermedia viene firmata nella catena mentre riceve tutti i certificati della CA in upstream e l'ultima CA intermedia infine firma ogni dispositivo e inserisce tutti i certificati di autorità dalla catena al dispositivo. Questo è comune quando la società di produzione del contratto con una gerarchia di aziende contratta un'azienda specifica per eseguire la produzione. Nel corso della gerarchia ci potrebbero essere più livelli (ad esempio, per tipo di prodotto/geografia linea di produzione/tipo), solo l'azienda alla fine ottiene di interagire con il dispositivo, ma la catena è gestita dalla parte superiore della gerarchia.

Delle catene alternative potrebbero avere diverse CA intermedie che interagiscono con il dispositivo, in tal caso l'autorità di certificazione che interagisce con il dispositivo inserisce il contenuto della catena di certificati in quel punto. I modelli ibridi sono anche possibili laddove solo alcune delle autorità di certificazione abbiano un'interazione fisica con il dispositivo.

Il diagramma seguente illustra come la catena di certificati di trust si riunisce nell'esempio relativo ai widget smart X.

1. L'azienda X non interagisce fisicamente con nessuno dei widget smart X. Avvia la catena di certificati di attendibilità firmando il certificato CA intermedio della factory Y.
2. La factory Y ha ora un proprio certificato CA intermedio e una firma dell'azienda X. Passa copie di questi elementi al dispositivo. Usa anche il certificato CA intermedio per firmare il certificato CA intermedio del tecnico Z e il certificato del dispositivo widget smart X.
3. Il tecnico Z ha ora un proprio certificato CA intermedio e una firma della factory Y. Passa copie di questi elementi al dispositivo. Usa anche il certificato CA intermedio per firmare il certificato del dispositivo widget smart X.
4. Ogni dispositivo widget smart X ha ora un proprio certificato di dispositivo univoco e copie delle chiavi pubbliche e delle firme da ogni certificato CA intermedio con cui ha interagito in tutta la catena di fornitura. Questi certificati e firme possono essere ritracciati alla radice originale dell'azienda X.

Il metodo di autenticazione della CA garantisce una contabilità protetta nella catena di alimentazione del dispositivo. A causa del processo della catena di certificati, le azioni di ogni membro nella catena sono registrate e crittograficamente e verificabili.

Questo processo si basa sul presupposto che la coppia di chiavi pubblica/privata univoca del dispositivo venga creata in modo indipendente e che la chiave privata sia sempre protetta all'interno del dispositivo. Fortunatamente esistono dei chip in silicone protetti sotto forma di moduli di protezione hardware (HSM) in grado di generare chiavi internamente e proteggere le chiavi private. L'azienda X deve aggiungere un chip sicuro solo nella distinta dei componenti di widget smart X.

Autenticare i dispositivi

Dopo aver registrato il certificato della CA di primo livello nell'hub IoT e fornito ai dispositivi certificati univoci, come si connettono? Registrando un certificato della CA X.509 all'hub IoT una volta, come possono potenzialmente milioni di dispositivi connettersi e ottenere l'autenticazione dal primo momento? Tramite lo stesso caricamento del certificato e lo stesso flusso di proof-of-possession che si è verificato in precedenza con la registrazione del certificato della CA X.509.

I dispositivi prodotti per l'autenticazione della CA X.509 sono dotati di certificati univoci del dispositivo e di una catena di certificati dalle rispettive catena di alimentazione della produzione. La connessione del dispositivo, anche per la prima volta, ha luogo in un processo a due fasi: il caricamento della catena di certificati e la proof-of-possession.

Durante il caricamento della catena di certificati, il dispositivo carica il certificato univoco e la catena di certificati nell'hub IoT. Usando il certificato della CA X.509 pre-registrato, l'hub IoT verifica che la catena di certificati caricata sia internamente coerente e che la catena sia stata originata dal proprietario valido del certificato della CA X.509. È quanto accade con il processo di registrazione della CA di X.509: l'hub IoT usa un processo di richiesta-risposta di proof-of-possession per verificare che la catena e pertanto il certificato del dispositivo appartenga effettivamente al dispositivo che lo sta caricando. Una risposta corretta attiva hub IoT per accettare il dispositivo come autentico e concedergli la connessione.

In questo esempio, ciascun Smart-X-Widget potrebbe caricare il proprio certificato univoco del dispositivo insieme ai certificati della CA X.509 dell'Azienda-Y e del Tecnico-Z e quindi rispondere alla richiesta di proof-of-possession dall'hub IoT.

La base della relazione di attendibilità risiede nelle chiavi private di protezione che comprendono le chiavi private del dispositivo. Pertanto è fondamentale sottolineare l'importanza dei chip di sicurezza in silicone sotto forma di moduli di protezione hardware (HSM) per la protezione delle chiavi private del dispositivo e la procedura consigliata complessiva di non condividere mai le chiavi private, come ad esempio affidare a un'altra azienda la propria chiave privata.

Passaggi successivi

Usare il servizio Device Provisioning per Effettuare il provisioning di più dispositivi X.509 usando i gruppi di registrazione.

Per altre informazioni sui campi che costituiscono un certificato X.509, vedere Certificati X.509.

Se si dispone di un certificato CA radice o di un certificato CA subordinato e si vuole caricarlo nell'hub IoT, è necessario verificare di essere proprietari del certificato. Per altre informazioni, vedere Esercitazione: Creare e caricare certificati per il test.