Android IKEv2: korisnički certifikat i CA rade različite poslove
Jedno polje dokazuje ko je telefon, drugo odlučuje kojem se prolazu vjeruje. IKEv2 profil na Androidu drži ih odvojeno.
IKEv2 ekran na Androidu koji traži i korisnički certifikat i CA certifikat 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 prolazu vjeruje. Korisnički certifikat odgovara na prvo pitanje, pouzdani CA na drugo, i nijedno ne zamjenjuje ono drugo.
Dva smjera provjere u jednoj razmjeni
IKEv2 gradi upravljački kanal u dvije faze. Prva dogovara 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 primatelj već vjeruje.
Prolaz dokazuje sebe vlastitim certifikatom, a telefon provjerava lanac do korijena kojem vjeruje i to da se identitet u certifikatu podudara s prolazom kojem se namjeravao javiti; telefon dokazuje sebe svojim vjerodajnicama, a prolaz ih provjerava prema CA koja je izdala klijentski certifikat.
To je cijeli mehanizam iza dvaju polja. Korisnički certifikat izjava je telefona o sebi; polje CA izjava je o tome kome će telefon vjerovati. Profil s jednim ali bez drugoga 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, a bez uporišta povjerenja ne može prihvatiti certifikat prolaza.
| 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 |
Što traži graditelj profila na Androidu
Graditelj IKEv2 profila na Androidu nudi svaki način provjere zasebno, a ne kao jedan certifikatni način. Način s digitalnim potpisom uzima korisnički certifikat, privatni ključ i korijensku CA poslužitelja; ostali uzimaju korisničko ime i lozinku ili unaprijed dijeljeni ključ.
Pročitajte taj potpis pažljivo jer 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 prolaza, jer ti načini dokazuju različite stvari. Lozinka zalijepljena u polje certifikata daje profil koji pada na IKE_AUTH s porukom koja ne imenuje nijedno od toga.
Dokumentirani tip privatnog ključa za način s digitalnim potpisom je RSA. Izbornik s oznakom IPsec ili certifikat ne znači podršku za ECDSA, a profil sastavljen na toj pretpostavci pada na API platforme prije nego što mreža uopće dođe na red.
Zašto javni korisnički certifikat nije dovoljan
AUTH teret je potpis nad razmjenom napravljen klijentovim privatnim ključem. Javni certifikat omogućuje prolazu provjeru potpisa, 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 certifikata. Paket za upis ili tijek upravljanja uređajem koji par instalira zajedno uobičajen je način da se dobije upotrebljiv identitet; ručno kopiranje datoteke obično nije.
Dakle dva elementa u profilu nisu snop certifikata i njegova kopija. Jedan je par ključeva kojim platforma mora moći potpisivati, drugi je uporište povjerenja s kojim se uspoređuje. 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 odabrati kroz svoju mrežnu sigurnosnu konfiguraciju, a prije tog izdanja korisnički instalirane CA prihvaćale 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 sustav koristi instalaciju certifikata uređaja ili upis administratora, a profil zatim upućuje na namjeravanu CA. VPN kojim upravlja aplikacija drži vlastiti materijal povjerenja i vlastiti dokumentirani uvoz, koji može biti posve odvojen od zaslona postavki Androida. Tu se popravlja i prekinuti lanac.
Odredite u kojem ste modelu prije nego bilo što uvezete, a zatim potvrdite izbor povjerenja aktivnog profila. Ako se uputa operatera i izbornik klijenta ne slažu, za tu instalaciju pobjeđuje dokumentirano ponašanje klijenta, ali CA ipak mora doći od operatera kanalom koji možete provjeriti. Ime datoteke nije dokaz o tome ko ju je izdao.
Prvo način, pa datoteke
Certifikatni način traži par ključeva klijenta, CA izdavatelja na strani prolaza, uporište povjerenja za certifikat prolaza i očekivanje koji identitet taj certifikat mora nositi. Korisničko ime i lozinka zamjenjuju par ključeva vjerodajnicama ali zadržavaju zahtjev povjerenja u prolaz. PSK zamjenjuje oboje zajedničkom tajnom i mijenja model povjerenja umjesto da ga pojednostavljuje.
Što 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 prihvaćanje bilo kojeg poslužiteljskog certifikata zato što veza radi i bez njega.
Zatim provjerite na pravom mjestu: uvezite materijal, povežite se jednom i u pojedinostima veze potvrdite da je identitet prolaza onaj koji ste očekivali i da profil izvješćuje način koji ste namjeravali. Uspješna veza s pogrešnim načinom konfiguracija je koju još ne razumijete i pasti će kad operater pooštri pravilo.