Android IKEv2: uživatelský certifikát a CA dělají různé věci
Jedno pole dokazuje, kdo je telefon, druhé rozhoduje, které bráně věřit. Profil IKEv2 v Androidu je drží oddělené, protože tak funguje handshake.
Obrazovka IKEv2 v Androidu, která chce současně uživatelský certifikát i certifikát CA, vypadá, jako by chtěla totéž dvakrát. Není to tak. IKEv2 ověřuje obě strany v obou směrech v rámci jedné výměny a telefon má v každém směru jinou roli: musí dokázat, kdo je, a rozhodnout, které bráně věří. Uživatelský certifikát odpovídá na první otázku, důvěryhodná CA na druhou a ani jedno nenahradí druhé.
Dva směry ověřování v jedné výměně
IKEv2 buduje řídicí kanál ve dvou fázích. První vyjednává algoritmy a klíče; druhá, IKE_AUTH, nese jeden AUTH payload od každé strany spolu s její identitou. Payload je podpis nebo MAC nad výměnou a ověřuje se proti něčemu, čemu příjemce už věří.
Brána dokazuje svou identitu vlastním certifikátem; telefon ověří řetěz až ke kořeni, kterému věří, a zkontroluje, že identita v certifikátu odpovídá bráně, které se chtěl připojit. Telefon dokazuje svou identitu svým údajem a brána jej ověří proti CA, která vydala klientský certifikát.
To je celý mechanismus za oběma poli. Uživatelský certifikát je tvrzení telefonu o sobě; pole CA je tvrzení o tom, komu bude telefon věřit. Profil s jedním bez druhého nedokončí vzájemné ověření a opakování to nezmění. I selhání vypadají různě: bez uživatelského klíče telefon vůbec nepodepíše, bez ukotvení důvěry nepřijme certifikát brány.
| 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 |
Co vyžaduje tvůrce profilu v Androidu
Tvůrce profilu IKEv2 v Androidu nabízí každou metodu ověření zvlášť, ne jako jeden režim certifikátu. Metoda digitálního podpisu bere uživatelský certifikát, soukromý klíč a kořenovou CA serveru; ostatní berou jméno a heslo, nebo předem sdílený klíč.
Čtěte to rozhraní pozorně, protože popisuje mechanismus výše. V metodě jméno a heslo není pole pro soukromý klíč a v PSK není pole pro ukotvení důvěry brány, protože tyto metody dokazují různé věci. Heslo vložené do pole certifikátu dá profil, který selže na IKE_AUTH se zprávou, jež nejmenuje ani jedno.
Dokumentovaný typ soukromého klíče pro digitální podpis je RSA. Nabídka označená IPsec nebo certifikát neznamená podporu ECDSA a profil postavený na tomto předpokladu selže v API platformy dřív, než se síť vůbec zapojí.
Proč nestačí jen veřejný uživatelský certifikát
Payload AUTH je podpis nad výměnou vytvořený soukromým klíčem klienta. Veřejný certifikát umožní bráně podpis zkontrolovat, ale telefonu nepomůže, protože ten potřebuje klíč, aby podpis vytvořil. Importovat jen .crt a nechat klíč doma je nejčastější podoba tohoto selhání.
Klíčová infrastruktura Androidu to odráží. Volba klientské identity jde přes KeyChain, který vyžaduje přístup k odpovídajícímu soukromému klíči, ne jen záznam certifikátu. Registrační balíček nebo správa zařízení, která nainstaluje pár společně, je obvyklý způsob, jak získat použitelnou identitu; ruční kopírování souboru obvykle ne.
Dvě položky v profilu tedy nejsou balík certifikátů a jeho kopie. Jedna je pár klíčů, kterým platforma musí umět podepsat, druhá je ukotvení důvěry, proti kterému porovnává. Kontrolujte je jako dvě oddělená fakta: umí tento profil podepsat a ví, komu věřit?
Ukotvení důvěry patří aplikaci, ne telefonu
Kořen nainstalovaný v úložišti uživatele neznamená, že mu každá aplikace Androidu věří: od Android 7 se k tomu aplikace musí přihlásit svou konfigurací síťového zabezpečení a před tím vydáním byly uživatelské CA přijímány mnohem šířeji. Konfigurace důvěry se může lišit a klient VPN, který si spravuje vlastní materiál důvěry, se do úložiště uživatele nemusí vůbec podívat. Proto stejný soubor CA může v jednom klientu fungovat a v jiném vypadat ignorovaný.
Z toho plynou dva modely vlastnictví. Profil spravovaný systémem používá instalaci certifikátů zařízení nebo registraci správcem a pak odkazuje na zamýšlenou CA. VPN spravovaná aplikací si drží vlastní materiál důvěry a vlastní dokumentovaný import, který může být zcela oddělen od obrazovky nastavení Androidu. Tam se také opravuje přerušený řetěz.
Rozhodněte, ve kterém modelu jste, než cokoli importujete, a potom potvrďte volbu důvěry aktivního profilu. Když se pokyny operátora a nabídka klienta rozcházejí, pro danou instalaci vyhrává dokumentované chování klienta, ale CA musí stále přijít od operátora kanálem, který umíte ověřit. Název souboru není důkaz o tom, kdo jej vydal.
Nejdřív režim, potom soubory
Režim certifikátu potřebuje pár klíčů klienta, vydávající CA na straně brány, ukotvení důvěry pro certifikát brány a očekávání, jakou identitu má tento certifikát nést. Jméno a heslo nahradí pár klíčů údaji, ale požadavek důvěry v bránu zůstává. PSK nahradí obojí sdíleným tajemstvím a mění model důvěry, místo aby jej zjednodušil.
Ať zvolíte cokoli, nechte běžné ověřování zapnuté. Volba neověřovat odstraňuje kontrolu, kvůli které pole CA existuje; chybějící ukotvení důvěry neopraví. Totéž platí pro přijetí libovolného certifikátu serveru proto, že spojení funguje i bez něj.
Pak ověřte na správném místě: importujte materiál, připojte se jednou a v podrobnostech spojení potvrďte, že identita brány je ta očekávaná a že profil hlásí metodu, kterou jste zamýšleli. Úspěšné spojení s nesprávnou metodou je konfigurace, které ještě nerozumíte, a selže, až operátor zpřísní pravidla.