Android IKEv2: certyfikat użytkownika i CA robią różne rzeczy
Jedno pole dowodzi, kim jest telefon, drugie decyduje, której bramie zaufać. Profil IKEv2 w Androidzie trzyma je osobno.
Ekran IKEv2 w Androidzie, który prosi jednocześnie o certyfikat użytkownika i certyfikat CA, wygląda, jakby chciał tego samego dwa razy. Tak nie jest. IKEv2 uwierzytelnia obie strony w obu kierunkach w jednej wymianie, a telefon w każdym kierunku ma inną rolę: musi dowieść, kim jest, i zdecydować, której bramie wierzy. Certyfikat użytkownika odpowiada na pierwsze pytanie, zaufany CA na drugie, i żaden nie zastępuje drugiego.
Dwa kierunki uwierzytelniania w jednej wymianie
IKEv2 buduje kanał sterujący w dwóch fazach. Pierwsza negocjuje algorytmy i klucze; druga, IKE_AUTH, niesie po jednym ładunku AUTH z każdej strony wraz z jej tożsamością. Ładunek to podpis lub MAC nad wymianą, weryfikowany wobec czegoś, czemu odbiorca już ufa.
Brama dowodzi siebie własnym certyfikatem, a telefon weryfikuje łańcuch do korzenia, który akceptuje, i sprawdza, czy tożsamość w certyfikacie odpowiada bramie, do której chciał dotrzeć; telefon dowodzi siebie swoimi danymi, a brama weryfikuje je wobec CA, która wydała certyfikat klienta.
To cały mechanizm za oboma polami. Certyfikat użytkownika to oświadczenie telefonu o sobie; pole CA to oświadczenie o tym, komu będzie wierzył. Profil z jednym bez drugiego nie ukończy uwierzytelnienia wzajemnego, a ponawianie tego nie zmieni. Same błędy wyglądają różnie: bez klucza użytkownika telefon nie podpisze, a bez kotwicy zaufania nie przyjmie certyfikatu bramy.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Czego wymaga kreator profilu w Androidzie
Kreator profilu IKEv2 w Androidzie udostępnia każdą metodę uwierzytelniania osobno, nie jako jeden tryb certyfikatu. Metoda podpisu cyfrowego bierze certyfikat użytkownika, klucz prywatny i główny CA serwera; pozostałe biorą nazwę użytkownika i hasło albo klucz współdzielony z góry.
Przeczytaj ten podpis uważnie, bo opisuje powyższy mechanizm. W metodzie z nazwą i hasłem nie ma pola na klucz prywatny, a w PSK nie ma pola na kotwicę zaufania bramy, bo te metody dowodzą różnych rzeczy. Hasło wklejone w pole certyfikatu daje profil, który zawodzi na IKE_AUTH z komunikatem, który nie nazywa żadnego z nich.
Udokumentowanym typem klucza prywatnego dla podpisu cyfrowego jest RSA. Menu oznaczone IPsec lub certyfikat nie oznacza obsługi ECDSA, a profil zbudowany na tym założeniu zawodzi w API platformy, zanim pojawi się sieć.
Dlaczego publiczny certyfikat nie wystarcza
Ładunek AUTH to podpis nad wymianą wykonany kluczem prywatnym klienta. Publiczny certyfikat pozwala bramie sprawdzić podpis, ale nic nie daje telefonowi, który potrzebuje klucza, by go wytworzyć. Importowanie tylko .crt i zostawienie klucza z tyłu to najczęstsza postać tego błędu.
Infrastruktura kluczy Androida to odzwierciedla: wybór tożsamości klienta idzie przez KeyChain, który wymaga dostępu do odpowiedniego klucza prywatnego, nie tylko wpisu certyfikatu. Pakiet rejestracyjny lub przepływ zarządzania urządzeniem, który instaluje parę razem, to normalna droga do użytecznej tożsamości; ręczne kopiowanie pliku zwykle nie.
Zatem dwa elementy profilu to nie pakiet certyfikatów i jego kopia. Jeden to para kluczy, którą platforma musi móc podpisywać, drugi to kotwica zaufania, z którą porównuje. Sprawdzaj je jako dwa osobne fakty: czy ten profil potrafi podpisywać i czy wie, komu zaufać?
Kotwice zaufania należą do aplikacji, nie do telefonu
Korzeń zainstalowany w magazynie użytkownika nie sprawia, że każda aplikacja mu ufa: od Androida 7 aplikacja musi wybrać to w swojej konfiguracji bezpieczeństwa sieci, a przed tą wersją CA instalowane przez użytkownika były akceptowane znacznie szerzej. Konfiguracja zaufania może się różnić, a klient VPN zarządzający własnym materiałem zaufania może nigdy nie zajrzeć do magazynu. Dlatego ten sam plik CA może działać w jednym kliencie i wyglądać na ignorowany w innym.
Wynikają z tego dwa modele własności. Profil zarządzany przez system używa instalacji certyfikatów urządzenia lub rejestracji administratora, a potem wskazuje zamierzony CA. VPN zarządzany przez aplikację trzyma własny materiał zaufania i własny udokumentowany import, który może być całkiem osobny od ekranu ustawień Androida. Tam też naprawia się zerwany łańcuch.
Zdecyduj, w którym modelu jesteś, zanim coś zaimportujesz, a potem potwierdź wybór zaufania aktywnego profilu. Jeśli instrukcje operatora i menu klienta się różnią, dla tej instalacji wygrywa udokumentowane zachowanie klienta, ale CA nadal musi pochodzić od operatora kanałem, który możesz zweryfikować. Nazwa pliku nie jest dowodem, kto go wydał.
Najpierw tryb, potem pliki
Tryb certyfikatu wymaga pary kluczy klienta, CA wydającej po stronie bramy, kotwicy zaufania dla certyfikatu bramy i oczekiwania, jaką tożsamość ma nieść ten certyfikat. Nazwa i hasło zastępują parę kluczy danymi, ale zachowują wymóg zaufania do bramy. PSK zastępuje oba wspólnym sekretem i zmienia model zaufania, zamiast go upraszczać.
Cokolwiek wybierzesz, zostaw normalną walidację włączoną. Opcja bez weryfikacji usuwa kontrolę, dla której istnieje pole CA; nie naprawia brakującej kotwicy zaufania. To samo dotyczy akceptowania dowolnego certyfikatu serwera dlatego, że połączenie działa bez niego.
Potem sprawdź w odpowiednim miejscu: zaimportuj materiał, połącz się raz i w szczegółach połączenia potwierdź, że tożsamość bramy jest oczekiwana, a profil zgłasza zamierzoną metodę. Udane połączenie z niewłaściwą metodą to konfiguracja, której jeszcze nie rozumiesz, i zawiedzie, gdy operator zaostrzy politykę.