Tecniche di Onboarding dei dispositivi
Questo approfondimento fa parte della serie dedicata alle tecniche di onboarding sicuro dei dispositivi IoT in piattaforma cloud. L’articolo esplora tre metodologie principali: l’autenticazione basata su informazioni hardware e di connessione, l’utilizzo di credenziali statiche precaricate, e l’implementazione di certificati a mutua autenticazione x.509. Viene analizzata in dettaglio ogni tecnica, evidenziandone vantaggi, svantaggi e considerazioni di sicurezza nel contesto delle moderne piattaforme cloud come AWS.
Tecniche di Onboarding IoT: Metodi di Autenticazione e Sicurezza
L’onboarding può avvenire contattando un servizio oppure un intermediario che accetta operazioni di pubblicazione e sottoscrizione da parte dei dispositivi (il broker usato nei paradigmi di comunicazione Message Oriented Middleware). Indipendentemente dalla modalità di scambio scelta con la piattaforma, possiamo distinguere questi approcci basandoci sul tipo di dati scambiato per il riconoscimento della legittimità del dispositivo alla comunicazione.
Primo metodo. Utilizzo di Informazioni sulla connessione e l’hardware
In questo metodo la piattaforma ricorre alle informazioni correnti di connessione usate dal dispositivo per riconoscerlo e considerarlo affidabile.
Step 1. Un operatore autorizzato riceve l’indirizzo IP ed il codice seriale del dispositivo che dovrà essere installato in campo. Tramite un servizio presente in piattaforma, con il suo ruolo procederà all’aggiornamento della base dati contenente l’insieme delle coppie (indirizzo IP, codice seriale) autorizzate alla comunicazione.
Step 2. Il servizio dedicato all’Onboarding, a cadenza fissata recupererà dal database l’insieme di indirizzi IP e procederà con l’aggiornamento delle regole di apertura rotte in ingresso. Se stiamo lavorando sul cloud provider AWS, questa operazione consiste nell’aggiornamento delle regole in inbound del security group associato all’EC2.
Step 3. il dispositivo contatta il servizio di onboarding mandando nel suo primo messaggio il suo codice seriale. La piattaforma accerta che il codice seriale corrisponda a quello assegnato all’indirizzo IP. Se la verifica ha esito positivo, il dispositivo è abilitato alla comunicazione con i restanti servizi di monitoraggio e controllo offerti dalla piattaforma. Si noti che un dispositivo con indirizzo IP non presente in piattaforma o con codice seriale non conforme non è supportato dal servizio di onboarding.
Il vantaggio di questa tecnica consiste nel non dover mantenere alcuna credenziale a bordo del dispositivo per autenticarsi in piattaforma perché sarà la piattaforma stessa a gestire una whitelist contenente l’insieme degli indirizzi IP e dei codici seriali autorizzati al dialogo. Lo svantaggio di questo approccio consiste nel dover usare un riferimento fisso per la connessione, come un indirizzo IP pubblico statico oppure ricorrere ad una soluzione che permetta alla piattaforma di “seguire” le variazioni di connessione del dispositivo (Pensiamo ad un canonical name assegnato al dispositivo con un servizio DNS che si occupa di tradurlo).
In quest’ultimo scenario si aprono ulteriori complessità di gestione, come la scelta di chi e come dovrà aggiornare le variazioni della connessione. Delegare il dispositivo
nell’aggiornamento richiederebbe l’introduzione di un ulteriore meccanismo di autenticazione e controllo.
Se volessimo lasciare questa Idra ad Ercole optando per il servizio di indirizzamento pubblico statico, un fattore da considerare sono i costi previsti dal proprio ISP (Internet Service Provider). Su logiche di larga scala potrebbe non essere la strategia migliore. Si potrebbe ovviare al problema dell’indirizzamento dinamico tramite l’allestimento di una VPN (menzionata in precedenza), accettando però i relativi costi di amministrazione e manutenzione.
Secondo metodo. Utilizzo di credenziali statiche pre-caricate a bordo del dispositivo
Esempio. Utilizzo di Access Key e secret Key di un’utenza AWS pre-caricate a bordo del dispositivo:
Step 1. un operatore autorizzato assume un ruolo in piattaforma per poter censire l’utenza dedicata per il dispositivo con la definizione dei permessi associati.
Step 2. L’operatore immette e salva in un’area di memoria sicura del dispositivo le credenziali associate all’utenza creata.
Step 3. il dispositivo si autentica in piattaforma. Se il nostro cloud provider è AWS, abbiamo una coppia di valori noti come Access Key e Secret Key con cui il dispositivo può accedere in piattaforma. Qualsiasi operazione il dispositivo tenta di fare in piattaforma è soggetta a revisione. Viene consultata una tabella che definisce per un’utenza l’insieme delle azioni consentite. AWS offre questo servizio tramite L’identity Access Management (IAM). Se l’utenza è autorizzata, potrà interagire con le funzionalità offerte dalla piattaforma.
Un pre-requisito è che la sua utenza sia censita preventivamente a sistema. Nel caso di smarrimento delle credenziali, è richiesto un intervento manuale per la rigenerazione.
Minacce
In questa soluzione ci si espone al rischio di compromissione delle credenziali. un attaccante potrebbe impossessarsi della coppia username/password presente a bordo del dispositivo e impersonificarlo. Una soluzione per arginare questo problema consiste nel riportare queste credenziali in un’area sicura di memoria del dispositivo. Ciò non toglie che le credenziali sono comunque esposte al guessing, quindi deve essere costantemente aggiornata per ridurre le probabilità di individuazione.
Terzo metodo. Utilizzo di certificati a mutua autenticazione
I certificati a mutua autenticazione seguono lo standard x.509. è uno standard proposto dall’Unione internazionale delle telecomunicazioni (ITU-T), usato per definire il formato dei certificati a chiave pubblica (PKC) e delle autorità di certificazione (CA).
I certificati superano diverse limitazioni dei precedenti metodi. A differenza della password, anche se un certificato viene rubato, senza la chiave privata di cui solo il dispositivo può essere in possesso l’attaccante non può interagire con la piattaforma. I certificati possono essere revocati in caso di compromissione mentre l’invalidamento di una password permette all’attaccante di poter sfruttare la sessione corrente per completare la sua attività. Infine, ogni volta che mandiamo un messaggio con l’autenticazione basata su certificati il messaggio viene “firmato”, mentre con l’utilizzo di password i messaggi non lo sono.
Con la firma digitale abbiamo la garanzia che il messaggio provenga effettivamente dal dispositivo e che il contenuto del messaggio non sia stato alterato durante il transito. Solo il dispositivo che possiede la chiave privata corrispondente al certificato può generare quella firma e non può affermare di non aver inviato il messaggio “firmato”.
Le autorità di certificazione sono gli enti che attestano che un certificato è autorizzato. Possiamo vederle come i nostri Paesi che ci rilasciano il passaporto.
Step 1. Un operatore PKI autorizzato genera le credenziali specificando quale sarà la CA associate alle richieste dietro queste credenziali. Le credenziali cambiano a seconda del protocollo scelto per la verifica di identità del dispositivo. Il più longevo è il protocollo SCEP, in cui il dispositivo ricorre ad una challenge password per poter presentare la richiesta di emissione del certificato. Il più recente è il protocollo EST, dove vengono generate delle chiavi di pre-enrollment da affidare al dispositivo. Il sistema le salva e le rende disponibili al servizio di enrollment.
Step 2. L’operatore immette e salva in un’area di memoria sicura del dispositivo le credenziali associate all’identità creata.
Step 3. Mettiamoci nei panni di un dispositivo, che ha bisogno di dialogare con la piattaforma. Il dispositivo genera una coppia di chiavi (una chiave privata e una chiave pubblica), ma non sa come generare il suo certificato firmato da un’autorità. Ricordiamo la metafora del passaporto. Dove andiamo a richiederlo? In questura. La questura nel mondo IoT è la PKI. Il dispositivo crea una richiesta di certificato (CSR, Certificate Signing Request). Questa richiesta contiene la chiave pubblica e altre informazioni identificative (ad esempio, l’Organization Unit, il Subject Name, ecc.). La PKI riceve la CSR e verifica l’identità. In questo flusso entrano in gioco i protocolli menzionati in precedenza (SCEP ed EST).
Se la verifica dell’identità è andata a buon fine, la PKI emette il certificato firmandolo con la CA dedicata per il dispositivo. Pensiamo alla piattaforma AWS. È possibile avere una sola CA attestata in una region. Cosicché, se il dispositivo deve essere installato in Nord America (es.region North Virginia), è cosa buona firmare il suo certificato con la CA di North Virginia anziché con quella europea. Questo certificato contiene la chiave pubblica del dispositivo. La PKI “firma” il certificato utilizzando la chiave privata della CA. Questa firma digitale garantisce l’autenticità del certificato e permette a chiunque riceva il certificato di verificare che sia stato emesso effettivamente dalla CA.
Quando la piattaforma IoT viene contattata dal dispositivo e riceve il certificato, può usare la chiave pubblica della CA per verificare la firma. Se la verifica ha successo, la piattaforma può fidarsi della validità del certificato.
Implementazione di Policy Progressive per la Sicurezza IoT
In questo metodo, notiamo un aspetto peculiare. C’è bisogno di un’interazione tra la PKI e la piattaforma IoT per aggiornare il censimento dei certificati autorizzati a dialogare con la piattaforma. I certificati sono visti dalla piattaforma IoT come un’identità a cui tramite delle policies è possibile dire cosa fare e non fare.
Ad esempio, al certificato associato ad un dispositivo che deve ancora stabilire la sua prima connessione in piattaforma possiamo limitare alcune funzionalità. Sicuramente quella di cancellazione, poiché sarebbe un controsenso consentire a chi non è ancora registrato di cancellarsi da una piattaforma. Ma potremmo anche bloccare tentativi di invio dati.
La piattaforma non può accettare messaggi da chi deve ancora formalmente registrarsi. È come se si consentisse ad un utente non registrato di poter scambiare in totale anonimato dei messaggi con gli altri utenti registrati su un forum. Questa restrizione è un esempio di implementazione di policy progressive di accesso, dove i permessi per interagire con i canali di comunicazione della piattaforma sono rilasciati solo a quei dispositivi pre-autorizzati, che rispettano le condizioni previste di ingresso.
Con AWS è possibile ricorrere al servizio di Just in time Registration. La Just in Time Registration è un processo che consente alla piattaforma di non dover conoscere a priori quali sono i certificati autorizzati a comunicare, a patto che si presentino con un certificato firmato da una CA considerata affidabile. Quindi un pre-requisito per abilitare questo scenario è quello di rendere attendibile su AWS la stessa CA usata dalla PKI.
Tra i 3 approcci suggeriti, a costo di una gestione ed implementazione più complessa, il terzo è quello che permette di mitigare i principali rischi legati all’ingresso di un nuovo dispositivo in piattaforma. Spetta all’architetto di soluzioni software il compito di disegnare e adottare la soluzione più indicata per l’organizzazione in cui lavora, venendo incontro ai requisiti temporali ed economici.
In questo approfondimento abbiamo esplorato le principali metodologie di onboarding sicuro per dispositivi IoT, dalla gestione basata su IP fino ai certificati x.509, analizzando vantaggi e criticità di ogni approccio. Nel prossimo articolo della serie approfondiremo le tecniche di validazione hardware nell’onboarding IoT, con particolare focus sulle best practice di sicurezza. Per una visione completa dell’argomento, vi invitiamo a scaricare il white paper integrale “Onboarding dei dispositivi IoT” di Fabrizio Giorgione e Giovanni Cappabianca.
Fabrizio Giorgione si è laureato nel 2018 alla magistrale in ingegneria informatica presso l’università degli studi del Sannio con una tesi dal titolo “Analisi della superficie di attacco di un sistema SCADA”. Nello stesso anno ha iniziato a lavorare nel settore della Cyber Defense in NTT Data come Cyber Security Expert all’interno dello zenSOC in molteplici contesti internazionali occupandosi anche di tematiche relative all’incident response, email security, malware analysis e threat intelligence.Ha conseguito numerose certificazioni tra cui: CompTIA CySA+, Splunk, Proofpoint, Microsoft, FireEye e Fortinet e utilizza le sue conoscenze e competenze per guidare e supportare colleghi e amici su tematiche legate alla cyber security e all’ingegneria dell’informazione.
Giovanni Cappabianca, classe 1992, ha conseguito la laurea magistrale in Ingegneria Informatica presso l'Università degli Studi del Sannio (BN) nel 2016.
La sua carriera professionale è iniziata in Ernst & Young, dove ha ricoperto il ruolo di Data Analyst, acquisendo competenze fondamentali nell'analisi dei dati. Nel 2017, ha partecipato a una competizione indetta dal Gruppo Ferrovie dello Stato, distinguendosi tra i primi 28 candidati su un ampio numero di partecipanti. Questo successo lo ha portato a trascorrere due anni presso la capogruppo "Ferrovie dello Stato S.p.A." come ICT Project Manager, dove ha affinato le sue capacità nella gestione di progetti complessi. Successivamente, Giovanni è entrato a far parte del Gruppo Enel come ingegnere del software specializzato nell'Internet of Things (IoT).
Attualmente, ricopre il ruolo di Architetto IoT, occupandosi dell'analisi dei requisiti di business e della progettazione di soluzioni architetturali IoT end-to-end. Le sue responsabilità includono la fornitura di stime e tempi di realizzazione, la gestione tecnica dei progetti come team leader e l'analisi dei costi dei servizi cloud AWS, con l'obiettivo di individuare opportunità di ottimizzazione.
