Android IKEv2. օգտվողի վկայականը և CA-ն տարբեր աշխատանք են կատարում
Մի դաշտը հաստատում է, թե ով է հեռախոսը, մյուսը որոշում է, թե որ դարպասին վստահել։ Android-ի IKEv2 պրոֆիլը դրանք առանձին է պահում։
Android-ի IKEv2 էկրանը, որը միաժամանակ պահանջում է օգտվողի վկայական և CA վկայական, թվում է թե նույն բանը երկու անգամ է ուզում։ Այդպես չէ։ IKEv2-ը հաստատում է երկու կողմերին երկու ուղղություններով մեկ փոխանակման մեջ, և հեռախոսը յուրաքանչյուր ուղղությամբ այլ դեր ունի՝ պետք է ապացուցի, թե ով է, և որոշի, թե որ դարպասին է հավատում։ Օգտվողի վկայականը պատասխանում է առաջին հարցին, վստահելի CA-ն՝ երկրորդին, և ոչ մեկը չի փոխարինում մյուսին։
Հաստատման երկու ուղղություն մեկ փոխանակման մեջ
IKEv2-ը կառավարման ուղին կառուցում է երկու փուլով։ Առաջինը պայմանավորվում է ալգորիթմների և բանալիների շուրջ, երկրորդը՝ IKE_AUTH-ը, յուրաքանչյուր կողմից բերում է մեկ AUTH ծանրաբեռնվածություն իր ինքնությամբ։ Ծանրաբեռնվածությունը փոխանակման վրա արված ստորագրություն կամ MAC է և ստուգվում է այն բանի դեմ, ինչին ստացողն արդեն վստահում է։
Դարպասը ինքն իրեն ապացուցում է իր սեփական վկայականով, հեռախոսը ստուգում է շղթան մինչև իր ընդունած արմատը և ստուգում, որ վկայականի ինքնությունը համապատասխանում է այն դարպասին, որին ուզում էր հասնել. հեռախոսն ինքն իրեն ապացուցում է իր հավատարմագրերով, և դարպասը դրանք ստուգում է այն CA-ի դեմ, որը տվել է հաճախորդի վկայականը։
Ահա ամբողջ մեխանիզմը երկու դաշտերի հետևում։ Օգտվողի վկայականը հեռախոսի հայտարարությունն է իր մասին, CA դաշտը՝ հայտարարություն այն մասին, թե ում կհավատա։ Մեկը մյուսի առանց ունեցող պրոֆիլը չի կարող ավարտել փոխադարձ հաստատումը, և կրկնվող փորձերը դա չեն փոխում։ Նույնիսկ ձախողումները տարբեր տեսք ունեն․ առանց օգտվողի բանալու հեռախոսը ընդհանրապես չի կարող ստորագրել, առանց վստահության խարիսխի չի կարող ընդունել դարպասի վկայականը։
| 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 |
Ինչ է պահանջում Android-ի պրոֆիլի կառուցիչը
Android-ի IKEv2 պրոֆիլի կառուցիչը յուրաքանչյուր հաստատման եղանակ առաջարկում է առանձին, ոչ որպես մեկ վկայականի ռեժիմ։ Թվային ստորագրության եղանակը վերցնում է օգտվողի վկայական, մասնավոր բանալի և սերվերի արմատային CA, մյուսները՝ օգտվողի անուն և գաղտնաբառ կամ նախապես համօգտագործված բանալի։
Կարդացեք այդ ստորագրությունը ուշադիր, որովհետև այն նկարագրում է վերը նշված մեխանիզմը։ Օգտվողի անվան և գաղտնաբառի եղանակում մասնավոր բանալու դաշտ չկա, PSK եղանակում էլ դարպասի վստահության խարիսխի դաշտ չկա, որովհետև այդ եղանակները տարբեր բաներ են ապացուցում։ Վկայականի դաշտում տեղադրված գաղտնաբառը տալիս է պրոֆիլ, որը ձախողվում է IKE_AUTH-ում այնպիսի հաղորդագրությամբ, որը ոչ մեկին չի նշում։
Թվային ստորագրության եղանակի համար փաստաթղթավորված մասնավոր բանալու տեսակը RSA-ն է։ IPsec կամ վկայական պիտակով ընտրացանկը ECDSA-ի աջակցություն չի նշանակում, և այդ ենթադրության վրա կառուցված պրոֆիլը ձախողվում է հարթակի API-ում դեռ մինչև ցանցի ներգրավումը։
Ինչու բավարար չէ միայն հրապարակային վկայականը
AUTH ծանրաբեռնվածությունը հաճախորդի մասնավոր բանալիով փոխանակման վրա արված ստորագրություն է։ Հրապարակային վկայականը թույլ է տալիս դարպասին ստուգել ստորագրությունը, բայց հեռախոսին ոչինչ չի տալիս, քանի որ ստորագրություն ստեղծելու համար հեռախոսին բանալին է պետք։ Միայն .crt ներմուծելը և բանալին հետևում թողնելը այս ձախողման ամենատարածված ձևն է։
Android-ի բանալիների ենթակառուցվածքը դա է արտացոլում․ հաճախորդի ինքնության ընտրությունը անցնում է KeyChain-ով, որը պահանջում է համապատասխան մասնավոր բանալու հասանելիություն, ոչ միայն վկայականի գրառում։ Զույգը միասին տեղադրող գրանցման փաթեթը կամ սարքի կառավարման հոսքը սովորական ճանապարհն է օգտագործելի ինքնություն ստանալու, ֆայլը ձեռքով պատճենելը սովորաբար ոչ։
Այսպիսով պրոֆիլի երկու տարրերը վկայականների փաթեթ և դրա պատճեն չեն։ Մեկը բանալիների զույգ է, որով հարթակը պետք է կարողանա ստորագրել, մյուսը վստահության խարիսխ է, որի հետ համեմատում է։ Ստուգեք դրանք որպես երկու առանձին փաստ․ կարո՞ղ է այս պրոֆիլը ստորագրել, և գիտի՞ ում վստահել։
Վստահության խարիսխները պատկանում են հավելվածին, ոչ հեռախոսին
Օգտվողի պահոցում տեղադրված արմատը չի ստիպում բոլոր Android հավելվածներին վստահել դրան․ Android 7-ից հավելվածը պետք է դա ընտրի իր ցանցային անվտանգության կարգաբերմամբ, և մինչ այդ թողարկումը օգտվողի տեղադրած CA-ները շատ ավելի լայն էին ընդունվում։ Վստահության կարգաբերումը կարող է տարբերվել, և սեփական վստահության նյութը կառավարող VPN հաճախորդը կարող է ընդհանրապես չնայել պահոցին։ Դրա համար նույն CA ֆայլը կարող է աշխատել մի հաճախորդում և անտեսված թվալ մյուսում։
Այստեղից բխում են սեփականության երկու մոդել։ Համակարգի կողմից կառավարվող պրոֆիլը օգտագործում է սարքի վկայականների տեղադրումը կամ ադմինիստրատորի գրանցումը, ապա հղում է նախատեսված CA-ին։ Հավելվածի կողմից կառավարվող VPN-ը պահում է իր վստահության նյութը և իր փաստաթղթավորված ներմուծումը, որը կարող է լիովին առանձին լինել Android-ի կարգավորումների էկրանից։ Այնտեղ էլ վերանորոգվում է կոտրված շղթան։
Որոշեք, թե որ մոդելում եք, նախքան ինչ-որ բան ներմուծելը, ապա հաստատեք ակտիվ պրոֆիլի վստահության ընտրությունը։ Եթե օպերատորի հրահանգները և հաճախորդի ընտրացանկը չեն համընկնում, այդ տեղադրման համար հաղթում է հաճախորդի փաստաթղթավորված վարքը, բայց CA-ն դեռ պետք է գա օպերատորից ստուգելի ուղով։ Ֆայլի անունը ապացույց չէ, թե ով է այն թողարկել։
Նախ ռեժիմը, հետո ֆայլերը
Վկայականի ռեժիմին պետք է հաճախորդի բանալիների զույգ, դարպասի կողմում թողարկող CA, վստահության խարիսխ դարպասի վկայականի համար և ակնկալիք, թե ինչ ինքնություն պետք է կրի այն։ Օգտվողի անունն ու գաղտնաբառը փոխարինում են զույգին հավատարմագրերով, բայց պահում են դարպասին վստահելու պահանջը։ PSK-ն երկուսն էլ փոխարինում է համօգտագործված գաղտնիքով և փոխում է վստահության մոդելը՝ փոխարենը պարզեցնելու։
Ինչ էլ ընտրեք, թողեք սովորական ստուգումը միացված։ Առանց ստուգման տարբերակը հեռացնում է այն ստուգումը, որի համար գոյություն ունի CA դաշտը, և չի վերանորոգում բացակայող խարիսխը։ Նույնը վերաբերում է ցանկացած սերվերի վկայական ընդունելուն, քանի որ կապն աշխատում է առանց դրա։
Ապա ստուգեք ճիշտ տեղում․ ներմուծեք նյութը, միացեք մեկ անգամ և կապի մանրամասներում հաստատեք, որ դարպասի ինքնությունը սպասվածն է, և պրոֆիլը հայտնում է ձեր նախատեսած եղանակը։ Սխալ եղանակով հաջող կապը կարգաբերում է, որը դեռ չեք հասկանում, և այն կձախողվի, երբ օպերատորը խստացնի քաղաքականությունը։