Czy Microsoft może rozpoznawać to samo urządzenie po zmianie adresu IP, użyciu VPN lub ponownym uruchomieniu systemu? Niedawne doniesienia dotyczące GDID (Global Device Identifier), opisanego w dokumentach amerykańskich organów ścigania, zwróciły uwagę na mechanizmy identyfikacji i korelacji urządzeń w ekosystemie Microsoft.
Postanowiliśmy sprawdzić w praktyce. Przeanalizowaliśmy dane diagnostyczne Windows 11 przed i po restarcie systemu, przed i po reinstalacji całego systemu, w maszynie wirtualnej i sklonowanej maszynie, po zmianie adresu IP przez VPN – chcieliśmy ustalić, czy Windows 11 przechowuje tzw. trwały identyfikator urządzenia oraz jakie informacje można z nim powiązać, dodatkowo czy to ID występuje również w wymaganej telemetrii systemu.
Aby przeanalizować dane diagnostyczne na swojej stacji roboczej przejdź do sekcji „Ustawienia > Prywatność i zabezpieczenia > Diagnostyka i opinie” a następnie włącz możliwość zapisywania dzienników na dysku oraz zainstaluj z Microsoft Store aplikację do przeglądania dzienników (system zaproponuje to automatycznie).
GDID a identyfikatory widoczne w telemetrii Windows
Według opisu przywoływanego w dokumentach federalnych GDID jest trwałym identyfikatorem na poziomie urządzenia, przeznaczonym do identyfikowania instalacji systemu Windows na urządzeniu fizycznym lub maszynie wirtualnej.
W analizowanej sprawie w dokumentach FBI występował identyfikator w formacie:
g:6755467234350028
Taki identyfikator nie występuje w systemie wprost. W danych udostępnianych przez aplikację Diagnostic Data Viewer zaobserwowaliśmy inny identyfikator.
Fizyczny komputer:
device.localId = s:B46BA1E5-ABFD-481C-8059-BB30DAB5A612
Analizując dziesiątki zdarzeń diagnostycznych, nie znaleźliśmy dowodów pozwalających powiązać device.localId z GDID. Może to być niezależny identyfikator telemetryczny lub jeden z elementów szerszego mechanizmu korelacji wykorzystywanego przez usługi Microsoft.
Możemy jednak eksperymentalnie sprawdzić, jak trwały jest device.localId i w jakich sytuacjach ulega zmianie.
Zaczęliśmy od najprostszego testu
Czy device.localId zmienia się po restarcie?
Przed restartem systemu jedno ze zdarzeń telemetrycznych zawierało:
device.localId = s:B46BA1E5-ABFD-481C-8059-BB30DAB5A612
user.localId = o:3
bootId = 112
Po ponownym uruchomieniu Windows 11 zarejestrował kolejne zdarzenia:
device.localId = s:B46BA1E5-ABFD-481C-8059-BB30DAB5A612
user.localId = o:3
bootId = 113
BootId zmienił się wraz z ponownym uruchomieniem systemu, natomiast device.localId pozostał identyczny.
Na razie w ramach przeprowadzonego testu device.localId jest trwały pomiędzy kolejnymi uruchomieniami Windows.
Jednak ciekawy jest też zakres zdarzeń, do których Windows dołącza ten sam device.localId. Zaobserwowaliśmy go między innymi w następujących zdarzeniach.
Jakie są informacje o GPU?
Zdarzenie: DxgKrnlTelemetry.GPUAdapterInventoryV2
zawierało szczegółowe informacje dotyczące konfiguracji GPU, między innymi:
- identyfikator producenta i urządzenia,
- identyfikator podsystemu,
- wersję i datę sterownika,
- ilość dedykowanej i współdzielonej pamięci,
- wersję WDDM,
- obsługiwane funkcje sprzętowe,
- ścieżki do sterowników i bibliotek.
Do zdarzenia dołączono ten sam device.localId = s:B46BA1E5-ABFD-481C-8059-BB30DAB5A612
Informacje o UEFI i firmware:
Zdarzenie: Microsoft.Windows.UEFI.ESRT
również zawierało ten sam device.localId. Telemetria obejmowała informacje dotyczące między innymi wersji firmware, statusu ostatniej próby aktualizacji i obsługi mechanizmu ESRT.
Konfiguracja zabezpieczeń sprzętowych:
Zdarzenie: Microsoft.Windows.Defender. Shield.HardwareSecurityFeatures
zawierało informacje dotyczące stanu mechanizmów bezpieczeństwa, między innymi:
- Secure Boot,
- TPM 2.0,
- HVCI,
- Credential Guard,
- Vulnerable Driver Blocklist.
Ponownie zdarzenie zawierało ten sam device.localId.
Windows Update i Microsoft Store:
W zdarzeniu: Microsoft.Windows. Update.WUClient.InstallSucceeded
Windows zarejestrował instalację aplikacji Diagnostic Data Viewer z Microsoft Store (co też przecież zrobiliśmy). Także tutaj występował ten sam identyfikator urządzenia.
Wymagane (obowiązkowe) dane diagnostyczne
Istotnym elementem analizowanych zdarzeń było pole:
isRequired = true
Oznacza to, że analizowane rekordy zostały sklasyfikowane jako wymagane dane diagnostyczne, a nie opcjonalne.
W naszych próbkach ten sam trwały device.localId był więc obecny w różnych klasach wymaganej telemetrii generowanej przez różne komponenty Windows. Technicznie umożliwia to korelowanie wielu zdarzeń pochodzących z tego samego urządzenia lub instalacji systemu w ramach mechanizmu telemetrycznego.
Czy device.localId pozwala śledzić urządzenie mimo używania VPN?
Sam VPN zmienia przede wszystkim sposób, w jaki ruch sieciowy opuszcza urządzenie i jaki publiczny adres IP widzi usługa docelowa. Nie zmienia jednak lokalnych identyfikatorów systemu operacyjnego.
Jeżeli Windows wysyła zdarzenia zawierające ten sam trwały identyfikator przed i po zmianie adresu IP, odbiorca danych może potencjalnie stwierdzić, że zdarzenia pochodzą z tego samego urządzenia lub instalacji.
Przykładowo:
- localId X + jakiś adres IP A
- localId X + jakiś adres IP B
- localId X + jakiś adres VPN IP C
Zmiana adresu IP nie musi oznaczać utraty możliwości korelacji, jeżeli w przesyłanych danych występuje inny trwały identyfikator. Nie oznacza to jednak automatycznie, że device.localId jest dostępny dla każdej usługi Microsoftu ani że jest wykorzystywany dokładnie w taki sam sposób jak GDID opisany w dokumentach federalnych.
Sklonowane maszyny wirtualne
Podobny eksperyment przeprowadziliśmy w dwóch niezależnych maszynach wirtualnych. Na podstawie jednej utworzyliśmy pełny klon drugiej z odrębnym adresem MAC.
Oryginalna VM:
device.localId = s:9D69401D-7FF8-4679-AD95-CB6CE64E7841
Sklonowana VM:
device.localId = s:9D69401D-7FF8-4679-AD95-CB6CE64E7841
Czyli klon VMware zachował identyczny device.localId. Oznacza to, że ten identyfikator jest zapisany w sklonowanym stanie systemu, a nie generowany na podstawie bieżącego sprzętu wirtualnego przy każdym uruchomieniu.
Oba systemy mogą teraz wysyłać telemetrię z tym samym device.localId. Z perspektywy tej warstwy identyfikacji Microsoft może więc potencjalnie traktować dwie VM jako tę samą instancję albo rozróżniać je dopiero za pomocą innych identyfikatorów.
Co Microsoft robi w chmurze i nad czym nie masz kontroli?
Microsoft, opierając się wyłącznie na device.localId, nie mógłby jednoznacznie odróżnić oryginalnej maszyny wirtualnej od jej pełnego klona. Do ich rozróżnienia potrzebne byłyby dodatkowe identyfikatory lub dane.
Dla naszego badania ważniejsze jest jednak coś innego – device.localId jest zapisany trwale w systemie i pozostaje niezmieniony zarówno po restarcie, jak i po pełnym sklonowaniu instalacji Windows, jak również po zmianie adresu IP, restarcie systemu.
Device.localId jest jednym znanym nam z identyfikatorów wykorzystywanych przez system telemetryczny Windows, natomiast GDID może funkcjonować w innej warstwie identyfikacji (poza urządzeniem – na serwerach Microsoftu). Różne identyfikatory mogą być mapowane lub korelowane po stronie infrastruktury Microsoft.
Współczesny Windows jest silnie zintegrowany z usługami chmurowymi Microsoft, takimi jak Windows Update, Microsoft Store, Defender, Edge, synchronizacja ustawień, usługi konta Microsoft czy mechanizmy diagnostyczne. Oznacza to, że nawet jeśli użytkownik może ograniczyć część danych diagnostycznych, identyfikatory wykorzystywane po stronie usług chmurowych nie muszą być bezpośrednio widoczne ani kontrolowane z poziomu systemu operacyjnego.
Dlatego na obecnym etapie możemy potwierdzić istnienie trwałego device.localId w wymaganej telemetrii Windows 11, ale nie możemy jeszcze potwierdzić jego technicznej relacji z GDID ani stwierdzić, czy użytkownik może zresetować lub kontrolować sam GDID.
Co do tej pory potwierdził nasz test?
Możemy potwierdzić, że w analizowanym systemie Windows 11:
- dane diagnostyczne zawierały device.localId w formacie s:<GUID>,
- identyfikator pozostał niezmieniony po restarcie systemu,
- jednocześnie zmienił się bootId, co pozwala rozróżnić kolejne uruchomienia systemu,
- ten sam identyfikator występował w różnych klasach telemetrii,
- obejmowały one informacje o sprzęcie, firmware, konfiguracji zabezpieczeń i aktualizacjach,
- analizowane zdarzenia były oznaczone jako wymagane dane diagnostyczne.
Kolejny etap testów
Czy device.localId zmienia się po zmianie konta użytkownika?
Nowy użytkownik zmienił tylko identyfikator użytkownika. Czyli device.localId jest niezależny od lokalnego konta użytkownika, natomiast user.localId rozróżnia użytkowników w obrębie tej samej instalacji Windows.
Czy device.localId pozostaje taki sam po zmianie adresu IP i użyciu VPN?
device.localId jest lokalnym identyfikatorem instalacji i zmiana IP/VPN nie zmienia niczego.
Co dzieje się po resecie Windows? Przywrócenie do ustawień fabrycznych, wymazanie wszystkiego.
Czy ponowna instalacja systemu i wyczyszczenie danych generuje nowy identyfikator?
Przed resetem:
device.localId = s:9D69401D-7FF8-4679-AD95-CB6CE64E7841
Po resecie:
device.localId = s:9D69401D-7FF8-4679-AD95-CB6CE64E7841
Okazuje się, że w tym przypadku device.localId jest nadal trwałym identyfikatorem instalacji i tożsamości systemu i nie jest zwykłym identyfikatorem sesji, uruchomienia ani konta użytkownika. Reset Windows w zastosowanym wariancie nie wygenerował nowego ID.
Jak zachowuje się identyfikator po sklonowaniu maszyny wirtualnej?
Po wykonaniu pełnego klonu maszyny wirtualnej identyfikator device.localId pozostał taki sam w oryginalnej maszynie jak i w klonie. Oznacza to, że pełne klonowanie kopiuje również lokalną tożsamość telemetryczną Windows.
Czy istnieje techniczna możliwość wykazania relacja pomiędzy device.localId a GDID?
To bardzo trudne pytanie, ponieważ nie ma oficjalnej dokumentacji Microsoftu na ten temat.
W zdarzeniu „Microsoft.Windows.Update.SIHClient*” znaleźliśmy jednocześnie dwa różne identyfikatory urządzenia: wcześniej analizowany device.localId oraz WUDeviceID. Potwierdza to, że device.localId nie jest bezpośrednio identyfikatorem używanym przez Windows Update.
WUDeviceID jest osobnym identyfikatorem przypisanym do urządzenia w mechanizmie Windows Update i stanowi znacznie bliższy techniczny odpowiednik Global Device ID. Nadal nie można jednak potwierdzić, że odpowiada on dokładnie identyfikatorowi GDID w formacie g:<liczba> opisanym w dokumentach FBI. Niewykluczone, że WUDeviceID jest następnie mapowany na inny identyfikator po stronie usług Microsoft.
Co użytkownik może zrobić w kontekście prywatności?
Microsoft publikuje osobny poradnik dotyczący minimalizowania połączeń Windows z usługami Microsoft, głównie przydatny dla wersji systemów zarządzanych i środowisk organizacyjnych.
Użytkownik może ograniczyć ilość dodatkowych danych przekazywanych do Microsoft, ale nie ma pełnej kontroli nad wszystkimi identyfikatorami wykorzystywanymi przez system i usługi chmurowe.
Warto przede wszystkim:
- wyłączyć opcjonalne dane diagnostyczne,
- wyłączyć spersonalizowane oferty i wykorzystywanie danych diagnostycznych do personalizacji,
- wyłączyć identyfikator reklamowy,
- przejrzeć uprawnienia aplikacji do lokalizacji, kamery, mikrofonu i innych danych,
- ograniczyć synchronizację danych z kontem Microsoft, jeśli nie jest potrzebna,
- osobno sprawdzić ustawienia prywatności Edge i innych usług Microsoft,
- regularnie sprawdzać dane widoczne w Microsoft Privacy Dashboard oraz Diagnostic Data Viewer.
Dezaktywując wszystkie dostępne opcje nie oznacza to wyłączenia wymaganej telemetrii Windows. Nasze testy pokazały, że device.localId oraz WUDeviceID występują również w zdarzeniach oznaczonych jako isRequired: true. Z poziomu standardowych ustawień prywatności Windows użytkownik może więc ograniczyć część zbieranych danych, ale nie ma jednego przełącznika pozwalającego wyłączyć lub kontrolować wszystkie identyfikatory urządzenia używane przez system i usługi Microsoft.
