Wat Is Zero-knowledge Versleuteling? Een Eenvoudige Handleiding
Zero-knowledge versleuteling betekent dat de provider geen toegang heeft tot je data.
Zero-knowledge-versleuteling is een architectuur waarin de aanbieder niet de sleutel heeft die nodig is om opgeslagen gebruikersinhoud te ontsleutelen. Bij gewone cloudversleuteling beheert de aanbieder de inhoudssleutel; bij versleuteling aan de clientzijde blijft die mogelijkheid op de apparaten van de gebruiker. Een juridisch verzoek, een inbraak of een insider kan nog steeds versleutelde gegevens, accountgegevens, verkeersgegevens of andere metagegevens die de provider bewaart, blootleggen. De NIST-richtlijnen voor sleutelbeheer maken het bewaren van sleutels de kern van toegang, maar de client-app, het besturingssysteem en het ontgrendelde apparaat blijven onderdeel van de vertrouwensgrens.
Hoe Zero-knowledge Versleuteling Werkt
De eenvoudigste analogie: een hotelkluis waarbij alleen jij de combinatie instelt, en het hotel hem nooit leert. Als je de combinatie vergeet, kan het hotel de kluis niet voor je openen. Dat is geen fout in het ontwerp. Dat is het ontwerp.
In technische termen werkt zero-knowledge versleuteling via drie stappen:
Sleutelafleiding op het apparaat. De gebruiker voert een geheim in, zoals een wachtwoord, wachtwoordzin of patroon. Een op wachtwoord gebaseerde sleutelafleidingsfunctie combineert deze met een salt om een sleutel op het apparaat van de gebruiker te produceren. Een goed gescheiden ontwerp kan die sleutel gebruiken om een willekeurige inhoudssleutel te ontgrendelen in plaats van elk bestand rechtstreeks met het geheim van de gebruiker te versleutelen.
Versleuteling vóór verzending. Alle data wordt versleuteld op het apparaat met de afgeleide sleutel voordat het het apparaat verlaat voor cloudopslag of back-up. De versleutelde uitvoer (ciphertext) is wat wordt geüpload.
De aanbieder ontvangt geen leesbare inhoudssleutel. Inhoudssleutels staan tijdens gebruik noodzakelijk in het geheugen van de app en kunnen ook lokaal of op afstand worden opgeslagen in geauthenticeerde, versleutelde enveloppen. De aanbieder kan versleutelde gegevens en omhulde sleutels opslaan zonder het gebruikersgeheim te bewaren dat nodig is om ze te openen. Metagegevens over account, verkeer, recordgrootte en timing kunnen nog steeds zichtbaar blijven.
De kritische beperking: als de gebruiker alle geldige inloggegevens en herstelroutes verliest, wordt de versleutelde inhoud onbereikbaar. Herstel kan nog steeds bestaan, maar de sleutelbewaring ervan moet worden uitgelegd. Als alleen een e-mailreset leesbare inhoud herstelt zonder goedkeuring van het oude apparaat, herstelzin, herstelsleutel of een gelijkwaardig door de gebruiker bewaard geheim, heeft de aanbieder in feite een route terug naar de leesbare inhoud gehouden.
Zero-knowledge Versleuteling vs Andere Typen Versleuteling
De term "versleuteling" verschijnt in marketingmaterialen voor bijna elke cloudservice. De verschillen tussen typen zijn substantieel.
| Type | Wie Houdt de Sleutel | Provider Kan Data Lezen | Overleeft Providerlek | Voorbeeld |
|---|---|---|---|---|
| Geen versleuteling | N.v.t. | Ja | Nee | Dropbox (standaard laag) |
| Versleuteling onderweg (TLS) | Provider | Ja (in rust op hun servers) | Nee | Google Foto's |
| Serversijdige versleuteling in rust | Provider | Ja (zij houden de ontsleutelingssleutel) | Gedeeltelijk (hangt af van lekbereik) | iCloud (standaard) |
| End-to-end-encryptie van het platform | Clientapparaten en accountherstelsysteem | Niet via het normale servicepad | Afhankelijk van de client, het herstel en de blootstelling aan metagegevens | iCloud met geavanceerde gegevensbescherming |
| Versleuteling aan de clientzijde zonder sleutel bij de aanbieder | Herstel onder controle van app en gebruiker | Aanbieder bewaart geen leesbare inhoudssleutel | Inhoud kan versleuteld blijven; metadata en versleutelde gegevens kunnen nog steeds uitlekken | Versleutelde kluis- en back-upsystemen |
Het onderscheid tussen "versleuteling in rust" en "zero-knowledge versleuteling" is het meest verwardend. Met versleuteling in rust versleutelt de provider je data op hun servers met sleutels die zij beheren. Dit beschermt tegen fysieke diefstal van de serverhardware. Het beschermt niet tegen het lezen van je data door de provider, een overheidsdagvaarding voor de data en sleutels, of een bedreiging van binnenuit. De provider heeft de ontsleutelingscapaciteit.
Bij versleuteling aan de clientzijde zonder sleutel bij de aanbieder krijgt de dienst via het gedocumenteerde protocol geen leesbare inhoudssleutel. Opgeslagen versleutelde gegevens kunnen voor die aanbieder onleesbaar blijven, terwijl de clientsoftware, het herstelpad, de metagegevens van het account en het softwareleveringskanaal nog steeds vertrouwen en beoordeling vereisen.
Waarom Zero-knowledge Versleuteling Ertoe Doet
Datalekken Blootstellen Jaarlijks Miljarden Gegevens
Het Identity Theft Resource Center rapporteerde in 2023 3.205 datalekken in de Verenigde Staten, waarbij ongeveer 353 miljoen personen betrokken waren. Als een aanbieder de inhoudssleutels heeft, kan één inbraak zowel de opgeslagen gegevens als een manier om ze te ontsleutelen blootleggen. Versleuteling zonder sleutel bij de aanbieder houdt die twee gescheiden: een serverlek kan nog steeds versleutelde gegevens en metadata blootleggen, maar geen leesbare inhoudssleutel van de aanbieder. Het raden van inloggegevens en een gehackte app blijven aparte risico's.
Juridische Dwang Is een Echte Bedreiging
Aanbieders kunnen verplicht worden de gegevens die zij bewaren openbaar te maken. Een ontwerp zonder sleutel bij de aanbieder beperkt die afgifte tot versleutelde gegevens en de beschikbare account-, verkeers-, facturerings- of dienstmetadata, omdat de aanbieder de leesbare inhoudssleutel niet heeft. Of een andere partij de inloggegevens van een gebruiker kan bemachtigen, de app kan misbruiken of afgifte kan afdwingen, is een aparte vraag. Apple introduceerde Geavanceerde gegevensbescherming in iOS 16.2 als optionele uitbreiding van end-to-end-versleuteling voor iCloud-gegevens.
"Vertrouw Ons" Is Geen Beveiligingsarchitectuur
Versleuteling aan de serverzijde is afhankelijk van door de provider beheerde sleutels en beleid. Versleuteling zonder sleutel bij de aanbieder verandert wie de sleutels bewaart, zodat de gedocumenteerde dienst geen leesbare inhoudssleutel heeft. Dat is een sterkere grens in de architectuur, maar de kracht ervan hangt nog steeds af van de juiste clientcode, geauthenticeerde softwarelevering, goed herstel, veilige apparaten en een implementatie die overeenkomt met de specificatie.
De NIST-standaard Achter de Cryptografie
AES-GCM werd gestandaardiseerd door het National Institute of Standards and Technology in SP800-38D (2007). AES zelf werd in 2001 door NIST geselecteerd via een openbare wedstrijd. De "256" in AES-256 verwijst naar een sleutel van 256 bits. Uitputtend zoeken naar een uniform willekeurige sleutel is rekenkundig onhaalbaar, maar een menselijk wachtwoord of patroon kan veel minder entropie opleveren, zelfs als een sleutelafleidingsfunctie 256 bits uitvoert.
GCM (Galois/Counter Mode) voegt geverifieerde versleuteling toe, wat betekent dat het ontsleutelingsproces eventuele manipulatie van de ciphertext detecteert. Als één bit van de versleutelde data wordt gewijzigd, mislukt ontsleuteling in plaats van gecorrumpeerde uitvoer te produceren. Dit voorkomt dat aanvallers versleutelde data manipuleren zonder detectie.
PBKDF2 (Wachtwoordgebaseerde sleutelafleidingsfunctie 2), gespecificeerd in RFC8018, zet een door een mens ingevoerd geheim om in sleutelmateriaal met een vaste lengte door middel van herhaalde pseudo-willekeurige functieaanroepen. Meer iteraties verhogen de kosten van elke gok. Ze voegen geen entropie toe aan een voorspelbaar patroon of wachtwoord, dus de keuze van inloggegevens en offline verificatie zijn nog steeds van belang.
Hoe Vaultaire aanbieder en sleutels gescheiden houdt
Vaultaire is een aan de clientzijde versleutelde kluis voor de iPhone. Van wat vaak als 'zero-knowledge' wordt verkocht, is de beperktere gedocumenteerde bewering dat Wraxle geen leesbare kluisinhoud ontvangt en ook niet de sleutels die nodig zijn om die te ontsleutelen. Hieronder ziet u per laag hoe de implementatie werkt en welke vertrouwensgrenzen overblijven.
Sleutelafleiding. De gebruiker tekent een patroon op een 5x5 raster van 25 stippen. PBKDF2-HMAC-SHA512 combineert die reeks in 600.000 iteraties met één salt van het apparaat uit de sleutelhanger (Keychain) om een 256-bits kluissleutel af te leiden. De kluissleutel verifieert de versleutelde index en omhult een aparte willekeurige hoofdsleutel van 256 bits. Herstelgegevens, inclusief het patroon, worden opgeslagen in een met AES-GCM versleutelde database in de sleutelhanger (Keychain), niet in leesbare tekstbestanden of een Vaultaire-account.
Bestandsversleuteling. Elk geïmporteerd bestand wordt versleuteld met AES-256-GCM onder de willekeurige hoofdsleutel. CryptoKit maakt geauthenticeerde sealed boxes met nieuwe nonces, en het streamingformaat leidt voor elk opeenvolgend deel een aparte nonce af.
Versleuteling van metadata. Bestandsnamen, MIME-typen, datums, indexrecords en miniatuurgegevens zijn ook beveiligd met AES-256-GCM. Vaultaire gebruikt ChaCha20 niet voor kluismetagegevens.
Sleutelbeheer. Vaultaire slaat de salt van het apparaat en de versleutelde hersteldatabase op als gewone generieke wachtwoorditems in de iOS-sleutelhanger (Keychain), beveiligd met de toegankelijkheidsklasse WhenUnlockedThisDeviceOnly. Van het patroon afgeleide kluissleutels en willekeurige hoofdsleutels worden met CryptoKit in het app-geheugen verwerkt. Vergrendeling laat de actieve sleutelstatus vallen, maar Swift en iOS bieden geen garantie dat elke tijdelijke kopie wordt overschreven.
Kluizen ontdekken. De normale interface toont geen kluislijst. Het opslagformaat houdt één opslagmap per kluis bij. Iemand met toegang tot de app-container kan daarom kluizen tellen, al onthullen de mapnamen geen patronen, namen of leesbare inhoud. Bekijk de volledige beveiligingsarchitectuur en uitleg over patroonversleuteling.
Hoe Te Controleren of een App Echte Zero-knowledge Versleuteling Gebruikt
Begin met drie snelle tests en verifieer vervolgens de gepubliceerde architectuur:
De wachtwoord-vergeten-test. Als alleen een reset via e-mail de leesbare gegevens terugbrengt, vraag dan welk mechanisme van de provider de effectieve inhoudssleutel heeft hersteld. Door de gebruiker beheerde herstelzinnen, goedkeuring van oude apparaten en door de provider gecontroleerde resets zijn verschillende ontwerpen.
De nieuwe-apparaattest. Als een nieuw apparaat leesbare inhoud herstelt, identificeer dan het geheime of vertrouwde apparaat dat het heeft geautoriseerd. Is alleen inloggen op een account genoeg, dan wijst dat op herstel onder controle van de aanbieder; een herstelzin plus versleutelde back-uprecords kan de sleutels buiten bereik van de aanbieder houden.
De accounttest. Een e-mailadres of telefoonnummer koppelt identiteit aan metagegevens van de dienst, maar bewijst op zichzelf niet dat de provider inhoud kan ontsleutelen. Inspecteer de sleutelhiërarchie, het herstelontwerp, de clientcode of audit, het metadatabeleid en of geauthenticeerde versleutelde gegevens het mogelijk maken het geheim offline te raden.
Deze tests zijn filters, geen veiligheidsbewijs. Een coherente specificatie moet de inhoudssleutel, ontgrendelingssleutel, salts, afleidingsparameters, geauthenticeerde versleutelingsindeling, nonce-regels, herstelenveloppen, lokale geheime opslag, cloud-metagegevens en het punt waar sleutels in platte tekst bestaan, benoemen. Onafhankelijke beoordeling is sterker bewijs dan een productlabel.
Veelgestelde vragen
Is zero-knowledge versleuteling hetzelfde als end-to-end versleuteling?
Ze overlappen maar zijn niet identiek. End-to-end versleuteling (E2EE) betekent dat data versleuteld wordt op het apparaat van de afzender en alleen ontsleuteld op het apparaat van de ontvanger. Zero-knowledge versleuteling betekent dat de provider geen toegang heeft tot de data. Een service kan end-to-end versleuteld zijn zonder zero-knowledge te zijn als de provider de sleutels op enig moment heeft gegenereerd of toegang had. Zero-knowledge versleuteling is de strengere standaard.
Wat gebeurt er als ik mijn wachtwoord verlies met zero-knowledge versleuteling?
Uw gegevens worden permanent ontoegankelijk als alle geldige inloggegevens en herstelenveloppen verloren gaan. Een reset of hoofdsleutel onder controle van de aanbieder zou die grens verzwakken, dus herstel moet afzonderlijk worden ontworpen. Vaultaire gebruikt een herstelzin, een gegenereerde zin van negen woorden of een eigen zin van minstens zes woorden, waarvan de afgeleide herstelsleutel een versleutelde envelop met de kluissleutel opent. De zin maakt de sleutel niet opnieuw aan en bevat hem niet, en herstel op een nieuw apparaat vereist ook de bijbehorende versleutelde CloudKit-records.
Kan wetshandhaving toegang krijgen tot zero-knowledge versleutelde data?
Een aanbieder kan verplicht worden opgeslagen versleutelde gegevens en de account-, verkeers-, facturerings- of dienstmetadata die hij bewaart af te geven. Zonder een leesbare inhoudssleutel in eigen bezit kan die aanbieder de inhoud niet via de normale dienst ontsleutelen. Misbruik van apparaten, het achterhalen van inloggegevens, herstelkopieën en gedwongen openbaarmaking zijn afzonderlijke routes waarvan de wettigheid en effectiviteit variëren afhankelijk van het rechtsgebied en de feiten.
Is zero-knowledge versleuteling langzamer dan reguliere versleuteling?
De snelheid van AES-256-GCM hangt niet af van wie de sleutel heeft. Op wachtwoord gebaseerde afleiding voegt werk toe tijdens het ontgrendelen, en de duur ervan hangt af van het algoritme, het aantal iteraties, het apparaat en de implementatie. Applicaties moeten die kosten voor ondersteunde hardware meten en de responsiviteit afwegen tegen de kosten die aan elke offline gok worden opgelegd.
Betekent zero-knowledge dat de app helemaal geen data verzamelt?
Niet noodzakelijkerwijs. De term gaat over de grens tussen inhoud en sleutels bij de aanbieder, niet over elke gegevensstroom. Een app kan nog steeds accountgegevens, analyses, crashrapporten, IP-adressen, recordgroottes, timing of andere metagegevens van de service verwerken. Voor Vaultaire is geen identiteitsaccount vereist. De app-analyse en crashdiagnostiek zijn standaard ingeschakeld en kunnen worden uitgeschakeld met “Deel fouten anoniem” in Instellingen. Het gedocumenteerde gebeurtenisbeleid sluit kluisinhoud, patronen, zinnen en ontsleutelingssleutels uit; het privacybeleid beschrijft de huidige regels voor verzamelen en bewaren.
Hoe verhoudt zero-knowledge versleuteling zich tot Apple's Geavanceerde gegevensbescherming?
Apple's Geavanceerde gegevensbescherming (ADP), geïntroduceerd in iOS 16.2, breidt end-to-end-versleuteling uit naar extra iCloud-categorieën en gebruikt het herstelmodel van de Apple-account. Vaultaire versleutelt de kluisinhoud op het apparaat en vraagt geen Vaultaire-account; de iCloud-back-up (standaard aan, uit te zetten), synchronisatie en delen gebruiken aan de clientzijde versleutelde CloudKit-records in de Apple-account van de gebruiker. Vaultaire biedt ook aparte kluistoegang per patroon en plausibele ontkenning, met de opslag- en herstellimieten die worden beschreven in de documentatie over de dwangmodus.
Samenvatting
Zero-knowledge-versleuteling kun je het best zien als een bewering dat aanbieder en sleutels gescheiden zijn: de dienst heeft niet de leesbare sleutel die nodig is om opgeslagen inhoud te ontsleutelen. Dat is sterker dan versleuteling aan de serverzijde met sleutels onder controle van de aanbieder, maar het is geen claim dat sleutels alleen in het geheugen bestaan, dat metagegevens verdwijnen, of dat elke client- en apparaatcompromis wordt verslagen. Beoordeel het product op sleutelhiërarchie, herstelontwerp, implementatie en onafhankelijke beoordeling.