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 kepada 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, sehingga secara signifikan meningkatkan jumlah operator yang dapat menggunakan API. Untuk referensi API, lihat CarrierConfigManager ; untuk petunjuknya, lihat Konfigurasi Operator .

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

Aturan di UICC

Penyimpanan di UICC kompatibel dengan spesifikasi Kontrol Akses Elemen Aman GlobalPlatform . Pengidentifikasi aplikasi (AID) pada kartu adalah A00000015141434C00 , dan perintah GET DATA standar digunakan untuk mengambil aturan yang disimpan di kartu. Anda dapat memperbarui aturan ini melalui pembaruan kartu over-the-air (OTA).

Hierarki 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 REF-DO dan AR-DO :

  • REF-DO ( E1 ) berisi DeviceAppID-REF-DO atau gabungan DeviceAppID-REF-DO dan PKG-REF-DO .
    • DeviceAppID-REF-DO ( C1 ) menyimpan tanda tangan sertifikat SHA-1 (20 byte) atau SHA-256 (32 byte).
    • PKG-REF-DO ( CA ) adalah string nama paket lengkap yang ditentukan dalam manifes, dikodekan ASCII, panjang maksimal 127 byte.
  • AR-DO ( E3 ) diperluas untuk mencakup PERM-AR-DO ( DB ), yang merupakan bit mask 8-byte yang mewakili 64 izin terpisah.

Jika PKG-REF-DO tidak ada, aplikasi apa pun yang ditandatangani oleh sertifikat akan diberikan akses; jika tidak, sertifikat dan nama paket harus cocok.

Contoh aturan

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

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

Aturan UICC dalam string hex adalah:

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

Akses dukungan file aturan

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

Platform Android pertama-tama mencoba memilih aplikasi aturan akses (ARA) AID A00000015141434C00 . Jika tidak menemukan AID di UICC, ia kembali ke ARF dengan memilih PKCS15 AID A000000063504B43532D3135 . Android kemudian membaca file aturan kontrol akses (ACRF) pada 0x4300 dan mencari entri dengan AID FFFFFFFFFFFF . Entri dengan AID yang berbeda akan diabaikan, sehingga aturan untuk kasus penggunaan lainnya dapat diterapkan secara bersamaan.

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

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

API yang diaktifkan

Android mendukung API berikut.

Manajer Telepon

Panggilan Balik Telepon

TelephonyCallback memiliki antarmuka dengan metode panggilan balik untuk memberi tahu aplikasi panggilan ketika status terdaftar berubah:

Manajer Langganan

Manajer Sms

Manajer Konfigurasi Pembawa

Untuk petunjuknya, lihat Konfigurasi Operator .

Manajer Laporan Bug

Metode untuk memulai laporan bug konektivitas, yang merupakan versi khusus dari laporan bug yang hanya mencakup informasi untuk men-debug masalah terkait konektivitas: startConnectivityBugreport

Manajer NetworkStats

ImsMmTelManager

Manajer ImsRcs

Manajer Penyediaan

Manajer Euicc

Metode untuk beralih ke (mengaktifkan) langganan tertentu: switchToSubscription

Layanan Pesan Operator

Layanan yang menerima panggilan dari sistem ketika SMS dan MMS baru dikirim atau diterima. Untuk memperluas kelas ini, deklarasikan layanan dalam file manifes Anda dengan izin android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE dan sertakan filter maksud dengan tindakan #SERVICE_INTERFACE . Metodenya meliputi:

  • Metode untuk memfilter pesan SMS masuk: onFilterSms
  • Metode untuk mencegat pesan SMS teks yang dikirim dari perangkat: onSendTextSms
  • Metode untuk mencegat pesan SMS biner yang dikirim dari perangkat: onSendDataSms
  • Metode untuk mencegat pesan SMS panjang yang dikirim dari perangkat: onSendMultipartTextSms
  • Metode untuk mencegat pesan MMS yang dikirim dari perangkat: onSendMms
  • Metode untuk mengunduh pesan MMS yang diterima: onDownloadMms

Layanan Pengangkut

Layanan yang memaparkan fungsionalitas khusus operator ke sistem. Untuk memperluas kelas ini, deklarasikan layanan dalam file manifes aplikasi dengan izin android.Manifest.permission#BIND_CARRIER_SERVICES dan sertakan filter maksud dengan tindakan CARRIER_SERVICE_INTERFACE . Jika layanan memiliki pengikatan jangka panjang, setel android.service.carrier.LONG_LIVED_BINDING ke true dalam metadata layanan.

Platform ini mengikat CarrierService dengan tanda khusus agar proses layanan operator dapat berjalan di keranjang siaga aplikasi khusus. Hal ini membebaskan aplikasi layanan operator dari pembatasan aplikasi menganggur dan membuatnya lebih mungkin untuk tetap hidup ketika memori perangkat hampir habis. Namun, jika aplikasi layanan operator mengalami error karena alasan apa pun, aplikasi tersebut akan kehilangan semua hak istimewa di atas hingga aplikasi dimulai ulang dan pengikatan dibuat ulang. Jadi, penting untuk menjaga kestabilan aplikasi layanan operator.

Metode dalam CarrierService meliputi:

  • Untuk mengganti dan mengatur konfigurasi khusus operator: onLoadConfig
  • Untuk memberi tahu sistem tentang perubahan jaringan operator mendatang yang disengaja oleh aplikasi operator: notifyCarrierNetworkChange

Penyedia telepon

API penyedia konten untuk memungkinkan modifikasi (memasukkan, menghapus, memperbarui, menanyakan) pada database telepon. Bidang nilai ditentukan di Telephony.Carriers ; untuk lebih jelasnya lihat referensi kelas Telephony

Saran Jaringan Wifi

Saat membuat objek WifiNetworkSuggestion , gunakan metode berikut untuk menyetel ID langganan atau grup langganan:

platform Android

Pada UICC yang terdeteksi, platform membuat objek UICC internal yang menyertakan aturan hak istimewa operator sebagai bagian dari UICC. UiccCarrierPrivilegeRules.java memuat aturan, menguraikannya dari kartu UICC, dan menyimpannya dalam cache di memori. Ketika pemeriksaan hak istimewa diperlukan, UiccCarrierPrivilegeRules membandingkan sertifikat pemanggil dengan aturannya sendiri satu per satu. Jika UICC dihapus, aturan akan dimusnahkan bersama dengan objek UICC.

Validasi

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

Siapkan UICC

Untuk Android 11 dan lebih rendah, 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 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 pengujian API operator CTS di Android 12, perangkat perlu menggunakan SIM dengan hak istimewa operator CTS yang memenuhi persyaratan yang ditentukan dalam versi terbaru spesifikasi Profil Tes GSMA TS.48 pihak ketiga.

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

Memodifikasi Profil SIM CTS

  1. Tambahkan: Hak istimewa operator CTS di master aplikasi aturan akses (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. 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
  2. Buat: File dasar ADF USIM (EF) tidak ada di TS.48 dan diperlukan untuk CTS:
    1. EF_MBDN (6FC7), ukuran catatan: 28, nomor catatan: 4
      • Isi
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rek2-n: FF…FF
    2. EF_EXT6 (6FC8), ukuran catatan:13, nomor catatan: 1
      • Konten: 00FF…FF
        1. EF_MBI (6FC9), ukuran catatan: 4, nomor catatan: 1
      • Isi: Rek1: 01010101
        1. EF_MWIS (6FCA), ukuran catatan: 5, nomor catatan: 1
      • Isi: 0000000000
  3. Ubah: Tabel layanan USIM: Aktifkan layanan n°47, n°48
    1. EF_UST (6F38)
      • Konten: 9EFFBF1DFFFE0083410310010400406E01
  4. Ubah: file DF-5GS dan DF-SAIP
    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)
      • Isi: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Isi: A0020000FF…FF
  5. Modifikasi: Gunakan string nama operator Android CTS di masing-masing EF yang berisi sebutan ini:
    1. EF_SPN (USIM/6F46)
      • Isi: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Konten: Rec1 430B83413759FE4E934143EA14FF..FF

Mencocokkan struktur profil pengujian

Unduh dan cocokkan versi terbaru dari struktur profil pengujian umum berikut. Profil ini tidak akan memiliki aturan Hak Istimewa Operator CTS yang dipersonalisasi atau modifikasi lain yang tercantum di atas.

Menjalankan tes

Demi kenyamanan, CTS mendukung token perangkat yang membatasi pengujian agar hanya dijalankan pada perangkat yang dikonfigurasi dengan token yang sama. Tes Carrier API CTS mendukung token perangkat sim-card-with-certs . Misalnya, token perangkat berikut membatasi pengujian API operator agar hanya berjalan pada perangkat abcd1234 :

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

Saat menjalankan pengujian tanpa menggunakan token perangkat, pengujian akan dijalankan di semua perangkat.

Pertanyaan Umum

Bagaimana cara memperbarui sertifikat di UICC?

A: Gunakan mekanisme pembaruan OTA kartu yang ada.

Bisakah UICC hidup berdampingan dengan aturan lain?

J: Tidak masalah jika ada aturan keamanan lain di UICC di bawah AID yang sama; platform memfilternya secara otomatis.

Apa yang terjadi jika UICC dihapus untuk aplikasi yang mengandalkan sertifikat di dalamnya?

J: Aplikasi kehilangan hak istimewanya karena aturan yang terkait dengan UICC dimusnahkan saat UICC dihapus.

Apakah ada batasan jumlah sertifikat di UICC?

J: Platform tidak membatasi jumlah sertifikat; namun 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, namun kami membatasi cakupan hanya pada API yang terkait dengan operator.

Apakah ada beberapa API yang dilarang menggunakan metode ini? Jika ya, bagaimana Anda menegakkannya? (yaitu, apakah Anda memiliki pengujian untuk memvalidasi API mana yang didukung dengan metode ini?)

J: Lihat bagian Kompatibilitas Perilaku API di Dokumen Definisi Kompatibilitas Android (CDD). Kami memiliki beberapa pengujian CTS untuk memastikan bahwa model izin API tidak berubah.

Bagaimana cara kerjanya dengan fitur multi-SIM?

A: 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 aturannya hidup berdampingan dan difilter oleh SEEK atau UiccCarrierPrivileges .

Kapan saat yang tepat untuk memeriksa hak istimewa operator?

A: Setelah status SIM dimuat siaran.

Bisakah OEM menonaktifkan sebagian API operator?

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

Apakah setOperatorBrandOverride mengesampingkan SEMUA bentuk string nama operator lainnya? Misalnya SE13, UICC SPN, atau NITZ berbasis jaringan?

Ya, penggantian merek operator memiliki prioritas tertinggi. Jika sudah disetel, ini akan menimpa SEMUA bentuk string nama operator lainnya.

Apa yang dilakukan pemanggilan metode injectSmsPdu ?

J: Metode ini memfasilitasi pencadangan/pemulihan SMS di cloud. Panggilan injectSmsPdu mengaktifkan fungsi pemulihan.

Untuk pemfilteran SMS, apakah panggilan onFilterSms didasarkan pada pemfilteran port SMS UDH? Atau apakah aplikasi operator memiliki akses ke SEMUA SMS masuk?

J: Operator memiliki akses ke semua data SMS.

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

J: Untuk memberikan keamanan masa depan, ekstensi ini memperkenalkan SHA-256 untuk DeviceAppID-REF-DO selain SHA-1, yang saat ini merupakan satu-satunya opsi dalam standar GP SEAC. Kami sangat merekomendasikan penggunaan SHA-256.

Jika DeviceAppID adalah 0 (kosong), apakah Anda menerapkan aturan tersebut ke semua aplikasi perangkat yang tidak tercakup dalam aturan tertentu?

J: API Operator memerlukan DeviceAppID-REF-DO untuk diisi. Kosong dimaksudkan untuk tujuan pengujian dan tidak disarankan untuk penerapan operasional.

Menurut spesifikasi Anda, PKG-REF-DO digunakan sendirian, tanpa DeviceAppID-REF-DO , tidak boleh diterima. Namun hal ini masih dijelaskan pada Tabel 6-4 spesifikasi sebagai perluasan definisi REF-DO . Apakah ini disengaja? Bagaimana perilaku kode ketika hanya PKG-REF-DO yang digunakan di REF-DO ?

J: Opsi untuk menjadikan PKG-REF-DO sebagai item nilai tunggal di REF-DO telah dihapus di versi terbaru. PKG-REF-DO hanya boleh muncul jika dikombinasikan dengan DeviceAppID-REF-DO .

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

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

Bisakah Anda mendefinisikan lebih lanjut DeviceAppID untuk Android secara spesifik? Ini adalah nilai hash SHA-1 (20 byte) dari sertifikat Penerbit yang digunakan untuk menandatangani aplikasi tertentu, jadi bukankah nama tersebut harus mencerminkan tujuan tersebut? (Nama tersebut mungkin membingungkan banyak pembaca karena aturan tersebut kemudian berlaku untuk semua aplikasi yang ditandatangani dengan sertifikat Penerbit yang sama.)

J: Sertifikat penyimpanan DeviceAppID didukung oleh spesifikasi yang ada. Kami mencoba meminimalkan perubahan spesifikasi untuk menurunkan hambatan adopsi. Untuk detailnya, lihat Aturan di UICC .