Rekening herstel via machtiging en de geïntegreerde bankkluis voor smart-tokens

Maayan
Bancor (Nederlands)
4 min readAug 20, 2017

Met dank aan kyriacos voor een geweldig artikel over het Bancor protocol op Steemit, waar we deze prachtige afbeelding hebben gevonden.

Het is nu wel duidelijk dat blockchain technologie een grote belofte is voor de toekomst, en ook dat we er nog niet helemaal zijn, vooral als het gaat om gebruikersacceptatie. We gaan ervan uit dat een van de belangrijkste redenen van deze terughoudendheid te maken heeft met veiligheidskwesties.

Bij bestaande cloud gebaseerde internet services is het veiligheidsmodel gebaseerd op door de gebruiker gegenereerde wachtwoorden die hersteld kunnen worden door middel van een speciale URL. Deze URL kan worden ontvangen via diverse kanalen, bijvoorbeeld per e-mail of mobiele telefoon. Dit model is twee decennia lang het de-facto standaardmodel geweest en waarschijnlijk hebben velen van jullie het meerdere malen gebruikt.

Als we kijken naar de blockchain dan zijn er in het algemeen drie veiligheidsmodellen in gebruik, elk hiervan met zijn eigen uitdagingen.

Bij het eerste veiligheidsmodel bewaart de online service de private sleutel. Dit model is het populairst, omdat het de eenvoud van het bestaande cloud model weerspiegelt. Het bezwaar is natuurlijk dat de gebruiker geen directe controle heeft over zijn digitale goederen. Daarnaast moet de gebruiker erop vertrouwen dat de service provider de veiligheid van de digitale goederen waarborgt en zorgt voor het uitvoeren van orders. Dit model moedigt ook het uitvoeren van aanvallen door hackers aan omdat een centrale service controle heeft over alle goederen.

Een andere benadering is het volgende veiligheidsmodel: De gebruiker bewaart en versleutelt zijn eigen private sleutel. Dit model is geschikt voor ervaren gebruikers die weten hoe zij hun bestanden veilig moeten houden en hoe zij om moeten gaan met versleuteling. Het bezwaar hier is dat er geen “wachtwoord vergeten” optie is, omdat er geen centrale server is die de gebruiker kan helpen het wachtwoord te herinneren of opnieuw in te stellen.

Het derde model is een hybride vorm waarbij de private sleutels versleuteld worden met behulp van een wachtwoord dat opgeslagen is op een centrale server. De gebruiker hoeft zelf niet bezig te zijn met de beveiliging van bestanden, echter het kiezen van een veilig wachtwoord is van groot belang omdat de server-hosted versleutelingsbestanden in de handen van een hacker kunnen vallen die kan proberen de bestanden te decoderen. Een veilig wachtwoord is gewoonlijk moeilijker te onthouden. Echter, het is vn groot belang dat de gebruiker het wachtwoord niet vergeet anders heeft hij geen toegang meer tot zijn digitale bestanden.

Als we kijken naar adoptie door de massa, lijkt geen van de bovengenoemde opties optimaal of helemaal toereikend. Echter, hierin kan verandering komen doordat voor smart contracts een betere oplossing geboden kan worden via een nieuwe functionaliteit die “rekening herstel via machtiging” wordt genoemd.

Het idee in zijn simpelste vorm is dat iedere gebruiker een of meer beheerders kan kiezen om zijn rekening te beschermen. Een beheerder kan iedere gebruiker zijn, zoals een admin of een smart token van een community, een familielid, een vriend, een collega, etc. De gebruiker geeft de beheerder geen volledige toegang tot de rekening, maar de beheerder krijgt speciale toestemming om rekening herstel in werking te stellen wanneer dit nodig is.

Als een gebruiker zijn wachtwoord vergeet kan de account hersteld worden door het aanmaken van een nieuwe portemonnee (met een nieuwe private sleutel) en kan een van de beheerders gevraagd worden het herstel van de initiële rekening in gang te zetten en de fondsen over te boeken naar de nieuwe portemonnee. Na verificatie door de beheerder dat de aanvrager inderdaad de rekeninghouder is kan deze het protocol voor herstel aanroepen.

Het aanroepen van het rekening herstel protocol betekent dat na een vooraf gedefinieerde periode met een bepaalde tijdsduur (welke wordt geconfigureerd door de gebruiker tijdens de setup, bijvoorbeeld 3 dagen), de goederen die op de rekening staan worden overgeboekt naar de nieuwe portemonnee.

De reden voor het instellen van een tijdsperiode is dat als de beheerder probeert zijn macht te misbruiken, of gehackt is, de eigenaar van de rekening tijd heeft om het protocol stop te zetten. De fondsen zullen niet worden overgeboekt en de gebruiker kan veranderingen aanbrengen in de lijst van beheerders van de rekening. Het hebben van meerdere beheerders biedt meer veiligheid en verkleint de kans dat meerdere rekeningen gehackt worden.

Een andere belangrijke functie die de beheerders vervullen is het beschermen van de kluis van een rekening. De kluis fungeert als een eenvoudige manier om de goederen af te sluiten zodat ze alleen opgenomen kunnen worden na een vooraf gedefinieerde tijdsperiode(geconfigureerd door de gebruiker, bijvoorbeeld 24 uur). Op dat moment kan een hacker alleen fondsen overboeken die zich niet in de kluis bevinden, terwijl de beheerders ervoor kunnen zorgen dat de fondsen uit de kluis alleen overgeboekt worden naar de nieuwe portemonnee van de echte eigenaar nadat zij een verzoek hebben ontvangen.

Door de bovengenoemde functionaliteiten kan een eindgebruiker zich tamelijk goed beschermen tegen hackers en tegen hun eigen geheugenverlies. Een van de kwetsbaarheden die blijft bestaan is de situatie waarin een meerderheid van beheerders een team vormen om de fondsen van een gebruiker te stelen wanneer deze zijn wachtwoord vergeet. Echter, deze kans wordt verkleind doordat het voor de hand ligt dat een gebruiker een voor hem betrouwbare partij zal benoemen om de taak van beheerder uit te voeren en zelf ook een betrouwbare partij zal zijn om op te treden als beheerder voor anderen.

--

--