Google is committed to advancing racial equity for Black communities. See how.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

APK Signature Scheme v3

Android 9 mendukung rotasi kunci APK , yang memberi aplikasi kemampuan untuk mengubah kunci penandatanganannya sebagai bagian dari pembaruan APK. Untuk membuat 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.

Blok Penandatanganan APK

Untuk mempertahankan kompatibilitas mundur dengan format APK v1, tanda tangan APK v2 dan v3 disimpan di dalam Blok Penandatanganan APK, yang terletak tepat sebelum ZIP Central Directory.

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

APK Signature Scheme v3 Block

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

Namun, skema v3 menambahkan informasi tentang versi SDK yang didukung dan struct bukti rotasi.

Format

APK Signature Scheme v3 Block disimpan di dalam APK Signing Block dengan ID 0xf05368c0 .

Format Blokir APK Signature Scheme v3 mengikuti format v2:

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

Structs bukti rotasi dan sertifikat lama yang dipercaya sendiri

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

  • pernyataan untuk 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 proof-of-rotation dan self-trust-old-certs. Daftar ini diurutkan berdasarkan versi dengan sertifikat penandatanganan terlama yang sesuai dengan node root. Struktur data bukti rotasi dibangun dengan memiliki sertifikat di setiap node yang menandai berikutnya dalam daftar, dan dengan demikian menanamkan setiap kunci baru dengan bukti bahwa itu harus dipercaya seperti kunci yang lebih lama.

Struktur data self-trusted-old-certs dibangun dengan menambahkan tanda ke setiap node yang menunjukkan keanggotaan dan propertinya dalam set. Misalnya, mungkin ada tanda yang menunjukkan bahwa sertifikat penandatanganan pada node tertentu dipercaya untuk mendapatkan izin tanda tangan Android. Bendera ini memungkinkan aplikasi lain yang ditandatangani oleh sertifikat yang lebih lama untuk tetap diberi izin tanda tangan yang ditentukan oleh aplikasi yang ditandatangani dengan sertifikat penandatanganan baru. Karena seluruh atribut bukti rotasi berada di bagian data yang ditandatangani dari bidang signer v3, atribut ini dilindungi oleh kunci yang digunakan untuk menandatangani apk yang memuatnya.

Format ini menghalangi beberapa kunci penandatanganan dan konvergensi berbagai sertifikat penandatanganan induk 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 yang diawali panjang dari levels diawali dengan panjang:
    • signed data awalan panjang (dengan sertifikat sebelumnya - jika ada)
      • certificate X.509 dengan awalan panjang (formulir ASN.1 DER)
      • signature algorithm ID (uint32) - algoritma yang digunakan oleh cert di tingkat sebelumnya
    • flags (uint32) - flag yang menunjukkan apakah sertifikat ini harus ada dalam struct self-trusted-old-certs, dan untuk operasi apa.
    • signature algorithm ID (uint32) - harus cocok dengan salah satu dari bagian data yang ditandatangani di tingkat berikutnya.
    • signature awalan panjang di atas signed data atas

Beberapa sertifikat

Android saat ini memperlakukan APK yang ditandatangani dengan beberapa sertifikat sebagai memiliki identitas penandatanganan unik yang terpisah dari sertifikat pembentuknya. Dengan demikian, atribut bukti rotasi di bagian data bertanda membentuk grafik asiklik terarah, yang dapat lebih baik dilihat sebagai daftar tertaut tunggal, dengan setiap kumpulan penanda untuk versi tertentu mewakili satu node. Ini menambah kerumitan ekstra pada struct bukti rotasi (versi multi-penanda tangan di bawah). Secara khusus, pemesanan menjadi perhatian. Terlebih lagi, APK tidak dapat lagi ditandatangani 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 membuat penandatangan B hanya menyertakan tanda tangan oleh A atau B, karena itu adalah identitas penandatanganan yang berbeda dari B dan C. Ini akan berarti bahwa penandatangan harus berkoordinasi sebelum membangun struct semacam itu.

Atribut bukti rotasi penandatangan ganda

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

Beberapa leluhur dalam struct bukti-rotasi

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

Verifikasi

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

Proses verifikasi tanda tangan APK

Gambar 1. Proses verifikasi tanda tangan APK

Verifikasi APK Signature Scheme v3

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

Validasi

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