Een hack van een chatserver betekent niet noodzakelijk dat alle berichten worden gelezen. Het resultaat hangt af van de opgeslagen gegevens, de locatie van de sleutels en het toegangsniveau van de aanvaller. Ook als de chattekst correct end-to-end is versleuteld, kunnen accountgegevens, tijdstippen, groepslidmaatschap en bezorgroutes gevoelig zijn.
Vraag bij de beoordeling van een incident eerst wat de aanvaller heeft bemachtigd: een databasekopie, infrastructuursleutels, een actieve server of het softwarepublicatiesysteem? Deze scenario’s hebben niet dezelfde gevolgen.
Een gestolen database is niet hetzelfde als een server onder controle
Een aanvaller met alleen een oude databasekopie is beperkt tot de daarin vastgelegde gegevens. Controle over de live dienst kan het mogelijk maken nieuwe gegevens te registreren, sessies te stelen, antwoorden te wijzigen of te proberen de sleutel van een contact te vervangen. Toegang tot de softwarepublicatieketen vormt een ander risico: kwaadaardige code op een eindpunt kan de tekst vóór versleuteling of na ontsleuteling zien.
De bewering «de database bevat geen sleutel voor de berichttekst» is dus belangrijk, maar geen volledig antwoord op alle soorten inbraak.
Vijf architectuurpatronen vergeleken
Dit zijn educatieve patronen, geen ranglijst van vijf producten. Eén dienst kan voor verschillende functies meerdere patronen gebruiken.
| Patroon | Gegevens toegankelijk via de database | Belangrijke grens |
|---|---|---|
| Berichten en wachtwoorden in leesbare vorm | Inhoud en inloggegevens zijn direct leesbaar | Ontbrekende passende bescherming voor beide soorten gegevens |
| Gehashte wachtwoorden, leesbare berichten | Inhoud is leesbaar; wachtwoordgissingen kunnen mogelijk worden getest | De kwaliteit van wachtwoordopslag beschermt de chattekst niet |
| Inhoud versleuteld met een serversleutel | Versleutelde tekst; leesbaarheid hangt af van toegang tot de sleutel | Werkelijke scheiding tussen sleutel en gegevens is belangrijk |
| E2EE-chat met een voor de aanbieder toegankelijke back-up | De live chat kan beschermd zijn, maar de geschiedeniskopie heeft een afzonderlijke blootstellingsroute | Back-upbeleid en -sleutel moeten worden onderzocht |
| E2EE-chat met versleuteld herstel en een onafhankelijke sleutel | Versleutelde tekst en operationele gegevens; inhoudsbescherming hangt af van ontwerp en sleutelbescherming | Apparaat, herstelzin en verificatie van contacten blijven belangrijk |
Versleuteling van de serverschijf helpt tegen diefstal van een ruwe schijf. Als de aanvaller ook de actieve dienst of de ontsleutelingssleutel bezit, mag dezelfde bescherming niet worden verondersteld. Bij E2EE is het doel dat de tussenliggende dienst niet beschikt over de sleutel om beschermde inhoud te lezen.
Wat onthullen metadata?
Metadata kunnen laten zien welke accounts contact hadden, wanneer ze actief waren, van welke groepen ze lid zijn en hoeveel gegevens zijn uitgewisseld. Deze informatie is niet de berichttekst, maar is waardevol voor inzicht in communicatienetwerken of activiteitspatronen.
De beveiligingspagina van Livara beschrijft expliciet de opslag en verwerking van operationele gegevens, waaronder routering, lidmaatschap, tijdstippen, grootte van versleutelde tekst en bezorgstatus. Vertrouwelijkheid van privé-inhoud mag niet worden opgevat als volledige anonimiteit of afwezigheid van alle gegevens op de server.
SRP vrijwaart accountgegevens niet van wachtwoordgissingen
SRP is een methode om kennis van een wachtwoord te bewijzen zonder het wachtwoord zelf rechtstreeks te versturen. De server bewaart nog steeds verificatiegegevens, een zogeheten verifier. Het beveiligingsonderdeel van RFC 5054 legt uit dat diefstal van de verifier een woordenboekaanval om het wachtwoord te raden mogelijk kan maken.
«Het wachtwoord wordt niet over het netwerk verstuurd» is dus iets anders dan «er bestaan geen wachtwoordgerelateerde gegevens om te stelen». Een uniek, sterk wachtwoord, apparaatbescherming en een passende incidentrespons blijven nodig. SRP vervangt ook geen inhoudsversleuteling of bescherming van inlogsessies.
Welke grenzen beschrijft Livara?
De beveiligingsdocumentatie van Livara beschrijft LVR1 voor directe berichten en LGS1 voor beschermde groepen. Groepsbescherming hangt af van de werkelijke status; een oudere incompatibele groep mag geen E2EE-label krijgen. Openbare kanalen vallen buiten deze vertrouwelijkheidsgrens.
Hetzelfde document beschrijft v7-herstel als een versleuteld identiteitspakket dat vóór het uploaden wordt beschermd. Dit proces herstelt de cryptografische identiteit, niet de chatgeschiedenis. Blootstelling van de herstelzin of het apparaat met de sleutels is een ander scenario dan uitsluitend diefstal van de database.
Dit zijn gepubliceerde productbeschrijvingen, geen resultaten van een onafhankelijke audit door dit artikel. Ook het noemen van AES of ML-KEM bewijst op zichzelf niet dat sleutelbeheer en app-implementatie correct zijn.
Welke vragen stel je bij een incidentmelding?
- Welke periode en welke systemen zijn getroffen? De vage term «gebruikersgegevens» is niet voldoende.
- Waren leesbare tekst, bestanden, sleutels, verifiers, inlogsessies of alleen versleutelde tekst toegankelijk?
- Kon de aanvaller de dienst of de aan gebruikers geleverde software wijzigen?
- Welke acties zijn via de officiële route nodig: sessies beëindigen, wachtwoord wijzigen, bijwerken of de identiteit van contacten controleren?
- Kan het hersteladvies de lokale geschiedenis wissen? Lees de beperkingen voordat je de app verwijdert.
Gebruik geen link uit een anoniem bericht om «je account onmiddellijk te verifiëren». Open de melding zelfstandig via het officiële adres. Livara’s dreigingsmodel helpt om algemene grenzen te begrijpen; de omvang van een werkelijk incident moet worden bepaald met bewijs uit dat incident.
