Wat Is Zero-knowledge Versleuteling? Een Eenvoudige Handleiding
Zero-knowledge versleuteling betekent dat de provider geen toegang heeft tot je data.
Zero-knowledge-encryptie is een providergebonden architectuur waarin de service niet de sleutel bevat die nodig is om opgeslagen gebruikersinhoud te decoderen. In tegenstelling tot standaard cloud-encryptie waarbij de provider de inhoudssleutel beheert, kan encryptie aan de clientzijde deze mogelijkheid op gebruikersapparaten behouden. Een juridisch verzoek, inbreuk of insider kan nog steeds cijfertekst, accountgegevens, verkeersgegevens of andere metagegevens die de provider bewaart, blootleggen. De richtlijnen voor sleutelbeheer van NIST maken sleutelbewaring centraal bij 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 apparaat. De gebruiker geeft een referentie op, 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 inhoudscoderingssleutel te ontgrendelen in plaats van elk bestand rechtstreeks met de menselijke inloggegevens te coderen.
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 (cijfertekst) is wat wordt geüpload.
De provider ontvangt geen inhoudssleutel in leesbare tekst. Inhoudssleutels bestaan tijdens gebruik noodzakelijkerwijs in het geheugen van de cliënt en kunnen ook lokaal of op afstand worden opgeslagen in geauthenticeerde gecodeerde enveloppen. De provider kan cijfertekst en ingepakte 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 referenties en herstelpaden verliest, wordt de gecodeerde inhoud ontoegankelijk. 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 provider een effectieve route terug naar de leesbare tekst behouden.
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 |
| Provider-blinde versleuteling aan de clientzijde | Door client en gebruiker gecontroleerd herstelpad | Geen door de provider bewaarde inhoudssleutel in platte tekst | Inhoud kan gecodeerd blijven; metadata en cijfertekst kunnen nog steeds lekken | Gecodeerde 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.
Met provider-blinde encryptie aan de clientzijde krijgt de service niet de inhoudssleutel in platte tekst via het gedocumenteerde protocol. Opgeslagen cijfertekst kan voor die provider ondoorzichtig 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. Wanneer een provider inhoudssleutels bezit, kan één inbreuk zowel opgeslagen gegevens als een pad om deze te ontsleutelen blootleggen. Provider-blinde encryptie scheidt deze activa: een serverlek kan nog steeds cijfertekst en metagegevens blootleggen, maar niet een door de provider bewaarde inhoudssleutel in platte tekst. Het raden van inloggegevens en het compromitteren van klanten blijven afzonderlijke risico's.
Juridische Dwang Is een Echte Bedreiging
Aanbieders kunnen verplicht worden de gegevens die zij bewaren openbaar te maken. Een provider-blind ontwerp kan die reactie op cijfertekst en beschikbare account-, verkeer-, facturerings- of service-metagegevens beperken, omdat de provider niet over de inhoudssleutel in platte tekst beschikt. Of een andere partij een gebruikersreferentie kan verkrijgen, een klant kan exploiteren of openbaarmaking kan afdwingen, is een aparte vraag. Apple introduceerde geavanceerde gegevensbescherming in iOS 16.2 als optionele uitbreiding van end-to-end-encryptie voor iCloud gegevens.
"Vertrouw Ons" Is Geen Beveiligingsarchitectuur
Versleuteling aan de serverzijde is afhankelijk van door de provider beheerde sleutels en beleid. Provider-blinde encryptie verandert de sleutelbewaring, zodat het gedocumenteerde servicepad geen inhoudssleutel in platte tekst heeft. Dat is een sterkere architectonische grens, 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 cijfertekst 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 mensen verstrekte referentie 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 de scheiding tussen providers en sleutels implementeert
Vaultaire is een gecodeerde kluis aan de clientzijde iPhone. In de zin van het product dat vaak op de markt wordt gebracht als 'nulkennis', is de beperktere gedocumenteerde bewering dat Wraxle geen kluisinhoud in platte tekst ontvangt of de sleutels die nodig zijn om deze te decoderen. Hier ziet u hoe de implementatie en resterende vertrouwensgrenzen op elke laag werken.
Sleutelafleiding. De gebruiker tekent een patroon op een 5x5 raster van 25 stippen. PBKDF2-HMAC-SHA512 combineert die reeks met één apparaatbreed Keychain salt voor 600.000 iteraties om een 256-bits kluissleutel af te leiden. De kluissleutel verifieert de gecodeerde index en bevat een afzonderlijke willekeurige hoofdsleutel van 256 bits. Herstelinformatie, inclusief het patroon, wordt opgeslagen in een AES-GCM gecodeerd Keychain database in plaats van platte tekstbestanden of een Vaultaire-account.
Bestandsversleuteling. Elk geïmporteerd bestand is gecodeerd met AES-256-GCM onder de willekeurige hoofdsleutel. CryptoKit creëert geauthenticeerde verzegelde dozen met nieuwe nonces, en het streamingformaat leidt een aparte nonce af voor elk besteld deel.
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 zijn apparaatzout en gecodeerde hersteldatabase op als normaal iOS Keychain generieke wachtwoorditems die zijn beveiligd met de WhenUnlockedThisDeviceOnly toegankelijkheid klasse. Van patronen afgeleide kluissleutels en willekeurige hoofdsleutels worden in het app-geheugen verwerkt CryptoKit. Vergrendeling laat de actieve sleutelstatus vallen, maar Swift en iOS bieden geen garantie dat elke tijdelijke kopie wordt overschreven.
Kluis ontdekking. De normale interface toont geen kluislijst. In het lokale formaat wordt voor elke kluis precies één gecodeerd indexbestand opgeslagen, en de onderhoudscode kan deze bestanden opsommen. Iemand met app-containertoegang kan daarom gecodeerde indexen tellen, hoewel de bestandsnamen geen patronen, namen of platte tekstinhoud onthullen. Bekijk het 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 het opnieuw instellen van e-mail de leesbare gegevens herstelt, 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. Alleen al het inloggen op een account duidt op een door de provider gecontroleerd herstelpad; een herstelzin plus gecodeerde back-uprecords kunnen de scheiding tussen providersleutels behouden.
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 cijfertekst offline referentiecontroles toestaat.
Deze tests zijn filters, geen veiligheidsbewijs. Een coherente specificatie moet de inhoudssleutel, ontgrendelingssleutel, salts, afleidingsparameters, geauthenticeerde coderingsindeling, 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 door de provider gecontroleerde reset of hoofdsleutel zou de providergrens verzwakken, dus herstel moet afzonderlijk worden ontworpen. Vaultaire genereert een aangepaste zin met 9 afzonderlijke woorden waarvan de afgeleide herstelsleutel een gecodeerde kluissleutel-envelop opent. De zin genereert of codeert de sleutel niet, en voor het herstellen van een nieuw apparaat is ook de overeenkomende versleuteling vereist CloudKit records.
Kan wetshandhaving toegang krijgen tot zero-knowledge versleutelde data?
Het kan zijn dat een provider opgeslagen cijfertekst en de account-, verkeers-, facturerings- of service-metagegevens die hij bewaart, openbaar moet maken. Zonder een door de provider bewaarde sleutel voor inhoud in platte tekst kan die provider het normale servicepad niet gebruiken om de inhoud te decoderen. Exploitatie van apparaten, het ontdekken 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?
AES-256-GCM Prestaties zijn niet afhankelijk van wie de sleutel in handen 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 heeft betrekking op de grens tussen inhoud en sleutel van de provider, en niet op elke gegevensstroom. Een app kan nog steeds accountgegevens, analyses, crashrapporten, IP-adressen, recordgroottes, timing of andere metagegevens van de service verwerken. Vaultaire vereist geen identiteitsaccount en zegt dat de op toestemming gebaseerde analyses de kluisinhoud, patronen, zinsneden en decoderingssleutels uitsluiten; zijn privacybeleid beschrijft de huidige regels voor verzamelen en bewaren.
Hoe verhoudt zero-knowledge versleuteling zich tot Apple's Geavanceerde gegevensbescherming?
Apple's Advanced Data Protection (ADP), geïntroduceerd in iOS 16.2 breidt end-to-end-encryptie uit naar extra iCloud categorieën en maakt gebruik van het Apple Account-herstelmodel. Vaultaire houdt de kluisinhoud standaard lokaal en vereist geen Vaultaire-identiteitsaccount; Optionele back-up, synchronisatie en delen gebruiken versleuteling aan de clientzijde CloudKit records in het Apple-account van de gebruiker. Vaultaire biedt ook patroongescheiden kluistoegang en dwangmodus, met de opslag- en herstellimieten die worden beschreven in de bijbehorende plausibele ontkenningsdocumentatie.
Samenvatting
Zero-knowledge-encryptie kan het beste worden behandeld als een claim voor het scheiden van provider-sleutels: de service bevat niet de leesbare sleutel die nodig is om opgeslagen inhoud te decoderen. Dat is sterker dan versleuteling aan de serverzijde met door de provider gecontroleerde sleutels, 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 basis van de belangrijkste hiërarchie, herstelontwerp, implementatie en onafhankelijke beoordeling.