End-to-end-kryptering utan kompromisser

End-to-end-kryptering är en av de funktioner som är lätta att lova men svåra att leverera korrekt. Många samarbetsplattformar hävdar att de erbjuder E2EE, men detaljerna i deras implementationer varierar enormt — och detaljerna är där säkerheten lever eller dör.

Den här artikeln förklarar hur Mandraki implementerar end-to-end-kryptering, de protokollval vi gjort och de kompromisser vi är transparenta om.

Vad end-to-end-kryptering egentligen betyder

I ett system med end-to-end-kryptering krypteras meddelanden och media på avsändarens enhet och kan bara dekrypteras på mottagarnas enheter. Servern som vidarebefordrar data ser bara krypterad text. Den kan inte läsa innehållet, även om den tvingas att göra det av en domstol, en obehörig anställd eller en säkerhetsöverträdelse.

Detta är grundläggande annorlunda än transportkryptering (TLS), som skyddar data under överföring mellan en klient och en server men lämnar servern med åtkomst till klartext. Det är också annorlunda än kryptering i vila, som skyddar data på disk men lämnar programvarulagret med åtkomst till klartext under bearbetning.

Sann E2EE innebär att servern är obehörig i grunden. Den är en vidarebefordrare, inte en läsare.

MLS-protokollet för meddelanden

För krypterade meddelanden använder vi Messaging Layer Security (MLS)-protokollet, standardiserat som RFC 9420 av IETF. MLS utformades specifikt för gruppmötesscenarier och erbjuder flera fördelar jämfört med äldre tillvägagångssätt.

MLS använder en trädstrukturerad nyckelöverenskommelse som kallas TreeKEM, som tillåter en grupp av deltagare att etablera en delad hemlighet effektivt. När en medlem går med i eller lämnar en grupp uppdateras nyckelmaterialet genom en Commit-meddelande som främjar gruppens epok. Detta ger framåtriktad sekretess — att kompromettera en medlems nycklar vid en given tidpunkt avslöjar inte meddelanden från tidigare epoker — och efterkompromiss-säkerhet — gruppen återställer säkerheten efter en överträdelse så snart den drabbade medlems nyckelmateriel roteras.

Varje användarenhet laddar upp MLS-nyckelpaket till servern. Dessa är engångskryptografiska paket som tillåter andra enheter att lägga till dem i en grupp utan att kräva att enheten är online vid den tidpunkten. När ett nyckelpaket konsumeras måste enheten ladda upp färska paket. Servern lagrar och distribuerar dessa paket men har aldrig åtkomst till den privata nyckelmaterialet de innehåller.

MLS-grupper i Mandraki motsvarar kanaler och direktmeddelandetrådar. När du skickar ett meddelande i en krypterad kanal krypterar din klient det med gruppens aktuella epoknyckel. Servern tar emot krypterad text, lagrar den och distribuerar den till gruppmedlemmarna. Deras klienter dekrypterar den lokalt.

SFrame för mediekryptering

Att kryptera realtidsmedia — ljud och video i ett gruppsamtal — presenterar olika utmaningar jämfört med meddelanden. Latenstoleransen mäts i millisekunder, inte sekunder. Datahastigheterna är flera storleksordningar högre. Och mediet passerar genom en Selective Forwarding Unit (SFU), som behöver vidarebefordra paket till rätt deltagare utan att kunna se innehållet.

Vi använder SFrame (RFC 9605) för mediekryptering, tillämpat via WebRTC Encoded Transform API. Detta API tillåter JavaScript-kod att avlyssna kodade mediefiler efter kodning men före paketering, kryptera dem och skicka krypterad text till transportlagret. På mottagarsidan dekrypteras ramarna efter återmontering men före avkodning.

Fördelen med SFrame i en SFU-arkitektur är att SFU fortfarande kan utföra sin vidarebefordringsfunktion — vidarebefordra paket från en deltagare till andra, fatta bandbreddsadaptiva beslut om vilka lager som ska vidarebefordras — utan att någonsin ha åtkomst till medieinnehållet i klartext. SFU ser krypterade ramar och vidarebefordrar dem som opaka blobbar.

De kompromisser vi är ärliga om

End-to-end-kryptering är inte gratis. Den introducerar verkliga begränsningar som vi tror är värda att erkänna.

Server-sidig sökning fungerar inte för E2EE-innehåll. Om meddelanden krypteras med nycklar som servern inte har, kan servern inte indexera dem för sökning. Mandraki hanterar detta genom att underhålla en lokal krypterad sökindex på klienten med hjälp av IndexedDB. Detta ger sökning per enhet men stöder inte sökhistorik över enheter för meddelanden som mottagits före en enhet lades till i gruppen.

Serverbaserade AI-funktioner är ömsesidigt uteslutande med E2EE. Våra AI-transkriptions- och sammanfattningfunktioner kräver serverbaserad åtkomst till ljud i klartext. Ett samtal eller en kanal kan inte ha både E2EE och AI-funktioner aktiverade samtidigt. Detta genomförs arkitektoniskt, inte bara genom policy. Organisationer väljer på samtal- eller kanalnivå vilken modell de föredrar.

Nya enheter ser meddelanden endast från anslutningspunkten och framåt. När du lägger till en ny enhet till ditt konto kan den dekryptera meddelanden från den tidpunkt den ansluter till MLS-gruppen och framåt. Historiska meddelanden som krypterats under tidigare epoker är inte tillgängliga på den nya enheten. Detta är en grundläggande egenskap hos framåtriktad sekretess. Vi undersöker säkra säkerhetskopieringsmekanismer som skulle tillåta användare att exportera krypterad meddelandehistorik till en ny enhet, men detta förblir ett pågående arbete.

Nyckelhantering lägger till komplexitet. Varje enhet måste underhålla nyckelmateriel, ladda upp färska nyckelpaket och bearbeta gruppstatusuppdateringar. Vi investerar betydande ingenjörsinsatser i att göra detta osynligt för användare. Målet är att kryptering inte är något du konfigurerar eller tänker på — den sker helt enkelt.

E2EE och serverbaserad kryptering samexisterar

Mandrakis E2EE-lager och vår serverbaserade kuvertkryptering (den trelagrade nyckelhierarkin som beskrivs i vår säkerhetsarkitektur) tjänar kompletterande syften. Serverbaserad kryptering skyddar data i vila på vår infrastruktur — om en disk stjäls eller en databasbackup komprometteras, är data oläsliga utan krypteringsnycklarna. E2EE går längre genom att säkerställa att servern aldrig ser klartext från början.

För organisationer som aktiverar E2EE är båda lagren aktiva samtidigt. Data krypteras end-to-end av klienterna och krypteras också i vila på servern. Bälte och byxor.

Vi tror att end-to-end-kryptering bör vara standard för känsliga kommunikationer, inte en premiumfunktion eller en kryssruta som de flesta användare aldrig hittar. Mandraki gör det enkelt att aktivera, transparent i dess begränsningar och robust i sin implementation.