Criptare end-to-end fără compromis

Notă: Acest articol descrie arhitectura și designul Mandraki. Unele funcții discutate sunt în curs de implementare progresivă și pot să nu fie încă disponibile în toate planurile.

Criptarea end-to-end este una din acele funcții care este ușor de promis și dificil de livrat corect. Multe platforme de colaborare pretind că oferă E2EE, dar detaliile implementărilor lor variază enorm — și detaliile sunt locul unde trăiește sau moare securitatea.

Această postare explică cum implementează Mandraki criptarea end-to-end, alegerile de protocol pe care le-am făcut și compromisurile pe care suntem transparenți cu privire la ele.

Ce înseamnă cu adevărat criptarea end-to-end

Într-un sistem cu criptare end-to-end, mesajele și media sunt criptate pe dispozitivul expeditorului și pot fi decriptate doar pe dispozitivele destinatarilor. Serverul care retransmite datele vede doar ciphertext. Nu poate citi conținutul, chiar dacă este obligat să facă aceasta de o hotărâre judecătorească, un angajat necinstit sau o breșă de securitate.

Aceasta este fundamental diferită de criptarea de transport (TLS), care protejează datele în tranzit între client și server dar lasă serverul cu acces la text clar. Este de asemenea diferită de criptarea în repaus, care protejează datele pe disc dar lasă nivelul aplicației cu acces la text clar în timpul prelucrării.

Adevărata E2EE înseamnă serverul nu este de încredere prin design. Este un releu, nu un cititor.

Protocolul MLS pentru mesagerie

Pentru mesageria criptată, folosim protocolul Messaging Layer Security (MLS), standardizat ca RFC 9420 de IETF. MLS a fost proiectat în mod specific pentru scenarii de mesagerie de grup și oferă mai multe avantaje peste abordări mai vechi.

MLS folosește o structură de acord de cheie bazată pe arbore numită TreeKEM, care permite unui grup de participanți să stabilească o chestiune comună eficient. Când un membru se alătură sau pleacă din grup, materialul de cheie este actualizat printr-un mesaj Commit care avansează epoca grupului. Aceasta oferă secret înainte — compromiterea cheilor unui membru la un moment în timp nu dezvăluie mesaje din epoce anterioare — și securitate post-compromis — grupul recuperează securitatea după un compromis de îndată ce materialul de cheie al membrului afectat este rotat.

Fiecare dispozitiv utilizator încarcă pachete de cheie MLS cu utilizare unică pe server. Acestea sunt pachete criptografice care permit altor dispozitive să le adauge la un grup fără a necesita dispozitivul să fie online în acel moment. Când un pachet de cheie este consumat, dispozitivul trebuie să încarce pachete proaspete. Serverul stochează și distribuie aceste pachete dar nu are niciodată acces la materialul de cheie privată pe care-l conțin.

Grupurile MLS în Mandraki se mapează la canale și fire de mesaj direct. Când trimit un mesaj într-un canal criptat, clientul îl criptează folosind cheia epocii curente a grupului. Serverul primește ciphertext, îl stochează și îl distribuie membrilor grupului. Clienții lor îl decriptează local.

SFrame pentru criptarea media

Criptarea media în timp real — audio și video într-un apel de grup — prezintă provocări diferite de mesagerie. Toleranța la latență este măsurată în milisecunde, nu secunde. Ratele de date sunt cu ordine de mărime mai mari. Și media trece printr-o Unitate de Forwarding Selectiv (SFU), care necesită rutarea pachete la participanții corecți fără a putea vedea conținutul.

Folosim SFrame (RFC 9605) pentru criptarea media, aplicată prin WebRTC Encoded Transform API. Acest API permite cod JavaScript să intercepteze cadre media codificate după codificare dar înainte de pachetizare, să le cripteze și să transmită ciphertext-ul la nivelul transportului. La capătul receptorului, cadrele sunt decriptate după reassambly dar înainte de decodificare.

Avantajul cheie al SFrame într-o arhitectură SFU este că SFU-ul poate totuși să-și efectueze funcția de rutare — forwarea pachete de la un participant la alții, luând decizii adaptative la lățime de bandă despre care straturi să forweze — fără a avea niciodată acces la media plaintext. SFU-ul vede cadre criptate și le forwează ca bloburi opace.

Compromisurile pe care suntem onești cu privire la ele

Criptarea end-to-end nu este gratuită. Introduce constrângeri reale pe care credem că merită să le recunoaștem.

Căutarea pe partea serverului nu este posibilă pe conținut E2EE. Dacă mesajele sunt criptate cu chei pe care serverul nu le deține, serverul nu le poate indexa pentru căutare. Mandraki abordează aceasta prin menținerea unui index de căutare criptat local pe client folosind IndexedDB. Aceasta oferă căutare per-dispozitiv dar nu suportă istoric de căutare cross-dispozitiv pentru mesaje primite înainte ca un dispozitiv să fie adăugat la grup.

Funcțiile AI pe partea serverului se exclud mutual cu E2EE. Funcțiile noastre de transcriere și rezumare AI necesită acces server-side la audio plaintext. Un apel sau canal nu poate avea atât E2EE cât și funcții AI activate simultan. Aceasta este aplicată arhitecturonic, nu doar de politică. Organizațiile aleg la nivel de apel sau canal care model preferă.

Dispozitivele noi văd mesaje doar de la punctul de alăturare înainte. Când adaugi un dispozitiv nou la cont, acesta poate decripta mesaje din momentul în care se alătură grupului MLS înainte. Mesajele istorice criptate sub epoce anterioare nu sunt accesibile pe noul dispozitiv. Aceasta este o proprietate fundamentală a secretului înainte. Explorăm mecanisme de backup sigur care ar permite utilizatorilor să exporte istoric criptat de mesaje la un dispozitiv nou, dar aceasta rămâne în lucru.

Gestionarea cheilor adaugă complexitate. Fiecare dispozitiv trebuie să menționeze material de cheie, să încarce pachete de cheie proaspete și să proceseze actualizări ale stării grupului. Investim efort de inginerie semnificativ în a face aceasta invizibilă pentru utilizatori. Scopul este ca criptarea să nu fie ceva care să configurezi sau să gândești — pur și simplu se întâmplă.

E2EE și criptarea server-side coexistă

Merită remarcat că stratul E2EE al Mandraki și criptarea noastră envelope server-side (ierarhia de cheie cu trei straturi descrisă în arhitectura noastră de securitate) servesc scopuri complementare. Criptarea server-side protejează datele în repaus pe infrastructura noastră — dacă un disc este furat sau o copie de rezervă de bază de date este compromisă, datele sunt inaccesibile fără cheile de criptare. E2EE merge mai departe asigurând că serverul nu vede niciodată plaintext de la început.

Pentru organizații care activează E2EE, ambele straturi sunt active simultan. Datele sunt criptate end-to-end de clienți și de asemenea criptate în repaus pe server. Centura și bretele.

Credem că criptarea end-to-end ar trebui să fie implicită pentru comunicări sensibile, nu un add-on premium sau o casetă pe care majoritatea utilizatorilor nu o găsesc niciodată. Mandraki o face directă de activat, transparentă în limitări și robustă în implementare.