Weryfikacja wieku w UE może uderzyć w Linuksa i custom romy. Wymagany będzie specjalny sprzęt

Projekt Unii Europejskiej mający ułatwić potwierdzanie wieku użytkowników internetu wywołał nową falę pytań o przyszłość otwartego oprogramowania. Powód jest konkretny: jeden z opiekunów projektu potwierdził, że sprzętowe poświadczenie to nie opcjonalny dodatek, lecz element wymagany przez architekturę rozwiązania.

Dla zwykłego użytkownika może to brzmieć jak techniczny szczegół. Dla osób korzystających z Linuksa, alternatywnych wersji Androida czy samodzielnie kompilowanych aplikacji sprawa wygląda znacznie poważniej. System może mieć otwarty kod źródłowy, a mimo to jego działanie zależeć od zabezpieczeń wbudowanych w konkretne urządzenia oraz od usług kontrolowanych przez określonych dostawców.

Projekt ma rozwiązać jeden z najbardziej kłopotliwych problemów współczesnego internetu: jak potwierdzić, że użytkownik jest pełnoletni, bez zmuszania go do przekazywania serwisowi pełnego dokumentu tożsamości. Technologia ma pozwolić udowodnić spełnienie wymogu wiekowego bez ujawniania imienia, nazwiska, dokładnej daty urodzenia czy całego dokumentu.

Brzmi rozsądnie. Problem pojawia się wtedy, gdy użytkownik chce korzystać z własnego systemu, niestandardowego oprogramowania albo urządzenia, które nie znajduje się na liście wspieranych konfiguracji.

„ Atestacja sprzętowa jest wymogiem tego projektu, a nie szczegółem implementacji, który możemy po prostu pominąć ” – odpowiedział opiekun projektu

Jedno zdanie rozpaliło dyskusję

Kontrowersja wybuchła w repozytorium GitHub aplikacji projektu przeznaczonej dla Androida. Jeden z uczestników dyskusji zwrócił uwagę, że powiązanie mechanizmu poświadczeń z konkretnym środowiskiem sprzętowym może utrudnić korzystanie z rozwiązania przez osoby używające otwartych i zmodyfikowanych systemów.

Odpowiedź opiekuna projektu była jednoznaczna. Atestacja sprzętowa została określona jako wymóg architektoniczny, a nie detal implementacyjny, który można po prostu usunąć.

To właśnie ten fragment uruchomił dyskusję o tym, jak daleko sięgać będzie kontrola nad środowiskiem, z którego korzysta użytkownik. Samo udostępnienie kodu na GitHubie nie gwarantuje bowiem pełnej swobody korzystania z systemu.

Twórcy projektu zapowiedzieli jednocześnie przygotowanie osobnego przeglądu bezpieczeństwa oraz modelu zagrożeń. Społeczność może również przedstawiać alternatywne propozycje architektury.

Na odpowiedzi trzeba więc jeszcze poczekać. Już teraz wiadomo jednak, że kwestia sprzętowego zaufania nie jest przypadkowym dodatkiem do projektu.

Weryfikacja wieku bez wysyłania dowodu osobistego

Idea stojąca za systemem jest stosunkowo prosta. Użytkownik ma otrzymać cyfrowe poświadczenie potwierdzające określony warunek wiekowy. Serwis internetowy może sprawdzić, czy warunek został spełniony, bez poznawania wszystkich danych osobowych użytkownika.

Taki mechanizm ma ograniczyć sytuacje, w których osoba chcąca wejść na stronę dla dorosłych albo skorzystać z określonej usługi musi przesłać skan dowodu osobistego lub inne szczegółowe dane.

Techniczna ochrona przed kopiowaniem poświadczeń jest jednak znacznie trudniejsza. Gdyby można było po prostu skopiować odpowiedni klucz lub plik na inne urządzenie, system łatwo byłoby oszukać.

Dlatego projekt wykorzystuje zabezpieczenia sprzętowe. Klucze mogą być przechowywane w chronionych elementach urządzenia, takich jak Android TEE, StrongBox czy Apple Secure Enclave.

W praktyce oznacza to przeniesienie części zaufania z samego programu na sprzęt, na którym ten program działa.

Tutaj zaczyna się problem dla Linuksa

W świecie Androida i iPhone'ów takie rozwiązania są stosunkowo łatwe do wdrożenia. Producenci urządzeń dostarczają określone mechanizmy bezpieczeństwa, a system operacyjny może komunikować się z nimi według ustalonych zasad.

Linux desktopowy działa jednak według zupełnie innego modelu. Użytkownik może samodzielnie wybrać dystrybucję, zmienić środowisko graficzne, skompilować program ze źródeł albo wymienić komponenty systemu. Taka elastyczność jest jedną z największych zalet otwartego oprogramowania, ale jednocześnie utrudnia stworzenie jednolitego mechanizmu sprzętowego zaufania.

Co istotne, projekt nie wprowadza prostego zakazu korzystania z Linuksa. Użytkownik komputera z tym systemem może wejść na stronę internetową i wykorzystać kod QR, aby przeprowadzić proces za pomocą obsługiwanego portfela mobilnego.

Brakuje jednak natywnego portfela przeznaczonego dla desktopowego Linuksa. Jeszcze większe pytania dotyczą alternatywnych systemów mobilnych, które nie mają dostępu do dokładnie tych samych mechanizmów sprzętowych i usług zaufania.

Otwarty kod nie daje pełnej niezależności

Właśnie tutaj pojawia się najbardziej paradoksalny element całej historii. Projekt jest rozwijany jako oprogramowanie open source. Każdy może więc zajrzeć do kodu i analizować sposób działania aplikacji. Teoretycznie społeczność może również przygotować własną wersję programu.

Problem w tym, że niezależna kompilacja aplikacji nie musi wystarczyć do uzyskania prawdziwego poświadczenia. Dostawcy usługi Proof of Age mają wydawać dane uwierzytelniające tylko aplikacjom znajdującym się na liście zgodnych programów prowadzonej przez Komisję Europejską. W efekcie ktoś może stworzyć własną, zmodyfikowaną wersję aplikacji i opublikować ją w internecie, lecz sama dostępność kodu nie zagwarantuje jej dostępu do całej infrastruktury.

To ważna różnica między otwartym kodem a otwartym systemem. Pierwszy element może być dostępny dla wszystkich, podczas gdy drugi nadal może wymagać certyfikowanego sprzętu, zatwierdzonego oprogramowania oraz dostępu do określonych usług.

Nie każda kontrola musi być sprzętowa

W dokumentacji technicznej pojawia się jednak istotne rozróżnienie. Projekt zakłada korzystanie z natywnego sprzętu kryptograficznego, gdy taki mechanizm jest dostępny. Nie wszystkie dodatkowe zabezpieczenia muszą być natomiast obowiązkowe na poziomie implementacji referencyjnej.

Dotyczy to między innymi kontroli uprawnień roota, integralności Google Play czy mechanizmu Apple App Attest. Daje to pewne pole do interpretacji, szczególnie w przypadku urządzeń korzystających z niestandardowych konfiguracji. Nie rozwiązuje jednak głównego problemu: kluczowym elementem architektury pozostaje sprzętowe poświadczenie.

Dopiero zapowiadany model zagrożeń powinien dokładniej wyjaśnić, przed jakimi atakami projekt chce się zabezpieczyć i dlaczego uznano, że rozwiązanie sprzętowe jest konieczne.

Linux nie jest jedynym znakiem zapytania

Debata szybko wyszła poza pytanie o jeden system operacyjny. Znacznie więcej kontrowersji może wywołać kwestia alternatywnych ROM-ów Androida. Społeczność takich systemów często rezygnuje z części zamkniętych usług Google, zmienia komponenty systemu albo korzysta z własnych mechanizmów bezpieczeństwa.

Jeśli cyfrowe poświadczenie wieku ma być związane z określonym środowiskiem sprzętowym i aplikacją znajdującą się na zatwierdzonej liście, użytkownik może stracić część swobody, którą daje mu instalacja alternatywnego systemu.

To samo dotyczy osób, które wolą samodzielnie kompilować aplikacje. Kod może być dostępny publicznie, ale droga od pobrania źródeł do uzyskania działającego poświadczenia może wymagać przejścia przez dodatkowe mechanizmy autoryzacji.