Hak istimewa operator UICC

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

Android 7.0 memperluas fitur ini untuk mendukung sumber penyimpanan lain untuk aturan hak istimewa operator UICC, yang secara drastis meningkatkan jumlah operator yang dapat menggunakan API. Untuk referensi API, lihat CarrierConfigManager; untuk mengetahui petunjuknya, 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) sekaligus mempertahankan hak istimewa khusus di perangkat dan tanpa perlu menandatangani aplikasi dengan sertifikat platform per perangkat atau menginstal sebelumnya sebagai aplikasi sistem.

Aturan di UICC

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

Hierarki data

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

  • REF-DO (E1) berisi DeviceAppID-REF-DO atau penyambungan 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, dienkode ASCII, panjang maksimum 127 byte.
  • AR-DO (E3) diperluas untuk menyertakan PERM-AR-DO (DB), yang merupakan mask bit 8 byte yang mewakili 64 izin terpisah.

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

Contoh aturan

Nama aplikasi 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

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

Platform Android terlebih dahulu mencoba memilih AID aplikasi aturan akses (ARA) A00000015141434C00. Jika tidak menemukan AID di UICC, AID akan kembali ke ARF dengan memilih PKCS15 AID A000000063504B43532D3135. Android kemudian membaca file aturan kontrol akses (ACRF) di 0x4300 dan mencari entri dengan AID FFFFFFFFFFFF. Entri dengan AID yang berbeda akan diabaikan, sehingga aturan untuk kasus penggunaan lainnya dapat 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

Pada 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 akan diberi hak istimewa operator.

API yang diaktifkan

Android mendukung API berikut.

Pengelola Telepon

TelephonyCallback

TelephonyCallback memiliki antarmuka dengan metode callback untuk memberi tahu aplikasi pemanggil saat status terdaftar berubah:

SubscriptionManager

PengelolaSms

CarrierConfigManager

Untuk mengetahui petunjuknya, lihat Konfigurasi Operator.

BugreportManager

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

NetworkStatsManager

ImsMmTelManager

Manajer ImsRcs

Pengelola Penyediaan

EuiccManager

Metode untuk beralih ke (mengaktifkan) langganan yang diberikan: switchToSubscription

CarrierMessagingService

Layanan yang menerima panggilan dari sistem saat SMS dan MMS baru dikirim atau diterima. Untuk memperluas class ini, deklarasikan layanan dalam file manifes Anda dengan izin android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE dan sertakan filter intent 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 mendownload pesan MMS yang diterima: onDownloadMms

CarrierService

Layanan yang mengekspos fungsi khusus operator ke sistem. Untuk memperluas class ini, deklarasikan layanan dalam file manifes aplikasi dengan izin android.Manifest.permission#BIND_CARRIER_SERVICES dan sertakan filter intent dengan tindakan CARRIER_SERVICE_INTERFACE. Jika layanan memiliki binding yang berumur panjang, tetapkan android.service.carrier.LONG_LIVED_BINDING ke true dalam metadata layanan.

Platform ini mengikat CarrierService dengan flag khusus agar proses layanan operator dapat berjalan di bucket aplikasi standby khusus. Hal ini mengecualikan aplikasi layanan operator dari pembatasan aplikasi tidak ada aktivitas dan membuatnya lebih cenderung tetap aktif saat memori perangkat rendah. Namun, jika aplikasi layanan operator mengalami error karena alasan apa pun, aplikasi akan kehilangan semua hak istimewa di atas hingga aplikasi dimulai ulang dan binding dibuat ulang. Jadi, penting untuk menjaga aplikasi layanan operator tetap stabil.

Metode di CarrierService mencakup:

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

Penyedia layanan telepon

API penyedia konten untuk mengizinkan perubahan (menyisipkan, menghapus, memperbarui, membuat kueri) pada database telephony. Kolom nilai ditentukan di Telephony.Carriers; untuk detail selengkapnya, lihat referensi class Telephony

WifiNetworkSuggestion

Saat mem-build objek WifiNetworkSuggestion, gunakan metode berikut untuk menetapkan 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, mengurainya dari kartu UICC, dan meng-cache-nya dalam memori. Jika pemeriksaan hak istimewa diperlukan, UiccCarrierPrivilegeRules akan membandingkan sertifikat pemanggil dengan aturannya sendiri satu per satu. Jika UICC dihapus, aturan akan dihancurkan bersama dengan objek UICC.

Validasi

Untuk memvalidasi penerapan melalui Compatibility Test Suite (CTS) menggunakan CtsCarrierApiTestCases.apk, Anda harus memiliki UICC developer dengan aturan UICC atau dukungan ARF yang benar. Minta vendor kartu SIM pilihan Anda untuk menyiapkan UICC developer 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 pengujian CTS.

Menyiapkan UICC

Untuk Android 11 dan yang lebih lama, 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 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.

Mengubah profil SIM CTS

  1. Tambahkan: Hak istimewa operator CTS di access rule app master (ARA-M) atau ARF. Kedua tanda tangan harus denkode 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
  2. Buat: File elemen (EF) USIM ADF yang tidak ada dalam TS.48 dan diperlukan untuk CTS:
    1. EF_MBDN (6FC7), ukuran data: 28, nomor data: 4 
      • Konten
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), ukuran catatan:13, catatan nomor: 1
      • Konten: 00FF...FF
        1. EF_MBI (6FC9), ukuran data: 4, nomor data: 1
      • Konten: Rec1: 01010101
        1. EF_MWIS (6FCA), ukuran data: 5, nomor data: 1
      • Konten: 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: Gunakan string nama operator Android CTS di setiap EF yang berisi penetapan ini:
    1. EF_SPN (USIM/6F46)
      • Konten: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Konten: Rec1 430B83413759FE4E934143EA14FF..FF

Mencocokkan struktur profil pengujian

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

Menjalankan pengujian

Untuk memudahkan, CTS mendukung token perangkat yang membatasi pengujian agar hanya berjalan di perangkat yang dikonfigurasi dengan token yang sama. Pengujian CTS Carrier API mendukung token perangkat sim-card-with-certs. Misalnya, token perangkat berikut membatasi pengujian API operator untuk dijalankan hanya pada abcd1234 perangkat:

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

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

FAQ

Bagaimana cara memperbarui sertifikat di UICC?

A: Menggunakan mekanisme update OTA kartu yang ada.

Dapatkah UICC berdampingan dengan aturan lain?

A: Tidak masalah jika ada aturan keamanan lain di UICC dengan AID yang sama; platform akan memfilternya secara otomatis.

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

A: Aplikasi kehilangan hak istimewanya karena aturan yang terkait dengan UICC dihancurkan saat UICC dihapus.

Apakah ada batas jumlah sertifikat di UICC?

A: Platform tidak membatasi jumlah sertifikat. Namun, karena pemeriksaan bersifat linear, terlalu banyak aturan dapat menimbulkan latensi untuk pemeriksaan.

Apakah ada batas jumlah API yang dapat kita dukung dengan metode ini?

A: Tidak, tetapi kami membatasi cakupannya ke API terkait operator.

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

A: 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 akan digunakan.

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

A: Misalnya, SEEK menggunakan AID yang sama seperti di UICC. Jadi, aturan tersebut berdampingan dan difilter menurut SEEK atau UiccCarrierPrivileges.

Kapan waktu yang tepat untuk memeriksa hak istimewa operator?

A: Setelah siaran status SIM dimuat.

Dapatkah OEM menonaktifkan sebagian API operator?

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

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

Ya, penggantian merek operator memiliki prioritas tertinggi. Jika ditetapkan, string ini akan menggantikan SEMUA bentuk string nama operator lainnya.

Apa fungsi panggilan metode injectSmsPdu?

A: Metode ini memfasilitasi pencadangan/pemulihan 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 masuk?

A: 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 sudah memadai untuk menghindari konflik? Apakah Anda sudah mengusulkan perubahan ini ke GP, karena hal ini mungkin tidak kompatibel dengan ARA-M/ARF yang sudah ada?

A: Untuk memberikan keamanan yang siap menghadapi 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. Sebaiknya gunakan SHA-256.

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

A: Carrier API mengharuskan DeviceAppID-REF-DO diisi. Kosong dimaksudkan untuk tujuan pengujian dan tidak direkomendasikan untuk deployment operasional.

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

A: Opsi untuk memiliki PKG-REF-DO sebagai item nilai tunggal di REF-DO telah dihapus di versi terbaru. PKG-REF-DO hanya boleh muncul dalam kombinasi dengan DeviceAppID-REF-DO.

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

A: Fitur ini disediakan untuk masa mendatang, dan kami menerima saran.

Dapatkah Anda menentukan DeviceAppID lebih lanjut untuk Android secara khusus? Ini adalah nilai hash SHA-1 (20 byte) dari sertifikat Penerbit yang digunakan untuk menandatangani aplikasi tertentu, jadi bukankah nama tersebut seharusnya mencerminkan tujuan tersebut? (Nama ini mungkin membingungkan bagi banyak pembaca karena aturan tersebut berlaku untuk semua aplikasi yang ditandatangani dengan sertifikat Penayang yang sama.)

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