Android IKEv2: notandaskilríkið og CA gegna ólíkum hlutverkum

IKEv2-skjár í Android sem biður um bæði notandaskilríki og CA-skilríki í einu virðist biðja um sama hlutinn tvisvar. Svo er ekki. IKEv2 sannar báða aðila í báðar áttir innan einnar skiptingar, og síminn gegnir ólíku hlutverki í hvora átt: hann verður að sanna hver hann er og ákveða hvaða gátt hann trúir. Notandaskilríkið svarar fyrri spurningunni, traust CA þeirri seinni, og hvort tveggja kemur ekki í stað hins.

Tvær áttir sannprófunar í einni skiptingu

IKEv2 byggir stjórnrás í tveimur þrepum. Fyrra þrepið semur um reiknirit og lykla; annað, IKE_AUTH, ber eitt AUTH-farm frá hvorri hlið ásamt auðkenni hennar. Farmurinn er undirskrift eða MAC yfir skiptinguna og er staðfestur gegn einhverju sem viðtakandinn treystir þegar.

Gáttin sannar sig með eigin skilríki, og síminn staðfestir keðjuna upp að rót sem hann samþykkir og athugar að auðkennið í skilríkinu passi við gáttina sem hann ætlaði að ná; síminn sannar sig með sínum skírteinum, og gáttin staðfestir þau gegn CA sem gaf út skilríki biðlarans.

Þetta er öll vélbúnaðurinn á bak við reitina tvo. Notandaskilríkið er yfirlýsing símans um sjálfan sig; CA-reiturinn er yfirlýsing um hvern hann muni trúa. Snið með öðru en ekki hinu getur ekki lokið gagnkvæmri sannprófun, og endurtekin tilraun breytir því ekki. Jafnvel mistökin líta ólíkt út: án notendalykils getur síminn alls ekki skrifað undir, án traustsankers getur hann ekki samþykkt skilríki gáttarinnar.

Hvað byggir Android-sniðsins krefst

Byggir IKEv2-sniðsins í Android býður hverja sannprófunaraðferð fyrir sig, ekki sem eitt skilríkjamó. Aðferðin með stafrænni undirskrift tekur notandaskilríki, einkalykil og rótar-CA þjónsins; hinar taka notandanafn og lykilorð, eða lykil sem deilt var fyrirfram.

Lestu þá undirskrift vel, því hún lýsir vélbúnaðnum hér að ofan. Ekkert svæði er fyrir einkalykil í aðferðinni með notandanafni og lykilorði, og ekkert svæði fyrir traustsanker gáttarinnar í PSK, því þessar aðferðir sanna ólíka hluti. Lykilorð sem sett er í skilríkjasvæði gefur snið sem mistekst við IKE_AUTH með skilaboðum sem nefna hvorki né.

Skráð tegund einkalykils fyrir aðferðina með stafrænni undirskrift er RSA. Valmynd merkt IPsec eða skilríki þýðir ekki stuðning við ECDSA, og snið byggt á þeirri forsendu mistekst í API vettvangsins áður en netið kemur við sögu.

Hvers vegna opinbert notandaskilríki eitt og sér nægir ekki

AUTH-farmurinn er undirskrift yfir skiptinguna gerð með einkalykli biðlarans. Opinbera skilríkið leyfir gáttinni að athuga undirskrift, en gerir ekkert fyrir símann, sem þarf lykilinn til að búa hana til. Að flytja inn aðeins .crt og skilja lykilinn eftir er algengasta mynd þessa mistaks.

Lykla-innviðir Android endurspegla það: val á auðkenni biðlara fer í gegnum KeyChain, sem krefst aðgangs að samsvarandi einkalykli, ekki bara skráningar skilríkis. Skráningarpakki eða stjórnun tækja sem setur parið upp saman er venjulega leiðin að nothæfu auðkenni; handafritun skráar er það sjaldan.

Svo þau tvö atriði í sniðinu eru ekki skilríkjabúnt og eintak af því. Annað er lyklapar sem vettvangurinn verður að geta skrifað undir með, hitt er traustsanker sem hann ber saman við. Athugaðu þau sem tvær aðskildar staðreyndir: getur þetta snið skrifað undir, og veit það hverjum á að treysta?

Traustsanker tilheyra forriti, ekki símanum

Rót sem sett er í geymslu notandans lætur ekki hvert Android-forrit treysta henni: frá Android 7 verður forrit að velja það í gegnum netöryggisstillingar sínar, og fyrir þá útgáfu voru CA sem notandinn setti upp samþykkt mun víðar. Traustsstillingin getur verið mismunandi og VPN-biðlari sem stýrir eigin traustsefni kann að líta aldrei í geymslu notandans. Þess vegna getur sama CA-skráin virkað í einum biðlara og virst hunsuð í öðrum.

Af því leiða tvö eignarlíkön. Snið sem stýrt er af kerfinu notar uppsetningu skilríkja tækisins eða skráningu stjórnanda og vísar þá á fyrirhugaða CA. VPN sem forritið stýrir heldur eigin traustsefni og eigin skráðri innflutningi, sem getur verið algjörlega aðskilinn frá stillingaskjá Android. Þar er líka rakin keðja gerð við.

Ákveddu í hvaða líkani þú ert áður en þú flytur inn eitthvað, og staðfestu síðan traustsval virka sniðsins. Ef leiðbeiningar rekstraraðila og valmynd biðlarans stangast á gildir skráð hegðun biðlarans fyrir þá uppsetningu, en CA verður samt að koma frá rekstraraðilanum um rás sem þú getur staðfest. Skráarnafn er ekki sönnun um hver gaf hana út.

Veldu ham, síðan skrárnar

Skilríkjahamurinn krefst lyklapars biðlarans, útgáfu-CA á gáttarhlið, traustsankers fyrir skilríki gáttarinnar og væntinga um hvaða auðkenni skilríkið á að bera. Notandanafn og lykilorð koma í stað lyklaparsins með skírteinum en halda kröfunni um traust á gáttina. PSK kemur í stað beggja með sameiginlegu leyndarmáli og breytir traustslíkaninu í stað þess að einfalda það.

Hvað sem þú velur, hafðu venjulega staðfestingu virka. Valkostur án staðfestingar fjarlægir þá athugun sem CA-reiturinn er til fyrir; hann lagar ekki traustsanker sem vantar. Sama gildir um að samþykkja hvaða þjónskilríki sem er af því að tengingin virkar án þess.

Staðfestu síðan á réttum stað: flyttu efnið inn, tengdu einu sinni og staðfestu í upplýsingum tengingarinnar að auðkenni gáttarinnar sé það sem þú bjóst við og að sniðið tilkynni þá aðferð sem þú ætlaðir. Árangursrík tenging með rangri aðferð er stilling sem þú skilur ekki enn, og hún mistekst þegar rekstraraðilinn herðir stefnu.