御盾Kesimpulan dan kondisi pengambilan keputusan
- Instalasi berhasil, verifikasi tanda tangan berhasil, dan identitas penerbit resmi adalah tiga penilaian terpisah; dua yang pertama tidak dapat menggantikan yang ketiga.
- Paket yang ditandatangani ulang umumnya tidak dapat melakukan overlay pada versi resmi yang diinstal di bawah identitas tanda tangan berbeda; rantai pembaruan merupakan gerbang kritis untuk mengidentifikasi artefak anomali.
- APK akhir harus memperbaiki nama paket, versi, digest sertifikat, digest file, asal build, dan urutan pemrosesan channel.
- Server harus mempertahankan daftar izin (allowlist) untuk versi dan identitas aplikasi yang diizinkan, memperlakukan sinyal integritas platform sebagai masukan risiko daripada memercayai data yang dilaporkan sendiri oleh klien.
Membedakan Validasi Instalasi, Identitas Tanda Tangan, dan Otorisasi Bisnis
Android mensyaratkan APK ditandatangani. Sistem memverifikasi apakah struktur paket installer dan data tanda tangan membuktikan bahwa konten saat ini ditandatangani oleh kunci privat yang sesuai. Jika penyerang memodifikasi file DEX, sumber daya, atau Manifest, lalu menandatangani ulang hasilnya sepenuhnya dengan kunci mereka sendiri, paket baru tersebut dapat secara kriptografis konsisten dengan dirinya sendiri dan mungkin memenuhi kondisi untuk instalasi baru.
Hasil ini hanya menjawab apakah paket saat ini memiliki tanda tangan yang dapat diverifikasi; tidak menjawab apakah penandatangan adalah penerbit resmi. Otorisasi merek, channel sah, izin masuk akun, dan akses ke antarmuka berisiko tinggi adalah urusan bisnis yang harus dievaluasi secara terpisah oleh aplikasi dan server.
Oleh karena itu, laporan pengujian tidak boleh menyamakan 'dapat diinstal setelah ditandatangani ulang' dengan 'kegagalan proteksi tanda tangan', maupun menyamakan 'kegagalan instalasi' dengan 'semua risiko pengemasan ulang telah tertutup'. Pertanyaan yang benar adalah: Dapatkah paket yang dimodifikasi mencapai perangkat pengguna? Dapatkah paket tersebut menyamar sebagai versi resmi selama pembaruan? Dapatkah paket tersebut terhubung ke layanan nyata? Dan bagaimana server mengidentifikasi serta menangani kasus semacam itu?
| Penilaian | Pertanyaan yang Dijawab | Bukti yang Diperlukan | Kesimpulan yang Tidak Dapat Diekstrapolasi |
|---|---|---|---|
| Paket Dapat Diurai | Dapatkah installer membaca struktur file? | Hasil installer, Manifest, dan struktur sumber daya | Tidak membuktikan legitimasi tanda tangan atau keamanan kode |
| Tanda Tangan Saat Ini Konsisten dengan Dirinya Sendiri | Apakah konten saat ini ditandatangani oleh kunci privat yang sesuai dengan sertifikat saat ini? | Verifikasi skema tanda tangan dan digest sertifikat | Tidak membuktikan bahwa sertifikat milik entitas resmi |
| Kontinuitas Identitas Pembaruan | Dapatkah paket melakukan overlay pada aplikasi resmi yang sudah terinstal? | Menjalankan pembaruan dari versi live yang asli | Tidak membuktikan bahwa semua antarmuka bisnis akan menolak klien anomali |
| Otorisasi Bisnis Berhasil | Apakah server mengizinkan akun dan versi tersebut mengakses sumber daya? | Kebijakan versi, akun, integritas, dan perilaku di sisi server | Tidak menjamin kode klien kebal terhadap analisis atau modifikasi |
Mengapa Paket yang Ditandatangani Ulang Seringkali Hanya Mengizinkan Instalasi Baru
Android menggunakan identitas tanda tangan aplikasi untuk menjaga kontinuitas pembaruan. Saat aplikasi terinstal menerima pembaruan overlay, platform harus mengonfirmasi bahwa versi baru memenuhi aturan identitas tanda tangan relatif terhadap versi yang ada. Paket yang dimodifikasi dan ditandatangani dengan sertifikat tidak terkait biasanya tidak dapat langsung menimpa versi resmi; langkah ini memerlukan pencopotan instalasi aplikasi resmi terlebih dahulu, perubahan nama paket, atau induksi agar pengguna menginstalnya di lingkungan terpisah.
Inilah mengapa uji pengemasan ulang harus menjalankan baik instalasi baru maupun pembaruan overlay. Menguji hanya instalasi baru akan melewatkan pemeriksaan kontinuitas tanda tangan, sedangkan menguji hanya pembaruan overlay akan melewatkan jalur di mana paket palsu masuk ke perangkat melalui nama paket berbeda atau siklus copot-instal ulang. Hasil untuk kedua skenario tersebut harus dicatat secara terpisah.
Rotasi tanda tangan dan Play App Signing menambahkan kompleksitas pada rantai rilis. Tim harus mempertahankan identitas sertifikat yang saat ini berlaku dan yang diizinkan secara historis, aturan rotasi, serta tanggung jawab kunci unggah dibandingkan kunci penandatanganan aplikasi. Kebijakan sisi server harus menggunakan data yang sesuai dengan metode distribusi. Sertifikat pengembangan, sertifikat unggah, dan sertifikat distribusi final tidak boleh pernah digabungkan menjadi satu bidang.
- Jalankan pembaruan overlay dari versi live saat ini
- Lakukan instalasi baru setelah pencopotan instalasi
- Periksa perubahan nama paket dan dampaknya pada direktori data
- Verifikasi rotasi sertifikat terhadap aturan platform distribusi
Tata Kelola Pengemasan Ulang Harus Dimulai dari Identitas Artefak Final
Tim sering kali hanya menyimpan nomor build, namun mengabaikan pencatatan digest file dan digest sertifikat penandatanganan dari APK final. Injeksi sumber daya saluran, penyelarasan ulang, penandatanganan ulang, atau optimasi paket dapat mengubah file final. Jika pemindaian keamanan menganalisis artefak pra-saluran, file yang diterima oleh pengguna live tidak tercakup oleh bukti yang sama.
Kami merekomendasikan pembuatan catatan artefak yang tidak ambigu untuk setiap release candidate: nama paket, versionCode, versionName, SHA-256 file, SHA-256 sertifikat, hasil verifikasi skema tanda tangan, asal build, saluran, urutan pemrosesan, dan stempel waktu generasi. Pemeriksaan statis, peningkatan instalasi, pengujian regresi fungsional, dan aturan izin sisi server harus semuanya mereferensikan catatan ini.
Digest file bukanlah tindakan protektif itu sendiri; nilainya terletak pada pencegahan perubahan diam-diam pada objek uji selama alur kerja. Setiap perubahan pada digest, tanda tangan, atau urutan saluran menunjukkan release candidate baru, yang memerlukan eksekusi ulang gerbang yang terdampak.
artifact:
package: com.example.redacted
version_code: 240
version_name: 2.4.0
sha256: REDACTED
signing:
certificate_sha256: REDACTED
schemes: [v2, v3]
distribution: managed-channel
pipeline:
- build-release
- harden-candidate
- channel-resources
- final-sign
acceptance:
install_fresh: required
upgrade_from_production: required
server_policy_check: requiredServer Harus Memperlakukan Klien Anomali sebagai Masalah Kebijakan
Klien dapat melaporkan nama paket, versi, sertifikat, atau materi integritas, namun klien yang dimodifikasi juga dapat memanipulasi bidang pelaporan standar ini. Server harus memprioritaskan sinyal yang dapat diverifikasi, dengan menggabungkan status akun, versi, perilaku permintaan, risiko perangkat, dan lingkungan distribusi ke dalam sebuah kebijakan, alih-alih mempercayai satu nilai boolean yang dilaporkan klien.
Play Integrity dapat mengembalikan putusan mengenai pengenalan aplikasi, integritas perangkat, lisensi akun, dan risiko lingkungan. Dokumentasi resmi mencatat bahwa sinyal tertentu mungkin tidak tersedia karena versi OS, faktor bentuk perangkat, sumber distribusi, status Play Services, atau konfigurasi. Pendekatan yang benar adalah memodelkan status 'tidak tersedia', 'gagal', dan 'berisiko tinggi' secara terpisah, sambil menyiapkan strategi untuk degradasi, verifikasi sekunder, pembatasan hak akses, atau penolakan.
Skenario distribusi di luar Google Play tidak dapat sekadar menyalin sinyal eksklusif Play. Distribusi perusahaan, saluran domestik, dan pengiriman privat memerlukan pembentukan daftar izin mereka sendiri untuk versi, pemetaan sertifikat, mekanisme pembaruan, dan prosedur penanganan anomali. Sinyal platform merupakan bagian dari bukti, bukan jawaban universal di seluruh saluran.
| Masukan | Metode Verifikasi | Status yang Mungkin | Tindakan yang Direkomendasikan |
|---|---|---|---|
| Versi dan Nama Paket | Bandingkan dengan buku besar rilis dan aturan saluran | Diizinkan, Kedaluwarsa, Tidak Dikenal | Izinkan, minta pembaruan, batasi kapabilitas berisiko tinggi |
| Sinyal Pengenalan Aplikasi | Validasi tanda tangan yang dikembalikan platform dan hasil identitas aplikasi | Teridentifikasi, Tidak Teridentifikasi, Tidak Tersedia | Normal, tantang atau batasi, degradasi sesuai saluran |
| Akun dan Lisensi | Izin akun sisi server dan lisensi distribusi | Valid, Kedaluwarsa, Anomali | Otorisasi atau tolak berdasarkan cakupan sumber daya |
| Perilaku Permintaan | Laju, replay, perubahan perangkat, dan konteks bisnis | Normal, Mencurigakan, Berisiko Tinggi | Catat, verifikasi sekunder, batasi laju, atau blokir |
| Perangkat dan Lingkungan | Putusan platform dan aturan risiko proprietari | Terpenuhi, Sinyal Lemah, Tidak Dikenal | Penilaian risiko bertingkat, bukan keputusan absolut satu titik |
Urutan Rilis yang Salah Membatalkan Pemeriksaan Sebelumnya
Memodifikasi DEX, sumber daya, atau Manifest setelah penandatanganan akhir merusak konten yang dicakup oleh tanda tangan; membangun ulang atau menandatangani ulang setelah pemindaian memisahkan kesimpulan pemindaian dari file akhir. Jika alat pemrosesan saluran perlu memodifikasi badan paket, hal ini harus diselesaikan sebelum penandatanganan akhir, dan urutannya harus ditetapkan dalam buku besar artefak.
Distribusi AAB lebih membedakan antara artefak yang diunggah dan APK terpisah yang diterima oleh perangkat pengguna. Tim harus mengunduh atau memperoleh artefak yang benar-benar dikirimkan dari platform distribusi untuk pemeriksaan acak, memastikan bahwa nama paket, versi, identitas tanda tangan, dan sumber daya kunci cocok dengan catatan rilis. APK generik yang dibuat secara lokal tidak dapat secara otomatis mewakili semua konfigurasi perangkat.
Paket rollback juga harus menjalani validasi tanda tangan dan pembaruan yang sama. Dalam suatu insiden, penandatanganan ulang sementara pada file lama mungkin gagal melakukan instalasi overlay karena ketidakcocokan nomor versi, tanda tangan, atau persyaratan migrasi data.
| Tahap | Masukan | Bukti Keluaran | Kondisi Kegagalan Utama |
|---|---|---|---|
| Bangunan Rilis | Kode sumber dan dependensi yang dibekukan | Rekaman bangunan dan artefak dasar | Dependensi atau konfigurasi tidak dapat direproduksi |
| Pemrosesan Pengerasan Aplikasi | Konfigurasi perlindungan eksplisit | Versi konfigurasi dan artefak kandidat rilis | Objek pemrosesan tidak cocok dengan versi target |
| Pemrosesan Saluran | Sumber daya saluran dan informasi kepatuhan | Artefak kandidat saluran | Konten dimodifikasi setelah penandatanganan |
| Penandatanganan Akhir | Kunci terkendali dan badan paket akhir | Ringkasan sertifikat dan hasil verifikasi tanda tangan | Penggunaan kunci atau lingkungan yang salah |
| Rilis Penerimaan | File akhir yang unik | Gerbang instalasi, pembaruan, bisnis, dan sisi server | Penggantian objek yang diterima dengan file lain |
Cara Menentukan Risiko Pengemasan Ulang Berada di Bawah Kontrol yang Dapat Dipublikasikan
Kesimpulan yang dapat dipublikasikan tidak berarti paket yang dimodifikasi tidak akan pernah dapat diinstal. Ini berarti identitas artefak resmi dapat dilacak, artefak anomali tidak dapat menutupi versi resmi secara diam-diam, server dapat mengidentifikasi atau membatasi klien yang tidak tepercaya, pengguna memiliki jalur untuk memperoleh versi asli dan pulih, serta tim dapat mengaudit file pengiriman akhir.
Pengujian harus menyimpan bukti untuk jalur sukses dan gagal. Jalur sukses mencakup instalasi/pembaruan normal versi resmi, login, dan alur bisnis utama. Jalur anomali mencakup pembaruan overlay dengan sertifikat yang tidak terkait, versi tidak dikenal yang mengakses antarmuka berisiko tinggi, versi kedaluwarsa, sinyal integritas yang tidak tersedia, dan pemulihan positif palsu. Memverifikasi hanya penolakan tanpa proses pemulihan menjebak pengguna nyata dalam keadaan yang tidak dapat diselesaikan.
Artikel ini tidak mengklaim bahwa teknologi pengerasan aplikasi saja dapat mencegah semua instalasi yang ditandatangani ulang. Tata kelola pengemasan ulang adalah upaya rekayasa sistem yang diselesaikan bersama oleh manajemen tanda tangan, kontrol pembaruan, manajemen artefak, ketahanan klien, sinyal platform, dan kebijakan sisi server.
- Identitas artefak resmi dapat diaudit secara independen
- Sertifikat anomali tidak dapat menutupi instalasi resmi secara diam-diam
- Server memiliki kebijakan berjenjang untuk klien yang tidak dikenal
- Pengguna dapat pulih ke saluran rilis tepercaya
- Paket rollback telah menyelesaikan validasi peningkatan sebelumnya
Batasan bukti dan penerapan
Bagian ini memisahkan fakta platform yang terdokumentasi, penilaian teknik, dan batasan yang tidak dapat digeneralisasikan ke dalam klaim produk yang belum diverifikasi.
| Penghakiman pasal | Dasar fakta atau rekayasa | Batas penerapan |
|---|---|---|
| Kemampuan instalasi paket yang ditandatangani ulang tidak menyamakan identitas penerbit resmi. | Android mensyaratkan APK memiliki tanda tangan yang dapat diverifikasi; penyerang dapat menghasilkan tanda tangan yang konsisten secara internal menggunakan kunci mereka sendiri pada konten yang dimodifikasi. | Kemampuan instalasi juga dipengaruhi oleh nama paket, kebijakan perangkat, versi OS, dan sumber instalasi; hasil sampel spesifik tidak dapat disimpulkan hanya dari prinsip desain. |
| Peningkatan overlay harus memverifikasi kontinuitas identitas tanda tangan. | Dokumentasi resmi Android menyatakan platform menggunakan kunci penandatanganan aplikasi untuk memastikan pembaruan berasal dari pemegang kunci yang sama. | Rotasi sertifikat dan aturan penandatanganan platform distribusi harus diverifikasi sesuai konfigurasi proyek. |
| Sinyal integritas platform harus divalidasi dan ditangani di backend. | Vonit Play Integrity mencakup pengenalan aplikasi, perangkat, akun, dan informasi lingkungan; pihak resmi merekomendasikan respons backend berdasarkan risiko. | Sinyal Play tidak mencakup semua negara, saluran, perangkat, atau skenario offline. |
| File pengiriman akhir harus berkorespondensi satu-ke-satu dengan bukti pengujian. | Pembangunan ulang, modifikasi sumber daya, atau penandatanganan ulang mengubah identitas artefak dan perilaku runtime potensial. | Digest file menetapkan asosiasi identitas tetapi tidak menyediakan kemampuan anti-tampering itu sendiri. |
| Kegagalan instalasi saja tidak membuktikan risiko pengemasan ulang telah ditutup. | Paket anomali mungkin masih menimbulkan risiko dengan mengubah nama paket, siklus uninstall-instal ulang, menggunakan saluran lain, atau mengeksploitasi kurangnya kebijakan versi sisi server. | Jalur serangan spesifik harus diverifikasi dalam lingkup pengujian yang diotorisasi terhadap arsitektur distribusi dan bisnis nyata. |
Pertanyaan teknik
Mengapa sistem tidak langsung menolak semua APK yang ditandatangani dengan sertifikat non-resmi?
Installer Android dapat memverifikasi apakah tanda tangan paket saat ini konsisten secara internal, namun sistem tidak mengetahui sertifikat mana yang diakui setiap merek. Identitas resmi harus ditentukan bersama oleh rantai peningkatan, platform distribusi, dan layanan bisnis.
Jika paket yang ditandatangani ulang tidak dapat melakukan peningkatan overlay, apakah tidak ada risiko?
Tidak. Penyerang mungkin masih menginduksi siklus uninstall-instal ulang, memodifikasi nama paket, atau mengeksploitasi hilangnya kebijakan versi sisi server untuk mengakses logika bisnis. Pencegahan peningkatan overlay hanyalah satu item dalam matriks tata kelola.
Apakah cukup bagi klien untuk membaca digest sertifikatnya sendiri?
Tidak. Klien yang dimodifikasi dapat secara simultan mengubah pemeriksaan lokal atau logika pelaporan. Informasi sertifikat dapat berpartisipasi dalam pertahanan berlapis, tetapi keputusan otorisasi berisiko tinggi harus dibuat oleh server dengan menggabungkan sinyal yang dapat diverifikasi.
Setelah rilis AAB, digest file mana yang harus disimpan?
Simpan identitas AAB yang diunggah, dan juga peroleh serta lakukan pemeriksaan acak pada artefak yang benar-benar dikirimkan dari platform distribusi. Perangkat berbeda mungkin menerima APK terpisah; menyimpan hanya APK generik yang dihasilkan secara lokal tidak cukup.
Kapan kesimpulan rilis dapat dibentuk?
Kesimpulan hanya dapat dibentuk untuk cakupan yang tercakup setelah identitas artefak bertanda tangan akhir ditetapkan, dan instalasi, peningkatan dari versi live, alur bisnis utama, kebijakan sisi server, rentang OS target, serta validasi rollback semuanya selesai.
Ingin mengujinya di aplikasi Anda sendiri?
Kirimkan kandidat rilis, sistem target, dan jalur bisnis penting untuk Yudun PoC dan penilaian kompatibilitas.
Lanjutkan dengan: Bagaimana cara menerima APK, DEX, dan menandatangani integritas bersama-sama