Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Skema Tanda Tangan APK v3

Android 9 mendukung rotasi kunci APK , yang memberi aplikasi kemampuan untuk mengubah kunci penandatanganannya sebagai bagian dari pembaruan APK. Untuk membuat rotasi 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 untuk memungkinkan kunci baru dan lama digunakan. V3 menambahkan informasi tentang versi SDK yang didukung dan struct proof-of-rotation ke blok penandatanganan APK.

Blok Penandatanganan APK

Untuk menjaga kompatibilitas mundur 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.

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 proof-of-rotation.

Format

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

Format APK Signature Scheme v3 Block mengikuti format v2:

  • urutan penanda dengan awalan panjang dari signer dengan awalan panjang :
    • signed data dengan awalan panjang :
      • urutan awalan panjang dari digests awalan panjang :
        • signature algorithm ID (4 byte)
        • digest (panjang-diawali)
      • urutan awalan panjang dari 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 angka ini.
      • maxSDK (uint32) - penanda tangan ini harus diabaikan jika versi platform di atas angka ini.
      • urutan awalan panjang dari additional attributes 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 dalam jangkauan. Harus cocok 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 cocok dengan nilai data yang ditandatangani.
    • urutan 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 ASN.1 DER)

Struktur bukti rotasi dan sertifikat lama yang dapat dipercaya sendiri

Struktur bukti rotasi memungkinkan aplikasi untuk memutar sertifikat penandatanganan mereka tanpa diblokir pada aplikasi lain yang mereka gunakan untuk berkomunikasi. Untuk mencapai ini, tanda tangan aplikasi berisi dua bagian data baru:

  • pernyataan untuk pihak ketiga bahwa sertifikat penandatanganan aplikasi dapat dipercaya dimanapun pendahulunya dipercaya
  • sertifikat penandatanganan aplikasi yang lebih lama yang masih dipercaya oleh aplikasi itu sendiri

Atribut proof-of-rotation 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 berisi bukti-rotasi konseptual dan struktur data self-trusted-old-certs. Daftar diurutkan berdasarkan versi dengan sertifikat penandatanganan tertua yang sesuai dengan simpul akar. Struktur data proof-of-rotation dibangun dengan membuat sertifikat di setiap node menandatangani yang berikutnya dalam daftar, dan dengan demikian menambahkan setiap kunci baru dengan bukti bahwa itu harus dipercaya seperti kunci yang lebih lama.

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

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 Skema Tanda Tangan APK v3 di bawah ID 0x3ba06f8c . Formatnya adalah:

  • urutan awalan panjang dari levels 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 salah satu dari bagian data yang ditandatangani di tingkat berikutnya.
    • signature dengan awalan panjang di atas signed data di atas

Beberapa sertifikat

Android saat ini memperlakukan APK yang ditandatangani dengan beberapa sertifikat sebagai memiliki identitas penandatanganan unik yang terpisah dari sertifikat penyusunnya. Dengan demikian, atribut proof-of-rotation di bagian data bertanda membentuk grafik asiklik terarah, yang dapat lebih baik dilihat sebagai daftar tertaut tunggal, dengan setiap set penanda untuk versi tertentu mewakili satu simpul. Ini menambah kerumitan ekstra pada struct proof-of-rotation (versi multi-penanda tangan di bawah). Secara khusus, pemesanan menjadi perhatian. Terlebih lagi, tidak mungkin lagi menandatangani APK secara mandiri, karena struktur proof-of-rotation harus memiliki sertifikat penandatanganan lama yang menandatangani kumpulan sertifikat baru, daripada menandatanganinya satu per satu. Misalnya, APK yang ditandatangani oleh kunci A yang ingin ditandatangani oleh dua kunci baru B dan C tidak dapat membuat penanda tangan B hanya menyertakan tanda tangan oleh A atau B, karena itu adalah identitas penandatanganan yang berbeda dari B dan C. Ini akan berarti penandatangan harus berkoordinasi sebelum membangun struktur tersebut.

Atribut bukti rotasi banyak penanda tangan

  • urutan awalan panjang dari sets awalan panjang :
    • signed data (dengan 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 set sebelumnya, dalam urutan yang sama.
    • flags (uint32) - flag yang menunjukkan apakah kumpulan sertifikat ini harus berada dalam struct sertifikat lama yang terpercaya atau tidak, dan untuk operasi apa.
    • urutan 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 berputar ke kunci penandatanganan yang sama untuk aplikasi yang sama. Ini berbeda dari kasus akuisisi, di mana perusahaan yang mengakuisisi ingin memindahkan aplikasi yang diakuisisi untuk 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 struct proof-of-rotation-nya sendiri. Kasus yang tidak didukung, dari aplikasi yang sama yang memiliki dua jalur berbeda untuk mendapatkan sertifikat yang sama, mematahkan banyak asumsi yang dibuat dalam desain rotasi kunci.

Verifikasi

Di Android 9 dan yang lebih tinggi, APK dapat diverifikasi menurut Skema Tanda Tangan APK 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 Blok Penandatanganan APK dan verifikasi bahwa:
    1. Dua bidang ukuran Blok Penandatanganan APK berisi nilai yang sama.
    2. ZIP Central Directory segera diikuti oleh ZIP End of Central Directory record.
    3. ZIP End of Central Directory tidak diikuti oleh lebih banyak data.
  2. Temukan Blok Skema Tanda Tangan APK v3 pertama di dalam Blok Penandatanganan APK. Jika Blok v3 ada, lanjutkan ke langkah 3. Jika tidak, kembali ke verifikasi APK menggunakan skema v2 .
  3. Untuk setiap signer di APK Signature Scheme v3 Block dengan versi SDK min dan maks yang berada dalam jangkauan platform saat ini:
    1. Pilih signature algorithm ID didukung terkuat dari signatures . Urutan kekuatan tergantung pada setiap versi implementasi/platform.
    2. Verifikasi tanda tangan yang sesuai dari signature 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 berurutan ID algoritme tanda tangan dalam digests dan signatures adalah 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 digests digest
    7. Pastikan bahwa SubjectPublicKeyInfo dari certificate certificates 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.

Validasi

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