Le linee guida dell’AGiD relative alle best practice di secure design per le architetture basate su registri distribuiti (DLT).

Leggi l’articolo di Francesco Dagnino e Filippo Belfatto (LEXIA Avvocati).

Lo scorso 7 maggio 2020, l’Agenzia per l’Italia Digitale (“AGiD”) ha emanato, ai sensi dell’art. 71 del codice dell’amministrazione digitale (“CAD”), le linee guida relative alle best practice di secure design per le architetture basate su registri distribuiti (DLT), in conformità ai principi di Secure/Privacy by Design (le “Linee Guida”).

Il presente contributo ha lo scopo di illustrare gli orientamenti adottati dall’AGiD e indirizzati agli sviluppatori delle tecnologie DLT, riassumendo le principali indicazioni fornite dall’Autorità.

Preliminarmente, è opportuno specificare brevemente che lo scopo delle Linee Guida è l’analisi dei processi, metodi e modelli concernenti la progettazione di applicazioni software sicure, fornendo quindi indicazioni agli attori del settore, durante la fase di progettazione e creazione del software, per la modellazione delle minacce e per l’individuazione preventiva di potenziali azioni e procedure volte alla mitigazione delle stesse in conformità con il principio di c.d. “Secure/privacy by Design”. 

Nel contesto delle indicazioni contenute nelle Linee Guida, l’AGiD ha redatto un apposito paragrafo (nello specifico il paragrafo numero 1.1.1.3 delle Linee Guida) concernente i registri distribuiti (DLT) o, come specificato nel documento, le tecnologie “più notoriamente [denominate] Blockchain”. Con riferimento alla definizione di DLT, e in aggiunta alla definizione introdotta ai sensi dell’art. 8-ter comma 3 del d.l. n. 135/2018 (c.d. Decreto Semplificazioni), convertito nella legge 11 febbraio 2019 n. 12, le Linee Guida specificano che le DLT “sono sistemi informatici che gestiscono dati, transazioni o codici eseguibili (Smart Contracts) in modo il più possibile indipendente da un’autorità centrale attraverso l’utilizzo di data storage distribuito in correlazione con processi crittografici e sistemi decisionali decentralizzati”.

Sulla base del principio di neutralità tecnologica della regolamentazione, le Linee Guida dovrebbero essere adottate da tutti gli operatori del settore indipendentemente dalla specifica applicazione della tecnologia DLT. Pertanto, come specificato nelle Linee Guida, l’ambito di applicazione delle prescrizioni contenute nel documento è esteso alle più svariate applicazioni della tecnologia, ad esempio:

  1. sistemi di identità digitale (Self Sovereign Identity);
  2. sistemi di certificazione garantita di dati e certificazioni (Verifiable Claims);
  3. creazione e gestione di nuovi mercati digitali (vedi i mercati peer to peer di scambio energetico) fino alla creazione e gestione di nuove entità (vedi ad esempio le DAO/DAC Distributed Autonomous Organizations/Corporations)”.

Preliminarmente, quindi, l’AGiD ha ritenuto fondamentale analizzare i profili di integritàdisponibilità e riservatezza dei dati memorizzati in una DLT.

Con riferimento all’integrità dei dati, le Linee Guida specificano che “uno dei fattori fondamentali che assicurano tale caratteristica in una DLT è la struttura a blocchi concatenati attraverso la funzione di hash”. Tuttavia, l’AGiD avverte gli operatori che tale caratteristica connaturata alle DLT “di per sé non basterebbe se non fosse affiancata da un adeguato algoritmo di consenso che garantisca l’immediata evidenza di una qualsivoglia modifica di questa struttura in confronto a strutture uguali esistenti nei vari nodi componenti la DLT”.

In altre parole, le Linee Guide riconoscono che la struttura a blocchi delle DLT “amplifica la sicurezza della funzionalità di hash attraverso la concatenazione dei dati”, ovverosia che “la modifica di un blocco in posizione <n> implicherebbe la conseguente modifica di tutti i blocchi successivi fino alla testa della catena”, ma raccomandano agli operatori di settore di considerare quale “fattore critico relativamente all’integrità dei dati […] quello dato dall’algoritmo di consenso”. Pertanto, in relazione alla sicurezza di tali algoritmi, le Linee Guida suggeriscono agli operatori di rispettare le indicazioni fornite nel documento stesso in relazione all’applicazione del principio c.d. “Secure by Design” (si vedano i paragrafi 5.2 e seguenti delle Linee Guida nonché quanto specificato nel prosieguo del presente testo).

In relazione alla disponibilità dei dati di una DLT, le Linee Guida prescrivono che “è intrinsecamente garantita dall’infrastruttura sottostante: difatti ogni nodo di una DLT (a meno di nodi specifici, normalmente chiamati “light nodes”) detiene una intera copia della struttura dati e quindi l’indisponibilità degli stessi si potrebbe avere solo nel caso in cui tutti i nodi fossero allo stesso istante inattivi”. Pertanto, da un lato “attacchi che mirino ad un eventuale centro non avrebbero senso in una struttura decentralizzata”, tuttavia un possibile attacco sulla disponibilità dei dati “dovrebbe essere mirato all’intera infrastruttura e quindi avere ad esempio come obiettivo il software di base, al fine di rendere indisponibili le informazioni negandone l’accesso attraverso la modifica della modalità con cui tutti i nodi operano”.

Infine, con riferimento alla riservatezza dei dati, l’AGiD ha riconosciuto che varia ampiamente a seconda della specifica tecnologia utilizzata, ad esempio “alcune DLT sono intrinsecamente trasparenti (vedi bitcoin) in quanto chiunque ha accesso a tutte le transazioni fatte da qualsivoglia partecipante e la confidenzialità è demandata all’anonimità dei partecipanti che vengono identificati da un indirizzo generico”. In tali applicazioni della tecnologia, sarebbe tuttavia più corretto ritenere che le transazioni e i relativi dati siano pseudo-anonimi poiché dall’analisi delle ripetute attività di un indirizzo è possibile risalire all’identità del soggetto persona fisica ovvero giuridica. Invece, alcune DLT con caratteristiche differenti, ovverosia maggiormente orientate all’anonimità dei partecipanti e delle transazioni (ad esempio “Zcash” o “Monero”), comportano che per “un osservatore esterno è praticamente impossibile risalire agli attori parte di una qualsiasi transazione proprio per le tecnologie utilizzate (ad esempio “ring transactios”, una caratteristica concernente la blockchain Monero).

Pertanto, e “in qualsiasi caso”, le Linee Guida raccomandano agli sviluppatori di tecnologie DLT di “provvedere ad una adeguata gestione della riservatezza dei dati in modo disgiunto dalla gestione dell’infrastruttura: il livello di riservatezza da implementare sarà come al solito legato alla tipologia dei dati e le metodologie le stesse applicate a qualsiasi altra tipologia di data storage”.

Con specifico riferimento alla sicurezza delle DLT, le Linee Guida analizzano alcuni elementi che compongono la tecnologia per fornire alcune indicazioni operative concernenti lo sviluppo. A tal proposito, il documento dell’AGiD prende in considerazione le seguenti caratteristiche delle DLT:

  1. rete infrastrutturale peer-to-peer;
  2. struttura dati (concatenazione di blocchi);
  3. algoritmi di consenso (e.g. PoW, PoS, etc);
  4. smart contract e logiche dinamiche (e.g. token, DAC/DAO, etc.).

Riguardo l’infrastruttura, l’AGiD ritiene che un possibile attacco di “Distributed Denial of Service” potrebbe provenire “dall’utilizzo di wallet/accounts per generare grandi numeri di transazioni al fine di rallentare la rete. Un evento del genere, anche se non rappresentante un attacco, è avvenuto nella rete Ethereum all’apparire dello smart contract CryptoKitties: questo smart contract ha raggiunto volumi superiori al 10% dell’intero volume di transazioni della rete, causando un indesiderato rallentamento dell’intera rete”.

Con riferimento alla struttura dati, le Linee Guida correlano il tema con le caratteristiche e il funzionamento dell’algoritmo di consenso poiché quest’ultimo determina i requisiti per l’introduzione di nuove transazioni (ovverosia dati) nei blocchi della catena di una DLT. Pertanto, l’AGiD ha ritenuto opportuno analizzare le due tematiche in modo congiunto.

Quindi, in relazione all’analisi di un algoritmo di consenso, preliminarmente, le Linee Guida evidenziano l’applicabilità del teorema CAP, ovverosia che “è impossibile per una DLT garantire contemporaneamente più di due dei seguenti elementi:

  1. Consistenza: una DLT è consistente quando i fork sono evitati, caratteristica detta anche “finalizzazione del consenso”. In pratica i nodi devono tutti avere la stessa copia del ledger nello stesso momento;
  2. Disponibilità: una DLT è disponibile se le transazioni generate dai client sono gestite e quindi “committed” (cioè aggiunte alla catena di blocchi)
  3. Tolleranza alle partizioni: quando una partizione della rete avviene, i nodi autoritativi sono divisi in gruppi disgiunti affinché i nodi di un gruppo non possono comunicare con i nodi di un altro gruppo”.

Inoltre, considerando che l’algoritmo di consenso è un costrutto sviluppato dal singolo operatore, la responsabilità in relazione alle proprietà summenzionate, e, quindi, il funzionamento della DLT, è in capo allo sviluppatore che decide “quali caratteristiche siano fondamentali per lo specifico caso d’uso”.

Infine, le Linee Guida illustrano alcuni attacchi di cui possono essere vittime le DLT:

  1. Il block withholding attack (BWH) ha come obiettivo le mining pools e fa in modo che il sistema di reward delle stesse pool non sia più corretto, gratificando alcuni partecipanti al pool (che normalmente sono anche gli attaccanti) ricevere dei premi non proporzionali con il lavoro di mining effettuato;
  2. l’attacco denominato “selfish mining” prevede che un attaccante possa guadagnare dei premi non proporzionali con il lavoro di mining effettuato generando deliberatamente dei fork;
  3. l’attacco denominato “Fork after withholding” (FAW), similarmente al selfish mining, utilizza false fork: a differenza perà il reward di un attaccante FAW è sempre maggiore od uguale a quello di un attaccante BWH ma è utilizzabile fino a 4 volte più spesso;
  4. il famoso attacco del 51% (principalmente orientato al consenso PoW) prevede che un gruppo di nodi con più del 51% della capacità di minare possa decidere in ogni caso qual è la prossima transazione indipendentemente dalla realtà (da considerare che un simile attacco su altri algoritmi quali il PBFT potrebbe essere portato anche con il 33% dei nodi);
  5. l’attacco denominato “eclipse attack” prevede un attacco non a tutta la rete ma solo ad uno o pochi nodi. L’attaccante isola il nodo e poi introduce transazioni malevole facendo in modo che lo stesso nodo non si accorga della non-sincronizzazione con i suoi peer;
  6. l’attacco denominato “spatial partitioning” prevede l’isolamento di un autonomous system che gestisce uno o più sistemi di mining e ridurre il mining power globale: questo attacco è portato in generale per facilitare altri attacchi attraverso proprio la riduzione del mining powrer;
  7. l’attacco denominato “consensus delay” è associato con la natura P2P delle blockchain: in questo attacco si iniettano blocchi falsi con lo scopo di incrementare la latenza e quindi prevenire i nodi dal raggiungere un consenso sullo stato della DLT.
  8. l’attacco denominato “Finney Attack” prevede che il minatore possa minare un blocco che contenga una delle proprie transazioni e mantenerlo nascosto (stealth): c’è la possibilità di un double-spending nel caso in cui merchant accetti la transazione non confermata. A seguire il blocco nascosto viene pubblicato prima che la transazione venisse confermata dalla rete.”

Come precisato dalle Linee Guida, il predetto elenco non costituisco un elenco esaustivo di tutti i possibili attacchi ma vuole “sottolineare le tipologie degli stessi e quindi le azioni preventive da tenere in considerazione” per gli operatori di settore.

Infine, l’AGiD evidenzia ed avverte gli sviluppatori di tecnologie DLT che “la maggioranza degli attacchi è orientata verso le applicazioni (smart contracts) che girano sulla DLT e non sulla chain stessa”. Pertanto, sottolinea l’AGiD, gli operatori dovrebbero concentrarsi “sulla qualità delle applicazioni che operano sulla DLT e prevedere per le stesse lo stesso ciclo di controllo di un qualsiasi software sviluppato come da linee guida AGID”.

Per maggiori informazioni:

Avv. Francesco Dagnino

Tel. (+39) 02 890 78 580

Email: francesco.dagnino@lexia.it

Via dell’Annunciata, 23/4

20121 Milano

Tel. (+39) 02 3663 8610

Email: info@lexia.it

Web: www.lexia.it


0 commenti

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *