Skema Tanda Tangan APK v3

Android 9 mendukung rotasi kunci APK , yang memberi aplikasi kemampuan untuk mengubah kunci penandatanganannya sebagai bagian dari pembaruan APK. Agar rotasi menjadi praktis, APK harus menunjukkan tingkat kepercayaan antara kunci penandatanganan baru dan lama. Untuk mendukung rotasi kunci, kami memperbarui skema tanda tangan APK dari v2 ke v3 agar kunci baru dan lama dapat digunakan. V3 menambahkan informasi tentang versi SDK yang didukung dan struktur bukti rotasi ke blok penandatanganan APK.

Catatan : Rotasi kunci APK tidak disarankan sebelum rilis Android 11. Pengembang memiliki opsi untuk menggunakan peningkatan kunci Google Play untuk pemasangan baru. Pengembang yang terdaftar di Penandatanganan Aplikasi Play dapat meminta upgrade melalui konsol Play.

Blok Penandatanganan APK

Untuk menjaga kompatibilitas dengan format APK v1, tanda tangan APK v2 dan v3 disimpan di dalam Blok Penandatanganan APK, yang terletak tepat sebelum Direktori Pusat ZIP.

Format Blok Penandatanganan APK v3 sama dengan v2 . Tanda tangan v3 APK disimpan sebagai pasangan nilai ID dengan ID 0xf05368c0.

Blok Skema Tanda Tangan APK v3

Skema v3 dirancang sangat mirip dengan skema v2 . Ini memiliki format umum yang sama dan mendukung ID algoritma tanda tangan , ukuran kunci, dan kurva EC yang sama.

Namun, skema v3 menambahkan informasi tentang versi SDK yang didukung dan struktur proof-of-rotation.

Format

Blok Skema Tanda Tangan APK v3 disimpan di dalam Blok Penandatanganan APK di bawah ID 0xf05368c0 .

Format Blok APK Signature Scheme v3 mengikuti v2:

• urutan signer dengan awalan panjang:
  • signed data dengan awalan panjang :
    • urutan intisari dengan awalan panjang dari digests dengan awalan panjang :
      • signature algorithm ID (4 byte)
      • digest (awalan panjang)
    • urutan certificates X.509 dengan awalan panjang :
      • certificate X.509 dengan awalan panjang (formulir ASN.1 DER)
    • minSDK (uint32) - penandatangan ini harus diabaikan jika versi platform di bawah angka ini.
    • maxSDK (uint32) - penandatangan ini harus diabaikan jika versi platform di atas nomor ini.
    • urutan additional attributes dengan awalan panjang:
      • ID (uint32)
      • value (panjang variabel: panjang atribut tambahan - 4 byte)
      • ID - 0x3ba06f8c
      • value - Struktur bukti rotasi
  • minSDK (uint32) - duplikat nilai minSDK di bagian data yang ditandatangani - digunakan untuk melewati verifikasi tanda tangan ini jika platform saat ini tidak berada dalam jangkauan. Harus cocok dengan nilai data yang ditandatangani.
  • maxSDK (uint32) - duplikat nilai maxSDK di bagian data yang ditandatangani - digunakan untuk melewati verifikasi tanda tangan ini jika platform saat ini tidak berada dalam jangkauan. Harus cocok dengan nilai data yang ditandatangani.
  • urutan tanda tangan dengan awalan panjang dari signatures dengan awalan panjang :
    • signature algorithm ID (uint32)
    • signature dengan awalan panjang di atas signed data
  • public key dengan awalan panjang (SubjectPublicKeyInfo, formulir DER ASN.1)

Struktur bukti rotasi dan sertifikat lama yang dipercaya sendiri

Struktur bukti rotasi memungkinkan aplikasi untuk merotasi sertifikat penandatanganannya tanpa diblokir pada aplikasi lain yang berkomunikasi dengannya. Untuk mencapai hal ini, tanda tangan aplikasi berisi dua data baru:

• penegasan bagi pihak ketiga bahwa sertifikat penandatanganan aplikasi dapat dipercaya di mana pun pendahulunya dipercaya
• sertifikat penandatanganan lama aplikasi yang masih dipercaya oleh aplikasi itu sendiri

Atribut bukti rotasi di bagian data yang ditandatangani terdiri dari daftar tertaut tunggal, dengan setiap node berisi sertifikat penandatanganan yang digunakan untuk menandatangani versi aplikasi sebelumnya. Atribut ini dimaksudkan untuk memuat struktur data bukti rotasi konseptual dan sertifikat lama yang dapat dipercaya sendiri. Daftar ini diurutkan berdasarkan versi dengan sertifikat penandatanganan terlama yang sesuai dengan simpul akar. Struktur data proof-of-rotation dibangun dengan meminta sertifikat di setiap node menandatangani node berikutnya dalam daftar, dan dengan demikian memberikan setiap kunci baru dengan bukti bahwa kunci tersebut harus dipercaya seperti kunci lama.

Struktur data sertifikat lama yang dipercaya sendiri dibuat dengan menambahkan tanda ke setiap node yang menunjukkan keanggotaan dan propertinya dalam kumpulan. Misalnya, mungkin ada tanda yang menunjukkan bahwa sertifikat penandatanganan pada node tertentu dipercaya untuk mendapatkan izin tanda tangan Android. Tanda ini memungkinkan aplikasi lain yang ditandatangani dengan sertifikat lama tetap diberikan izin tanda tangan yang ditentukan oleh aplikasi yang ditandatangani dengan sertifikat penandatanganan baru. Karena seluruh atribut bukti rotasi berada di bagian data yang ditandatangani pada bidang signer v3, maka atribut tersebut dilindungi oleh kunci yang digunakan untuk menandatangani apk yang memuatnya.

Format ini menghalangi beberapa kunci penandatanganan dan konvergensi sertifikat penandatanganan leluhur yang berbeda menjadi satu (beberapa node awal ke sink umum).

Format

Bukti rotasi disimpan di dalam Blok APK Signature Scheme v3 dengan ID 0x3ba06f8c . Formatnya adalah:

• urutan dengan awalan panjang dari levels dengan awalan panjang :
  • signed data dengan awalan panjang (berdasarkan sertifikat sebelumnya - jika ada)
    • certificate X.509 dengan awalan panjang (formulir ASN.1 DER)
    • signature algorithm ID (uint32) - algoritma yang digunakan oleh sertifikat di level sebelumnya
  • flags (uint32) - flag yang menunjukkan apakah sertifikat ini harus berada dalam struct self-trusted-old-certs atau tidak, dan untuk operasi apa.
  • signature algorithm ID (uint32) - harus cocok dengan yang ada di bagian data yang ditandatangani di tingkat berikutnya.
  • signature dengan awalan panjang di atas signed data di atas

Banyak sertifikat

Android saat ini memperlakukan APK yang ditandatangani dengan beberapa sertifikat sebagai memiliki identitas penandatanganan unik yang terpisah dari sertifikat yang ada di dalamnya. Dengan demikian, atribut proof-of-rotation di bagian data yang ditandatangani membentuk grafik asiklik terarah, yang lebih baik dilihat sebagai daftar tertaut tunggal, dengan setiap kumpulan penanda tangan untuk versi tertentu mewakili satu node. Ini menambah kompleksitas ekstra pada struktur proof-of-rotation (versi multi-penanda tangan di bawah). Secara khusus, pemesanan menjadi perhatian. Terlebih lagi, penandatanganan APK tidak lagi mungkin dilakukan secara independen, karena struktur bukti rotasi harus memiliki sertifikat penandatanganan lama yang menandatangani kumpulan sertifikat baru, bukan menandatanganinya satu per satu. Misalnya, APK yang ditandatangani oleh kunci A yang ingin ditandatangani oleh dua kunci baru B dan C tidak boleh meminta penandatangan B hanya menyertakan tanda tangan dari A atau B, karena itu merupakan identitas penandatanganan yang berbeda dari B dan C. Hal ini akan berarti penandatangan harus berkoordinasi sebelum membangun struktur seperti itu.

Atribut bukti rotasi beberapa penandatangan

• barisan dengan awalan panjang dari sets dengan awalan panjang :
  • signed data (menurut set sebelumnya - jika ada)
    • urutan certificates dengan awalan panjang
      • certificate X.509 dengan awalan panjang (formulir ASN.1 DER)
    • Urutan signature algorithm IDs (uint32) - satu untuk setiap sertifikat dari kumpulan sebelumnya, dalam urutan yang sama.
  • flags (uint32) - flag yang menunjukkan apakah rangkaian sertifikat ini harus berada dalam struct self-trusted-old-certs, dan untuk operasi apa.
  • urutan tanda tangan dengan awalan panjang dari signatures dengan awalan panjang :
    • signature algorithm ID (uint32) - harus cocok dengan yang ada di bagian data yang ditandatangani
    • signature dengan awalan panjang di atas signed data di atas

Banyak leluhur dalam struktur bukti rotasi

Skema v3 juga tidak menangani dua kunci berbeda yang diputar ke kunci penandatanganan yang sama untuk aplikasi yang sama. Hal ini berbeda dengan kasus akuisisi, di mana perusahaan yang mengakuisisi ingin memindahkan aplikasi yang diakuisisi agar menggunakan kunci penandatanganannya untuk berbagi izin. Akuisisi ini dipandang sebagai kasus penggunaan yang didukung karena aplikasi baru akan dibedakan berdasarkan nama paketnya dan dapat berisi struktur bukti rotasinya sendiri. Kasus yang tidak didukung, yaitu aplikasi yang sama memiliki dua jalur berbeda untuk mendapatkan sertifikat yang sama, mematahkan banyak asumsi yang dibuat dalam desain rotasi kunci.

Verifikasi

Di Android 9 dan lebih tinggi, APK dapat diverifikasi berdasarkan APK Signature Scheme v3, v2 skema, atau v1 skema. Platform lama mengabaikan tanda tangan v3 dan mencoba memverifikasi tanda tangan v2, lalu v1.

Gambar 1. Proses verifikasi tanda tangan APK

Verifikasi APK Skema Tanda Tangan v3

1. Temukan Blok Penandatanganan APK dan verifikasi bahwa:
   1. Dua bidang ukuran Blok Penandatanganan APK berisi nilai yang sama.
   2. Direktori Pusat ZIP segera diikuti oleh catatan ZIP Akhir Direktori Pusat.
   3. ZIP Akhir Direktori Pusat tidak diikuti oleh data lainnya.
2. Temukan Blok APK Signature Scheme v3 pertama di dalam Blok Penandatanganan APK. Jika Blok v3 ada, lanjutkan ke langkah 3. Jika tidak, kembali memverifikasi APK menggunakan skema v2 .
3. Untuk setiap signer di Blok APK Signature Scheme v3 dengan versi SDK min dan maks yang berada dalam jangkauan platform saat ini:
   1. Pilih signature algorithm ID terkuat yang didukung dari signatures . Urutan kekuatan tergantung pada setiap versi implementasi/platform.
   2. Verifikasi signature yang sesuai dari signatures terhadap signed data menggunakan public key . (Sekarang aman untuk mengurai signed data .)
   3. Verifikasikan versi SDK min dan max dalam data yang ditandatangani cocok dengan yang ditentukan untuk signer .
   4. Verifikasi bahwa daftar urutan ID algoritma tanda tangan dalam digests dan signatures adalah identik. (Ini untuk mencegah pengupasan/penambahan tanda tangan.)
   5. Hitung intisari konten APK menggunakan algoritma intisari yang sama dengan algoritma intisari yang digunakan oleh algoritma tanda tangan.
   6. Verifikasi bahwa intisari yang dihitung identik dengan digest yang sesuai dari digests .
   7. Verifikasi bahwa certificates certificate identik dengan public key .
   8. Jika atribut proof-of-rotation ada untuk signer , verifikasi bahwa struct tersebut valid dan signer ini adalah sertifikat terakhir dalam daftar.
4. Verifikasi berhasil jika tepat satu signer ditemukan dalam jangkauan platform saat ini dan langkah 3 berhasil untuk signer tersebut.

Perhatian : APK tidak boleh diverifikasi menggunakan skema v1 atau v2 jika terjadi kegagalan pada langkah 3 atau 4.

Validasi

Untuk menguji apakah perangkat Anda mendukung v3 dengan benar, jalankan pengujian CTS PkgInstallSignatureVerificationTest.java di cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .