Android IKEv2: istifadəçi sertifikatı və CA fərqli işlər görür
Bir sahə telefonun kim olduğunu sübut edir, digəri hansı şlüzə etibar ediləcəyini müəyyən edir. Android-in IKEv2 profili onları ayrı saxlayır.
Android-də IKEv2 ekranı eyni anda həm istifadəçi sertifikatı, həm də CA sertifikatı istədikdə, guya eyni şeyi iki dəfə istəyir kimi görünür. Belə deyil. IKEv2 hər iki tərəfi eyni mübadilə daxilində iki istiqamətdə autentifikasiya edir və telefon hər istiqamətdə fərqli rol oynayır: kim olduğunu sübut etməli və hansı şlüzə inandığını qərar verməlidir. İstifadəçi sertifikatı birinci suala, etibarlı CA ikincisinə cavab verir və heç biri digərini əvəz edə bilməz.
Bir mübadilədə iki autentifikasiya istiqaməti
IKEv2 idarəetmə kanalını iki mərhələdə qurur. Birinci mərhələ alqoritmləri və açarları razılaşdırır; ikincisi, IKE_AUTH, hər tərəfdən öz kimliyi ilə birlikdə bir AUTH yükü daşıyır. Yük mübadilə üzərində hesablanmış imza və ya MAC-dır və qəbul edənin artıq etibar etdiyi bir şeylə yoxlanılır.
Şlüz özünü öz sertifikatı ilə sübut edir; telefon zənciri etibar etdiyi kökə qədər yoxlayır və sertifikatdakı kimliyin çatmaq istədiyi şlüzə uyğun olduğunu təsdiqləyir. Telefon da özünü öz etimadnaməsi ilə sübut edir və şlüz bunu müştəri sertifikatını verən CA ilə yoxlayır.
İki sahənin arxasındakı bütün mexanizm budur. İstifadəçi sertifikatı telefonun özü haqqında bəyanatıdır; CA sahəsi isə telefonun kimə inanacağı haqqında bəyanatdır. Birini daşıyıb digərini daşımayan profil qarşılıqlı autentifikasiyanı tamamlaya bilmir və təkrar cəhdlər bunu dəyişmir. Uğursuzluqlar hətta fərqli görünür: istifadəçi açarı yoxdursa telefon ümumiyyətlə imza yarada bilmir; etibar lövbəri yoxdursa şlüzün sertifikatını qəbul edə bilmir.
| 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 |
Android profil qurucusu nə tələb edir
Android-in IKEv2 profil qurucusu hər autentifikasiya metodunu ayrıca təqdim edir, tək bir sertifikat rejimi kimi yox. Rəqəmsal imza metodu istifadəçi sertifikatı, şəxsi açar və server kök CA-sı alır; digərləri istifadəçi adı və parol, ya da əvvəlcədən paylaşılmış açar alır.
O imzanı diqqətlə oxuyun, çünki yuxarıdakı mexanizmi məhz o ifadə edir. İstifadəçi adı/parol metodunda şəxsi açar üçün sahə yoxdur, PSK metodunda şlüzün etibar lövbəri üçün sahə yoxdur, çünki bu metodlar fərqli şeyləri sübut edir. Parolu sertifikat sahəsinə yapışdırmaq IKE_AUTH-da uğursuz olan profil yaradır və mesaj ikisinin heç birini adlandırmır.
Rəqəmsal imza metodu üçün sənədləşdirilmiş şəxsi açar növü RSA-dır. IPsec və ya sertifikat yazılmış menyu ECDSA dəstəyi demək deyil və bu fərziyyə ilə qurulmuş profil şəbəkəyə çatmadan platforma API-sində uğursuz olur.
Yalnız açıq istifadəçi sertifikatı niyə kifayət etmir
AUTH yükü müştərinin şəxsi açarı ilə mübadilə üzərində hesablanmış imzadır. Açıq sertifikat şlüzə imzanı yoxlamağa imkan verir, amma telefon üçün heç nə etmir, çünki imza yaratmaq üçün telefon açarı istəyir. Yalnız .crt faylını idxal edib açarı geridə qoymaq bu uğursuzluğun ən geniş yayılmış formasıdır.
Android-in açar infrastrukturu bunu əks etdirir. Müştəri kimliyinin seçilməsi KeyChain-dən keçir və bu, yalnız sertifikat qeydi deyil, uyğun şəxsi açara çıxış tələb edir. Cütü birlikdə quraşdıran qeydiyyat paketi və ya cihaz idarəetmə iş axını istifadəyə yararlı kimlik əldə etməyin normal yoludur; sertifikat faylını əl ilə köçürmək adətən deyil.
Deməli profildəki iki element sertifikat bağlaması və onun surəti deyil. Biri platformanın imzalaya bilməli olduğu açar cütüdür, digəri müqayisə etdiyi etibar lövbəridir. Onları iki ayrı fakt kimi yoxlayın: bu profil imzalaya bilirmi və kimə etibar edəcəyini bilirmi?
Etibar lövbərləri tətbiqə aiddir, telefona yox
İstifadəçi anbarına kök sertifikat quraşdırmaq hər Android tətbiqinin ona etibar etməsi demək deyil: Android 7-dən bəri tətbiq bunu şəbəkə təhlükəsizliyi konfiqurasiyası ilə seçməlidir, o buraxılışdan əvvəl isə istifadəçinin quraşdırdığı CA-lar daha geniş qəbul edilirdi. Etibar konfiqurasiyası tətbiqdən tətbiqə fərqlənə bilər və öz etibar materialını idarə edən VPN müştərisi istifadəçi anbarına heç baxmaya bilər. Buna görə eyni CA faylı bir müştəridə işləyib digərində görməzdən gəlinmiş görünə bilər.
Buradan iki sahiblik modeli çıxır. Sistem tərəfindən idarə olunan profil cihazın sertifikat quraşdırmasından və ya administrator qeydiyyatından istifadə edir və nəzərdə tutulan CA-ya istinad edir. Tətbiq tərəfindən idarə olunan VPN öz etibar materialını və öz sənədləşdirilmiş idxalını saxlayır; bu, Android ayarları ekranından tamamilə ayrı ola bilər. Qırılmış zənciri təmir etdiyiniz yer də elə oradır.
Nəyisə idxal etməzdən əvvəl hansı modeldə olduğunuzu müəyyənləşdirin, sonra aktiv profilin etibar seçimini təsdiqləyin. Operatorun təlimatı ilə müştərinin menyusu ziddiyyət təşkil edirsə, həmin quraşdırma üçün müştərinin sənədləşdirilmiş davranışı üstündür, lakin CA yenə də operator tərəfindən yoxlaya bildiyiniz kanalla gəlməlidir. Fayl adı kimin verdiyinin sübutu deyil.
Əvvəlcə rejimi, sonra faylları seçin
Sertifikat rejimi müştəri açar cütü, şlüz tərəfində verən CA, şlüz sertifikatı üçün etibar lövbəri və həmin sertifikatın daşımalı olduğu kimlik barədə gözlənti tələb edir. İstifadəçi adı/parol açar cütünü etimadnamə ilə əvəz edir, lakin şlüzə etibar tələbini saxlayır. PSK hər ikisini ümumi sirrlə əvəz edir və etibar modelini sadələşdirmək əvəzinə dəyişir.
Hansını seçsəniz də, normal yoxlamanı aktiv saxlayın. Yoxlamama seçimi CA sahəsinin mövcud olma səbəbi olan nəzarəti aradan qaldırır; çatışmayan etibar lövbərini düzəltmir. Bağlantı onsuz da işləyir deyə hər hansı server sertifikatını qəbul etmək üçün də eyni şey keçərlidir.
Sonra düzgün yerdə yoxlayın: materialı idxal edin, bir dəfə qoşulun və müştərinin bağlantı detallarında şlüz kimliyinin gözlədiyiniz olduğunu, profilin isə niyyət etdiyiniz metodu göstərdiyini təsdiqləyin. Səhv metodla uğurlu bağlantı hələ başa düşmədiyiniz konfiqurasiyadır və operator siyasəti sərtləşdirəndə uğursuz olacaq.