środa, 1 lipca 2020

Deanonimizacja i śledzenie Covid19 Bluetooth Exposure Notifications


Rok 2020, z pewnością zapisze się w historii. Już teraz można go podsumować nie tylko jako rok pandemii, ale przede wszystkim rok który najpewniej zapoczątkuje ogromne zmiany w funkcjonowaniu społeczeństw. Politykę zostawiam jednak z boku, to na czym w tym wpisie chce się skupić to idea śledzenia kontaktów międzyludzkich.

Jednym z głównych problemów przy opanowaniu pandemii jest skuteczne namierzanie osób potencjalnie zarażonych, czyli takich które miały kontakt z kimś zdiagnozowanym jako nosiciel choroby. W czasie poprzednich pandemii które nękały ludzkość na światowa skale, nie mieliśmy tego co mamy dzisiaj, czyli technologii umożliwiającej śledzenie kontaktów.

W obecnych czasach sytuacja wygląda jednak inaczej. Najpierw pojawiła się propozycja pochodząca z środowiska akademickiego, czyli DP-3T, później temat został podchwycony przez Google oraz Apple, które opierając się na DP-3T, zaproponowały własny protokół G+A. Oba rozwiązania bazują na komunikatach rozgłaszanych przez urządzenia mobilne za pomocą Bluetooth.

W dużym skrócie, chodzi o to by na podstawie identyfikatorów (ich skrócona nazwa to RPI) rozgłaszanych w eter przez smartfony, pojedyncza osoba była w stanie ustalić czy miała kontakt z kimś u kogo zdiagnozowano chorobę. Identyfikatory są generowane przy pomocy klucza kryptograficznego, a sam klucz który umożliwiający ich "rozszyfrowanie", może zostać upubliczniony tylko przez właściciela smartfon-u, o ile został zdiagnozowany pozytywnie. W teorii wszystko jest bezpieczne i zapewnia prywatność, w praktyce jednak nie jest tak różowo.

Problemów jest całe mnóstwo, począwszy od ataków które polegają na celowym propagowaniu identyfikatorów zarażonych osób by wywołać chaos w społeczeństwie, po dokładne śledzenie kto, kiedy i z kim się kontaktował. Więcej o możliwych atakach można przeczytać chociażby tu i tu.

Mnie osobiście najbardziej zaintrygował problem deanonimizacji oraz śledzenia pojedynczych osób, a konkretniej pytanie, czy ktokolwiek poza Google i Apple, będzie również w stanie skutecznie śledzić wybrane osoby? Nawiasem mówiąc, sytuacja w której musimy polegać na "słowie" dwóch wielkich korporacji słynących z wykorzystywania i gromadzenia wszelakich informacji o użytkownikach, nie jest specjalnie lepsza od sytuacji gdy tym samym zaufaniem musielibyśmy obdarzyć nasz rzad.

Wracając do tematu, okazuje się, że praktyczna implementacja G+A nie jest idealna pod względem zachowania anonimowości i wcale nie trzeba łamać żadnych szyfrów by coś ugrać. Przede wszystkim jest kilka ograniczeń jeżeli chodzi o sam Bluetooth:

  • Nasłuchiwanie na komunikaty wymaga wybudzenia całego urządzenia, co drastycznie zwiększa pobór prądu, a tym samym szybko wyczerpuje baterie. Z tego powodu urządzenia wybudzają się tylko raz na kilka minut by odebrać komunikaty od innych urządzeń

  • Bluetooth od wersji 4.0 jest przystosowany do ciągłego rozgłaszania komunikatów i nie wymaga to wybudzania urządzenia. Tak więc by zwiększyć szansę na odebranie danych przez inny smartfon, identyfikatory RPI są rozgłaszane dosyć często (zwykle co 300-600ms)

  • Komunikaty muszą być nadawane z jakimś adresem MAC, który dla każdego urządzenia powinien być różny. Inaczej będziemy blokować pozostałe funkcje Bluetooth

  • By utrudnić śledzenie urządzeń, adresy MAC oraz identyfikatory RPI powinny być również okresowo zmieniane, najlepiej oba w tym samym momencie

Warto jeszcze wiedzieć, że w BT4.0 pojawiło się wsparcie dla sprzętowej zmiany adresów MAC. Czas zmiany w BT4.0 i BT4.1 ustawiony jest na sztywno i wynosi 15minut. Dopiero od wersji BT4.2 może być ustawiony praktycznie dowolnie (w przedziale od 1s do do 11.5h). Dodatkowo adresy MAC powinny być losowe, ale nie mogą być przypadkowe. Większość czytelników zapewne spyta, a co to za różnica?

Chodzi o to, że jeżeli adres zmieni się w trakcie komunikacji, to urządzenia stracą ze sobą łączność. Użytkownicy np. słuchawek bezprzewodowych nie byliby specjalnie szczęśliwi musząc co chwile parować swoje słuchawki. Z tego powodu kolejne adresy MAC powinny wyglądać na losowe, ale równocześnie muszą być możliwe do odebrania przez urządzenia z którymi już nawiązaliśmy łączność.

Jak to jest zrobione w praktyce? Adresy MAC generowane są przy pomocy klucza IRK (ang. Identity Resolving Key), w taki sposób że przy jego pomocy szyfrowane są losowe 24bity danych (tzw. prand). Ostatecznie adres MAC uzyskiwany jest z połączenia zaszyfrowanych danych (hash) oraz ich wersji odszyfrowanej (prand), tak jak na rysunku poniżej :


Samo szyfrowanie zrobione jest w oparciu o algorytm AES-128, którego na tą chwile uznawany jest za bezpieczny. Teraz, by potwierdzić że nadawany adres MAC pochodzi od zaufanego urządzenia, wystarczy podzielić adres na dwie części (24 bitowy hash i prand), zaszyfrować prand i sprawdzić czy uzyskany hash jest taki sam jak w oryginalnym adresie MAC. Adresy tego typu nazwane są adresami RPA (ang. Resolvable Random Private Address) natomiast cały proces znany jest jako rozwiązywanie adresu (ang. address resolution).

Tak więc jeżeli sparujemy ze sobą dwa urządzenia i chcemy używać adresów RPA, urządzenia muszą jeszcze po sparowaniu przejść tzw. bonding, czyli wymienić się swoimi kluczami szyfrującymi, w tym kluczem IRK.

Podsumujmy teraz zebrane fakty.

Urządzenia mogą zmieniać swoje adresy MAC na poziomie sprzętowym (zdaje się, że od BT4.1) i moment tej zmiany nie koniecznie pokrywa się z momentem zmiany komunikatu RPI, co widać poniżej:


Czas i okres tej zmiany (zazwyczaj co 15minut) jest dosyć charakterystyczny dla konkretnego urządzenia, podobnie zresztą jak interwał pomiędzy rozgłaszanymi komunikatami:


Jest jeszcze klucz IRK. Możemy go poznać jeżeli parowaliśmy się z urządzeniem które chcemy śledzić. W przypadku Windows można to zrobić podglądając zawartość rejestru (klucz HKLM\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys) przy pomocy narzędzia psexec:



Co z tego wszystkiego wynika? Kilka ciekawych wniosków, co możemy z tym wszystkim zrobić:

  • Śledzić smartfon jeżeli będzie pozostawać w zasięgu naszych odbiorników. Czyli możliwe jest śledzenie ruchu osoby w obrębie zamkniętej lokalizacji

  • Śledzić smartfon w oparciu o klucz IRK o ile w jakiś sposób uzyskaliśmy ten klucz, co nie koniecznie będzie łatwe

  • Udowodnić komuś, że przebywał w wybranej lokalizacji. Może to zrobić np. policja po aresztowaniu i wyciągnięciu klucza IRK oraz uzyskaniu logów np. z galerii handlowej

  • Nawet jeżeli zostanie udostępniony cały kod źródłowy obsługujący protokół G+A do wglądu przez osoby trzecie i nikt nie wykryje w nim żadnych mechanizmów zaprojektowanych do śledzenia użytkowników, dla Google i Apple śledzenie użytkowników po adresach MAC będzie banalnie proste. Wcześniej nie koniecznie mieli tego typu możliwości, ponieważ ludzie co do zasady nie chodzili z smartfonami rozgłaszającymi swoją obecność

  • Równie dużym zagrożeniem dla prywatności są popularne ostatnio wszelkiego rodzaju smartbandy, które bez skrępowania rozgłaszają swoją obecność. Pytanie czy trudno byłoby śledzić osobę rozgłaszającą równocześnie komunikaty G+A?

Czy zatem powinniśmy zainstalować na swoim smartphonie aplikację ProtegoSafe i wziąć udział w tym eksperymencie? Oczywiście decyzję każdy powinien podjąć samodzielnie, a dzięki temu wpisowi można ją podjąć świadomie, wiedząc na co się człowiek pisze.

Na zakończenie, jeżeli kogoś zainteresował temat, to polecam całą dyskusję na github, natomiast osoby lubiące eksperymenty mogą się zainteresować narzędziem bentool, które rozwijałem w trakcie przyglądania się protokołowi G+A (ewentualnie zerknąć na skrypty od jasisz).