Jak deanonimizować użytkowników z włączonym BT

[SeraMoon]

Describe the bug Ponieważ z założenia BT ma być włączony cały czas, zaś ludzie mają ograniczoną możliwiść szybkości poruszania się - za pomocą anten wyłapujących sygnał BT, w tym analizujących modulację oraz inne właściwości sygnału oraz biorąc fakt, że prędkość światła jest w naszym układzie słonecznym w miarę stała - można tworzyć na bieżąco w galeriach handlowych (ale nie tylko) mapę punktów, które nadają sygnał BT (ok. 2.4GHz).

Powoduje to, że można ustawić w galerii 4 anteny połączone z komputerem i każdy odbiornik z zegarem atomowym i zabawić się w "odwrotny GPS", czyli zamiast tego, że satelita GPS wysyła nam swój czas a my go odbieramy i stwierdzamy, gdzie jesteśmy na mapie, następuje odwrócenie kontroli i to charakterystyka naszego sygnału jest mierzona z jakim przesunięciem czasowym dotrze do każdej z anten. Na tej podstawie liczymy gdzie znajduje się nadajnik. Teraz system zna pozycję użytkownika i zmieniony identyfikator.

Ponieważ ludzie często w galeriach stoją lub też przemieszczają się powolnie - można skorelować zmienione tmpID2 z tmpID1, zakładając, że użytkownik nie wykonał teleportacji (wciąż jest w tym samym miejscu galerii lub blisko!).

Dzięki sztucznej inteligencji (są znane już algorytmy śledzące podobnie w oparciu o wizerunek twarzy) można zebrać wszystkie tmpID użytkownika dopóki nie wyjdzie z zasięgu anten odbiorczych.

Ten scenariusz można oczywiście rozszerzyć na całe miasto ustawiając anteny w odpowiedniej odległości by "słyszały" głośny radiowo telefon użytkownika, który nonstop nadaje sygnał.

Całość przedstawiam na rysunku.

To Reproduce

Nie ma zastosowania - nie trzeba mieć nawet aplikacji, wystarczy nadawać przez BT.

Expected behavior

Nieskorelowane TmpID1 z TmpID2... tylko jak to zrobić?

Screenshots

Desktop (please complete the following information): Jest zbędny

Smartphone (please complete the following information): Dowolny z aktywnym BT.

Additional context Brak zastosowania - atak może być dokładniejszy od GPS, z którego zrezygnowano. Daję do przemyślenia, czy ciągle nadający użytkownik na pewno pozostaje anonimowy i czy nie da się go śledzić mimo zmieniającego się tmpID.

Jak wykryć atak: nie da się - atak należy do ataków wykonywanych metodą cichą, bez nadawania dodatkowego sygnału.

[Dr-Kownacki]

Piękny pomysł ale uproszę jeszcze bardziej i "old-schoolowo": Pamiętacie przygody J-23 i "namierzanie/polowanie na radiostację" przez Niemców ? ;-)

Stary numer z antenami kierunkowymi i tzn. pelengacją radiową (polowanie na lisa etc.).

Zamiast "kręcenia antenami" (jak w "Stawce.." ) i znajdowania azymutu i kąta przecięcia wystarczy zrobić dwie matryce gęstych anten na 360 stopni gdzie na podstawie fizycznego (i ew. RSSI) pomiaru siły sygnału można namierzyć wszystko i wszędzie jeśli tylko ten sygnał "doleci".
Dwa azumuty, punkt przecięcia i już wiadomo gdzie jest nadajnik, żadna nowość :-)

Ewentualny "frequency hooping" może być tutaj przeszkodą przy transmisjach w protokole BT, natomiast jest to już dawno zhackowane (BLE ponoć łatwiejszy do cracku niż "stary" BT), wszystko na YT pod hasłem "Ubertooth" i wszystko jasne.

W punkcie przecięcia w hipotetycznym sklepie są kamery CCTV i generalnie rozwiązanie gotowe. Utrudnione jedynie w sytuacji po prostu "tłumu" gdzie każdy ma włączony tracing. Potem już tylko AI, śledzenie twarzy/osób, "odprowadzenie przez AI każdego na parking" i zalogowanie jego tablicy rejestracyjnej. Ale ja tutaj nie raczej nie odkrywam Ameryki, to są od dawna stosowane techniki i nie ma co się nakręcać niepotrzebnie chyba... Zabawki do tego w/w. można sobie zakupić na Allegro, jak już wcześniej w innych wątkach sygnalizowałem :-)

Natomiast sprytny przykład podało EEF do "wtórnego odkodowywania" przemieszczania się/lokalizowania osób które "ujawniły swoje klucze" (jak w API A+G):

https://www.eff.org/deeplinks/2020/04/apple-and-googles-covid-19-exposure-notification-api-questions-and-answers

Hipotetyczna matryca anten "w terenie" wyłapuje rozgłaszane klucze, a potem: If someone uploads their daily diagnosis keys to a central server, a bad actor could then use those keys to link together multiple RPID pings. This can expose their daily routine, such as where they live and work.

Chciałoby się zacytować "Nie ze mną te numery Bruner" no ale chyba nie można. i się nie da.

[SeraMoon]

Do całości dodajmy sieć kamer w galerii - można tmpID przypisać do twarzy :joy_cat: a już kilka krajów korzysta z jakiegoś systemu do rozpoznawania ludzi na podstawie twarzy - dane zebrano nielegalnie (lub półlegalnie - każdy kto ma FB powinien się z tym liczyć!) z serwisów społecznościowych...

Dzisiejsza technika daje piękne możliwości deanonimizacji. Już za czasów J-23 było to dość rozbudowane, teraz jest jeszcze bardziej - prawie doskomałe.

BTW. poleganie na kształcie sygnału (różny zależnie od tmpID) jest leposze od polegania na RSSI w terenie zabudowanym / przemieszanym innymi ludźmi / telefon w kieszeni itp. O ile RSSI można oszukać - czas (a więc odległość) ciężej oszukać.

Dobrze,m że kazali nam nosić te maski. 😹 Ma to przynajmniej tą jedną zaletę, poza wadą, że wracam półprzytomna z zakupów. Życzę miłego uprawiania sportu na siłowni w takiej masce XD.

[adrb]

Pamiętajcie, że to ministerstwo generuje identyfikator tmpID, zatem wie który użytkownik w danym momencie się nim posługuje. Wystarczy więc zrobić nasłuch komunikatów BLE. Teraz, osoba która przeszła przez kilka takich punktów "nasłuchowych", może zostać z wysokim prawdopodobieństwem zidentyfikowana, bez potrzeby użycia "kosmicznych technologi".

Teraz kolejna sprawa to adresy MAC urządzenia i ich powiązanie z rozgłaszanym tmpID, co umożliwia całe spektrum różnorakich ataków, włączenie ze śledzeniem pojedynczych użytkowników.

[SeraMoon]

@adrb, czyli podsumowując, nawet najbardziej starając się zachować prywatność użytkownika i tak będą możliwe dość proste ataki i deanonimizacja użytkowników, jeżeli będzie włączone rozsyłanie czegokolwiek "anonimowego"?

Możesz przybliżyć na czym polega atak na MAC urządzenia w tym scenariuszu? W sensie jak powiązać adres MAC karty sieciowej z tmpID lub samym sygnałem BT?

[matsobdev]

Chociażby wykorzystując to, że BT jest dziurawy. Jakiś czas temu odkryto lukę w implementacji (BlueBorne), która pozwala podłączyć się do telefonu (niejawnie i uzyskać dostęp do np. plików, mikrofonu), nawet kiedy ten nie rozgłasza swojej nazwy, bo i tak w tle szuka sparowanych ze sobą urządzeń, z którymi się może połączyć, bo te chcą się połączyć z telefonem o określonym adresie MAC. Nie wszyscy mają aktualny sofy, bo np. już aktualizacje się skończyły albo sami nie aktualizują. Ponoć tylko dotknęło to klasyczny BT, BLE był od tego wolny. W Androidzie Adapter Bluetooth można enable() lub enableBle(), ale to drugie to cześć ukrytego API, tak więc, żeby tylko korzystać z BLE trzeba włączyć cały BT razem z BLE. Z ciekawości kiedyś zrobiłem apkę z tym ukrytym enableBle(), ale na Samsungu S6 5.0 wyrzuciło, że nie ma takiej metody. Usługa od Google będzie mogła więcej... (na plus).

[potiuk]

@adrb, czyli podsumowując, nawet najbardziej starając się zachować prywatność użytkownika i tak będą możliwe dość proste ataki i deanonimizacja użytkowników, jeżeli będzie włączone rozsyłanie czegokolwiek "anonimowego"?

Tego problemu jest kompletnie pozbawiony https://www.apple.com/covid19/contacttracing/ - w protokole A+G RPI (Rolling Proximity Identifier) jest generowany na urządzeniu i nigdy nie jest wysyłany inaczej niż przez bluetooth.

Chociażby wykorzystując to, że BT jest dziurawy. Jakiś czas odkryto lukę w implementacji (BlueBorne), która pozwala podłączyć się do telefonu (niejawnie i uzyskać dostęp do np. plików, mikrofonu), nawet kiedy ten nie rozgłasza swojej nazwy, bo i tak w tle szuka sparowanych ze sobą urządzeń, z którymi się może połączyć, bo te chcą się połączyć z telefonem o określonym adresie MAC. Nie wszyscy mają aktualny sofy, bo np. już aktualizacje się skończyły albo sami nie aktualizują. Ponoć tylko dotknęło to klasyczny BT, BLE był od tego wolny. W Androidzie Adapter Bluetooth można enable() lub enableBle(), ale to drugie to cześć ukrytego API, tak więc, żeby tylko korzystać z BLE trzeba włączyć cały BT razem z BLE. Z ciekawości kiedyś zrobiłem apkę z tym ukrytym enableBle(), ale na Samsungu S6 5.0 wyrzuciło, że nie ma takiej metody. Usługa od Google będzie mogła więcej... (na plus).

Dokładnie tak. BLE jest o wiele bardziej bezpieczny a dodatkowo - w przypadku "Advertisments" - pisaliśmy o tym wcześniej jest już od wielu lat (i praktycznie we wszystkich modelach telefonów używanych obecnie w Polsce) anonimizacja MAC-ów (po prostu co 15 minut zmienia się adres MAC na losowy). Dokładna lektura protokołu Google + Apple (https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf) mówi o tym nawet że zmiany RPI i Advertising Adress powinny być synchronizowane:

" On platforms supporting the Bluetooth Random Private Address with a randomized rotation timeout interval, the advertiser address rotation period shall be a random value that is greater than 10 minutes and less than 20 minutes. • The advertiser address, Rolling Proximity Identifier, and Associated Encrypted Metadata shall be changed synchronously so that they cannot be linked. "

[adrb]

@adrb, czyli podsumowując, nawet najbardziej starając się zachować prywatność użytkownika i tak będą możliwe dość proste ataki i deanonimizacja użytkowników, jeżeli będzie włączone rozsyłanie czegokolwiek "anonimowego"?

Wydaje sie, że przy obecnej architekturze ProteGO-Safe deanonimizacja użytkowników jest relatywnie łatwa dla rządowych instytucji. Poza tym umożliwia pasywne śledzenie wybranej osoby np. w obrębie galerii handlowej.

Możesz przybliżyć na czym polega atak na MAC urządzenia w tym scenariuszu? W sensie jak powiązać adres MAC karty sieciowej z tmpID lub samym sygnałem BT?

Polecam lekture np: Tracking-Anonymized-Bluetooth-Devices.pdf

" On platforms supporting the Bluetooth Random Private Address with a randomized rotation timeout interval, the advertiser address rotation period shall be a random value that is greater than 10 minutes and less than 20 minutes. • The advertiser address, Rolling Proximity Identifier, and Associated Encrypted Metadata shall be changed synchronously so that they cannot be linked. "

Synchroniczna zmiana RPI oraz Advertising Adress, utrudnia ale nie uniemożliwia identyfikacji. Możemy w różny sposób próbować korelować obserwowane zdarzenia, oraz dodatkowo tworzyć odciski na podstawie danych, które urządzenia ujawniają w sposób nie zamierzony. Przy czym to jest już raczej wskazanie kierunku dla dalszych badań, jak stwierdzenie faktu.

Na tą chwile wydaje mi się (podkreślam ze to tylko moja opinia nie podparta rzetelnymi danymi), że RPI oraz synchroniczna zmiana adresu MAC sprawiają, że deanonimizacja jest wystarczająco trudna w przypadku protokołu A+G. Pozostają jednak inne ataki, na sam protokół. Wystarczająco zmotywowana osoba będzie w stanie dalej sporo namieszać. Prawdopodobnie jednak, będziemy musieli się z tym pogodzić, podobnie jak z dziurami w innych protokołach obecnie szeroko wykorzystywanymi w internecie.

[potiuk]

Na tą chwile wydaje mi się (podkreślam ze to tylko moja opinia nie podparta rzetelnymi danymi), że RPI oraz synchroniczna zmiana adresu MAC sprawiają, że deanonimizacja jest wystarczająco trudna w przypadku protokołu A+G. Pozostają jednak inne ataki, na sam protokół. Wystarczająco zmotywowana osoba będzie w stanie dalej sporo namieszać. Prawdopodobnie jednak, będziemy musieli się z tym pogodzić, podobnie jak z dziurami w innych protokołach obecnie szeroko wykorzystywanymi w internecie.

Też mam takie wrażenie. Jeden z takich ataków zaproponowany przez @Dr-Kownacki jest opisany tu #109 - i faktycznie wydaje się dość ciekawym (i wykonalnym) atakiem, a jednocześnie wygląda na to że w protokole G+A jest miejsce na zabezpieczenie się przed tym w przyszłości (szczegóły w wątku #109 )

I tu jeden komentarz - z ciekawych rzeczy ten protokół i jego natura jest o tyle ciekawy ze nigdy nie będzie więcej niż 2 tygodnie danych na telefonach i na serwerze, więc spokojnie można wprowadzać drobne zmiany dość szybko nie przejmując się o wersje sprzed 2 tygodni. To sprawia że mozna bedzie szybko reagowac na jakies nowe pomysly atakow

[Dr-Kownacki]

Z ciekawostek: dorzucę tutaj że ( z tego co wiem) @kierepka napisał o potencjalnej luce ze #109 chyba nawet bezpośrednio do... Tim'a Cook'a.

W razie czego: my ostrzegaliśmy :-)

Jeśli te opisywane w #109 "wolne bajty" etc. zostaną wykorzystane celem zapobiegania takim atakom to będzie dobra decyzja. Jeżeli nie to nadal zabezpieczenie jakieś "na poziomie aplikacji" da się pewnie wprowadzić żeby to spróbować załatać jakoś...

[rafaljanicki]

Ja tylko dodam, ze triangulacja konkretnego telefonu na podstawie tylko 4 odbiornikow w danej galerii jest bardzo, ale to bardzo nieprecyzjne. ToF sygnalu (=dB) potrafi sie drastycznie zmienic pomiedzy pojedynczymi odbiorami, a tlumaczenie tego na metry jest karkolomne i podobnie niestabilne. Dodatkowo, chociaz ten pomysl o tym nie wspomina na pierwszy rzut oka, mamy klopoty z identyfikacja - np. od 5-6 lat iOS randomizuje i zmienia co jakis czas adresy MAC

Innymi slowy, jest to atak o prawdopodobienstwie bliskim zeru w obecnym rezimie technologicznym.

P.S. Jezeli juz chcialbym sledzic uzytkownikow w galerii (co jest robione), to nie czterema, a czterystoma malymi nadajnikami, ktore sprawdzaja jaki sygnal kolo nich przechodzil i na podstawie tego robil mape. Ale to juz sie dzieje tak ze ma to tyle do ProteGO-Safe co sledzenie za pomoca fal 3-5G

[pebog79636]

Opinia Panoptykonu: https://panoptykon.org/protego-safe-ryzyka

[potiuk]

Opinia Panoptykonu: https://panoptykon.org/protego-safe-ryzyka

Absoolutnie polecam!

[dbielawsd]

Describe the bug Ponieważ z założenia BT ma być włączony cały czas, zaś ludzie mają ograniczoną możliwiść szybkości poruszania się - za pomocą anten wyłapujących sygnał BT, w tym analizujących modulację oraz inne właściwości sygnału oraz biorąc fakt, że prędkość światła jest w naszym układzie słonecznym w miarę stała - można tworzyć na bieżąco w galeriach handlowych (ale nie tylko) mapę punktów, które nadają sygnał BT (ok. 2.4GHz).

Powoduje to, że można ustawić w galerii 4 anteny połączone z komputerem i każdy odbiornik z zegarem atomowym i zabawić się w "odwrotny GPS", czyli zamiast tego, że satelita GPS wysyła nam swój czas a my go odbieramy i stwierdzamy, gdzie jesteśmy na mapie, następuje odwrócenie kontroli i to charakterystyka naszego sygnału jest mierzona z jakim przesunięciem czasowym dotrze do każdej z anten. Na tej podstawie liczymy gdzie znajduje się nadajnik. Teraz system zna pozycję użytkownika i zmieniony identyfikator.

Ponieważ ludzie często w galeriach stoją lub też przemieszczają się powolnie - można skorelować zmienione tmpID2 z tmpID1, zakładając, że użytkownik nie wykonał teleportacji (wciąż jest w tym samym miejscu galerii lub blisko!).

Dzięki sztucznej inteligencji (są znane już algorytmy śledzące podobnie w oparciu o wizerunek twarzy) można zebrać wszystkie tmpID użytkownika dopóki nie wyjdzie z zasięgu anten odbiorczych.

Ten scenariusz można oczywiście rozszerzyć na całe miasto ustawiając anteny w odpowiedniej odległości by "słyszały" głośny radiowo telefon użytkownika, który nonstop nadaje sygnał.

Całość przedstawiam na rysunku.

To Reproduce

Nie ma zastosowania - nie trzeba mieć nawet aplikacji, wystarczy nadawać przez BT.

Expected behavior

Nieskorelowane TmpID1 z TmpID2... tylko jak to zrobić?

Screenshots

Desktop (please complete the following information): Jest zbędny

Smartphone (please complete the following information): Dowolny z aktywnym BT.

Additional context Brak zastosowania - atak może być dokładniejszy od GPS, z którego zrezygnowano. Daję do przemyślenia, czy ciągle nadający użytkownik na pewno pozostaje anonimowy i czy nie da się go śledzić mimo zmieniającego się tmpID.

Jak wykryć atak: nie da się - atak należy do ataków wykonywanych metodą cichą, bez nadawania dodatkowego sygnału.

Wydaje się, iż podejście do triangulacji opartej o propagację fal radiowych jest już świetnie opisane literaturze, a zatem czy jesteśmy pewni odnośnie konieczności zajmowania się tym tematem. Mam nieodparte wrażenie, że to nie jest zakres ProteGO - Safe

[KoderFPV]

Założenia projektowe uległy zmianie, obecnie wdrażana wersja to rozwiązanie oparte o Exposure Notifications od Google i Apple w związku z tym ten wątek się zdezaktualizował. Prośba do autora o zamkniecie wątku.

[jasisz]

@Tarvald Wątek jest dalej aktualny - to samo ma zastosowanie przy rozwiązaniu Google i Apple.

[jasisz]

Tak z moich eksperymentów na kolanie łatwo jest heurystycznie połączyć kolejne nadawane TempID, z samego "zachowania".

Podczas zmiany charakterystyczne jest że:

• stary identyfikator przestaje być nadawany
• nowy identyfikator jest nadawany, ale jest widoczna charakterystyczna krótka przerwa, a nowy identyfikator nie pokrywa się interwałem 280ms ze starym
• dodaję do tego drobną heurystyke że RSSI nie zmienia się "bardzo", która jest pewnie do pominięcia

Prawdopobieństwo nałożenia się takich przerw i pomyłki jest niewielkie i wprost zależne od liczby urządzeń w okolicy. Pojawienie się nowego urządzenia musiałoby się zbiegać w czasie ze zniknięciem innego. W bardzo dynamicznym środowisku (typu galeria handlowa) jest to pewnie utrudnione i wymagałoby synchronizacji z paru punktów, ale wydaje się być jak najbardziej wykonalne.

Bawiłem się w domu na trzech telefonach, które sobie wędrowały, skuteczność łączenia kolejnych "odsłon" urządzenia oceniam na ponad 90%, a działam na upośledzonym na MacOS stacku CoreBluetooth.

Dwa razy natknąłem się na to, że MAC został zmieniony ale wysyłane dane pozostały te same - musi istnieć jakiś corner case z nakładaniem się okien MAC i Exposure Notifications, chociaż miało być to wyeliminowane przez zsynchronizowanie tych zmian.

[adrb]

• nowy identyfikator jest nadawany, ale jest widoczna charakterystyczna krótka przerwa, a nowy identyfikator nie pokrywa się interwałem 280ms ze starym

Dwa pytania. 1. Z którą aplikacją testowałeś? Ten interwał jest charakterystyczny dla aplikacji i możliwe że tez dla modelu urządzenia.

2. Testowałeś może z iPhone? Z tego co zauważyłem one się dosyć mocno rozgłaszają i pytanie jest czy po włączeniu aplikacji, iPhone dalej rozgłasza swoją obecność + komunikaty EN.

• dodaję do tego drobną heurystyke że RSSI nie zmienia się "bardzo", która jest pewnie do pominięcia

Czemu do pominięcia? RSSI przecież powinien się wpasowywać w "sinusoidę", sygnał się zbliży a potem oddali, czasem "zatrzyma", ale generalnie raczej nie będzie sytuacji że nagle zniknie lub się pojawi znikąd będąc dobrze słyszalnym, dokładnie w tym samym czasie co powinna nastąpić zmiana EN.

RSSI mogłoby być też przydatne do określenia czy źródło sygnału weszło lub opuściło zasięg odbiornika, co mogłoby być kolejną wskazówką przy wątpliwych przypadkach.

Na pewno sporo może zależeć od wyboru miejsca do nasłuchu i wcześniejszego poznania jego "charakterystyki".

Dwa razy natknąłem się na to, że MAC został zmieniony ale wysyłane dane pozostały te same - musi istnieć jakiś corner case z nakładaniem się okien MAC i Exposure Notifications, chociaż miało być to wyeliminowane przez zsynchronizowanie tych zmian.

Tzn urządzenie po zmianie adresu MAC generowało dalej te same dane przez cały interwał EN? Czy może tylko pierwszy pakiet miał nie zmienione dane?

[jasisz]

Z którą aplikacją testowałeś? Ten interwał jest charakterystyczny dla aplikacji i możliwe że tez dla modelu urządzenia.

Testowałem z trzema aplikacjami - Immuni (Włochy), Apturi Covid (Łotwa) i wczoraj z ProteGO Safe - wszystkie korzystają z Exposure Notification API i wszystkie mają ten sam interwał 280ms na trzech telefonach z Androidem na których próbowałem.

Wczoraj trochę zmieniłem skrypt, pomijając ten warunek że "psuje się interwał" i po prostu linkując pierwsze urządzenie, które zaczyna się rozgłąszać po tym jak przestało stare, a wyniki się nie zmieniły.

Z CoreBluetooth na Mac OS X jest taki problem, że nie można mu podać interwałów skanowania, więc trzeba mieć trochę szczęścia żeby trafić na ten nowy pakiet - u mnie w praktyce zajmuje to od około sekundy do +/- 10 sekund. Ciekawe jak szybko jest on wysyłany tak naprawdę, bo może to być częścia algorytmu linkowania ;)

Testowałeś może z iPhone? Z tego co zauważyłem one się dosyć mocno rozgłaszają i pytanie jest czy po włączeniu aplikacji, iPhone dalej rozgłasza swoją obecność + komunikaty EN.

Niestety nie mam teraz dostępu do iPhone.

Czemu do pominięcia? RSSI przecież powinien się wpasowywać w "sinusoidę", sygnał się zbliży a potem oddali, czasem "zatrzyma", ale generalnie raczej nie będzie sytuacji że nagle zniknie lub się pojawi znikąd będąc dobrze słyszalnym, dokładnie w tym samym czasie co powinna nastąpić zmiana EN.

Masz rację, takie miałem założenie, jest to pewna heurystyka ale rzeczywiście w praktyce wydaje się sprawdzać.

Tzn urządzenie po zmianie adresu MAC generowało dalej te same dane przez cały interwał EN? Czy może tylko pierwszy pakiet miał nie zmienione dane?

Kiedy się to zdarza to taka sytuacja trwa około 3 minut.

EDIT: Może to też być tylko przypadłość CoreBluetooth, bo w nim tak naprawdę nie mam dostępu do MAC, tylko do UUID które go przykrywa. Jest szansa że CoreBluetooth coś tam miesza, ale chyba jest to tylko proste MAC->losowy UUID (ale różne an różnych urządzeniach skanujących).

EDIT 2: Udało mi się te samą sytuację złapać na telefonie z androidem :) Więc chyba jest tak faktycznie: Mój log:

2020-06-09 09:20:18.808122: 017DE10F-B13B-482A-AA42-3F2D7EC585D2 (45a0f84eb388b30a31d1009565550c5eafc8e678) is now 4627FD69-0671-4E68-927F-A796E87F0626 (45a0f84eb388b30a31d1009565550c5eafc8e678) after gap of 12571ms

Screen z Androida:

[adrb]

Jeżeli payload mimo wszystko się zmienia po jakimś czasie, to znaczy że prawdopodobnie czasem szyfrowanie danych trwa znacznie dłużej niż powinno lub z jakiegoś powodu się nie powiodło za pierwszym razem (zwykle oznacza to problemy z pulą entropii).

Jak będę mieć chwilę to przetestuje jak to wygląda u mnie na bluez, ostatnio nie śledzę tego tematu i nie wiedziałem nawet, że aplikacje z G+A już są.

[jasisz]

@adrb Na CoreBluetooth i z moimi Androidami wygląda to tak, że potem kiedy po tych 3 minutach faktycznie zmieni się payload to zmienia się też UUID. Ale tak jak pisałem - niekoniecznie musi to znaczyć ze zmienił się faktycznie MAC ;) Przykład jednego urządzenia przefiltrowany:

2020-06-09 11:21:24.652258: B3DC1FBE-4A7E-48F4-86A9-FFF3DC8565D3 (de78adcd43bb56d8681ab10ca2d86fb293817db0) is now 84088E72-3CC3-412B-98E7-84566EFBF5B7 (003c6b2d6ddc602016615951890220e525b978ba) after gap of 1201ms
2020-06-09 11:36:22.853442: 84088E72-3CC3-412B-98E7-84566EFBF5B7 (003c6b2d6ddc602016615951890220e525b978ba) is now 4D2560F3-7233-4BE8-ADA8-825AAEF47A24 (003c6b2d6ddc602016615951890220e525b978ba) after gap of 6603ms
2020-06-09 11:39:15.361957: 4D2560F3-7233-4BE8-ADA8-825AAEF47A24 (003c6b2d6ddc602016615951890220e525b978ba) is now 93F95F4C-C5B0-4761-A8A9-624458B5A6C2 (88a24512097ea047aa8497c52f4270073c22ca1b) after gap of 2133ms

Czekam na wyniki Twoich eksperymentów! U mnie zdarza się to dość często, początkowo myślałem że to jakiś mój bug...

EDIT: ale teraz widzę że chyba faktycznie mam buga i prawdą może być to co piszesz, że po prostu zmiana service data nie nadążą za zmiana MAC, sprawdzam to. EDIT 2: chyba wychodzi na to samo.

[adrb]

@adrb Na CoreBluetooth i z moimi Androidami wygląda to tak, że potem kiedy po tych 3 minutach faktycznie zmieni się payload to zmienia się też UUID. Ale tak jak pisałem - niekoniecznie musi to znaczyć ze zmienił się faktycznie MAC ;)

Właśnie dlatego swoje narzędzie (bentool) napisałem w C pod Linuksem, gdzie mam bezpośredni dostęp do interfejsu HCI. Omijam w ten sposób wszystkie ograniczenia i niedoróbki bibliotek.

Czekam na wyniki Twoich eksperymentów! U mnie zdarza się to dość często, początkowo myślałem że to jakiś mój bug...

EDIT: ale teraz widzę że chyba faktycznie mam buga i prawdą może być to co piszesz, że po prostu zmiana service data nie nadążą za zmiana MAC, sprawdzam to. EDIT 2: chyba wychodzi na to samo.

Poprawiłem kod i dorobiłem śledzenie mniej więcej według Twojego algorytmu i ta dam, u mnie też widać ten sam problem :)

Device has changed only EN data from 2020-06-13 04:33:53.951 - BD 68:93:4F:42:38:E2, RSSI -76, RPI: be95d32663d2ec9b1613a4f4654c1276, AEM: cd827cb9 to 2020-06-13 04:33:54.211 - BD 68:93:4F:42:38:E2, RSSI -65, RPI: 46f35404d9380fca13851f2532b9629e, AEM: 0ec95706

Device has changed only EN data from 2020-06-13 06:10:20.340 - BD 68:A9:26:EB:B1:08, RSSI -65, RPI: 62e1e15fee4c8825de2a4e03029eeb52, AEM: c842db0d to 2020-06-13 06:10:20.604 - BD 68:A9:26:EB:B1:08, RSSI -72, RPI: 48d0e1268c2d973c6dfb7f98024231ea, AEM: f498be51

Device has changed only EN data from 2020-06-13 09:10:55.894 - BD 77:8A:DD:CF:3B:9F, RSSI -77, RPI: 2ae83b325a8330f805eea5b9989d5e55, AEM: 9b6ac89f to 2020-06-13 09:10:56.155 - BD 77:8A:DD:CF:3B:9F, RSSI -65, RPI: b6aff24e1d8c0b869bf3d879b7b00cc9, AEM: 1acc77e3

Device has changed only EN data from 2020-06-13 10:50:10.682 - BD 4E:70:DB:F8:70:A8, RSSI -76, RPI: 20a97a5e4ecdd1efdc7d5fa4c1cff727, AEM: 87e99d1c to 2020-06-13 10:50:10.942 - BD 4E:70:DB:F8:70:A8, RSSI -65, RPI: a712190d335cfc406f4eea33f0a2603b, AEM: 822ebb48

Dodatkowo zauważyłem, że czasami rozgłaszanie milknie na dłuższy czas, np godzinę. Ciężko powiedzieć, czy to jest problem sprzętowy czy z samą aplikacją w telefonie. Na pewno nie z moim kodem bo weryfikowałem z drugiego telefonu by potwierdzić brak komunikatów BLE.

Jakby ktoś chciał się tym pobawić to zrobiłem screenshot z testów. Na konsoli na dole uruchomiłem skanowanie, a na konsoli u góry modyfikowałem rozgłaszane dane (poleceniem dev wybieram z którego urządzenia BT chce korzystać, mam dwa w tej maszynie).

Po skanowaniu trzeba wydać polecenie 'track', by przejść algorytmem zebrane dane, nie chciałem robić tego na "żywca" by czasem nie gubić pakietów.

Zbieram tez wszystkie inne komunikaty z danego urządzenia, jednak na razie ich nie analizuje, ale pewnie coś drobie. W tym momencie chciałem tylko potwierdzić Twoje obserwacje i to się udało :)

[adrb]

Mały update.

Zmiana adresu następuje w każdym interwale. Nie wygląda to na błąd czy niedopatrzenie. Okres rozsyłania komunikatu wydaje się losowy, w granicach 10-15 minut, jednak czas zmiany już nie koniecznie (da się wyłapać punkty które się powtarzają co godzinę z dokładnością do kilkunastu sekund).

Dodałem opcję eksportujaca złapane dane do pliku CSV, by ułatwić import do bazy danych. Może ktoś będzie się chciał pobawić w wyszukiwanie jakichś statystycznych zależności.

[jasisz]

@adrb To mnie właśnie dziwi, bo według https://blog.google/documents/70/Exposure_Notification_-_Bluetooth_Specification_v1.2.2.pdf

• On platforms supporting the Bluetooth Random Private Address with a randomized rotation timeout interval, the advertiser address rotation period shall be a random value that is greater than 10 minutes and less than 20 minutes.
• The advertiser address, RollingProximityIdentifier, and Associated Encrypted Metadata shall be changed synchronously so that they cannot be linked.

A i Twoje i moje obserwacje temu przeczą.

[SeraMoon]

@adrb i @jasisz dobra robota. Jak widać zapewnienia Google można włożyć między bajki.

Reszty przez to, że jest zamknięta, jak też samego sprawdzania przesyłania identyfikatora na PIN (z powodu braku ścieżki testu) - nie sprawdzimy. Należy jako społeczność i jako Państwo (Ministerstwo Cyfryzacji - za pośrednictwem @MateuszRomanow ) wystąpić o bezwzględne udostępnienie społeczności GitHub kodu źródłowego Exposure Notification. Skoro błędy wychodzą aż tak na wierzchu - schowanych będzie dużo więcej.

@Tarvald - ponieważ wątek się dalej toczy, a powyższy ( z pierwszego posta) atak jest możliwy, jak też przedstawione przez @jasisz'a i @adrb'a ataki są możliwe - temat powinien zostać otwarty.

Obecnie wątek należy traktować jako "Jak deanonimizować użytkowników z włączonym BT" niezależnie od treści pierwszego posta, bo jak widać anonimowość Exposure Notification jest szyta grubymi nićmi (MAC i diagnosis key rozjeżdżają się umożliwiając śledzenie). Przy takim asynchronicznym działaniu to mija się z celem zmienianie tego klucza co 15 minut.

czy rozwiązaniem nie byłoby wysyłanie diagnosis key z losowym adresem MAC lub zawsze zerowym (tego my nie rozwiążemy - to mógł zrobić Google)?

System z wyścigami...?

[adrb]

Obecnie wątek należy traktować jako "Jak deanonimizować użytkowników z włączonym BT" niezależnie od treści pierwszego posta, bo jak widać anonimowość Exposure Notification jest szyta grubymi nićmi (MAC i diagnosis key rozjeżdżają się umożliwiając śledzenie). Przy takim asynchronicznym działaniu to mija się z celem zmienianie tego klucza co 15 minut.

To nie jest tak do końca. Adres i rozgłaszane dane zmieniaj się co 10-15minut, i w każdym tym przedziale czasu następuje jeszcze dodatkowa zmiana adresu. Nie jest to zgodne z opisanym standardem, ale z drugiej strony ciężko powiedzieć w tym momencie, czy zwiększa "powierzchnie ataku".

Nie mam natomiast wątpliwości, że jest możliwe śledzenie przybliżonej pozycji ludzi jeżeli poruszają się w ramach jakiegoś zamkniętego kompleksu.

czy rozwiązaniem nie byłoby wysyłanie diagnosis key z losowym adresem MAC lub zawsze zerowym (tego my nie rozwiążemy - to mógł zrobić Google)?

Nie. Problemem jest sam BT który nie był projektowany z myślą o tego rodzaju komunikacji.

Zasadniczo wszystko się rozbija o to, czy możemy ufać że Google i Apple nie będą wykorzystywać zgromadzonych danych w inny sposób jak zadeklarowali. Czemu np. nie mogliby wyciągać (nawet zdalnie), kluczy z urządzenia i przekazywać je instytucji rządowym?

System z wyścigami...?

Możesz wyjaśnić o co chodzi?

[SeraMoon]

Możesz wyjaśnić o co chodzi?

@adrb, sorry, nie zauważyłam, że zmienia się liczba minut w logu, czyli, że posortowane jest po innym kryterium niż czas.

Jednak nadal nieczyste jest to, że działa to inaczej niż opisano i pozostawia podejrzenia odnośnie EN.

Czemu np. nie mogliby wyciągać (nawet zdalnie), kluczy z urządzenia i przekazywać je instytucji rządowym?

Tego się nigdy nie dowiemy jako obywatele.

Nie mam natomiast wątpliwości, że jest możliwe śledzenie przybliżonej pozycji ludzi jeżeli poruszają się w ramach jakiegoś zamkniętego kompleksu.

Przy komunikacji radiowej - gdy się ktoś uprze, to prawie zawsze będzie to możliwe. Pytaniem pozostaje - jakie większe korzyści da to osobie śledzącej niż śledzenie użytkownika po wizerunku twarzy na obiekcie, gdzie i tak są kamery CCTV. Co dają atakującemu zebrane wartości w postaci kluczy diagnosis key oraz MAC połączone z konkretną osobą.

[jasisz]

@adrb W pierwotnej wersji Exposure Notification zmiana RPI nie miała być synchronizowana ze zmianą MAC. Stwierdzono, że pozwala to łatwiej linkować urządzenia i zmieniono na to, co wklejałem.

Też to traktuję bardziej jako ciekawostkę i zabawną niezgodność z dokumentacją (może pozostałość po starych założeniach, może zwyczajny bug). A być może powód jest tak prozaiczny, że MAC na tych konkretnych urządzeniach zmienia się częściej niż co ten okres założony w Exposure Notifications i brakuje jeszcze nowego klucza do nadawania (a to jest słabość protokołu, który mógłby je jakoś rotować).

Dalej w mocy pozostaje ten główny "probabilistyczny" sposób linkowania zmieniających sie RPI. Śledzenie czyjejś ścieżki po takiej galerii handlowej wydaje się proste i będzie działać z wysoką skutecznością.

Dodatkowo to proste linkowanie może ułatwiać inne potencjalne ataki, np. atak typu replay można w ten sposób ograniczać do transmitowania kluczy wytypowanej osoby o wysokim ryzyku zarażenia, przysłowiowemu paparazzi czy szpiegowi może to ułatwić podążanie za konkretną osobą, etc.

[SeraMoon]

@jasisz a jak wyobrażasz sobie zablokowanie możliwości ataku typu replay? Przecież można koło kogoś przejść, nagrać klucz, przesłać komuś (rzecz jasna drogą błyskawiczną - internet), kto jest w tłumie i ma możliwość nadania tego klucza z mocą 10 watów... Rozgłoszenie takie będzie miało więc:

• poprawny w miarę czas (ludzie i tak mają nawet do 3 minut rozregulowane zegarki na telefonie - piszę z doświadczenia)
• poprawny MAC względem RPI (o ile nagrano oba)
• duży zasięg gdy rozgłoszono to właśnie w jakimś skupisku ludzi typu galeria, a nagrano klucz osoby "wytypowanej" na ulicy lub pod jej domem, by doprowadzić do "politycznej" kwarantanny (tak, wiem, że aluczapkę powinnam założyć, ale do czego ktoś, szczególnie służby specjalne lub rząd użyją tego nie wiemy i jak widać po wielu wątkach - mamy nie wiedzieć - dlaczego tak mówię - ilość czasu która schodzi choćby na zapytania o informację publiczną + ewentualne odmowy, jak choćby temat NDA...).

[jasisz]

@SeraMoon Trochę nie ten temat, ale są możliwości znacznego utrudnienia ataku replay, które czyniłyby go mniej praktycznym, np.:

• zastosowanie podejścia secret sharing do nadawania identyfikatorów (tworzy to inne problemy, bo ktoś może intencjonalnie psuć innym nadawanie kolejnych kawałków sekretu)
• "domieszanie" przybliżonej lokalizacji do tworzenia RPI (które jest hashem), co czyniłoby je ważnym tylko w określonym miejscu

[adrb]

@jasisz

A być może powód jest tak prozaiczny, że MAC na tych konkretnych urządzeniach zmienia się częściej niż co ten okres założony w Exposure Notifications i brakuje jeszcze nowego klucza do nadawania (a to jest słabość protokołu, który mógłby je jakoś rotować).

Wydaje mi się, że własnie o to chodzi, bo komunikaty są rozgłaszane z adresem typu "Resolvable Random Private Address". Adres ten musi się zmieniać co jakiś czas. Zdaje się że w BT 4.0 jest to ustawione na sztywno na 15minut, dopiero od BT 4.2 można ustawić tą wartość w przedziale od 1 sekundy do 11.5 godziny. Najwyraźniej chip BT sam zmienia ten adres niezależnie od aplikacji.

Jak sobie o tym pomyślę, to otwiera to drogę na kilka ataków ;)

[kwiszowaty]

To rzeczywiście otwiera drogę do stworzenia narzędzi do śledzenia użytkowników np. w sklepach. W innym wątku dyskutowaliśmy z @potiuk jak to zrobić wykrywając tylko zmiany RPI, ale ten pomysł upadł ze względu na duże ryzyko zakłóceń.

Tutaj mając rozjazd z MAC wydaje się to bardziej realne w dobrze przygotowanej sieci BT. I nie myślę tu o deanonimizacji, ale o zbieraniu danych gdzie chodził i co w końcu kupił (chociaż przy karcie lojalnościowej mamy też deanonimizację).

Nie wiem czy to duży problem, ale na pewno ciekawostka dla działów sprzedaży/marketingu takich sklepów.

[jasisz]

W innym wątku dyskutowaliśmy z @potiuk jak to zrobić wykrywając tylko zmiany RPI, ale ten pomysł upadł ze względu na duże ryzyko zakłóceń.

@kwiszowaty I mi i ardb wychodzi "w praktyce", że jest to jak najbardziej możliwe. Siądę jeszcze niedługo z lepszym devkitem Bluetooth i zobaczymy.

[kwiszowaty]

@jasisz nie mówię, że nie - mi też wydawało się to jak najbardziej możliwe. Na pewno w warunkach "laboratoryjnych". Natomiast z tego co zauważył @potiuk problemy będą w normalnych sklepach gdzie będą przeszkody i dużo ludzi. Woda jest dobrym absorberem fali, a człowiek składa się w ponad 70% z wody, więc fale będą tłumione. Przez to duża część z rozgłaszanych pakietów będzie tracona i niemożliwe byłoby odebranie wszystkich (mój pomysł na ich łączenie był na obserwację zmiany co te 260ms jak znika jeden RPI i pojawia się drugi -> wiemy w co się zamienił) - ten pomysł upadł.

Ale w przypadku który opisujesz jest zupełnie inaczej - jak mogę je powiązać poprzez MAC, który jest dostępny dłużej - to ułatwia sprawę.

Jestem bardzo ciekaw tych testów "w terenie", gdy będziesz mógł zasymulować więcej ludzi i telefonów.

[adrb]

@kwiszowaty Z tymi zakłóceniami to mam wrażenie, że patrzycie przez pryzmat zwykłego pojedynczego telefonu albo małego dongla USB. Przecież już lata temu były prezentowane praktyczne ataki na BT przeprowadzane nawet z 1km, gdzie atakujący posługiwał się "podrasowaną" anteną. Myśląc o punkcie nasłuchowym raczej myślę właśnie o urządzeniu z dobrą anteną dookólna lub kierunkową, a nie kawałku blaszki w telefonie.

Na tą chwilę widzę kilka punktów zaczepienia:

1. Okres zmiany adresu RPA (Resolvable Private Address), bez zmiany RPI jest dużo bardziej przewidywalny jak czas zmiany RPI. Wcześniej nie byłem pewien czy to zbieg okoliczności, ale teraz już wiem, że nakładają się na siebie dwa okresy zmiany adresów. RPA zmienia się u mnie co 15minut, z dokładnością do 1-2 sekund a RPI z dużo większym rozrzutem który w tym momencie jest już mniej istotny.

2. Odstęp pomiędzy komunikatami BLE również jest charakterystyczny dla urządzeń różnego typu. Na jednym mam ~350ms, na innym ~600ms. Zestawiając to z okresem zmiany RPA mamy już fajną charakterystykę wybranego urządzenia.

3. Adres RPA nazywa się "resolvable" bo jest generowany na podstawie klucza IRK (Identity Resolving Key). Algorytm jest taki, że jeżeli urządzenia były wcześniej sparowane i przeszły tzw. bonding (wymieniły się kluczami IRK), to w momencie ponownego zestawiania połączenia, są w stanie stwierdzić już po samych adresach czy mają do czynienia z zaufanym urządzeniem czy nie.

I teraz mam taką teorię, wydaje mi się że urządzenia z którymi się łączyliśmy i które mają zapisany nasz klucz IRK, mogą być w stanie identyfikować komunikaty nadawane przez nasze urządzenie. Pytanie też, czy ten klucz da się wyciągnąć przez aplikację na telefonie lub go nadpisać LE Privacy. Jeżeli tak, to generalnie w dobie wszechobecnych apek do wszystkiego, prywatność urządzeń z BT leży i kwiczy.

[SeraMoon]

@adrb @jasisz może ktoś z Was wykonać prosty rysunek jak wygląda pakiet BT z opisaniem ich części (MAC, RPI itp.) tak aby każdy wizualnie mógł określić o czym rozmawiacie i miał też pogląd na sytuację?

Do tego proponuję pokazać też jak wpływa na to druga (praktycznie zawsze) obecna funkcja: rozgłaszanie, że się istnieje ;) Mam przeczucia, że rozgłaszanie się, że jest się urządzeniem BlueTooth, gdy z tym samym MAC leci tracking Exposure Notification (w dodatku tak często - co 260 do 600ms) - już sam w sobie pozwala śledzić. Mając ciągle aktywne dwie funkcje - rozgłaszanie EN i rozgłaszanie siebie jako urządzenia BlueTooth (z którym można się sparować) - umożliwia dość prosty atak na zmieniające się Diagnosis Key? Czy się mylę?

Między innymi stąd postulowałam, aby pakiety Exposure Notification były rozsyłane z MAC złożonym z samych zer lub samych wartości FF. Nie wiem tylko na ile możliwe jest wysyłanie z dedykowanym MAC akurat tylko tego jednego typu pakietu.

[adrb]

@SeraMoon

@adrb @jasisz może ktoś z Was wykonać prosty rysunek jak wygląda pakiet BT z opisaniem ich części (MAC, RPI itp.) tak aby każdy wizualnie mógł określić o czym rozmawiacie i miał też pogląd na sytuację?

Zapewne się pokuszę o jakieś dłuższe wyjaśnienie, ale jeszcze nie teraz. Opis pakietów EN masz tutaj, natomiast sam pakiet BT jest zbyt skomplikowany by to wyjaśnić ad hoc.

Do tego proponuję pokazać też jak wpływa na to druga (praktycznie zawsze) obecna funkcja: rozgłaszanie, że się istnieje ;) Mam przeczucia, że rozgłaszanie się, że jest się urządzeniem BlueTooth, gdy z tym samym MAC leci tracking Exposure Notification (w dodatku tak często - co 260 do 600ms) - już sam w sobie pozwala śledzić. Mając ciągle aktywne dwie funkcje - rozgłaszanie EN i rozgłaszanie siebie jako urządzenia BlueTooth (z którym można się sparować) - umożliwia dość prosty atak na zmieniające się Diagnosis Key? Czy się mylę?

Wszystko zależy od sprzętu. Androidy się w ten sposób nie rozgłaszają, iPhone tak, i tutaj możesz mieć racje, ale nie mam żadnego iPhone do testów.

Między innymi stąd postulowałam, aby pakiety Exposure Notification były rozsyłane z MAC złożonym z samych zer lub samych wartości FF. Nie wiem tylko na ile możliwe jest wysyłanie z dedykowanym MAC akurat tylko tego jednego typu pakietu.

Protokół BT wyklucza tego typu ustawienie adresów. Ustawienie jakiegoś innego adresu na sztywno na wszystkich urządzeniach spowodowałoby, że rozgłaszanie blokowałoby normalne funkcje BT.

[SeraMoon]

Protokół BT wyklucza tego typu ustawienie adresów.

To krótko stwierdzę - kicha. Szkoda, że nie ma dostępu do warstwy PHY (fizycznej), aby pakiety Exposure Notification nadawać z zerami w polu MAC (i wtedy takie też odbierać). Nie miałam na myśli ustawiania adresu, ale wysłanie tego jednego typu pakietu z zerami. Czyli już sama koncepcja BT od początku jest dziurawa - rozreklamowywanie, że się istnieje (czy to samoistne, czy po wysłaniu jakiegoś pakietu), inne aplikacja mogące coś wysyłać z tym samym adresem MAC - to wszystko ułatwia deanonimizację.

@adrb czy Androidy da się jakoś "zmusić" aby się przedstawiły (powiedziały: "istnieję" i nazywam się 12:34:56:78:9A) - czyli wysłać jakiś pakiet, aby stały się widoczne (zakładając włączony BlueTooth i wyłączony Exposure Notification + standardowe fabryczne ustawienie aplikacji)?

[jasisz]

Polecam https://www.polidea.com/blog/bluetooth-low-energy-sniffing-guide/ tam wszystko jest ładnie rozpisane.

A już taki konkretnie Exposure Notifications pakiet wygląda tak:

[SeraMoon]

@jasisz dzięki. O to właśnie chodziło. W dokumentacji Exposure Notification jest zobrazowana tylko część tego pakietu, bez wspomnienia o advertising address (MAC).

Teraz przydałaby się cała lista niezałatanych CVE (Common Vulnerabilities and Exposures) dotycząca BlueTooth (BT) - o ile ktoś ma czas to wydobyć :wink: Dotyczących nie tylko BLE, bo jak rozumiem, włączenie Exposure Notification wymaga włączenia całej funkcjonalności BT.

[adrb]

Protokół BT wyklucza tego typu ustawienie adresów.

To krótko stwierdzę - kicha. Szkoda, że nie ma dostępu do warstwy PHY (fizycznej), aby pakiety Exposure Notification nadawać z zerami w polu MAC (i wtedy takie też odbierać).Nie miałam na myśli ustawiania adresu, ale wysłanie tego jednego typu pakietu z zerami.

Ależ da się bez problemu nadać i odebrać taki pakiet:

Czyli już sama koncepcja BT od początku jest dziurawa - rozreklamowywanie, że się istnieje (czy to samoistne, czy po wysłaniu jakiegoś pakietu), inne aplikacja mogące coś wysyłać z tym samym adresem MAC - to wszystko ułatwia deanonimizację.

Tak, zostało do dostrzeżone i dlatego w BT 4.0 adres mac może się okresowo zmieniać. Tak jak już pisałem wcześniej, ustawienie na sztywno adresu na jakąkolwiek wartość, nie ma po prostu sensu. Urządzenia muszą się jakoś rozróżniać.

@adrb czy Androidy da się jakoś "zmusić" aby się przedstawiły (powiedziały: "istnieję" i nazywam się 12:34:56:78:9A) - czyli wysłać jakiś pakiet, aby stały się widoczne (zakładając włączony BlueTooth i wyłączony Exposure Notification + standardowe fabryczne ustawienie aplikacji)?

Telefon musi być wybudzony i po prostu klikasz "wyszukiwanie urządzeń w pobliżu" lub coś w ten deseń.

@jasisz Zmodyfikowałem swój kod tak by uwzględnić punkty 1 i 2 które opisałem tutaj.

Efekt jest taki:

Czyli podsumowując, mając cały czas użytkownika w zasięgu nadajnika można skutecznie łączyć poszczególne komunikaty RPI. Teraz jest jeszcze kwestia wybadania, jak się sprawy mają z kluczem IRK używanym do generowania pseudolosowego adresu urządzenia.

[jasisz]

Udało mi się zasilić algorytm danymi z zewnętrznego sniffera. Urządzenie 1:

2020-06-23 08:06:41.792460: 66d162e7335f (4a8828d0817bf1dbbebee053ed2dc43a25ab8e55) is now 7adb05250fb3 (4a8828d0817bf1dbbebee053ed2dc43a25ab8e55) after gap of 285ms, device was present for 0:02:46.148785
2020-06-23 08:09:43.460338: 7adb05250fb3 (4a8828d0817bf1dbbebee053ed2dc43a25ab8e55) is now 46d14a18668b (328a17828d0f68f486ff83456246b5995503974e) after gap of 354ms, device was present for 0:03:01.313370
2020-06-23 08:24:44.523814: 46d14a18668b (328a17828d0f68f486ff83456246b5995503974e) is now 6167db8e6cdc (328a17828d0f68f486ff83456246b5995503974e) after gap of 284ms, device was present for 0:15:00.779267
2020-06-23 08:27:44.321021: 6167db8e6cdc (328a17828d0f68f486ff83456246b5995503974e) is now 7a1373da4ceb (6d809fb06f36e7325e0fce2204ee5c5cb21b6803) after gap of 405ms, device was present for 0:02:59.392124
2020-06-23 08:40:20.620243: 7a1373da4ceb (6d809fb06f36e7325e0fce2204ee5c5cb21b6803) is now 5e53de47c9be (65a3f9e8299c1eee2740404d58e7d94e01ffd7e4) after gap of 976ms, device was present for 0:12:35.322661
2020-06-23 08:54:14.544851: 5e53de47c9be (65a3f9e8299c1eee2740404d58e7d94e01ffd7e4) is now 6978de7614b0 (68b95e6d943f8b0a743c2de21e786871e92a102f) after gap of 61ms, device was present for 0:13:53.863066
2020-06-23 09:07:37.807590: 6978de7614b0 (68b95e6d943f8b0a743c2de21e786871e92a102f) is now 4a30aa2b35b9 (ab3e12b9e1bae22921b3e490f923a0744521f3c7) after gap of 331ms, device was present for 0:13:22.931273
2020-06-23 09:20:38.844246: 4a30aa2b35b9 (ab3e12b9e1bae22921b3e490f923a0744521f3c7) is now 47ab4e8d24a6 (55eec62014ee6863ce4c501ab915606d6fe28751) after gap of 352ms, device was present for 0:13:00.683784
2020-06-23 09:34:44.863574: 47ab4e8d24a6 (55eec62014ee6863ce4c501ab915606d6fe28751) is now 531ed3725eda (96d1034340780c4014dc9b349ab8cd4bae178e54) after gap of 499ms, device was present for 0:14:05.519330
2020-06-23 09:45:59.864717: 531ed3725eda (96d1034340780c4014dc9b349ab8cd4bae178e54) is now 44f98502b5d5 (71bf8cdbc0474af779da9db1d6d14fae0a0ce9f8) after gap of 453ms, device was present for 0:11:14.547898
2020-06-23 09:59:31.566654: 44f98502b5d5 (71bf8cdbc0474af779da9db1d6d14fae0a0ce9f8) is now 5ef063089ba4 (88094bff25805dd3e9ad12f921796271c6d74ec0) after gap of 390ms, device was present for 0:13:31.311830
2020-06-23 10:14:32.295293: 5ef063089ba4 (88094bff25805dd3e9ad12f921796271c6d74ec0) is now 45970b10f96c (88094bff25805dd3e9ad12f921796271c6d74ec0) after gap of 283ms, device was present for 0:15:00.445075
2020-06-23 10:17:40.589008: 45970b10f96c (88094bff25805dd3e9ad12f921796271c6d74ec0) is now 7306dbec62a7 (0c550869a30c92273caef0512f7f0b542f78b784) after gap of 434ms, device was present for 0:03:07.858761
2020-06-23 10:32:41.128413: 7306dbec62a7 (0c550869a30c92273caef0512f7f0b542f78b784) is now 6e247bd473ba (0c550869a30c92273caef0512f7f0b542f78b784) after gap of 288ms, device was present for 0:15:00.251340
2020-06-23 10:35:40.883614: 6e247bd473ba (0c550869a30c92273caef0512f7f0b542f78b784) is now 56fc14242de5 (488617bd7ab11fb8829276bb377d0dcac37fd144) after gap of 394ms, device was present for 0:02:59.360510
2020-06-23 10:47:51.020103: 56fc14242de5 (488617bd7ab11fb8829276bb377d0dcac37fd144) is now 59ba9ad06859 (2bda6ee3c54a84a50a56297c2f57e351ccbdc617) after gap of 948ms, device was present for 0:12:09.188066
2020-06-23 10:58:48.600778: 59ba9ad06859 (2bda6ee3c54a84a50a56297c2f57e351ccbdc617) is now 5237bf6049f2 (a89a93843408a5d4b004a3cc777192196103fbcf) after gap of 488ms, device was present for 0:10:57.092332

Urządzenie 2:

2020-06-23 08:30:17.014062: 56bbfc6ee458 (dc9ff2b8617827cc76898bcf74cefaaf0dc0f7f8) is now 5609268ad976 (e097beb34996a8e6aec852232cf99b72d4775f87) after gap of 1461ms, device was present for 0:10:49.006418
2020-06-23 08:43:32.299485: 5609268ad976 (e097beb34996a8e6aec852232cf99b72d4775f87) is now 5d6142df41c3 (157464a469a79904f9a20e467f8c0470ac52c8f4) after gap of 487ms, device was present for 0:13:14.798183
2020-06-23 08:57:21.206022: 5d6142df41c3 (157464a469a79904f9a20e467f8c0470ac52c8f4) is now 4969802d5d97 (827abf760d97cb4dd7f03b8f4b17a930e8d66b3a) after gap of 609ms, device was present for 0:13:48.297276
2020-06-23 09:09:35.222396: 4969802d5d97 (827abf760d97cb4dd7f03b8f4b17a930e8d66b3a) is now 5abadbd605f7 (95e0a73fc7038d67f440e5533cd7ce3c223096a8) after gap of 552ms, device was present for 0:12:13.463632
2020-06-23 09:21:55.765531: 5abadbd605f7 (95e0a73fc7038d67f440e5533cd7ce3c223096a8) is now 7b89099b8f9e (2b7ffbbba86678b7182ed9d69f297f904a79b71e) after gap of 1066ms, device was present for 0:12:19.476283
2020-06-23 09:36:55.844104: 7b89099b8f9e (2b7ffbbba86678b7182ed9d69f297f904a79b71e) is now 5bb0a6be2e0e (2b7ffbbba86678b7182ed9d69f297f904a79b71e) after gap of 284ms, device was present for 0:14:59.794181
2020-06-23 09:38:45.962597: 5bb0a6be2e0e (2b7ffbbba86678b7182ed9d69f297f904a79b71e) is now 558eb712df87 (2f6b15b533b74c19cdc0710849bc56acaeac75a4) after gap of 299ms, device was present for 0:01:49.818878
2020-06-23 09:53:30.761668: 558eb712df87 (2f6b15b533b74c19cdc0710849bc56acaeac75a4) is now 7d52d508e4cd (e1e85644d2ca20e08e7b3c57613d9652478e8a62) after gap of 364ms, device was present for 0:14:44.434400
2020-06-23 10:05:31.884758: 7d52d508e4cd (e1e85644d2ca20e08e7b3c57613d9652478e8a62) is now 67b8102046d1 (a473f939e374a6da0b364b03157224ec869dba80) after gap of 133ms, device was present for 0:12:00.990005
2020-06-23 10:17:33.001507: 67b8102046d1 (a473f939e374a6da0b364b03157224ec869dba80) is now 689fd37fe0a5 (54fe9345eced0d357ce2f0303488ac961381633f) after gap of 365ms, device was present for 0:12:00.751102
2020-06-23 10:28:23.020006: 689fd37fe0a5 (54fe9345eced0d357ce2f0303488ac961381633f) is now 4bafaa2730de (d4dccc0e54f616adc20f49c8e86e97ac181020bd) after gap of 391ms, device was present for 0:10:49.627161
2020-06-23 10:43:25.240354: 4bafaa2730de (d4dccc0e54f616adc20f49c8e86e97ac181020bd) is now 42468384646a (d4dccc0e54f616adc20f49c8e86e97ac181020bd) after gap of 1719ms, device was present for 0:15:00.501213
2020-06-23 10:45:11.792306: 42468384646a (d4dccc0e54f616adc20f49c8e86e97ac181020bd) is now 69d5fdfadcfa (634f0c0ae05118a8a31bb28028c002f4feeecf3a) after gap of 62ms, device was present for 0:01:46.489295
2020-06-23 11:00:12.969010: 69d5fdfadcfa (634f0c0ae05118a8a31bb28028c002f4feeecf3a) is now 68ff85958b91 (634f0c0ae05118a8a31bb28028c002f4feeecf3a) after gap of 290ms, device was present for 0:15:00.886325
2020-06-23 11:00:37.954595: 68ff85958b91 (634f0c0ae05118a8a31bb28028c002f4feeecf3a) is now 661385c72ee5 (0762d0aa0a4e01f73d2110feb393371af98d2796) after gap of 373ms, device was present for 0:00:24.612314

Więc u mnie wygląda to tak, że jeżeli device był 15 minut "bez zmian", to w następnym bardzo krótkim okresie (charakterystycznym dla urządzenia, bo na jednym jest to ~3 minuty, a na drugim ~1:50, a raz tylko 25 sekund) będzie reużyty ten sam RPI.

Trochę to wygląda jakby logika była taka, że ENIntervalNumber jest brany z końca okresu nadawania, a nie z jego początku.

[adrb]

@jasisz Wydaje mi się, że to przypadek, pewnie zależy jak nakładają sie poszczególne interwały.

Ok, a teraz myślę "dobra" informacja, udało mi się potwierdzić teorię numer 3, opisana tutaj.

Czyli, urządzenia z którymi parowaliśmy telefon i przeszły bonding sa w stanie śledzić nasze komunikaty G+A na podstawie adresu MAC. Wystarczy jeden odebrany pakiet, tak więc zakłócenia i dziury w transmisji nie robią różnicy. W sumie jakiegoś wielkiego zaskoczenia nie ma, bo czemu by to miało nie działać skoro tak zostało zaprojektowane i opisane w dokumentacji BT?

Bardziej technicznie, mając klucz IRK jestem w stanie przypisywać komunikaty do konkretnego urządzenia na podstawie adresu BT z jakim rozgłasza komunikaty. Jak zdobyć klucz IRK? Na ta chwile wiem jak go wyciągnąć z windows-a i linuksa po sparowaniu urządzeń. Możliwe że istnieją też metody na wyciągniecie go z andraoida i iphone, nie mówiąc już o chwytach w stylu włamanie na komputer osoby która chcemy śledzić itd, czy zabranie na chwile odblokowanego telefonu.

Zadziała to tez w druga stronę, tzn. mając nagrane komunikaty EN, można będzie bez problemu sprawdzić czy dana osoba byla faktycznie w wybranym miejscu, jeżeli wpadnie nam w ręce klucz IRK telefonu, nawet jeżeli rozgłaszane dane zostaną już z telefonu skasowane.

[jasisz]

@adrb Bardzo ciekawe, bo specyfikacja mówi, że The advertiser address type shall be Random Non-resolvable. Co znowu potwierdzałoby że specyfikacja sobie, a praktyka sobie...

Nie mam niestety dostępu do iPhone ale potwierdzam - dla wszystkich androidowych adresów jakie widziałem to prawda, są to adresy Random, ale typu Resolvable (dwa pierwsze bity zawsze 01). Po sparowaniu urządzeń pakiety EN są nawet widoczne jako Bonded w skanerze:

[adrb]

Dokumentacja jest w sumie nie jednoznaczna, mamy :

 •The advertiser address type shall be Random Non-resolvable.
 •On platforms supporting the Bluetooth Random Private Address with a randomized rotation timeout interval, the advertiser address rotation period shall be a random value that is greater than 10 minutes and less than 20 minutes.

Czyli w tym momencie rozumiem to tak, że na platformach które obsługują adresy RPA, powinno się z nich korzystać.

Zaktualizowałem kod i readme w bentool. Dodałem opis jak wydobyć klucz IRK oraz dwa plecenia. Jedno do weryfikacji zgodności klucza IRK z adresem (_resolverpa) a drugie które dodaje klucz IRK do listy (bonding), dzięki czemu możliwe jest śledzenie urządzeń na podstawie adresów BT.

[adrb]

Tutaj małe podsumowanie "badań"

[jasisz]

Ja z kolei w międzyczasie dawałem talka o Contact Tracing na online PyWaw i też tam poruszyłem kwestie między innymi z tego wątku - link do konkretnego momentu https://youtu.be/GC9ldWCzlWA?t=2408 ;)

[potiuk]

Ja z kolei w międzyczasie dawałem talka o Contact Tracing na online PyWaw i też tam poruszyłem kwestie między innymi z tego wątku - link do konkretnego momentu https://youtu.be/GC9ldWCzlWA?t=2408 ;)

Ogladalem. Super prezentacja @jasisz ! Bardzo konkretna i rzeczowa.

[jasisz]

Pojawił się kod od Google i w dokumentacji piszą o tym co zaobserwowaliśmy (zmienia się MAC ale RPI zostaje takie samo) - https://github.com/google/exposure-notifications-internals#ble-mac-and-rpi-rotation

A więc w sumie tak jak obstawialiśmy - zmiana RPI zawsze powoduje zmianę MAC, ale "szybsza" zmiana MAC nie powoduje zmiany RPI, ponieważ w Androidzie brakuje callbacka na zmianę MAC, który by to obsługiwał.