Android IKEv2: používateľský certifikát a CA robia rôzne veci
Jedno pole dokazuje, kto je telefón, druhé rozhoduje, ktorej bráne dôverovať. Profil IKEv2 v Androide ich drží oddelene.
Obrazovka IKEv2 v Androide, ktorá žiada súčasne používateľský certifikát aj certifikát CA, vyzerá, akoby chcela to isté dvakrát. Nie je to tak. IKEv2 overuje obe strany v oboch smeroch v rámci jednej výmeny a telefón má v každom smere inú úlohu: musí dokázať, kto je, a rozhodnúť, ktorej bráne verí. Používateľský certifikát odpovedá na prvú otázku, dôveryhodná CA na druhú, a ani jedno nenahrádza druhé.
Dva smery overovania v jednej výmene
IKEv2 buduje riadiaci kanál v dvoch fázach. Prvá dohaduje algoritmy a kľúče; druhá, IKE_AUTH, nesie jednu AUTH záťaž z každej strany spolu s jej identitou. Záťaž je podpis alebo MAC nad výmenou a overuje sa voči niečomu, čomu príjemca už dôveruje.
Brána sa dokazuje vlastným certifikátom a telefón overuje reťaz až po koreň, ktorý akceptuje, a či identita v certifikáte zodpovedá bráne, ku ktorej sa chcel dostať; telefón sa dokazuje svojimi prihlasovacími údajmi a brána ich overuje voči CA, ktorá vydala klientsky certifikát.
To je celý mechanizmus za oboma poľami. Používateľský certifikát je vyhlásenie telefónu o sebe; pole CA je vyhlásenie o tom, komu bude veriť. Profil s jedným bez druhého nedokončí vzájomné overenie a opakovanie to nezmení. Dokonca aj zlyhania vyzerajú inak: bez používateľského kľúča telefón vôbec nepodpíše, bez ukotvenia dôvery neprijme 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 |
Čo vyžaduje tvorca profilov v Androide
Tvorca profilov IKEv2 v Androide ponúka každú metódu overenia zvlášť, nie ako jeden certifikátový režim. Metóda digitálneho podpisu berie používateľský certifikát, súkromný kľúč a koreňovú CA servera; ostatné berú meno a heslo alebo vopred zdieľaný kľúč.
Prečítajte si ten podpis pozorne, pretože opisuje mechanizmus vyššie. V metóde s menom a heslom nie je pole pre súkromný kľúč a v PSK nie je pole pre ukotvenie dôvery brány, pretože tieto metódy dokazujú rozdielne veci. Heslo vložené do poľa certifikátu vytvorí profil, ktorý zlyhá pri IKE_AUTH so správou, ktorá nepomenuje ani jedno.
Dokumentovaný typ súkromného kľúča pre digitálny podpis je RSA. Menu s označením IPsec alebo certifikát neznamená podporu ECDSA a profil postavený na tomto predpoklade zlyhá v API platformy skôr, než sa objaví sieť.
Prečo nestačí verejný certifikát
AUTH záťaž je podpis nad výmenou vytvorený súkromným kľúčom klienta. Verejný certifikát umožní bráne skontrolovať podpis, ale telefónu nepomôže, pretože ten potrebuje kľúč na jeho vytvorenie. Importovať iba .crt a nechať kľúč za sebou je najčastejšia podoba tejto chyby.
Kľúčová infraštruktúra Androida to odráža: výber klientskej identity ide cez KeyChain, ktorý vyžaduje prístup k príslušnému súkromnému kľúču, nielen záznam certifikátu. Registračný balík alebo správa zariadení, ktorá nainštaluje pár spolu, je bežná cesta k použiteľnej identite; ručné kopírovanie súboru zvyčajne nie.
Dve položky v profile teda nie sú balík certifikátov a jeho kópia. Jedna je pár kľúčov, ktorým platforma musí vedieť podpísať, druhá je ukotvenie dôvery, s ktorým porovnáva. Kontrolujte ich ako dva oddelené fakty: dokáže tento profil podpísať a vie, komu dôverovať?
Ukotvenia dôvery patria aplikácii, nie telefónu
Koreň nainštalovaný v používateľskom úložisku neprinúti každú aplikáciu Androidu, aby mu dôverovala: od Androidu 7 si to aplikácia musí zvoliť cez konfiguráciu sieťovej bezpečnosti a pred týmto vydaním boli používateľské CA akceptované oveľa širšie. Konfigurácia dôvery sa môže líšiť a klient VPN, ktorý si spravuje vlastný materiál dôvery, sa do úložiska nemusí vôbec pozrieť. Preto ten istý súbor CA môže v jednom klientovi fungovať a v druhom vyzerať ignorovaný.
Z toho plynú dva modely vlastníctva. Profil spravovaný systémom používa inštaláciu certifikátov zariadenia alebo registráciu správcom a potom odkazuje na zamýšľanú CA. VPN spravovaná aplikáciou si drží vlastný materiál dôvery a vlastný dokumentovaný import, ktorý môže byť úplne oddelený od obrazovky nastavení Androidu. Tam sa tiež opravuje prerušená reťaz.
Rozhodnite sa, v ktorom modeli ste, skôr než niečo importujete, a potom potvrďte voľbu dôvery aktívneho profilu. Ak sa pokyny operátora a ponuka klienta rozchádzajú, pre danú inštaláciu vyhráva dokumentované správanie klienta, ale CA musí stále prísť od operátora kanálom, ktorý viete overiť. Názov súboru nie je dôkazom o tom, kto ho vydal.
Najprv režim, potom súbory
Certifikátový režim potrebuje pár kľúčov klienta, vydávajúcu CA na strane brány, ukotvenie dôvery pre certifikát brány a očakávanie, akú identitu má certifikát niesť. Meno a heslo nahrádzajú pár kľúčov prihlasovacími údajmi, ale zachovávajú požiadavku dôvery voči bráne. PSK nahrádza oboje spoločným tajomstvom a mení model dôvery namiesto toho, aby ho zjednodušil.
Čokoľvek si vyberiete, nechajte bežné overovanie zapnuté. Voľba bez overovania odstraňuje kontrolu, pre ktorú pole CA existuje; chýbajúce ukotvenie dôvery neopraví. To isté platí pre prijatie akéhokoľvek serverového certifikátu preto, že spojenie funguje aj bez neho.
Potom overte na správnom mieste: importujte materiál, pripojte sa raz a v podrobnostiach spojenia potvrďte, že identita brány je tá očakávaná a že profil hlási zamýšľanú metódu. Úspešné spojenie s nesprávnou metódou je konfigurácia, ktorej ešte nerozumiete, a zlyhá, keď operátor sprísni pravidlo.