Android IKEv2: cheti cha mtumiaji na CA vina majukumu tofauti

Skrini ya Android IKEv2 inayoomba cheti cha mtumiaji na cheti cha CA inaonekana kama inataka kitu kimoja mara mbili. Haifanyi hivyo. IKEv2 huthibitisha pande zote mbili, katika mielekeo yote miwili, ndani ya mazungumzo yale yale, na simu ina jukumu tofauti katika kila mwelekeo: inapaswa kuthibitisha yenyewe ni nani, na inapaswa kuamua gateway ipi inayoiamini. Cheti cha mtumiaji hujibu swali la kwanza, CA inayoaminika hujibu la pili, na hakuna kimoja kinachoweza kuchukua nafasi ya kingine.

Mielekeo miwili ya uthibitishaji katika mazungumzo moja

IKEv2 huanzisha kituo cha udhibiti katika awamu mbili. Mazungumzo ya kwanza hujadili algoriti na funguo; ya pili, IKE_AUTH, hubeba payload moja ya AUTH kutoka kila upande pamoja na utambulisho wa kila upande. Payload ni sahihi au MAC iliyohesabiwa juu ya mazungumzo, na huthibitishwa dhidi ya kitu ambacho mpokeaji tayari anaamini.

Gateway huthibitisha utambulisho wake kwa cheti chake mwenyewe, na simu huthibitisha mnyororo wa cheti hicho hadi mzizi ambao iko tayari kuuamini, kisha hukagua kwamba utambulisho katika cheti unalingana na gateway iliyokusudiwa kufikiwa. Simu huthibitisha utambulisho wake kwa kitambulisho chake mwenyewe, na gateway hukithibitisha dhidi ya CA iliyotoa cheti cha mteja.

Huo ndio utaratibu mzima nyuma ya sehemu hizo mbili. Cheti cha mtumiaji ni tamko ambalo simu hutoa kuhusu yenyewe; sehemu ya CA ni tamko kuhusu nani simu itamwamini. Profaili iliyo na kimoja bila kingine haiwezi kukamilisha uthibitishaji wa pande zote, na kurudia hakuwezi kubadilisha hilo. Makosa hayo mawili hata yanaonekana tofauti: ufunguo wa mtumiaji usiokuwepo huzuia simu kutoa sahihi kabisa, wakati nanga ya uaminifu isiyokuwepo huzuia kukubali cheti cha gateway.

Kile kijenzi cha profaili cha Android hukiomba

Kijenzi cha profaili ya IKEv2 cha Google hufichua kila njia ya uthibitishaji kivyake badala ya hali moja ya cheti. Njia ya sahihi ya kidijitali huchukua cheti cha mtumiaji, ufunguo wa faragha na CA mzizi ya seva. Njia nyingine huchukua jina la mtumiaji na nenosiri, au ufunguo ulioshirikiwa mapema.

Soma sahihi hiyo kwa makini, kwa sababu inasimba utaratibu ulio juu. Hakuna sehemu ya ufunguo wa faragha wa mtumiaji katika njia ya jina la mtumiaji na nenosiri, na hakuna sehemu ya nanga ya uaminifu ya gateway katika njia ya PSK, kwa sababu rahisi kwamba njia hizo huthibitisha mambo tofauti. Kuchanganya kwa kubandika nenosiri kwenye sehemu ya cheti hutoa profaili inayoshindikana kwenye IKE_AUTH na ujumbe usiotaja hata moja.

Aina ya ufunguo wa faragha iliyoandikwa kwa njia ya sahihi ya kidijitali ni RSA. Menyu iliyoandikwa IPsec au cheti haimaanishi msaada wa ECDSA, na profaili iliyoundwa kwa dhana kwamba ina msaada huo itashindikana kwenye API ya jukwaa kabla mtandao haujahusishwa kabisa.

Kwa nini cheti cha mtumiaji cha umma pekee hakitoshi

Payload ya AUTH ni sahihi juu ya mazungumzo, iliyotengenezwa kwa ufunguo wa faragha wa mteja. Kuwa na cheti cha umma humruhusu gateway kukagua sahihi; kwa simu hakusaidii kitu, kwa kuwa inahitaji ufunguo ili kuunda moja. Kuagiza .crt pekee na kuacha ufunguo nyuma ndio toleo la kawaida zaidi la hitilafu hii.

Miundombinu ya funguo ya Android inaonyesha hilo. Kuchagua utambulisho wa mteja hupitia KeyChain, ambayo inahitaji ufikiaji wa ufunguo wa faragha unaolingana, sio tu kiingilio cha cheti. Kifurushi cha uandikishaji au mtiririko wa usimamizi wa kifaa unaoweka jozi pamoja ndio njia ya kawaida ya kupata utambulisho unaotumika; kunakili faili ya cheti kwa mkono kwa kawaida hakutoshi.

Kwa hivyo vitu viwili kwenye profaili si kifurushi cha vyeti na nakala yake. Kimoja ni jozi ya funguo ambayo jukwaa linapaswa kuweza kusaini nayo, kingine ni nanga ya uaminifu ambayo jukwaa hulinganisha nayo. Vikague kama ukweli mbili tofauti: profaili hii inaweza kusaini, na inajua nani wa kumwamini?

Nanga za uaminifu ni za programu, sio za simu

Kuweka cheti cha mzizi kwenye hifadhi ya mtumiaji hakufanyi kila programu ya Android kuiamini: tangu Android 7 programu inapaswa kujiunga kupitia usanidi wake wa usalama wa mtandao, na kabla ya toleo hilo CA zilizowekwa na mtumiaji zilikubaliwa kwa upana zaidi. Usanidi wa uaminifu wa programu unaweza kutofautiana, na mteja wa VPN anayesimamia nyenzo zake za uaminifu anaweza asiangalie kabisa hifadhi ya mtumiaji. Ndio sababu faili ile ile ya CA inaweza kufanya kazi kwenye mteja mmoja na kuonekana kupuuzwa kwenye mwingine.

Mifano miwili ya umiliki inafuata. Profaili ya VPN inayosimamiwa na mfumo hutumia usakinishaji wa vyeti vya kifaa au mtiririko wa uandikishaji wa msimamizi, na profaili kisha hurejelea CA iliyokusudiwa. VPN inayosimamiwa na programu huhifadhi nyenzo zake za uaminifu na hutumia uagizaji wake ulioandikwa, ambao unaweza kuwa tofauti kabisa na skrini ya mipangilio ya Android. Hapo pia hutengeneza mnyororo uliovunjika: kwenye hifadhi ya CA na uchaguzi wa profaili kwa kesi inayosimamiwa na mfumo, kwenye skrini ya uagizaji ya mteja kwa inayosimamiwa na programu.

Amua uko kwenye mfano gani kabla ya kuagiza kitu chochote, kisha thibitisha uchaguzi wa uaminifu wa profaili inayotumika. Ikiwa maagizo ya mwendeshaji na menyu ya mteja hayalingani, tabia iliyoandikwa ya mteja inashinda kwa usakinishaji huo, lakini CA bado inapaswa kutoka kwa mwendeshaji kupitia njia unayoweza kuthibitisha. Jina la faili si ushahidi wa nani aliitoa.

Chagua hali, kisha faili

Hali ya cheti inahitaji jozi ya funguo ya mteja, CA inayotoa upande wa gateway, nanga ya uaminifu kwa cheti cha gateway, na matarajio ya utambulisho ambao cheti hicho kinapaswa kubeba. Hali ya jina la mtumiaji na nenosiri hubadilisha jozi ya funguo ya mteja na vitambulisho lakini huweka sharti la uaminifu wa gateway. Hali ya PSK hubadilisha vyote viwili na siri iliyoshirikiwa na hubadilisha mfano wa uaminifu badala ya kuurahisisha.

Chochote unachochagua, weka uthibitishaji wa kawaida ukiwa umewashwa. Chaguo la kutothibitisha, pale mteja anapolitoa, huondoa ukaguzi ambao sehemu ya CA ipo kwa ajili yake; haitengenezi nanga ya uaminifu inayokosekana. Vile vile kunakubali cheti chochote cha seva kwa sababu muunganisho unafanya kazi bila hicho.

Kisha thibitisha mahali sahihi: agiza nyenzo, unganisha mara moja, na thibitisha katika maelezo ya muunganisho ya mteja kwamba utambulisho wa gateway ni ule ulioutarajia na kwamba profaili inaripoti njia ya uthibitishaji uliyokusudia kutumia. Muunganisho wenye mafanikio ukiwa umechagua njia isiyo sahihi ni usanidi ambao haujauelewa bado, na utashindikana wakati mwendeshaji atakapokaza sera ijayo.