Een schijfkopie, live controle over de server en toegang tot een telefoon zijn drie verschillende scenario’s; één algemene garantie volstaat niet voor alle drie.
Als een berichtenserver wordt overgenomen, hangt het precieze antwoord op “wat wordt openbaar?” af van de opgeslagen gegevens, de locatie van de sleutels en het soort toegang van de aanvaller. Een kopie van een schijf bemachtigen is niet hetzelfde als live controle over de dienst en het distributiepad van de app.
Dit artikel onderzoekt een hypothetisch scenario op basis van de openbare documentatie van Livara. Het doet geen uitspraken over de locatie van Livara-datacenters, een daadwerkelijke inbeslagname of gegarandeerde werking van de dienst tijdens een internetstoring. Inhoudsversleuteling, netwerkbeschikbaarheid en infrastructuurbeveiliging zijn afzonderlijke onderwerpen.
Bepaal eerst het soort toegang
Opgeslagen serverkopie: de aanvaller krijgt toegang tot de bestanden, database of back-ups die in die kopie aanwezig zijn. Als privé-inhoud correct op het apparaat is versleuteld en de server niet over de ontsleutelingssleutel beschikt, onthult alleen het bezit van die kopie de gesprekstekst niet.
Actieve controle over de dienst: naast het lezen van bestaande gegevens kan de aanvaller bepaalde verzoeken blokkeren, oude gegevens terugsturen of het gedrag van gecontroleerde onderdelen veranderen. Controle van de identiteit van de gesprekspartner, versiecontrole en de integriteit van de client worden in dit scenario belangrijker.
Gelijktijdige toegang tot het apparaat: een ontgrendelde telefoon, malware of een leesbare kopie bij een deelnemer kan de inhoud langs een heel andere weg onthullen. Ook het dreigingsmodel van Livara garandeert geen bescherming van een ontgrendeld of besmet apparaat.
Welke gegevens zijn volgens de Livara-documentatie zichtbaar op de server?
De beveiligingspagina van Livara, met versielabel 0.1.68, onderscheidt de inhoud van directe chats onder LVR1 en compatibele privégroepen onder LGS1 van operationele informatie. Dezelfde pagina stelt expliciet dat oudere, incompatibele groepen buiten E2EE blijven; controleer daarom de status van het betreffende gesprek.
| Gegevenscategorie | Gedocumenteerde grens en mogelijk gevolg |
|---|---|
| Tekst en bijlagen van een beschermd gesprek | De server bewaart de versleutelde kopie; lezen vereist de juiste sleutel |
| Communicatiemetadata | Informatie zoals deelnemers, tijd, grootte en afleverstatus is beschikbaar voor de dienst |
| Groepslidmaatschap | Maakt deel uit van de operationele informatie en bevoegdheden van de server |
| Openbaar kanaal | De inhoud is openbaar en leesbaar voor de server |
| v7-pakket voor identiteitsherstel | Wordt vóór het uploaden versleuteld en vereist een apart herstelgeheim |
| Optionele serveropnamemodus | Wordt met REC onderscheiden van E2EE; end-to-endprivacy mag hiervoor niet worden verondersteld |
De documentatie noemt LSS1-code voor metadatabescherming, maar die is niet aangesloten op gewone berichtverzending. Een protocolnaam in een project bewijst niet dat het protocol in alle communicatie actief is.
Deze tabel beschrijft productclaims, niet de resultaten van een echte inbeslagnametest of een onafhankelijke audit van alle databasekopieën.
Hoe belangrijk kunnen metadata zijn?
Informatie over contacten tussen mensen, tijdstippen en groepslidmaatschappen kan ook zonder berichttekst gevoelig zijn. Toch is “de volledige communicatiegrafiek wordt voorgoed onthuld” niet nauwkeurig zonder kennis van bewaartermijnen, logdekking en de verkregen gegevenskopie.
Voor een echte beoordeling moet worden gevraagd welke velden zijn verzameld, hoelang ze zijn bewaard en welke back-ups toegankelijk zijn. Inhoudsversleuteling alleen bepaalt geen bewaarbeleid. Evenmin kan uit de architectuur van één berichtendienst worden afgeleid dat alle berichtendiensten noodzakelijkerwijs dezelfde metadata bewaren.
Welk risico vormt servercontrole voor toekomstige berichten?
Bij een beveiligingsonderzoek moeten manipulatie van ledenlijsten, het aanbieden van een andere identiteitssleutel, het verhinderen van updates en het leveren van een kwaadaardige client afzonderlijk worden getest. Het effect hangt af van validatie aan de clientzijde, de zichtbaarheid van veranderingen en identiteitsverificatie.
Zonder implementatietests kan niet worden gesteld dat elke overgenomen server zeker een verborgen lid kan toevoegen; evenmin dat actieve servercontrole geen enkel effect heeft. Bij gevoelige gesprekken moeten onverwachte veranderingen in identiteit of leden worden onderzocht. Een sleutelvingerafdruk met de gesprekspartner vergelijken via een onafhankelijk, vertrouwd kanaal geeft meer informatie dan alleen vertrouwen op een weergavenaam.
Als de aanvaller de code verandert die op het apparaat draait, kan die de tekst mogelijk vóór de versleuteling zien. Daarom maakt beveiliging van appdistributie en updates deel uit van dit scenario en staat die niet los van cryptografie.
Wat voegt postkwantumbeveiliging toe?
De norm NIST FIPS 203 voor ML-KEM helpt bij het tot stand brengen van een gedeeld geheim. Correct gebruik in een hybride combinatie kan het risico van bepaalde toekomstige aanvallen op sleuteluitwisseling verkleinen. Dit vervangt geen apparaatbeveiliging, beperkte bewaring van metadata of toegangscontrole op de server.
Ook Proof Lab toont slechts enkele lokale P-256-, HKDF- en AES-GCM-bewerkingen en rekent de volledige LVR1/LGS1-combinatie niet tot die test. Een geslaagd resultaat garandeert niet dat het hele product bestand is tegen overname van de infrastructuur.
Wat te doen bij een beoordeling of een echt incident?
- Leg het soort toegang en bevestigde informatie vast; stel een gerucht over een storing niet gelijk aan een vastgesteld beveiligingsincident.
- Controleer de appversie en de versleutelingsstatus van het betreffende gesprek.
- Onderzoek identiteitsveranderingen, groepsleden en onbekende sessies via officiële kanalen.
- Geef herstelgeheimen, wachtwoorden en privé-inhoud niet aan onbekenden voor een “beveiligingscontrole”.
- Raadpleeg bij ernstig gevaar of juridische kwesties een geschikte deskundige en neem geen onomkeerbare maatregelen op basis van één artikel.
Een betrouwbare conclusie moet aangeven welke gegevens, in welke versie en tegen welk soort toegang beschermd zijn. “Zelfs als de server in beslag wordt genomen, gebeurt er niets” is geen vervanging voor dat antwoord.
