Android IKEv2: sertifikat pengguna dan CA menjalankan tugas berbeda

Layar IKEv2 di Android yang meminta sertifikat pengguna sekaligus sertifikat CA terlihat seperti meminta hal yang sama dua kali. Tidak demikian. IKEv2 mengautentikasi kedua pihak di kedua arah dalam satu pertukaran, dan telepon berperan berbeda di tiap arah: harus membuktikan siapa dirinya dan memutuskan gerbang mana yang dipercayainya. Sertifikat pengguna menjawab pertanyaan pertama, CA yang dipercaya menjawab yang kedua, dan tidak ada yang menggantikan yang lain.

Dua arah autentikasi dalam satu pertukaran

IKEv2 membangun kanal kendali dalam dua fase. Fase pertama menegosiasikan algoritme dan kunci; fase kedua, IKE_AUTH, membawa satu muatan AUTH dari masing-masing pihak bersama identitasnya. Muatan itu adalah tanda tangan atau MAC atas pertukaran dan diverifikasi terhadap sesuatu yang sudah dipercaya penerimanya.

Gerbang membuktikan dirinya dengan sertifikatnya sendiri, sedangkan telepon memvalidasi rantai sampai akar yang diterimanya dan memeriksa bahwa identitas di sertifikat cocok dengan gerbang yang hendak dituju; telepon membuktikan dirinya dengan kredensialnya, dan gerbang memverifikasinya terhadap CA yang menerbitkan sertifikat klien.

Itulah seluruh mekanisme di balik kedua kolom. Sertifikat pengguna adalah pernyataan telepon tentang dirinya; kolom CA adalah pernyataan tentang siapa yang akan dipercayainya. Profil yang hanya punya salah satunya tidak dapat menyelesaikan autentikasi timbal balik, dan mengulanginya tidak mengubah itu. Bahkan kegagalannya tampak berbeda: tanpa kunci pengguna telepon sama sekali tidak dapat menandatangani, tanpa jangkar kepercayaan ia tidak dapat menerima sertifikat gerbang.

Apa yang diminta pembuat profil Android

Pembuat profil IKEv2 di Android menawarkan setiap metode autentikasi secara terpisah, bukan sebagai satu mode sertifikat. Metode tanda tangan digital memakai sertifikat pengguna, kunci privat, dan CA akar server; metode lain memakai nama pengguna dan kata sandi, atau kunci yang dibagikan sebelumnya.

Baca tanda tangan itu dengan cermat, karena di situlah mekanisme di atas terlihat. Tidak ada kolom kunci privat pada metode nama pengguna dan kata sandi, dan tidak ada kolom jangkar kepercayaan gerbang pada metode PSK, sebab metode itu membuktikan hal berbeda. Kata sandi yang ditempel ke kolom sertifikat menghasilkan profil yang gagal di IKE_AUTH dengan pesan yang tidak menyebut keduanya.

Jenis kunci privat yang didokumentasikan untuk metode tanda tangan digital adalah RSA. Menu berlabel IPsec atau sertifikat tidak berarti dukungan ECDSA, dan profil yang dibangun atas asumsi itu gagal di API platform sebelum jaringan ikut terlibat.

Mengapa sertifikat pengguna publik saja tidak cukup

Muatan AUTH adalah tanda tangan atas pertukaran yang dibuat dengan kunci privat klien. Sertifikat publik memungkinkan gerbang memeriksa tanda tangan, tetapi tidak berguna bagi telepon, yang memerlukan kunci itu untuk membuatnya. Mengimpor hanya .crt dan meninggalkan kuncinya adalah bentuk paling umum dari kegagalan ini.

Infrastruktur kunci Android mencerminkannya: memilih identitas klien melewati KeyChain, yang menuntut akses ke kunci privat terkait, bukan sekadar entri sertifikat. Paket pendaftaran atau alur manajemen perangkat yang memasang pasangan itu bersama-sama adalah cara normal mendapatkan identitas yang bisa dipakai; menyalin berkas dengan tangan biasanya bukan.

Jadi dua hal di profil itu bukan bundel sertifikat dan salinannya. Satu adalah pasangan kunci yang harus bisa dipakai platform untuk menandatangani, yang lain adalah jangkar kepercayaan yang menjadi pembandingnya. Periksa keduanya sebagai dua fakta terpisah: dapatkah profil ini menandatangani, dan tahukah ia siapa yang harus dipercaya?

Jangkar kepercayaan milik aplikasi, bukan telepon

Akar yang dipasang di penyimpanan pengguna tidak membuat semua aplikasi Android mempercayainya: sejak Android 7 aplikasi harus memilihnya melalui konfigurasi keamanan jaringannya, dan sebelum rilis itu CA yang dipasang pengguna diterima jauh lebih luas. Konfigurasi kepercayaan bisa berbeda, dan klien VPN yang mengelola materi kepercayaannya sendiri mungkin tidak pernah melihat penyimpanan pengguna. Karena itu berkas CA yang sama bisa bekerja di satu klien dan tampak diabaikan di klien lain.

Ada dua model kepemilikan. Profil yang dikelola sistem memakai pemasangan sertifikat perangkat atau pendaftaran administrator, lalu merujuk CA yang dimaksud. VPN yang dikelola aplikasi menyimpan materi kepercayaannya sendiri dan impor terdokumentasinya sendiri, yang bisa sepenuhnya terpisah dari layar setelan Android. Di situlah rantai yang rusak diperbaiki.

Putuskan Anda di model mana sebelum mengimpor apa pun, lalu pastikan pilihan kepercayaan profil yang aktif. Jika instruksi operator dan menu klien berbeda, perilaku terdokumentasi klien yang menang untuk pemasangan itu, tetapi CA tetap harus datang dari operator melalui saluran yang dapat Anda verifikasi. Nama berkas bukan bukti siapa yang menerbitkannya.

Pilih mode, lalu berkasnya

Mode sertifikat memerlukan pasangan kunci klien, CA penerbit di sisi gerbang, jangkar kepercayaan untuk sertifikat gerbang, dan harapan tentang identitas yang harus dibawanya. Nama pengguna dan kata sandi menggantikan pasangan kunci dengan kredensial tetapi mempertahankan syarat kepercayaan pada gerbang. PSK menggantikan keduanya dengan rahasia bersama dan mengubah model kepercayaan, bukan menyederhanakannya.

Apa pun pilihan Anda, biarkan validasi normal menyala. Opsi tanpa verifikasi menghapus pemeriksaan yang menjadi alasan kolom CA ada; ia tidak memperbaiki jangkar kepercayaan yang hilang. Hal yang sama berlaku untuk menerima sertifikat server apa pun karena koneksi tetap jalan tanpanya.

Lalu verifikasi di tempat yang benar: impor materinya, sambungkan sekali, dan pastikan di detail koneksi bahwa identitas gerbang adalah yang Anda harapkan dan profil melaporkan metode yang Anda maksud. Koneksi berhasil dengan metode yang salah adalah konfigurasi yang belum Anda pahami, dan akan gagal saat operator memperketat kebijakan.