Alla fine di settembre Teleconsys ha depositato la richiesta di brevetto internazionale per un sistema distribuito. Il sistema si chiama dOra ed è il frutto di una lunga attività di ricerca partita circa cinque anni fa sperimentando con smartcard criptografiche e blockchain. In questo breve articolo vi racconto di cosa si tratta.
Background
Negli anni ’80 il peggior incubo di un IT manager era il guasto di un sistema dipartimentale. Con l’avvento dell’architettura client-server l’incubo è diventato il guasto dello storage o di un server critico, ma con la virtualizzazione e cloud-computing finalmente gli IT manager hanno iniziato a dormire tranquillamente. Questo periodo di serenità è però durato poco perché la possibilità di collegarsi alle piattaforme aziendali via internet ha portato nuovi rischi e nuove tipologie di problemi.
Il nuovo incubo che tormenta le notti degli IT manager si chiama cybersecurity
Questo nuovo problema ha una natura molto diversa: i virus e cyber attack non sono guasti ma minacce attive progettate appositamente per produrre ingenti danni. Questo rischio è molto difficile da affrontare per un informatico perchè in realtà è legato ad aspetti organizzativi: ogni piattaforma applicativa prevede ruoli amministrativi che inevitabilmente devono essere assegnati a molteplici utenti di cui ci si deve fidare, ma che anche in buonafede possono sbagliare.
I virus cercano utenti con credenziali amministrative per poi poter agire con pieni poteri sul sistema per rubare dati, cancellare o peggio, immetterne di falsi. Le credenziali amministrative di una piattaforma cloud sono estremamente pericolose perchè offrono un singolo punto di attacco (un “single point of control”) con cui compromettere l’intero sistema.
Gli attacchi silenziosi a un single point of control possono durare anni senza essere notati (come il famoso hack di SolarWinds). In questo periodo l’organizzazione criminale ottiene informazioni che spesso usa e altre volte vende.
È sostanzialmente impossibile prevenire efficacemente questa minaccia perchè spesso il criminale si avvale di personale infedele che fornisce un contribuito determinante al successo dell’attacco.
Questo spiega perché questo problema crea gran brutti incubi agli IT manager: siamo passati a dover prevenire problemi tecnici a dover svolgere un lavoro da HR intelligence, senza sottovalutare che l’IT manager stesso può essere corrotto.
Possibili soluzioni
Come si può prevenire che un collaboratore commetta un errore o si lasci corrompere?
Esistono varie soluzioni tecnologiche che dissuadono comportamenti scorretti perché permettono di dimostrare il dolo, tuttavia questo approccio non impedisce l’errore involontario.
Questo argomento è già stato affrontato e risolto negli anni ’60 dal prof. Paul Baran a cui si devono gli studi che ci hanno portato dalle reti telefoniche a Internet (On distributed communication – Introduction to distributed communication network).
Baran ha studiato come rendere resistente dagli attacchi di vario tipo la rete telefonica. La rete era strutturata in modo molto simile a come sono oggi le piattaforme cloud: grandi sistemi a cui tutti gli utenti si collegavano direttamente. L’infrastruttura odierna è molto più resistente, ma la piattaforma applicativa ha un centro nevralgico.
La soluzione di Baran è semplice: bisogna distribuire in modo più ampio possibile i sistemi funzionali coinvolti nella gestione della rete. Per spiegare la sua idea coniò tre aggettivi che si possono applicare alle reti ma più in generale a tutte le architetture informatiche o a organizzazioni operative: centralizzata, decentralizzata e distribuita.
Intuitivamente una rete centralizzata ha un centro che diviene un punto critico, una decentralizzata ne ha molti quindi il guasto di alcuni non crea un disservizio globale.
Quella che ci interessa è la tipologia di rete distribuita dove non c’è alcun centro: nessun sistema è un sistema critico per la sopravvivenza dell’intera rete (o dell’intera piattaforma o dell’intera organizzazione).
Internet è figlia delle idee di Baran e infatti non c’è alcun centro nevralgico: se il mio punto d’accesso alla rete è guasto posso usare un altro service provider. Se una tratta del percorso che mi collega a un server remoto si interrompe il mio traffico prenderà uno dei molteplici percorsi alternativi senza necessità di alcun intervento umano.
La natura totalmente distribuita della rete Internet (almeno nella maggioranza delle sue tante parti) rende perfino difficile attuare delle procedure restrittive che impediscono completamente il collegamento a sistemi remoti.
La decentralizzazione delle piattaforme applicative
È possibile creare una piattaforma applicativa distribuita, ovvero una dApp? La risposta è sì perché esiste già. Anzi, ne esistono molte.
Già dagli anni ’70 molti sistemi critici sono stati progettati per essere fault-tolerant creando cluster di apparati. Tuttavia, dal punto di vista applicativo si tratta ancora di sistemi centralizzati. Per arrivare ad avere un’applicazione completamente distribuita occorre attendere il 2009: la prima piattaforma ad erogare un servizio critico a migliaia di utenti e completamente priva di un singolo punto di controllo attaccabile è Bitcoin, seguita poi da tutti i suoi derivati.
Bitcoin e derivati forniscono un servizio di trasferimento di valore del tutto analogo al sistema SEPA che interconnette le banche (ovvero gli intermediari finanziari) per inviare denaro con un bonifico. Tuttavia in Bitcoin non vi sono intermediari: nessuno può impedire l’immissione di una transazione, pertanto si può sostenere che non ci sia alcuna forma di intermediazione.
Bitcoin, inoltre, è una piattaforma con una caratteristica mai vista prima: chiunque può partecipare attivamente alla gestione del servizio attivando un nodo della rete distribuita, senza dover ricorrere ad autorizzazioni o credenziali. In altre parole, nessuno lo può impedire.
Da questa architettura distribuita deriva la straordinaria sicurezza di Bitcoin e derivati che ha portato l’investimento complessivo in criptomonete a sfiorare il trilione di dollari.
La sicurezza del sistema è talmente elevata e comprovata che molti progettisti IT hanno pensato di portare parti critiche delle piattaforme cloud su blockchain, anche sfruttando gli smartcontract supportati da varie reti. Un approccio ibrido che tuttavia non ha prodotto un risultato soddisfacente proprio a causa degli smartcontract.
Gli smartcontract sono programmi eseguiti dai nodi validatori delle reti durante il mining, attività in cui i nodi competono per produrre il prossimo blocco e ottenere la ricompensa: se l’esecuzione degli smartcontract li rallentasse nessun nodo li eseguirebbe.
Per evitare rischi di rallentamento e altre problematiche, gli smartcontract elaborano solo dati già presenti nel registro, ovvero nel database del nodo e quindi occorre che qualcun altro fornisca loro i dati da elaborare.
Gli oracoli
Come l’Oracolo di Delfi che collegava il mondo dei vivi con quello dei morti, così gli oracoli moderni collegano le applicazioni con la blockchain immettendo dati che verranno elaborati dagli smartcontract.
Questo sistema tuttavia non risolve i problemi di sicurezza delle applicazioni cloud based. Infatti, gli smartcontract elaborano dati che potrebbero essere stati manomessi o prodotti artificiosamente grazie a un oracolo “compromesso”.
Abbiamo solo spostato il problema. Per risolverlo realmente ci occorre la certifica di chi ha immesso il dato nel registro distribuito e che il dato è stato acquisito in modo corretto. Questo è esattamente l’obiettivo del sistema dOra (che fornisce molti altri servizi e vantaggi).
Gli oracoli decentralizzati e il sistema dOra
Il sistema dOra di Teleconsys è stato progettato per realizzare un oracolo distribuito che possa fornire un dato di cui si può verificare l’autenticità e la correttezza.
Nel realizzare questo sistema ci siamo tuttavia resi conto che potevamo andare ben oltre: possiamo usarlo anche per elaborare il dato prima che venga pubblicato e ciò significa che la successiva elaborazione da parte degli smartcontract non è più indispensabile.
In pratica possiamo suddividere il processo operativo di una generica piattaforma cloud per farlo eseguire da più sistemi dOra in sequenza (o parallelo). Se riusciamo a “destrutturare” l’applicazione cloud, allora abbiamo raggiunto l’obiettivo di renderla distribuita e quindi non più attaccabile.
Come funziona il sistema dOra
I sistemi distribuiti funzionano creando “consenso” sul loro operato. Sono composti da più sistemi (nodi) che eseguono un compito in modo indipendente: se una maggioranza di sistemi ha ottenuto la stessa informazione allora si dice che quell’informazione è dotata di ampio consenso.
In pratica il consenso sul risultato di una elaborazione implica che è stato eseguito correttamente e che quindi il dato è da considerarsi valido.
Nel sistema dOra i nodi che collaborano si uniscono per formare un “comitato”. Un comitato è attivato da un governor (in sostanza il proprietario del sistema) che chiede a soggetti terzi di partecipare. Questi soggetti possono essere remunerati o semplicemente essere interessati a mettere a disposizione delle risorse computazionali per ottenere i dati prodotti dal comitato. Il governor non ha altre funzioni o poteri.
Per produrre consenso i nodi del comitato si scambiano informazioni. Abbiamo previsto due possibili canali di comunicazione:
• via TCP/IP per avere comunicazioni molto rapide
• via messaggi scambiati via rete IOTA per avere comunicazioni molto affidabili
La seconda opzione è particolarmente vantaggiosa per applicazioni critiche perché l’indirizzo di rete dei nodi del comitato non viene mai reso noto e pertanto sono protetti da attacchi via Internet.
I dati prodotti dal comitato sono firmati digitalmente. Ciò permette a chi li utilizza di poterne verificare la validità.
Tuttavia una normale firma digitale non permette di verificare sia stata prodotta da molteplici nodi. Per fornire questa informazione il sistema dOra prevede che ogni soggetto coinvolto sia identificato (in modo rispettoso della privacy):
• Ogni nodo è dotato di una identità basata su standard W3C DID
• Il comitato stesso è dotato di identità W3C DID
• Queste informazioni sono incluse nel DID Document, ovvero il set di dati che permettono di validare l’identità di un soggetto: il DID Document del comitato contiene l’elenco dei DID dei nodi e ogni DID Document di ogni nodo contiene il DID del comitato
• La firma dei dati, prodotta dal comitato, è ottenuta con uno schema di “firma a soglia”
Lo schema di firma a soglia prevede che i nodi producano una chiave pubblica comune e permette di realizzare un sistema realmente distribuito perché la chiave relativa chiave privata non esiste.
I nodi possono produrre una firma valida solo scambiandosi firme parziali dello stesso dato derivate da loro chiavi private che ovviamente non vengono condivise.
Lo schema di firma a soglia fornisce tre garanzie:
• È possibile produrre una firma valida solo se la maggioranza dei nodi del comitato collabora attivamente alla realizzazione della firma. Quindi impossibile ottenere una firma valida di un dato falso.
• La produzione della firma valida è possibile solo se ogni nodo del comitato sta firmando lo stesso dato. Ciò implica che anche se un nodo non ha operato correttamente, il suo contributo non impatta sul dato pubblicato dal comitato.
• Se anche una minoranza di nodi non collabora, la maggioranza è in grado di produrre una firma valida vanificando un attacco attuato con nodi non collaborativi.
Grazie a queste caratteristiche è possibile creare applicazioni distribuite o rendere distribuite parti critiche di quelle esistenti.
Programmazione del sistema dOra
Un comitato dOra può essere programmato con un semplice script. Lo script contiene le indicazioni su dove acquisire i dati (una URI) e le indicazioni su come acquisire un’immagine Docker che contiene l’algoritmo di elaborazione.
La fase di elaborazione dei dati è in realtà molto flessibile perché possono essere attivate più immagini in sequenza. Ciò permette di produrre consenso anche su dati che, dal punto di vista di ogni nodo, divergono.
Il consenso sarà prodotto su dati derivati poi pubblicati insieme ai dati “raw” per permettere di verificare la correttezza della prima fase di elaborazione e valutare l’errore statistico introdotto.
Ogni nodo segue lo script e poi esegue la procedura di firma. Dati, firma e chiave pubblica sono pubblicati su una URI specifica.
Infine è possibile richiedere ai nodi di conservare i dati (con le relative firme e chiavi pubbliche). Quando un client chiederà i dati conservati, i nodi produrranno una firma a soglia che dimostra che ognuno ha conservato lo stesso dato in modo distribuito.
Il sistema dOra ci permette di realizzare praticamente ogni tipologia di applicazione in modo distribuito.
Il ruolo di IOTA
Sebbene siamo partiti pensando il sistema dOra come un affidabile oracolo per le reti distribuite, di fatto dOra è sostanzialmente indipendente dalla blockchain ma ne sfrutta alcuni servizi di elevato valore. Tra questi servizi vi è la possibilità di pubblicare e conservare i DID Document dello standard di identità W3C DID.
Grazie alla sicurezza della rete IOTA queste informazioni critiche sono conservate con il massimo dell’affidabilità rendendo il sistema dOra virtualmente immune da attacchi basati sul furto di identità dei nodi.
Applicazioni del sistema dOra
Disporre di un sistema distribuito completamente programmabile in grado di garantire la qualità dei dati che produce, permette di realizzare praticamente qualsiasi applicazione.
Tra i primi casi d’uso su cui stiamo lavorando vi è una piattaforma IoT. Queste piattaforme sono nate per semplificare la gestione di grandi flotte di device remoti. La principale funzione che dovevano svolgere era il monitoraggio dello stato operativo dei device e produrre allarmi in caso di guasti, ma nel tempo si sono arricchite con molteplici servizi tra i quali c’è la raccolta e conservazione dei dati.
Per questo motivo sono oggetto di innumerevoli attacchi che negli ultimi dieci anni hanno causato miliardi di dollari di danni a produzioni industriali.
Grazie a dOra e la rete IOTA è possibile progettare un sistema completamente sicuro:
• La piattaforma non deve archiviare dati in un db centralizzato perché i device li inviano direttamente via IOTA ai destinatari. IOTA garantisce la conservazione e l’accessibilità dei dati.
• Le funzioni di gestione e monitoraggio sono svolte da un sistema dOra. Queste funzioni sono gestite in modo distribuito quindi non possono essere veicolo di attacchi ai device.
Inoltre, per rafforzare ulteriormente la sicurezza di una rete IoT distribuita stiamo realizzando un apposito device che, sempre grazie allo standard W3C DID, aggiunge alla sicurezza del sistema l’identificazione certa della sorgente dei dati.
Un altro caso d’uso del sistema dOra è un “Object Storage Distribuito”. Gli object storage sono i sistemi di archiviazione più versatili ed economici oggi disponibili tipicamente via cloud. Il limite di questi strumenti è che sempre lo stesso di ogni altro sistema centralizzato: c’è sempre qualcuno che ha il potere di modificare o cancellare i dati immessi.
dOra permette di risolvere questo problema creando un comitato dove ogni nodo gestisce il proprio Object Storage. Ogni nodo riceve, firma con la propria chiave privata e archivia i dati, quindi ogni nodo ha una versione leggermente diversa dei dati. Ciò permette agli altri nodi di versificare che abbia correttamente conservato un dato quando viene richiesto da un cliente:
• Ogni nodo recupera il proprio dato (completo di propria firma) e ne produce l’hash
• Condivide l’hash con tutti gli altri
• Quando tutti hanno l’hash degli altri nodi ogni nodo condivide la propria copia del dato.
• Ogni nodo può verificare che l’hash del dato fornito dagli altri nodi è corretto, ovvero ha effettivamente conservato il dato in modo appropriato.
• Se esiste una maggioranza di nodi che ha conservato correttamente il dato allora il comitato può pubblicare il dato richiesto, comprensivo di firma a soglia.
I nodi che non hanno conservato il dato in modo corretto saranno penalizzati ed esclusi dal comitato.
Il cliente che riceve il dato può verificare che è stato conservato correttamente, quindi è autentico, perché è stato firmato dal comitato. Inoltre, in fase di archiviazione il l’hash del dato può essere pubblicato su rete IOTA ed ottenere la “proof of inclusion”, ovvero una firma del blocco in cui è stato pubblicato l’hash. Questa informazione aggiuntiva viene conservata con il dato stesso e permetterà di dimostrare che il dato fornito dal comitato ha lo stesso hash di quello che era stato inviato dal client per conservarlo.
Vi sono poi innumerevoli altri casi dove è possibile applicare il sistema dOra anche solo per rafforzare la sicurezza di un’applicazione tradizionale.
Il limite è solo la fantasia
