Korekta i redakcja: Nightmare

Niemiecki portfel tożsamości będzie wymagał Google/Apple

Dokumentacja architektoniczna niemieckiego wdrożenia cyfrowego portfela tożsamości ujawnia, że aplikacja będzie w praktyce wymagała urządzenia certyfikowanego przez Google lub Apple. Dostęp do państwowej usługi identyfikacji może być uzależniony od posiadania konta u jednej z tych firm. W Polsce mObywatel jest już dostępny wyłącznie przez ich sklepy - a to może być zapowiedzią tego, co nas czeka.

Federalne Ministerstwo Spraw Wewnętrznych Niemiec (dalej „BMI”) opublikowało dokumentację architektoniczną krajowej implementacji cyfrowego portfela tożsamości [1] wymaganego przez znowelizowane unijne rozporządzenie dotyczące elektronicznej identyfikacji i usług zaufania. Dokument opisuje mechanizm Mobile Device Vulnerability Management (dalej „MDVM”), który za zadanie ma weryfikować bezpieczeństwo urządzeń użytkowników. Analiza wspomnianej dokumentacji przez społeczność techniczną [2] pokazuje, że w praktyce system obsługuje wyłącznie urządzenia działające w ekosystemach Google i Apple.

Czym jest eIDAS 2.0 i EUDI Wallet?

eIDAS (ang. Electronic IDentification, Authentication and trust Services) to unijna regulacja dotycząca elektronicznej identyfikacji i usług zaufania. Jej nowelizacja - eIDAS 2.0 - zobowiązuje kraje członkowskie do wdrożenia EUDI Wallet: cyfrowego portfela tożsamości, który pozwoli obywatelom UE potwierdzać swoją tożsamość, korzystać z dokumentów i podpisywać je elektronicznie w całej Unii za pomocą jednej aplikacji mobilnej [3].

Na czym polega problem z niemieckim wdrożeniem?

Dokumentacja BMI opisuje, jakie sygnały z urządzenia będą zbierane i weryfikowane w celu potwierdzenia jego bezpieczeństwa. Na ten moment są to wyłącznie mechanizmy atestacji (ang. attestation) oferowane przez dwie platformy:

• Google Play Integrity API - dla urządzeń z Androidem,
• Apple DCDeviceCheck / App Attest - dla urządzeń z iOS.

Mechanizmy atestacji kryptograficznie potwierdzają, że urządzenie pochodzi od producenta, uruchamia niezmodyfikowany system operacyjny oraz że aplikacja została pobrana z oficjalnego sklepu. Ostatni warunek jest kluczowy: Google Play Integrity pozwala wykryć, że aplikacja została zainstalowana ze Sklepu Play, co pośrednio oznacza konieczność posiadania konta Google, jeśli deweloper aplikacji będzie tego wymagał.

Dokumentacja wprost wymienia jako potencjalne zagrożenia m.in. „unknown system image (e.g. custom ROM)”, czyli sytuację, w której użytkownik zainstalował na swoim telefonie alternatywny system operacyjny, taki jak GrapheneOS czy LineageOS. Urządzenie z takim systemem nie przejdzie weryfikacji - niezależnie od rzeczywistego poziomu jego bezpieczeństwa.

Dodatkowym wymogiem jest posiadanie bieżącej wersji oprogramowania: warunek MEETS_STRONG_INTEGRITY w Play Integrity API wymaga, aby urządzenie otrzymało łatkę bezpieczeństwa nie starszą niż 12 miesięcy. Wyklucza to urządzenia, których producenci zaprzestali wydawania aktualizacji - nawet jeśli są to sprawne telefony używane na co dzień.

Czy specyfikacja eIDAS 2.0 tego wymaga?

Nie. Specyfikacja techniczna eIDAS 2.0 nie narzuca konkretnych platform ani ekosystemów. Wymaga natomiast, by portfel tożsamości spełniał określone wymogi bezpieczeństwa kryptograficznego - w tym ochrony kluczy prywatnych przed skopiowaniem czy nieuprawnionym użyciem. Krytycy projektu wskazują, że te same wymogi można spełnić przy użyciu innych mechanizmów, np. sprzętowych kluczy bezpieczeństwa zgodnych ze standardem FIDO2 lub atestacji sprzętowej niezależnej od usług platformy.

Austria wdrożyła już rozwiązanie, w którym do korzystania z cyfrowej tożsamości na komputerze wystarczy właśnie klucz FIDO2 - token bezpieczeństwa dostępny od wielu niezależnych producentów.

Użytkownik podający się za jednego z twórców niemieckiego projektu odpowiedział na uwagi w publicznym systemie zgłoszeń błędów, przyznając, że obsługa alternatywnych systemów, jak GrapheneOS, jest na liście zadań, ale na razie zespół skupia energię na wdrożeniu dla głównych platform.

Dlaczego niezależność od korporacji jest kluczowa dla suwerenności?

Wbudowanie rozwiązań od korporacji takich jak Google i Apple w infrastrukturę cyfrowej tożsamości oznacza, że prywatne firmy z siedzibą poza Unią Europejską zyskują faktyczną kontrolę nad dostępem obywateli do własnych dokumentów i usług państwowych.

Ta zależność jest groźna z kilku powodów:

Konto można stracić bez powodu i bez odwołania

Konta Google i Apple są blokowane przez algorytmy moderacji - często bez ostrzeżenia, bez jasnego uzasadnienia i bez skutecznej ścieżki odwoławczej. Jeden z uczestników dyskusji na Hacker News opisuje przypadek, gdy jego wujek stracił cztery konta Google - z powodów takich jak: zapomnienie hasła, pożar, czy automatyczne zablokowanie za „podejrzaną aktywność walutową” wynikającą ze zwykłego zamieszkiwania w kilku krajach. Jeśli tożsamość cyfrowa jest związana z takim kontem, zablokowanie konta oznacza wykluczenie z usług państwowych.

Decyzja korporacji może mieć skutki polityczne

W 2025 roku Stany Zjednoczone Ameryki (USA) nałożyły sankcje na urzędników Międzynarodowego Trybunału Karnego - obywateli europejskich, którzy w następstwie stracili dostęp do usług amerykańskich firm. Gdyby infrastruktura tożsamości cyfrowej zależała od kont Google lub Apple, podobna decyzja mogłaby pozbawić obywatela UE dostępu do jego własnych dokumentów cyfrowych - bez wyroku sądu i bez procedury odwoławczej. To nie jest scenariusz teoretyczny.

Suwerenność cyfrowa nie może istnieć na cudzym fundamencie

Ustawa o Ochronie Danych Osobowych z dnia 10 maja 2018 r. z późn. zm. (RODO) w artykułach 44-50 reguluje zasady, na podstawie których odbywać się może przekazywanie danych osobowych do podmiotów znajdujących się na terytoriach niewchodzących w skład Europejskiego Obszaru Gospodarczego (EEA). Jednym ze sposobów, na podstawie artykułu 45, ustępu 2, RODO, jest uznanie przez Komisję Europejską państwa za „bezpieczne”. Za państwa „bezpieczne” uznano m.in. Argentynę, Japonię, Nową Zelandię, Wielką Brytanię czy też Koreę Południową. Natomiast na liście państw „bezpiecznych” nie znajdują się USA. Jest to wynikiem dwóch wyroków Trybunału Sprawiedliwości Unii Europejskiej, odpowiednio w sprawie Schrems I [4] dotyczącej ram transferowych „Safe Harbour” oraz w sprawie Schrems II [5] dotyczącej ram transferowych „Privacy Shield”, ze względu na nadmierne uprawnienia służb wywiadowczych USA w świetle prawa Unii Europejskiej.

Europejskie dyskusje o strategicznej autonomii cyfrowej tracą sens, jeśli podstawowa infrastruktura identyfikacji obywateli opiera się na firmach, których serwery, zasady działania i decyzje biznesowe są poza jakąkolwiek kontrolą europejskich rządów i sądów.

Komentarz eksperta

O komentarz do kwestii europejskiej suwerenności cyfrowej poprosiliśmy bezpośrednio prof. dr. Thomasa Fankhausera z Hochschule Heilbronn.

„Uważam, że dla większej europejskiej suwerenności cyfrowej konieczne jest, abyśmy stali się znacznie bardziej niezależni w domenie cyfrowej i ograniczyli nasze uzależnienie od zewnętrznych dostawców technologii. W związku z tym staram się coraz częściej zastępować amerykańskie usługi tam, gdzie jest to wykonalne - na przykład przechodząc z Google na Proton, z GitHub na prywatną instancję Gitea, a z chmurowych usług AI na lokalnie hostowane modele językowe. Nadal jednak dostrzegam, że ekosystemy mobilne są szczególnie trudne do zastąpienia.”

Prof. Dr. Thomas Fankhauser
Profesor systemów rozproszonych, baz danych, przetwarzania w chmurze, sztucznej inteligencji i tworzenia aplikacji webowych
Przewodniczący Komisji Egzaminacyjnej ds. Inżynierii Oprogramowania i Stosowanej Informatyki
Hochschule Heilbronn
[Przetłumaczono z języka angielskiego / Translated from English]

Polska: mObywatel jako zapowiedź podobnego problemu

W Polsce ta podległość już istnieje - choć na razie na poziomie dystrybucji, a nie architektury.

Aplikacja mObywatel, będąca krajowym cyfrowym portfelem dokumentów tożsamości, jest dostępna wyłącznie za pośrednictwem Google Play i Apple App Store [6]. Nie istnieje oficjalna wersja dla alternatywnych sklepów z aplikacjami (np. F-Droid), nie ma możliwości pobrania pliku instalacyjnego bezpośrednio od wydawcy. Użytkownik telefonu bez usług Google - np. korzystający z telefonu Huawei po sankcjach, z LineageOS lub ze starszego urządzenia z alternatywnym systemem - jest oficjalnie pozbawiony możliwości instalacji mObywatela.

Jest to wzorzec identyczny z tym, który Niemcy chcą teraz wbudować w architekturę systemu na poziomie weryfikacji bezpieczeństwa urządzeń.

Co może nas czekać w Polsce?

Polska, wdrażając EUDI Wallet, stanie przed tym samym wyborem co Niemcy: czy oprzeć weryfikację urządzeń na mechanizmach Google i Apple, czy poszukać rozwiązania niezależnego od tych ekosystemów.

Jeśli Polska pójdzie drogą wyznaczoną przez Niemcy, zależność od tych firm zostanie wbudowana głęboko w architekturę systemu. Urządzenia bez certyfikacji Google lub Apple będą traktowane przez system jako potencjalne zagrożenie bezpieczeństwa, a nie po prostu jako nieobsługiwane. Zmiana takiej decyzji w przyszłości będzie wymagała zmiany kodu aplikacji, a więc będzie to zmiana trudniejsza niż samo udostępnienie aplikacji w dodatkowym sklepie.

Warto podkreślić, że sama specyfikacja eIDAS 2.0 pozostawia tu przestrzeń na bardziej suwerenne rozwiązanie, jak pokazuje to przykład Austrii. Tylko czas pokaże, czy Naukowa i Akademicka Sieć Komputerowa - Państwowy Instytut Badawczy (dalej „NASK-PIB”), odpowiedzialna za polską wersję EUDI Wallet, która ma u nas zawitać w postaci nowej wersji mObywatela, będzie świadoma tego wyboru i czy zdecyduje się skorzystać z prawdziwie suwerennych rozwiązań.

Gdzie można śledzić prace i zgłaszać uwagi?

Niemcy prowadzą prace nad dokumentacją w sposób otwarty. Publiczne repozytorium projektu oraz system zgłoszeń są dostępne na platformie OpenCode [7] - instancji GitLab prowadzonej przez administrację federalną. Uwagi do dokumentacji można zgłaszać, zakładając konto w tym systemie.

Polska z kolei prowadzi prace w sposób nietransparentny. Do tej pory nie udostępniono publicznie kodu aplikacji mObywatel (Kontrabanda). Niestety, jedyny oficjalny sposób dla obywatela na wyrażenie swojej opinii wobec kierunku rozwoju mObywatela to pismo skierowane do NASK-PIB.

Źródła

[1] Federalne Ministerstwo Spraw Wewnętrznych Niemiec (BMI). Mobile Device Vulnerability Management Concept - German National EUDI Wallet: Architecture Documentation. OpenCode. (zapis z maja 2026 r.) https://web.archive.org/web/20260513155630/https://bmi.usercontent.opencode.de/eudi-wallet/wallet-development-documentation-public/latest/Guidelines/appAttestation/#android

[2] Hacker News. German implementation of eIDAS will require an Apple/Google account to function (dyskusja). https://news.ycombinator.com/item?id=47644406

[3] Komisja Europejska. Architecture and Reference Framework - EUDI Wallet. https://eudi.dev/latest/architecture-and-reference-framework-main/

[4] Wyrok Trybunału (wielka izba) z dnia 6 października 2015 r. w sprawie Maximillian Schrems przeciwko Data Protection Commissioner przy udziale Digital Rights Ireland Ltd (C-362/14)

[5] Wyrok Trybunału Sprawiedliwości Unii Europejskiej z dnia 16 lipca 2020 r. w sprawie Facebook Ireland i Maximillian Schrems (C-311/18)

[6] Ministerstwo Cyfryzacji RP. mObywatel - aplikacja. https://www.gov.pl/web/mobywatel

[7] Repozytorium projektu EUDI Wallet (BMI). Issue #2: Support for alternative Android systems. OpenCode. https://gitlab.opencode.de/bmi/eudi-wallet/wallet-development-documentation-public/-/issues/2