Android IKEv2: lietotāja sertifikāts un CA veic dažādus darbus
Viens lauks pierāda, kas ir tālrunis, otrs izlemj, kurai vārtejai uzticēties. Android IKEv2 profils tos tur atsevišķi.
Android IKEv2 ekrāns, kas vienlaikus prasa lietotāja sertifikātu un CA sertifikātu, izskatās tā, it kā tas prasītu vienu un to pašu divreiz. Tā nav. IKEv2 autentificē abas puses abos virzienos vienā apmaiņā, un tālrunim katrā virzienā ir cita loma: tam jāpierāda, kas tas ir, un jāizlemj, kurai vārtejai tas tic. Lietotāja sertifikāts atbild uz pirmo jautājumu, uzticamā CA uz otro, un neviens neaizstāj otru.
Divi autentifikācijas virzieni vienā apmaiņā
IKEv2 veido vadības kanālu divos posmos. Pirmais vienojas par algoritmiem un atslēgām; otrais, IKE_AUTH, pārsūta vienu AUTH kravu no katras puses kopā ar tās identitāti. Krava ir paraksts vai MAC pār apmaiņu, un to pārbauda pret kaut ko, kam saņēmējs jau uzticas.
Vārteja pierāda sevi ar savu sertifikātu, un tālrunis pārbauda ķēdi līdz saknei, kuru tas pieņem, un to, vai sertifikātā esošā identitāte atbilst vārtejai, kuru tas gribēja sasniegt; tālrunis pierāda sevi ar saviem datiem, un vārteja tos pārbauda pret CA, kas izdeva klienta sertifikātu.
Tas ir viss mehānisms aiz diviem laukiem. Lietotāja sertifikāts ir tālruņa paziņojums par sevi; CA lauks ir paziņojums par to, kam tas ticēs. Profils ar vienu bez otra nevar pabeigt savstarpēju autentifikāciju, un atkārtošana to nemaina. Pat kļūmes izskatās citādi: bez lietotāja atslēgas tālrunis vispār nevar parakstīt, bez uzticības enkura tas nevar pieņemt vārtejas sertifikātu.
| 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 |
Ko prasa Android profila veidotājs
Android IKEv2 profila veidotājs piedāvā katru autentifikācijas metodi atsevišķi, nevis kā vienu sertifikāta režīmu. Digitālā paraksta metode ņem lietotāja sertifikātu, privāto atslēgu un servera saknes CA; pārējās ņem lietotājvārdu un paroli vai iepriekš koplietotu atslēgu.
Lasiet šo parakstu uzmanīgi, jo tas apraksta iepriekš minēto mehānismu. Lietotājvārda un paroles metodē nav privātās atslēgas lauka, un PSK metodē nav vārtejas uzticības enkura lauka, jo šīs metodes pierāda dažādas lietas. Sertifikāta laukā ielīmēta parole dod profilu, kas neizdodas pie IKE_AUTH ar ziņojumu, kurā nav nosaukts neviens no abiem.
Dokumentētais privātās atslēgas tips digitālā paraksta metodei ir RSA. Izvēlne ar apzīmējumu IPsec vai sertifikāts nenozīmē ECDSA atbalstu, un uz šo pieņēmumu balstīts profils neizdodas platformas API vēl pirms tīkla iesaistīšanās.
Kāpēc ar publisku sertifikātu vien nepietiek
AUTH krava ir paraksts pār apmaiņu, kas veidots ar klienta privāto atslēgu. Publiskais sertifikāts ļauj vārtejai pārbaudīt parakstu, bet tālrunim neko nedod, jo tam paraksta izveidei vajag atslēgu. Importēt tikai .crt un atstāt atslēgu aiz muguras ir visbiežākā šīs kļūdas forma.
Android atslēgu infrastruktūra to atspoguļo: klienta identitātes izvēle iet caur KeyChain, kam vajadzīga piekļuve attiecīgajai privātajai atslēgai, nevis tikai sertifikāta ieraksts. Reģistrācijas pakotne vai ierīces pārvaldības plūsma, kas instalē pāri kopā, ir parastais ceļš uz lietojamu identitāti; faila kopēšana ar roku parasti nav.
Tātad abi profila elementi nav sertifikātu saišķis un tā kopija. Viens ir atslēgu pāris, ar kuru platformai jāprot parakstīt, otrs ir uzticības enkurs, ar ko tā salīdzina. Pārbaudiet tos kā divus atsevišķus faktus: vai šis profils var parakstīt un vai tas zina, kam uzticēties?
Uzticības enkuri pieder lietotnei, ne tālrunim
Lietotāja krātuvē instalēta sakne nepadara to uzticamu katrai Android lietotnei: kopš Android 7 lietotnei tā jāizvēlas ar savu tīkla drošības konfigurāciju, un pirms šī izlaiduma lietotāja instalētie CA tika pieņemti daudz plašāk. Uzticības konfigurācija var atšķirties, un VPN klients, kas pats pārvalda savu uzticības materiālu, var vispār neielūkoties lietotāja krātuvē. Tāpēc viens un tas pats CA fails var darboties vienā klientā un šķist ignorēts citā.
No tā izriet divi īpašumtiesību modeļi. Sistēmas pārvaldīts profils izmanto ierīces sertifikātu instalāciju vai administratora reģistrāciju un pēc tam atsaucas uz paredzēto CA. Lietotnes pārvaldīts VPN patur savu uzticības materiālu un savu dokumentēto importu, kas var būt pilnīgi atsevišķi no Android iestatījumu ekrāna. Tur arī labo pārtrauktu ķēdi.
Izlemiet, kurā modelī esat, pirms kaut ko importējat, un pēc tam apstipriniet aktīvā profila uzticības izvēli. Ja operatora norādes un klienta izvēlne nesakrīt, šai instalācijai uzvar klienta dokumentētā uzvedība, bet CA tomēr jānāk no operatora pa kanālu, kuru varat pārbaudīt. Faila nosaukums nav pierādījums par to, kas to izdevis.
Vispirms režīms, tad faili
Sertifikāta režīmam vajag klienta atslēgu pāri, izdevējCA vārtejas pusē, uzticības enkuru vārtejas sertifikātam un gaidu par to, kāda identitāte tajā jābūt. Lietotājvārds un parole aizstāj atslēgu pāri ar datiem, bet saglabā prasību uzticēties vārtejai. PSK aizstāj abus ar koplietotu noslēpumu un maina uzticības modeli, nevis vienkāršo to.
Ko vien izvēlaties, atstājiet parasto pārbaudi ieslēgtu. Opcija bez pārbaudes noņem to kontroli, kurai CA lauks ir domāts; tā nelabo trūkstošu uzticības enkuru. Tas pats attiecas uz jebkura servera sertifikāta pieņemšanu tāpēc, ka savienojums strādā arī bez tā.
Pēc tam pārbaudiet pareizajā vietā: importējiet materiālu, pievienojieties vienreiz un savienojuma detaļās apstipriniet, ka vārtejas identitāte ir gaidītā un ka profils norāda paredzēto metodi. Veiksmīgs savienojums ar nepareizu metodi ir konfigurācija, kuru vēl nesaprotat, un tas neizdosies, kad operators pastiprinās politiku.