Deel 1 in onze reeks ging in op wat blockhain op conceptueel niveau wel en niet kan. Deel 2 gaat in op wat blockchain wel kan: het beschermen van data en het afdwingen van regels (met inbegrip van transfereren van activa). Kan blockchain dit compromisloos? Of is er toch een bepaalde prijs die we moeten betalen? We zullen zien dat de combinatie van blockchain om vertrouwen te distribueren aan de ene kant, en confidentialiteit (onder meer van persoonsgegevens) aan de andere kant vandaag een allerminst evidente evenwichtsoefening is.

Beschermen van data

Een beperkte hoeveelheid niet-gevoelige gegevens op een blockchain bewaren kan natuurlijk probleemloos. Op publieke (unpermissioned) blockchain netwerken zoals Bitcoin en Ethereum zul je daar wel een prijs voor betalen, uitgedrukt in de virtuele munt van het platform (bitcoin of ether). Je betaalt immers onder meer per byte. Sowieso moeten we opletten met de hoeveelheid data die we in de blockchain stoppen, aangezien we er niets uit kunnen verwijderen en de blockchain dus snel erg groot dreigt te worden.

Als we gevoelige gegevens op de blockchain bewaren kunnen bovendien meerdere participanten op het netwerk de data zien. We kunnen het natuurlijk encrypteren, maar ook dat houdt risico’s in. Uw vercijferde data is binnen 20 jaar misschien nog steeds gevoelig, maar kan tegen dan wel m.b.v. quantum computers of een andere doorbraak gekraakt worden. Of misschien wordt uw cryptografische sleutel gewoon gestolen (of verliest u die domweg).

Omwille van deze twee redenen, grootte & confidentialiteit, zal er veelal geopteerd worden om enkel de cryptografische hash (een unieke fingerprint) van gegevens op de blockchain te bewaren. Op die manier kunnen we nagaan of een document op de blockchain geregistreerd werd, wanneer, en onder welk pseudoniem (adres), zonder dat de blockchain verdere informatie lekt. Dan is de logische vraag: waar bewaren we de data zelf? We schetsen een aantal mogelijkheden:

• De eindgebruiker van de applicatie of participanten in het blockchain netwerk bewaren deze zelf. De burger is dan, als eindgebruiker, verantwoordelijk voor het bewaren zijn diploma’s, huwelijkscontracten, verkoopovereenkomsten, … die in de blockchain geregistreerd staan. Zorg wel voor een goede backup en beveiliging! En waar zouden velen deze informatie bewaren? In de omgeving van één of andere gecentraliseerde cloud aanbieder… In het geval van diploma’s kan iedere onderwijsinstelling, als participant in het netwerk, instaan voor het bewaren van de diploma’s. Dat is toch al wat gemakkelijker voor de burger, maar je introduceert weer een afhankelijkheid in de vorm van een SPOF (single point of failure). De server van de onderwijsinstelling kan bijvoorbeeld onbeschikbaar zijn, of misschien verdwijnt de onderwijsinstelling gewoon.
• De participanten in een blockchain applicatie maken gebruik van een gedeelde server met beveiligingsmechanismes zoals encryptie en toegangscontrole. Maar was centralisatie niet net wat we wilden vermijden? En komt een dergelijke hybride oplossing niet met een hogere kost? Tweemaal ja. Toch kan een dergelijke oplossing noodzakelijk zijn om in overeenstemming te zijn met regulering. We denken hierbij in de eerste plaats aan, verrassing, de GDPR. Dankzij vercijfering is het overigens niet nodig dat de centrale server zelf toegang heeft tot de gegevens. Het vereiste vertrouwen in de centrale server blijft dus beperkt.
• Een derde oplossing is dat de gegevens nog steeds – al dan niet geëncrypteerd – gedistribueerd bewaard worden door de participanten van de blockchain applicatie, maar buiten de blockchain. Dit is mogelijk met Distributed Hash Tables (DHTs). Deze technologie laat toe om gegevens te bewaren en te delen in een netwerk van participanten, waarbij de data redundant bewaard wordt. Als een participant uitvalt, blijft het systeem dus gewoon werken. In tegenstelling tot data in de blockchain, hoeft de data hier niet tot het einde der dagen bewaard te worden, en bewaart iedereen slechts een deel van de informatie. Dit versoepelt de vereisten naar opslag toe aanzienlijk. En net zoals bij blockchain kan data niet eenzijdig gewijzigd worden door een malafide participant. DHTs worden onder meer gebruikt in het Interplanetary File System (IPFS). Je hebt niet de centralisatie zoals in de vorige piste, maar de prijs is ook een verlies aan controle over de data, wat vanuit GDPR perspectief moeilijk kan liggen. Wanneer gevraagd wordt aan de participanten in het netwerk om bepaalde gegevens te verwijderen kun je niet nagaan of dit overal effectief gebeurd is en er geen kopieën achtergehouden worden. Wanneer de set van participanten relatief klein is en ze elkaar onderling kennen, zoals het geval is in een afgeschermd (permissioned) blockchain netwerk, kunnen contractuele clausules mogelijks wel een uitweg bieden. Ook encryptie kan nuttig zijn, maar dan moet je wel zorgen dat iedereen die toegang nodig heeft tot de data, en enkel zij, de data kunnen ontcijferen.
• Verschillende blockchain technologieën bieden geïntegreerde ondersteuning voor confidentiële off-chain opslag van data door de participanten in het netwerk, waarbij nodes (participanten) enkel deze data lokaal bewaren die voor hen relevant is en die ze gemachtigd zijn te zien. Deze gegevens worden confidentieel uitgewisseld en in een aparte gegevensbank, los van de blockchain bewaard. Enkel de fingerprint komt op de blockchain terecht. In Hyperledger Fabric heeft men daarvoor side databases, in MultiChain gewoon over off-chain data. MultiChain maakt bijvoorbeeld gebruik van data streams. Een participant kan geabonneerd zijn op nul, één of meer data streams op eenzelfde blockchain. De participant ontvangt, bewaart en verspreidt enkel die off-chain data voor streams waarop hij geabonneerd is. Zijn slechts twee participanten geabonneerd op een data stream, dan zal de bijhorende data enkel door hen bewaard worden. Data is hier dus gedupliceerd, maar niet echt gedistribueerd.

Het gebruik van encryptie om data on-chain te bewaren op een publiek (permissionless) blockchain is niet zonder risico, gezien encryptie de enige beschermlaag is. De geëncrypteerde data blijven voor eeuwig op de blockchain, maar mettertijd zal de sterkte van de gebruikte encryptie afnemen, en sleutels kunnen gestolen worden. In traditionele, gecentraliseerde omgevingen en in afgeschermde blockchain netwerken zijn er nog extra beschermlagen zoals toegangscontrole en blijft de data dus onder de controle van een of een beperkt aantal entiteiten (tenzij er een data leak is, uiteraard).

Samengevat zijn er verschillende mogelijkheden om data te beschermen m.b.v. een blockchain. De data zelf kan on-chain of off-chain bewaard worden, kan al dan niet geëncrypteerd zijn, en al dan niet gecentraliseerd bewaard worden. De keuze zal afhangen van de applicatie. En soms zullen er op de een of ander manier concessies moeten gedaan worden. Verder moeten we er ook rekening mee houden dat er mogelijks gevoelige gegevens afgeleid kunnen worden uit de meta-data op de blockchain.

Afdwingen van regels

Blockchain laat toe om collectief regels te valideren. Bij een transactie van cryptogeld is dit beperkt tot “is de zender ook de eigenaar van de activa die hij wil transfereren”, bij smart contracts kunnen die regels complexer zijn. Collectief valideren impliceert ook dat meerdere entiteiten toegang hebben tot dezelfde gegevens in de blockchain, om aldus de validatie te kunnen doen. Voor een smart contract dat belastingen int en automatisch uitbetaalt, betekent dit dus dat meerdere entiteiten toegang nodig hebben tot alle relevante belastinggegevens. Dit is meteen ook een achilleshiel van blockchain. Het uitschakelen van de centrale autoriteit betekent dat we meerdere participanten toegang geven tot potentieel gevoelige gegevens. We moeten hen dus vertrouwen deze gegevens niet te misbruiken. In het geval van een permissioned (afgeschermd) blockchain netwerk, is het aantal entiteiten met toegang tot de gegevens weliswaar beperkt en kunnen er contractuele afspraken gemaakt worden, maar we vertrouwen er nog steeds op dat de gegevens niet misbruikt worden en dat de participant niet gehackt wordt.

Op de blockchain zijn we gelukkig niet gekend onder onze echte naam (of rijksregisternummer), maar onder een pseudoniem (adres). Helaas is dit een nodige maar onvoldoende vorm van bescherming. Bij een relatief eenvoudige toepassing, het transfereren van virtuele munten, zijn er al diverse deanoniemisatieaanvallen gepubliceerd. Naarmate een applicatie complexer wordt, en er meer gegevens verwerkt worden, stijgt ook de kans dat deze gegevens door een aanvaller aan een bedrijf of burger gekoppeld kunnen worden. De GDPR blijft dan ook – terecht – van toepassing op gepseudonimiseerde persoonsgegevens.

Er wordt gelukkig wel onderzoek gedaan om het ongewenst lekken van informatie naar onbevoegden te verminderen. Denk maar aan het in 2016 gelanceerde Zcash, dat dankzij het gebruik van geavanceerde cryptografie erin slaagt om bij transacties van virtuele munten zowel het adres van de zender, het adres van de ontvanger, alsook het getransfereerde bedrag te verbergen, zelfs voor de validatoren. Dit klinkt fantastisch – zeker als je criminele intenties hebt – en het is inderdaad een indrukwekkende prestatie. Maar toch komt dit tegen een prijs. Daar waar een gemiddelde transactie in Bitcoin zo’n 300 bytes groot is en in enkele milliseconden gecreëerd kan worden, wordt dit bij Zcash 2000 bytes en enkele tientallen seconden op een typische desktop PC, volgens een rapport van het R3 consortium. Bovendien is dit enkel een oplossing voor één specifieke toepassing van blockchain, namelijk het transfereren van virtuele munten.

De voorgestelde oplossing kan niet zomaar geëxtrapoleerd worden naar andere toepassingen, laat staan naar een generieke technologie zoals blockchain-based smart contracts. Er werd wel een theoretisch model uitgewerkt voor private smart contracts, dat luistert naar de naam Hawk. Tot op heden is er nog geen implementatie, laat staan benchmarks, beschikbaar. Op conceptueel niveau is er alvast één nadeel dat gedetecteerd kan worden; Private smart contracts worden uitgevoerd door een manager, die toegang heeft tot alles met betrekking tot het smart contract en dus door de betrokkenen vertrouwd moet worden. Permissioned blockchain technologieën zoals Quorum en Hyperledger Fabric laten wel toe dat een contract maar door een beperkt aantal of zelf enkel de betrokkenen gezien en uitgevoerd kan worden, maar dan is de graad van distributie natuurlijk minder. Bovendien blijkt de benadering in de praktijk niet steeds even werkbaar, zoals blijkt uit experimenten door SWIFT. Ook volgens Ripple, een van de toonaangevende spelers, is het onwaarschijnlijk dat banken in de nabije toekomst zullen overschakelen op distributed ledger technologie, waar ook blockchain toe behoort. De redenen liggen bij schaalbaarheid en privacy.

Heel wat pogingen om de confidentialiteit en privacy in blockchain toepassingen te verbeteren zijn dan ook toepassingsspecifiek. Ook op Smals Onderzoek werden we hier reeds in 2016 mee geconfronteerd, bij het bouwen van onze eerste blockchain proof-of-concept. Deze PoC verwerkte m.b.v. een smart contract medische voorschriften. In dit verwerkingsproces zijn verschillende partijen betrokken, waaronder de zeven ziekteverzekeringsfondsen, die moeten aangeven of een patient verzekerd is en al dan niet recht heeft op een verhoogde tegemoetkoming. De ziekteverzekeringsfondsen staan in ons voorstel samen in voor het veilig houden van de blockchain en hebben allen dus toegang tot de volledige blockchain. Maar toch moeten we vermijden dat ze ook maar enige informatie over elkaar te weten kunnen komen via de blockchain, zelfs niet via metadata. Tegelijkertijd wilden we niet dat artsen of apothekers te weten konden komen bij welk ziekteverzekeringsfonds een burger aangesloten is. Zo waren er nog een aantal strenge privacy- en confidentialiteitsvereisten. De uiteindelijke oplossing voldeed aan deze vereisten en was gebaseerd op blockchain, maar met een aanzienlijke schil cryptografie errond, wat de complexiteit, en dus ook de kost, sterk verhoogde. De reden dat dit in onze applicatie mogelijk was, is dat voor elk voorschrift een aparte, geïsoleerde, beperkte, niet-transfereerbare set data in het smart contract bijgehouden werd. Enkel met de juiste cryptografische sleutels kunnen voorschriften immers aan elkaar of een betrokken entiteit gelinkt worden. Die sleutels bevinden zich niet op de blockchain. Wanneer een smart contract beslissingen moet nemen op basis van een rijkere set gegevens, wordt het moeilijker de identiteit van de betrokken burger of onderneming afdoende te beschermen.

Samengevat komt het gebruik van blockchain voor het afdwingen van regels vandaag met een prijs. Ofwel hebben meerdere partijen toegang tot bepaalde, mogelijks gevoelige, gegevens, ofwel gebruik je complexe, vaak op maat gemaakte, oplossingen, die bovendien een significante impact kunnen hebben op zaken zoals efficiëntie en schaalbaarheid. Of dergelijke oplossingen op maat altijd mogelijk zijn, is trouwens niet gezegd. In de tabel hieronder geven we samenvattend een aantal mitigerende maatregelen met hun consequenties.

Mitigerende maatregel	Consequenties
Pseudoniemen	Deanonimisatierisico. Vaak nodige maar onvoldoende maatregel.
Minder data on-chain	Minder regels collectief gevalideerd Meta-data kan nog steeds gevoelige informatie lekken Data moet elders bewaard worden
Minder participanten hebben toegang tot data / smart contracts (vb. d.m.v. channels in Hyperledger Fabric of streams in Multichain)	Lagere graad van distributie van vertrouwen. Hogere operationele complexiteit
Geavanceerde cryptografie	Hogere technologische complexiteit Computationele en opslag overhead. Vaak toepasingsspecifiek

Conclusies

Blockchain laat toe afhankelijkheden van intermediaire partijen te reduceren. Niet langer een vertrouwde partij bewaart data, garandeert eigenschappen over data of voert regels uit, maar het blockchain netwerk. De prijs die je ervoor betaalt is transparantie, in de zin dat meerdere entiteiten toegang tot bepaalde informatie nodig hebben in het validatieproces.

Dat kan lastig zijn wat betreft confidentialiteit als we gegevens willen registreren in het blockchain netwerk, of als we het netwerk collectief regels willen laten afdwingen. Vandaag zijn er bij mijn weten nog geen generieke blockchain oplossingen die deze uitdagingen op een voldoende praktische manier aanpakken. Ik kijk alvast uit naar de komende evoluties, in het bijzonder die rond zero-knowledge proofs.