Android IKEv2: sijil pengguna dan CA menjalankan tugas berbeza
Satu medan membuktikan siapa telefon itu, medan lain menentukan pintu gerbang mana yang dipercayai. Profil IKEv2 dalam Android memisahkan keduanya.
Skrin IKEv2 dalam Android yang meminta sijil pengguna dan sijil CA serentak kelihatan meminta perkara yang sama dua kali. Sebenarnya tidak. IKEv2 mengesahkan kedua-dua pihak dalam kedua-dua arah dalam satu pertukaran, dan telefon memainkan peranan berbeza dalam setiap arah: ia mesti membuktikan siapa dirinya dan memutuskan pintu gerbang mana yang dipercayainya. Sijil pengguna menjawab soalan pertama, CA yang dipercayai menjawab soalan kedua, dan tiada satu menggantikan yang lain.
Dua arah pengesahan dalam satu pertukaran
IKEv2 membina saluran kawalan dalam dua fasa. Fasa pertama merundingkan algoritma dan kunci; fasa kedua, IKE_AUTH, membawa satu muatan AUTH daripada setiap pihak bersama identitinya. Muatan itu ialah tandatangan atau MAC atas pertukaran dan disahkan terhadap sesuatu yang penerima sudah percaya.
Pintu gerbang membuktikan dirinya dengan sijilnya sendiri, manakala telefon mengesahkan rantaian hingga ke akar yang diterimanya dan menyemak bahawa identiti dalam sijil sepadan dengan pintu gerbang yang hendak dituju; telefon membuktikan dirinya dengan kelayakannya, dan pintu gerbang mengesahkannya terhadap CA yang mengeluarkan sijil klien.
Itulah keseluruhan mekanisme di sebalik dua medan itu. Sijil pengguna ialah pernyataan telefon tentang dirinya; medan CA ialah pernyataan tentang siapa yang akan dipercayainya. Profil yang mempunyai satu tanpa yang lain tidak dapat melengkapkan pengesahan bersama, dan cubaan semula tidak mengubahnya. Kegagalan pun kelihatan berbeza: tanpa kunci pengguna telefon langsung tidak boleh menandatangani, tanpa sauh kepercayaan ia tidak boleh menerima sijil pintu gerbang.
| 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 |
Apa yang diminta pembina profil Android
Pembina profil IKEv2 dalam Android menawarkan setiap kaedah pengesahan secara berasingan, bukan sebagai satu mod sijil. Kaedah tandatangan digital mengambil sijil pengguna, kunci peribadi dan CA akar pelayan; kaedah lain mengambil nama pengguna dan kata laluan, atau kunci yang dikongsi terlebih dahulu.
Baca tandatangan itu dengan teliti, kerana itulah mekanisme di atas. Tiada medan untuk kunci peribadi dalam kaedah nama pengguna dan kata laluan, dan tiada medan untuk sauh kepercayaan pintu gerbang dalam kaedah PSK, kerana kaedah itu membuktikan perkara berbeza. Kata laluan yang ditampal dalam medan sijil menghasilkan profil yang gagal pada IKE_AUTH dengan mesej yang tidak menyebut mana-mana satu pun.
Jenis kunci peribadi yang didokumenkan untuk kaedah tandatangan digital ialah RSA. Menu berlabel IPsec atau sijil tidak bermaksud sokongan ECDSA, dan profil yang dibina atas andaian itu gagal pada API platform sebelum rangkaian terlibat.
Mengapa sijil pengguna awam sahaja tidak mencukupi
Muatan AUTH ialah tandatangan atas pertukaran yang dibuat dengan kunci peribadi klien. Sijil awam membolehkan pintu gerbang menyemak tandatangan, tetapi tidak membantu telefon, yang memerlukan kunci itu untuk menghasilkannya. Mengimport hanya .crt dan meninggalkan kunci di belakang ialah bentuk kegagalan ini yang paling biasa.
Infrastruktur kunci Android mencerminkannya: memilih identiti klien melalui KeyChain, yang memerlukan akses kepada kunci peribadi berkenaan, bukan sekadar entri sijil. Pakej pendaftaran atau aliran pengurusan peranti yang memasang pasangan itu bersama-sama ialah cara biasa untuk mendapat identiti yang boleh digunakan; menyalin fail dengan tangan biasanya bukan.
Jadi dua item dalam profil itu bukan berkas sijil dan salinannya. Satu ialah pasangan kunci yang platform mesti boleh menandatangani dengannya, satu lagi ialah sauh kepercayaan yang dibandingkannya. Semak keduanya sebagai dua fakta berasingan: bolehkah profil ini menandatangani, dan tahukah ia siapa yang harus dipercayai?
Sauh kepercayaan milik aplikasi, bukan telefon
Akar yang dipasang dalam stor pengguna tidak membuat setiap aplikasi Android mempercayainya: sejak Android 7 aplikasi mesti memilihnya melalui konfigurasi keselamatan rangkaiannya, dan sebelum keluaran itu CA yang dipasang pengguna diterima jauh lebih luas. Konfigurasi kepercayaan boleh berbeza, dan klien VPN yang menguruskan bahan kepercayaannya sendiri mungkin tidak pernah melihat stor pengguna. Itulah sebabnya fail CA yang sama boleh berfungsi dalam satu klien dan kelihatan diabaikan dalam klien lain.
Dua model pemilikan berikut. Profil yang diurus sistem menggunakan pemasangan sijil peranti atau pendaftaran pentadbir, kemudian merujuk CA yang dimaksudkan. VPN yang diurus aplikasi menyimpan bahan kepercayaannya sendiri dan import yang didokumenkan, yang mungkin berasingan sepenuhnya daripada skrin tetapan Android. Di situlah rantaian yang rosak dibaiki.
Tentukan anda dalam model mana sebelum mengimport apa-apa, kemudian sahkan pilihan kepercayaan profil yang aktif. Jika arahan pengendali dan menu klien tidak sepadan, tingkah laku didokumenkan klien mengalahkan untuk pemasangan itu, tetapi CA masih mesti datang daripada pengendali melalui saluran yang anda boleh sahkan. Nama fail bukan bukti siapa yang mengeluarkannya.
Pilih mod, kemudian fail
Mod sijil memerlukan pasangan kunci klien, CA pengeluar di sebelah pintu gerbang, sauh kepercayaan untuk sijil pintu gerbang dan jangkaan tentang identiti yang perlu dibawanya. Nama pengguna dan kata laluan menggantikan pasangan kunci dengan kelayakan tetapi mengekalkan syarat kepercayaan pada pintu gerbang. PSK menggantikan keduanya dengan rahsia dikongsi dan mengubah model kepercayaan dan bukannya memudahkannya.
Apa pun pilihan anda, biarkan pengesahan biasa dihidupkan. Pilihan tanpa pengesahan membuang semakan yang menjadi tujuan medan CA; ia tidak membaiki sauh kepercayaan yang hilang. Perkara sama berlaku untuk menerima mana-mana sijil pelayan kerana sambungan berfungsi tanpanya.
Kemudian sahkan di tempat yang betul: import bahan, sambung sekali, dan dalam butiran sambungan sahkan bahawa identiti pintu gerbang ialah yang anda jangkakan dan profil melaporkan kaedah yang anda maksudkan. Sambungan berjaya dengan kaedah salah ialah konfigurasi yang belum anda fahami, dan ia akan gagal apabila pengendali mengetatkan dasar.