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

Hak Istimewa Operator UICC

Android 5.1 memperkenalkan mekanisme untuk memberikan hak istimewa khusus untuk API yang relevan dengan pemilik aplikasi kartu sirkuit terpadu universal (UICC). Platform Android memuat sertifikat yang disimpan di UICC dan memberikan izin ke aplikasi yang ditandatangani oleh sertifikat ini untuk melakukan panggilan ke beberapa API khusus.

Android 7.0 memperluas fitur ini untuk mendukung sumber penyimpanan lain untuk aturan hak istimewa operator UICC, secara dramatis meningkatkan jumlah operator yang dapat menggunakan API. Untuk referensi API, lihat CarrierConfigManager ; untuk petunjuk, lihat pembawa Konfigurasi .

Operator memiliki kontrol penuh atas UICC, sehingga mekanisme ini menyediakan cara yang aman dan fleksibel untuk mengelola aplikasi dari operator jaringan seluler (MNO) yang dihosting di saluran distribusi aplikasi generik (seperti Google Play) sambil mempertahankan hak istimewa khusus pada perangkat dan tanpa perlu untuk menandatangani aplikasi dengan sertifikat platform per perangkat atau melakukan prainstal sebagai aplikasi sistem.

Aturan di UICC

Penyimpanan pada UICC kompatibel dengan GlobalPlatform Elemen Aman Access Control spesifikasi . Aplikasi identifier (AID) pada kartu A00000015141434C00 , dan standar GET DATA perintah digunakan untuk mengambil aturan yang tersimpan pada kartu. Anda dapat memperbarui aturan ini melalui pembaruan kartu over-the-air (OTA).

Hirarki data

Aturan UICC menggunakan hierarki data berikut (kombinasi dua karakter huruf dan angka dalam tanda kurung adalah tag objek). Setiap aturan adalah REF-AR-DO ( E2 ) dan terdiri dari gabungan dari REF-DO dan AR-DO :

  • REF-DO ( E1 ) mengandung DeviceAppID-REF-DO atau gabungan dari DeviceAppID-REF-DO dan PKG-REF-DO .
    • DeviceAppID-REF-DO ( C1 ) menyimpan SHA-1 (20 byte) atau SHA-256 (32 bytes) tanda tangan sertifikat.
    • PKG-REF-DO ( CA ) adalah nama lengkap paket string yang didefinisikan dalam manifest, ASCII dikodekan, max panjang 127 bytes.
  • AR-DO ( E3 ) yang diperluas untuk mencakup PERM-AR-DO ( DB ), yang merupakan bit masker 8-byte mewakili 64 perizinan yang terpisah.

Jika PKG-REF-DO tidak hadir, setiap aplikasi yang ditandatangani oleh sertifikat yang diberikan akses; jika tidak, sertifikat dan nama paket harus cocok.

Contoh aturan

Nama aplikasi adalah com.google.android.apps.myapp dan sertifikat SHA-1 di hex string:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

Aturan pada UICC dalam string hex adalah:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

Dukungan file aturan akses (ARF)

Android 7.0 menambahkan dukungan untuk membaca aturan hak istimewa operator dari file aturan akses (ARF).

Upaya pertama platform Android untuk memilih aturan akses applet (ARA) aplikasi identifier (AID) A00000015141434C00 . Jika tidak menemukan AID di UICC, ia jatuh kembali ke ARF dengan memilih PKCS15 AID A000000063504B43532D3135 . Android kemudian membaca file aturan akses kontrol (ACRF) di 0x4300 dan terlihat untuk entri dengan AID FFFFFFFFFFFF . Entri dengan AID yang berbeda akan diabaikan, sehingga aturan untuk kasus penggunaan lain dapat hidup berdampingan.

Contoh konten ACRF dalam string hex:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

Contoh konten file kondisi kontrol akses (ACCF):

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

Dalam contoh di atas, 0x4310 adalah alamat untuk ACCF, yang berisi sertifikat hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Aplikasi yang ditandatangani oleh sertifikat ini diberikan hak istimewa operator.

API yang diaktifkan

Android mendukung API berikut.

Manajer Telepon

Manajer SMS

Metode untuk memungkinkan penelpon untuk membuat pesan SMS yang masuk baru: injectSmsPdu .

CarrierConfigManager

Metode untuk memberitahu konfigurasi berubah: notifyConfigChangedForSubId . Untuk petunjuk, lihat pembawa Konfigurasi .

Layanan Pesan Operator

Layanan yang menerima panggilan dari sistem saat SMS dan MMS baru dikirim atau diterima. Untuk memperpanjang kelas ini, menyatakan layanan di file manifest Anda dengan android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE izin dan mencakup filter maksud dengan #SERVICE_INTERFACE tindakan. Metode meliputi:

Penyedia telepon

API penyedia konten untuk memungkinkan modifikasi (menyisipkan, menghapus, memperbarui, membuat kueri) ke database telepon. Bidang nilai-nilai yang didefinisikan pada Telephony.Carriers ; untuk lebih jelasnya, lihat Telephony API referensi pada developer.android.com.

platform Android

Pada UICC yang terdeteksi, platform membuat objek UICC internal yang menyertakan aturan hak istimewa operator sebagai bagian dari UICC. UiccCarrierPrivilegeRules.java beban aturan, mem-parsing mereka dari kartu UICC, dan cache dalam memori. Ketika cek hak istimewa yang dibutuhkan, UiccCarrierPrivilegeRules membandingkan sertifikat pemanggil dengan aturan sendiri satu per satu. Jika UICC dihapus, aturan akan dihancurkan bersama dengan objek UICC.

Validasi

Untuk memvalidasi pelaksanaan melalui Uji Kompatibilitas Suite (CTS) menggunakan CtsCarrierApiTestCases.apk , Anda harus memiliki UICC pengembang dengan aturan UICC benar atau dukungan ARF. Anda dapat meminta vendor kartu SIM pilihan Anda untuk menyiapkan UICC pengembang dengan ARF yang tepat seperti yang dijelaskan di bagian ini dan menggunakan UICC tersebut untuk menjalankan pengujian. UICC tidak memerlukan layanan seluler aktif untuk lulus tes CTS.

Mempersiapkan UICC

Untuk Android 11 dan bawah, CtsCarrierApiTestCases.apk ditandatangani oleh aosp-testkey , dengan nilai hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Mulai di Android 12, CtsCarrierApiTestCases.apk ditandatangani oleh cts-uicc-2021-testkey nilai hash CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0 .

Untuk menjalankan CTS tes pembawa API di Android 12, perangkat harus menggunakan SIM dengan hak operator CTS memenuhi persyaratan yang ditentukan dalam versi terbaru dari pihak ketiga GSMA TS.48 Uji Profil spesifikasi.

SIM yang sama juga dapat digunakan untuk versi sebelum Android 12.

Memodifikasi Profil SIM CTS

  1. Menambahkan: CTS Pembawa Keistimewaan di ARA-M atau ARF. Kedua tanda tangan harus dikodekan dalam aturan hak istimewa operator:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1 :94:A8:2C:9B:F1:5D:49:2A:A0
  1. Buat: ADF USIM EF tidak hadir dalam TS.48 dan diperlukan untuk CTS:
    1. EF_MBDN (6FC7), Ukuran Rekaman: 28, Nomor rekaman: 4
      • Isi
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), Ukuran rekaman:13, Nomor rekaman: 1
      • Konten: 00FF…FF
        1. EF_MBI (6FC9), Ukuran Rekaman: 4, Nomor rekaman: 1
      • Konten: Rec1: 01010101
        1. EF_MWIS (6FCA), Ukuran Rekaman: 5, Nomor rekaman: 1
      • Isi: 00000000000
  2. Modify: USIM Jasa Tabel: Aktifkan Layanan n ° 47, n ° 48
    1. EF_UST (6F38)
      • Konten: 9EFFBF1DFFFE0083410310010400406E01
  3. Modifikasi: DF-5Gs dan DF-SAIP Files
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Konten: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Konten: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Konten: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Konten: A0020000FF…FF
  4. Memodifikasi: Pembawa Nama string akan Android CTS di EF masing berisi penunjukan ini:
    1. EF_SPN (USIM/6F46)
      • Konten: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Konten: Rec1 430B83413759FE4E934143EA14FF..FF

Mencocokkan struktur profil uji

Download dan mencocokkan versi terbaru dari tes generik struktur profil berikut. Profil ini tidak akan memiliki aturan Hak Istimewa Operator CTS yang dipersonalisasi atau modifikasi lain yang tercantum di atas.

Menjalankan tes

Untuk kenyamanan, CTS mendukung token perangkat yang membatasi pengujian untuk dijalankan hanya pada perangkat yang dikonfigurasi dengan token yang sama. Tes pembawa API CTS mendukung perangkat tanda sim-card-with-certs . Sebagai contoh, berikut perangkat tanda tes API Membatasi operator untuk hanya berjalan pada perangkat abcd1234 :

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

Saat menjalankan pengujian tanpa menggunakan token perangkat, pengujian berjalan di semua perangkat.

FAQ

Bagaimana sertifikat dapat diperbarui di UICC?

A: Gunakan mekanisme pembaruan OTA kartu yang ada.

Bisakah UICC hidup berdampingan dengan aturan lain?

J: Tidak apa-apa untuk memiliki aturan keamanan lain di UICC di bawah AID yang sama; platform menyaringnya secara otomatis.

Apa yang terjadi ketika UICC dihapus untuk aplikasi yang bergantung pada sertifikat di dalamnya?

J: Aplikasi kehilangan hak istimewanya karena aturan yang terkait dengan UICC dihancurkan pada penghapusan UICC.

Apakah ada batasan jumlah sertifikat di UICC?

J: Platform tidak membatasi jumlah sertifikat; tetapi karena pemeriksaannya linier, terlalu banyak aturan dapat menimbulkan latensi untuk pemeriksaan.

Apakah ada batasan jumlah API yang dapat kami dukung dengan metode ini?

J: Tidak, tetapi kami membatasi cakupan untuk API terkait operator.

Apakah ada beberapa API yang dilarang menggunakan metode ini? Jika demikian, bagaimana Anda menegakkan mereka? (yaitu, apakah Anda memiliki tes untuk memvalidasi API mana yang didukung dengan metode ini?)

A: Lihat "API Perilaku Kompatibilitas" bagian dari Definisi Dokumen Android Compatibility (CDD) . Kami memiliki beberapa pengujian CTS untuk memastikan bahwa model izin API tidak diubah.

Bagaimana cara kerjanya dengan fitur multi-SIM?

J: SIM default yang ditentukan oleh pengguna digunakan.

Apakah ini berinteraksi atau tumpang tindih dengan teknologi akses SE lainnya, misalnya, SEEK?

J: Sebagai contoh, SEEK menggunakan AID yang sama seperti pada UICC. Jadi aturan hidup berdampingan dan disaring oleh salah SEEK atau UiccCarrierPrivileges .

Kapan saat yang tepat untuk memeriksa hak istimewa operator?

A: Setelah status SIM memuat siaran.

Bisakah OEM menonaktifkan bagian dari API operator?

J: Tidak. Kami percaya bahwa API saat ini adalah set minimal, dan kami berencana untuk menggunakan bit mask untuk kontrol perincian yang lebih baik di masa mendatang.

Apakah setOperatorBrandOverride menimpa SEMUA bentuk lain dari string nama Operator? Misalnya, SE13, UICC SPN, atau NITZ berbasis jaringan?

A: Lihat entri SPN di TelephonyManager

Apa injectSmsPdu metode panggilan lakukan?

A: Metode ini memfasilitasi backup/restore SMS di cloud. The injectSmsPdu panggilan memungkinkan mengembalikan fungsi.

Untuk SMS penyaringan, adalah onFilterSms panggilan berdasarkan SMS UDH port filtering? Atau apakah aplikasi operator memiliki akses ke SEMUA SMS yang masuk?

A: Operator memiliki akses ke semua data SMS.

Perpanjangan DeviceAppID-REF-DO untuk mendukung 32 byte tampaknya tidak sesuai dengan GP spesifikasi saat ini (yang memungkinkan 0 atau 20 byte saja), jadi mengapa Anda memperkenalkan perubahan ini? Bukankah SHA-1 cukup untuk menghindari tabrakan? Sudahkah Anda mengusulkan perubahan ini ke GP, karena ini mungkin tidak kompatibel dengan ARA-M/ARF yang ada?

A: Untuk memberikan jaminan masa depan-bukti, ekstensi ini memperkenalkan SHA-256 untuk DeviceAppID-REF-DO selain SHA-1, yang saat ini satu-satunya pilihan dalam standar GP SEAC. Kami sangat merekomendasikan menggunakan SHA-256.

Jika DeviceAppID adalah 0 (kosong), Anda menerapkan aturan untuk semua perangkat apps tidak tercakup oleh aturan tertentu?

A: Pembawa API memerlukan DeviceAppID-REF-DO diisi. Menjadi kosong dimaksudkan untuk tujuan pengujian dan tidak disarankan untuk penerapan operasional.

Menurut spec, PKG-REF-DO digunakan hanya dengan sendirinya, tanpa DeviceAppID-REF-DO , tidak harus diterima. Tapi masih dijelaskan pada Tabel 6-4 sebagai memperluas definisi REF-DO . Apakah ini sengaja? Bagaimana kode berperilaku ketika hanya PKG-REF-DO digunakan dalam REF-DO ?

J: pilihan untuk memiliki PKG-REF-DO sebagai item nilai tunggal dalam REF-DO telah dihapus dalam versi terbaru. PKG-REF-DO seharusnya hanya terjadi dalam kombinasi dengan DeviceAppID-REF-DO .

Kami berasumsi bahwa kami dapat memberikan akses ke semua izin berbasis operator atau memiliki kontrol yang lebih halus. Jika demikian, apa yang mendefinisikan pemetaan antara topeng bit dan izin sebenarnya? Satu izin per kelas? Satu izin per metode? Apakah 64 izin terpisah cukup dalam jangka panjang?

A: Ini disediakan untuk masa depan, dan kami menerima saran.

Dapatkah Anda lebih menentukan DeviceAppID untuk Android khusus? Ini adalah nilai hash SHA-1 (20 byte) dari sertifikat Publisher yang digunakan untuk menandatangani aplikasi yang diberikan, jadi bukankah nama harus mencerminkan tujuan itu? (Nama tersebut dapat membingungkan banyak pembaca karena aturan tersebut kemudian berlaku untuk semua aplikasi yang ditandatangani dengan sertifikat Publisher yang sama.)

J: DeviceAppID menyimpan sertifikat didukung oleh spesifikasi yang ada. Kami mencoba meminimalkan perubahan spesifikasi untuk menurunkan hambatan adopsi. Untuk rincian, lihat Aturan di UICC .