Hej Habra!
Dzisiaj opowiem o tym, czym zajmujemy się z kolegami już od kilku miesięcy: powiadomieniami push na mobilnych komunikatorach. Jak już mówiłem, w naszej aplikacji główny nacisk położony jest na bezpieczeństwo. Dowiedzieliśmy się zatem, czy powiadomienia push mają „słabe punkty”, a jeśli tak, to w jaki sposób możemy je zniwelować, aby dodać tę przydatną opcję do naszej usługi.
Publikuję tłumaczenie naszego
Badamy materiał
W klasycznym modelu powiadomienia push narażają komunikatorów na ataki MITM (ang. Man-in-the-middle). Przykładowo w przypadku Google, Microsoftu i starej wersji iMessage aplikacja wysyła klucze szyfrujące na serwery Apple – na serwerze następuje uwierzytelnienie użytkowników i odszyfrowanie nagłówka wiadomości (lub jej zawartości).
Dzięki temu istnieje szansa na zapoznanie się z korespondencją poprzez uzyskanie dostępu do serwera powiadomień push. Oznacza to, że jakiekolwiek szyfrowanie korespondencji jest bezużyteczne: powiadomienia push nadal pozostawiają możliwość odczytania przez osoby trzecie. Autorzy artykułu szczegółowo omówili tę możliwość.
Jeśli uważasz, że serwery Apple i Google są w 100% zabezpieczone przed wyciekiem kluczy szyfrujących użytkowników, weź pod uwagę fakt, że dostęp do nich mają ich pracownicy. A pracownicy to ludzie.
Pomimo wszystkich luk w powiadomieniach push, korzysta z nich wiele „bezpiecznych” komunikatorów internetowych, w tym Signal i Telegram. W przeciwnym razie użytkownicy będą musieli „ręcznie” monitorować nowe wiadomości, stale logując się do aplikacji. Co jest bardzo niewygodne, a konkurujący ze sobą komunikatorzy zyskają przewagę.
Paranoja i zdrowy rozsądek
W naszym projekcie zajęliśmy się tą tematyką dokładnie kilka miesięcy temu. Aby być konkurencyjnym, musieliśmy dodać opcję powiadomień push. Ale jednocześnie nie należy otwierać luki w zabezpieczeniach, ponieważ jakikolwiek wyciek danych podważy zaufanie do projektu.
Mamy jednak już istotną przewagę: nasz komunikator jest zdecentralizowany (dane przechowywane są na blockchainie), a pracownicy nie mają dostępu do kont. Tylko użytkownicy posiadają klucze szyfrujące, a klucze publiczne rozmówców są dostępne na blockchainie w celu ochrony przed atakami MITM.
W pierwszej wersji powiadomień push postanowiliśmy zachować jak największą ostrożność i w ogóle nie przesyłać treści wiadomości. Usługa push nie odebrała tekstu wiadomości z węzła, a jedynie sygnał o fakcie jej otrzymania. Dlatego użytkownik zobaczył powiadomienie „Odestała nowa wiadomość”. Można było go przeczytać jedynie w komunikatorze.
Potem dowiedzieliśmy się, że najnowsza wersja powiadomień Apple ma nowe funkcje bezpieczeństwa. Oni
Opracowaliśmy teraz drugą wersję powiadomień push na iOS, która pozwala na wyświetlenie tekstu wiadomości bez zagrożenia bezpieczeństwa. W nowej koncepcji logika wygląda następująco:
- Usługa push wysyła powiadomienie push z numerem transakcji (zaszyfrowana wiadomość może być bardzo duża, a rozmiar powiadomień jest bardzo ograniczony)
- Gdy urządzenie otrzyma powiadomienie, uruchamia naszą NotificationServiceExtension – mikroaplikację, która żąda transakcji od węzła po identyfikatorze, odszyfrowuje ją przy użyciu zapisanego hasła i wysyła nowe powiadomienie do systemu. Hasło jest przechowywane w bezpiecznym magazynie.
- System wyświetla powiadomienie z odszyfrowaną wiadomością lub tłumaczeniem.
- Klucze nigdzie nie idą, tak jak zwykła wiadomość tekstowa. Usługa push nie ma możliwości odszyfrowania wiadomości.
Przyjęliśmy tę wersję jako działającą i zaimplementowaliśmy ją w najnowszej aktualizacji aplikacji iOS.
Osoby zainteresowane stroną techniczną mogą zapoznać się z kodem źródłowym:
Źródło: www.habr.com