End-to-end-kryptering uden kompromis

Bemærk: Denne artikel beskriver Mandraki’s arkitektur og design. Nogle funktioner, der diskuteres, bliver implementeret progressivt og er muligvis ikke endnu tilgængelige i alle planer.

End-to-end-kryptering er en af disse funktioner, der er let at love og svær at levere ordentligt. Mange samarbejdsplatforme hævder at tilbyde E2EE, men detaljerne i deres implementeringer varierer enormt — og detaljerne er der, hvor sikkerhed lever eller dør.

Dette indlæg forklarer, hvordan Mandraki implementerer end-to-end-kryptering, protokolvalget, vi gjorde, og de trade-offs, vi er transparente omkring.

Hvad end-to-end-kryptering faktisk betyder

I et system med end-to-end-kryptering bliver beskeder og medier krypteret på afsenderens enhed og kan kun dekrypteres på modtagernes enheder. Serveren, der relayerer dataene, ser kun ciphertext. Den kan ikke læse indholdet, selv hvis tvunget til det af en domstol, en ondsindet medarbejder eller en sikkerhedsbrud.

Dette er grundlæggende forskelligt fra transport-kryptering (TLS), som beskytter data i transit mellem en klient og en server, men forlader serveren med adgang til klartekst. Det er også forskelligt fra lagring-i-hvile-kryptering, som beskytter data på disk, men forlader applikationslaget med adgang til klartekst under behandling.

Ægte E2EE betyder, at serveren ikke er pålidelig efter design. Det er et relay, ikke en læser.

MLS-protokollen til beskeder

For krypteret beskeder bruger vi Messaging Layer Security-protokollen (RFC 9420) standardiseret af IETF. MLS blev specifikt designet til gruppe-beskeds-scenarier og tilbyder flere fordele frem for ældre tilgange.

MLS bruger en træ-baseret nøgle-aftale-struktur kaldet TreeKEM, som tillader en gruppe af deltagere at etablere en delt hemmelighed effektivt. Når et medlem tilslutter sig eller forlader en gruppe, opdateres nøgle-materialet gennem en Commit-meddelelse, der fremskrider gruppens epoke. Dette giver fremadrettet hemmelighed — at kompromittere en medlems nøgler på et punkt i tiden afslører ikke beskeder fra tidligere epoker — og post-kompromis-sikkerhed — gruppen genvinder sikkerhed efter et kompromis, så snart det pågældende medlems nøgle-materiale bliver roteret.

Hver bruger-enhed uploader one-time-use-nøgle-pakker til serveren. Disse er éngangs-kryptografiske bundter, der tillader andre enheder at tilføje dem til en gruppe uden at kræve, at enheden er online på det tidspunkt. Når en nøgle-pakke forbruges, skal enheden uploade friske. Serveren lagrer og distribuerer disse pakker, men har aldrig adgang til det private nøgle-materiale, de indeholder.

MLS-grupper i Mandraki kortlægges til kanaler og direkte besked-tråde. Når du sender en besked i en krypteret kanal, krypterer din klient den ved hjælp af gruppens aktuelle epoke-nøgle. Serveren modtager ciphertext, lagrer den og distribuerer den til gruppe-medlemmer. Deres klienter dekrypterer den lokalt.

SFrame til media-kryptering

At kryptere realtids-medier — lyd og video i et gruppe-opkald — præsenterer forskellige udfordringer end beskeder. Latens-tolerancen måles i millisekunder, ikke sekunder. Data-priserne er størrelses-orden højere. Og mediet passerer gennem en Selective Forwarding Unit (SFU), som skal dirigere pakker til de rigtige deltagere uden at kunne se indholdet.

Vi bruger SFrame (RFC 9605) til media-kryptering, applied via WebRTC Encoded Transform API. Denne API tillader JavaScript-kode at opfange kodede media-frames efter kodning, men før pakkemeddeling, kryptere dem og passere ciphertextet til transport-laget. På den modtagende ende, dekrypteres frames efter samling, men før dekodning.

Nøgle-fordelen ved SFrame i en SFU-arkitektur er, at SFU’en stadig kan udføre sin rute-funktion — viderestille pakker fra én deltager til andre, tage bånd-adaptive beslutninger om, hvilke lag der skal videresendes — uden at have adgang til klartekst-mediet. SFU’en ser krypterede frames og viderestiller dem som uigennemskinnelige klatter.

De trade-offs, vi er ærlige omkring

End-to-end-kryptering er ikke gratis. Det introducerer reelle begrænsninger, som vi mener er værd at erkende.

Server-side-søgning er ikke mulig på E2EE-indhold. Hvis beskeder bliver krypteret med nøgler, serveren ikke holder, kan serveren ikke indeksere dem for søgning. Mandraki håndterer dette ved at opretholde et lokalt krypteret søg-indeks på klienten ved hjælp af IndexedDB. Dette giver per-enhed-søgning, men understøtter ikke søgning på tværs af enheder-historik for beskeder modtaget, før en enhed blev tilføjet til gruppen.

Server-side-AI-funktioner er gensidigt udelukkende med E2EE. Vores AI-transskription og opsummerings-funktioner kræver server-side-adgang til klartekst-lyd. Et opkald eller kanal kan ikke have både E2EE og AI-funktioner aktiveret samtidigt. Dette håndhæves arkitektonisk, ikke blot efter politik. Organisationer vælger på opkalds- eller kanal-niveau, hvilken model de foretrækker.

Nye enheder ser beskeder kun fra tilslutnings-punkt og fremad. Når du tilføjer en ny enhed til din konto, kan den dekryptere beskeder fra det tidspunkt, det tilslutter sig MLS-gruppen og fremad. Historiske beskeder, der blev krypteret under tidligere epoker, er ikke tilgængelige på den nye enhed. Dette er en grundlæggende egenskab af fremadrettet hemmelighed. Vi udforsker sikker backup-mekanismer, der ville tillide brugere at eksportere krypteret besked-historik til en ny enhed, men det forbliver et igangværende arbejde.

Nøglestyrings-kompleksitet. Hver enhed må opretholde nøgle-materiale, uploade friske nøgle-pakker og behandle gruppe-stat-opdateringer. Vi investerer betydelig ingeniør-indsats i at gøre dette usynligt for brugere. Målet er, at kryptering ikke er noget, du konfigurerer eller tænker på — det sker simpelthen.

E2EE og server-side-kryptering eksisterer sammen

Det er værd at notere, at Mandraki’s E2EE-lag og vores server-side-envelope-kryptering (hierarkiet for trelags-nøgler beskrevet i vores sikkerhedsarkitektur) tjener komplementære formål. Server-side-kryptering beskytter data i hvile på vores infrastruktur — hvis en disk bliver stjålet eller en databasebackup bliver kompromitteret, er dataene uleselige uden kryptering-nøglerne. E2EE går længere ved at sikre, at serveren aldrig ser klartekst i første omgang.

For organisationer, der aktiverer E2EE, er begge lag aktive samtidigt. Data er krypteret end-to-end af klienterne og også krypteret i hvile på serveren. Både sikkerhed og mere.

Vi mener, at end-to-end-kryptering bør være standard-indstillingen for følsom kommunikation, ikke et premium-tilføjelse eller et felt, som de fleste brugere aldrig finder. Mandraki gør det ligetil at aktivere, transparent i dets begrænsninger og robust i dets implementering.