Perché il provisioning sicuro va eseguito in produzione
Un dispositivo connesso spedito senza identità deve essere provisionato sul campo. Il provisioning sul campo comporta un passaggio manuale (o un auto-enrollment vulnerabile) al momento dell'installazione. Entrambi generano oneri operativi e un'esposizione di sicurezza.
Il provisioning lato produzione assegna al dispositivo un'identità crittografica unica prima della spedizione. Il dispositivo si avvia, si autentica e si registra senza alcun intervento manuale.
Secure element
Microchip ATECC608 e NXP EdgeLock sono secure element diffusi nell'IoT. Entrambi supportano:
- Generazione della chiave privata ECC all'interno del chip (la chiave non esce mai)
- Firma e verifica dei certificati
- Protezione anti-replay basata su contatore
- Comportamento a evidenza di manomissione
La linea di produzione genera una chiave all'interno del secure element, firma un certificato con la CA radice, scrive il certificato sul dispositivo e registra la chiave pubblica associata al numero di serie.
Enrollment del certificato X.509
X.509 è il formato di certificato standard. L'enrollment lato produzione segue di norma questo schema:
- Il secure element genera una coppia di chiavi ECC (la chiave privata resta bloccata nel chip)
- Il sistema di produzione legge la chiave pubblica
- Il sistema di produzione firma il certificato con la CA radice protetta da HSM
- Il certificato viene riscritto sul dispositivo
- La chiave pubblica e il fingerprint del certificato vengono registrati con il numero di serie
La chiave privata della CA radice non tocca mai la linea di produzione. Risiede in un HSM, in un ambiente controllato.
AWS IoT e Azure DPS
AWS IoT supporta il Just-in-Time Provisioning (JITP) e la Multi-Account Registration. Azure Device Provisioning Service (DPS) supporta l'attestazione X.509, l'attestazione tramite Trusted Platform Module (TPM) e l'attestazione a chiave simmetrica.
Entrambi permettono alla linea di produzione di preregistrare i dispositivi in modo che si registrino automaticamente alla prima connessione al cloud. Il flusso lato produzione:
- Il dispositivo viene provisionato con un certificato X.509
- Il fingerprint del certificato del dispositivo viene registrato presso il DPS cloud
- Il dispositivo si avvia sul campo, presenta il certificato, si registra in automatico
- Il cloud assegna il dispositivo al gruppo corretto e scarica la configurazione
Una PKI privata segue lo stesso schema con un'infrastruttura interna al posto di AWS o Azure.
Un flusso di produzione che funziona
- CA radice protetta da HSM in ambiente controllato, accessibile tramite API di firma
- Generazione della chiave per singola unità all'interno del secure element, in linea
- Firma del certificato tramite chiamata API (nessun materiale di chiave esposto)
- Preregistrazione presso il DPS cloud integrata nello step di provisioning
- Record di enrollment per singola unità tracciato nel database di produzione
- Gestione opzionale della lista di revoca per i dispositivi a fine vita o smarriti
Errori comuni
- Chiave privata della CA radice memorizzata sulla linea di produzione (non in HSM)
- Stessa chiave caricata su più dispositivi ("modalità test finita in produzione")
- Fingerprint del certificato registrato ma non preregistrato presso il DPS cloud
- Flusso di provisioning eseguito a mano su poche unità, mai portato a scala
Fonti
- Documentazione AWS IoT Just-in-Time Provisioning
- Documentazione Microsoft Azure Device Provisioning Service
- Documentazione del secure element Microchip ATECC608
- Documentazione del secure element NXP EdgeLock