End-to-End-versleuteling zonder compromis
Hoe Mandraki end-to-end-versleuteling implementeert met het MLS-protocol voor berichten en SFrame voor media, zonder bruikbaarheid op te offeren.
Opmerking: Dit artikel beschrijft Mandraki’s architectuur en ontwerp. Sommige besproken functies worden geleidelijk uitgerold en zijn mogelijk niet in alle abonnementen beschikbaar.
End-to-end-versleuteling is een van die functies die gemakkelijk te beloven en moeilijk goed af te leveren is. Veel samenwerkingsplatformen beweren E2EE aan te bieden, maar de details van hun implementaties verschillen enorm — en de details zijn waar beveiliging leeft of sterft.
Dit artikel legt uit hoe Mandraki end-to-end-versleuteling implementeert, de protocolkeuzes die we hebben gemaakt en de compromissen die we transparant zijn.
Wat end-to-end-versleuteling werkelijk betekent
In een systeem met end-to-end-versleuteling worden berichten en media versleuteld op het apparaat van de afzender en kunnen alleen worden ontsleuteld op de apparaten van de ontvangers. De server die de gegevens doorgeeft ziet alleen ciphertext. Het kan de inhoud niet lezen, zelfs niet als het onder dwang van een gerechtsbevel, een rogue werknemer of een beveiligingsovertoon zou worden.
Dit verschilt fundamenteel van transportversleuteling (TLS), die gegevens in transit beschermt tussen een client en een server maar de server met toegang tot leesbare tekst achterlaat. Het verschilt ook van versleuteling in rust, die gegevens op schijf beschermt maar de applicatielaag met toegang tot leesbare tekst laat tijdens verwerking.
Waar E2EE betekent dat de server per ontwerp niet wordt vertrouwd. Het is een doorvoer, geen lezer.
Het MLS-protocol voor berichten
Voor versleutelde berichten gebruiken we het Messaging Layer Security-protocol (MLS), gestandaardiseerd als RFC 9420 door de IETF. MLS was specifiek ontworpen voor scenario’s met groepsberichten en biedt verschillende voordelen ten opzichte van oudere benaderingen.
MLS gebruikt een op bomen gebaseerde sleutelovereenkomststructuur genaamd TreeKEM, waarmee een groep deelnemers efficiënt een gedeeld geheim kunnen vaststellen. Wanneer een lid een groep betreedt of verlaat, wordt het sleutelmateriaal bijgewerkt via een Commit-bericht dat de groepsepoche van de groep voortgang. Dit biedt forward secrecy — het compromis van de sleutels van een lid op een bepaald moment onthult geen berichten van eerdere epochen — en post-compromisbeveiliging — de groep herstelt beveiliging na een compromis zodra het sleutelmateriaal van het betrokken lid wordt geroteerd.
Elk gebruikersapparaat laadt MLS-sleutelpakketten op. Dit zijn eenmalig-gebruik cryptografische bundels waarmee andere apparaten hen aan een groep kunnen toevoegen zonder dat het apparaat op dat moment online hoeft te zijn. Wanneer een sleutelpakket wordt verbruikt, moet het apparaat verse uploaden. De server slaat deze pakketten op en verspreidt deze, maar heeft nooit toegang tot het persoonlijke sleutelmateriaal dat ze bevatten.
MLS-groepen in Mandraki kaarten naar kanalen en directe bericht-threads. Wanneer u een bericht in een versleuteld kanaal verzendt, versleutelt uw client het met behulp van de huidige groepsepochesleutel. De server ontvangt ciphertext, slaat het op en verspreidt het naar groepsleden. Hun clients ontsleutelen het lokaal.
SFrame voor mediaversleuteling
Het versleutelen van realtime media — audio en video in een groepsgesprek — presenteert andere problemen dan berichten. Latentietolerantie wordt gemeten in milliseconden, niet seconden. De gegevenssnelheden zijn orden van grootte hoger. En de media gaat door een Selective Forwarding Unit (SFU), die pakketten naar de juiste deelnemers moet doorsturen zonder de inhoud te zien.
We gebruiken SFrame (RFC 9605) voor mediaversleuteling, toegepast via de WebRTC Encoded Transform API. Deze API stelt JavaScript-code in staat gecodeerde mediaframes na codering maar vóór verpakking te onderscheppen, ze te versleutelen en de ciphertext aan de transportlaag door te geven. Aan de ontvangende zijde worden de frames na herassemblage maar vóór decodering ontsleuteld.
Het belangrijkste voordeel van SFrame in een SFU-architectuur is dat de SFU nog steeds zijn routeringsfunctie kan uitvoeren — pakketten van een deelnemer naar anderen doorsturen, bandbreedteadaptieve beslissingen nemen over welke lagen door te sturen — zonder ooit toegang tot de leesbare media te hebben. De SFU ziet versleutelde frames en stuurt ze als ondoorzichtige blobs door.
De compromissen waarvoor we eerlijk zijn
End-to-end-versleuteling is niet gratis. Het brengt echte beperkingen mee die we geloven het waard zijn om te erkennen.
Server-zijde zoeking is niet mogelijk op E2EE-inhoud. Als berichten worden versleuteld met sleutels die de server niet houdt, kan de server er niet op indexeren voor zoeken. Mandraki richt dit op door een lokale versleutelde zoekindex op de client te onderhouden met IndexedDB. Dit biedt per-apparaatzoeking maar ondersteunt niet crossapparaat-zoekgeschiedenis voor berichten ontvangen voordat een apparaat aan de groep werd toegevoegd.
Server-zijde AI-functies zijn wederzijds exclusief met E2EE. Onze AI-transcriptie en samenvattingsfuncties vereisen server-zijde toegang tot leesbare audio. Een oproep of kanaal kan niet beide E2EE en AI-functies tegelijk hebben ingeschakeld. Dit wordt architecturaal afgedwongen, niet alleen door beleid. Organisaties kiezen op oproep- of kanaalniveau welk model ze liever hebben.
Nieuwe apparaten zien berichten alleen van aansluitingspunt voorwaarts. Wanneer u een nieuw apparaat aan uw account toevoegt, kan het berichten ontsleutelen vanaf het moment waarop het de MLS-groep betreedt. Historische berichten versleuteld onder eerdere epochen zijn niet toegankelijk op het nieuwe apparaat. Dit is een fundamenteel eigendom van forward secrecy. We verkennen beveiligde back-upmechanismes die gebruikers in staat zouden stellen versleutelde berichtgeschiedenis naar een nieuw apparaat uit te voeren, maar dit blijft onderhanden.
Sleutelbeheer voegt complexiteit toe. Elk apparaat moet sleutelmateriaal onderhouden, verse sleutelpakketten uploaden en groepsstatusupdate verwerken. We investeren aanzienlijke engineeringmoeite in het onzichtbaar maken hiervan voor gebruikers. Het doel is dat versleuteling niet iets is dat u configureert of over nadenkt — het gebeurt eenvoudig.
E2EE en server-zijde versleuteling coëxisteren
Het is de moeite waard op te merken dat Mandraki’s E2EE-laag en onze server-zijde envelopversleuteling (de drielaagse sleutelhiërarchie beschreven in onze beveiligingsarchitectuur) aanvullende doeleinden dienen. Server-zijde versleuteling beschermt gegevens in rust op onze infrastructuur — als een schijf wordt gestolen of een databasebackup wordt gecompromitteerd, zijn de gegevens zonder de versleutelingssleutels onleesbaar. E2EE gaat verder door ervoor te zorgen dat de server in de eerste plaats nooit leesbare tekst ziet.
Voor organisaties die E2EE inschakelen, zijn beide lagen tegelijk actief. Gegevens worden end-to-end door de clients versleuteld en ook in rust op de server versleuteld. Riem en bretels.
We geloven dat end-to-end-versleuteling de standaard voor gevoelige communicatie zou moeten zijn, niet een betaald extra of een selectievakje dat de meeste gebruikers nooit vinden. Mandraki maakt het eenvoudig in te schakelen, transparant in zijn beperkingen en robuust in zijn implementatie.