Android IKEv2: korisnički sertifikat i CA obavljaju različite poslove
Jedno polje dokazuje ko je telefon, drugo odlučuje kojem šluzu vjerovati. IKEv2 profil na Androidu drži ih odvojeno.
IKEv2 ekran na Androidu koji traži i korisnički sertifikat i CA sertifikat izgleda kao da isto traži dvaput. Nije tako. IKEv2 provjerava obje strane u oba smjera unutar iste razmjene, a telefon u svakom smjeru ima drugu ulogu: mora dokazati ko je i odlučiti kojem šluzu vjeruje. Korisnički sertifikat odgovara na prvo pitanje, pouzdani CA na drugo, i nijedno ne zamjenjuje ono drugo.
Dva smjera provjere u jednoj razmjeni
IKEv2 gradi kontrolni kanal u dvije faze. Prva pregovara algoritme i ključeve; druga, IKE_AUTH, nosi po jedan AUTH teret sa svake strane zajedno s identitetom te strane. Teret je potpis ili MAC nad razmjenom i provjerava se prema nečemu u što primalac već vjeruje.
Šluz dokazuje sebe vlastitim sertifikatom; telefon provjerava lanac do korijena kojem vjeruje i da se identitet u sertifikatu poklapa sa šluzom kojem je namjeravao pristupiti. Telefon dokazuje sebe svojim vjerodajnicama, a šluz ih provjerava prema CA koji je izdao klijentski sertifikat.
To je cijeli mehanizam iza dva polja. Korisnički sertifikat je izjava telefona o sebi; polje CA je izjava o tome kome će telefon vjerovati. Profil s jednim ali bez drugog ne može dovršiti uzajamnu provjeru i ponovni pokušaji to ne mijenjaju. Čak i otkazi izgledaju različito: bez korisničkog ključa telefon uopće ne može potpisati, bez uporišta povjerenja ne može prihvatiti šluzov sertifikat.
| 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 |
Šta traži graditelj profila na Androidu
Graditelj IKEv2 profila na Androidu nudi svaki način provjere zasebno, a ne kao jedan sertifikatni način. Način s digitalnim potpisom uzima korisnički sertifikat, privatni ključ i korijenski CA servera; ostali uzimaju korisničko ime i lozinku ili unaprijed dijeljeni ključ.
Pročitajte taj potpis pažljivo, jer on opisuje gornji mehanizam. U načinu s korisničkim imenom i lozinkom nema polja za privatni ključ, a u PSK načinu nema polja za uporište povjerenja šluza, jer ti načini dokazuju različite stvari. Lozinka zalijepljena u polje sertifikata daje profil koji pada na IKE_AUTH s porukom koja ne imenuje nijedno od toga.
Dokumentovani tip privatnog ključa za način s digitalnim potpisom je RSA. Meni s oznakom IPsec ili sertifikat ne znači podršku za ECDSA, a profil sastavljen na toj pretpostavci pada na API platforme prije nego što mreža uopće stupi na scenu.
Zašto samo javni korisnički sertifikat nije dovoljan
AUTH teret je potpis nad razmjenom napravljen klijentovim privatnim ključem. Javni sertifikat omogućava šluzu da provjeri potpis, ali telefonu ne pomaže, jer telefon treba ključ da bi ga proizveo. Uvoz samo .crt i ostavljanje ključa za sobom najčešći je oblik ovog otkaza.
Ključna infrastruktura Androida to odražava. Odabir klijentskog identiteta ide kroz KeyChain, koji zahtijeva pristup odgovarajućem privatnom ključu, a ne samo unos sertifikata. Paket za upis ili tok upravljanja uređajem koji instalira par zajedno normalan je način da se dobije upotrebljiv identitet; ručno kopiranje datoteke obično nije.
Dakle, dva elementa u profilu nisu paket sertifikata i njegova kopija. Jedan je par ključeva kojim platforma mora moći potpisivati, drugi je uporište povjerenja s kojim se poredi. Provjeravajte ih kao dvije odvojene činjenice: može li ovaj profil potpisivati i zna li kome vjerovati?
Uporišta povjerenja pripadaju aplikaciji, ne telefonu
Korijen instaliran u korisničko spremište ne čini ga pouzdanim za svaku Android aplikaciju: od Android 7 aplikacija to mora izabrati kroz svoju mrežnu sigurnosnu konfiguraciju, a prije tog izdanja korisnički instalirani CA prihvatali su se mnogo šire. Konfiguracija povjerenja može se razlikovati, a VPN klijent koji sam upravlja svojim materijalom povjerenja možda nikad ne pogleda korisničko spremište. Zato isti CA fajl može raditi u jednom klijentu i izgledati zanemaren u drugom.
Slijede dva modela vlasništva. Profilom koji upravlja sistem koristi instalaciju sertifikata uređaja ili upis administratora, a profil zatim upućuje na namjeravani CA. VPN kojim upravlja aplikacija drži vlastiti materijal povjerenja i vlastiti dokumentovani uvoz, koji može biti potpuno odvojen od ekrana postavki Androida. Tu se popravlja i prekinut lanac.
Odredite u kojem ste modelu prije nego bilo šta uvezete, a zatim potvrdite izbor povjerenja aktivnog profila. Ako se uputstvo operatera i meni klijenta ne slažu, za tu instalaciju pobjeđuje dokumentovano ponašanje klijenta, ali CA ipak mora doći od operatera kanalom koji možete provjeriti. Ime datoteke nije dokaz ko ju je izdao.
Prvo način, pa datoteke
Sertifikatni način traži par ključeva klijenta, CA izdavaoca na strani šluza, uporište povjerenja za šluzov sertifikat i očekivanje koji identitet taj sertifikat mora nositi. Korisničko ime i lozinka zamjenjuju par ključeva vjerodajnicama ali zadržavaju zahtjev povjerenja u šluz. PSK zamjenjuje oboje zajedničkom tajnom i mijenja model povjerenja umjesto da ga pojednostavljuje.
Šta god odabrali, ostavite normalnu provjeru uključenom. Opcija bez provjere uklanja provjeru zbog koje polje CA i postoji; ne popravlja uporište povjerenja koje nedostaje. Isto vrijedi za prihvatanje bilo kojeg serverskog sertifikata zato što veza radi i bez njega.
Zatim provjerite na pravom mjestu: uvezite materijal, povežite se jednom i u detaljima veze potvrdite da je identitet šluza onaj koji ste očekivali i da profil izvještava način koji ste namjeravali. Uspješna veza s pogrešnim načinom je konfiguracija koju još ne razumijete i pasti će kad operater pooštri pravilo.