Android IKEv2: uporabniško potrdilo in potrdilo CA opravljata različni nalogi
Eno polje dokazuje, kdo je telefon, drugo odloča, kateremu prehodu zaupati. Androidov profil IKEv2 ju ločuje, ker ju ločuje tudi rokovanje.
Zaslon Android IKEv2, ki zahteva uporabniško potrdilo in potrdilo CA, je videti, kot da isto stvar zahteva dvakrat. Ni tako. IKEv2 preverja identiteto obeh strani, v obeh smereh, znotraj iste izmenjave, telefon pa ima v vsaki smeri različno vlogo: dokazati mora, kdo je, in se odločiti, kateremu prehodu verjame. Uporabniško potrdilo odgovori na prvo vprašanje, zaupanja vredno potrdilo CA na drugo, in nobeno ne more nadomestiti drugega.
Dve smeri preverjanja identitete v eni izmenjavi
IKEv2 vzpostavi krmilni kanal v dveh fazah. Prva izmenjava se pogaja o algoritmih in ključih; druga, IKE_AUTH, prinese po en podatek AUTH z vsake strani skupaj z identiteto vsake strani. Podatek je podpis ali MAC, izračunan čez izmenjavo, in se preveri glede na nekaj, kar prejemnik že zaupa.
Prehod dokaže svojo identiteto z lastnim potrdilom, telefon pa preveri verigo tega potrdila do korena, ki mu je pripravljen zaupati, nato preveri, ali se identiteta v potrdilu ujema s prehodom, ki ga je nameraval doseči. Telefon dokaže svojo identiteto z lastno poverilnico, prehod pa jo preveri glede na CA, ki je izdal potrdilo odjemalca.
To je celoten mehanizem za obema poljema. Uporabniško potrdilo je izjava, ki jo telefon poda o sebi; polje CA je izjava o tem, komu bo telefon verjel. Profil, ki ima eno brez drugega, ne more dokončati vzajemnega preverjanja identitete in nobeno ponavljanje tega ne spremeni. Tudi obe napaki sta videti različni: manjkajoči uporabniški ključ telefonu onemogoči, da bi sploh ustvaril podpis, manjkajoča sidrna točka zaupanja pa mu onemogoči, da bi sprejel potrdilo prehoda.
| 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 |
Kaj zahteva graditelj profilov v Androidu
Googlov graditelj profilov IKEv2 vsak način preverjanja identitete izpostavi ločeno, ne kot en način »potrdilo«. Način digitalnega podpisa sprejme uporabniško potrdilo, zasebni ključ in korenski CA strežnika. Drugi načini sprejmejo uporabniško ime in geslo ali vnaprej dogovorjeni ključ.
Ta podpis preberite pozorno, ker kodira zgornji mehanizem. V načinu z uporabniškim imenom in geslom ni polja za zasebni ključ uporabnika, v načinu PSK pa ni polja za sidrno točko zaupanja prehoda, iz preprostega razloga, ker ti načini dokazujejo različne stvari. Če jih zmešate tako, da geslo prilepite v polje za potrdilo, dobite profil, ki odpove pri IKE_AUTH s sporočilom, ki ne imenuje niti enega od njiju.
Dokumentirani tip zasebnega ključa za način digitalnega podpisa je RSA. Meni z oznako IPsec ali potrdilo ne pomeni podpore za ECDSA, profil, sestavljen ob predpostavki, da jo podpira, pa bo odpovedal že v vmesniku API platforme, preden je vključeno sploh omrežje.
Zakaj samo javno uporabniško potrdilo ni dovolj
Podatek AUTH je podpis čez izmenjavo, narejen z zasebnim ključem odjemalca. Če imate javno potrdilo, lahko prehod preveri podpis; telefonu to ne pomaga, saj potrebuje ključ, da podpis ustvari. Če uvozite samo datoteko .crt in ključ pustite zadaj, je to najpogostejša različica te napake.
Infrastruktura ključev v Androidu to odraža. Izbira identitete odjemalca poteka prek KeyChain, ki zahteva dostop do ustreznega zasebnega ključa, ne le do vnosa potrdila. Paket za vpis ali potek upravljanja naprav, ki par namesti skupaj, je običajen način za uporabno identiteto; ročno kopiranje datoteke s potrdilom običajno ni.
Dva elementa v profilu torej nista sveženj potrdil in njegova kopija. Eden je par ključev, s katerim mora platforma znati podpisovati, drugi pa sidrna točka zaupanja, s katero platforma primerja. Preverite ju kot dve ločeni dejstvi: ali ta profil lahko podpiše in ali ve, komu zaupati?
Sidrne točke zaupanja pripadajo aplikaciji, ne telefonu
Namestitev korenskega potrdila v shrambo uporabnika ne pomeni, da mu bo zaupala vsaka aplikacija Android: od različice Android 7 se mora aplikacija zanj odločiti v svoji konfiguraciji omrežne varnosti, pred to izdajo pa so bila uporabniško nameščena potrdila CA sprejeta veliko širše. Konfiguracija zaupanja se med aplikacijami lahko razlikuje in odjemalec VPN, ki upravlja svoje gradivo zaupanja, v shrambo uporabnika morda sploh ne pogleda. Zato ista datoteka CA lahko deluje v enem odjemalcu, v drugem pa je videti prezrta.
Sledita dva modela lastništva. Sistemsko upravljan profil VPN uporablja namestitev potrdil v napravi ali potek vpisa skrbnika, profil pa se nato sklicuje na predvideni CA. Aplikacijsko upravljan VPN ohrani svoje gradivo zaupanja in uporabi svoj dokumentirani uvoz, ki je lahko popolnoma ločen od zaslona nastavitev Androida. Tam tudi popravite prekinjeno verigo: v shrambi CA in izbiri profila pri sistemsko upravljanem primeru, na lastnem zaslonu za uvoz odjemalca pri aplikacijsko upravljanem.
Preden kar koli uvozite, se odločite, v katerem modelu ste, nato potrdite izbiro zaupanja v dejavnem profilu. Če se navodila operaterja in meni odjemalca ne ujemajo, za to namestitev velja dokumentirano vedenje odjemalca, a CA mora še vedno priti od operaterja po poti, ki jo lahko preverite. Ime datoteke ni dokaz o tem, kdo jo je izdal.
Najprej izberite način, nato datoteke
Način s potrdilom potrebuje par ključev odjemalca, CA, ki izda potrdilo, na strani prehoda, sidrno točko zaupanja za potrdilo prehoda in pričakovanje, katero identiteto mora nositi to potrdilo. Način z uporabniškim imenom in geslom zamenja par ključev odjemalca s poverilnicami, a zahtevo po zaupanju v prehod ohrani. Način PSK oba nadomesti s skupno skrivnostjo in spremeni model zaupanja, namesto da bi ga poenostavil.
Ne glede na izbiro pustite običajno preverjanje omogočeno. Možnost brez preverjanja, kjer jo odjemalec ponuja, odstrani prav tisto preverjanje, zaradi katerega polje CA obstaja; manjkajoče sidrne točke zaupanja ne odpravi. Enako velja za sprejemanje katerega koli potrdila strežnika zato, ker povezava deluje brez njega.
Nato preverite na pravem mestu: uvozite gradivo, se enkrat povežite in v podrobnostih povezave odjemalca potrdite, da je identiteta prehoda tista, ki ste jo pričakovali, in da profil poroča o načinu preverjanja identitete, ki ste ga nameravali uporabiti. Uspešna povezava z napačno izbranim načinom je konfiguracija, ki je še ne razumete, in odpovedala bo, ko bo operater naslednjič zaostril pravilo.