Vraag bij gespreksbeveiliging niet alleen ‘is het versleuteld?’, maar ook waar de versleuteling eindigt en wat opnemen verandert.
Versleuteling van een chat bewijst op zichzelf niet dat audio, video, schermdeling of gespreksopnamen dezelfde bescherming krijgen. Om de beveiliging van een gesprek te beoordelen, moet je vragen tot waar de media versleuteld blijven, wie de sleutel heeft en wat er verandert als functies zoals opnemen worden ingeschakeld.
Deze gids verdeelt beveiligingsclaims in controleerbare lagen; de naam van een protocol of een slotpictogram vervangt de antwoorden op deze vragen niet.
Drie verschillende routes in één app
| Route | Voorbeelden van gegevens | Beveiligingsvraag |
|---|---|---|
| Opgeslagen berichten | Tekst, foto's, bestanden en spraakberichten | Wie kan de kopieën op het apparaat, op de server en in de back-up lezen? |
| Livemedia | Microfoongeluid, video en schermdeling | Eindigt de versleuteling op het apparaat van de gesprekspartner of op een tussenliggende server? |
| Signalering | Gespreksuitnodigingen, antwoorden en informatie om de verbinding tot stand te brengen | Wie kan controleberichten of de identiteit van de beoogde ontvanger wijzigen? |
Een spraakbericht dat via de chat wordt verstuurd, is een bestand; een audiogesprek is een livestream. Een product kan hiervoor verschillende sleutels en mechanismen gebruiken. Een goede geluidskwaliteit of het niet aankomen van een tekstbericht zegt op zichzelf evenmin iets over de beveiliging van de andere route.
Wat toont DTLS-SRTP aan?
In WebRTC beschermt SRTP de mediastroom en is DTLS-SRTP een manier om het bijbehorende sleutelmateriaal tot stand te brengen. RFC 5764 beschrijft het DTLS-SRTP-mechanisme en RFC 3711 de bescherming van mediapakketten.
Maar de uitspraak ‘wij gebruiken WebRTC’ beantwoordt op zichzelf niet de vraag of de conferentieserver de media ontsleutelt. De eindpunten van de versleuteling en hun authenticatie moeten duidelijk zijn. De verbinding tussen gebruiker en server kan versleuteld zijn, terwijl de server voor verwerking of opname toegang heeft tot de ontsleutelde inhoud. Dat is niet hetzelfde als E2EE tussen de deelnemers.
De WebRTC-beveiligingsarchitectuur in RFC 8827 laat ook zien dat vertrouwen in de webapp, de signaleringsroute en de identiteit van de gesprekspartner naast de bescherming van media van belang zijn. Versleutelde pakketten betekenen niet dat alle onderdelen van het product betrouwbaar zijn.
Waarom moet signalering afzonderlijk worden beoordeeld?
Signalering coördineert wie met wie belt en hoe de verbinding tot stand komt. Als een app controleberichten beschermt, moet nog steeds worden onderzocht hoe die bescherming is gekoppeld aan de werkelijke identiteit van de deelnemers en de mediasleutels.
Drie vragen volstaan om de documentatie te lezen:
- Zijn de uitnodiging, het antwoord en de sleutelinformatie beschermd tegen wijzigingen?
- Hoe weet de gebruiker dat de sleutel bij de bedoelde gesprekspartner hoort?
- Welke waarschuwing verschijnt als de sleutel of het apparaat verandert?
Informatie over de routering, het tijdstip en de deelnemers van een gesprek kan zelfs bij een E2EE-gesprek bekend zijn bij de dienst. De uitleg over metadata van berichtenapps gaat op dit verschil in.
Gespreksopnamen vormen een nieuwe beveiligingsgrens
‘Versleuteld gesprek’ geeft geen volledig antwoord over de opgenomen versie. Een deelnemer kan met het eigen apparaat audio of video vastleggen. Ook opname aan de serverzijde moet afzonderlijk worden gedocumenteerd: krijgt de server voor de opname toegang tot onversleutelde media? Wie bewaart het bestand? Wanneer wordt het verwijderd?
Als het inschakelen van de opname de beveiligingsmodus verandert, moet die verandering voor de deelnemers duidelijk zijn. Controleer vóór een gevoelig gesprek de opnamestatus en de toestemming van de deelnemers; als de ingebouwde opname-indicator uitstaat, garandeert dat niet dat niemand met een ander apparaat opneemt.
Hoe lees je de huidige documentatie van Livara?
De beveiligingspagina van Livara beschrijft directe en groepsgesprekken als E2EE, maar maakt een uitzondering voor optionele opname aan de serverzijde: in de zichtbare REC-modus gaat de bescherming van het gesprek over op transportversleuteling. Dit is een claim uit de productdocumentatie, geen resultaat van een onafhankelijke test of audit in dit artikel.
De beperking van alle groepsgesprekken tot ‘2 tot 6 personen op Android’ in de oude tekst is niet in overeenstemming met de huidige documentatie en vormt geen uitgangspunt voor deze gids. Voor de capaciteit, het platform en de gewenste versie moeten de actuele handleiding en het werkelijke gedrag van de app worden bekeken; dit artikel bevat geen capaciteitstest.
Ook de naam van chatalgoritmen zoals ML-KEM bewijst op zichzelf niet dat hetzelfde algoritme voor gespreksmedia wordt gebruikt. Voor de claim dat een gesprek postkwantumbeveiliging heeft, is specifiek bewijs voor de mediaroute en authenticatie nodig. Lees het dreigingsmodel van Livara naast de functiepagina, niet als vervanging voor een onafhankelijke test.
Korte checklist voordat je twee diensten vergelijkt
Noteer bij elk antwoord ‘ja’ ook de versie en de bron:
- Zijn één-op-ééngesprekken, groepsgesprekken en schermdeling afzonderlijk beschreven?
- Is duidelijk of de server alleen pakketten doorstuurt of de media ook kan ontsleutelen?
- Kunnen de identiteit en de sleutel van een deelnemer worden gecontroleerd?
- Zijn een apparaatwissel, het toevoegen van een deelnemer en het inschakelen van een opname zichtbaar?
- Is de gespreksroute op het web en in de app hetzelfde, of zijn er verschillen?
- Is uitgelegd hoe opgenomen bestanden en metadata worden bewaard?
- Heeft het bewijs uit tests of audits betrekking op dezelfde versie en functie?
Staat het antwoord niet in de documentatie, schrijf dan ‘onbekend’; het ontbreken van een antwoord bewijst noch dat de dienst veilig is, noch dat er wordt afgeluisterd.
Veelgestelde vragen
Voorkomt een E2EE-gesprek dat de gesprekspartner een opname maakt?
Nee. De bevoegde ontvanger heeft toegang tot de onversleutelde inhoud en kan die met software of een ander apparaat opnemen.
Is transportversleuteling slecht?
Transportversleuteling biedt belangrijke bescherming tegen afluisteren onderweg. Het verschil is dat de dienst die het eindpunt vormt toegang kan hebben tot de ontsleutelde inhoud; dat mag geen E2EE tussen gebruikers worden genoemd.
Maakt postkwantumversleuteling in de chat ook gesprekken postkwantumveilig?
Nee. De claim moet betrekking hebben op dezelfde laag, algoritmen en implementatieversie. Beoordeel chat en gesprekken afzonderlijk.
