Versleutelde opslag scheidt bestandsbytes van de bevoegdheid tot ontsleutelen, maar ontvangers, metadata en lokale kopieën blijven deel van het dreigingsmodel.
Een end-to-end versleutelde bijlage kan op een server worden opgeslagen zonder die server het onversleutelde bestand te geven. Een veelgebruikt ontwerp versleutelt het bestand op het apparaat van de afzender met een nieuwe inhoudssleutel, uploadt de versleutelde gegevens en stuurt de sleutel in een geauthenticeerd, versleuteld bericht naar de beoogde ontvangers.
Die scheiding is nuttig, maar ‘zero-knowledge-opslag’ is geen volledige specificatie. Je moet nog steeds vragen hoe sleutels, bestandsverwijzingen, bestandsnamen, toegangscontroles en gedownloade kopieën worden behandeld.
De levenscyclus van een bijlage
- Bereid het bestand voor. De afzender kiest een foto, video of document. Metadata verwijderen of transcoderen is een aparte stap; versleuteling alleen verwijdert geen EXIF-gegevens of documenteigenschappen.
- Maak versleutelingsmateriaal. Een veilige implementatie genereert de benodigde sleutels en nonces volgens het gekozen schema.
- Versleutel vóór het uploaden. De opslagdienst ontvangt versleutelde bytes in plaats van de oorspronkelijke inhoud.
- Bezorg een geauthenticeerde verwijzing. Het versleutelde chatbericht bevat de informatie die ontvangers nodig hebben, zoals de bestandslocatie, ontsleutelingssleutel en relevante integriteitsmetadata.
- Haal op en verifieer. De ontvangende client haalt het gegevensobject op en controleert de authenticatie voordat hij het resultaat als geldige inhoud behandelt.
- Beheer lokale kopieën. Weergeven, exporteren, bewerken of opslaan in een galerij kan kopieën buiten de oorspronkelijke grens van de versleutelde opslag maken.
De sleutel kan in een versleutelde envelop via de infrastructuur van dezelfde aanbieder reizen. Dat ‘out-of-band’ noemen kan misleiden: de sleutel is logisch gescheiden van de objectopslag, maar wordt niet noodzakelijk via een onafhankelijk communicatiekanaal bezorgd.
Wat geauthenticeerde versleuteling toevoegt
Een schema voor geauthenticeerde versleuteling beschermt vertrouwelijkheid en detecteert ongeoorloofde wijzigingen binnen zijn geauthenticeerde bereik. De GCM-specificatie van NIST beschrijft zo'n constructie en de vereisten ervan. Correct sleutel- en noncebeheer en controle van het authenticatieresultaat zijn essentieel; de naam van een erkend algoritme maakt niet iedere implementatie veilig.
De applicatie moet het bestand ook aan het juiste bericht en gesprek binden. Een geldig versleuteld gegevensobject bewijst op zichzelf niet dat het in deze specifieke chat thuishoort. Bestandsidentificatoren, verwachte grootte, volgorde van blokken en bijlagemetadata hebben een passend geauthenticeerd ontwerp nodig.
Wat de opslagdienst nog steeds kan leren
| Informatie | Verbergt inhoudsversleuteling alleen dit? |
|---|---|
| Oorspronkelijke bestandsbytes | Ze is ontworpen om die te verbergen voor partijen zonder sleutel |
| Geschatte versleutelde grootte | Meestal niet |
| Tijdstippen van upload en download | Meestal niet |
| Welk account een bestand opvraagt | Hangt af van routering en toegangscontrole |
| Bestandsnaam en bijschrift | Alleen als het protocol die ook beschermt |
| Een door de ontvanger opgeslagen kopie | Nee; de ontvanger heeft al toegang tot de leesbare inhoud |
Toegangscontroles blijven belangrijk, ook als gegevensobjecten versleuteld zijn. Ze kunnen ongewenste downloads, misbruik en blootstelling van identificatoren beperken. Versleuteling vervangt geen autorisatie, bewaarbeleid of beschikbaarheid.
Grote bestanden vragen meer dan een slogan
Een ontwerp voor grote bestanden kan gegevens streamen of in geauthenticeerde blokken opdelen. Dat kan geheugengebruik verminderen, maar bloknummering, uiteindelijke lengte, herhaalde pogingen en afhandeling van afkapping moeten vaststaan. Verzin geen prestatiecijfers en beweer niet dat een bestand in een bericht noodzakelijk ‘opgeblazen ratchetstatus’ veroorzaakt; zulke uitkomsten hangen van de implementatie af.
Een nuttige test omvat een geldig bestand, een gewijzigde byte, een afgeknotte download, een verplaatst blok en een ongeoorloofde ophaalpoging. Voer zulke tests alleen uit in een geautoriseerde testomgeving met niet-gevoelige bestanden. Leg vast of de client ongeldige gegevens weigert voordat hij ze opent.
Wat Livara documenteert
Livara's beveiligingspagina beschrijft versleuteling vóór de upload, een willekeurige sleutel per bestand die binnen de beschermde sessie wordt verstuurd en bescherming van bestandsnamen en bijschriften in gesprekken met actieve E2EE, waaronder compatibele privégroepen. Oudere incompatibele groepen vallen uitdrukkelijk buiten die dekking. De pagina onderscheidt beschermde gesprekken van openbare uitzendkanalen. Dit zijn gedocumenteerde productclaims, geen nieuwe implementatieaudit in dit artikel.
Het dreigingsmodel erkent ook dat een ontvanger of gecompromitteerd apparaat leesbare inhoud kan blootleggen. Versleutelde opslag kan daarom niet beloven dat een afbeelding van ieder apparaat verdwijnt wanneer het chatbericht wordt verwijderd.
Vragen vóór het delen van gevoelige bestanden
Controleer of het gesprekstype E2EE ondersteunt, of alle beoogde ontvangers betrouwbaar zijn en of het bestand zelf identificerende metadata bevat. Bekijk automatisch opslaan in de galerij en cloudback-ups van foto's afzonderlijk. Overweeg bij een document of opmerkingen, revisiegeschiedenis of ingesloten eigenschappen vóór verzending moeten worden verwijderd.
Begrijp ten slotte verwijderen en herstel. Een gegevensobject van de server verwijderen kan een toekomstige download stoppen, maar geen bestaande kopie van een ontvanger terughalen. Verlies van de benodigde sleutel kan een overgebleven versleuteld bestand onleesbaar maken. Een goed bijlageontwerp legt beide uitkomsten helder uit.
