Wat betekent zero-knowledge-versleuteling?

Stel u een kluis voor in een hotelkamer waarvan alleen u de sleutel bezit. Niet het hotel, niet de maker van de kluis, niemand anders kan haar openen – ook niet wanneer iemand erom vraagt, en ook niet wanneer men het hotel daartoe zou willen dwingen. Het hotel bewaart de gesloten kast, maar weet niet wat erin ligt en heeft geen middel om daarachter te komen. Precies dat is de belofte achter de term zero-knowledge-versleuteling: de aanbieder die uw gegevens opslaat of verstuurt, heeft geen enkele kennis van de inhoud ervan. Dit artikel legt uit wat de term precies betekent, hoe de techniek erachter werkt, waarin hij verschilt van verwante concepten – en waaraan u een echte zero-knowledge-methode herkent in plaats van een loutere etikettering.

• De aanbieder die niets weet
• Waar de sleutel ontstaat
• Een voorbeeld van begin tot eind
• Eén term, twee betekenissen
  • Zero-knowledge of eind-tot-eind?
• Vier beschermingsmodellen vergeleken
• Wat zero-knowledge beschermt – en wat niet
  • Wat gebeurt er als ik mijn wachtwoord verlies?
• Waaraan men echte zero-knowledge herkent
• Conclusie

#De aanbieder die niets weet

De kern van de term zit in de woorden „zero knowledge", ofwel „nul kennis": bedoeld wordt dat de dienstaanbieder nul kennis heeft van de inhoud die hij voor u opslaat of doorstuurt. Hij ziet alleen versleutelde gegevens – een onbegrijpelijke tekenreeks – en bezit niet de middelen om die te ontsleutelen. Dat onderscheidt zero-knowledge wezenlijk van de meeste gangbare cloud- en deeldiensten, waarbij de aanbieder de gegevens weliswaar versleuteld opslaat, maar de bijbehorende sleutel zelf beheert en daarmee op elk moment toegang heeft tot de leesbare inhoud.

Dit onderscheid heeft tastbare gevolgen. Houdt de aanbieder de sleutel, dan kan hij de gegevens lezen – uit eigen beweging, door een beveiligingslek, via een gecompromitteerd medewerkersaccount, of omdat een autoriteit hem daartoe verplicht. Bij een echte zero-knowledge-methode vervalt die mogelijkheid niet uit een belofte of goede bedoeling, maar uit technische noodzaak: de aanbieder kan niet afgeven wat hij niet heeft. De vertrouwelijkheid hangt daarmee niet langer af van vertrouwen in de aanbieder, maar van de architectuur van het systeem.

Dat verandert het dreigingsmodel wezenlijk. Bij gangbare diensten moet men erop vertrouwen dat de aanbieder zorgvuldig werkt, dat zijn medewerkers integer zijn, dat zijn systemen niet worden gecompromitteerd en dat hij verzoeken van derden passend toetst. Elk van deze punten is een mogelijk breekpunt. Zero-knowledge verwijdert ze niet stuk voor stuk, maar maakt ze irrelevant: waar de aanbieder de leesbare inhoud technisch niet kan bereiken, doet het er niet meer toe of een medewerker nieuwsgierig, een aanvaller succesvol of een overheidsbevel werkzaam is. Het vertrouwen verschuift van het gedrag van de aanbieder naar de wiskunde van de versleuteling.

#Waar de sleutel ontstaat

Wil de aanbieder niets weten, dan moet een eenvoudige regel gelden: de versleuteling gebeurt bij de gebruiker, voordat de gegevens het apparaat verlaten, en de sleutel verlaat het apparaat nooit in leesbare vorm. De technische term is clientzijdige versleuteling – „client" staat voor het apparaat of de toepassing van de gebruiker, in tegenstelling tot de server van de aanbieder.

Het verloop laat zich in enkele stappen beschrijven. Uit een geheim dat alleen de gebruiker kent – doorgaans een wachtwoord – wordt op het apparaat een cryptografische sleutel afgeleid. Met die sleutel worden de gegevens lokaal versleuteld, in de browser of de app, voordat er iets wordt verstuurd. Pas de zo ontstane, onleesbare versie wordt naar de aanbieder geüpload. Bij het ophalen verloopt het proces omgekeerd: de aanbieder levert de versleutelde gegevens terug, en pas op het apparaat van de gebruiker worden ze met de daar afgeleide sleutel weer leesbaar gemaakt.

Het beslissende punt is wat daarbij nooit gebeurt: de afgeleide sleutel en het onderliggende wachtwoord worden niet naar de aanbieder verstuurd. De server ziet op geen enkel moment de leesbare inhoud en nooit de sleutel. De vertrouwelijkheid is daarmee geen eigenschap die de aanbieder verleent, maar een die hij in het geheel niet kan opheffen. Hoe dit beginsel zich laat toepassen op het concrete versturen van vertrouwelijke inhoud, laat het artikel Vertrouwelijke documenten veilig versturen – stap voor stap zien.

#Een voorbeeld van begin tot eind

Aan een eenvoudige handeling laat het samenspel zich navolgen. Stel dat u een vertrouwelijk document wilt delen via een op zero-knowledge gebaseerde dienst. Zodra u het bestand kiest, genereert de toepassing op uw apparaat een willekeurige sleutel en versleutelt het document daarmee lokaal. Wat vervolgens naar de aanbieder wordt geüpload, is alleen nog de versleutelde versie – voor de server een betekenisloze tekenreeks.

Wil de ontvanger het document kunnen lezen, dan heeft hij de sleutel nodig. Hier toont zich een eigenaardigheid van op zero-knowledge gebaseerde diensten: de sleutel mag niet via de aanbieder lopen, anders zou die hem immers hebben. In plaats daarvan wordt hij vaak in de link zelf meegegeven – preciezer in het deel achter het hekje, dat technisch niet aan de server wordt verstuurd – of via een gescheiden kanaal aan de ontvanger overhandigd. Opent de ontvanger de link, dan haalt zijn toepassing het versleutelde bestand op en ontsleutelt het pas op zijn apparaat met de meegeleverde sleutel.

Over het hele traject ziet de aanbieder op geen enkel moment de leesbare inhoud en nooit de sleutel. Precies dat is de praktische betekenis van zero-knowledge: de dienst bemiddelt de overdracht zonder deel te hebben aan de inhoud. Tegelijk maakt het voorbeeld een verantwoordelijkheid zichtbaar – wordt de sleutel over hetzelfde onveilige kanaal als de link gedeeld, dan ontstaat een gat dat niet in de architectuur ligt, maar in het gebruik.

#Eén term, twee betekenissen

Op dit punt is een verduidelijking nodig die in de praktijk vaak ontbreekt en die een deskundig publiek terecht verwacht. „Zero-knowledge" duidt op twee verschillende dingen die gemakkelijk worden verward.

Het eerste is de hier beschreven zero-knowledge-versleuteling of zero-knowledge-architectuur: een bouwwijze van opslag- en deeldiensten waarbij de aanbieder geen toegang heeft tot sleutels en leesbare inhoud. „Zero-knowledge" is hier een beschrijvende uitspraak over de aanbieder – hij heeft nul kennis van uw inhoud.

Het tweede is het zero-knowledge-bewijs (Engels: zero-knowledge proof), een zelfstandig cryptografisch protocol. Daarbij bewijst de ene partij aan de andere dat een bewering waar is, zonder enige andere informatie prijs te geven dan het feit dat de bewering klopt. Het klassieke voorbeeld is het aantonen dat men een wachtwoord kent, zonder het te versturen. Zero-knowledge-bewijzen zijn een instrument van de cryptografie en worden onder meer gebruikt bij authenticatieprocedures en in de blockchainwereld.

Beide termen delen het grondidee om iets aan te tonen of te verwerken zonder het eigenlijke prijs te geven – maar zij zijn niet hetzelfde. Een zero-knowledge-versleuteling vereist niet noodzakelijk een zero-knowledge-bewijs. Sommige diensten combineren beide, bijvoorbeeld door de aanmelding te beveiligen met een methode waarbij de server het wachtwoord kan controleren zonder het ooit te kennen. Noodzakelijk voor de vertrouwelijkheid van de opgeslagen gegevens is dat echter niet; daarvoor volstaat de clientzijdige versleuteling. Wie de termen zuiver scheidt, herkent sneller wat een dienst werkelijk belooft.

#Zero-knowledge of eind-tot-eind?

Nauw verwant maar niet samenvallend is de eind-tot-eindversleuteling. Zij beschrijft dat inhoud doorlopend versleuteld blijft van afzender tot de beoogde ontvanger, zodat tussenstations – ook de bemiddelende aanbieder – die niet kunnen lezen. Zero-knowledge is in de kern hetzelfde idee, maar benadrukt het perspectief van de opslaande aanbieder: hij heeft nul kennis, omdat de sleutel en de ontsleuteling uitsluitend bij de gebruiker liggen.

Inhoudelijk overlappen de termen sterk. Een op zero-knowledge gebaseerde opslagdienst is clientzijdig versleuteld; een eind-tot-eind versleutelde dienst houdt de aanbieder eveneens buiten spel. Het verschil is meestal een van nadruk en toepassing – „eind-tot-eind" denkt vanuit de communicatie tussen twee partijen, „zero-knowledge" vanuit de opslag bij de aanbieder. Waar precies de grens tussen doorlopende en louter transportversleuteling ligt, verdiept het geplande artikel Eind-tot-eind versus transportversleuteling.

#Vier beschermingsmodellen vergeleken

De waarde van zero-knowledge wordt het duidelijkst wanneer men het naast de overige gangbare beschermingsmodellen plaatst. Het volgende overzicht ordent ze naar wie de sleutel houdt en waartegen het model werkelijk beschermt:

De eerste twee rijen beschrijven modellen waarbij de aanbieder de leesbare inhoud kan zien – serverzijdige versleuteling beschermt vooral tegen de diefstal van harde schijven, transportversleuteling tegen meelezen onderweg. Waarom juist de gewone e-mail deze zwakheden bundelt, behandelt het artikel Waarom e-mail geen veilige manier is om gegevens te versturen. Pas de onderste twee rijen sluiten de aanbieder uit – en zero-knowledge is de meest consequente uitdrukking van dat idee.

#Wat zero-knowledge beschermt – en wat niet

Hoe sterk het model ook is, het is geen wondermiddel, en een serieuze omgang met de term benoemt ook zijn grenzen. Zero-knowledge beschermt de vertrouwelijkheid van de inhoud tegenover de aanbieder en tegenover ieder die zich toegang tot diens systemen verschaft. Het maakt de gegevens niet „onkraakbaar", en het beschermt niet tegen alles.

Een eerste grens ligt in de sterkte van het wachtwoord. Omdat de sleutel uit het geheim van de gebruiker wordt afgeleid, is de hele methode slechts zo sterk als dat geheim. Een zwak, te raden wachtwoord ondermijnt de bescherming, hoe degelijk de versleuteling zelf ook is. Een tweede grens ligt in het apparaat: is de computer van de gebruiker met malware besmet, dan kan de inhoud daar worden afgevangen voordat hij wordt versleuteld of nadat hij is ontsleuteld. Zero-knowledge beschermt de gegevens bij de aanbieder, niet het gecompromitteerde eindpunt.

Een derde, subtielere grens betreft het vertrouwen in de client. De versleuteling vindt plaats in de software van de gebruiker – maar die software komt vaak van de aanbieder zelf, bijvoorbeeld als een webtoepassing die bij elk bezoek opnieuw wordt geladen. Men vertrouwt er dus op dat de geleverde client werkelijk doet wat hij belooft en de sleutel niet stiekem afvoert. Opensource, onafhankelijk toetsbare code en navolgbare publicatieprocessen verkleinen dit restvertrouwen, maar heffen het niet volledig op. Ten slotte blijven vaak metagegevens zichtbaar – zoals bestandsgroottes of tijdstippen – die aan de inhoudsversleuteling ontsnappen.

Een vierde grens toont zich bij het delen. Zolang gegevens alleen voor uzelf zijn versleuteld, blijft de kring van ingewijden beperkt tot één persoon. Zodra u inhoud met anderen deelt, geeft u noodzakelijkerwijs de sleutel door – en verbreedt u daarmee de kring van wie kan ontsleutelen. Zero-knowledge zorgt ervoor dat de aanbieder buiten beeld blijft; het zorgt er niet voor dat de ontvanger betrouwbaar is of de sleutel veilig bewaart. De vertrouwelijkheid is altijd slechts zo goed als de zwakste schakel onder wie de sleutel houden. Wie deelt, moet daarom even zorgvuldig kiezen met wie en langs welke weg hij toegang geeft als hij de dienst zelf kiest.

#Wat gebeurt er als ik mijn wachtwoord verlies?

Deze vraag leidt naar de onvermijdelijke keerzijde van het model. Omdat de aanbieder de sleutel niet bezit, kan hij die ook niet opnieuw instellen. Er is geen „wachtwoord vergeten"-knop die de toegang herstelt, want daarvoor zou de aanbieder de gegevens moeten kunnen ontsleutelen – en juist dat sluit zero-knowledge uit. Verliest u het wachtwoord en een eventuele herstelsleutel, dan zijn de gegevens onherstelbaar verloren.

Dat is geen zwakte van de uitvoering, maar het logische gevolg van de belofte: de volledige controle over de sleutel betekent ook de volledige verantwoordelijkheid ervoor. Veel diensten verzachten dit met een eenmalig gegenereerde herstelcode die de gebruiker veilig bewaart. Die verschuift de verantwoordelijkheid, maar heft haar niet op. Wie zero-knowledge gebruikt, moet deze keerzijde kennen en het wachtwoord en de herstelsleutel met overeenkomstige zorg behandelen.

#Waaraan men echte zero-knowledge herkent

Omdat de term in marketing aantrekkelijk is, loont een toetsende blik of een dienst waarmaakt wat het etiket belooft. De volgende vragen helpen bij de inordening:

• Vindt de versleuteling aantoonbaar plaats op het apparaat van de gebruiker voordat er gegevens worden verstuurd?
• Wordt uitdrukkelijk verklaard dat de aanbieder noch de sleutel noch het wachtwoord ontvangt en geen toegang heeft tot de leesbare inhoud?
• Is er, consequent, geen wachtwoordherstel aan aanbiederszijde dat de toegang herstelt zonder een herstelsleutel?
• Is de client opensource of onafhankelijk geauditeerd, zodat de beweringen toetsbaar zijn?
• Doet de aanbieder duidelijke, navolgbare uitspraken over de sleutelhouderschap, in plaats van enkel het modewoord te gebruiken?

Hoe meer van deze vragen met ja kunnen worden beantwoord, des te eerder staat achter de term een echte architectuur en niet slechts een marketingbelofte. Eén tegenspraak is bijzonder veelzeggend: wie een volledig wachtwoordherstel aanbiedt en tegelijk „zero-knowledge" belooft, kan beide nauwelijks tegelijk nakomen. Crymbl plaatst zijn op zero-knowledge gebaseerde concepten precies in dit begrip – vertrouwelijkheid als eigenschap van de architectuur, niet als een betuiging van vertrouwen.

#Conclusie

Zero-knowledge-versleuteling betekent dat een aanbieder uw gegevens kan opslaan of versturen zonder ze ooit te kunnen lezen. Dat wordt bereikt door clientzijdige versleuteling: de sleutel ontstaat bij de gebruiker en verlaat diens apparaat nooit in leesbare vorm, zodat de aanbieder alleen onbegrijpelijke gegevens ziet. De vertrouwelijkheid verschuift daarmee van vertrouwen in de aanbieder naar een eigenschap van het systeem.

Twee dingen horen bij een eerlijk begrip. Ten eerste is de zero-knowledge-versleuteling niet te verwarren met het gelijknamige zero-knowledge-bewijs – verwant idee, verschillend concept. Ten tweede heeft het model een prijs: het maakt gegevens niet onkraakbaar, het vereist een sterk wachtwoord en een betrouwbaar eindapparaat, en het kent geen reddingslijn bij verlies van het wachtwoord. Wie deze grenzen kent, kan de term plaatsen in plaats van erop te vertrouwen – en juist dat oordeelsvermogen zou een goed begrip van zero-knowledge moeten bijbrengen.