Checklist Review Keamanan Android Keystore
Android Keystore memungkinkan aplikasi membuat dan memakai key melalui provider keystore Android. Status hardware-backed bergantung pada perangkat serta konfigurasi; aplikasi tidak boleh menganggap semua key memiliki perlindungan yang sama. Material key Keystore biasanya tidak diekspor, tetapi kode aplikasi masih dapat salah memakai key, mengekspos plaintext, menyimpan ciphertext terlalu lama, atau kehilangan akses setelah siklus hidup berubah. Karena itu review harus mencakup tujuan key dan siklus hidup data.
Target review adalah artefak rilis, bukan hanya cuplikan Kotlin. Catat application ID, version code, digest sertifikat penandatanganan, versi Android, model perangkat, tanggal, dan penguji. Temukan seluruh alias, pemanggil, transformation, serta format ciphertext yang persisten. Alias adalah pengenal, bukan tempat menyimpan secret; gunakan nama non-sensitif dan cukup stabil untuk migrasi yang terdokumentasi.
Batasi kemampuan saat membuat key
KeyGenParameterSpec.Builder menetapkan otorisasi saat key Android Keystore dibuat. Batasi purpose dengan KeyProperties.PURPOSE_ENCRYPT dan KeyProperties.PURPOSE_DECRYPT untuk enkripsi data, atau purpose penandatanganan bila memang dibutuhkan. Jangan memberi encrypt, decrypt, sign, dan verify pada satu alias hanya demi praktis. Block mode dan padding harus sesuai transformation yang dipakai kode; ketidakcocokan harus gagal dalam pengujian, bukan diam-diam memakai fallback.
val spec = KeyGenParameterSpec.Builder(
"profile-wrap-v2",
KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
)
.setBlockModes(KeyProperties.BLOCK_MODE_GCM)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.setUserAuthenticationRequired(true)
.setUserAuthenticationParameters(
0,
KeyProperties.AUTH_BIOMETRIC_STRONG or KeyProperties.AUTH_DEVICE_CREDENTIAL
)
.build()Contoh ini mewajibkan peristiwa autentikasi pengguna yang diizinkan pada setiap penggunaan kriptografi. Ini tidak mengautentikasi identitas pengguna di server atau mengotorisasi operasi server. Untuk membuka data lokal yang sensitif, gunakan crypto object BiometricPrompt bersama key terikat autentikasi, lalu coba operasi sebelum prompt, setelah berhasil, setelah cancel, dan setelah aplikasi masuk background. Catat exception yang diharapkan serta pemulihan yang tampak oleh pengguna. Jangan menggantikannya dengan flag Boolean “biometrik lulus”; operasi crypto harus terikat pada hasil prompt.
Jenis autentikasi, durasi validitas, dan perilaku invalidasi adalah keputusan produk. Key yang harus dipakai ulang tiap operasi tidak cocok untuk sinkronisasi background; jendela waktu mungkin tidak cocok untuk aksi berdampak tinggi. Dokumentasikan alasan parameter setUserAuthenticationParameters. Bila pendaftaran biometrik berubah, uji apakah setting yang dipilih menginvalidasi key yang terkait dan apakah aplikasi pulih tanpa kehilangan data. Jangan menghapus ciphertext sembarangan; pemulihan mungkin perlu re-wrap dari server atau autentikasi ulang.
StrongBox adalah permintaan, bukan jaminan
Pada perangkat kompatibel, setIsStrongBoxBacked(true) meminta pembuatan key StrongBox. Proses dapat gagal bila StrongBox tidak tersedia atau tidak mendukung algoritme, ukuran, mode, atau padding yang diminta. Perlakukan ketiadaan StrongBox sebagai cabang kemampuan yang diuji, bukan blok catch yang menurunkan perlindungan secara diam-diam. Simpan KeyInfo atau perilaku platform, model, API level, dan hasil pembuatan key untuk tiap kelas perangkat. Bila model ancaman mewajibkan StrongBox, perangkat tanpa dukungan harus gagal memenuhi syarat atau memakai alternatif yang disetujui; fallback software-backed bukan perlindungan StrongBox.
Rekam bukti dan penerimaan
| Pemeriksaan | Artefak selesai | Pemilik | Penerimaan lulus |
|---|---|---|---|
| Inventaris alias | Tabel alias, lokasi pakai, purpose, klasifikasi data. | Lead Android | Semua key produksi punya pemilik dan purpose. |
| Pembuatan key | Referensi kode, spec, ID build uji. | Pemilik crypto | Keystore membuat key tanpa byte key hard-code. |
| Ikatan autentikasi | Rekaman prompt dan hasil sukses/cancel/background. | Pemilik keamanan mobile | Pemakaian crypto terlindungi gagal sampai autentikasi diwajibkan terpenuhi. |
| Cabang StrongBox | Matriks perangkat serta hasil sukses atau gagal. | Pemilik kompatibilitas | Kebutuhan atau fallback dinyatakan dan diuji. |
| Siklus ciphertext | Sampel envelope berversi, uji instal ulang/restore/rotasi. | Pemilik data | Data lama dan baru mengikuti pemulihan terdokumentasi. |
| Inspeksi rilis | Catatan dekompilasi dan review log dengan penanda uji. | Pemilik rilis | Alias, plaintext, byte key, metadata sensitif tidak bocor. |
Beri status lulus hanya bila artefak dan penerimaan tersedia. Gagal bila key diekspor, penggunaan tanpa perlindungan berhasil, purpose salah dapat dipakai, material key di-hard-code, atau siklus hidup rusak. Belum terverifikasi bila build, perangkat, atau akses tidak tersedia.
Pengecualian dan remediasi
Setiap pengecualian menyebut alias terdampak, kelas data, hubungan MASVS, pemilik risiko, kontrol kompensasi, tanggal berakhir, serta persetujuan. Batasan perangkat tanpa pemilik dan tanggal berakhir bukan penutupan. Urutan remediasi: buat key khusus; persempit purpose dan parameter kriptografi; ikat penggunaan berisiko ke autentikasi; buat ciphertext berversi; tambahkan rotasi atau pemulihan yang diuji; hapus log tidak aman. Build ulang, jalankan kembali set uji yang sama, lalu lampirkan bukti retest sebelum menutup.
Dokumentasi Android dan OWASP MASTG adalah rujukan teknis, bukan sertifikasi. Audit kode sumber atau pengujian aplikasi mobile dapat menilai ruang lingkup yang disepakati.
Ulangi hasil penggunaan key
Generate key pada perangkat uji fisik, catat alias saja, lalu enkripsi plaintext sintetis tetap dan simpan envelope ciphertext dengan algoritme, IV, serta versi. Hasil yang diharapkan: operasi Keystore berhasil setelah autentikasi wajib dan pemanggil menerima ciphertext, bukan byte key mentah. Coba inisialisasi cipher sama sebelum prompt, setelah pembatalan, dan setelah event invalidasi wajib; hasil yang diharapkan adalah kegagalan autentikasi atau key-invalidated yang ditangani alur pemulihan. Catat kelas exception, API level, model perangkat, build ID, pemilik, lulus/gagal, dan tiket remediasi.
Uji key dan penutupan
Buat alias key seperti release dengan tujuan, algoritme, dan syarat autentikasi terdokumentasi. Catat metadata alias tanpa mengekspor material key, lalu coba operasi sebelum dan sesudah autentikasi perangkat. Hasil diharapkan: operasi kriptografis berhasil hanya dalam jendela otorisasi; di luar jendela aplikasi menangani UserNotAuthenticatedException tanpa melemahkan kebijakan atau mencatat material rahasia. Periksa backup dan migrasi: data aplikasi terbungkus mungkin berpindah, tetapi key Keystore non-exportable umumnya tetap terikat perangkat kecuali desain menyediakan pemulihan terkendali.
Kasus tepi: hardware perangkat berbeda. Key hardware-backed pada satu perangkat dapat memakai implementasi lain pada perangkat lain. Rekam attestation atau KeyInfo bila desain bergantung pada properti hardware, dan perlakukan properti tidak tersedia sebagai keputusan desain, bukan lulus diam-diam. Alias key bukan klaim otorisasi; server tetap mengotorisasi pengguna dan transaksi.
Tutup dengan identifier build, extract konfigurasi alias, perangkat/API diuji, output sukses dan penolakan, keputusan pemulihan, serta pemilik. Buka ulang setelah perubahan algoritme, target Android, kebijakan biometrik, atau migrasi format data terenkripsi.