Szyfrowanie end-to-end bez kompromisów

Uwaga: Ten artykuł opisuje architekturę i projekt Mandraki. Niektóre omówione funkcje są wdrażane progresywnie i mogą być jeszcze niedostępne we wszystkich planach.

Szyfrowanie end-to-end to jedna z tych funkcji, która jest łatwa do obiecania i trudna do prawidłowego dostarczenia. Wiele platform współpracy twierdzi, że oferuje E2EE, ale szczegóły ich implementacji różnią się ogromnie — a szczegóły to miejsce, gdzie bezpieczeństwo żyje lub umiera.

Ten post wyjaśnia, jak Mandraki implementuje szyfrowanie end-to-end, wybory protokołu, które poczyniliśmy, i kompromisy, o których jesteśmy przejrzyści.

Co naprawdę oznacza szyfrowanie end-to-end

W systemie z szyfrowaniem end-to-end wiadomości i media są szyfrowane na urządzeniu nadawcy i mogą być odszyfrowane tylko na urządzeniach odbiorców. Serwer, który przekazuje dane, widzi tylko zaszyfrowany tekst. Nie może odczytać zawartości, nawet jeśli zmuszony do tego wyrokiem sądowym, zdrajcą pracownika lub naruszeniem bezpieczeństwa.

To jest fundamentalnie inne niż szyfrowanie transportu (TLS), które chroni dane w tranzycie między klientem a serwerem, ale pozostawia serwer z dostępem do zwykłego tekstu. Jest to również inne niż szyfrowanie w spoczynku, które chroni dane na dysku, ale pozostawia warstwę aplikacji z dostępem do zwykłego tekstu podczas przetwarzania.

Prawdziwe E2EE oznacza, że serwer jest niezaufany przez projekt. To jest przekaźnik, nie czytelnik.

Protokół MLS do komunikacji

W celu szyfrowanej komunikacji, używamy protokołu Messaging Layer Security (MLS), standaryzowanego jako RFC 9420 przez IETF. MLS został zaprojektowany specjalnie dla scenariuszy komunikacji grupowej i oferuje kilka zalet nad starszymi podejściami.

MLS używa struktury zgodności opartej na drzewie zwanej TreeKEM, która pozwala grupie uczestników na efektywne ustalenie wspólnego tajnego. Kiedy członek dołącza lub opuszcza grupę, materiał klucza jest aktualizowany za pośrednictwem wiadomości Commit, która napędza epokę grupy. Zapewnia to tajność przyszłości — kompromis kluczy członka w jednym momencie czasu nie ujawnia wiadomości z wcześniejszych epok — i bezpieczeństwo po kompromisie — grupa odzyskuje bezpieczeństwo po kompromisie, gdy tylko materiał klucza dotkniętego członka zostanie obrócony.

Każde urządzenie użytkownika przesyła pakiety kluczy MLS do serwera. Są to jednorazowe kryptograficzne pakiety, które pozwalają innym urządzeniom dodawać je do grupy bez konieczności bycia urządzeniu w trybie online w tym momencie. Gdy pakiet klucza jest zużyty, urządzenie musi przesłać świeże. Serwer przechowuje i rozprowadza te pakiety, ale nigdy nie ma dostępu do materiału klucza prywatnego, który zawierają.

Grupy MLS w Mandraki mapują na kanały i wątki wiadomości bezpośrednich. Gdy wysyłasz wiadomość w zaszyfrowanym kanale, Twój klient szyfruje go przy użyciu bieżącego klucza epoki grupy. Serwer otrzymuje zaszyfrowany tekst, przechowuje go i rozprowadza go do członków grupy. Ich klienci odszyfrują go lokalnie.

SFrame do szyfrowania mediów

Szyfrowanie mediów w czasie rzeczywistym — audio i wideo w rozmowie grupowej — przedstawia inne wyzwania niż komunikacja. Tolerancja opóźnienia jest mierzona w milisekundach, a nie sekundach. Przepływy danych są rzędu wielkości wyższe. A media przechodzą przez Selective Forwarding Unit (SFU), który musi kierować pakiety do właściwych uczestników bez możliwości zobaczenia zawartości.

Używamy SFrame (RFC 9605) do szyfrowania mediów, zastosowanego za pośrednictwem WebRTC Encoded Transform API. Ten API pozwala kodowi JavaScript na przechwycenie zakodowanych ramek multimediów po kodowaniu, ale przed pakietyzacją, zaszyfrowaniu ich i przesłaniu zaszyfrowanego tekstu do warstwy transportu. Po stronie odbiorczej ramki są odszyfrowane po ponownym zmontowaniu, ale przed dekodowaniem.

Kluczową zaletą SFrame w architekturze SFU jest to, że SFU nadal może wykonywać swoją funkcję routingu — przesyłanie pakietów od jednego uczestnika do innych, podejmowanie decyzji adaptacyjnych przepustowości o tym, które warstwy przesyłać — bez nigdy dostępu do zwykłego tekstu mediów. SFU widzi zaszyfrowane ramki i przesyła je jako nieprzejrzyste obiekty.

Kompromisy, które jesteśmy szczerzy

Szyfrowanie end-to-end nie jest bezpłatne. Wprowadza rzeczywiste ograniczenia, które wierzymy, są warte potwierdzenia.

Wyszukiwanie po stronie serwera nie jest możliwe na zawartości E2EE. Jeśli wiadomości są szyfrowane kluczami, których serwer nie posiada, serwer nie może ich indeksować do wyszukiwania. Mandraki rozwiązuje to, utrzymując lokalny zaszyfrowany indeks wyszukiwania na kliencie przy użyciu IndexedDB. To zapewnia wyszukiwanie dla każdego urządzenia, ale nie obsługuje wyszukiwania historii między urządzeniami dla wiadomości otrzymanych przed dodaniem urządzenia do grupy.

Funkcje AI po stronie serwera są wzajemnie wyłączne z E2EE. Nasze funkcje transkrypcji i streszczenia AI wymagają dostępu po stronie serwera do zwykłego tekstu audio. Rozmowa lub kanał nie mogą mieć jednocześnie włączonych funkcji E2EE i AI. To jest wymuszane architektonicznie, a nie tylko polityką. Organizacje wybierają na poziomie rozmowy lub kanału, który model preferują.

Nowe urządzenia widzą wiadomości tylko z punktu dołączenia do przodu. Gdy dodasz nowe urządzenie do swojego konta, może odszyfrować wiadomości od momentu dołączenia do grupy MLS. Historyczne wiadomości szyfrowane w poprzednich epokach nie są dostępne na nowym urządzeniu. To jest fundamentalną właściwością tajności przyszłości. Badamy bezpieczne mechanizmy kopii zapasowych, które pozwoliłyby użytkownikom na eksportowanie zaszyfrowanej historii wiadomości na nowe urządzenie, ale to pozostaje w toku.

Zarządzanie kluczami dodaje złożoność. Każde urządzenie musi utrzymywać materiał klucza, przesyłać świeże pakiety kluczy i przetwarzać aktualizacje stanu grupy. Inwestujemy znaczny wysiłek inżynierski, aby to było niewidoczne dla użytkowników. Celem jest, aby szyfrowanie nie było czymś, co konfigurujesz lub myślisz — to po prostu się dzieje.

E2EE i szyfrowanie po stronie serwera współistnieją

Warto zauważyć, że warstwa E2EE Mandraki i nasze szyfrowanie koperty po stronie serwera (trzywarstwowa hierarchia kluczy opisana w naszej architekturze bezpieczeństwa) służą komplementarnym celom. Szyfrowanie po stronie serwera chroni dane w spoczynku w naszej infrastrukturze — jeśli dysk zostanie skradziony lub kopia zapasowa bazy danych zostanie zagrożona, dane są nieczytelne bez kluczy szyfrowania. E2EE idzie dalej, zapewniając, że serwer nigdy nie widzi zwykłego tekstu w pierwszym miejscu.

Dla organizacji, które włączają E2EE, obie warstwy są aktywne jednocześnie. Dane są szyfrowane end-to-end przez klientów i również szyfrowane w spoczynku na serwerze. Pas i szelki.

Wierzymy, że szyfrowanie end-to-end powinno być domyślne dla wrażliwej komunikacji, a nie dodatkiem premium lub polem wyboru, które większość użytkowników nigdy nie znalezie. Mandraki czyni to proste do włączenia, przejrzyste w jego ograniczeniach i niezawodne w jego implementacji.