La sicurezza nelle Blockchain è divenuto un tema “caldo”, soprattutto ora che l’articolo 8-ter del recente “decreto semplificazioni” (Legge 11 febbraio 2019) ha introdotto nella normativa italiana gli smart contract e le blockchain ‒ ove queste ultime sono sinonimo di “tecnologia basata su registro distribuito” (ovvero DLT: Distributed Ledger Technologies).
È fondamentale, dunque, ricordare che non esiste un’unica Blockchain, bensì molteplici blockchain basate su tecnologie potenzialmente anche molto diverse fra loro.
Un po’ come descrivere la propria automobile dicendo che è basata sulla “tecnologia del motore a scoppio” non permette di valutare né il costo dell’auto, né le prestazioni del motore, né tantomeno la sua affidabilità, allo stesso modo parlare solamente di “blockchain”, ovvero di “registro distribuito” non è utile per nessuno e, anzi, può rivelarsi particolarmente dannoso ‒ soprattutto quando, così come per l’automobile, si vada a valutare parametri fondamentali quali il costo e l’affidabilità.
Indice degli argomenti
Sicurezza nelle Blockchain: algoritmi innovativi per la convalida delle transazioni
Parliamo di costo, innanzitutto, perché il registro distribuito è solo una componente delle blockchain: la tecnologia delle basi di dati distribuite, infatti, esiste da più di quarant’anni[1] ed è oggi ampiamente utilizzata da una miriade di servizi online che poco o nulla hanno che fare hanno con le blockchain.
Realizzare una blockchain significa implementare non solo un registro distribuito, ma anche vari meccanismi per consentire agli attori della tecnologia di interagire con tale registro (cioè leggerlo e, all’occorrenza, modificarlo e propagare le modifiche a tutte le copie del registro).
Se si considera il Bitcoin come esempio più famoso di sistema basato su una blockchain, tale criptovaluta deve la sua fortuna non soltanto dall’uso di un registro distribuito, ma anche alla sapiente implementazione di algoritmi innovativi per la convalida delle transazioni monetarie (crittografia a chiave pubblica), nonché per la remunerazione, gli incentivi e l’avvicendamento delle code (il cosiddetto “proof of work”) e dei portafogli elettronici dei suoi correntisti, oltre che mantenere la sostenibilità (tramite i cosiddetti “minatori” di bitcoin) e l’auto-consistenza della sua blockchain.
Ciascuno di questi meccanismi, da solo, meriterebbe una trattazione a parte. È bene perciò effettuare un’analisi dei costi adeguata prima di realizzare con una blockchain un servizio che potrebbe essere efficacemente (ed economicamente) realizzato mediante un sottoinsieme di tali tecnologie, come ad esempio basi di dati “sublimati” in cloud per ottenere una efficace e conveniente decentralizzazione dei dati.
Valutare i componenti tecnologici per la sicurezza nelle Blockchain
Riguardo l’affidabilità, vanno anche qui valutati individualmente i diversi componenti tecnologici di una blockchain, per poi considerarne la sicurezza nella sua interezza.
Innanzitutto, è sempre l’uomo a programmare gli algoritmi di funzionamento delle blockchain, perciò uno dei passi da affrontare è effettuare valutazioni di impatto proprio su questa componente “software”, prendendo in considerazione scenari ove codice “malevolo” o comunque non autorizzato viene eseguito dai nodi, eventualmente modificando lo schema decisionale della blockchain.
In alcune blockchain, ad esempio, la variazione degli algoritmi di funzionamento (cioè le “regole del gioco”) è essa stessa una funzionalità contemplata by design, ma solo a fronte di un quorum tra i nodi che ne fanno parte, stabilita con modalità più o meno automatizzate.
In alcuni casi è necessaria una maggioranza assoluta dei nodi, che divengono in quel caso “plenipotenziari” relativamente ai cambiamenti effettuabili. Va considerato, quindi, che le blockchain neonate, formate inizialmente da pochissimi nodi, potrebbero facilmente costituire delle “oligarchie informatiche” auto-regolamentanti, anziché fornire un esempio di democrazia tecnologica.
Anche senza valutare scenari così estremi, la logica di funzionamento di molte blockchain potrebbe essere codificata ab initio per subire metamorfosi pre-programmate del proprio codice non appena l’inflazione dei nodi superi determinate soglie, seguendo meccanismi noti dello sviluppo biologico e anche, si badi bene, a prodotti finanziari ben più tradizionali.
Attenzione però: una blockchain pur dotata di una “costituzione democratica” e i cui nodi siano in totale buona fede potrebbe essere vulnerabile a una “congiura tecnica” di agenti malevoli che, violando un numero di nodi pari al quorum, si impossessano dell’intera blockchain, realizzando quello che viene chiamato, appunto, “attacco del 51%”.
Tali problematiche sono perciò legate all’inflazione intrinseca nelle blockchain. Proprio per questo motivo è necessario che gli stakeholder coinvolti possano revisionare il codice sorgente e verificare che tale codice sia quello realmente in esecuzione sui nodi dell’effettiva blockchain d’interesse, ad esempio mediante meccanismi di apposizione di firme o sigilli elettronici sul codice, che siano a loro volta verificabili in maniera indipendente ed “esterna” dalla blockchain.
L’importanza della robustezza del sistema di identificazione
Il governo di molte tecnologie blockchain è decentralizzato e tolto dall’appannaggio di una singola autorità di controllo; questo aspetto sicuramente innovativo e dirompente è spesso uno dei migliori argomenti a favore di tali tecnologie.
Tuttavia, una tecnologia senza un’autorità centrale “di governo” è cosa ben diversa da una senza alcun controllo a livello “tecnico”; è bene puntualizzare questa importante differenza, che può generare gravi problemi di sicurezza.
Nel caso delle blockchain “private” (o permissioned, come si chiamano in gergo), la robustezza del registro dipende dall’obbligo di identificare coloro che lo consultano e, ancor più, che ne modificano il contenuto, mediante sistemi di controllo sicuro delle autorizzazioni.
Tuttavia, anche nel caso di blockchain completamente “aperte” (o permissionless) ‒che possono essere consultate e modificate da chiunque ‒ tale controllo inteso come mera autenticazione continua ad essere requisito fondamentale, in quanto le firme digitali che legano ogni blocco della catena al successivo si basano sul controllo dell’integrità del blocco precedente.
Anche in questo caso l’auto-consistenza dell’intera blockchain è protetta dalla robustezza del sistema di identificazione effettuato dai nodi: chiunque può accedervi, ma l’integrità di ogni transazione (o blocco di transazioni) sarà comunque riconducibile alle entità autenticate per essa.
Regolamento eIDAS, firme e sigilli elettronici
Tornando alla legislazione italiana, nel sopracitato decreto si attribuisce alle blockchain il ruolo di marcature temporali che, secondo il Regolamento europeo (UE) 910/2014, denominato “eIDAS”, sono una tipologia di servizi fiduciari elettronici che collegano dei dati a una particolare ora e data, così da provarne l’esistenza in quel momento.
Il Regolamento eIDAS disciplina anche le firme e i sigilli elettronici che, come abbiamo visto, sono anch’essi tasselli fondamentali per qualunque blockchain, in quanto l’immutabilità e l’autenticità di ciascun blocco della catena sono, in ultima analisi, sempre garantiti dall’apposizione di un sigillo elettronico (se in capo a un software o comunque per conto di un soggetto giuridico), ovvero alla sottoscrizione mediante una firma elettronica (se da parte di una persona fisica).
Il Regolamento eIDAS tratta, infine, gli schemi di identificazione elettronica (in Italia, lo SPID e la Carta d’Identità Elettronica) quali tasselli fondamentali per autenticare cittadini e imprese, in maniera interoperabile e transfrontaliera, presso qualunque servizio online.
A tali schemi potrebbe, ad esempio, essere demandata la fase di mera autenticazione presso alcune tecnologie blockchain, invece di una vera e propria firma elettronica (argomento trattato, tra l’altro, anche dall’art. 20 del CAD e di prossima emanazione con apposite Linee Guida da parte di AGID).
Bisogna precisare, però, che solo le firme, i sigilli e le marcature temporali elettroniche qualificate ai sensi del Regolamento eIDAS, così come gli schemi di identificazione elettronica notificati alla Commissione Europea (ad oggi solo lo SPID), garantiscono la piena interoperabilità a livello europeo, oltre alla garanzia di poterne facilmente verificare la validità mediante strumenti aperti e disponibili nell’internet pubblico.
Ancora una volta, non va confusa l’assenza di un’autorità centralizzata che governi alcune tipologie di blockchain, con la mancanza di un sistema “aperto” che permetta di convalidare alcuni aspetti quali il codice sorgente, la precisione dell’orario ovvero le modifiche al registro distribuito.
Per l’assenza della prima, infatti, trattasi di una specificità architetturale che, quando presente, è tipicamente voluta by design; per la mancanza della seconda, invece, trattasi di una vera e propria vulnerabilità di sicurezza.
Valutazioni tecnologiche per la sicurezza nelle Blockchain
Per essere precisi, una caratteristica peculiare delle blockchain consiste nell’autenticità e immutabilità intrinseca dei dati in esse contenuti (ex art. 8-ter del decreto semplificazioni), ottenuta dalla possibilità di verificare l’integrità di ogni blocco risalendo ricorsivamente all’indietro all’integrità di blocchi precedenti, fra di loro incatenati.
Sebbene ciò sia teoricamente realizzabile e potrebbe in linea di principio sostituire l’esigenza di affidarsi ad autorità certificanti per la validità dei suddetti servizi fiduciari elettronici, vi sono due problematiche di sicurezza associate.
Innanzitutto, il trust model appena descritto implica che la “fiducia tecnica” dell’intera blockchain dipenderebbe interamente dalla fiducia nelle primissime transazioni avvenute nel registro, ricadendo quindi nelle problematiche del modello inflazionario delle blockchain descritto poco sopra.
Come secondo problema, a fronte della possibilità teorica, vi è invece l’impossibilità tecnica di effettuare tali verifiche ricorsive qualora il registro distribuito diventi una catena di blocchi troppo lunga: la convalida completa dell’intera catena comporterà una richiesta di risorse computazionali e di rete definitivamente eccessiva (che, se non adeguatamente gestita, potrebbe rendere l’intera blockchain indisponibile a causa di eccessive richieste di convalida).
Un ultimo aspetto che ogni valutazione di impatto su una tecnologia blockchain dovrebbe considerare riguarda infine l’infrastruttura tecnologica su cui le blockchain, immancabilmente, vengono eseguite.
Che si tratti di dispositivi mobili sotto il presunto esclusivo controllo degli utenti, di macchine virtuali sublimate in qualche cloud più o meno privato, ovvero di server in “vil metallo” che “minano e sminano” senza sosta in locali definiti con precisione catastale, la più tradizionali minacce informatiche non dovrebbero mai essere ignorate.
Il rischio di infettare, corrompere, esfiltrare i dati “incatenati”, o di rendere comunque inutilizzabile parte dell’infrastruttura deve essere valutato, possibilmente confrontato con quello legato a diverse scelte tecnologiche e, infine, adeguatamente trattato o mitigato. La decentralizzazione delle blockchain va di pari passo con l’elevata interconnettività tra i suoi nodi ed utenti (questi ultimi spesso connessi tramite il proprio smartphone), contribuendo perciò al perimetro di sicurezza che tende a gonfiarsi e sgretolarsi sempre di più e va, perciò, adeguatamente protetto.
Si veda, ad esempio, D.J. Rosenkrantz, R.E. Stearns, P.M. Lewis II, ‘System level concurrency control for distributed database systems’ in ACM Transactions on Database Systems, Vol.3(2), pagg. 178-198, New York, giugno 1978; ovvero P.A. Bernstein, N. Goodman, ‘Timestamp-based algorithms for concurrency control in distributed database systems’, in Proceeding of the 6th international conference on Very Large Data Bases, Vol. 6, pagg. 285-300, Montreal, ottobre 1980. ↑
