Android IKEv2: foydalanuvchi sertifikati va CA turli vazifalarni bajaradi
Bir maydon telefonning kimligini isbotlaydi, ikkinchisi qaysi gatewayga ishonishni hal qiladi. Android IKEv2 profili ularni ajratib turadi, chunki handshake shunday ishlaydi.
Ham foydalanuvchi sertifikatini, ham CA sertifikatini so'raydigan Android IKEv2 ekrani xuddi bir narsani ikki marta so'rayotgandek ko'rinadi. Aslida unday emas. IKEv2 ikkala tomonni ham, ikkala yo'nalishda ham, bitta almashinuv ichida autentifikatsiya qiladi va telefon har bir yo'nalishda boshqa rol o'ynaydi: u kimligini isbotlashi va qaysi gatewayga ishonishini hal qilishi kerak. Foydalanuvchi sertifikati birinchi savolga javob beradi, ishonchli CA ikkinchisiga, va hech biri ikkinchisining o'rnini bosa olmaydi.
Bitta almashinuvda autentifikatsiyaning ikki yo'nalishi
IKEv2 boshqaruv kanalini ikki bosqichda o'rnatadi. Birinchi almashinuv algoritmlar va kalitlar bo'yicha kelishadi; ikkinchisi, IKE_AUTH, har bir tomondan bitta AUTH yuklamasini har bir tomonning identifikatori bilan birga olib yuradi. Yuklama almashinuv ustida hisoblangan imzo yoki MAC bo'lib, qabul qiluvchi allaqachon ishonadigan narsaga nisbatan tekshiriladi.
Gateway o'z identifikatorini o'z sertifikati bilan isbotlaydi, telefon esa bu sertifikat zanjirini ishonishga tayyor bo'lgan ildizgacha tekshiradi, so'ng sertifikatdagi identifikator yetib bormoqchi bo'lgan gatewayga mos kelishini tekshiradi. Telefon o'z identifikatorini o'z hisob ma'lumotlari bilan isbotlaydi, gateway esa uni mijoz sertifikatini bergan CAga nisbatan tekshiradi.
Ikki maydon ortidagi butun mexanizm shu. Foydalanuvchi sertifikati telefon o'zi haqida bergan bayonot; CA maydoni esa telefon kimga ishonishi haqidagi bayonot. Bittasi bor-u ikkinchisi yo'q profil o'zaro autentifikatsiyani tugata olmaydi va necha marta qayta urinish ham buni o'zgartirmaydi. Bu ikki nosozlik hatto boshqacha ko'rinadi: foydalanuvchi kaliti yo'q bo'lsa telefon umuman imzo yarata olmaydi, ishonch ankeri yo'q bo'lsa gateway sertifikatini qabul qila olmaydi.
| 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 profil quruvchisi nimani so'raydi
Google'ning IKEv2 profil quruvchisi har bir autentifikatsiya usulini alohida ko'rsatadi, bitta sertifikat rejimi sifatida emas. Raqamli imzo usuli foydalanuvchi sertifikatini, maxfiy kalitni va serverning ildiz CAini oladi. Boshqa usullar foydalanuvchi nomi va parolni yoki oldindan bo'lishilgan kalitni oladi.
Bu imzoni diqqat bilan o'qing, chunki u yuqoridagi mexanizmni kodlaydi. Foydalanuvchi nomi va parol usulida foydalanuvchining maxfiy kaliti uchun maydon yo'q, PSK usulida esa gatewayning ishonch ankeri uchun maydon yo'q, sababi oddiy: bu usullar turli narsalarni isbotlaydi. Parolni sertifikat maydoniga yopishtirib ularni aralashtirish IKE_AUTHda muvaffaqiyatsiz bo'ladigan va ikkalasini ham nomlamaydigan xabar beradigan profil hosil qiladi.
Raqamli imzo usuli uchun hujjatlashtirilgan maxfiy kalit turi RSA. IPsec yoki sertifikat deb belgilangan menyu ECDSA qo'llab-quvvatlanishini anglatmaydi, va bunday qo'llab-quvvatlash bor deb tuzilgan profil tarmoq ishtirok etishidan oldin platforma API'sida muvaffaqiyatsiz bo'ladi.
Nega faqat ommaviy foydalanuvchi sertifikati yetarli emas
AUTH yuklamasi mijozning maxfiy kaliti bilan almashinuv ustida yaratilgan imzo. Ommaviy sertifikatga ega bo'lish gatewayga imzoni tekshirish imkonini beradi; telefonga bu hech narsa bermaydi, chunki imzo yaratish uchun kalit kerak. Faqat .crt ni import qilib kalitni ortda qoldirish bu nosozlikning eng keng tarqalgan ko'rinishidir.
Android kalit infratuzilmasi buni aks ettiradi. Mijoz identifikatorini tanlash KeyChain orqali boradi, u tegishli maxfiy kalitga kirishni talab qiladi, faqat sertifikat yozuvini emas. Ikkalasini birga o'rnatadigan ro'yxatga olish paketi yoki qurilma boshqaruvi jarayoni ishlatish mumkin identifikator olishning odatiy yo'li; sertifikat faylini qo'lda nusxalash odatda unday emas.
Demak profildagi ikki element sertifikatlar to'plami va uning nusxasi emas. Biri platforma imzo qo'yishi kerak bo'lgan kalit juftligi, ikkinchisi platforma taqqoslaydigan ishonch ankeri. Ularni ikki alohida fakt sifatida tekshiring: bu profil imzo qo'ya oladimi va kimga ishonishni biladimi?
Ishonch ankerlari ilovaga tegishli, telefonga emas
Foydalanuvchi omboriga ildiz sertifikatini o'rnatish har bir Android ilovasi unga ishonishini ta'minlamaydi: Android 7 dan boshlab ilova o'z tarmoq xavfsizligi konfiguratsiyasi orqali qo'shilishi kerak, va bu versiyadan oldin foydalanuvchi o'rnatgan CAlar ancha keng qabul qilinardi. Ilovalarning ishonch konfiguratsiyasi farq qilishi mumkin, va o'z ishonch materialini o'zi boshqaradigan VPN mijozi foydalanuvchi omboriga umuman qaramasligi mumkin. Shuning uchun bir xil CA fayli bir mijozda ishlaydi, boshqasida esa e'tiborsiz ko'rinadi.
Bundan ikki egalik modeli kelib chiqadi. Tizim boshqaradigan VPN profili qurilmaning sertifikat o'rnatilishi yoki administrator ro'yxatga olish jarayonidan foydalanadi, so'ng profil ko'zda tutilgan CAni ko'rsatadi. Ilova boshqaradigan VPN o'z ishonch materialini saqlaydi va o'z hujjatlashtirilgan importidan foydalanadi, u Android sozlamalari ekranidan butunlay ajratilgan bo'lishi mumkin. Uzilgan zanjirni ham shu yerda tuzatasiz: tizim boshqaradigan holatda CA ombori va profil tanlovida, ilova boshqaradigan holatda mijozning o'z import ekranida.
Biror narsani import qilishdan oldin qaysi modelda ekaningizni hal qiling, so'ng faol profilning ishonch tanlovini tasdiqlang. Agar operatorning ko'rsatmalari va mijoz menyusi mos kelmasa, o'sha o'rnatish uchun mijozning hujjatlashtirilgan xatti-harakati ustun, lekin CA baribir operatordan siz tekshira oladigan kanal orqali kelishi kerak. Fayl nomi uni kim berganining dalili emas.
Avval rejimni, keyin fayllarni tanlang
Sertifikat rejimiga mijoz kalit juftligi, gateway tomonida beruvchi CA, gateway sertifikati uchun ishonch ankeri va bu sertifikat qaysi identifikatorni olib yurishi kerakligi haqidagi kutish kerak. Foydalanuvchi nomi va parol rejimi mijoz kalit juftligini hisob ma'lumotlari bilan almashtiradi, lekin gatewayga ishonch talabini saqlab qoladi. PSK rejimi ikkalasini umumiy sir bilan almashtiradi va ishonch modelini soddalashtirish o'rniga o'zgartiradi.
Nimani tanlasangiz ham oddiy tekshiruvni yoqilgan holda saqlang. Mijoz taklif qilsa, tekshirmaslik varianti CA maydoni uchun mavjud bo'lgan tekshiruvni olib tashlaydi; yo'q ishonch ankerini tuzatmaydi. Aloqa usiz ishlagani uchun har qanday server sertifikatini qabul qilish ham xuddi shunday.
So'ng to'g'ri joyda tekshiring: materialni import qiling, bir marta ulanib, mijozning aloqa tafsilotlarida gateway identifikatori siz kutgan identifikator ekanini va profil siz ishlatmoqchi bo'lgan autentifikatsiya usulini ko'rsatayotganini tasdiqlang. Noto'g'ri usul tanlangan holda muvaffaqiyatli aloqa bu siz hali tushunmagan konfiguratsiya bo'lib, operator keyingi safar siyosatni qattiqlashtirganda u muvaffaqiyatsiz bo'ladi.