De business case

Disclaimer: Er bestaan verschillende eBoxen. Met BeSure willen een zo generiek mogelijke dienst aanbieden. We focussen dan ook niet op een specifieke bestaande eBox.

Binnen de overheid is er een eBox platform dat gebruikt wordt voor het uitwisselen van documenten tussen eindgebruikers. Er zijn verschillende organisaties die elk een verschillend, niet-overlappend deel van de eindgebruikers vertegenwoordigen (zie figuur 1). Elke eindgebruiker wordt dus door exact één organisatie vertegenwoordigd. Wanneer Alice een bericht verstuurt naar Bob, is de flow als volgt:

1. Alice stuurt het bericht via haar organisatie naar de eBox.
2. Bob download het bericht via zijn organisatie.

Alice en Bob maken daarbij gebruik van een web client of fat client aangeboden door de hen vertegenwoordigende organisatie. De eBox moet je dus zien als een gecentraliseerd uitwisselplatform voor documenten, waarop verschillende organisaties aangesloten zijn.

Nu hadden we graag een bewijs dat het document op een bepaald moment door Alice verstuurd werd, en dat het op een bepaald moment door Bob ontvangen werd. Die bewijzen moeten 40 à 50 jaar lang bewaard worden. We kunnen er natuurlijk op vertrouwen dat de eBox dit correct zal doen, maar eigenlijk vertrouwen de eindgebruikers en organisaties de eBox toch onvoldoende daarvoor. De eindgebruikers vertrouwen wel hun organisatie en willen zelf ver weg blijven van complexe informatica. Een blockchain benadering, waarbij de organisaties deel uitmaken van het blockchain netwerk (de blauwe cirkel in figuur 1) lijkt dan ook een logische benadering.

Basisidee

In een ideale blockchain-wereld zijn het de eindgebruikers zelf die direct participeren in het blockchain netwerk. Dat vereist echter dat ze blockchain software installeren, draaien en updates installeren wanneer nodig. Het vereist dat ze een private sleutel genereren en afdoende beschermen. Het vereist dat er een systeem is om te beheren wie wel en wie geen toegang heeft tot het blockchain netwerk, wat niet evident is met een grote variabele groep eindgebruikers. Eindgebruikers worden liever niet lastig gevallen met al het bovenstaande. Vandaar dat we een benadering voorstellen waarin enkel de organisaties en de eBox participeren. Dat is een relatief kleine, stabiele set entiteiten die over de mogelijkheid beschikken om te participeren in het blockchain netwerk en die onderling (juridisch bindende) afspraken kunnen maken. In onze benadering hoeft de eindgebruiker dus niet eens te weten dat er achterliggend een blockchain gebruikt wordt. De prijs is dat het vertrouwen gedecentraliseerd is onder een paar entiteiten, en niet gedistribueerd onder de eindgebruikers.

Per document worden twee bewijzen gecreëerd: eentje dat bewijst dat een specifiek document afkomstig van Alice en bestemd voor Bob op een bepaald moment verstuurd werd naar de eBox, en eentje dat bewijst dat het document ook op een bepaald moment ontvangen is. Zo’n bewijs is eigenlijk een akkoord tussen de betrokken organisatie en de eBox. Het is een blockchain-transactie die door de twee partijen ondertekend wordt. De creatie van dit akkoord is een proces tussen slechts de twee betrokken partijen.

Daarna wordt dit akkoord aan het blockchain netwerk gegeven. Slechts indien de transactie door de eBox en een van de gekende organisaties ondertekend is, wordt het door het netwerk collectief aanvaard, en komt het in de blockchain terecht, waar het onverwijderbaar is. Dit is een collectief proces tussen de betrokken organisaties. De eBox speelt in deze stap niet mee.

Figuur 2 geeft de inhoud weer van zo’n akkoord. Eerst wordt de cryptografische hash van enkel het document berekend. De resulterende documenthash wordt nog eens gehasht, maar nu samen met de identifier van zowel de zender als de bestemmeling. Die finale hash komt in het bewijs terecht. Ten tweede bevat een bewijs het moment waarop het akkoord gecreëerd is, en ten derde de actie; wordt het document afgeleverd aan de eBox (‘SEND’), of wordt het document er opgehaald (‘RECEIVE’). Deze drie zaken worden ondertekend door zowel de eBox als de betrokken organisatie. Beide partijen ondertekenen pas als ze akkoord zijn met deze informatie. Het blockchain netwerk verifieert vervolgens dat het bewijs effectief ondertekend is door de eBox en een gekende organisatie, en is op zich niet geïnteresseerd in de inhoud van het bewijs/akkoord. Bemerk dat de blockchain dus geen persoonsgegevens bevat, wat een zorg minder is. Dit is niet onbelangrijk gegeven het spanningsveld tussen de GDPR en blockchain.

Bewijskracht

Wat is de bewijskracht van een dergelijk bewijs? Er zijn drie niveaus, afhankelijk van de extra informatie die we hebben.

1. Zonder extra informatie bewijst een bewijs enkel dat een ongekend document op een gekend moment verstuurd of ontvangen werd door een ongekende eindgebruiker die aangesloten is bij een geïdentificeerde organisatie. Dit is wat de participanten in het netwerk sowieso te weten komen en zegt iets over de activiteit van de verschillende organisaties
2. Wanneer we enkel de documenthash en de identifiers van de afzender en bestemmeling hebben, kunnen we bewijzen dat een ongekend document verstuurd door een geïdentificeerde afzender naar een geïdentificeerde bestemmeling op een bepaald moment verstuurd of ontvangen is. Dit komt functioneel in de buurt van zowel de klassieke papieren aangetekende zending als de meta-data die telefonieoperatoren juridisch verplicht zijn bij te houden.
3. Wanneer we naast de identifiers van de afzender en de bestemmeling ook nog het originele document hebben, kunnen we bewijzen dat exact dat document, verstuurd door een geïdentificeerde afzender en bestemd voor een geïdentificeerde afzender, op een gekend moment verstuurd of ontvangen is.

Een dergelijke granulariteit kan nuttig zijn. Ook zonder het document prijs te geven kan je bepaalde activiteit bewijzen.

Veiligheid

We willen uiteraard vermijden dat de eBox of een organisatie kan valsspelen. Het wijzigen van het document, zender, ontvanger, tijdstip of type actie is dankzij de twee digitale handtekeningen onmogelijk. Maar er zijn nog aspecten om rekening mee te houden.

• We willen vermijden dat de eBox valse berichten kan injecteren in het systeem, dus dat de eBox in naam van een eindgebruiker een document kan versturen naar een andere eindgebruiker.
• We willen niet dat een document verzonden of ontvangen wordt, zonder dat een bewijs daarvan op de blockchain terecht komt.
• We willen niet dat op de blockchain een bewijs geregistreerd wordt dat een document verzonden of ontvangen is, terwijl dit in werkelijkheid niet zo is.

Dit is niet triviaal in een context waarbij de partijen elkaar niet vertrouwen. Toch hebben we hiervoor een sterke en realistische oplossing gevonden.

Zoals ik reeds in een vorige blogpost schreef, is er een spanningsveld tussen enerzijds blockchain, die steunt op transparantie, en anderzijds confidentialiteit. Hoewel we in de voorgestelde oplossing enkel hashes bewaren bevat ze toch nog een ernstige tekortkoming wat betreft confidentialiteitsbescherming. Dezelfde hash wordt immers herbruikt in alle bewijzen met betrekking tot eenzelfde document. Daardoor kunnen deze bewijzen triviaal aan elkaar gelinkt worden, ook door organisaties die niet in de flow betrokken zijn. Ze kunnen zien wanneer een ongekend document via een gekende organisatie verstuurd werd, en wanneer dat document via een andere gekende organisatie ontvangen werd. En als ze dit doen voor elk document, kunnen ze daar potentieel nuttige statistieken uit extraheren. Ook dit hebben we kunnen oplossen, waarbij we zelfs rekening hielden met erg subtiele vormen van datalekken.

Een gedetailleerde uitleg van alle veiligheidsaspecten zou deze blogpost helaas wat te lang maken, maar het staat u steeds vrij om mij te contacteren. We vatten toch even een aantal eigenschappen van BeSure samen:

• Het systeem kan omgaan met gecompromitteerde sleutels. Voor elke actie (rechtenbeheer, creatie bewijs, publicatie bewijs en sleutelbeheer) zijn immers meerdere sleutels vereist. Dit resulteert in een conceptueel hoger niveau van veiligheid dan gecentraliseerde systemen.
• De blockchain lekt geen confidentiële gegevens, zelfs niet op meer subtiele manieren. Participanten komen via de blockchain geen gevoelige informatie over elkaar te weten. En wanneer een hacker toegang krijgt tot de blockchain of als de blockchain op straat belandt, heeft dit geen implicaties voor de privacy van de burger.
• Het sleutelbeheer gebeurt via de blockchain. De participanten zijn dus niet afhankelijk van een PKI.
• Het crashen van een BeSure component resulteert niet in (tijdelijke) kwetsbaarheden.
• Wanneer de bestemmeling vb. na 25% de download onderbreekt komt er geen bewijs op de blockchain terecht; er is immers geen sprake van een succesvolle download. BeSure verhindert dat de bestemmeling toch al enige informatie uit het gedownloade deel kan extraheren.
• BeSure gebruikt MultiChain als onderliggende blockchain technologie. Dit is een fork van de Bitcoin code, die in de praktijk al uitgebreid getest is. Dit resulteert in een product met weinig bugs, dat dus als stabiel en veilig beschouwd kan worden.
• Externe validatoren kunnen toegevoegd worden aan het netwerk. Zij krijgen toegang tot de blockchain en staan mee in voor het verwerken van de bewijzen in de blockchain. Dit verhoogt verder het vertrouwen dat alles correct verloopt.

Samengevat bekomen we dus een systeem dat een erg hoog niveau van veiligheid kan garanderen.

Conclusies

Een vraag waar we dikwijls mee geconfronteerd worden is: “Kunnen we dit niet met traditionele technologie?” Dit kan, maar dan zullen we afhankelijk zijn van autoriteiten. Om digitale handtekeningen lange tijd geldig te houden, hebben we bijvoorbeeld nood aan een timestamping service telkens wanneer een bewijs gecreëerd wordt. In een traditionele oplossing moeten we ook een manier vinden om te vermijden dat de bewijzen in de loop der jaren verloren gaan of doelbewust verwijderd worden. Gaan we ook daarvoor vertrouwen op een centrale dienst? Er zijn dus goede redenen om een blockchain-benadering te overwegen.

Heel wat blockchain proofs of concept vandaag zijn helaas om weg te gooien. Sommige blockchain bedrijven negeren de GDPR, bouwen blockchain proofs of concept die niet bedoeld zijn om gedistribueerd te draaien (!) en negeren confidentialiteitsvereisten. Voor BeSure hebben we, naast een werkende poc, een uitgebreide analyse gemaakt. Bovendien maken we gebruik van een blockchain technologie die reeds uitgebreid getest is in de praktijk. Door bovenstaande combinatie verhogen we aanzienlijk de kans op uiteindelijke inproductiestelling.

De blockchain filosofie indachtig kunnen we nog een stap verder gaan en het bestaan van de eBox zelf, als centraal uitwisselplatform, in vraag stellen. We moeten immers erop vertrouwen dat de eBox beschikbaar is, de documenten confidentieel behandelt en niet gehackt wordt. Hoewel dit in pakweg de eerstvolgende tien jaar wellicht onrealiseerbaar zal blijven, blijft het een interessante denkpiste die ik misschien in een toekomstige blogpost uitwerk.

Stay tuned! 

Werking

Het Bitcoin systeem laat toe om waarde (uitgedrukt in bitcoins) te transfereren van één partij naar een andere. Al deze transacties worden geregistreerd in de blockchain. Dit is een sequentie van blokken, waarbij elk blok een aantal transacties bevat, zoals geïllustreerd in figuur 1. Vooraleer we hier dieper op ingaan, leggen we eerst de hashfunctie uit, wat noodzakelijk is om de werking van de blockchain te kunnen begrijpen.

Gemiddeld wordt elke 10 minuten een nieuw blok aan het einde van de blockchain toegevoegd. Dit gebeurt door het zogenaamde minen (ontginnen). Verschillende deelnemers in het bitcoin netwerk zijn miners (ontginners) en gaan met elkaar in competitie om een rekenintensieve cryptografische puzzel op te lossen, wat nodig is om een geldig blok te creëren. De uitdaging is daarbij om een nonce-waarde te vinden in de block header (zie figuur 1) zodat de hashwaarde van het block inclusief de nonce, kleiner is dan de maximum door Bitcoin toegelaten waarde. Hoe kleiner deze waarde, hoe moeilijker de puzzel.

Wanneer één van de deelnemers zo een nonce-waarde gevonden heeft en daarmee de cryptografische puzzel opgelost heeft, stuurt hij het correct gevormde blok naar zijn buren, die het op hun beurt verder over het netwerk verspreiden. Voor de andere deelnemers is het nu zeer eenvoudig om na te gaan of het hashen van het blok inderdaad resulteert in een hashwaarde die voldoende klein is. Het berekenen van een hashwaarde kan immers bijzonder efficiënt. Het is een soort bewijs voor het geleverde werk en wordt daarom proof-of-work genoemd. Ter illustratie werd voor blok 398837 de nonce-waarde 425462554 gevonden wat resulteerde in de hashwaarde 000000000000000002ed91269a2b5f53cc0e68289f8327f272f6f40ac7c19a96 die voldoende klein is.

De miner krijgt een compensatie voor het geleverde werk: nieuw gecreëerde bitcoins voor het vinden van de puzzel, wat een vast bedrag is, plus de transaction fees, wat variabel is. Het aantal nieuw gecreëerde Bitcoins bedraagt momenteel 25 en wordt geregistreerd in de eerste transactie in het block, de generation transaction (zie figuur 1), waarin 25 nieuwe bitcoins gecreëerd worden. Deze beloning halveert elke 4 jaar, waardoor dit vanaf midden 2016 zal verminderen tot 12,5 bitcoins. In elke transactie is er een bedrag dat uitgegeven wordt en een bedrag dat ontvangen wordt. Het verschil tussen de twee is de transaction fee voor de miner. We zien in figuur 1 dat er honderden transacties zijn per block. Alle transaction fees zijn voor de winnende miner. Momenteel zijn de transaction fees vrij laag (meestal het minimum) en bestaat de voornaamste inkomstenbron van miners uit de nieuwe bitcoins in de generation transaction. De verwachting is dat mettertijd de inkomstenbron meer zal verschuiven naar transaction fees.

Gemiddeld wordt elke 10 minuten een nieuw blok gecreëerd. De totale rekenkracht van alle miners samen verandert natuurlijk voortdurend. Meer rekenkracht betekent dat de puzzels sneller opgelost zullen worden. Daarom wordt om de twee weken de moeilijkheid van de cryptografische puzzel aangepast, waarbij gekeken wordt naar het gemiddelde van de voorbije twee weken.

Terwijl alle miners de cryptografische puzzel proberen op te lossen, verzamelen ze alle nieuwe transacties. Wanneer een miner de cryptografische puzzel oplost, eindigt de competitie voor dit blok, maar start tegelijkertijd een nieuwe competitie om de ondertussen verzamelde transacties in een nieuw blok te steken. Dit principe is het kloppend hart van Bitcoin.

Is dit wel veilig?

Elke deelnemer (node) in het Bitcoin netwerk heeft een kopie van ofwel de volledige blockchain, ofwel van op zijn minst alle block headers. Dit alleen maakt het bijzonder lastig om een transactie die reeds in de blockchain zit te wijzigen of te verwijderen of om een nieuwe transactie toe te voegen. Alle deelnemers moeten immers akkoord gaan met deze wijziging in de write-only blockchain.

Maar er is meer. Stel dat ik een wijziging aanbreng in een transactie die pakweg een dik uur oud is, dan verandert ook de hashwaarde van het blok waartoe de transactie behoort. De waarde in previous_block_hash in het daaropvolgende blok moet dus ook aangepast worden. Maar dan zal ook in dit blok een andere nonce waarde gevonden moeten worden om de cryptografische puzzel op te lossen. Stel dat we daarin slagen, dan moet ook het daaropvolgende blok aangepast worden, want ook daar verandert de waarde in het veld previous_block_hash. We moeten dus alle blokken aanpassen tot aan het einde van de blockchain, waarbij telkens voor elk blok de cryptografische puzzel opnieuw opgelost moet worden. In ons voorbeeld van een transactie die een dik uur oud is, zou het dus gaan om een zestal cryptografische puzzels. Gezien de beperkte rekenkracht van de de valsspeler is dit in de praktijk onmogelijk.
In het algemeen wordt aangenomen dat een transactie definitief goedgekeurd is wanneer het blok beschermd is door zes nieuwere blokken.

Een voordeel van een blockhain is het wegvallen van de centrale database die extreem goed beveiligd moest worden. Gezien iedereen een kopie heeft van dezelfde blockchain zijn er ook geen problemen meer wat betreft het consistent houden van verschillende gegevensbanken. Denk hierbij bijvoorbeeld aan transacties tussen een persoon met een rekening bij bank A en een persoon met een rekening bij bank B. Zowel bank A als bank B bewaren deze transactie in hun database.

Dit brengt ons direct bij een ander voordeel. We hoeven geen centrale autoriteiten meer te vertrouwen. Sterker nog, we kunnen het perfect zonder hen.

We vermelden ook dat elke transactie, met uitzondering van generation transactions, verwijzingen bevatten naar oudere transacties in andere blokken. Indien Bob 5 Bitcoins ontvangen heeft van Alice en indien Bob 25 Bitcoin in een generation block heeft, dan kan Bob daarmee 26 Bitcoins aan Charlie geven. Daarbij zal de nieuwe transactie verwijzingen bevatten naar de twee oudere transacties waaruit bleek dat Bob in totaal 30 Bitcoins bezat. De nieuwe transactie geeft nu aan dat Bob 4 Bitcoins heeft en Charlie 26. Doordat elke transactie bewaard wordt, is het niet mogelijk een Bitcoin twee maal uit te geven.

Beperkingen

Toch heeft de Bitcoin blockhain zijn beperkingen. Zo blijkt momenteel dat de limiet voor Bitcoin ongeveer 3 transacties per seconde is. Wanneer deze limiet overschreden wordt, wordt het netwerk instabiel en onbetrouwbaar en worden de transaction fees onredelijk hoog. Transacties met een hoge transaction fee krijgen immers voorrang op de andere transacties. Dit zou opgevangen kunnen worden door de maximumgrootte van een blok te vergroten. Die is momenteel 1 MB. Maar omwille van economische belangen besliste het core team van Bitcoin om dit niet te doen. De meeste mining gebeurt immers in grote Chinese mining farms en grotere blokken zouden moeilijker door de chinese firewall raken, gezien die maar een beperkte bandbreedte heeft. Bovendien dreigde een split in bitcoin, waarbij een deel zou overschakelen op grotere blokken (Bitcoin XT met blokken van 8 MB) en een ander deel niet. Dit zou uiteraard nefast zijn voor het beleggersvertrouwen.

Een andere beperking is dat het core Bitcoin team maar uit een tiental mensen bestaat. Hooguit tien (onverkozen) personen bepalen dus de toekomst van Bitcoin. Dit is een enorm sterke vorm van centralisatie. Was dit niet wat Bitcoin net wou tegengaan? Maar er is meer… Het minen van Bitcoins wordt gedomineerd door een klein aantal spelers met enorm veel rekenkracht. Ze bezitten hele datacenters met als enig doel het minen van Bitcoins. Als particulier kan je niet op tegen dergelijke schaalvoordelen.

De blockchain groeit elke 10 minuten met 1 blok (momenteel 1 MB). Wordt dit op termijn niet erg groot? Momenteel is de volledige blockchain zo’n 56 GB groot. In plaats van de volledige blockhain kan een deelnemer (node) enkel de block headers bijhouden, wat neerkomt op 80 KB per block, ofwel een dikke 30 MB in totaal. Bovendien is het (m.b.v. Merkle trees) mogelijk om een transactie in een blok te valideren zonder alle andere transacties in het blok te kennen. Enkele korte 256 bits hashwaarden volstaan.

Ten slotte vermelden we dat het minen van Bitcoins enorme hoeveelheden energie consumeert, wat uiteraard een impact heeft op het milieu.

Conclusies

Het belang van Bitcoin als eerste gedistribueerde blockchain is niet te onderschatten. Toch is voor velen Bitcoin op zich niet de belangrijkste uitvinding, maar wel de onderliggende blockchain technologie.

Bitcoin is een uit zijn voegen gebarsten experiment dat zijn beperkingen kent. Zelfs indien Bitcoin mislukt mogen we daaruit niet de conclusie trekken dat ook blockchain gefaald heeft. Bitcoin is slechts een toepassing van blockchains.

In een volgend artikel willen we dan ook dieper ingaan op de verschillende types blockhain en hun toepassingen, zowel in het algemeen als meer specifiek binnen een overheidscontext.

Tot slot is er nog de website https://www.blockchain.com/explorer met de laatste transacties, blokken en statistieken in de Bitcoin blockchain.