EO_485

DIGITAL EMBEDDED SECURITY 48 - ELETTRONICA OGGI 485 - APRILE 2020 I servizi cloud forniscono altri mezzi per controllare la sicurezza. Uno dei pronciapli vantaggi legati alla ge- stione basata su cloud per gli operatori dei servizi è rappresentato dal fatto che semplifica il ripudio se, ad esempio, un dispositivo non è più in uso. Rimuovendo il dispositivo e le sue chiavi dal servizio attivo, un hacker non può tentare di riutilizzare l’hardware, che si ritiene sia disattivato, per condurre un attacco alla rete. Il punto debole L’uso di certificati e firme digitali richiede un’attenta gestione della catena di fornitura dei dei prodotti elet- tronici. Un potenziale punto debole in un sistema ba- sato sui certificati X.509 standard è rappresentato dal fatto che eventuali problemi che si possono verificare nella catena stessa permettano agli hacker di manipo- lare certificati o intercettare chiavi private durante la programmazione di un dispositivo sulla linea di pro- duzione. Idealmente, una chiave privata non dovrebbe mai essere divulgata al di fuori dell’elemento sicuro. Ma per garantire che i certificati possano essere col- legati alle chiavi corrette, alcune implementazioni pre- vedono l’inserimento della chiave nell’elemento sicuro dopo l’assemblaggio della scheda utilizzando un pro- grammatore di memoria flash. Un hacker con accesso al programmatore sarebbe in grado di intercettare le chiavi o inserire i propri certificati in modo da poter accedere al dispositivo dopo l’installazione. Una valida alternativa Un’alternativa più sicura è quella impiegata nella fab- bricazione di ATECC608a e di altri componenti della famiglia di elementi sicuri di Microchip . Le credenziali segrete vengono create utilizzando moduli HSM (Hard- ware Secure Module) che vengono installati negli sta- bilimenti Microchip. Le credenziali generate non sono autorizzate a lasciare l’elemento sicuro una volta pro- grammate. ATEC608a non rivela la chiave privata sulla porta di comunicazione e utilizza un meccanismo an- timanomissione basata su hardware per impedire che vengano condotti attacchi di natura fisica per ottenere i dati segreti memorizzati al suo interno. Ad esempio, se un utente malintenzionato volesse tagliare la scher- matura metallica che ricopre i circuiti sensibili nel ten- tativo di sondare fisicamente il dispositivo, l’elemento cesserà immediatamente di funzionare. Le contromi- sure per gli attacchi di tipo “glitching” e l’analisi side- channel in canali passivi impediscono di ottenere i dati chiave utilizzando le emissioni elettromagnetiche. Non è sufficiente fornire chiavi e certificati segreti in un elemento sicuro. La catena di approvvigionamen- to deve implementare meccanismi per generare cer- tificati e trasferirli da e verso il sito di produzione in modo che l’OEM o l’operatore possano mantenere un elenco di dispositivi che potranno connettersi alla rete dopo l’installazione. Alcuni di questi certificati dovran- no essere trasferiti nel database utilizzato dal servi- zio cloud che gestisce l’autenticazione del dispositivo. Chiaramente, la creazione di tale infrastruttura di pro- duzione è un’impresa complessa e costosa. Non solo richiede l’acquisto e la manutenzione di infrastrutture hardware come gli HSM per la programmazione degli elementi sicuri, ma comporta anche un costo elevato in termini di formazione e gestione del personale. L’opzione outsourcing A causa dell’elevato costo derivante dalla programma- zione interna sicura, un’opzione è quella di affidare le operazioni in outsourcing a un produttore di elettronica a contratto o a un altro fornitore di servizi. Tuttavia, ciò comporta generalmente costi di installazione elevati. I servizi di generazione e consegna dei certificati devono essere personalizzati per ciascun prodotto. Per giustifi- care gli elevati costi fissi del processo di installazione, i fornitori di servizi richiedono normalmente ordini mini- mi di centinaia di migliaia di unità. Una risposta è stata quella di offrire un approccio unico per tutti gli aspetti della gestione delle chiavi. Ciò comporta una collabo- razione sinergica tra fornitori di servizi cloud e dell’e- lettronica al silicio, con uno di loro che si occupa della creazione e gestione dei certificati. Tutti i certificati ri- portano al proprietario dell’account cloud, che funge da autorità di certificazione centrale. Il suo database viene utilizzato per monitorare tutti i dispositivi IoT per i qua- li detiene i certificati e altri dati per conto di ciascuno degli utenti. Ciò non richiede che il cliente sia legato a un servizio cloud specifico. Al contrario, il servizio cen- trale fornisce autenticazione e altri servizi di sicurezza che possono essere utilizzati dalle proprie applicazioni cloud dei clienti. Ciò li libera dalla gestione quotidiana della sicurezza e dell’autenticazione e li aiuta a concen- trarsi sulla loro applicazione principale. Ma con questo modello il produttore non può fungere da autorità di certificazione per i propri dispositivi e deve utilizzare lo stesso provider cloud per tutti i servizi di autenticazione. Molti produttori desiderano un approccio più flessibile alla gestione della sicurezza. La struttura ideale per la gestione dei certificati dipenderà dalle esigenze dell’ap- plicazione. In un tipico scenario IoT in cui è necessario inviare un numero elevato di dispositivi, e a più clienti, è probabile che il root certificate sia di proprietà e ge- stito dall’OEM. Tuttavia, più operazioni saranno delegate a servizi che si basano su ulteriori certificati intermedi. Ad esempio, per incorporare i sistemi nella rete prescel- ta, ogni singolo cliente può utilizzare un certificato di livello intermedio derivato da quello root per generare certificati a livello di dispositivo. Ciò consente ai server o alle applicazioni del cliente in esecuzione nel cloud di verificare l’identità e assicurarsi che sul campo stiano funzionando con i dispositivi IoT giusti.