Android IKEv2: la uzanta atestilo kaj la CA faras malsamajn taskojn
Unu kampo pruvas, kiu estas la telefono, la alia decidas, kiun enirejon fidi. La IKEv2-profilo en Android tenas ilin apartaj.
IKEv2-ekrano en Android, kiu samtempe petas uzantan atestilon kaj CA-atestilon, aspektas kvazaŭ ĝi volus la saman aferon dufoje. Tio ne veras. IKEv2 aŭtentikigas ambaŭ flankojn en ambaŭ direktoj ene de unu interŝanĝo, kaj la telefono ludas malsaman rolon en ĉiu direkto: ĝi devas pruvi, kiu ĝi estas, kaj decidi, kiun enirejon ĝi kredas. La uzanta atestilo respondas la unuan demandon, la fidata CA la duan, kaj nek anstataŭas la alian.
Du direktoj de aŭtentikigo en unu interŝanĝo
IKEv2 konstruas regan kanalon en du fazoj. La unua interkonsentas algoritmojn kaj ŝlosilojn; la dua, IKE_AUTH, portas unu AUTH-ŝarĝon de ĉiu flanko kun ĝia identeco. La ŝarĝo estas subskribo aŭ MAC super la interŝanĝo, kaj ĝi estas kontrolata kontraŭ io, kiun la ricevanto jam fidas.
La enirejo pruvas sin per sia propra atestilo; la telefono kontrolas la ĉenon ĝis radiko, kiun ĝi fidas, kaj ke la identeco en la atestilo kongruas kun la enirejo, kiun ĝi volis atingi. La telefono pruvas sin per siaj identigiloj, kaj la enirejo kontrolas ilin kontraŭ la CA, kiu eldonis la klientan atestilon.
Tio estas la tuta mekanismo malantaŭ la du kampoj. La uzanta atestilo estas aserto de la telefono pri si mem; la CA-kampo estas aserto pri tio, kiun la telefono kredos. Profilo kun unu sed ne la alia ne povas fini reciprokan aŭtentikigon, kaj ripetado tion ne ŝanĝas. Eĉ la malsukcesoj aspektas malsame: sen uzanta ŝlosilo la telefono tute ne povas subskribi, sen fida ankro ĝi ne povas akcepti la atestilon de la enirejo.
| 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 |
Kion postulas la profilkonstruilo de Android
La IKEv2-profilkonstruilo de Android prezentas ĉiun aŭtentikigan metodon aparte, ne kiel unu atestilan reĝimon. La metodo de cifereca subskribo prenas uzantan atestilon, privatan ŝlosilon kaj radikan CA de la servilo; la aliaj prenas uzantnomon kaj pasvorton, aŭ antaŭe kunhavatan ŝlosilon.
Legu tiun subskribon atente, ĉar ĝi priskribas la supran mekanismon. Ne estas kampo por la privata ŝlosilo en la metodo de uzantnomo kaj pasvorto, nek kampo por la fida ankro de la enirejo en la metodo PSK, ĉar tiuj metodoj pruvas malsamajn aferojn. Pasvorto enigita en atestilan kampon donas profilon, kiu malsukcesas ĉe IKE_AUTH per mesaĝo, kiu nomas neniun el ili.
La dokumentita speco de privata ŝlosilo por la cifereca subskribo estas RSA. Menuo nomata IPsec aŭ atestilo ne implicas subtenon de ECDSA, kaj profilo konstruita sur tiu supozo malsukcesas ĉe la API de la platformo antaŭ ol la reto eĉ eniras.
Kial publika uzanta atestilo sola ne sufiĉas
La AUTH-ŝarĝo estas subskribo super la interŝanĝo farita per la privata ŝlosilo de la kliento. La publika atestilo ebligas al la enirejo kontroli subskribon, sed ĝi faras nenion por la telefono, kiu bezonas la ŝlosilon por krei ĝin. Importi nur .crt kaj lasi la ŝlosilon malantaŭe estas la plej ofta formo de ĉi tiu malsukceso.
La ŝlosila infrastrukturo de Android spegulas tion. Elekti klientan identecon iras tra KeyChain, kiu postulas aliron al la responda privata ŝlosilo, ne nur atestilan enskribon. Enskriba pako aŭ aparat-administra laborfluo, kiu instalaĵas la paron kune, estas la normala vojo al uzebla identeco; mana kopiado de dosiero kutime ne estas.
Do la du eroj en la profilo ne estas atestila fasko kaj ĝia kopio. Unu estas ŝlosila paro, per kiu la platformo devas povi subskribi, la alia estas fida ankro, kun kiu ĝi komparas. Kontrolu ilin kiel du apartajn faktojn: ĉu ĉi tiu profilo povas subskribi, kaj ĉu ĝi scias, kiun fidi?
Fidaj ankroj apartenas al aplikaĵo, ne al la telefono
Radiko instalita en la uzanta konservejo ne igas ĉiun Android-aplikaĵon fidi ĝin: ekde Android 7 aplikaĵo devas elekti tion per sia retsekureca agordo, kaj antaŭ tiu eldono uzante instalitaj CA-oj estis akceptataj multe pli vaste. La fida agordo povas diferenci, kaj VPN-kliento, kiu mem administras sian fidan materialon, eble neniam rigardas la uzantan konservejon. Tial la sama CA-dosiero povas funkcii en unu kliento kaj aspekti ignorata en alia.
El tio sekvas du posedmodeloj. Sistema profilo uzas la atestilan instalaĵon de la aparato aŭ administran enskribon, kaj poste la profilo referencas la celatan CA-on. Aplikaĵa VPN tenas sian propran fidan materialon kaj sian propran dokumentitan importon, kiu povas esti tute aparta de la agorda ekrano de Android. Tie ankaŭ rompita ĉeno estas riparata.
Decidu, en kiu modelo vi estas, antaŭ ol importi ion, kaj poste konfirmu la fidan elekton de la aktiva profilo. Se la instrukcioj de la operaciisto kaj la menuo de la kliento malkongruas, por tiu instalaĵo venkas la dokumentita konduto de la kliento, sed la CA devas ankoraŭ veni de la operaciisto per kanalo, kiun vi povas kontroli. Dosiernomo ne estas pruvo pri tio, kiu eldonis ĝin.
Unue la reĝimo, poste la dosieroj
La atestila reĝimo bezonas klientan ŝlosilan paron, la eldonantan CA-on ĉe la flanko de la enirejo, fidan ankron por la atestilo de la enirejo, kaj atendojn pri tio, kiun identecon tiu atestilo devas porti. Uzantnomo kaj pasvorto anstataŭas la ŝlosilan paron per identigiloj sed konservas la postulon fidi la enirejon. PSK anstataŭas ambaŭ per komuna sekreto kaj ŝanĝas la fidmodelon anstataŭ simpligi ĝin.
Kiun ajn vi elektas, lasu la normalan kontroladon ŝaltita. Opcio sen kontrolo forigas la kontrolon, por kiu la CA-kampo ekzistas; ĝi ne riparas mankan fidan ankron. La samo validas por akcepti ajnan servilan atestilon ĉar la konekto funkcias sen ĝi.
Poste kontrolu en la ĝusta loko: importu la materialon, konektu unufoje, kaj en la detaloj de la konekto konfirmu, ke la identeco de la enirejo estas la atendita kaj ke la profilo raportas la metodon, kiun vi intencis. Sukcesa konekto kun malĝusta metodo estas agordo, kiun vi ankoraŭ ne komprenas, kaj ĝi malsukcesos, kiam la operaciisto streĉos politikon.