Autor: Marek Wesołowski (WESMAR) · github.com/wesmar · kvc.pl

W skrócie. Artykuł obejmuje dwie części. Pierwsza to rozwiązanie problemu uruchomienia produkcyjnej wersji eDO App 1.7.1 (Xamarin/.NET 9, ARM) na WSA x86-64 przez translator Houdini: przyczyną awarii był splot biblioteki ICU, mostu native bridge, kodu wyciętego przez trimmer oraz optymalizacji wektorowych SIMD w bibliotece standardowej .NET. Druga część stanowi niezależny audyt bezpieczeństwa klienta: analiza statyczna assembly oraz weryfikacja dynamiczna na Xiaomi 13T Pro. Ustalenia potwierdzają brak lokalnego kontenera tożsamości, powiązanie sekretów z Android Keystore, implementację PACE i Chip Authentication na bibliotece Bouncy Castle oraz poprawną konfigurację certyfikatów. Główne uchybienie to brak wymuszonego podglądu dokumentu w kroku podpisu kwalifikowanego oraz brak filtracji wejścia z klawiatury sprzętowej.

1. Zakres badania i granice wniosków

Badam własną instalację, własne WSA, własne konto i własny dowód. Celem jest interoperacyjność oraz niezależna ocena bezpieczeństwa klienta. Rozdzielam trzy poziomy pewności:

1. Dowód statyczny: obecny w APK, bibliotekach ELF i IL.
2. Dowód wykonaniowy: zaobserwowany w procesie, logcat, stosach, aktywnościach i ruchu TLS.
3. Hipoteza audytowa: trop wymagający jeszcze kontrolowanego testu.

APK badawczy podpisałem oddzielnym certyfikatem. Opisuję każdą modyfikację, aby późniejsze wyniki nie mieszały zachowania producenta z zachowaniem laboratorium. Podczas akceptacji regulaminu aplikacja wykonała ruch do serwera. Nie eksportowałem danych dokumentu, PIN-u ani innych danych osobowych.

2. Materiał i powtarzalność

Całość trzymam w C:\Temp\eDO_App, osobno od mObywatela. Nie odinstalowałem, nie nadpisałem ani nie podpisałem ponownie działającego mObywatela.

3. Stanowisko WSA

W jednej z pośrednich konfiguracji problem z native bridge zbiegł się z włączonym Zygiskiem i dał komunikat EM_AARCH64/EM_X86_64. Była to błędna korelacja, nie warunek działania eDO App. Po końcowej konfiguracji WSA aplikacja działa z aktywnym Zygiskiem i aktywnym MagiskSU. Stan ten traktuję jako potwierdzony funkcjonalnie; gdy WSA zostanie ponownie uruchomiony, uzupełnię go jeszcze o bieżący zrzut właściwości systemowych.

4. Xamarin kontra Kotlin: dlaczego eDO to trudny klient dla WSA

Zanim wejdę w szczegóły, muszę wyjaśnić różnicę, która przesądza o całej trudności, a której w audycie mObywatela w ogóle nie było.

mObywatel napisano w Kotlinie. Kod kompiluje się do bajtkodu Dalvik i wykonuje go natywnie wirtualna maszyna Androida (ART). Na WSA ART działa jako proces x86-64, więc logika aplikacji chodzi natywnie; przez Houdini przechodzi jedynie kilka drobnych bibliotek natywnych. Dlatego dla WSA mObywatel jest „lekki".

eDO App napisano w C# na .NET. To rodowód Xamarina, dziś kontynuowany jako .NET MAUI (co widać w APK po obecności Microsoft.Maui.Essentials). Logika aplikacji to kod pośredni IL, który wykonuje runtime Mono, a Mono to duża, natywna biblioteka ARM (libmonosgen-2.0.so). W efekcie translator Houdini na WSA wykonuje pełny silnik uruchomieniowy Mono wraz z biblioteką standardową .NET, warstwą ICU i kodem natywnym aplikacji, a nie jedynie pojedyncze wywołania JNI. Stanowi to przyczynę problemów opisanych poniżej.

Kontekst technologiczny: Microsoft wygasił „klasycznego" Xamarina 1 maja 2024 r. i scalił go z ujednoliconym .NET pod postacią .NET MAUI. Powodem był koszt utrzymywania osobnego stosu mobilnego obok głównego .NET oraz chęć jednego modelu dla wszystkich platform. eDO App wykorzystuje platformę .NET 9 oraz MAUI, zachowując tę samą architekturę: kod zarządzany wykonywany przez natywne środowisko Mono. Na fizycznym procesorze ARM działa to bez narzutu, natomiast w procesie translacji ARM→x86-64 pod Houdini stanowi przypadek o najwyższym stopniu złożoności.

Aplikacja zawiera własne środowisko Mono oraz biblioteki natywne ARM, co wymusza translację pełnego stosu .NET pod emulatorem Houdini.

Na tej granicy kolejno ujawniły się: ICU 70/72, host bridging, Scudo, bezwarunkowy LoadICU, reguły porządkowania tekstu, inicjalizacja MvvmCross, SearchValues i parser HTTP.

5. ICU 70 kontra ICU 72

WSA ma ICU 70, a eDO App oczekuje ICU 72. Houdini mostkuje wybrane biblioteki do hosta. Gdy ARM64 żądał symboli ICU 72, bridge szukał ich w hostowym ICU 70.

Próba dostarczenia czystych bibliotek gościa ARM64 ICU 72 zakończyła się niepowodzeniem: pliki danych były otwierane poprawnie, jednak funkcja IcuRegistration::registerIcu() powodowała błąd w alokatorze Scudo podczas zwalniania obiektów tymczasowych. Czterobajtowy skok w libicuuc.so omijał ten SIGABRT, ale wywołanie ucol_open_72+56 nadal kończyło się błędem SIGSEGV.

To był potrzebny eksperyment z negatywnym zakończeniem: dowiódł, że problem nie leży już w ścieżce, uprawnieniach ani braku danych. Ścianą były reguły sortowania ICU wykonywane pod Houdini. Finalna metoda nie modyfikuje WSA i nie podmontowuje ICU do systemu.

6. Trimmer usunął strażnik globalizacji

Aplikację zbudowano z InvariantGlobalization=false. ILLink usunął gałąź if (!Invariant). W GlobalizationMode.Settings..cctor wynik gettera był wyrzucany:

call Settings.get_Invariant
pop
ldloca.s 0
call TryGetAppLocalIcuSwitchValue
...
call LoadICU
...
call Environment.FailFast

Przestawienie gettera na true nie pomagało, bo nikt nie używał wyniku. Skuteczny patch zatrzymał konstruktor przed LoadICU: w CoreLib offset 0x82100 zmieniłem z 0x12 (ldloca.s) na 0x2A (ret). W LZ4 był to literał pod 0x9D4DEB.

Po tej zmianie zniknął Environment.FailFast: Unable to load required ICU Globalization data.

7. Globalizacja bez niezaładowanego ICU

Po pominięciu LoadICU część wskaźników była pusta. GlobalizationNative_GetSortHandle wykonywało blr przez ucol_open == 0, więc proces skakał pod pc=0.

Najpierw zastąpiłem trzy punkty wejścia: GetSortHandle, CompareString i GetSortKey. Następnie objąłem poprawką wszystkie 36 eksportowanych funkcji globalizacji używanych przez runtime. Wyszukiwanie i porównania otrzymały bezpieczne procedury ARM64, a funkcje lokalizacyjne deterministyczne wartości. Dotyczy to m.in. IndexOf, LastIndexOf, StartsWith, EndsWith, CompareString, GetLocaleName i IsPredefinedLocale.

Końcowa libSystem.Globalization.Native.so ma 71 960 B:

E14B0710A9BD310FA26F7B83426E71D4AC0AE06688FB574807B4A2EB800B99BF

To warstwa zgodności laboratorium, a nie pełny zamiennik językowy ICU.

8. Blokady w kodzie zarządzanym

Zmiany weszły do Pwpw.Mobile.EdoHub.Core.dll. Wpis #67 ponownie skompresowałem do dokładnie 742 032 B.

9. Obfuskacja, która nie ukryła protokołu

Nazwy prywatnych klas i metod skrócono do _bz, _b6, _b3, ac.g, s.e i b.d. Zwiększyło to koszt ręcznej analizy, ale nie usunęło informacji potrzebnych do odtworzenia przepływu.

Pozostały czytelne:

• interfejsy, DTO, view-modele i część metod publicznych;
• tokeny metod i typów;
• maszyny stanów IAsyncStateMachine i MoveNext;
• zależności MvvmCross i System.Net.Http;
• literały endpointów, nagłówków i błędów;
• stosy łączące kod obfuskowany z RegulationsViewModel.

Obfuskowany łańcuch _bz+s.e → _bz+ac.g → _bz+b.d prowadził wprost do maszyny stanu AcceptRegulations. Literały X-Device, text/plain oraz komunikat probably no internet connection nie były jawne: odzyskano je przez zdeszyfrowanie zaciemnionych łańcuchów (§9.2).

XALZ/LZ4 nie jest obfuskacją. Po odczytaniu tabeli deskryptorów assembly można wyodrębnić, zanalizować po tokenach i wstawić ponownie.

9.1. Czym jest ta obfuskacja i na ile jest skuteczna

Obfuskatorem jest PreEmptive Dotfuscator (ślady w metadanych Core.dll). Zastosowano trzy techniki. Po pierwsze przemianowanie symboli: prywatne klasy i metody dostały krótkie nazwy _bz, _b6, ac.g, s.e, b.d. Po drugie zaciemnienie przepływu sterowania: właściwa maszyna stanów HTTP (_bz/ac::g(), token 0x060001F4) jest rozbita na przełączniki i fałszywe stany, które utrudniają odtworzenie kolejności wykonania. Po trzecie szyfrowanie literałów łańcuchowych: łańcuchy przechowywane są jako zaszyfrowane tablice bajtów i odszyfrowywane w czasie wykonania (§9.2).

Charakterystyczne dla tego profilu jest zachowanie metadanych .NET przy jednoczesnym szyfrowaniu literałów. Jawne pozostały wszystkie interfejsy publiczne, DTO i view-modele, tokeny metod i typów oraz nazwy maszyn stanu async (<AcceptRegulations>d__20), a także zależności MvvmCross i System.Net.Http, które bezpośrednio ujawniają architekturę rozwiązania. Literały protokołu (endpoint edoservices_012/acceptTerms, nagłówek X-Device, text/plain oraz komunikaty błędów) były natomiast zaszyfrowane i wymagały odwrócenia szyfru (§9.2). Odtworzenie logiki sprowadziło się zatem do mapowania tokenów oraz zdeszyfrowania łańcuchów.

Deobfuskacja sprowadziła się więc do prześledzenia stosów i tokenów. Odzyskana mapa jest jednoznaczna:

W aplikacji wykorzystano komercyjny pakiet Dotfuscator w konfiguracji łączącej zmianę nazw symboli, spłaszczenie przepływu sterowania oraz szyfrowanie literałów łańcuchowych, przy zachowaniu metadanych .NET. Jest to konfiguracja istotnie mocniejsza od samej zmiany nazw, jednak odwracalny offline schemat szyfrowania łańcuchów oraz nienaruszone metadane sprawiają, że nie chroni ona architektury protokołu, adresów endpointów ani operacji kryptograficznych. Stanowi to rozwinięcie ustalenia EDO-P-01: zastosowany poziom zaciemnienia kodu podnosi próg analizy, lecz pozostaje nieadekwatny do wartości chronionego zasobu tożsamościowego.

9.2. Szyfrowanie literałów i jego odwrócenie

Wbrew pierwotnemu założeniu Dotfuscator zaszyfrował literały łańcuchowe. W Core.dll na 734 łańcuchy jawne przypada 2230 zaszyfrowanych, w Droid.dll kolejne kilkaset. Zaszyfrowany łańcuch ma postać tablicy bajtów odszyfrowywanej w czasie wykonania przez wspólną metodę _a3::b(string, int32, string).

Sam deszyfrator jest podręcznikowym przykładem zaciemnienia przepływu. Jego konstruktor statyczny to festiwal śmieciowej arytmetyki: mnożenie przez jeden, dodawanie i natychmiastowe odejmowanie tej samej stałej (add 0x900000 / sub 0x900000), dzielenie przez jeden oraz switch na wartości zawsze prawdziwej. Instrukcje te nie zmieniają wyniku; służą wyłącznie zmyleniu dekompilatora i rozbiciu liniowego odczytu.

Sam algorytm szyfru jest natomiast słaby. Dla każdego znaku UTF-16 o bajtach (młodszy, starszy) tekst jawny odtwarza się jako jawny = starszy XOR ((młodszy + 1) mod 256). Młodszy bajt każdego znaku pełni rolę strumienia klucza, rosnącego o dwa na znak, przez co każdy szyfrogram niesie własny klucz. W praktyce oznacza to, że argument A_1 przekazywany do deszyfratora jest zbędny, a wszystkie łańcuchy da się odzyskać w pełni offline, bez uruchamiania aplikacji. Napisany na tej podstawie deszyfrator odtworzył komplet literałów.

Odzyskana zawartość pokazuje kluczowe parametry architektury, które mechanizm obfuskacji miał ukryć:

Wniosek jest taki, że szyfrowanie literałów podnosi próg analizy pobieżnej, lecz przy samoopisującym się kluczu i zachowanych metadanych nie chroni ani architektury protokołu, ani parametrów kryptograficznych, ani osadzonego materiału klucza.

10. Pierwszy skrót w SearchValues i jego koszt

CompareInfo..cctor tworzył SearchValues<char> z prawidłowego, stałego zbioru ASCII. Pod Houdini TryGetSingleRange<char> rzucało IndexOutOfRangeException.

Pierwsze obejście zastąpiło fabryki SearchValues.Create obiektem EmptySearchValues<T>. Aplikacja przeszła do ekranu regulaminu, co jednak naruszyło semantykę parserów w bibliotece standardowej BCL. Po kliknięciu przycisku walidator nagłówka wywoływał:

int invalidIndex = input.IndexOfAnyExcept(s_tokenChars);

Pusty zbiór zwracał 0, więc X-Device był uznawany za nieprawidłowy. Doraźne EmptySearchValues<T>.IndexOfAnyExcept => -1 przepuściło nazwę, ale parser text/plain nadal nie znajdował ukośnika. Użytkownik widział „brak Internetu”, mimo że Internet działał.

11. Jak zdjąłem fałszywy komunikat sieciowy

Warstwa aplikacji przechwytywała właściwy wyjątek i zastępowała go probably no internet connection. Zrobiłem dwie tymczasowe kompilacje diagnostyczne.

W _bz::j(Exception,string,HttpResponseMessage), token 0x060001B9, IL 0x1B9, offset 0x24F91, zmieniłem:

02 28 55 01 00 0A 26 2A

na ldarg.0; throw:

02 7A 00 00 00 00 00 00

To odsłoniło wrapper. Następnie w _bz/ac::g(), token 0x060001F4, IL 0x1DA, offset 0x2FDC2, rzuciłem zachowany wyjątek wewnętrzny. logcat podał dokładną przyczynę:

System.FormatException: net_http_headers_invalid_value, text/plain
 at System.Net.Http.Headers.MediaTypeHeaderValue.CheckMediaTypeFormat
 at System.Net.Http.StringContent..ctor
 at Xamarin.Android.Net.AndroidMessageHandler.<DoProcessRequest>d__140.MoveNext
 at _bz+s.e
 at _bz+ac.g
 at RegulationsViewModel.<AcceptRegulations>d__20.MoveNext

Obie sondy zostały wycofane po diagnozie i nie występują w finalnym APK.

12. Sieć i TLS działały

Proces łączył się z 185.31.88.82:8443. TLS 1.2 dochodził do skutku. Serwer przedstawiał certyfikat *.edoapp.pl, PWPW S.A., ważny 24.10.2025–24.10.2026. Względny endpoint to edoservices_012/acceptTerms.

Awaria następowała wcześniej, przy tworzeniu StringContent(..., "text/plain"). Komunikat o braku Internetu był błędnym mapowaniem wyjątku parsera.

13. Końcowy fix SearchValues

Zamiast omijać kolejne walidacje, przywróciłem prawdziwe zbiory znaków i wyłączyłem tylko dwie wadliwe optymalizacje.

TryGetSingleRange prawidłowo obliczał min i max, a padał dopiero w fazie mapy Span<bool> z localloc. Po wcześniejszym zwrocie fabryka wybiera skalarną implementację bitmapową lub probabilistyczną z prawdziwym zbiorem.

Nieosiągalny kod po ret wypełniłem nop, dzięki czemu CoreLib skompresował się do 1 066 866 B. Rekord XALZ miał 1 066 878 B i zmieścił się w pierwotnym slocie 1 066 975 B. Round-trip dał SHA-256:

5A1B8E868BC219C864E66995C498FBC6FAA29E444D9184050F365266E0DF01B7

14. Odrzucone hipotezy i ślepe odnogi

W dwudniowym reverse engineeringu ważne są również próby, które nie weszły do rozwiązania. Każda z nich rozstrzygnęła konkretną hipotezę.

Najważniejszy zwrot nastąpił po porzuceniu łatania kolejnych objawów. Skoro X-Device i text/plain psuły się w dwóch różnych walidatorach, wspólną przyczyną musiał być mechanizm wyszukiwania znaków. Przywrócenie prawdziwych SearchValues potwierdziło tę diagnozę.

Nie zostawiłem bind mountów ICU ani eksperymentalnych zmian w WSA jako wymogu uruchomienia aplikacji. Finalne dostosowanie znajduje się w kopii APK; WSA pozostaje wspólnym, stabilnym środowiskiem również dla mObywatela.

15. Weryfikacja końcowa po dwóch dniach pracy

APK zbudowałem przez apktool 3.0.3, wyrównałem zipalign i podpisałem niezależnym certyfikatem badawczym. apksigner potwierdził v2 i v3.

16. Wstępne ustalenia bezpieczeństwa

EDO-A-01: kontrole roota i blokady ekranu są po stronie klienta

Wynik detekcji roota i KeyguardManager.isDeviceSecure() sterują lokalną nawigacją i można je zmienić w przepakowanym kliencie. Potwierdziłem to do ekranu startowego. Nie potwierdziłem jeszcze obejścia operacji kryptograficznej, NFC ani podpisu.

EDO-P-01: obfuskacja nie chroni przepływu protokołu

Skrócone nazwy i szyfrowanie literałów utrudniają analizę, ale zachowane metadane oraz odwracalny offline szyfr łańcuchów wystarczyły do odtworzenia usług, endpointów, parametrów kryptograficznych i obsługi wyjątków (§9.2).

EDO-Q-01: mylące mapowanie wyjątków

Lokalny FormatException został pokazany jako brak Internetu. Tak szerokie mapowanie utrudnia diagnostykę i ukrywa klasę faktycznej awarii.

EDO-Q-02: pole PIN/PUK bez wymuszenia cyfr na klawiaturze sprzętowej

Ekranowy keypad ogranicza wejście tylko wizualnie; pole ma jedynie filtr długości, a w kodzie brak DigitsKeyListener i numerycznego inputType. Klawiaturą sprzętową (USB, Bluetooth, host WSA) można wpisać znaki niecyfrowe, w moim przypadku WESMAR zamiast sześciu cyfr. Sytuacja ta nie stanowi obejścia uwierzytelnienia, ponieważ PIN weryfikuje procesor karty, generuje jednak ryzyko wyczerpania limitu prób PIN i PUK oraz niespójności walidacji. Szczegóły i test w 19.3.2.

EDO-C-01: silne związanie z ARM64

Brak x86-64 nie jest podatnością. W połączeniu z natywną globalizacją i AdvSimd ogranicza jednak interoperacyjność i ujawnia założenia niewidoczne na fizycznym ARM.

17. Co pozostaje do zbadania

• rejestracja dokumentu przez NFC, CAN/MRZ i PIN;
• przechowywanie sekretów i danych dokumentu;
• Android Keystore, TEE i StrongBox;
• certificate pinning i kontrolowany MitM;
• reakcja API na przepakowany, ponownie podpisany klient;
• integralność żądań, nonce, replay i powiązanie z urządzeniem;
• podpis PDF i walidacja dokumentu wynikowego;
• zachowanie po restarcie i długiej sesji.

Samo sforsowanie uruchomienia na WSA nie stanowiło jeszcze podstawy do wystawienia oceny bezpieczeństwa aplikacji. Odblokowanie środowiska badawczego i odzyskanie spójnych binariów otworzyło dopiero drogę do właściwego badania kodu i protokołów. Dlatego ocenę punktową odnoszę wyłącznie do wyników deasemblacji i weryfikacji wykonawczej mechanizmów klienta, opisanych w kolejnych rozdziałach.

18. Narzędzia i ślad dowodowy

• apktool, zipalign, apksigner, adb, logcat, dumpsys;
• dnfile i ildasm do metadanych oraz IL;
• własny parser assembly-store i dekompresor XALZ/LZ4;
• K4os.Compression.LZ4 w trybie L12_MAX;
• analiza ELF, symboli i kodu ARM64;
• IDA Pro 9.4;
• SHA-256 oraz round-trip każdego przebudowanego assembly.

Powtarzalny patcher ma wersjoniezależny punkt wejścia i profile rozpoznawane po SHA-256 całego APK. Profil 1.7.1 został dwukrotnie sprawdzony od czystego pakietu. Nieznana przyszła wersja nie dostanie automatycznie starych offsetów: narzędzie zapisuje raport ABI oraz hashy krytycznych bibliotek i zatrzymuje się do czasu przeglądu nowego profilu.

19. Analiza statyczna: pierwszy przekrój

Ten etap dotyczy wyłącznie oryginalnego APK 1.7.1 o SHA-256 07768A1F0A07493D6A89A981E9603863787D04A750E04536FBB2E3CA8105B84B. Nie przenoszę wniosków z przebudowanej kopii badawczej na wydanie producenta. Zdekodowałem manifest i zasoby, a z oryginalnego assembly store ARM64 wyciągnąłem Pwpw.Mobile.EdoHub.Core.dll, Pwpw.Mobile.EdoHub.Droid.dll, Pwpw.Mobile.EdoHub.Interfaces.dll oraz Microsoft.Maui.Essentials.dll.

19.1. Szyfrowany magazyn dla danych lokalnych

Mimo zaciemnienia nazw pól, definicje typów oraz wywołania metod pozostają jawne w metadanych IL. SecureStorageKeys obejmuje PIN1, PIN2, CAN, MRZ, identyfikator urządzenia i certyfikatu, sól oraz prywatny klucz uwierzytelniający zapisany jako Base64. Kod biznesowy odczytuje i zapisuje je przez Microsoft.Maui.Storage.SecureStorage; lista certyfikatów jest przed zapisem serializowana do JSON.

Wyciągnięta z tego samego APK implementacja Maui nie jest zwykłym SharedPreferences. Tworzy AndroidX.Security.Crypto.EncryptedSharedPreferences z MasterKey w schemacie AES-256-GCM, nazwami kluczy szyfrowanymi AES-256-SIV i wartościami AES-256-GCM.

To jest potwierdzona ochrona zapisów aplikacji przed prostym odczytem pliku preferencji. Nie oznacza jeszcze, że klucz jest sprzętowo związany z TEE lub StrongBox: sam ten fakt wymaga odczytu właściwości Android Keystore na fizycznym urządzeniu i osobnego testu.

Jest też ważny szczegół dostępności. Gdy utworzenie zaszyfrowanych preferencji rzuca KeyStoreException, Java.Security.KeyStoreException albo BadPaddingException, implementacja Maui czyści cały magazyn i tworzy go ponownie. Kod nie pozwala jeszcze rozstrzygnąć, czy eDO App wcześniej synchronizuje wszystkie dane potrzebne do odtworzenia stanu. To będzie osobny test po kontrolowanej zmianie klucza lub przywróceniu kopii aplikacji.

19.1.1. Brak lokalnego kontenera tożsamości

To podstawowa różnica architektoniczna względem mObywatela. Zawartość bezpiecznego magazynu SecureStorageKeys obejmuje wyłącznie zdefiniowaną listę kluczy:

Magazyn nie zawiera danych osobowych: numeru PESEL, imienia, nazwiska, wizerunku ani grup danych. Modele PersonalData, Photo oraz DataGroup, gdzie DG1 oznacza MRZ, a DG2 wizerunek twarzy, istnieją wyłącznie jako obiekty w pamięci operacyjnej. Powstają podczas odczytu karty NFC i są niszczone komunikatem EndSessionMessage. Kod aplikacji nie zawiera żadnej warstwy trwałego zapisu danych dokumentu w SQLite, Realm ani w plikach płaskich.

Funkcja zapamiętywania danych nie narusza tej zasady. Metoda MrzInfo.RememberData zapisuje wyłącznie sumy kontrolne MRZ do bezpiecznego magazynu pod kluczem MRZ. Z kolei DocumentChoiceViewModel.RememberDocumentChoice to flaga interfejsu w jawnym rejestrze StorageKeys pod kluczem IdDocumentChoiceKey. Aplikacja utrwala jedynie parametry dostępowe do chipa NFC oraz preferencje widoku, bez danych tożsamościowych.

Architektura mObywatela opierała się na trwałym kontenerze mDowodu zapisanym w pamięci masowej, chronionym programowo funkcją PBKDF2 bez powiązania z Android Keystore, co umożliwiało atak offline na kopię danych. Aplikacja eDO App nie posiada takiego kontenera. Źródłem danych pozostaje fizyczny chip dowodu osobistego odczytywany przez interfejs NFC. W pamięci urządzenia pozostają jedynie tokeny sesyjne chronione przez EncryptedSharedPreferences z kluczem głównym w Android Keystore. W warstwie ochrony danych w spoczynku eDO App reprezentuje bezpieczniejszy model.

Dwa elementy techniczne wymagają odnotowania. Po pierwsze, klucz AUTHENTICATOR_PRIVATE_KEY_BASE64 zapisano w formacie Base64 zaszyfrowanym kluczem głównym, zamiast użyć nieeksportowalnego uchwytu w Keystore. Po odszyfrowaniu magazynu klucz prywatny można wyodrębnić. Po drugie, sprzętowe wiązanie klucza zależy od konkretnego telefonu. Test na fizycznym Xiaomi 13T Pro z systemem Android 16 wykazał obecność flagi android.hardware.hardware_keystore, czyli wsparcie dla środowiska TEE, przy braku flagi android.hardware.strongbox_keystore. Domyślny MasterKey biblioteki AndroidX jest na tym urządzeniu chroniony sprzętowo w TEE, bez dedykowanego układu StrongBox. Sama zdolność sprzętowa jest potwierdzona i odróżnia eDO od czysto programowego kontenera mObywatela.

19.1.2. Weryfikacja magazynu na żywym urządzeniu (WSA z rootem)

Ustalenia statyczne z §19.1 i §19.1.1 potwierdziłem empirycznie, odczytując prywatny katalog aplikacji na zrootowanym WSA (/data/data/pl.pwpw.edohub/). Wartości poniżej częściowo zamaskowano.

Plik sekretów …maui.essentials.preferences.xml ma postać AndroidX EncryptedSharedPreferences. Nazwy kluczy są szyfrogramem deterministycznym AES-SIV (wspólny prefiks Base64 AfnyGfQ…), a wartości szyfrogramem uwierzytelnionym AES-GCM w formacie Tink (prefiks wersji i identyfikatora klucza AUqzru…). Obok nich występują dwie pozycje __androidx_security_crypto_encrypted_prefs_*_keyset__, przechowujące zestawy kluczy opakowane kluczem głównym z Android Keystore. W chwili badania magazyn zawierał dokładnie dwa wpisy danych o długości wartości 105 oraz 47 bajtów.

Zawartość obu wpisów zidentyfikowałem bez odszyfrowywania, na podstawie znanego formatu zapisu. Wartość w EncryptedSharedPreferences jest ramką 4 bajty (typ) + 4 bajty (długość) + N bajtów łańcucha UTF-8, a szyfrowanie Tink AES-GCM dokłada stały narzut 33 bajtów (5 bajtów wersji i identyfikatora klucza, 12 bajtów wektora inicjującego, 16 bajtów znacznika uwierzytelnienia). Po odjęciu narzutu i ramki wpis 47-bajtowy odpowiada łańcuchowi o długości sześciu znaków, a wpis 105-bajtowy łańcuchowi o długości sześćdziesięciu czterech znaków. Sześcioznakowy łańcuch odpowiada numerowi CAN, utrwalonemu po zaznaczeniu opcji „Zapamiętaj numer CAN" i prezentowanemu w interfejsie w postaci zamaskowanej …886, natomiast łańcuch sześćdziesięcioczteroznakowy odpowiada identyfikatorowi urządzenia DEVICE_ID. Wniosek jest zgodny z deterministyczną naturą AES-SIV: ponowny zapis tego samego numeru CAN odtwarza tę samą nazwę klucza przy nowym, losowym szyfrogramie wartości.

Numer CAN jest zatem utrwalany, lecz wyłącznie w postaci zaszyfrowanej; w pliku ustawień jawnych …AppSettings.xml nie występuje. Plik ten zawiera jedynie flagi przepływu, między innymi IS_REGULATIONS_ACCEPTED_KEY, FIRST_RUN, SIGN_DOCUMENT_VIEW i CAN_CHANGE_SHOW_HELP_DIALOG, oraz token powiadomień. Nie stwierdzono w nim numeru CAN, ciągu MRZ ani numeru PESEL w postaci jawnej.

Wymagane jest zdefiniowanie granicy zaufania dla tego mechanizmu ochronnego. Prezentacja zamaskowanego numeru CAN w interfejsie dowodzi, że aplikacja odszyfrowuje wartość na żądanie kluczem głównym z Android Keystore. Na urządzeniu z uprawnieniami root klucz ten pozostaje używalny w kontekście aplikacji, wobec czego zapamiętany CAN jest tam odtwarzalny. Jest to wspólna właściwość każdego szyfrowania danych w spoczynku opartego o Keystore: chroni ono przed wydobyciem danych z samego pliku, na przykład z kopii zapasowej lub skradzionego nośnika, a nie przed żywym, skompromitowanym systemem, w którym klucz jest dostępny. Waga tego ograniczenia jest przy tym niska. CAN to sześciocyfrowy numer nadrukowany na awersie karty, w standardzie ICAO 9303 pełniący rolę słabego sekretu dostępowego do zestawienia kanału PACE; jego znajomość, bez fizycznego kontaktu NFC z kartą i bez kodu PIN, nie umożliwia żadnej operacji.

Deszyfracja literałów (§9.2) pozwoliła odtworzyć rzeczywiste nazwy kluczy magazynu i sklasyfikować je według trwałości. Trwale, na życzenie użytkownika, pamiętane są EDOAPP_CAN oraz EDOAPP_MRZ; obu odpowiadają pozycje menu „zapomnij CAN" i „zapomnij MRZ". Charakter trwały operacyjny mają DEVICE_ID oraz komplet kluczy Authenticatora (EDOAPP_AUTHENTICATOR_ID, _SALT, _PRIVATE_KEY_BASE64, _CERTIFICATE_LIST).

Postępowanie z kodami PIN wymaga sprostowania wcześniejszego uproszczenia. PIN tożsamości (PIN1) oraz PIN podpisu (PIN2) nie są pamiętane na stałe, lecz przechodzą przez zaszyfrowany magazyn przejściowo, na czas operacji, po czym są z niego jawnie usuwane. Kod zawiera dedykowaną procedurę czyszczącą wywoływaną w cyklu życia widoku, która kasuje PIN1, PIN2 oraz CERT_ID (SecureStorage.Remove), a wylogowanie wykonuje pełne SecureStorage.RemoveAll. Zapis PIN1 realizowany jest w warstwie Droid (SecureStorage.SetAsync), a wartość podlega następnie opisanemu skasowaniu. Jest to poprawna higiena: sekret uwierzytelniający nie pozostaje w spoczynku po zakończeniu operacji.

W środowisku WSA, pozbawionym czytnika NFC, nie doszło do rejestracji Authenticatora ani do operacji na karcie, wobec czego zaobserwowany magazyn zawierał wyłącznie zapamiętany CAN oraz DEVICE_ID, bez klucza prywatnego Authenticatora, sekretu TOTP i bez pozostałości kodów PIN, co jest zgodne z powyższą procedurą czyszczącą.

Katalogi databases/ oraz files/ zawierają wyłącznie komponenty Google, Firebase i Sentry. Nie odnaleziono bazy dokumentu, danych karty ani wizerunku twarzy. Empirycznie potwierdza to model bez trwałego kontenera tożsamości (§19.1.1) oraz brak zapisu dokumentów na nośnik (§19.3.5). Pełny zestaw sekretów operacyjnych można zweryfikować dopiero na urządzeniu z rzeczywistym odczytem karty.

19.2. Transport i piny certyfikatów

Manifest wskazuje network_security_config.xml. Dla edoapp.pl zapisano 11 pinów SHA-256, dla sigillum.pl kolejnych 6; dla obu domen i subdomen wyłączono ruch jawny. Zaufanie ograniczono do magazynu systemowego, bez magazynu certyfikatów użytkownika. W pliku nie ma dat ważności pinów.

Warstwa .NET nie podmienia tego transportu dowolnym klientem. IHttpMessageHandlerProvider zwraca Xamarin.Android.Net.AndroidMessageHandler, a kod tworzy z niego HttpClient. W kodzie własnym aplikacji nie znalazłem callbacku walidacji certyfikatu ani ścieżki typu „zaakceptuj każdy certyfikat”. To spina konfigurację Androida z faktycznym klientem HTTP; wcześniejszy test regulaminu dodatkowo potwierdził działające połączenie HTTPS.

Konfiguracja bazowa dopuszcza ruch cleartext dla pozostałych domen, w zasobach zidentyfikowano jednak wyłącznie archiwalny odnośnik ODR do http://ec.europa.eu/consumers/odr. Brak przesłanek wskazujących na transmisję danych wrażliwych otwartym kanałem HTTP.

19.3. Granice procesu Android

Wydanie produkcyjne ma android:debuggable="false" oraz android:allowBackup="false". Dostawca treści Maui deklaruje szeroki zestaw ścieżek plikowych obejmujący pamięć zewnętrzną oraz pamięć podręczną, jednak sam provider pl.pwpw.edohub.fileProvider ma atrybut exported="false". Dostęp z zewnętrznych procesów jest zablokowany, a pliki są udostępniane wyłącznie przez jawne nadanie uprawnień do URI.

Aplikacja udostępnia funkcję pobierania i przekazywania dokumentów. Weryfikacja zakresu uprawnień URI oraz czasu ich ważności wymaga testu z kontrolowaną aplikacją odbiorczą. Sama definicja ścieżek przy braku eksportu komponentu nie stanowi podatności.

Brak literału FLAG_SECURE w assembly biznesowych wynika z nakładania flagi w bazowej aktywności Androida. Weryfikacja dynamiczna na telefonie Xiaomi 13T Pro z systemem Android 16 potwierdziła obecność flagi SECURE w dumpsys window na wszystkich ekranach: CardActivityView, CanEntryView, AcceptSignDataView, SignDocumentView, RegulationsView oraz StartView. Próbny zrzut ekranu wykonany podczas procedury podpisu wygenerował czarny obraz, co potwierdza skuteczne działanie blokady przechwytywania widoku.

Eksportowana jest tylko jedna własna aktywność: SplashView. Manifest przypisuje jej cztery wejścia: start z ikony, edohub://application, edoapp://application i ACTION_SEND dla application/pdf. To jest zamierzona powierzchnia integracji z innymi aplikacjami.

Ścieżkę wejściową prześledziłem dalej niż manifest. IntentExtension.ToStartupAction bierze URI z intencji, otwiera je przez ContentResolver.OpenInputStream, kopiuje do MemoryStream, a następnie tworzy SignFileAction z nazwą i tablicą bajtów. Gdy odczyt się nie uda, adapter przekazuje pustą wartość zamiast kończyć proces. Ten adapter nie odczytuje Intent.Type i nie parsuje zawartości PDF; jest tylko mostem z Androida do kodu aplikacji.

Właściwa kontrola pojawia się w SignDocumentViewModel. Przed przejściem do dalszego kroku obowiązuje limit 0x500000, czyli 5 MiB. Następnie osobny walidator otrzymuje całą tablicę bajtów, odrzuca null, dane puste i dokument krótszy niż 290 B, a błędy walidacji zamienia na komunikat w interfejsie. To jest realna kontrola wejścia, choć sama obecność walidatora nie jest jeszcze dowodem odporności na uszkodzony lub celowo zbudowany PDF. Sprawdzę ją osobno dokumentami granicznymi i mutacjami struktury.

Te same wejścia URI prowadzą do dwóch odrębnych akcji startowych: parametr z URI może utworzyć CodeAction, a osobny parametr operacji jest najpierw parsowany jako Guid i dopiero wtedy tworzy NewOperationAction. Dynamicznie podam niepoprawne URI, pusty ClipData, wielokrotny ACTION_SEND i PDF o błędnej strukturze. Celem jest sprawdzenie walidacji całego łańcucha, nie tylko wywołanie ekranu.

Pozostałe eksportowane elementy nie są własną ścieżką biznesową eDO: odbiornik Firebase wymaga com.google.android.c2dm.permission.SEND, a androidx.profileinstaller.ProfileInstallReceiver wymaga android.permission.DUMP. Niezabezpieczony deklaracją permission odbiornik AppsFlyer przyjmuje tylko com.android.vending.INSTALL_REFERRER.

Własny AppsFlyerConversionDelegate odbiera dane konwersji i atrybucji, przechodzi po parach klucz–wartość i składa tekst diagnostyczny. W przejrzanej implementacji wynik nie jest zapisywany, przekazywany do logiki eDO ani używany do nawigacji. Ogranicza to wpływ spreparowanego referrera na aplikację, nie wyklucza jednak telemetrii instalacyjnej prowadzonej wewnętrznie przez pakiet SDK AppsFlyer. Zagadnienie to rozstrzygnie rejestracja ruchu sieciowego podczas pierwszego uruchomienia.

19.3.1. Sygnały integralności środowiska

IRootDetectionService nie sprowadza się do jednego testu su. Metoda IsRootedOrDangerous() łączy wynik rozpoznania roota, listy niepożądanych pakietów, wykrywania emulatora, flagi debugowalności i podłączonego debugera. Ten ostatni sygnał pochodzi bezpośrednio z Android.OS.Debug.IsDebuggerConnected. Są to lokalne wskaźniki stanu urządzenia.

Klasa IRootDetectionService nie wykonuje kryptograficznej atestacji stanu systemu. Weryfikacja ewentualnego odrzucania żądań przez serwer na podstawie parametrów nagłówka wymaga analizy ruchu sieciowego.

19.3.2. Pole PIN i PUK nie wymusza cyfr na klawiaturze sprzętowej

To ustalenie wyszło z obserwacji wykonaniowej, którą potem potwierdziłem w kodzie. Na ekranie PIN-u, mimo własnej ekranowej klawiatury numerycznej PinKeyboard, dało się wpisać znaki niecyfrowe z klawiatury sprzętowej: zamiast sześciu cyfr wpisałem słowo WESMAR. Na WSA jest to klawiatura hosta; na fizycznym Androidzie ten sam efekt da klawiatura USB albo Bluetooth.

Mechanizm jest znany: android:inputType="number" ogranicza jedynie miękką klawiaturę ekranową. Bez jawnego DigitsKeyListener albo InputFilter przepuszczającego tylko cyfry, klawiatura sprzętowa nie jest filtrowana. Kontrola kodu to potwierdza: w warstwie widoku PinView oraz PinKeyboard pole posiada wyłącznie filtr długości LengthFilter. W kodzie nie występuje DigitsKeyListener, numeryczny inputType ani filtr cyfr. Ograniczenie do cyfr wynika wyłącznie z układu graficznego klawiatury ekranowej, a nie z ograniczenia nałożonego na pole tekstowe. Ten sam wzorzec obejmuje ekrany zmiany PIN-u oraz PUK.

Wpływ na bezpieczeństwo: zjawisko to nie stanowi obejścia uwierzytelnienia, ponieważ PIN weryfikuje chip karty poleceniem APDU, które odrzuci ciąg znaków alfanumerycznych. Ryzyko dotyczy braku spójności walidacji oraz potencjalnego zużywania limitu prób. Jeżeli niepoprawny ciąg zostanie przekazany bezpośrednio do karty, każda próba dekrementuje licznik PIN, a w przypadku kodu PUK grozi trwałym zablokowaniem dowodu osobistego. Kwestię tego, czy PinValidatorBase.IsValid filtruje znaki niecyfrowe przed transmisją APDU, rozstrzygnie test z monitorowaniem licznika fizycznej karty. Ustalenie oznaczono jako EDO-Q-02.

19.3.3. Podpisywanie PDF: płytka walidacja klienta i pytanie WYSIWYS

Procedura składania podpisu kwalifikowanego została poddana deasemblacji oraz weryfikacji wykonawczej.

Po pierwsze, aplikacja kliencka nie zawiera biblioteki do parsowania plików PDF, takich jak PdfBox, iText czy PdfSharp. Walidacja w SignDocumentViewModel sprawdza jedynie nagłówek %PDF, rozmiar w granicach od 290 bajtów do 5 MiB oraz oblicza skrót SHA-256. Klient nie posiada powierzchni ataku parsera PDF, eliminując podatności typu XXE lub bomby dekompresyjne. Sam format PAdES generowany jest po stronie serwera Sigillum.

Po drugie, w kodzie aplikacji brak komponentu renderującego treść PDF. Widok StampPlacementView powiązany ze StampPlacementViewModel służy wyłącznie do określenia położenia pieczęci graficznej na siatce pól. W teście wykonawczym ekran ten wyświetlał jedynie schemat rozmieszczenia bez podglądu tekstu dokumentu.

Obecnie nie posiadam aktywnego certyfikatu kwalifikowanego; z podpisu mSzafir korzystałem wcześniej jako prezes Atlogika Sp. z o.o., dlatego test wykonawczy objął procedurę do etapu pozycjonowania pieczęci. Kluczowy fakt wynika bezpośrednio z kodu: aplikacja nie wyświetla podpisywanej treści. Przekazanie pliku do zewnętrznej przeglądarki przez akcję ACTION_VIEW jest opcjonalne i realizowane poza procesem eDO App. Narusza to zasadę WYSIWYS, czyli What You See Is What You Sign. Użytkownik autoryzuje operację kryptograficzną na danych binarnych, których integralności wizualnej klient nie wymusza.

Dochodzi do tego subtelniejsza warstwa, spójna z powyższym. Dokument i bajty podpisywane odczytywane są niezależnie: IntentExtension.ToStartupAction czyta URI przez ContentResolver.OpenInputStream do MemoryStream, osobno od jakiegokolwiek podglądu. Dla identyfikatora content:// przekazanego przez obcą aplikację zewnętrzny provider może zwrócić inną treść podczas podglądu, a inną w chwili podpisu, co otwiera drogę do podatności typu TOCTOU. Weryfikacja tego scenariusza wymaga osobnego testu z kontrolowanym dostawcą treści. Niezależnie jednak od podatności na wyścig, brak wymuszonego, czytelnego podglądu dokumentu przed złożeniem podpisu pozostaje najpoważniejszą wadą całej tej procedury.

Sprawdzenie 4 bajtów nagłówka %PDF i limitu rozmiaru to kontrola czysto formatowa. Aplikacja nie weryfikuje struktury dokumentu ani nie wyświetla jego stron. Użytkownik autoryzuje e-dowodem niezweryfikowane dane binarne, co przy braku podglądu pozwala na podrzucenie do podpisu zmanipulowanego pliku. Stanowi to podstawę do oznaczenia podatności jako EDO-A-02.

19.3.4. Walidacja wejścia QR i deep-link: potwierdzona dynamicznie

Jedyna eksportowana aktywność SplashView przyjmuje deep-linki edohub://application i edoapp://application; kod z QR mapuje się wewnętrznie na ten sam URI i przez IntentExtension.ToStartupAction na CodeAction albo NewOperationAction (parametry code, operation). To jest właściwa powierzchnia wejścia, więc sprawdziłem ją wykonaniowo.

Test był kontrolowany: wygenerowałem kod QR z treścią spoza formatu operacji (zwykłym tekstem) i zeskanowałem go w aplikacji. Reakcja jest wzorcowa: eDO odrzuciło kod komunikatem, że aplikacja odczytuje wyłącznie kody ze stron partnerów. dumpsys potwierdza, że proces nie padł i wrócił na StartView, bez crasha i bez przejścia w nieoczekiwany stan. Skaner QR waliduje więc treść względem oczekiwanego źródła, a nie przetwarza bezkrytycznie dowolnego ciągu.

Odfiltrowanie nieprawidłowych danych QR stanowi skuteczną warstwę ochronną klienta. W celu weryfikacji odporności na spreparowane parametry przeprowadzono test dynamiczny przez adb. Przekazano zestaw spreparowanych intencji: parametr operation ze zniekształconym formatem Guid, poprawny składniowo, niewystępujący w systemie Guid zerowy, parametr code z ciągiem wstrzyknięcia skryptu oraz pusty URI edoapp://application przy zimnym starcie procesu. W każdym przypadku parser ToStartupAction odrzucił wejście bez błędu krytycznego, a aplikacja powróciła do widoku StartView. Obsługa wejść zewnętrznych po stronie klienta zachowuje odporność na zniekształcone dane.

19.3.5. Brak zapisu dokumentów do pamięci współdzielonej

Zweryfikowałem odrębnie, czy aplikacja pozostawia pobrane lub podpisane dokumenty w lokalizacji dostępnej dla innych aplikacji, ponieważ była to realna słabość analizowana w przypadku mObywatela. W eDO nie stwierdzono ku temu podstaw. W kodzie nie występują typy odpowiedzialne za zapis ani udostępnianie plików na dysku, nie odnaleziono również literałów ścieżek do katalogu Downloads, pamięci zewnętrznej ani plików *.pdf. Liczne wystąpienia terminu „Download" odnoszą się do pobierania sieciowego, nie zaś do zapisu na nośniku. Dokument przeznaczony do podpisu jest wczytywany do pamięci (MemoryStream) i w niej pozostaje. Jest to ustalenie korzystne, spójne z modelem bez trwałego kontenera z §19.1.1: eDO nie utrwala treści dokumentów w pamięci urządzenia poza czasem operacji.

19.4. Diagnostyka i telemetria

W APK są Sentry, Firebase i AppsFlyer. Manifest ma io.sentry.auto-init=false, ale Setup inicjalizuje Sentry ręcznie, z własnym DSN ukrytym przez obfuskację. tracesSampleRate i profilesSampleRate ustawiono na 1.0. Kod wywołuje SentrySdk.CaptureException w blokach obsługi wyjątków, m.in. przy inicjalizacji aparatu oraz podczas odczytu i przetwarzania plików PDF. W warstwie Androida zidentyfikowałem ponadto dwa wywołania Android.Util.Log.Error dotyczące doboru rozdzielczości kamery, sparowane z wysyłką raportu do Sentry. Z kolei kod biznesowy implementuje interfejs IAnalyticsService z metodami TrackEvent i SendLog; zdarzenia telemetryczne rejestrowane są m.in. przy przejściu użytkownika do ekranu wprowadzania CAN.

W kodzie brak jawnego wywołania setSendDefaultPii(true), callbacku przypisującego tożsamość użytkownika oraz funkcji dołączania zrzutu ekranu. Nie wyklucza to jednak obecności danych wrażliwych w treści samych komunikatów wyjątków, a pełne próbkowanie śladów i profili (1.0) zwiększa ryzyko wycieku. Faktyczny zakres telemetrii zweryfikuje analiza ruchu sieciowego i bufora Sentry podczas wywołania kontrolowanego błędu testowego.

19.5. Biometria: FaceTec, przepływ danych twarzy i retencja

Weryfikacja tożsamości wykorzystuje silnik FaceTec, certyfikowane, komercyjne rozwiązanie do detekcji żywotności (Liveness 3D) oraz biometrycznego dopasowania twarzy. Kontrakty pozostają jawne w metadanych IL: interfejs IFaceTecClientService udostępnia operacje GetSessionToken, Enrollment3d, MatchFacePhoto, VerifyIdWithEnrollmentAndMatch oraz ConvertJP2ToJPEG, natomiast IFaceTecPlatformService odpowiada za sterowanie sesją. W warstwie prezentacji model FaceBiometryRecordingViewModel zarządza akwizycją klatek obrazu (OnNewFrame, StartRecording, HandleVideoSentMessage).

Obecność metody ConvertJP2ToJPEG jednoznacznie wyznacza schemat weryfikacji: skan trójwymiarowy z kamery jest zestawiany z wizerunkiem referencyjnym odczytanym z chipu dowodu osobistego, gdzie zgodnie ze specyfikacją ICAO 9303 zdjęcie twarzy (grupa DG2) kodowane jest w formacie JPEG 2000. Schemat ten zakłada zdalną autoryzację tożsamości, co wiąże się z transmisją danych biometrycznych poza urządzenie.

Zastosowanie renomowanego silnika biometrycznego, implementacja procedur czyszczenia buforów pamięci (wipe) oraz brak trwałego zapisu wizerunku na nośniku flash stanowią mocne punkty tej architektury. Kwestią wymagającą weryfikacji w teście dynamicznym pozostaje docelowy endpoint sieciowy, struktura przesyłanych pakietów oraz retencja danych po stronie serwera.

19.6. NFC i kryptografia karty

19.6.1. Zagrożenie skimmingiem i rola numeru CAN

Bezkontaktowy interfejs radiowy (ISO/IEC 14443) umożliwia transmisję danych drogą elektromagnetyczną bez bezpośredniego styku galwanicznego. W architekturze systemów RFID cecha ta rodzi specyficzne ryzyko: komunikacja może zostać zainicjowana przez czytnik przez materiał kieszeni, torebki czy portfela bez świadomości i woli posiadacza dokumentu. Zagadnienie to stanowiło realną podatność wczesnych generacji paszportów biometrycznych, w których brak wstępnego uwierzytelnienia pozwalał na pasywne odpytanie chipu z odległości i pozyskanie danych tożsamości (skimming).

W strukturze e-dowodu ochronę przed niekontrolowaną transmisją realizuje sześciocyfrowy numer CAN (Card Access Number) nadrukowany na awersie karty. Pełni on trzy kluczowe funkcje architektoniczne:

1. Optyczny dowód fizycznego dostępu i zgody (line-of-sight consent token). Odczyt logiczny danych wymaga uprzedniego odczytania numeru widocznego na dokumencie. Wiąże to nawiązanie sesji radiowej z bezpośrednią kontrolą wzrokową i fizycznym dostępem posiadacza do dokumentu. Zdalny odczyt przez kieszeń lub portfel w przestrzeni publicznej zostaje wykluczony, ponieważ bez znajomości CAN mikrokontroler karty odrzuca żądanie nawiązania sesji.
2. Materiał wejściowy dla protokołu PACE. Sześciocyfrowy ciąg stanowi ziarno (seed) dla funkcji wyprowadzania kluczy (KDF) w protokole PACE (Password Authenticated Connection Establishment, ICAO Doc 9303). W oparciu o ten parametr aplikacja i karta uzgadniają klucze sesyjne do szyfrowania i uwierzytelniania kanału (secure messaging). Chociaż przestrzeń 6 cyfr ($10^6$ kombinacji) jest niska w ujęciu czysto obliczeniowym, mikrokontroler karty egzekwuje sprzętowy licznik błędnych prób. Po przekroczeniu określonego limitu nieudanych autoryzacji procesor blokuje dalsze próby do momentu podania procedury odblokowującej, co uniemożliwia skuteczny atak siłowy (brute-force) na interfejsie radiowym.
3. Ergonomiczny ekwiwalent strefy MRZ. W paszportach biometrycznych rolę sekretu wejściowego do procedur BAC lub PACE pełni odczyt strefy maszynowej (Machine Readable Zone, MRZ), co wymaga fizycznego otwarcia dokumentu i optycznego skanowania kodów. W dowodzie osobistym CAN stanowi zminiaturyzowany, numeryczny odpowiednik MRZ, możliwy do szybkiego wprowadzenia ręcznego lub za pomocą mechanizmu OCR kamery.

Granice ochrony i model bezpieczeństwa CAN:
CAN jest celowo uproszczonym sekretem chronionym wyłącznie barierą optyczną, a nie poufnością kryptograficzną. Każdy podmiot mający wgląd w awers dowodu (np. pracownik instytucji weryfikującej tożsamość, obsługa hotelowa czy odbiorca kserokopii) zna numer CAN. Numer ten nie chroni dokumentu przed osobą posiadającą fizyczny dostęp do karty lub jej odwzorowania cyfrowego. Z tego względu architektura bezpieczeństwa e-dowodu rozdziela role na trzy odrębne mechanizmy:

• CAN: zabezpieczenie warstwy radiowej przed skimmingiem z dystansu (mechanizm zapobiegający nieautoryzowanemu wzbudzeniu interfejsu na odległość),
• PIN: poufne uwierzytelnienie intencji posiadacza dla operacji wrażliwych (nie jest nadrukowany na karcie i pozostaje niezbędny do złożenia podpisu osobistego lub kwalifikowanego),
• Chip Authentication: asymetryczna weryfikacja autentyczności mikrokontrolera (potwierdzenie, że fizyczny nośnik nie jest programową repliką lub emulatorem).

19.6.2. Wymiana APDU, protokół PACE i prymitywy kryptograficzne

NFC nie jest wyłącznie wywołaniem gotowego SDK. Interfejs ICardCommunicator ma surowe TransreceiveCommandRaw, wymianę APDU z limitem czasu, restart i anulowanie secure messaging oraz SetupChipAuthentication. Warstwa PACE tworzy własny klucz z sekretu, odszyfrowuje nonce, wylicza wspólny sekret i token uwierzytelnienia. W tym samym przepływie IAuthenticatorService otrzymuje PIN, identyfikator certyfikatu, klucz publiczny serwera, zakodowany sekret TOTP i klucz rejestracyjny.

Implementacja wyprowadzania kluczy jest czytelna mimo obfuskacji: dla KSenc dokleja do sekretu czterobajtowy licznik kończący się 01, dla KSmac analogiczny licznik z 02, po czym liczy skrót. Dostępne profile obejmują AES-128/192/256 i 3DES; dla chip authentication są DH i ECDH z 3DES-CBC-CBC lub AES-CBC-CMAC. Używana jest biblioteka Bouncy Castle.

W funkcji skrótu znajduje się także gałąź SHA-1. Fakt ten nie stanowi wprost luki bezpieczeństwa: standardy kartowe definiują profile wstecznej zgodności, a analiza statyczna kodu nie przesądza, czy procesor dowodu osobistego i jego OID wybierają tę ścieżkę. Test z fizycznym dokumentem zweryfikuje negocjowany algorytm, OID i długość kluczy.

Weryfikacja komponentów potwierdza zgodność implementacji ze standardami. W bibliotece Core.dll obecne są klasy Sha1Digest, Sha256Digest, AesEngine, DesEdeEngine (3DES), CMac z dopełnieniem ISO9797 oraz struktury PaceInfo, ChipAuthenticationInfo i SecurityInfos. Odpowiada to specyfikacji protokołów PACE oraz Chip Authentication według ICAO 9303, zrealizowanej w oparciu o bibliotekę Bouncy Castle. Zestaw szyfrów jest negocjowany na podstawie parametrów karty (SecurityInfos oraz identyfikatory OID), a nie narzucany statycznie przez aplikację. Gałąź SHA-1 oraz 3DES uaktywnia się wyłącznie w przypadku zadeklarowania jej przez chip dokumentu, co wynika z wymogów wstecznej zgodności ze specyfikacją ICAO, a nie z implementacji eDO App. Stanowi to różnicę względem mObywatela, w którym zastosowano własny kontener CBC ze stałą solą bez mechanizmów uwierzytelnienia; eDO App wykorzystuje standardowy protokół oraz audytowaną bibliotekę Bouncy Castle. Wybór algorytmu dla polskiego dowodu osobistego zostanie zweryfikowany podczas rejestracji sesji NFC w części dynamicznej.

19.7. Protokół Authenticatora: autoryzacja podpisu kwalifikowanego

Kluczowym modułem eDO App jest mechanizm Authenticatora, odpowiedzialny za autoryzację operacji podpisu kwalifikowanego. Protokół odtwarza się bezpośrednio z metadanych i interfejsu IAuthenticatorClient, struktur DTO oraz maszyn stanu w bibliotece Core.dll.

Procedura obejmuje cztery etapy:

1. Rejestracja (SetupAuthenticator). Klient generuje parę kluczy asymetrycznych i przekazuje klucz publiczny w żądaniu SetupAuthenticatorRequest{PublicKey, PublicKeyType, AuthenticatorId, OperationId}. W odpowiedzi serwer zwraca SetupAuthenticatorResponse{TotpSecret, PublicKey, CertificateId}, provisionując sekret TOTP oraz identyfikator certyfikatu. Wygenerowany klucz prywatny oraz sekret TOTP trafiają do lokalnego magazynu SecureStorage.
2. Pobranie operacji (LoadOperation). Odpowiedź serwera zawiera parametry Counter, CreatedAt oraz ExpiresAt. Numeryczna sekwencja operacji i ograniczenie czasu ważności zapewniają ochronę przed atakami typu replay oraz przetwarzaniem przeterminowanych żądań.
3. Autoryzacja (ConfirmOperation{Totp, OperationId}). Potwierdzenie operacji bazuje na jednorazowym kodzie TOTP wyliczanym z lokalnego sekretu i powiązanym z identyfikatorem zadania.
4. Złożenie podpisu. Obiekt SignaturePayloadDto przekazuje parametry Challenge, Timestamp, Data i Certificate. Z kolei struktura SignatureDataDto zawiera skróty grup danych dokumentu (Sod), flagi Authentication i OperationSecurity oraz numer seryjny karty (CardSerialNumber). Procedura implementuje mechanizm challenge-response z kryptograficznym wiązaniem z fizycznym chipem dowodu osobistego.

Wnioski z analizy architektury:
Sam protokół zaprojektowano prawidłowo. Wykorzystuje standardowe mechanizmy challenge-response, TOTP, sekwencyjne liczniki operacji, okna czasowe ważności oraz powiązanie podpisu z danymi fizycznej karty.

Identyfikowane ryzyko architektoniczne:
Prywatny klucz Authenticatora oraz sekret TOTP są serializowane do magazynu SecureStorage jako ciągi Base64. Mimo szyfrowania bazy kluczem z Android Keystore, sekrety te po odszyfrowaniu mają postać jawną w pamięci procesu, a nie nieeksportowalnych uchwytów sprzętowych chronionych w TEE. Ekstrakcja danych z odblokowanego lub zrootowanego urządzenia umożliwia odtworzenie generatora autoryzacji poza fizycznym telefonem.

Weryfikacja tego, czy serwer bezwzględnie egzekwuje parametry wyzwania, sekwencję licznika i limity czasu, stanowi przedmiot badania dynamicznego w kolejnym etapie prac.

20. Dygresja: brak czytnika NFC w WSA i przekaźnik APDU

WSA nie obsługuje kontrolera NFC, co uniemożliwia bezpośredni odczyt dowodu osobistego w maszynie wirtualnej. Podpis i odczyt zrealizowano na fizycznym telefonie Xiaomi 13T Pro. Poniższa architektura przedstawia koncepcję programowego przekaźnika ramek APDU przez sieć lokalną, pozwalającego na odczyt karty w środowisku WSA przy użyciu telefonu jako zdalnego czytnika.

Rozwiązaniem technicznym jest przekaźnik ramek APDU. Aplikacja eDO App komunikuje się z chipem dowodu poleceniami IsoDep.transceive, a protokoły PACE oraz bezpieczne kanały wymiany danych działają bezpośrednio między aplikacją a procesorem karty. Warstwa transmisyjna przesyła zaszyfrowane ramki bez konieczności ich modyfikacji.

Koncepcja wdrożenia:

1. Moduł LSPosed w WSA. Przechwycenie wywołań NfcAdapter.getDefaultAdapter oraz isEnabled w celu emulacji dostępności kontrolera NFC. Metoda IsoDep.transceive w warstwie Java jest przechwytywana przez LSPosed pomimo wywołania ze środowiska Xamarin.
2. Wstrzyknięcie tagu. Sfabrykowanie zdarzenia wykrycia karty w enableReaderMode oraz podstawienie instancji IsoDep przy użyciu mechanizmów refleksji.
3. Warstwa transportowa. Przekazywanie przechwyconych ramek APDU przez protokół TCP z wykorzystaniem przekierowania adb forward.
4. Demon na telefonie fizycznym. Aplikacja z aktywnym enableReaderMode wykonująca polecenie realIsoDep.transceive na przyłożonym dowodzie i odsyłająca odpowiedź do gniazda sieciowego w WSA. Wymaga obsługi rozszerzonych ramek APDU zadeklarowanych przez ExtendedLengthAPDUSupportedKey oraz zachowania limitów czasowych transmisji.

Architektura ta bazuje na mechanizmie przekaźnika APDU tożsamym z technikami typu relay attack na interfejsy zbliżeniowe. Z punktu widzenia inżynierskiego brak kontrolera NFC w WSA stanowi ograniczenie sprzętowe, które można rozwiązać programowo.

21. Reprodukowalność, dystrybucja i licencja

Procedurę modyfikacji zautomatyzowano skryptem weryfikującym sumę kontrolną SHA-256 oryginalnego pakietu APK oraz instalującym zmodyfikowane pliki poleceniem adb install -r z zachowaniem danych aplikacji.

Kod źródłowy mObywatela opublikowano na licencji MIT, co zezwalało na redystrybucję. Aplikacja eDO App stanowi oprogramowanie własnościowe PWPW S.A. Modyfikacja lokalnej kopii w celu zapewnienia interoperacyjności mieści się w granicach dozwolonego użytku, natomiast dystrybucja zmodyfikowanych binariów PWPW naruszałaby prawa autorskie producenta. Z tego względu repozytorium nie zawiera plików binarnych.

Paczka zawiera wyłącznie metodykę i skrypty weryfikacyjne: pliki automatyzujące, definicje profili oraz payload-manifest.json z sumami kontrolnymi SHA-256 wymaganych komponentów. Skrypt patch-eDO-App-1.7.1-WSA.ps1 sprawdza obecność podkatalogu payload/ zdefiniowanego w manifeście; skoro ze względów licencyjnych celowo go tam nie ma, skrypt zatrzyma się z błędem braku plików wsadowych. Dzięki temu repozytorium stanowi ścisły ślad dowodowy i weryfikator integralności, a nie kanał redystrybucji chronionego kodu producenta.

Potwierdzeniem działania procedury uruchomieniowej jest materiał wideo na YouTube rejestrujący start aplikacji na WSA z aktywnym MagiskSU, przejście przez akceptację regulaminu oraz załadowanie widoku StartView.

22. Ocena architektury bezpieczeństwa klienta

Ocena dotyczy warstwy aplikacji klienckiej Android (pl.pwpw.edohub) i opiera się na analizie statycznej trzech głównych assembly .NET, deasemblacji zasobów oraz testach dynamicznych wykonanych na telefonie bez uprawnień root. Nie stanowi audytu infrastruktury serwerowej PWPW ani fizycznego procesora karty kryptograficznej. Wagi poszczególnych osi odzwierciedlają model zagrożeń aplikacji tożsamościowej: decydujące znaczenie ma ochrona danych w spoczynku (25%) oraz integralność procedury podpisu kwalifikowanego (20%), podczas gdy podatność kodu na inżynierię wsteczną traktowana jest jako warstwa pomocnicza (5%). Weryfikacja ruchu telemetrii, atestacji klucza w Keystore, integralności po stronie serwera oraz odporności pinningu na inspekcję TLS wymaga środowiska z rootem i stanowi przedmiot kolejnego etapu badań.

Wynik ważony: ≈ 7,3/10: ocena dobra (górny przedział skali).

Podsumowanie wyników. Architektura eDO App wykazuje wyższy poziom bezpieczeństwa danych w spoczynku niż mObywatel. Brak lokalnego kontenera danych tożsamościowych eliminuje ryzyko ich ekstrakcji offline z kopii zapasowej. Dane uwierzytelniające chroni Android Keystore powiązany z TEE, a operacje kryptograficzne bazują na standardzie ICAO 9303 oraz zweryfikowanej bibliotece Bouncy Castle. Główną wadą rozwiązania pozostaje brak wymuszonego podglądu dokumentu przed złożeniem podpisu kwalifikowanego (fakt weryfikowalny bezpośrednio w kodzie widoku i view-modelu), uzupełniony o uchybienia w walidacji wejścia klawiatury sprzętowej oraz o obfuskację, która mimo szyfrowania literałów pozostaje odwracalna offline.

Porównanie z architekturą mObywatela. Przyjęty przez PWPW model bezpieczeństwa cechuje większy rygor inżynierski. Oparcie tożsamości na fizycznej karcie kryptograficznej, brak programowych magazynów tożsamości podatnych na ekstrakcję offline oraz implementacja standardowych protokołów kryptograficznych stanowią rozwiązania dojrzalsze od pierwotnej architektury mObywatela.

Nota autorska. Piszę to jako inżynier, który od lat dziewięćdziesiątych rozkłada oprogramowanie na części pierwsze i buduje własne, ulepszone wersje, w tym natywnego, desktopowego klienta mObywatela. Moje publiczne projekty (github.com/wesmar) sięgają warstw HVCI, EFI, DSE i PPL, dlatego klienta operującego wyłącznie w przestrzeni użytkownika, przez PC/SC i publiczne biblioteki kryptograficzne, traktuję jako zadanie inżyniersko proste. Przy dzisiejszym warsztacie i narzędziach realistycznie szacuję około trzech tygodni na działający szkielet i kolejne trzy na dopracowanie całości klienta do wersji w pełni dojrzałej i wydajnej. Znając strukturę klienta, zestaw protokołów i format magazynu, stawiam tezę praktyczną: warstwę odczytu e-dowodu da się odtworzyć jako natywną aplikację desktopową dla Windows w nowoczesnym C++23 na WinAPI. Odczyt tożsamości opiera się na otwartym standardzie ICAO 9303 (PACE, Chip Authentication, Passive Authentication, DG1/DG2/SOD), dostępnym przez interfejs PC/SC (WinSCard) i publiczne biblioteki kryptograficzne, bez żadnego zastrzeżonego komponentu PWPW. Wiele laptopów ma dziś czytnik NFC, a tam gdzie go brak, wystarcza tani czytnik PC/SC na USB; niezależny klient rozwiązałby realny problem osób, które eDO App na telefonie mieć nie mogą lub nie chcą.

Zachowanie transparentności systemowej wymaga dokładnego zdefiniowania granic między obiema warstwami, zamiast jedynie deklaratywnego ujęcia problemu. Warstwa odczytu charakteryzuje się bezpośrednią odtwarzalnością. Warstwa usługowa (internetowy Authenticator eDO oraz komunikacja z Sigillum) jest odtwarzalna co do zasady, lecz wyższym kosztem: wymaga przechwycenia i odtworzenia protokołu sieciowego (zdjęcie przypinania certyfikatu na własnym urządzeniu, analiza ruchu), ewentualnie sprzętowego podsłuchu wymiany APDU z kartą. Jest to wykonalne metodą logika + ruch + sniffing, a znajomość kodu daje tu istotną przewagę. Nie przesądzam wykonalności końcowej, ponieważ nie zbadałem jeszcze, czy serwery PWPW nie wymuszają atestacji integralności klienta, co stanowi właściwe pytanie etapu dynamicznego. Odrębną barierą, tym razem nie techniczną, lecz prawną, pozostaje status podpisu kwalifikowanego: jego moc wynika z certyfikowanego procesu dostawcy usług zaufania (QTSP) i ważnego certyfikatu w rozumieniu eIDAS, a nie z samego klienta. Taka implementacja byłaby moim autorskim kodem, dystrybuowanym bez binariów PWPW, i pozostawałaby w domenie interoperacyjności, nie zaś obchodzenia zabezpieczeń.

23. Puenta

Etap uruchomieniowy na WSA potwierdził konieczność wyeliminowania niezgodności w pięciu obszarach: native bridge, biblioteka ICU, zachowanie trimmera kodu, obfuskacja klienta oraz błędy translatora Houdini przy obsłudze wektorowych optymalizacji SIMD w bibliotece standardowej .NET 9. Moduł Zygisk działa poprawnie w konfiguracji końcowej.

Przywrócenie prawidłowej semantyki parsera HTTP oraz precyzyjne wyłączenie wadliwych optymalizacji umożliwiło przeprowadzenie audytu bezpieczeństwa klienta: interfejsu NFC, stosowanych algorytmów kryptograficznych, protokołu komunikacji oraz magazynu danych.

Badania dynamiczne wymagające uprawnień root, obejmujące inspekcję ruchu TLS, analizę atestacji kluczy w Keystore oraz weryfikację reakcji serwera na zmodyfikowanego klienta, zostaną zrealizowane w dedykowanym środowisku laboratoryjnym.

Badanie prowadzę na własnym urządzeniu wirtualnym, własnym koncie i własnym dokumencie. Opis dotyczy interoperacyjności i oceny bezpieczeństwa klienta. Nie zawiera danych osobowych ani PIN-u.

Add a comment

Name (optional)

Email (optional, never published)

Comment *

Type the characters from the image *

Submit