In dit artikel leg ik je dit probleem uit aan de hand van een use case en bied ik mogelijke oplossingen. Tot slot bespreek ik de rol die privacy regelgeving zoals de GDPR hierbij speelt.

Blockchain met selectief deurbeleid

In mijn voorgaande artikel legde ik je uit wat het verschil is tussen public en permissioned blockchains. Eén van de belangrijkste verschillen is dat een public blockchain voor iedereen ter wereld toegankelijk en inzichtelijk is. Dit terwijl een permissioned blockchain slechts voor een select gezelschap in zijn geheel te bekijken is. Als het je dus enkel te doen is om partijen buiten het netwerk buiten de deur te houden en niet door het raam te laten kijken, dan volstaat het om een permissioned blockchain te gebruiken.

Vaak is het echter zo dat juist ook de partijen binnen het blockchain-netwerk geïnteresseerd zijn in de data die de andere partijen hebben opgeslagen. Denk bijvoorbeeld aan een netwerk met concurrerende bedrijven en hun klanten. De klanten zouden maar al te graag de voorwaarden van de deals zien die andere klanten met hun leverancier hebben gesloten. De leveranciers (en misschien de andere klanten) willen dit juist weer niet met iedereen delen. Zoals je ziet is enkel beperkte toegang tot het blockchain-netwerk lang niet altijd voldoende. Laat ik dit probleem verder toelichten met een voorbeeld.

Een rolstoel aanvragen

Laten we als voorbeeld de volgende use case nemen: een minder mobiele oudere Nederlander genaamd Vincent wil gebruik gaan maken van een rolstoel. Vincent gaat op zoek naar hoe hij deze rolstoel kan aanvragen en of dit door de verzekering of de gemeente vergoed wordt. Vincent leest op de website van de Gemeente Tilburg: "Heeft u een hulpmiddel langer dan zes maanden nodig, dan is een vergoeding via de Wet maatschappelijk ondersteuning (Wmo) soms mogelijk."

"Mooi", denkt Vincent, "ik ga een aanvraag doen!". Achter de schermen gaat de Gemeente aan de slag en beoordeelt zijn aanvraag. Als deze wordt toegekend, dan gaat de Gemeente de rolstoel bestellen bij de Zorgaanbieder. De Zorgaanbieder levert de rolstoel (en de nodige uitleg en service) aan Vincent. Daarnaast stuurt de Zorgaanbieder een declaratie naar de Gemeente en stuurt de gegevens ook door naar het CAK. Het CAK gaat dan weer bepalen of Vincent eventueel een eigen bijdrage moet gaan betalen.

"Wheels of Trust"

Deze use case staat al op de radar van blockchainpilots.nl als een proces waarbij blockchain technologie veel verbetering kan bieden. Ik heb deze use case eens verder onder de loep genomen omdat de implementatie ervan op blockchain-technologie vanuit privacy oogpunt zeer interessant is. Stel je even voor dat we de opdracht krijgen om deze use case op blockchain-technologie te gaan realiseren. Als werktitel voor de app die we gaan ontwikkelen kiezen we "Wheels of Trust" (WoT).

Wat zijn een aantal dingen die meteen opvallen?

  • Er is veel communicatie tussen de vier partijen.
  • Vaak hebben dezelfde partijen, dezelfde gegevens nodig.
  • De informatie die gedeeld wordt is persoonlijk en privacy-gevoelig.

Nu is het zo dat we WoT (Wheels of Trust) prima zouden kunnen gaan bouwen op basis van blockchain-technologie. We zouden een smart contract kunnen schrijven waarmee we alle processtappen automatiseren en alle partijen op ieder moment inzicht hebben in dezelfde data. Het probleem is echter dat als we dit klakkeloos zo zouden doen, iedere partij op het netwerk zou weten wat Vincent per jaar verdient en dat hij een rolstoel nodig heeft. In het geval van een permissioned blockchain zou niet de hele wereld, maar misschien wel andere zorgbehoevenden of andere Gemeenten inzicht hebben in data die ze niet zouden moeten zien.

Wat kunnen we hier aan doen?

In principe hebben we twee manieren waarop we met de huidige staat van techniek toch de kracht van blockchain technologie kunnen gebruiken. We gebruiken daarbij niet de volledige kracht die blockchain technologie ons biedt, maar we moeten een compromis sluiten om toch onze privacygevoelige gegevens te kunnen beschermen. De twee alternatieven die we hebben zijn:

  • Encryptie | We slaan alle gegevens versleuteld op een blockchain op en geven de sleutel enkel aan diegenen die de data mogen zien.
  • Proof-of-Existence | We slaan enkel een cryptografische vingerafdruk (hash-waarde) van de data op een blockchain op. Vervolgens gebruiken we deze vingerafdruk om de data te verifiëren, maar delen de feitelijke data via een private verbinding.

Encryptie: Gegevens versleuteld opslaan

Met deze variant slaan we dus wel de volledige data op een blockchain op, maar versleutelen we de data zodat niet iedereen deze kan ontcijferen. Hiermee blijft de privacy dus gewaarborgd. Als we dit proces nader uitwerken, dan zou dit er als volgt kunnen uitzien:

  1. Vincent doet een aanvraag voor een rolstoel via de WoT-app. Deze aanvraag wordt versleuteld met de public key van de ontvangende partij, de gemeente.
  2. De gemeente opent de WoT-app en ziet dat er een nieuwe aanvraag is binnengekomen. De WoT-app ontsleutelt deze automatisch met de private key van de gemeente.
  3. De gemeente verwerkt de aanvraag en plaatst via de WoT-app een digitale bestelling (die op de blockchain wordt opgeslagen). Deze bestelling wordt versleuteld met de public key van de zorgaanbieder.
  4. De zorgaanbieder opent de WoT-app en de app ontsleutelt de digitale bestelling met de private key van de zorgaanbieder.

Proof-of-Existence: Cryptografische vingerafdruk op blockchain

In de Proof-of-Existence variant wordt de onderliggende blockchain technologie alleen gebruikt om te verifiëren dat de data juist is. De feitelijke data wordt niet op de blockchain opgeslagen en moet via andere wegen bij de ontvangende partij aankomen. De WoT-app moet deze gegevens dus via een ander kanaal (dus niet via de blockchain) naar de ontvangende partij sturen. Dit werkt dan op deze manier:

  1. Vincent doet een aanvraag voor een rolstoel. Deze aanvraag wordt opgeslagen in de private opslag van de WoT-app. De hashwaarde van deze aanvraag (een cryptografische vingerafdruk) wordt op de onderliggende blockchain opgeslagen.
  2. De WoT-app stuurt de aanvraag vanuit de private opslag van Vincent naar de private opslag van de WoT-app van de gemeente. De WoT-app verifieert via de bijbehorende hashwaarde op de blockchain dat het ontvangen document de exacte aanvraag is die bij stap 1) door Vincent is ingediend.
  3. De gemeente verwerkt de aanvraag en plaatst via de WoT-app een digitale bestelling. De hashwaarde van deze bestelling wordt op de blockchain opgeslagen. De WoT-app stuurt deze digitale bestelling weer naar de private opslag van de zorgaanbieder.
  4. De zorgaanbieder opent de WoT-app en die verifieert dat de ontvangen bestelling de enige, echte bestelling is die de gemeente bij stap 3) heeft ingevuld.

Wat zijn de voordelen en nadelen van beide alternatieven?

Het voordeel van encryptie is dat de data niet apart hoeft te worden opgeslagen of verstuurd. De ontvangende partij kan de data meteen ontsleutelen en openen.

We zien echter ook drie duidelijke nadelen. De techniek staat niet stil en de rekenkracht neemt toe, denk daarbij ook aan kwantum-computers. We kunnen er dus niet zeker van zijn dat de data altijd goed beveiligd zal blijven.

Daarnaast moeten de public en private key pairs periodiek ververst worden. Dit zorgt ervoor dat je aan key management moet gaan doen en dat je de pairs ook moet communiceren. Dit is extra werk en ook een extra aanvalsvlak.

Tot slot mag je volgens de GDPR-wetgeving privacy-gevoelige data niet voor lange tijd opslaan, ook niet versleuteld. Maar wat eenmaal op de blockchain staat, dat blijft op de blockchain.

Het voordeel van Proof-of-Existence is duidelijk. De data blijft helemaal buiten beeld van onbevoegde partijen en kan dus op geen enkele manier benaderd worden, ook niet met toekomstige technologieën. Bovendien wordt met dit concept helemaal voldaan aan de GDPR-wetgeving.

Het nadeel is echter dat er private communicatie nodig is tussen verschillende partijen en per partij ook private opslag. Voor deze opslag zijn er ook weer backups nodig.

De meeste van de bovenstaande voor- en nadelen spreken redelijk voor zich. De uitspraken over GDPR regelgeving licht ik nog wat verder toe.

GDPR

Vanaf 25 mei 2018 moeten alle Europese bedrijven voldoen aan de zogeheten General Data Protection Regulation. Dit is een verzameling regels die de EU heeft opgesteld met als doel het beschermen van de privacy van natuurlijke personen. Een aantal van deze regels zijn lastig te rijmen met het principe en de toepassing van blockchain. Zo gelden er voor persoonlijke identificeerbare gegevens de volgende regels:

  • Bewaarbeperking: de persoonsgegevens mogen niet langer bewaard worden dan nodig voor het beoogde doel.
  • Gegevensbeperking: enkel de gegevens die voor het beoogde doel noodzakelijk zijn, mogen worden verzameld.
  • Recht om vergeten te worden: Indien iemand hierom verzoekt, dan moet een bedrijf zijn/haar persoonlijke gegevens kunnen verwijderen.

De blockchain als transactielog

Op een blockchain sla je in principe alle gegevens, van iedereen, op alle nodes in het netwerk op. Alle gegevens blijven beschikbaar in de blockchain zelf. Je kan met blockchain technologie (zoals Ethereum) wel de waarden van een variabele wijzigen, maar het transactielog blijft altijd bewaard.

Hier een voorbeeld ter verduidelijking:

  • Gisteren voerde ik in: Patiënt = "Vincent"
  • Vandaag wijzig dit: Patiënt = ""
  • Vraag ik de waarde van Patiënt op, dan krijg ik een lege waarde, maar:
  • Het transactielog (de bockchain) bevat: Patiënt = "Vincent", Patiënt = ""

Het feit dat alle gegevens in het transactielog (de feitelijke chain van blocks) opgeslagen zal blijven, zorgt er dus voor dat we niet kunnen voldoen aan een aantal van de regels die de GDPR ons oplegt voor het omgaan met persoonsgegevens.

Is encryptie de oplossing?

Maar wat dan als we de bovengenoemde encryptie-oplossing toepassen? Helaas, ook al sla je persoonsgegevens versleuteld op een blockchain op, dan nog zijn het voor de wet persoonsgegevens en moeten ze als zodanig behandeld worden. Dus ook in dit geval gelden bewaarbeperking, gegevensbeperking en het recht om vergeten te worden.

Is Proof-of-Existence de oplossing?

Het enkel opslaan van cryptografische vingerafdrukken ter verificatie van de gegevens kan een goede oplossing zijn om te voldoen aan de GDPR. Heel erg strikt genomen vindt het Europese Hof nog steeds dat een hashwaarde een afgeleide van, en dus ook een persoonsgegeven is (dit is het zogeheten objectieve standpunt). Het relatieve standpunt lijkt erop te wijzen dat het gebruiken van een hash-waarde wel wordt toegestaan. Het Europese Hof heeft helaas nog geen officieel standpunt ingenomen, vandaar de voorzichtige bewoordingen in bovenstaande zinnen. Als we echter met een technische bril op kijken naar de Proof-of-Existence-oplossing, dan is het erg duidelijk dat we hiermee volop kunnen voldoen aan de eisen van de GDPR. Technisch gezien kunnen we op deze manier iedere link tussen de oorspronkelijke data en de afgeleide cryptografische vingerafdruk verwijderen.

Voor de technici onder ons: we gebruiken salted hashes, waarbij de partij die eigenaar is van de data het salt bewaart. Wanneer we data moeten verwijderen, verwijderen we ook het salt. Op deze manier kan niemand de hash ooit nog linken aan de oorspronkelijke data.

Zijn er nog andere oplossingen te bedenken?

Jazeker, bij permissioned blockchains zijn er wel een aantal strategieën te bedenken die dit probleem ook kunnen ondervangen. Eén daarvan ziet er als volgt uit: Je zou, als je met alle nodes in het netwerk instemt om bepaalde gegevens uit de blockchain te verwijderen, een mechanisme in werking kunnen stellen om dit uit te voeren. Technisch gezien zou je dan niet de data verwijderen, maar met de data die je juist niet wil verwijderen een nieuwe blockchain starten. Je zou dan gebruik maken van een hard fork-mechanisme wat je onder bepaalde voorwaarden, bijvoorbeeld door het houden van een stemming onder de nodes, in werking kan laten treden.

Dit mechanisme zou je zo kunnen programmeren dat iedere organisatie in het netwerk onder erg strikte voorwaarden, kleine gedeeltes van zijn eigen ingebrachte data mag verwijderen. We moeten ons echter wel sterk afvragen of zo'n soort mechanisme niet veel afdoet aan de kracht van een solide audit trail die een blockchain ons kan bieden. Op zijn minst moet er in zo'n mechanisme sterke beveiligingsmaatregelen worden ingebed om het hebben van een veilig en volledige audit trail te bewaken.

André van der Heijden is blockchain specialist bij Achmea. Achmea investeert veel tijd in innovaties zoals blockchain en is altijd op zoek naar techneuten die de toekomst een stap voor zijn.