W MindTheClub treść wiadomości podróżuje bezpośrednio między dwoma urządzeniami szyfrowanym kanałem peer-to-peer. Żaden serwer MindTheClub ani żadna strona trzecia nie przechowuje treści Twoich wiadomości.
Aby nawiązać to bezpośrednie połączenie, dwa urządzenia muszą wymienić niewielką ilość informacji konfiguracyjnych, a jeśli jedno z nich śpi — sygnał, który je obudzi. Te dwa kroki pomocnicze to jedyne miejsca, w których uczestniczy serwer, a poniżej precyzyjnie opisujemy, co każdy z nich może, a czego nie może zobaczyć.
Zanim cokolwiek z tego się wydarzy, oba urządzenia muszą znać swoją tożsamość. Opisujemy to najpierw, bo każdy późniejszy krok na tej stronie na tym się opiera.
Każdy późniejszy zaszyfrowany krok opiera się na jednym założeniu: każda strona używa prawdziwego klucza publicznego drugiej, a nie podstawionego przez pośredniczącego dostawcę. Osiągamy to jedną wymianą poza systemem i zapieczętowaną odpowiedzią, dzięki czemu obie strony są zweryfikowane po jednym zeskanowaniu kodu QR lub jednym dotknięciu linku z zaproszeniem.
Twój kod QR zawiera Twój identyfikator użytkownika i odcisk Twojego klucza publicznego — krótki kryptograficzny skrót, który jednoznacznie go identyfikuje. Twój link z zaproszeniem niesie te same dwie rzeczy, osadzone w samym linku. Niezależnie więc od tego, czy ktoś zeskanuje Twój kod, czy dotknie Twojego linku, jego urządzenie otrzymuje ten sam odcisk do sprawdzenia. Pokazanie kodu QR twarzą w twarz to najsilniejszy kanał, ale w obu przypadkach obowiązuje poniższa gwarancja: dostawca katalogu nigdy nie może niezauważenie podmienić Twojego klucza.
Gdy druga osoba skanuje lub dotyka, jej urządzenie pobiera Twój klucz publiczny z katalogu i lokalnie oblicza jego odcisk. Jeśli zgadza się z tym z kodu QR lub linku, klucz zostaje zaakceptowany; jeśli nie, jest odrzucany i nie jest zapisywany. Podmieniony klucz powoduje niezgodność, a urządzenie go odrzuca.
Jej urządzenie wysyła Ci następnie prośbę o kontakt z własnym odciskiem zapieczętowanym w środku, zaszyfrowanym Twoim zweryfikowanym kluczem. Tylko Ty możesz ją odszyfrować. Twoje urządzenie wykonuje tę samą kontrolę w drugą stronę, akceptując kontakt tylko wtedy, gdy odciski się zgadzają.
Po jednym skanie lub dotknięciu obie strony niezależnie zweryfikowały klucz drugiej, a dostawca trzymający katalog nie może podmienić żadnego z nich bez złamania kontroli, której nie jest w stanie sfałszować.
MindTheClub używa kanałów danych WebRTC do przenoszenia wiadomości. Kanał danych WebRTC to bezpośrednie, szyfrowane połączenie między dwoma urządzeniami. Gdy zostanie ustanowiony między dwiema stronami:
Duże pliki są dzielone na bloki i wysyłane tym samym bezpośrednim kanałem, z logiką ponawiania na urządzeniu nadawcy gwarantującą ostateczne dostarczenie. Bloki podróżują peer-to-peer jak wszystko inne.
Czasem dwa urządzenia nie mogą otworzyć bezpośredniej ścieżki (restrykcyjne NAT-y, zapory operatorów komórkowych). Wtedy WebRTC korzysta z przekaźnika TURN, by przepuścić zaszyfrowany strumień. MindTheClub używa do tego usługi TURN Cloudflare. Przekaźnik przekazuje zaszyfrowane pakiety; to standardowy element działania WebRTC, gdy bezpośrednie połączenie nie jest możliwe. Ten mechanizm wpływa tylko na ścieżkę sieciową zaszyfrowanego strumienia; nie zmienia faktu, że treść pozostaje end-to-end między dwoma urządzeniami.
Zanim kanał WebRTC może się otworzyć, oba urządzenia muszą wymienić informacje „sygnalizacyjne”: opisy połączenia i kandydujące adresy sieciowe (w terminologii WebRTC — ofertę/odpowiedź SDP i kandydatów ICE). To uniwersalny wymóg WebRTC — robi to każda aplikacja WebRTC, w tym strony do rozmów wideo. Informacje są małe i potrzebne tylko do ustanowienia połączenia; to nie jest treść Twoich wiadomości.
Pytanie brzmi: kto przenosi tę sygnalizację i co może zobaczyć. W MindTheClub:
Zaprojektowaliśmy sygnalizację tak, by przekaźnik dowiadywał się jak najmniej:
Jeśli telefon Boba śpi albo aplikacja nie działa, urządzenie Alicji potrzebuje sposobu, by go obudzić, aby mógł dołączyć do połączenia. MindTheClub używa do tego Firebase Cloud Messaging (FCM), usługi push Google, bo to mechanizm, który Android udostępnia do niezawodnego budzenia aplikacji z tła.
Zawartość ładunku budzącego jest szyfrowana kluczem publicznym odbiorcy, zanim opuści nadawcę. Co kluczowe, tożsamość nadawcy znajduje się wewnątrz tego zaszyfrowanego ładunku — nie jest widoczna dla infrastruktury push. To projekt typu „sealed sender”: strona dostarczająca powiadomienie nie widzi, kto je wysłał.
Aby dostarczyć powiadomienie, każdy system push musi wiedzieć, kto je odbiera — tak działa dostarczanie i dotyczy to każdego komunikatora opartego na push. Adres odbiorcy jest więc siłą rzeczy widoczny dla warstwy push. To, co nie jest widoczne, to tożsamość nadawcy, która pozostaje zapieczętowana w zaszyfrowanym ładunku.
Aby nawiązać połączenie WebRTC, urządzenia potrzebują krótkotrwałych poświadczeń do usługi STUN/TURN (komponentów, które pomagają dwóm urządzeniom znaleźć ścieżkę sieciową do siebie). Poświadczenia te są generowane przy użyciu tajnego klucza, który musi pozostać poza urządzeniem.
MindTheClub pobiera te poświadczenia z Cloudflare Workera, który przechowuje sekret po stronie serwera. Żadna usługa Google nie uczestniczy w pozyskiwaniu poświadczeń połączenia. Jeśli to pobranie się nie powiedzie, połączenie korzysta z publicznych serwerów STUN, które pomagają urządzeniu jedynie odkryć własny publiczny adres i nie dowiadują się niczego o tym, z kim się kontaktuje.
Składając wszystko razem: strony weryfikują swoje klucze jednym skanem kodu QR lub linkiem, następnie wymieniają niewielkie ilości zaszyfrowanych informacji konfiguracyjnych przez bezstanowy przekaźnik i zapieczętowane powiadomienie budzące. Gdy bezpośredni kanał jest otwarty, treść wiadomości płynie wyłącznie z urządzenia na urządzenie.