Android IKEv2: naudotojo sertifikatas ir CA atlieka skirtingus darbus
Vienas laukas įrodo, kas yra telefonas, kitas nusprendžia, kuriuo šliuzu pasitikėti. „Android“ IKEv2 profilis juos laiko atskirai.
„Android“ IKEv2 ekranas, kuris vienu metu prašo naudotojo sertifikato ir CA sertifikato, atrodo tarsi prašytų to paties du kartus. Taip nėra. IKEv2 autentifikuoja abi puses abiem kryptimis viename apsikeitime, o telefonas kiekviena kryptimi atlieka skirtingą vaidmenį: turi įrodyti, kas jis, ir nuspręsti, kuriuo šliuzu tiki. Naudotojo sertifikatas atsako į pirmą klausimą, patikima CA į antrą, ir nė vienas nepakeičia kito.
Dvi autentifikavimo kryptys viename apsikeitime
IKEv2 sukuria valdymo kanalą dviem etapais. Pirmas derasi dėl algoritmų ir raktų; antras, IKE_AUTH, perduoda po vieną AUTH naudingąją apkrovą iš kiekvienos pusės kartu su jos tapatybe. Apkrova yra apsikeitimo atžvilgiu sukurta parašas arba MAC, ir ji tikrinama pagal tai, kuo gavėjas jau pasitiki.
Šliuzas įrodo save savo sertifikatu, o telefonas tikrina grandinę iki šaknies, kurią priima, ir tai, ar sertifikate esanti tapatybė atitinka šliuzą, į kurį ketino patekti; telefonas įrodo save savo duomenimis, o šliuzas juos tikrina pagal CA, išdavusią kliento sertifikatą.
Tai visas mechanizmas, slypintis už dviejų laukų. Naudotojo sertifikatas yra telefono pareiškimas apie save; CA laukas yra pareiškimas apie tai, kuo jis tikės. Profilis, turintis vieną be kito, negali užbaigti abipusio autentifikavimo, ir kartojimas to nekeičia. Net gedimai atrodo skirtingai: be naudotojo rakto telefonas negali pasirašyti, be pasitikėjimo inkaro negali priimti šliuzo sertifikato.
| 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 reikalauja „Android“ profilio kūrėjas
„Android“ IKEv2 profilio kūrėjas pateikia kiekvieną autentifikavimo būdą atskirai, o ne kaip vieną sertifikato režimą. Skaitmeninio parašo būdas ima naudotojo sertifikatą, privatų raktą ir serverio šakninę CA; kiti ima naudotojo vardą ir slaptažodį arba iš anksto bendrinamą raktą.
Skaitykite tą parašą atidžiai, nes jis aprašo aukščiau pateiktą mechanizmą. Naudotojo vardo ir slaptažodžio būde nėra privataus rakto lauko, o PSK būde nėra šliuzo pasitikėjimo inkaro lauko, nes šie būdai įrodo skirtingus dalykus. Į sertifikato lauką įklijuotas slaptažodis duoda profilį, kuris nepavyksta ties IKE_AUTH, o pranešimas neįvardija nė vieno.
Dokumentuotas privataus rakto tipas skaitmeninio parašo būdui yra RSA. Meniu su žyma IPsec arba sertifikatas nereiškia ECDSA palaikymo, o šia prielaida pagrįstas profilis nepavyksta platformos API dar prieš atsirandant tinklui.
Kodėl vien viešo sertifikato nepakanka
AUTH apkrova yra apsikeitimo atžvilgiu kliento privačiu raktu sukurtas parašas. Viešas sertifikatas leidžia šliuzui patikrinti parašą, bet telefonui nieko neduoda, nes tam, kad sukurtų parašą, jam reikia rakto. Importuoti tik .crt ir palikti raktą už nugaros yra dažniausia šios klaidos forma.
„Android“ raktų infrastruktūra tai atspindi: kliento tapatybės pasirinkimas eina per KeyChain, kuris reikalauja prieigos prie atitinkamo privataus rakto, o ne vien sertifikato įrašo. Registracijos paketas arba įrenginio valdymo procesas, įdiegiantis porą kartu, yra įprastas kelias gauti tinkamą tapatybę; rankinis failo kopijavimas paprastai ne.
Taigi du profilio elementai nėra sertifikatų rinkinys ir jo kopija. Vienas yra raktų pora, kuria platforma turi galėti pasirašyti, kitas yra pasitikėjimo inkaras, su kuriuo ji lygina. Tikrinkite juos kaip du atskirus faktus: ar šis profilis gali pasirašyti ir ar žino, kuo pasitikėti?
Pasitikėjimo inkarai priklauso programai, ne telefonui
Naudotojo saugykloje įdiegta šaknis nepriverčia kiekvienos „Android“ programos ja pasitikėti: nuo Android 7 programa turi tai pasirinkti per savo tinklo saugos konfigūraciją, o prieš tą versiją naudotojo įdiegtos CA buvo priimamos daug plačiau. Pasitikėjimo konfigūracija gali skirtis, o VPN klientas, kuris pats tvarko savo pasitikėjimo medžiagą, gali net nepažvelgti į saugyklą. Todėl tas pats CA failas gali veikti viename kliente ir atrodyti ignoruojamas kitame.
Iš to kyla du nuosavybės modeliai. Sistemos valdomas profilis naudoja įrenginio sertifikatų diegimą arba administratoriaus registraciją ir tada nurodo numatytą CA. Programos valdomas VPN laiko savo pasitikėjimo medžiagą ir savo dokumentuotą importą, kuris gali būti visiškai atskiras nuo „Android“ nustatymų ekrano. Ten pat taisoma nutrūkusi grandinė.
Nuspręskite, kuriame modelyje esate, prieš ką nors importuodami, o paskui patvirtinkite aktyvaus profilio pasitikėjimo pasirinkimą. Jei operatoriaus nurodymai ir kliento meniu nesutampa, tai įdiegčiai laimi dokumentuotas kliento elgesys, bet CA vis tiek turi ateiti iš operatoriaus kanalu, kurį galite patikrinti. Failo pavadinimas nėra įrodymas, kas jį išdavė.
Pirmiausia režimas, paskui failai
Sertifikato režimui reikia kliento raktų poros, išduodančios CA šliuzo pusėje, pasitikėjimo inkaro šliuzo sertifikatui ir lūkesčio, kokią tapatybę tas sertifikatas turi turėti. Naudotojo vardas ir slaptažodis pakeičia raktų porą duomenimis, bet išlaiko reikalavimą pasitikėti šliuzu. PSK pakeičia abu bendra paslaptimi ir keičia pasitikėjimo modelį, o ne supaprastina jį.
Ką bebepasirinktumėte, palikite įprastą tikrinimą įjungtą. Parinktis be tikrinimo pašalina tą patikrą, kuriai egzistuoja CA laukas; ji nepataiso trūkstamo pasitikėjimo inkaro. Tas pats galioja priimant bet kurį serverio sertifikatą dėl to, kad ryšys veikia ir be jo.
Tada tikrinkite tinkamoje vietoje: importuokite medžiagą, prisijunkite kartą ir ryšio informacijoje patvirtinkite, kad šliuzo tapatybė yra laukiamoji ir kad profilis nurodo numatytą metodą. Sėkmingas ryšys su netinkamu metodu yra konfigūracija, kurios dar nesuprantate, ir ji nepavyks, kai operatorius sugriežtins taisykles.