Il GDPR è stato concepito quando la tecnologia informatica dominante era quella dei servizi cloud centralizzati, con un modello di raccolta dei dati che continua ad essere la principale fonte di profitto per le aziende. Da allora, le tecnologie decentralizzate, tra cui figurano quelle dei registri distribuiti, tra cui la blockchain, hanno avuto uno sviluppo accelerato.
Ciò può richiedere delle modifiche al framework GDPR la cui applicazione a trattamenti di dati personali basati su tecnologie decentralizzate è molto complessa, perché queste tecnologie tendono ad annullare le differenze – sul piano tecnico – tra chi fornisce il servizio e chi lo utilizza e quindi rendono più complessi i rapporti tra le figure fondamentali della protezione dati così come fino a oggi li abbiamo intesi. Di conseguenza, il rispetto del GDPR pone un certo numero di sfide che potrebbero rallentare o sconsigliare l’adozione nei trattamenti dei dati personali.
Il contrasto tra GDPR e blockchain
Il contrasto tra la blockchain, e le norme GDPR è interessante perché da un lato evidenzia che i distributed ledger garantiscono proprietà quali l’integrità e la disponibilità dei dati personali in modo intriseco grazie alla loro natura decentralizzata, alla immutabilità – per certi versi – dei dati e alla loro tracciabilità. In questa prospettiva, i distributed ledger possono essere considerati come un esempio di sistema che vuole garantire queste proprietà fin dal progetto (by design) e non grazie a modifiche successive. L’introduzione degli smart contract enfatizza ulteriormente questa caratteristica, garantendo anche l’integrità e la disponibilità delle operazioni sui dati, oltre che la loro esecuzione automatica. Quasi a smentire questa prospettiva, altre proprietà dei ledger, quali il numero non noto a priori di copie del ledger o l’immutabilità dei dati memorizzati, possono apparire in contrasto con alcuni dei diritti fondamentali che il GDPR vuole garantire, ovvero
- il diritto alla conoscenza di come i dati personali sono memorizzati ed elaborati
- il diritto alla modifica dei dati personali
- il diritto alla cancellazione o al delisting dei dati, detto anche diritto all’oblio.
Molti, ad esempio l’European union blockchain observatory & forum, hanno già affrontato questo apparente contrasto e sottolineato come il contrasto porta alla luce alcune assunzioni implicite nel GDPR su una elaborazione dei dati sostanzialmente centralizzata o dove comunque le varie copie del dato vengano create da un unico controllore del dato stesso. Come vedremo anche nel seguito, queste assunzioni implicite creano significativi problemi di attribuzioni di ruoli e responsabilità.
Il concetto di “cancellazione”
Inoltre, il contrasto evidenza anche che il GDPR non definisce in modo univoco che cosa intenda con cancellazione. Infatti, il termine può indicare la distruzione irreversibile del dato o quella del supporto fisico di memorizzazione o la impossibilità di visualizzarlo o usarlo in una qualsiasi elaborazione. Ovviamente, la garanzia che le funzioni software che implementano una certa elaborazione non accedano ad un dato non impedisce che l’accesso sia ottenuto mediante librerie diverse o mediante un frammento di codice software iniettato nella libreria stessa.
Linee guida 7/2020 EDPB su titolare e responsabile, ecco le definizioni per individuare i ruoli
Altri problemi interpretativi sul controllo dei dati nascono quando si considera che alcuni di coloro che hanno la responsabilità di elaborare i dati possono non conoscerli, perché possono accedere a questi dati solo quando sono già criptati, ma le loro limitate capacità di azione sui dati potrebbero comunque essere ricomprese nella nozione di trattamento qualora vi siano margini per la reidentificazione ovvero la riconnessione ad individui dei dati in qualche modo inintelligibili.
Dati memorizzati su distributed ledger: tre soluzioni
Nel seguito analizzeremo tre soluzioni alternative per una base di dati personali memorizzata su un distributed ledger per scoprire se ne esiste una che meglio rispetti la norma e lo spirito del GDPR. Le tre soluzioni che considereremo sono:
- la blockchain di una criptovaluta
- un distributed ledger che memorizza direttamente nei propri blocchi i dati personali
- un distributed ledger indice, che permette l’accesso ad un database distinto che memorizza dati personali.
L’analisi dei tre casi permette un primo insieme di conclusioni che presenteremo dopo l’analisi delle diverse implementazioni della base di dati.
Criptovalute e GDPR
Il distributed ledger che regola una criptovaluta è di tipo pubblico e senza permessi, ovvero chiunque può diventare un miner, scaricando una copia del ledger ed iniziando ad operare. In questo caso, il ledger memorizza fondamentalmente informazioni sulle transazioni collegate alla criptovaluta ovvero acquisti e cessioni di beni o di quantità di criptovalute. Vengono anche memorizzate le chiavi pubbliche delle organizzazioni e delle persone coinvolte nelle transazioni. Inoltre, nella blockchain di bitcoin alcuni campi della transazione possono essere utilizzati per memorizzare informazioni personali. L’elaborazione fondamentale che utilizza la blockchain è l’esame degli acquisti e vendite di un certo soggetto per calcolare la quantità di criptovaluta che il soggetto possiede ed evitare il fenomeno del double spending. Considerando i vari articoli GDPR e l’implementazione delle blockchain di criptovalute, è abbastanza immediato dedurre che
- una blockchain contiene informazioni personali protette dal GDPR a partire dalle chiavi di cifratura. Queste informazioni possono essere memorizzate in forma pseudoanonima, ad esempio cifrandole o comprimendole in un hash ma comunque l’informazione originale può essere ricostruita purchè venga comunicata una ulteriore informazione, ad esempio la chiave di cifratura,
- esiste una molteplicità di data controller che operano come “titolari autonomi” sui dati memorizzati del ledger. Ad esempio, ogni miner determina ed esegue un insieme di elaborazioni sui dati per realizzare una propria finalità. E’ vero che il ruolo del singolo miner può non essere decisivo nello stabilire il risultato di una elaborazione ma indubbiamente ogni miner, mentre opera per finalità proprie contribuisce computazionalmente all’attività di altri miner.
- l’informazione di una transazione inserita in un blocco che è stato collegato alla blockchain non può essere cancellata o modificata.
Un esempio delle possibili elaborazioni di dati personali permesse dalla blockchain è quella che ricostruisce tutte le transazioni che hanno coinvolto il proprietario di una certa una chiave privata. Identificato il proprietario, o la proprietaria, è immediato scoprire anche tutte le transazioni eseguite. Importante sottolineare come risultati simili possano essere ottenuti con analisi forensi che analizzino e correlino le varie transazioni che coinvolgono una stessa chiave e che questi risultati semplificano la reidentificazione del proprietario di una chiave.
Questo è un problema già noto, al punto che la proposta originale di bitcoin suggeriva di utilizzare una chiave privata in una singola transazione, inviando i bitcoin posseduti ma non utilizzati dalla transazione ad una diversa chiave privata. Strategia possibile ma che aumenta la complessità della gestione delle chiavi per il singolo utilizzatore. Soluzioni simili vengono utilizzate da criptovalute come Monero che aumentano le garanzie di privacy sulla identità di chi è coinvolto in una transazione. Qualcuno ipotizza maliziosamente che il successo di questa criptovaluta sia dovuto ad un rapporto FBI che evidenziava la difficoltà di violare l’anonimato da essa consentito.
I pareri sui miner
Per quanto riguarda b) è, ad esempio, indubbio che un miner sia in grado di decidere quali elaborazioni eseguire per il proprio beneficio personale e cioè il compenso ricevuto quando il blocco proposto viene accettato dagli altri miner. Alcuni pareri, ad esempio quello del Gruppo di Lavoro “Art. 29” ed un report del Parlamento Europeo, ritengono questa condizione sufficiente per stabilire che il miner è un data controller nell’accezione GDPR visto che memorizza tutta la blockchain. Di parere diverso la Commission Nationale Informatique et Libertés che non crede sia possibile attribuire il ruolo di controller ad una persona che aggiunga record ad una blockchain. La stessa CNIL ritiene che il ruolo di controller vada attribuito in base non tanto alle funzioni ma alla influenza nel determinare gli obiettivi del servizio.
Nel caso di una blockchain pubblica con transazioni commerciali, la CNIL ritiene che il miner sia un controller. Altri vedono il miner come colui che offre un servizio base ma non è responsabile di tutti i risultati del servizio, ritenendolo assimilabile alla figura del data processor prevista dal Regolamento. Tuttavia il data processor (o responsabile del trattamento nella traduzione italiana) è definito quale soggetto che opera sui dati su mandato del data controller (cfr. Art. 4 GDPR), situazione questa difficilmente riscontrabile nell’ambito dei distributed ledger in cui i miner operano ciascuno indipendentemente da, ed in competizione con, gli altri. In questo caso, si fa una analogia tra il miner ed un fornitore di connettività o di risorse cloud che non sono responsabili, rispettivamente, dei contenuti che altri trasmettono o delle elaborazioni che altri eseguono.
Data processor e data controller
La diversità di interpretazioni può essere vista come una conferma che talune assunzioni del GDPR si rivelano non adeguate nel momento in cui si decentralizza la computazione tra un numero di soggetti non noto a priori e non controllabile. Soprattutto quando i soggetti agiscono con spiccati livelli di autonomia senza legami formali e rapporti di tipo giuridico che li obblighino a specifiche prestazioni e responsabilità.
Da questo punto di vista, la scelta tra data processor e data controller è molto legata anche alla natura pubblica o privata della blockchain. In una blockchain privata, l’attribuzione al miner del ruolo di processor è molto più adeguata rispetto a quello di controller. Ovviamente, l’attribuzione o meno del ruolo di controller ad un miner ha ripercussioni pesanti sulla applicabilità del GDPR visto che vi sono criptovalute con decine di migliaia di miner. Infine, altri lavori ritengono che blockchain e GDPR non siano in rotta di collisione perché non corretto discutere il problema in astratto. Attribuire una volta per tutte i ruoli di data producer e controller per la blockchain non ha senso, sarebbe come decidere i ruoli per tutta la rete internet. Il problema deve essere risolto caso per caso per la specifica blockchain.
Supponendo risolto il problema dei ruoli ed identificato il proprietario della chiave non è ovviamente possibile rimediare al leak di informazioni cancellando la corrispondente chiave da tutti i record in cui appare, perché questo violerebbe il metodo per garantire l’integrità della blockchain. Esistono proposte di utilizzare chameleon hash ovvero hash che possono essere modificati quando cambiano alcune informazioni nel blocco ma questa soluzione introduce una chiave di cifratura il cui possesso garantisce la possibilità di modificare l’hash di un blocco e quindi la catena dei blocchi. Siamo di fronte ad una ulteriore implementazione del principio di “amministratore onnipotente” che ha generato un grande numero di vulnerabilità ed attacchi. Stupisce che ambienti che hanno, giustamente, avversato per decenni recovery key o backdoor di stato ora propongano una soluzione che invalida alla base una delle proprietà più innovative della blockchain. Anche a prescindere da queste considerazioni, la soluzione non è in alcun modo applicabile alla blockchain di Bitcoin.
Right to be forgotten: le difficoltà
I problemi che impediscono la cancellazione di transazioni sono gli stessi alla base della difficile implementazione del Right to be forgotten. Anche in questo caso, la blockchain può modificare qualche informazione solo aggiornando, in tutte le copie, i blocchi che la contengono. Di nuovo, si ripresenta il problema del ricalcolo dell’hash del blocco che si deve modificare e di quelli che contengono l’hash. Nel caso del Right to be forgotten, una diversa implementazione può essere quella che rende il dato inutilizzabile, costruendo così una soluzione che alcune legislazioni ritengono soddisfi il requisito normativo dettato dall’Art. 17 del GDPR (diritto alla cancellazione).
Ad esempio, si possono introdurre nuove transazioni il cui obiettivo è quello di inserire nella blockchain informazioni che indichino che altre transazioni possono essere utilizzate solo per verificare l’assenza di double spending ma non per leggere una delle chiavi. Questa soluzione è senz’altro possibile ma è anche molto facile da violare, basta diventare un miner, scaricare una copia del ledger ed accedere alla copia privata del ledger utilizzando una propria libreria di funzioni. In altri termini, il mancato controllo su chi può essere un miner implica anche la perdita di controllo sui moduli software che il singolo miner utilizza per accedere ai dati. In ultima analisi, l’unico modo di mitigare le discrepanze tra la blockchain di bitcoin e il GDPR è quello di usare una sola volta una chiave privata.
Il caso di un distributed ledger che memorizzi dati personali
È ovviamente possibile progettare e implementare ex novo un distributed ledger per la memorizzazione di una base di dati che comprenda anche dati personali. In altre parole, in questo caso i blocchi del ledger memorizzano informazioni personali ed il progetto del ledger può tener conto dei vincoli del GDPR ed adottare le opportune soluzioni. Ad esempio, il sistema può utilizzare meccanismi di indicizzazione per accedere ai dati basati su hash con chiave, talora indicati come peppered hashes. L’adozione di peppered hash permette di sconfiggere quegli attacchi che invertono un hash calcolando tutti gli hash degli elementi di un insieme. Inoltre, le informazioni possono essere codificate nei blocchi con chiavi non note ai gestori del distributed ledger in modo che solo il proprietario possa decidere a chi comunicare una chiave e rivelare così una certa informazione.
Anche nel caso di un ledger progettato ex novo però il diritto alla modifica o alla cancellazione del dato richiesti dal GDPR pongono il problema della modifica dell’hash di un blocco e di quelli che da questo hash dipendono. Una possibile soluzione prevede di utilizzare un ledger permissioned in modo da controllare chi è ammesso ad operare sul ledger. Questo controllo permette a cascata di verificare i moduli software che vengono usati per operare sul ledger. In pratica, si può garantire che tutti coloro che operano utilizzino soluzioni che impediscano di accedere ai dati quando opportune informazioni vengono inserite nel ledger.
In pratica, il ledger memorizza non solo le informazioni ma anche i diritti di accesso alle informazioni stesse. Inoltre tutti coloro che operano sui dati utilizzano moduli software che verificano mediante informazioni memorizzate nel distributed ledger i diritti di accesso ai dati. Questa soluzione impedisce di accedere alle informazioni sul ledger anche se un attacco riesce ad ottenere una copia del ledger purchè le informazioni stesse siano cifrate. È bene sottolineare che l’attacco può coinvolgere anche uno solo dei miner. Infatti, è sufficiente che uno solo degli autorizzati violi le regole sul software da utilizzare per provocare un leaking dei dati. Le vulnerabilità che un attaccante può sfruttare sono quindi le stesse che potrebbe utilizzare contro un database tradizionale. È ovvio comunque che una soluzione permissioned non introduce nuovi meccanismi software ma sfrutta solo la capacità di controllare a priori i moduli utilizzati. Come già detto, questa capacità si ripercuote anche sulla qualifica di data controller che è ovviamente correlato all’appartenenza al gruppo di coloro che possono elaborare i dati del ledger.
Distributed legder come indice
Questa soluzione si ispira ad un suggerimento dello European Union Blockchain Observatory & Forum secondo cui “it could be argued that blockchain networks should be used to store immutable proofs that certain data exists, rather than to store the data itself”. Questa strategia, indicata spesso come off chain storage, memorizza le informazioni in database esterni al distributed ledger che viene usato solo come meccanismo base per garantire l’accesso ai dati e per verificarne l’integrità. È ovviamente possibile memorizzare i dati in un sistema tradizionale o al limite addirittura centralizzato ma, come discusso in un nostro precedente contributo, spesso interessa estendere anche alle informazioni nello off chain storage le proprietà di affidabilità ed accessibilità tipiche di un distributed ledger. Per questa ragione, supporremo che il supporto utilizzato per la memoria off chain permetta di distribuire le informazioni tra un elevato numero di nodi fisici. Il sistema complessivo comprende sia moduli che gestiscono il ledger sia server di memoria ed ogni volta che si accede ad un dato memorizzato si usa il ledger per individuare il dato e verificarne l’integrità.
Un possibile esempio di off chain storage che soddisfa le proprietà richieste è InterPlanetary File System, un sistema p2p in cui nessun nodo è privilegiato ed in cui i nodi IPFS memorizzano oggetti IPFS localmente. I file IPFS non possono essere modificati visto che il loro identificatore viene generato in base al loro contenuto ma possono esistere versioni diverse dello stesso file. IPFS garantisce la disponibilità di un file anche in presenza di guasti permanenti o temporanei definendo cluster di peer e replicando un file tra i peer del cluster. In questa soluzione, il distributed ledger memorizza le informazioni per accedere al file in IPFS insieme alla versione e all’hash del file.
Il distributed ledger può anche contere informazioni sui diritti di accesso e quindi un utente può accedere ad un file solo se autorizzato dall’informazione nel ledger. Anche un ledger pubblico può utilizzare questa soluzione purché le informazioni vengano memorizzate criptate nella off chain storage. In questo modo, la chiave per decifrare verrà comunicata solo a coloro che il proprietario desidera autorizzare. Inoltre, utilizzando chiavi diverse per versioni diverse è anche semplice aggiornare le informazioni ed impedire l’accesso di chiunque alle versioni precedenti. La cancellazione delle varie chiavi di cifratura è una possibile soluzione per garantire il right to be forgotten.
L’impiego di off chain storage
L’uso di una off chain storage di tipo tradizionale, per quanto replicata ed affidabile, permette di soddisfare vincoli e regole pensate per un sistema più classico separando nettamente le funzioni di accesso e di verifica di integrità da quelle per aggiornamento e garanzia della disponibilità. Esisteranno, in generale, un numero diverso di repliche delle informazioni per l’accesso e delle informazioni vere e proprie. La possibilità di definire il numero delle repliche per ogni file permette di ottimizzare il rapporto costo prestazioni tenendo conto del diverso numero di accessi ad ogni file. Occorre comunque considerare che il numero diverso di repliche può implicare che il livello di disponibilità garantito da una memoria off chain possa essere diverso, e quindi anche inferiore, a quello garantito da un distributed ledger.
Una prima conclusione possibile è che una soluzione che riesca a fondere i distributed ledger con una memoria off chain può permettere di sfruttare al meglio la eliminazione degli intermediari e le garanzie di integrità offerte da un distributed ledger sfruttando contemporaneamente la disponibilità garantita da un off chain storage di tipo p2p. Notiamo che queste conclusioni dipendono dalle caratteristiche strutturali dei distributed ledger e sono indipendenti dal modello di consenso che il legder usa tra, ad esempio, proof of work, proof of stake, o voting. Questa conclusione conferma analisi che già all’apparire del GDPR la avevano indicata come l’unica strategia possibile per la modifica o la cancellazione dei dati.
Una possibile obiezione all’uso di off chain storage è che il meccanismo delle versioni può essere implementato anche memorizzando le informazioni direttamente nei blocchi di un distributed ledger. Questa soluzione aumenta però la complessità di tutte le operazioni rallentando, di conseguenza, anche la generazione dei blocchi ovvero la velocità di crescita del ledger. L’aumento della complessità può essere particolarmente importante quando si opera mediante smart contract perché la semplificazione dello smart contract riduce anche la probabilità di errori o vulnerabilità aumentando la correttezza e la sicurezza offerte.
___
Bibliografia
- U. Tatar, Y. Gokce, B. Nussbaum, Law versus technology: Blockchain, GDPR, and tough tradeoffs, Computer Law & Security Review, Volume 38, 2020,
- G. Ateniese, M. Bernardo, V. Daniele, A. Ewerton Redactable blockchain–or–rewriting history in bitcoin and friends Proceedings of the IEEE European symposium on security and privacy. 2017, pp. 111-126
- M. Finck Blockchain and the general data protection regulation can distributed ledgers be squared with European data protection law? Eur Parliam Res Serv, 32 (2019)
- M. Finck Blockchains and data protection in the European Union, Eur Data Prot L Rev, 4 (2018), p. 17
- N. Eichler, S. Jongerius, G. McMullen, O. Naegele, L. Steininger, K. Wagner, Blockchain, data protection, and the GDPR. Blockchain Bundesverband eV. (2018).
- M. Rahman, F. Baiardi, B. Guidi, L. Ricci, Protecting Personal Data using Smart Contracts, Int. Conf. on Internet and Distributed Systems, 2019
- M. Rahman, F. Baiardi, B. Guidi, L. Ricci, Context-aware and dynamic role-based access control using blockchain. In International Conference on Advanced Information Networking and Applications (pp. 1449-1460). Springer, April 2020
- Committee on International Trade, Report on Blockchain: a Forward-Looking Trade Policy (AB-0407/2018), EU parliament, 27/11/2018
- Commission Nationale Informatique et Libertés,, Premiers Éléments d’analyse de la CNIL: Blockchain, September 2018
- European Union Blockchain Observatory & Forum, Blockchain and the GDPR, Oct. 2018
- Lokke Moerel Blockchain & Data Protection … and Why They Are Not on a Collision Course, European Review of Private Law Volume 26, Issue 6 (2018)
- F. Baiardi, C. Comella, Distributed ledger, utilizzarli come memoria persistente e affidabile, Blockchain4Innovation,
