Android IKEv2: certifikata e përdoruesit dhe CA kanë role të ndryshme
Një fushë provon se kush është telefoni, tjetra vendos se cilit gateway t'i besohet. Profili Android IKEv2 i mban të ndara, sepse shkëmbimi i bën të ndara.
Një ekran Android IKEv2 që kërkon njëkohësisht certifikatë përdoruesi dhe certifikatë CA duket sikur kërkon të njëjtën gjë dy herë. Nuk është kështu. IKEv2 vërteton identitetin e të dy palëve, në të dy drejtimet, brenda të njëjtit shkëmbim, dhe telefoni luan rol të ndryshëm në çdo drejtim: duhet të provojë kush është dhe duhet të vendosë cilit gateway i beson. Certifikata e përdoruesit i përgjigjet pyetjes së parë, një CA e besuar i përgjigjet të dytës, dhe asnjëra nuk mund të zëvendësojë tjetrën.
Dy drejtime vërtetimi në një shkëmbim
IKEv2 ndërton një kanal kontrolli në dy faza. Shkëmbimi i parë negocion algoritme dhe çelësa; i dyti, IKE_AUTH, mbart një ngarkesë AUTH nga secila palë bashkë me identitetin e secilës palë. Ngarkesa është një nënshkrim ose MAC i llogaritur mbi shkëmbimin dhe verifikohet kundrejt diçkaje që marrësi beson tashmë.
Gateway-i provon identitetin e vet me certifikatën e vet, dhe telefoni verifikon zinxhirin e asaj certifikate deri në një rrënjë që është i gatshëm ta besojë, pastaj kontrollon që identiteti në certifikatë përputhet me gateway-in që synonte të arrinte. Telefoni provon identitetin e vet me kredencialin e vet, dhe gateway-i e verifikon atë kundrejt CA-së që lëshoi certifikatën e klientit.
Ky është i gjithë mekanizmi pas dy fushave. Certifikata e përdoruesit është një deklaratë që telefoni bën për veten; fusha CA është një deklaratë për atë se kujt do t'i besojë telefoni. Një profil që ka njërën por jo tjetrën nuk mund të përfundojë vërtetimin e ndërsjellë, dhe asnjë numër përpjekjesh nuk e ndryshon këtë. Të dyja dështimet madje duken ndryshe: një çelës përdoruesi që mungon e ndalon telefonin të prodhojë fare nënshkrim, ndërsa një pikë ankorimi besimi që mungon e ndalon të pranojë certifikatën e gateway-it.
| 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 |
Çfarë kërkon ndërtuesi i profilit në Android
Ndërtuesi i profilit IKEv2 i Google ekspozon çdo metodë vërtetimi veçmas, jo si një mënyrë e vetme certifikate. Metoda e nënshkrimit dixhital merr një certifikatë përdoruesi, një çelës privat dhe një CA rrënjë të serverit. Metodat e tjera marrin emër përdoruesi dhe fjalëkalim, ose një çelës të ndarë paraprakisht.
Lexoje me kujdes atë nënshkrim, sepse kodon mekanizmin më sipër. Nuk ka fushë për çelësin privat të përdoruesit në metodën emër përdoruesi dhe fjalëkalim, dhe nuk ka fushë për pikën ankorimi të besimit të gateway-it në metodën PSK, për arsyen e thjeshtë se ato metoda provojnë gjëra të ndryshme. Përzierja e tyre duke ngjitur një fjalëkalim në një fushë certifikate prodhon një profil që dështon në IKE_AUTH me një mesazh që nuk emërton asnjërën.
Lloji i dokumentuar i çelësit privat për metodën e nënshkrimit dixhital është RSA. Një menu e etiketuar IPsec ose certifikatë nuk nënkupton mbështetje për ECDSA, dhe një profil i montuar mbi supozimin se e mbështet do të dështojë në API-n e platformës përpara se rrjeta të përfshihet fare.
Pse një certifikatë publike e përdoruesit e vetme nuk mjafton
Ngarkesa AUTH është një nënshkrim mbi shkëmbimin, i bërë me çelësin privat të klientit. Të zotërosh certifikatën publike lejon gateway-in të kontrollojë një nënshkrim; për telefonin nuk bën asgjë, sepse i duhet çelësi për ta prodhuar. Importimi vetëm i .crt dhe lënia e çelësit pas është varianti më i zakonshëm i këtij dështimi.
Infrastruktura e çelësave e Android reflekton atë. Zgjedhja e një identiteti klienti kalon përmes KeyChain, që kërkon akses në çelësin privat përkatës, jo vetëm një zë certifikate. Një paketë regjistrimi ose një fluks menaxhimi pajisjesh që instalon çiftin së bashku është mënyra normale për të marrë një identitet të përdorshëm; kopjimi me dorë i një skedari certifikate zakonisht nuk është.
Pra, dy zërat në profil nuk janë një pako certifikatash dhe një dublikatë e saj. Njëri është një çift çelësash me të cilin platforma duhet të mund të nënshkruajë, tjetri është një pikë ankorimi besimi me të cilën platforma krahason. Kontrolloji si dy fakte të veçanta: a mund të nënshkruajë ky profil dhe a e di kujt t'i besojë?
Pikat e ankorimit të besimit i përkasin një aplikacioni, jo telefonit
Instalimi i një certifikate rrënjë në depon e përdoruesit nuk bën që çdo aplikacion Android t'i besojë asaj: që nga Android 7 një aplikacion duhet të përfshihet përmes konfigurimit të sigurisë së rrjetit, dhe përpara asaj versioni CA-të e instaluara nga përdoruesi pranoheshin shumë më gjerësisht. Konfigurimi i besimit të aplikacioneve mund të ndryshojë, dhe një klient VPN që menaxhon materialin e vet të besimit mund të mos e shohë fare depon e përdoruesit. Kjo është arsyeja pse i njëjti skedar CA mund të funksionojë në një klient dhe të duket i injoruar në një tjetër.
Pasojnë dy modele pronësie. Një profil VPN i menaxhuar nga sistemi përdor instalimin e certifikatave të pajisjes ose fluksin e regjistrimit të administratorit, dhe profili më pas referon CA-në e synuar. Një VPN i menaxhuar nga aplikacioni mban materialin e vet të besimit dhe përdor importin e vet të dokumentuar, që mund të jetë plotësisht i ndarë nga ekrani i cilësimeve të Android. Aty rregullohet edhe një zinxhir i thyer: në depon CA dhe zgjedhjen e profilit për rastin e menaxhuar nga sistemi, në ekranin e importit të klientit për rastin e menaxhuar nga aplikacioni.
Vendos në cilin model je përpara se të importosh gjë, pastaj konfirmo zgjedhjen e besimit të profilit aktiv. Nëse udhëzimet e operatorit dhe menyja e klientit nuk përputhen, sjellja e dokumentuar e klientit fiton për atë instalim, por CA duhet ende të vijë nga operatori përmes një kanali që mund ta verifikosh. Emri i një skedari nuk është provë se kush e lëshoi.
Zgjidh mënyrën, pastaj skedarët
Mënyra e certifikatës kërkon një çift çelësash klienti, CA-në lëshuese në anën e gateway-it, një pikë ankorimi besimi për certifikatën e gateway-it, dhe një pritje se cilin identitet duhet të mbajë ajo certifikatë. Mënyra emër përdoruesi dhe fjalëkalim zëvendëson çiftin e çelësave të klientit me kredenciale, por e mban të paprekur kërkesën për besim ndaj gateway-it. Mënyra PSK i zëvendëson të dyja me një sekret të përbashkët dhe e ndryshon modelin e besimit në vend që ta thjeshtojë.
Cilëndo që zgjedh, mbaj vërtetimin normal të aktivizuar. Një opsion mos verifiko, kur klienti e ofron, heq kontrollin që fusha CA ekziston për ta kryer; nuk rregullon një pikë ankorimi besimi që mungon. E njëjta vlen për pranimin e çdo certifikate serveri sepse lidhja funksionon pa të.
Pastaj verifiko në vendin e duhur: importo materialin, lidhu një herë dhe konfirmo në detajet e lidhjes së klientit se identiteti i gateway-it është ai që pritej dhe se profili raporton metodën e vërtetimit që synoje të përdorje. Një lidhje e suksesshme me mënyrën e gabuar të zgjedhur është një konfigurim që nuk e kupton ende, dhe do të dështojë herën tjetër kur operatori të shtrëngojë një politikë.