APK signature scheme v3.2

Android 17 (level API 37) memperkenalkan APK Signature Scheme v3.2, skema tanda tangan hybrid yang dirancang untuk mendukung transisi ekosistem Android ke kriptografi pasca-kuantum (PQC).

Saat industri men-deploy algoritma PQC dalam skala besar, skema v3.2 memberikan pertahanan mendalam. Skema ini mengharuskan Anda menandatangani APK dengan algoritma klasik, seperti RSA atau ECDSA, dan algoritma PQC. Pendekatan hybrid ini menggunakan kriptografi klasik untuk melindungi APK Anda sekaligus mempertahankan diri dari ancaman komputer kuantum.

Tujuan dan detail

Skema v3.2 beroperasi sebagai mekanisme transisi standar yang selaras dengan industri. Dengan pendekatan hybrid ini, Anda mendapatkan manfaat tahan kuantum dari PQC sekaligus terus mengandalkan keamanan algoritma tanda tangan klasik yang terbukti. Setelah algoritma PQC yang baru distandardisasi menetapkan kematangan operasional dalam skala besar, Anda dapat bertransisi dari konfigurasi hybrid ini ke kunci penandatanganan PQC tunggal. Dukungan platform untuk skema tanda tangan v3.2 dimulai dengan Android 17. Versi Android yang lebih rendah akan melewati blok v3.2 dan menggunakan skema sebelumnya untuk verifikasi tanda tangan.

Untuk mempertahankan keamanan dan mencegah serangan downgrade selama transisi ini, skema v3.2 menerapkan perilaku berikut:

  • Materi kunci baru: Transisi ke blok hybrid memerlukan pembuatan kunci klasik dan PQC baru. Jangan gunakan kembali materi kunci antara konfigurasi hybrid dan non-hybrid.
  • Rotasi implisit: Platform memperlakukan blok hybrid sebagai rotasi kunci implisit. Platform menambahkan kunci klasik baru ke silsilah penandatanganan aplikasi yang ada sebagai kunci kedua dari terakhir, dan memperlakukan kunci PQC baru sebagai identitas penandatanganan aplikasi saat ini.
  • Silsilah bersama: Untuk berhasil menjalankan rotasi implisit, kunci klasik baru dan kunci PQC baru dalam blok hybrid harus memiliki silsilah penandatanganan yang sama. Anda harus menduplikasi histori penandatanganan aplikasi yang ada—baik kunci asli tunggal maupun silsilah kunci yang dirotasi sebelumnya—untuk kedua penanda tangan hybrid baru. Platform menggunakan silsilah bersama ini untuk memverifikasi bahwa entitas yang mentransisikan aplikasi ke skema hybrid adalah pemilik sah identitas penandatanganan aplikasi saat ini.
  • Batasan penanda tangan tunggal PQC: Selama peluncuran awal PQC, Android secara eksplisit membatasi penggunaan algoritma PQC ke blok hybrid v3.2. Platform tidak memverifikasi konfigurasi PQC penanda tangan tunggal menggunakan skema tanda tangan sebelumnya, seperti v2, v3.0, atau v3.1.
  • Bertransisi kembali: Saat bertransisi dari blok hybrid v3.2 kembali ke blok penanda tangan tunggal—baik penanda tangan klasik maupun penanda tangan PQC jika didukung dalam rilis mendatang—platform akan memverifikasi bahwa kunci klasik dan PQC dari blok hybrid ada dalam silsilah penandatanganan baru dan membuktikan penanda tangan tunggal baru.

Praktik terbaik untuk transisi

Untuk mempertahankan kompatibilitas dengan versi Android yang lebih rendah dan menyediakan jalur upgrade yang aman selama transisi ke penandatanganan PQC, APK harus terus menyertakan blok tanda tangan v3.0 atau v3.1 standar yang ditandatangani oleh kunci klasik tunggal. Karena hanya Android 17 (level API 37) dan yang lebih tinggi yang mendukung skema hybrid v3.2, persyaratan ini memungkinkan perangkat yang menjalankan versi lebih rendah untuk memverifikasi dan menginstal aplikasi.

Konfigurasi penggantian klasik

Untuk menyediakan jaring pengaman operasional selama transisi PQC, terapkan konfigurasi penggantian klasik.

  • Aplikasi yang ada: Kunci penandatanganan yang ditetapkan saat ini, K0, berfungsi sebagai dasar alami untuk penggantian ini.
  • Aplikasi baru: Buat kunci penandatanganan klasik dasar, K0, bersama kunci hybrid baru, C_K1 dan PQC_K1, untuk menetapkan identitas awal.

Dalam kedua skenario tersebut, APK harus menyertakan blok tanda tangan v3.0 atau v3.1 standar yang ditandatangani oleh kunci klasik, K0, bersama blok hybrid v3.2 yang ditandatangani oleh kunci hybrid baru, C_K1 dan PQC_K1.

Selama deployment awal skema v3.2, silsilah penandatanganan untuk blok hybrid harus memberikan kemampuan ROLLBACK ke K0. Jika terjadi masalah deployment, kemampuan ini memungkinkan aplikasi kembali ke tanda tangan klasik tanpa mengganggu update pengguna. Setelah data runtime yang memadai mengonfirmasi bahwa deployment hybrid stabil, sebaiknya hapus kemampuan ROLLBACK dalam update berikutnya untuk mengamankan kunci baru Anda sepenuhnya.

Persyaratan konfigurasi jangka panjang

Anda harus mempertahankan konfigurasi penandatanganan hybrid ini selama aplikasi Anda menargetkan rilis platform yang secara eksklusif mendukung skema hybrid. Meskipun versi platform mendukung kunci PQC penanda tangan tunggal, Anda harus menandatangani APK apa pun yang menargetkan rilis yang memerlukan blok hybrid v3.2 dengan kedua kunci.

Blok skema tanda tangan APK v3.2

Blok Penandatanganan APK menyimpan blok tanda tangan v3.2 bersama blok tanda tangan v2, v3.0, dan v3.1.

Struktur blok v3.2 mirip dengan v3.0, tetapi menggunakan ID blok baru, 0x70e1c89f, untuk menandakan bahwa blok tersebut adalah blok hybrid. Blok v3.2 yang valid harus berisi tepat dua penanda tangan.

Algoritma yang didukung

Skema v3.2 awalnya mendukung algoritma tanda tangan PQC berikut:

  • ML-DSA-65
  • ML-DSA-87

Algoritma ini dipasangkan dengan algoritma tanda tangan klasik standar, seperti yang didukung di v3.0 dan v3.1, untuk membentuk blok hybrid.

Format

Blok Penandatanganan APK menyimpan blok APK Signature Scheme v3.2 dengan ID 0x70e1c89f.

Format blok v3.2 identik dengan v3.0, tetapi urutan elemen penanda tangan tingkat atas harus berisi tepat dua entri yang menargetkan versi SDK yang sama:

  • length-prefixed sequence of length-prefixed signer:
    • length-prefixed signer (Classical)
    • length-prefixed signer (PQC)

Setiap penanda tangan menggunakan format v3 standar:

  • length-prefixed signed data:
    • length-prefixed sequence of length-prefixed digests:
    • signature algorithm ID (4 bytes)
    • digest (length-prefixed)
    • length-prefixed sequence of certificates:
    • length-prefixed X.509 certificate (ASN.1 DER form)
    • minSDK (uint32)
    • maxSDK (uint32)
    • length-prefixed sequence of length-prefixed additional attributes:
    • ID (uint32)
    • value (variable-length: length of the additional attribute - 4 bytes)
  • minSDK (uint32)
  • maxSDK (uint32)
  • length-prefixed sequence of length-prefixed signatures:
    • signature algorithm ID (4 bytes)
    • length-prefixed signature over signed data
  • length-prefixed public key (SubjectPublicKeyInfo, ASN.1 DER form)

Verifikasi

Di Android 17 (level API 37) dan yang lebih tinggi, untuk memverifikasi tanda tangan v3.2, platform akan memverifikasi penanda tangan klasik dan PQC, mengonfirmasi kompatibilitasnya, dan memeriksa silsilah rotasi implisit. Pada rilis platform Android 16 (level API 36) dan yang lebih rendah, platform tidak memproses blok tanda tangan hybrid ini dan menggunakan skema sebelumnya.

Keseluruhan prosesnya adalah sebagai berikut:

  1. Temukan Blok APK Signature Scheme v3.2 (ID 0x70e1c89f).
  2. Pastikan blok berisi tepat dua penanda tangan. Jika ada kurang atau lebih dari dua, verifikasi akan gagal.
  3. Pastikan satu penanda tangan menggunakan algoritma tanda tangan klasik dan penanda tangan lainnya menggunakan algoritma tanda tangan PQC. Jika keduanya klasik atau keduanya PQC, verifikasi akan gagal.
  4. Pastikan kedua penanda tangan menargetkan rentang SDK yang sama persis (minSdkVersion dan maxSdkVersion).
  5. Untuk setiap penanda tangan, lakukan verifikasi v3 standar:
    1. Pilih ID algoritma tanda tangan terkuat yang didukung dari tanda tangan.
    2. Verifikasi tanda tangan yang sesuai dari tanda tangan terhadap data yang ditandatangani menggunakan kunci publik.
    3. Pastikan minSdkVersion dan maxSdkVersion dalam data yang ditandatangani cocok dengan minSdkVersion dan maxSdkVersion yang tidak ditandatangani.
    4. Mengurai sertifikat dan memverifikasi bahwa sertifikat pertama cocok dengan kunci publik.
    5. Mengurai atribut tambahan untuk mengekstrak struktur bukti rotasi.
  6. Verifikasi histori penandatanganan (bukti rotasi):
    1. Periksa apakah kedua penanda tangan memiliki histori penandatanganan sebelumnya yang identik.
    2. Panjang silsilah harus cocok, dan semua sertifikat serta flag kemampuan yang mengarah ke penanda tangan saat ini harus identik.
    3. Jika histori cocok, gabungkan silsilah: perlakukan sertifikat penanda tangan klasik sebagai pendahulu sertifikat penanda tangan PQC, dan tetapkan penanda tangan PQC sebagai node terminal saat ini.
  7. Verifikasi Ringkasan Konten:
    1. Ulangi peta ringkasan untuk kedua penanda tangan.
    2. Pastikan bahwa untuk algoritma ringkasan yang cocok, nilai ringkasan yang dihitung identik antara penanda tangan klasik dan PQC.
  8. Gunakan ringkasan yang cocok dari penanda tangan yang diverifikasi untuk memverifikasi integritas konten APK (mirip dengan v2 dan v3).
    1. Jika aplikasi sudah diinstal, verifikasi silsilah update paket:
    2. Mengupdate dari penanda tangan tunggal: Jika aplikasi terinstal ditandatangani dengan kunci klasik tunggal, kunci tersebut harus ada dalam silsilah penandatanganan blok hybrid baru sebagai pendahulu penanda tangan hybrid.
    3. Mengupdate dari signer hybrid untuk melanjutkan hybrid: Jika aplikasi terinstal ditandatangani dengan blok hybrid v3.2, kunci klasik dan PQC sebelumnya harus tetap menjadi signer aktif saat ini di blok v3.2 APK update, atau keduanya harus ada dalam silsilah (data) penandatanganan baru yang membuktikan kunci hybrid yang baru dirotasi.
    4. Bertransisi dari penanda tangan hybrid: Jika aplikasi yang diinstal ditandatangani dengan blok hybrid v3.2 dan APK update bertransisi kembali ke penanda tangan tunggal (baik PQC maupun klasik), kedua penanda tangan hybrid sebelumnya harus ada dalam silsilah penandatanganan APK update dan membuktikan kunci penandatanganan tunggal baru.
    5. Jalur update yang tidak valid: Jika developer mencoba mengupdate aplikasi yang ditandatangani hybrid menggunakan hanya salah satu kunci hybrid sebagai penanda tangan tunggal tanpa rotasi yang tepat, update akan gagal. Kedua kunci harus secara eksplisit terlibat dalam transisi apa pun untuk mencegah serangan downgrade.
  9. Jika ada langkah yang gagal, verifikasi akan gagal.

Perlindungan penghapusan

Untuk mencegah serangan downgrade ke skema tanda tangan yang lebih rendah, skema v3.2 menyertakan atribut perlindungan penghapusan yang mirip dengan iterasi skema sebelumnya.

Alat penandatanganan menulis dua atribut perlindungan penghapusan hybrid tertentu ke dalam atribut tambahan blok tanda tangan v3.0 dan v3.1. Atribut ini menentukan batas versi SDK yang tepat dalam blok hybrid v3.2 harus ada dan diverifikasi:

  • Atribut versi SDK minimum (ID 0xbf940529): Nilai atribut ini menentukan versi SDK minimum yang didukung oleh blok penandatanganan hybrid.
  • Atribut versi SDK maksimum (ID 0x9f06b79c): Nilai atribut ini menentukan versi SDK maksimum yang didukung oleh blok penandatanganan hybrid. Atribut ini memungkinkan Anda bertransisi ke konfigurasi penanda tangan tunggal saat rilis platform yang lebih tinggi tidak memerlukan tanda tangan hybrid.

Jika platform melewati verifikasi v3.2 karena blok tidak ada atau rentang SDK-nya tidak berlaku untuk perangkat, platform akan memverifikasi APK terhadap blok berikutnya yang ada. Jika blok sebelumnya berisi atribut perlindungan penghapusan ini, platform akan menerapkan pemeriksaan berikut:

  • Verifikasi keberadaan dan rentang: Jika blok tanda tangan v3.0 atau v3.1 berisi atribut SDK minimum (ID 0xbf940529, nilai X) atau atribut SDK maksimum (ID 0x9f06b79c, nilai Y), platform akan mewajibkan blok hybrid v3.2 ada dalam APK. Platform membaca blok hybrid untuk memverifikasi bahwa rentang SDK targetnya cocok dengan batas yang ditentukan oleh atribut ini. Jika blok v3.2 tidak ada, atau jika nilai target SDK minimum dan maksimum internalnya tidak sama dengan X dan Y, platform akan menolak penginstalan.
  • Penerapan dalam rentang: Jika versi SDK perangkat berada dalam rentang valid yang ditentukan oleh atribut ini—yang lebih besar dari atau sama dengan X, dan kurang dari atau sama dengan Y saat Anda memberikan atribut maksimum—platform akan mewajibkan blok hybrid v3.2 untuk verifikasi tanda tangan. Jika platform memverifikasi blok v3.0 atau v3.1 di perangkat dalam rentang SDK target ini, platform akan menolak penginstalan karena blok v3.2 dilewati atau dihapus secara berbahaya.

Dengan menerapkan batas ini, platform akan menentukan kapan APK harus berisi blok v3.2. Jika blok telah dihapus, platform akan menolak penginstalan untuk mencegah serangan downgrade.

Memvalidasi penerapan

Untuk menguji penerapan skema tanda tangan v3.2, jalankan pengujian CTS HybridSignatureVerificationTest.java yang terletak di cts/hostsidetests/appsecurity/src/android/appsecurity/cts/.

Pengujian ini mencakup rangkaian skenario yang komprehensif, termasuk penginstalan yang berhasil, update dari versi khusus klasik, transisi rollback menggunakan kemampuan ROLLBACK, dan verifikasi mitigasi serangan penghapusan.