Android IKEv2: erabiltzaile-ziurtagiriak eta CA-k lan desberdinak egiten dituzte
Eremu batek telefonoa nor den frogatzen du, besteak zein pasabidetan konfiantza izan erabakitzen du. Androiden IKEv2 profilek bereizita mantentzen ditu.
Androiden IKEv2 pantaila batek erabiltzaile-ziurtagiria eta CA ziurtagiria batera eskatzen dituenean, gauza bera bitan eskatuko balu bezala dirudi. Ez da horrela. IKEv2-k bi aldeak bi norabidetan autentikatzen ditu elkarrekintza berean, eta telefonok norabide bakoitzean rol desberdina du: nor den frogatu behar du eta zein pasabidetan sinesten duen erabaki. Erabiltzaile-ziurtagiriak lehen galderari erantzuten dio, konfiantzazko CA-k bigarrenari, eta batek ez du bestea ordezkatzen.
Autentikazioaren bi norabide elkarrekintza bakarrean
IKEv2-k kontrol-kanal bat eraikitzen du bi fasetan. Lehenak algoritmoak eta gakoak negoziatzen ditu; bigarrenak, IKE_AUTH-ek, alde bakoitzetik AUTH karga bat darama bere identitatearekin. Karga elkarrekintzaren gaineko sinadura edo MAC bat da, eta hartzaileak jadanik sinesten duen zerbaiten aurka egiaztatzen da.
Pasabideak bere ziurtagiriarekin frogatzen du bere burua; telefonak katea onartzen duen erro bateraino baliozkotzen du eta ziurtagiriko identitatea iritsi nahi zuen pasabidearekin bat datorrela egiaztatzen du. elefonak bere kredentzialekin frogatzen du bere burua, eta pasabideak bezero-ziurtagiria eman zuen CA-ren aurka egiaztatzen ditu.
Horixe da bi eremuen atzeko mekanismo osoa. Erabiltzaile-ziurtagiria telefonak bere buruari buruz egiten duen adierazpena da; CA eremuak nori sinetsiko dion adierazten du. Batekin baina beste gabe, profilek ezin du elkarrekiko autentikazioa osatu eta berriro saiatzeak ez du ezer aldatzen. Hutsegiteek ere itxura desberdina dute: erabiltzaile-gakorik gabe telefonak ezin du sinatu, eta konfiantza-antorarik gabe ezin du pasabidearen ziurtagiria onartu.
| 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 |
Zer eskatzen du Androiden profiletako eraikitzaileak
Androiden IKEv2 profiletako eraikitzaileak autentikazio-metodo bakoitza bereiz erakusten du, ez ziurtagiri-modu bakar gisa. Sinadura digitalaren metodoak erabiltzaile-ziurtagiria, gako pribatua eta zerbitzariko erro-CA hartzen ditu; besteek erabiltzaile-izena eta pasahitza, edo aldez aurretik partekatutako gakoa.
Irakurri sinadura hori arretaz, goiko mekanismoa deskribatzen baitu. Ez dago gako pribatuaren eremurik erabiltzaile-izena eta pasahitza metodoan, ezta pasabidearen konfiantza-antorarik PSK metodoan, metodo horiek gauza desberdinak frogatzen dituztelako. Ziurtagiri-eremu batean itsatsitako pasahitzak IKE_AUTH-en huts egiten duen profila sortzen du, eta mezuak ez du bat ere aipatzen.
Sinadura digitalerako dokumentatutako gako pribatu mota RSA da. IPsec edo ziurtagiri etiketadun menuak ez du ECDSA onarpenik esan nahi, eta suposizio horretan eraikitako profilek plataformaren APIan huts egiten du sarean sartu aurretik.
Zergatik ez da nahikoa erabiltzaile-ziurtagiri publiko bat
AUTH karga bezeroaren gako pribatuarekin elkarrekintzaren gainean egindako sinadura da. Ziurtagiri publikoak pasabideari sinadura bat egiaztatzea ahalbidetzen dio, baina ez dio telefonari ezer egiten, eta hark gakoa behar du sinadura sortzeko. .crt soilik inportatu eta gakoa atzean uztea da hutsegite honen forma ohikoena.
Androiden gako-azpiegiturak hori islatzen du: bezero-identitatea hautatzeak KeyChain-etik pasatzen da, eta horrek dagokion gako pribaturako sarbidea eskatzen du, ez ziurtagiri-sarrera soilik. Inskripzio-pakete batek edo gailu-kudeaketak bikotea batera instalatzen duenean lortzen da identitate erabilgarria; eskuz fitxategia kopiatzea ez da ohikoa.
Beraz, profileko bi elementuak ez dira ziurtagirien sorta bat eta haren kopia. Bata plataformak sinatu behar duen gako-bikotea da, bestea alderatzeko konfiantza-antora. Egiaztatu bi gertaera bereizi gisa: profile honek sinatu dezake, eta badaki norengan fidatu?
Konfiantza-antorak aplikazioarenak dira, ez telefonoarenak
Erabiltzailearen biltegian erro bat instalatzeak ez du Android aplikazio guztiek sinetsiko: Android 7-tik aurrera aplikazioak berak aukeratu behar du sare-segurtasunaren konfigurazioaren bidez, eta bertsio horren aurretik erabiltzaileak instalatutako CAak askoz zabalago onartzen ziren. Konfiantza-konfigurazioa aplikazioz aplikazio alda daiteke, eta bere konfiantza-materiala kudeatzen duen VPN bezeroak baliteke biltegia inoiz ez begiratzea. Horregatik CA fitxategi berak bezero batean funtziona dezake eta bestean baztertuta eman.
Bi jabetza-eredu datoz. Sistemak kudeatutako profilek gailuaren ziurtagiri-instalazioa edo administratzailearen inskripzioa erabiltzen du, eta gero nahi den CA aipatzen du. Aplikazioak kudeatutako VPNak bere konfiantza-materiala eta bere inportazio dokumentatua gordetzen ditu, Androiden ezarpenen pantailatik guztiz bereizita egon daitekeena. Han konpontzen da hautsitako katea ere.
Erabaki zein eredutan zauden ezer inportatu aurretik, eta gero berretsi profile aktiboaren konfiantza-hautaketa. Operadorearen argibideak eta bezeroaren menua bat ez badatoz, instalazio horretarako bezeroaren jokabide dokumentatuak irabazten du, baina CAak operadorearen aldetik etorri behar du, egiazta dezakezun kanal batetik. Fitxategi-izenak ez du frogatzen nork eman zuen.
Hautatu modua, gero fitxategiak
Ziurtagiri-moduak bezeroaren gako-bikotea, pasabidearen aldean ematen duen CAa, pasabidearen ziurtagirirako konfiantza-antora eta ziurtagiriak eramango duen identitatearen itxaropena behar ditu. Erabiltzaile-izenak eta pasahitzak gako-bikotea kredentzialei ordezkatzen diete, baina pasabidearekiko konfiantza-baldintza mantentzen da. PSK-k biak sekretu partekatu batekin ordezkatzen ditu eta konfiantza-eredua aldatzen du, ez sinplifikatu.
Nahi duzuna aukeratu, mantendu balidazio arrunta piztuta. Egiaztatu gabe uzteko aukerak CA eremuak betetzeko duen egiaztapena kentzen du; ez du falta den konfiantza-antorarik konpontzen. Gauza bera gertatzen da edozein zerbitzari-ziurtagiri onartzean, konexioa horren gabe funtzionatzen duelako.
Gero egiaztatu leku egokian: inportatu materiala, konektatu behin, eta konexioaren xehetasunetan berretsi pasabidearen identitatea espero zenuena dela eta profilek nahi zenuen metodoa salatzen duela. Metodo okerrarekin lortutako konexio arrakastatsua oraindik ulertzen ez duzun konfigurazioa da, eta operadoreak politika bat gogortzean huts egingo du.