Android IKEv2: kasutajasertifikaat ja CA teevad erinevat tööd
Üks väli tõestab, kes telefon on, teine otsustab, millist lüüsi usaldada. Androidi IKEv2 profiil hoiab neid lahus, sest käepigistus seda nõuab.
Androidi IKEv2 ekraan, mis küsib korraga nii kasutajasertifikaati kui ka CA sertifikaati, näib küsivat sama asja kaks korda. Nii see ei ole. IKEv2 autendib mõlemad pooled mõlemas suunas ühe vahetuse jooksul ja telefonil on kummaski suunas eri roll: tõestada, kes ta on, ja otsustada, millist lüüsi usaldada. Kasutajasertifikaat vastab esimesele küsimusele, usaldusväärne CA teisele, ja kumbki ei asenda teist.
Kaks autentimissuunda ühes vahetuses
IKEv2 ehitab juhtkanali kahes faasis. Esimene lepib kokku algoritmid ja võtmed; teine, IKE_AUTH, kannab kummalt poolelt ühe AUTH koorma koos selle poole identiteediga. Koorem on vahetuse kohal arvutatud allkiri või MAC ja seda kontrollitakse millegi vastu, mida vastuvõtja juba usaldab.
Lüüs tõestab end oma sertifikaadiga; telefon kontrollib ahela kuni juureni, mida ta usaldab, ja seda, et sertifikaadi identiteet vastab lüüsile, kuhu ta jõuda tahtis. elefon tõestab end oma volitustega ja lüüs kontrollib neid CA vastu, kes kliendi sertifikaadi väljastas.
See on kogu mehhanism kahe välja taga. Kasutajasertifikaat on telefoni väide enda kohta; CA väli on väide selle kohta, keda telefon usub. Ühega ilma teiseta profiil ei lõpeta vastastikust autentimist ja kordamine ei muuda seda. Isegi tõrked näevad erinevad välja: ilma kasutaja võtmeta ei saa telefon üldse allkirjastada, ilma usaldusankruta ei saa ta lüüsi sertifikaati vastu võtta.
| 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 |
Mida Androidi profiiliehitaja nõuab
Androidi IKEv2 profiiliehitaja pakub iga autentimismeetodit eraldi, mitte ühe sertifikaadirežiimina. Digitaalallkirja meetod võtab kasutajasertifikaadi, privaatvõtme ja serveri juur-CA; teised võtavad kasutajanime ja parooli või eelnevalt jagatud võtme.
Lugege seda allkirja hoolikalt, sest see kirjeldab ülaltoodud mehhanismi. Kasutajanime ja parooli meetodis ei ole privaatvõtme välja ja PSK meetodis ei ole lüüsi usaldusankru välja, sest need meetodid tõestavad erinevaid asju. Sertifikaadivälja kleebitud parool annab profiili, mis ebaõnnestub IKE_AUTH juures teatega, mis ei nimeta kumbagi.
Digitaalallkirja meetodi dokumenteeritud privaatvõtme tüüp on RSA. IPsec või sertifikaat märgistusega menüü ei tähenda ECDSA tuge ja sellele eeldusele ehitatud profiil ebaõnnestub platvormi API juures juba enne, kui võrk mängu tuleb.
Miks üks avalik kasutajasertifikaat ei piisa
AUTH koorem on kliendi privaatvõtmega vahetuse kohal tehtud allkiri. Avalik sertifikaat lubab lüüsil allkirja kontrollida, kuid ei tee telefoni jaoks midagi, sest allkirja loomiseks on tal võtit vaja. Ainult .crt importimine ja võtme maha jätmine on selle tõrke kõige tavalisem kuju.
Androidi võtmeinfrastruktuur peegeldab seda. Kliendi identiteedi valimine käib läbi KeyChaini, mis nõuab juurdepääsu vastavale privaatvõtmele, mitte ainult sertifikaadikirjet. Registreerimispakett või seadmehalduse voog, mis paari koos paigaldab, on tavaline tee kasutatava identiteedini; faili käsitsi kopeerimine tavaliselt ei ole.
Nii et profiili kaks elementi ei ole sertifikaatide kimp ja selle koopia. Üks on võtmepaar, millega platvorm peab suutma allkirjastada, teine on usaldusankur, millega ta võrdleb. Kontrollige neid kahe eraldi faktina: kas see profiil suudab allkirjastada ja kas ta teab, keda usaldada?
Usaldusankrud kuuluvad rakendusele, mitte telefonile
Kasutajapoodi paigaldatud juur ei pane iga Androidi rakendust seda usaldama: alates Android 7 peab rakendus selle valima oma võrgu turbe konfiguratsiooni kaudu ja enne seda versiooni võeti kasutaja paigaldatud CA-sid palju laiemalt vastu. Usalduse konfiguratsioon võib rakenduseti erineda ja VPN klient, kes haldab ise oma usaldusmaterjali, ei pruugi kunagi kasutajapoodi vaadata. Seetõttu võib sama CA fail ühes kliendis töötada ja teises eiratud näida.
Sellest tuleneb kaks omandimudelit. Süsteemi hallatav profiil kasutab seadme sertifikaatide paigaldust või administraatori registreerimist ja viitab seejärel kavandatud CA-le. Rakenduse hallatav VPN hoiab oma usaldusmaterjali ja oma dokumenteeritud impordi, mis võib olla Androidi seadete ekraanist täiesti eraldi. Seal parandatakse ka katkenud ahel.
Otsustage, millises mudelis olete, enne kui midagi impordite, ja kinnitage seejärel aktiivse profiili usaldusvalik. Kui operaatori juhised ja kliendi menüü lahknevad, võidab selle paigalduse jaoks kliendi dokumenteeritud käitumine, kuid CA peab ikkagi tulema operaatorilt kanali kaudu, mida saate kontrollida. Faili nimi ei ole tõend selle kohta, kes selle väljastas.
Kõigepealt režiim, siis failid
Sertifikaadirežiim vajab kliendi võtmepaari, lüüsi poolel väljastavat CA-d, lüüsi sertifikaadi jaoks usaldusankrut ja ootust, millist identiteeti see sertifikaat peab kandma. Kasutajanimi ja parool asendavad võtmepaari volitustega, kuid säilitavad nõude lüüsi usaldada. PSK asendab mõlemad ühise saladusega ja muudab usaldusmudelit, mitte ei lihtsusta seda.
Mida iganes valite, jätke tavaline valideerimine sisse. Kontrollimata jätmise valik eemaldab kontrolli, mille jaoks CA väli olemas on; puuduvat usaldusankrut see ei paranda. Sama kehtib iga serveri sertifikaadi vastuvõtmise kohta, sest ühendus töötab ka ilma selleta.
Seejärel kontrollige õiges kohas: importige materjal, ühenduge korra ja kinnitage ühenduse üksikasjades, et lüüsi identiteet on oodatud ja et profiil teatab meetodi, mida kavatsesite. Edukas ühendus vale meetodiga on konfiguratsioon, mida te veel ei mõista, ja see ebaõnnestub, kui operaator poliitikat karmistab.