Skąd wiadomo, co robi aplikacja mobilna

Ten artykuł piszę z myślą o osobach, które interesują się tematem aplikacji śledzących kontakty społeczne, ale nie mają ugruntowanej wiedzy z zakresu IT i programowania. Aplikacje wspomagające walkę z koronawirusem są obecnie przedmiotem wielu dyskusji i opracowań a nie wszyscy dyskutanci dobrze rozumieją charakterystyczne cechy ekosystemów Android i iOS. W tekście nawiążę do postulatów “7 Filarów Zaufania”, o których można przeczytać na stronach Fundacji Panoptykon.

Zastrzeżenie: Ministerstwo Zła, które pojawi się w tekście, nie ma nic wspólnego z żadnym istniejącym ministerstwem tego czy owego rządu i służy wyłącznie jako figura retoryczna. W rozważaniach dotyczących praw człowieka często rozważa się rozwój wydarzeń według najgorszego scenariusza – i nasze Ministerstwo Zła realizuje taką właśnie ścieżkę.

W pierwszej części tekstu opowiem, skąd można dowiedzieć się, co robi program komputerowy – w szczególności zaś, czy robi to, co deklaruje jego autor lub wydawca. Potem zahaczymy o ekosystem Google Play i Apple App Store, by zrozumieć zagrożenia wynikające z automatycznej aktualizacji programów. Na końcu popatrzymy na protokół Exposure Notification (vel Contact Tracing) zaproponowany przez Apple i Google oraz zastanowimy się, dlaczego ochroni nasze tajemnice przed Ministerstwem Zła.

Większość przykładów będzie dotyczyła Androida, który jest w Polsce najpopularniejszym mobilnym systemem operacyjnym, jednak prawie wszystkie sytuacje i techniki dotyczą także systemu iOS.

Skąd wiadomo, co robi aplikacja

Załóżmy, że Ministerstwo Czegośtam (w skrócie MC) bardzo wszystkich zachęca do instalacji jakiejś aplikacji i mówi, że ta aplikacja będzie robiła to i owo, na przykład śledziła kontakty społeczne ale bez rejestracji miejsca spotkania ani tożsamości spotkanych osób. Czy możemy jakoś sprawdzić, jak jest w rzeczywistości?

Aplikacje komputerowe są przystosowane do wykonania przez procesor komputera lub telefonu i pozostają całkowicie nieczytelne dla człowieka. Próba podejrzenia ich zawartości da taki lub podobny rezultat, na obrazku widzimy tak zwany kod wykonywalny programu (to, co rozumie komputer)

Do analizy programu możemy zabrać się na dwa sposoby.

Pierwszy sposób to tak zwana analiza statyczna, czyli bierzemy program, oglądamy jego zawartość i staramy się zrozumieć, co będzie on robił po uruchomieniu. Pomagają w tym specjalne programy, które przekładają instrukcje procesora na kod czytelny dla programisty (proces ten nazywamy dekompilacją). Przejrzenie kolejnych bloków kodu pozwala zrozumieć, jakie funkcje będą realizowane i od czego będzie zależało zachowanie programu.

Przykładowe narzędzie, które pomaga w analizie statycznej, wygląda tak:

Drugi sposób to analiza dynamiczna, czyli uruchamiamy program i za pomocą innych narzędzi śledzimy, co robi i w jaki sposób komunikuje się z otoczeniem – na przykład jakie pliki zapisuje, w jaki sposób je szyfruje, co wysyła do sieci, pod jakie adresy i tak dalej. Podczas takiej obserwacji jesteśmy w stanie ocenić, czy wykonywane akcje rzeczywiście składają się na zadania, o których zakresie byliśmy informowani.

Przykładowe narzędzie, które pomaga w analizie dynamicznej, wygląda tak:

Obie metody są trudne, czasochłonne i wymagają specjalistycznej wiedzy z zakresu tak zwanej inżynierii wstecznej (reverse engineering) – a i tak nie ma gwarancji, że specjalista dostrzeże i zrozumie każdy aspekt działania programu.

W jaki sposób można utrudnić analizę?

Czasem autorowi lub wydawcy zależy na tym, by utrudnić analizę aplikacji – na przykład po to, aby ukryć funkcje o których użytkownik ma się nie dowiedzieć (jak śledzenie albo profilowanie tegoż użytkownika). Choć zawsze będzie istnieć możliwość “rozprucia” aplikacji przez zdeterminowanego badacza, to praca taka może zająć długie tygodnie.

Prostą metodą utrudniania (i spowalniania) analizy jest zaciemnianie kodu, czyli zastosowanie narzędzi, które sprawiają, że przepływ danych w programie jest o wiele trudniejszy do zrozumienia, kod wykonywalny jest wzbogacany o liczne fragmenty które nigdy nie będą uruchamiane, pozbawiony czytelnych nazw funkcji i tak dalej. Wielu autorów robi to rutynowo, bo narzędzia są popularne i dobrze znane.

Czasem możemy spotkać się z szyfrowaniem kodu wykonywalnego, uniemożliwiającym analizę statyczną. Rozszyfrowanie ma miejsce dopiero w po uruchomieniu, w pamięci operacyjnej, zaś analizowanie programu w trakcie jego działania jest o wiele trudniejsze. Dodatkowo aplikacja może próbować wykrywać to, że jest śledzona, i podsuwać analitykowi fałszywe ścieżki, by go jeszcze bardziej spowolnić. Takie sposoby często są stosowane przez producentów gier. Gdyby Ministerstwo Czegośtam zachęcało nas do instalacji aplikacji chronionej w ten sposób, mielibyśmy do czynienia z sytuacją co najmniej zastanawiającą.

Niekiedy informacje niezbędne do działania programu pobierane są z sieci. Jest to cecha charakterystyczna dla złośliwego oprogramowania, które po zainfekowaniu systemu pobiera z macierzystego serwera instrukcje dotyczące dalszych działań. Analityk nie ma więc pewności, czy badana aplikacja pobrała z sieci ten sam zestaw informacji, które otrzymali inni użytkownicy. Gdyby aplikacja wydana przez Ministerstwo Czegośtam korzystała z takich technik, byłby to sygnał alarmowy – takich technik nie stosuje się w typowych aplikacjach.

Otwarte źródła (Open Source)

O wiele prostszy do analizy jest kod źródłowy programu czyli tekst pisany przez programistę w wybranym języku programowania. Jest bardziej czytelny i przejrzysty, zawiera komentarze opisujące bardziej złożone fragmenty, opisowe nazwy funkcji, niesie informacje o intencjach autora. Specjalistyczna wiedza z zakresu inżynierii wstecznej staje się zbędna, zwykły programista może dzięki lekturze kodu źródłowego zrozumieć zakres funkcjonalny badanego programu.

Wiele projektów programistycznych rozwijanych jest w modelu otwartym: kod źródłowy jest dostępny dla każdego zainteresowanego, można go zmieniać, ulepszać zaś efektami dzielić się z całym światem. Przykładem wielkiego projektu z otwartym kodem źródłowym jest jądro systemu Linux, rozwijane przez tysiące programistów z całego świata.

Większość programów powstaje jednak w modelu zamkniętym, gdzie kod źródłowy stanowi tajemnicę przedsiębiorstwa. Microsoft nie ujawnia kodu źródłowego pakietu Office, autorzy gier nie ujawniają kodu źródłowego swoich produkcji, Google – metod działania swojej wyszukiwarki itd.

Dostęp do kodu źródłowego bardzo pomaga w upewnieniu się, że działanie aplikacji jest zgodne z deklaracjami autorów. Najpierw robimy audyt, potem uruchamiamy kompilację czyli proces, w którym narzędzia programistyczne przetwarzają pliki z kodem źródłowym w pliki z kodem wykonywalnym. Na końcu sprawdzamy, czy powstałe pliki z kodem wykonywalnym są identyczne z tymi, które zawiera aplikacja pobrana ze sklepu. Jeśli tak jest, to zyskujemy pewność, że aplikacja będzie realizować dokładnie te funkcje, które odnaleźliśmy w kodzie źródłowym.

Szósty filar zaufania kontra sklep z aplikacjami

Aplikacje śledzące kontakty społeczne mogą stać się furtką do naruszeń praw i wolności obywateli, opracowano więc zestaw siedmiu zasad których realizacja ograniczy ryzyko naruszeń.

Zajrzyjmy do numeru szóstego: “Standardem dla narzędzi służących do walki z pandemią powinna być pełna otwartość kodu oraz algorytmów stosowanych do analizy danych […] Tylko taki standard umożliwi publiczną kontrolę nad narzędziami technologicznymi, a zarazem przełoży się na ich bezpieczeństwo. Otwartość kodu daje bowiem możliwość szybszego zidentyfikowania błędów i możliwych zagrożeń dla prywatności, co dodatkowo wzmacnia zaufanie do danej aplikacji.”

Wyobraźmy sobie sytuację, że kod źródłowy aplikacji mobilnej firmowanej przez Ministerstwo Czegośtam jest opublikowany na GitHubie, o jego zgodności z oczekiwaniami orzekło wielu specjalistów, zgodność z wytycznymi potwierdziły organizacje zajmujące się prawami człowieka – słowem wszyscy są zadowoleni. Czy użytkownicy są bezpieczni?

Niestety nie. W sklepach Google Play i App Store nie ma żadnych mechanizmów gwarantujących spójność kolejnych wersji aplikacji. Jedyny mechanizm kontroli to podpis cyfrowy, którym opatrywana jest paczka z programem – on jednak potwierdza jedynie tożsamość wydawcy. Jeśli więc Ministerstwo Czegośtam okaże się tak naprawdę Ministerstwem Zła, to w każdej chwili będzie mogło podmienić zaufaną apkę o otwartych źródłach na inwazyjną aplikację łamiącą wszystkie wytyczne i reguły, mającą niewiele lub zgoła nic wspólnego z wcześniejszą wersją.

Przykład: aplikacja śledząca kontakty społeczne może spełniać przywoływane już kryteria zaufania, czyli rejestrować wyłącznie anonimowe identyfikatory odebrane przez Bluetooth Low Energy (BLE), przechowywać je na urządzeniu, kasować po 14 dniach i tak dalej. Nowa wersja aplikacji może wysłać wszystkie te dane na serwer Ministerstwa, nadawać przez Bluetooth stały identyfikator zawierający numer telefonu oraz zapisywać godzinę i miejsce każdej interakcji, by Ministerstwo mogło sprawdzić, kto, gdzie i kiedy się z kim spotykał. Dodatkowo – jeśli nowa wersja aplikacji opublikowana przez Ministerstwo Zła będzie realizować polecenia pobierane z serwera, to złośliwe akcje mogą trafić jedynie do wybranych osób, wytypowanych w nieznany nam sposób.

Czy o takiej sytuacji w ogóle się dowiemy? W końcu nowa wersja aplikacji może wyglądać tak, jak poprzednia, choć dane przetworzy w zupełnie inny sposób. Cóż – różnicę wykaże dopiero audyt kodu wykonywalnego ujawniający, że wskazana wersja zachowuje się w sposób niezgodny z wcześniejszymi deklaracjami. Dobrą wiadomością jest to, że w świecie Androida serwis apkmirror.com archiwizuje kolejne wersje aplikacji opublikowanych w sklepie Google Play – to pozwala na łatwiejszą analizę różnic między nimi. Zła wiadomość jest taka, że o problemie dowiemy się dopiero, gdy nowa wersja zostanie wydana i trafi do telefonów użytkowników.

Podsumowując – w przypadku aplikacji mobilnych audyty i otwartość źródeł niewiele nam pomogą, bo wydawca aplikacji w dowolnej chwili może opublikować nową wersję aplikacji, zachowującą się zupełnie inaczej niż poprzednia.

Exposure Notification czyli Google i Apple na ratunek

Apple i Google za kilka dni otworzą dostęp do modułów (bibliotek) systemowych realizujących protokół o nazwie Exposure Notification (do przedwczoraj zwany Contact Tracing, ale w specyfikacji v1.1 nazwę zmieniono). Dzięki temu, że będą one działać z podwyższonymi uprawnieniami, niedostępnymi dla zwykłych aplikacji, jest nadzieja na jaką-taką skuteczność rozwiązania – aplikacje o normalnym poziomie uprawnień nie są w stanie działać w tle w sposób wystarczająco niezawodny.

Apki korzystające z Exposure Notification (EN) oprócz oczekiwanej wyższej skuteczności mają jeszcze jedną fundamentalną zaletę – gwarantowaną poufność rozwiązania. Apple i Google realizują śledzenie interakcji w modelu rozproszonym, zaś aplikacje mogą komunikować się z bibliotekami EN tylko za pośrednictwem API czyli określonego interfejsu programistycznego (patrz – dokumentacja Apple i Google).

Użytkownicy nie muszą się obawiać opisanego wyżej scenariusza ze złośliwą aktualizacją aplikacji, bo w żadnej wersji Ministerstwo Zła nie będzie w stanie poznać ani bieżącego identyfikatora nadawanego przez Bluetooth (zmienianego co kwadrans), ani identyfikatorów odebranych z innych urządzeń – API po prostu nie daje takiej możliwości. Ministerstwo Zła nie przechwyci też komunikacji sieciowej, bo szyfrowana transmisja danych będzie realizowana poza aplikacją, bezpośrednio między bibliotekami EN a serwerami Google/Apple.

Tu może pojawić się pytanie – jak aplikacja będzie w stanie cokolwiek zrobić bez dostępu do kluczowych danych? Większość pracy wykona Exposure Notification: zajmie się transmisją przez Bluetooth własnego identyfikatora, nasłuchem i rejestracją cudzych identyfikatorów, synchronizacją informacji o identyfikatorach nadawanych uprzednio przez osoby o pozytywnym wyniku testu na koronawirusa i wykrywaniem, czy któryś z tych identyfikatorów został zarejestrowany jako kontakt. Jeśli tak było, to aplikacja zostanie o tym poinformowana za pomocą mechanizmu powiadomień zwrotnych (callback) – jednak będą to dane składające się jedynie z daty i czasu przebywania w pobliżu osoby zarażonej (a raczej jej urządzenia).

To właśnie budzi opór wielu rządów, które chciałyby realizować model scentralizowany (z identyfikacją kontaktów po stronie serwera) albo chociaż dorzucić do powiadomień np. informację o miejscu spotkania.

Co dalej?

Trwa wizerunkowa walka między państwami a korporacjami. Korporacje oferują rozwiązanie techniczne, ale na własnych warunkach. Owszem, ochronią prywatność użytkowników przed rządami, lecz zrobią to bez pytania o zdanie żadnej ze stron. Z kolei Francja, Niemcy i Wielka Brytania domagają się od Apple i Google możliwości uruchamiania w tle aplikacji, których praca będzie koordynowana przez “krajowe” serwery, niekoniecznie zapewniające porównywalny poziom ochrony prywatności.

Nie zmienia to jednak faktu, że w państwach demokratycznych nie ma siły mogącej zmusić użytkowników do instalacji i używania aplikacji śledzącej kontakty społeczne. Jest to możliwe jedynie w systemach totalitarnych, np. w Chinach, gdzie od zielonego QR-kodu z aplikacji AliPay albo WeChat zależy, czy obywatel będzie mógł korzystać z transportu publicznego albo wstąpić do restauracji.

Śledzenie aplikacji śledzących?

Aplikacja ProteGO Safe, której patronem i wydawcą jest Ministerstwo Cyfryzacji, będzie korzystać z Exposure Notification. Biblioteki mają być dostępne dla programistów już pojutrze a więc przed zapowiadanym wcześniej terminem.

Jeśli wersja ProteGO Safe rozszerzona o śledzenie kontaktów społecznych rzeczywiście zostanie wydana, postaram się przygotować nasłuch Bluetooth w jednym lub dwóch uczęszczanych miejscach Wrocławia. Pozwoli to oszacować rzeczywistą popularność aplikacji w terenie. Więcej szczegółów wkrótce.