Hoe MemoryVault beschermt wat je opslaat

Waarom deze pagina bestaat

Beveiligingsclaims in consumentenproducten zijn meestal geschreven om gerust te stellen, niet om te informeren. Het resultaat is een genre teksten dat spreekt over "bankniveau versleuteling" en "je gegevens zijn veilig bij ons", zonder ooit het enige te vertellen dat er echt toe doet: wie je gegevens kan lezen, en onder welke omstandigheden.

Deze pagina probeert dat direct te beantwoorden, inclusief de minder vleiende delen. Je wordt gevraagd berichten voor je kinderen en gegevens over je accounts op te slaan in andermans systeem. Dat is nogal wat om te vragen, en het verdient een precies antwoord in plaats van een geruststellend antwoord.

Wat versleuteld wordt

De gevoelige onderdelen van wat je opslaat, worden versleuteld voordat ze de database of bestandsopslag bereiken. Dat geldt voor de inhoud van je herinneringen, inclusief titels en notities, de notities bij een dierbare, geüploade mediabestanden en emailadressen.

De versleuteling gebeurt in de API-laag, en dat is een bewuste keuze. Het betekent dat de bescherming geldt voor gegevens op weg naar binnen, ongeacht uit welk deel van de applicatie ze kwamen, in plaats van een instelling op de database te zijn die verkeerd geconfigureerd kan raken, of een eigenschap van één codepad dat een ander pad vergeet te gebruiken.

Het algoritme is AES-256-GCM. Het AES-256-deel is een standaard, breed beoordeelde cipher. Het GCM-deel is belangrijker dan mensen doorgaans meewegen: het is een geauthenticeerde modus, wat betekent dat het de inhoud niet alleen vertrouwelijk houdt maar ook manipulatie detecteert. Worden opgeslagen gegevens gewijzigd, dan mislukt ontsleuteling hoorbaar in plaats van stilzwijgend iets aannemelijks maar verkeerds terug te geven. Voor een systeem dat bestaat om een accuraat laatste bericht te bezorgen, is hoorbaar falen het juiste gedrag.

Waar dat tegen beschermt

De voornaamste dreiging die dit adresseert is blootstelling van gegevens in rust.

Als een databaseback-up zou uitlekken, of iemand de opgeslagen bestanden rechtstreeks uit de opslag zou halen, is de gevoelige inhoud niet leesbaar. Ze hebben dan versleutelde tekst. Dat is geen hypothetische zorg; uitgelekte back-ups en verkeerd geconfigureerde opslag horen bij de meest voorkomende manieren waarop gegevens echt weglekken bij bestaande diensten, en het zijn precies de scenario’s waarin versleuteling in rust zijn nut bewijst.

Toegang tot bezorgde inhoud is apart afgeschermd, en dat is als eigen laag de moeite waard om te begrijpen. Bezorglinks werken met tokens en kunnen met een wachtwoord beveiligd worden. Wanneer een ontvanger een levering ontgrendelt, geldt die ontgrendeling voor specifieke media in plaats van algemene toegang te geven, en is die beperkt houdbaar. Ontsleuteling gebeurt pas nadat de toegangscontroles zijn doorstaan, zodat een mislukte controle nergens in het proces leesbare gegevens oplevert.

Het praktische effect is dat het bezitten van een bezorg-URL op zichzelf niet genoeg is om iemands berichten te lezen, en dat een ontvanger die toegang kreeg tot één levering daarmee geen toegang krijgt tot de rest van de kluis.

Wat het niet is: end-to-end-versleuteling

Dit is app-beheerde versleuteling, geen end-to-end-versleuteling. Het verschil is belangrijk genoeg om hier in gewone taal te staan in plaats van in een voetnoot.

End-to-end zou betekenen dat de sleutel je apparaat nooit verlaat, en dat niemand die de dienst draait je inhoud kan lezen, ook niet als ze dat zouden willen, ertoe gedwongen werden, of gehackt waren. Dat is hier niet het geval. De applicatie beheert het sleutelmateriaal, wat betekent dat de draaiende dienst technisch in staat is je gegevens te ontsleutelen.

Dat is een echte afweging, en een bewuste in plaats van een ongelukje. De reden is precies het bestaansrecht van het product: inhoud moet bezorgd worden bij een ontvanger die nooit gebruiker was, geen sleutel, geen app en geen account heeft, mogelijk pas over vele jaren, op een moment dat jij niet beschikbaar bent om te helpen. Echte end-to-end-versleuteling maakt dat vrijwel onmogelijk zonder je dierbaren vooraf een sleutel te geven en te hopen dat ze die nog hebben, nog begrijpen wat het is, en hem niet kwijtgeraakt zijn na drie verhuizingen en twee nieuwe telefoons.

Gegeven die keuze leek een eerlijk app-beheerd systeem dat daadwerkelijk bezorgt beter dan een end-to-end-systeem dat stilletjes faalt in het enige waarvoor het bestaat. Maar je hoort te weten welke van de twee je gebruikt, en je mag wantrouwig zijn tegenover wie beweert beide te bieden. Zegt een dienst end-to-end versleuteld te zijn én je gegevens na je overlijden aan iemand anders te kunnen overhandigen, dan doet een van die twee beweringen verdacht veel werk.

Wat dit in de praktijk betekent

Het is goed om concreet te zijn over wat het app-beheerde model wel en niet impliceert.

Het betekent dat je gegevens beschermd zijn tegen de meest waarschijnlijke faalscenario’s: een uitgelekte back-up, gestolen opslagbestanden, een aanvaller die bij de database komt maar niet bij de draaiende applicatie. In die gevallen is wat ze hebben onleesbaar.

Het betekent ook dat de veiligheid van je inhoud afhangt van de veiligheid van de draaiende dienst en de sleutel die deze beheert. Dat is een kleiner pakket zekerheden dan end-to-end-versleuteling biedt, en dat is de eerlijke grens van de claim. Wie voldoende toegang heeft tot een draaiend productiesysteem met de sleutel, is in principe in staat gegevens te ontsleutelen. Geen enkele formulering verandert daar iets aan.

Wat dat risico verkleint is geen belofte maar een structuur: de sleutel gescheiden houden van de gegevens, beperken wie bij productie kan, en precies kunnen laten zien wat de code met die sleutel doet. Dat brengt ons bij het deel dat je zelf kunt controleren.

Waarom je dit kunt verifiëren in plaats van vertrouwen

Niets hiervan hoef je op ons woord aan te nemen. De Community Edition is open source, en de versleutelingsmodule, de bezorgstroom en de toegangscontroles staan allemaal in code die je kunt lezen.

Dat is de sterkste garantie die beschikbaar is voor een dienst die niet end-to-end versleuteld is. Een belofte kun je niet verifiëren. Een implementatie wel. Je kunt precies nalezen wat wanneer versleuteld wordt, bevestigen dat ontsleuteling áchter de toegangscontroles zit en niet ervoor, en zelf zien dat de ontgrendeling bij bezorging afgebakend en tijdelijk is in plaats van een generieke sleutel tot de kluis.

Wil je liever niet afhankelijk zijn van iemand anders die die code correct draait, dan kun je hem zelf draaien. Zelf hosten verandert de hierboven beschreven afweging volledig, want dan beheer jij het sleutelmateriaal en is de "draaiende dienst" je eigen machine. Dat is een echte optie, bewust opengehouden, en het is het eerlijke antwoord aan wie deze pagina leest en concludeert dat app-beheerde versleuteling voor hem niet genoeg is.

Beide antwoorden zijn legitiem. Wat niet legitiem zou zijn, is dit beschrijven als iets sterkers dan het is, en dan hopen dat niemand kijkt.