Een sleutel voor één bestand betekent niet dat het maar één keer kan worden bekeken of dat je de kopie van de ontvanger kunt terughalen.
Om een bijlage te beschermen, kan een berichtenapp het bestand op het apparaat van de afzender met een willekeurige sleutel versleutelen, de versleutelde versie uploaden en de bestandssleutel in een end-to-end versleuteld bericht naar de ontvanger sturen. Dit patroon wordt soms envelopversleuteling genoemd: het grote bestand en de kleine hoeveelheid informatie die nodig is om het te openen, volgen verschillende maar samenhangende routes.
Deze uitleg gaat over bijlagen in een gesprek met E2EE; bestanden versturen in elke willekeurige app of elk type kanaal biedt niet noodzakelijk dezelfde bescherming.
De weg van een privéfoto van apparaat naar ontvanger
- Het apparaat van de afzender genereert een inhoudssleutel voor het bestand.
- Het bestand wordt met geauthenticeerde versleuteling versleuteld; de ontvanger moet ongeoorloofde wijzigingen in de gegevens kunnen herkennen.
- De versleutelde versie wordt op een bestandsopslagdienst geplaatst.
- Het adres of de identificatie van het bestand en de benodigde sleutel worden in een beschermd bericht naar de ontvanger gestuurd.
- Het apparaat van de ontvanger ontvangt het bestand, valideert het en opent het vervolgens.
Livara’s beveiligingsdocumentatie beschrijft voor bijlagen een willekeurige sleutel per bestand en de overdracht daarvan binnen de berichtensessie. Dit artikel legt die beschreven architectuur uit, niet de resultaten van een implementatie-audit.
Een ‘sleutel per bestand’ is niet hetzelfde als ‘het bestand kan maar één keer worden geopend’
Een sleutel die voor één bestand wordt gegenereerd, kan nodig zijn om datzelfde bestand meerdere keren te lezen. Een eigen sleutel betekent niet dat deze direct na de eerste weergave wordt weggegooid, dat het bestand automatisch wordt verwijderd of dat de ontvanger het niet kan opslaan.
Ook een eenmalige berichtsleutel en het gebruik van een inhoudssleutel voor een bijlage zijn twee verschillende begrippen. Functies zoals Eenmalig bekijken of verdwijnende berichten mag je niet alleen uit de naam van het algoritme afleiden.
Waarom zijn zowel de sleutel als de nonce belangrijk?
AES-GCM biedt naast vertrouwelijkheid ook een controle op de authenticiteit van gegevens, maar correct gebruik is essentieel. De NIST SP 800-38D-standaard beschrijft de regels van GCM. Hergebruik van dezelfde combinatie van sleutel en nonce voor verschillende gegevens kan de beveiliging in gevaar brengen.
Voor de gebruiker betekent dit praktisch: de aanduiding ‘AES-256’ alleen is niet genoeg. Ook de specificaties voor sleutelbeheer, willekeurige generatie, bestandsvalidatie en foutafhandeling moeten worden bekeken. Een wijziging van één byte moet ertoe leiden dat een ongeldig bestand wordt geweigerd, niet dat gemanipuleerde inhoud als een intact bestand wordt getoond.
Wat zien de ontvanger, de server en de galerij-app?
| Locatie | Beveiligingsvraag |
|---|---|
| Bestandsopslagdienst | Heeft deze alleen versleutelde bytes, of heeft deze ook toegang tot de sleutel? |
| Bericht met de sleutel | Worden de sleutel, bestandsnaam en beschrijving beschermd in het E2EE-gesprek? |
| Apparaat van de ontvanger | Waar blijft het bestand na het openen: in het geheugen, de cache of de galerij? |
| Cloudback-up | Komt de opgeslagen kopie in de fotoback-up terecht, en hoe is die back-up beschermd? |
Versleuteling tijdens de overdracht beheerst niet de kopie die de ontvanger in de galerij opslaat. Controleer vóór het versturen van een gevoelig document ook onnodige delen van de afbeelding, tekst op de achtergrond en locatiegegevens van het bestand.
Wat is er anders aan een bestand in een privégroep?
Meer mensen mogen de sleutel bezitten. Livara beschrijft in LGS1 ondersteuning voor bijlagen in compatibele privégroepen in E2EE-modus; je mag die claim niet uitbreiden naar openbare kanalen. Elk lid dat het bestand heeft ontvangen, kan een kopie bewaren. Een lid verwijderen of toekomstige sleutels roteren haalt diens eerdere kopie niet terug.
Checklist voor het versturen van gevoelige bestanden
- Controleer de gespreksomgeving en de deelnemers opnieuw.
- Als de identiteit van je contact belangrijk is, verifieer dan de sleutelvingerafdruk via een vertrouwde weg.
- Stuur alleen noodzakelijke informatie; een volledige foto van een document is niet altijd nodig.
- Maak afspraken met de ontvanger over opslaan in de galerij, automatisch downloaden en cloudback-ups.
- Laat het ontsleutelde bestand niet achter op een gedeeld of ontgrendeld apparaat.
Veelgestelde vragen
Garandeert een eigen bestandssleutel dat versturen veilig is?
Nee. Ook veilige apparaten, authenticatie van de ontvanger en een correcte implementatie zijn noodzakelijk. Lees Livara’s dreigingsmodel naast de versleutelingsspecificaties.
Heeft een afbeelding in een openbaar kanaal dezelfde bescherming?
Volgens de door Livara beschreven grens zijn kanalen openbaar en leesbaar; er wordt daarvoor geen vertrouwelijkheid van privébijlagen beloofd.
Is alleen de bestandslink voldoende?
Dat hangt af van het ontwerp van de dienst. Beoordeel de link, de sleutel en de toegangsrechten afzonderlijk; een lange of willekeurige URL bewijst op zichzelf geen E2EE.
