Smals Onderzoek heeft begin dit jaar in detail een blockchain toepassing uitgewerkt. Er werd zowel een uitgebreide analyse gemaakt, als een werkende proof of concept. Deze blogpost legt op hoog niveau de problematiek en aanpak uit.

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! 🙂