Android IKEv2: magkaibang gawain ang sertipiko ng user at ang CA
Isang field ang nagpapatunay kung sino ang telepono, ang isa ay nagpapasya kung aling gateway ang pagkakatiwalaan. Pinaghihiwalay sila ng profile ng Android IKEv2 dahil ganoon ang handshake.
Ang screen ng Android IKEv2 na humihingi ng sertipiko ng user at sertipiko ng CA ay parang humihingi ng parehong bagay nang dalawang beses. Hindi ito ganoon. Ina-authenticate ng IKEv2 ang dalawang panig, sa dalawang direksyon, sa loob ng isang exchange, at may ibang papel ang telepono sa bawat direksyon: kailangan nitong patunayan kung sino ito, at kailangan nitong magpasya kung aling gateway ang pinaniniwalaan nito. Sinasagot ng sertipiko ng user ang unang tanong, sinasagot ng pinagkakatiwalaang CA ang pangalawa, at walang isa ang makapapalit sa isa.
Dalawang direksyon ng authentication sa isang exchange
Nagtatatag ang IKEv2 ng control channel sa dalawang yugto. Ang unang exchange ay nakikipagnegosasyon sa mga algorithm at key; ang pangalawa, IKE_AUTH, ay may dalang isang AUTH payload mula sa bawat panig kasama ang identidad ng bawat panig. Ang payload ay isang signature o MAC na kinakalkula sa exchange, at ito ay bineberipika laban sa isang bagay na pinagkakatiwalaan na ng tatanggap.
Pinatutunayan ng gateway ang identidad nito gamit ang sarili nitong sertipiko, at bineberipika ng telepono ang chain ng sertipikong iyon hanggang sa isang root na handa nitong pagkatiwalaan, pagkatapos ay sinusuri nito na ang identidad sa sertipiko ay tumutugma sa gateway na balak nitong maabot. Pinatutunayan ng telepono ang identidad nito gamit ang sarili nitong kredensyal, at bineberipika ito ng gateway laban sa CA na naglabas ng sertipiko ng kliyente.
Iyon ang buong mekanismo sa likod ng dalawang field. Ang sertipiko ng user ay isang pahayag na ginagawa ng telepono tungkol sa sarili nito; ang field ng CA ay isang pahayag tungkol sa kung sino ang paniniwalaan ng telepono. Ang profile na may isa ngunit wala ang isa ay hindi makakumpleto ng mutual authentication, at walang dami ng muling pagsubok ang makakabago nito. Magkaiba pa nga ang hitsura ng dalawang pagkabigo: ang kulang na key ng user ay pumipigil sa telepono na makagawa ng signature, samantalang ang kulang na trust anchor ay pumipigil dito na tanggapin ang sertipiko ng gateway.
| 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 |
Ano ang hinihingi ng profile builder sa Android
Ang IKEv2 profile builder ng Google ay naglalantad ng bawat paraan ng authentication nang hiwalay sa halip na isang mode ng sertipiko. Ang paraan ng digital signature ay kumukuha ng sertipiko ng user, private key at root CA ng server. Ang ibang mga paraan ay kumukuha ng username at password, o isang pre-shared key.
Basahin mong mabuti ang signature na iyon, dahil ini-encode nito ang mekanismo sa itaas. Walang field para sa private key ng user sa paraan ng username at password, at walang field para sa trust anchor ng gateway sa paraan ng PSK, sa simpleng dahilan na magkaibang bagay ang pinatutunayan ng mga paraang iyon. Ang paghahalo sa kanila sa pamamagitan ng pag-paste ng password sa field ng sertipiko ay gumagawa ng profile na nabibigo sa IKE_AUTH na may mensaheng hindi pinangalanan ang alinman.
Ang dokumentadong uri ng private key para sa paraan ng digital signature ay RSA. Ang menu na may label na IPsec o sertipiko ay hindi nangangahulugang may suporta sa ECDSA, at ang profile na binuo sa palagay na mayroon ito ay mabibigo sa API ng platform bago pa man masangkot ang network.
Bakit hindi sapat ang pampublikong sertipiko ng user lamang
Ang AUTH payload ay isang signature sa exchange, na ginawa gamit ang private key ng kliyente. Ang pagkakaroon ng pampublikong sertipiko ay nagbibigay-daan sa gateway na suriin ang signature; wala itong ginagawa para sa telepono, na kailangan ang key upang makagawa ng isa. Ang pag-import lamang ng .crt at pag-iiwan sa key ang pinakakaraniwang bersyon ng pagkabigong ito.
Ipinapakita iyon ng key infrastructure ng Android. Ang pagpili ng identidad ng kliyente ay dumadaan sa KeyChain, na nangangailangan ng access sa katumbas na private key, hindi lamang isang entry ng sertipiko. Ang enrolment package o daloy ng device management na nag-iinstall ng pares nang sama-sama ang normal na paraan upang makakuha ng magagamit na identidad; ang manu-manong pagkopya ng file ng sertipiko ay karaniwang hindi.
Kaya ang dalawang item sa profile ay hindi isang bundle ng sertipiko at isang kopya nito. Ang isa ay isang key pair na dapat makapag-sign ang platform, at ang isa ay isang trust anchor na inihahambing ng platform. Suriin sila bilang dalawang magkahiwalay na katotohanan: makakapag-sign ba ang profile na ito, at alam ba nito kung sino ang pagkakatiwalaan?
Ang mga trust anchor ay pag-aari ng isang application, hindi ng telepono
Ang pag-install ng root certificate sa user store ay hindi nagpapangyaring pagkatiwalaan ito ng bawat Android application: mula noong Android 7 kailangang sumali ng app sa pamamagitan ng configuration ng network security nito, at bago ang release na iyon ang mga CA na in-install ng user ay tinatanggap nang mas malawak. Maaaring magkaiba ang configuration ng tiwala ng application, at ang VPN client na namamahala ng sarili nitong trust material ay maaaring hindi kailanman tumingin sa user store. Kaya naman ang parehong file ng CA ay maaaring gumana sa isang client at mukhang binabalewala sa isa pa.
Dalawang modelo ng pagmamay-ari ang sumusunod. Ang system-managed VPN profile ay gumagamit ng certificate installation ng device o daloy ng enrolment ng administrator, at pagkatapos ay tinutukoy ng profile ang inilaan na CA. Ang app-managed VPN ay nagpapanatili ng sarili nitong trust material at gumagamit ng sarili nitong dokumentadong import, na maaaring lubos na hiwalay sa screen ng settings ng Android. Doon mo rin inaayos ang sirang chain: sa CA store at pagpili ng profile para sa system-managed na kaso, sa sariling import screen ng client para sa app-managed.
Magpasya kung aling modelo ka bago mag-import ng anuman, pagkatapos ay kumpirmahin ang pagpili ng tiwala ng aktibong profile. Kung hindi magkasundo ang mga tagubilin ng operator at ang menu ng client, ang dokumentadong pag-uugali ng client ang mananaig para sa installation na iyon, ngunit ang CA ay dapat pa ring magmula sa operator sa pamamagitan ng channel na maaari mong iberipika. Ang pangalan ng file ay hindi ebidensya kung sino ang naglabas nito.
Piliin ang mode, pagkatapos ang mga file
Ang certificate mode ay nangangailangan ng key pair ng client, ang issuing CA sa panig ng gateway, isang trust anchor para sa sertipiko ng gateway, at isang inaasahan kung aling identidad ang dapat dalhin ng sertipikong iyon. Ang username at password mode ay pinapalitan ang key pair ng client ng mga kredensyal ngunit pinananatiling buo ang pangangailangan ng tiwala sa gateway. Ang PSK mode ay pinapalitan ang dalawa ng isang shared secret at binabago ang modelo ng tiwala sa halip na pasimplehin ito.
Anuman ang piliin mo, panatilihing naka-enable ang normal na validation. Ang opsyon na huwag i-verify, kung inaalok ito ng client, ay nag-aalis ng check na dahilan ng field ng CA; hindi nito inaayos ang kulang na trust anchor. Ganoon din ang pagtanggap ng anumang sertipiko ng server dahil gumagana ang koneksyon nang wala ito.
Pagkatapos ay i-verify sa tamang lugar: i-import ang materyal, kumonekta nang isang beses, at kumpirmahin sa mga detalye ng koneksyon ng client na ang identidad ng gateway ay ang inaasahan mo at iniuulat ng profile ang paraan ng authentication na balak mong gamitin. Ang matagumpay na koneksyon na may maling paraan na napili ay isang configuration na hindi mo pa nauunawaan, at mabibigo ito sa susunod na higpitan ng operator ang isang patakaran.