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 Konfigurasi Operator .

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 tetap 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 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).

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

• REF-DO ( E1 ) berisi DeviceAppID-REF-DO atau gabungan dari DeviceAppID-REF-DO dan PKG-REF-DO .
  • DeviceAppID-REF-DO ( C1 ) menyimpan tanda tangan SHA-1 (20 byte) atau SHA-256 (32 byte) dari sertifikat.
  • PKG-REF-DO ( CA ) adalah string nama paket lengkap yang ditentukan dalam manifes, disandikan ASCII, panjang maksimal 127 byte.
• AR-DO ( E3 ) diperluas untuk menyertakan PERM-AR-DO ( DB ), yang merupakan topeng bit 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 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).

Platform Android pertama-tama mencoba memilih applet aturan akses (ARA) application identifier (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 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 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 oleh sertifikat ini diberikan hak istimewa operator.

API yang diaktifkan

Android mendukung API berikut.

Manajer Telepon

• Metode untuk mengizinkan aplikasi operator meminta tantangan/tanggapan UICC: getIccAuthentication .
• Metode untuk memeriksa apakah aplikasi panggilan telah diberikan hak istimewa operator: hasCarrierPrivileges .
• Metode untuk mengganti merek dan nomor:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• Metode untuk komunikasi UICC langsung:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• Metode untuk menyetel mode perangkat ke global: setPreferredNetworkTypeToGlobal .

Manajer SMS

Metode untuk mengizinkan penelepon membuat pesan SMS masuk baru: injectSmsPdu .

CarrierConfigManager

Metode untuk memberi tahu konfigurasi diubah: notifyConfigChangedForSubId . Untuk petunjuk, lihat Konfigurasi Operator .

Layanan Pesan Operator

Layanan yang menerima panggilan dari sistem saat 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 . Metode meliputi:

• onFilterSms
• onSendTextSms
• onSendDataSms
• onSendMultipartTextSms
• onSendMms
• onDownloadMms

Penyedia telepon

API penyedia konten untuk memungkinkan modifikasi (menyisipkan, menghapus, memperbarui, membuat kueri) ke database telepon. Bidang nilai ditentukan di Telephony.Carriers ; untuk lebih jelasnya, lihat referensi Telephony API di 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 memuat aturan, mem-parsingnya dari kartu UICC, dan menyimpannya di memori. Saat pemeriksaan hak istimewa diperlukan, UiccCarrierPrivilegeRules membandingkan sertifikat pemanggil dengan aturannya sendiri satu per satu. Jika UICC dihapus, aturan dihancurkan bersama dengan objek UICC.

Validasi

Untuk memvalidasi implementasi melalui Compatibility Test Suite (CTS) menggunakan CtsCarrierApiTestCases.apk , Anda harus memiliki UICC developer dengan aturan UICC atau dukungan ARF yang benar. 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 yang 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 dengan nilai hash cts-uicc-2021-testkey 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 harus menggunakan SIM dengan hak istimewa operator CTS yang memenuhi persyaratan yang ditentukan dalam versi terbaru spesifikasi Profil Pengujian GSMA TS.48 pihak ketiga.

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

Memodifikasi Profil SIM CTS

1. Tambahkan : Keistimewaan Operator CTS 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

Catatan: jika menggunakan ARF, ACRF dengan AID: FFFFFFFFFFFF harus menunjuk ke satu ACCF yang mengkodekan Hash1 dan Hash2.

2. Buat : ADF USIM EF tidak ada di TS.48 dan diperlukan untuk CTS:
   1. EF_MBDN (6FC7), Ukuran Rekaman: 28, Nomor rekaman: 4
      • Isi
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rek2-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: 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)
      • Konten: A0020000FF…FF
   4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Konten: A0020000FF…FF
5. Ubah : String Nama Operator harus Android CTS di masing-masing EF yang berisi penunjukan ini:
   1. EF_SPN (USIM/6F46)
      • Konten: 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.

• Struktur Profil Uji Generik GSMA TS.48
• Contoh profil TS.48 dalam format eSIM DER

Menjalankan tes

Untuk kenyamanan, CTS mendukung token perangkat yang membatasi pengujian untuk dijalankan hanya pada perangkat yang dikonfigurasi dengan token yang sama. Pengujian Carrier API CTS mendukung token perangkat sim-card-with-certs . Misalnya, token perangkat berikut membatasi pengujian API operator untuk berjalan hanya 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?)

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

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 ada dan difilter oleh 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 yang dilakukan pemanggilan metode injectSmsPdu ?

A: Metode ini memfasilitasi backup/restore SMS di cloud. Panggilan injectSmsPdu mengaktifkan fungsi pemulihan.

Untuk pemfilteran SMS, apakah panggilan onFilterSms didasarkan pada pemfilteran port UDH SMS? 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 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 ini mungkin tidak kompatibel dengan ARA-M/ARF yang ada?

J: Untuk menyediakan 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 menggunakan SHA-256.

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

J: Carrier API mengharuskan DeviceAppID-REF-DO diisi. Menjadi kosong dimaksudkan untuk tujuan pengujian dan tidak disarankan untuk penerapan operasional.

Menurut spesifikasi Anda, PKG-REF-DO digunakan sendiri, tanpa DeviceAppID-REF-DO , tidak boleh diterima. Tetapi masih dijelaskan pada Tabel 6-4 sebagai perluasan definisi REF-DO . Apakah ini sengaja? Bagaimana kode berperilaku ketika hanya PKG-REF-DO yang digunakan di REF-DO ?

J: Opsi memiliki PKG-REF-DO sebagai item nilai tunggal dalam REF-DO telah dihapus di versi terbaru. PKG-REF-DO hanya boleh muncul 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.

Bisakah Anda mendefinisikan lebih lanjut DeviceAppID untuk Android secara 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: Sertifikat penyimpanan DeviceAppID didukung oleh spesifikasi yang ada. Kami mencoba meminimalkan perubahan spesifikasi untuk menurunkan hambatan adopsi. Untuk detailnya, lihat Aturan di UICC .