UICC 電信業者權限

Android 5.1 推出了一種機制,可為通用積體電路卡 (UICC) 應用程式的擁有者,授予 API 特殊權限。Android 平台會載入儲存在 UICC 上的憑證,並授予憑證簽署的應用程式權限,以便呼叫少數特殊 API。

Android 7.0 擴充這項功能,以支援 UICC 電信業者權限規則的其他儲存來源,大幅增加可使用 API 的電信業者數量。如需 API 參考資料,請參閱 CarrierConfigManager;如需操作說明,請參閱「電信業者設定」。

由於電信業者可完全控管 UICC,因此這個機制可提供安全且彈性的管理方式,用於管理行動網路業者 (MNO) 在一般應用程式發布管道 (例如 Google Play) 上代管的應用程式,同時保留裝置上的特殊權限,且無需使用個別裝置平台憑證簽署應用程式,或將應用程式預先安裝為系統應用程式。

UICC 規則

UICC 上的儲存空間與 GlobalPlatform 安全元件存取權控制規格相容。卡片上的應用程式 ID (AID) 為 A00000015141434C00,標準 GET DATA 指令則用於擷取儲存在卡片上的規則。您可以透過卡片無線 (OTA) 更新來更新這些規則。

資料階層

UICC 規則使用下列資料階層 (括號內的兩個字母和數字組合是物件標記)。每項規則都是 REF-AR-DO (E2),由 REF-DOAR-DO 串連而成:

  • REF-DO (E1) 包含 DeviceAppID-REF-DO,或 DeviceAppID-REF-DOPKG-REF-DO 的串接。
    • DeviceAppID-REF-DO (C1) 會儲存憑證的 SHA-1 (20 個位元組) 或 SHA-256 (32 個位元組) 簽章。
    • PKG-REF-DO (CA) 是資訊清單中定義的完整套件名稱字串,採用 ASCII 編碼,長度上限為 127 個位元組。
  • AR-DO (E3) 已擴充為包含 PERM-AR-DO (DB),這是 8 位元遮罩,代表 64 個個別權限。

如果沒有 PKG-REF-DO,則憑證簽署的任何應用程式都會獲得存取權;否則,憑證和套件名稱都必須相符。

規則範例

應用程式名稱為 com.google.android.apps.myapp,十六進位字串中的 SHA-1 憑證如下:

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

十六進位字串中的 UICC 規則如下:

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

存取規則檔案支援

Android 7.0 新增了從存取規則檔案 (ARF) 讀取電信業者特權規則的支援功能。

Android 平台會先嘗試選取存取權規則應用程式 (ARA) AID A00000015141434C00。如果未在 UICC 上找到 AID,系統會改為選取 PKCS15 AID A000000063504B43532D3135,以便回復到 ARF。接著,Android 會讀取 0x4300 中的存取權控制規則檔案 (ACRF),並尋找具有 AID FFFFFFFFFFFF 的項目。系統會忽略不同 AID 的項目,因此其他用途的規則可以共存。

ACRF 內容十六進位字串範例:

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

存取控管條件檔案 (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

在上述範例中,0x4310 是 ACCF 的地址,其中包含憑證雜湊 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81。使用此憑證簽署的應用程式會獲得電信業者特權。

已啟用的 API

Android 支援下列 API。

電話管理工具

TelephonyCallback

TelephonyCallback 具有具有回呼方法的介面,可在註冊狀態變更時通知呼叫應用程式:

訂閱管理員

簡訊管理工具

CarrierConfigManager

如需操作說明,請參閱「電信業者設定」。

BugreportManager

開始連線錯誤報告的方法,這是錯誤報告的專屬版本,僅包含用於偵錯連線相關問題的資訊: startConnectivityBugreport

網路統計資料管理員

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

切換至 (啟用) 指定訂閱項目的方法: switchToSubscription

電信業者訊息服務

傳送或接收新簡訊和多媒體訊息時,接收系統來電的服務。如要擴充這個類別,請在資訊清單檔案中使用 android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE 權限宣告服務,並加入含有 #SERVICE_INTERFACE 動作的意圖篩選器。方法包括:

CarrierService

這項服務會將特定電信業者的功能提供給系統。如要擴充這個類別,請在應用程式資訊清單檔案中使用 android.Manifest.permission#BIND_CARRIER_SERVICES 權限宣告服務,並加入含有 CARRIER_SERVICE_INTERFACE 動作的意圖篩選器。如果服務具有長效繫結,請在服務的中繼資料中將 android.service.carrier.LONG_LIVED_BINDING 設為 true

平台會將 CarrierService 與特殊標記繫結,讓電信服務程序在特殊的 應用程式待命區塊中執行。這樣一來,您就能讓電信服務應用程式免於受到 應用程式閒置限制的影響,並在裝置記憶體不足時,提高應用程式持續運作的可能性。不過,如果電信服務應用程式因任何原因當機,就會失去上述所有權限,直到應用程式重新啟動並重新建立繫結為止。因此,請務必確保電信業者服務應用程式穩定運作。

CarrierService 中的函式包括:

  • 如要覆寫及設定電信業者專屬設定,請按照下列步驟操作: onLoadConfig
  • 如要讓系統知道電信業者應用程式即將進行的電信業者網路變更: notifyCarrierNetworkChange

電話服務供應商

內容供應器 API,可讓您修改 (插入、刪除、更新、查詢) 電話服務資料庫。值欄位定義於 Telephony.Carriers;詳情請參閱 Telephony 類別參考資料。

WifiNetworkSuggestion

建構 WifiNetworkSuggestion 物件時,請使用下列方法設定訂閱 ID 或訂閱群組:

Android 平台

在偵測到的 UICC 上,平台會建構內部 UICC 物件,並將電信業者權限規則納入 UICC。 UiccCarrierPrivilegeRules.java 會載入規則,從 UICC 卡片解析規則,並將規則快取到記憶體中。需要進行特權檢查時,UiccCarrierPrivilegeRules 會逐一將呼叫端憑證與其自身規則進行比較。如果移除 UICC,規則也會一併刪除,以及 UICC 物件。

驗證

如要使用 CtsCarrierApiTestCases.apk 透過 Compatibility Test Suite (CTS) 驗證導入作業,您必須具備具備正確 UICC 規則或 ARF 支援的開發人員 UICC。請所選 SIM 卡供應商準備開發人員 UICC,並按照本節所述設定正確的 ARF,然後使用該 UICC 執行測試。UICC 不需要啟用行動服務,即可通過 CTS 測試。

準備 UICC

如果是 Android 11 以下版本,CtsCarrierApiTestCases.apk 是由 aosp-testkey 簽署,雜湊值 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81

從 Android 12 開始,CtsCarrierApiTestCases.apk 是由 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

如要在 Android 12 執行 CTS 電信業者 API 測試,裝置必須使用具備 CTS 電信業者權限的 SIM 卡,且該 SIM 卡必須符合最新版本第三方 第三方 GSMA TS.48 測試設定檔中的需求條件。

Android 12 以下版本也可以使用相同 SIM 卡。

修改 CTS SIM 卡設定檔

  1. 新增:在存取權規則應用程式主檔 (ARA-M) 或 ARF 中新增 CTS 電信業者權限。兩個簽章都必須在電信業者特權規則中編碼:
    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. 建立:TS.48 中未提供的 ADF USIM 基本檔案 (EF),但 CTS 需要這些檔案:
    1. EF_MBDN (6FC7);記錄大小:28,記錄編號:4
      • 內容
        1. Rec1: 566F696365204D61696CFFFFFFFF0691515555555FF…FF
        2. Rec2-n:FF…FF
    2. EF_EXT6 (6FC8),記錄大小:13,記錄編號:1
      • 內容:00FF…FF
        1. EF_MBI (6FC9),記錄大小:4,記錄編號:1
      • 內容:Rec1:01010101
        1. EF_MWIS (6FCA),記錄大小:5,記錄號碼:1
      • 內容:0000000000
  3. 修改:USIM 服務表格:啟用服務 47、48
    1. EF_UST (6F38)
      • 內容:9EFFBF1DFFFE0083410310010400406E01
  4. 修改:DF-5GS 和 DF-SAIP 檔案
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • 內容:FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • 內容:FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • 內容:A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • 內容:A0020000FF…FF
  5. 修改:在包含此標示的個別 EF 中,使用電信業者名稱字串 Android CTS
    1. EF_SPN (USIM/6F46)
      • 內容:01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • 內容:Rec1 430B83413759FE4E934143EA14FF..FF

符合測試設定檔結構

下載並比對下列一般測試設定檔結構的最新版本。這些設定檔不會套用上述的 CTS 電信業者特權規則或其他修改。

執行測試

為方便起見,CTS 支援裝置權杖,可限制只在設定相同權杖的裝置上執行測試。電信業者 API CTS 測試支援裝置權杖 sim-card-with-certs。舉例來說,下列裝置符記會限制電信業者 API 測試,只在裝置 abcd1234 上執行:

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

如未使用裝置權杖執行測試,則測試會在所有裝置上執行。

常見問題

如何在 UICC 上更新憑證?

答:採用現有的卡片 OTA 更新機制。

UICC 能否與其他規則並存?

答:您可以在 UICC 上設定其他安全性規則,並在同一個 AID 底下進行設定;平台會自動篩除這些規則。

如果應用程式仰賴其憑證的 UICC 移除,會發生什麼情況?

答:由於系統刪除 UICC 時會刪除與 UICC 相關聯的規則,因此應用程式失去權限。

UICC 上的憑證數量是否有限制?

答:平台不會限制憑證數量,但由於檢查是線性的,太多規則可能會導致檢查延遲。

這個方法支援的 API 數量是否有上限?

答:否,但我們會將範圍限制在與電信業者相關的 API。

有些 API 是否禁止使用這個方法?如果是的話,您會如何強制執行這些政策?(也就是說,您是否有測試來驗證這個方法支援哪些 API?)

答:請參閱 Android 相容性定義說明文件 (CDD) 中的「 API 行為相容性」一節。我們會執行一些 CTS 測試,確保 API 的權限模型不會變更。

這項功能與多 SIM 卡功能的搭配運作方式為何?

答:系統會使用使用者指定的預設 SIM 卡。

這項技術是否會與其他搜尋引擎存取技術 (例如 SEEK) 互動或重疊?

答:舉例來說,SEEK 會使用與 UICC 相同的 AID。因此,規則會並存,並由 SEEK 或 UiccCarrierPrivileges 篩選。

何時是檢查電信業者特權的適當時機?

答:在 SIM 卡狀態載入廣播之後。

原始設備製造商 (OEM) 可以停用部分電信業者 API 嗎?

答:否。我們認為目前的 API 是最低限的集合,並計劃日後使用位元遮罩,以便更精細地控制細節。

setOperatorBrandOverride 是否會覆寫所有其他形式的運算子名稱字串?例如 SE13、UICC SPN 或網路 NITZ?

是,作業員品牌覆寫值的優先順序最高。設定後,會覆寫所有其他形式的運算子名稱字串。

injectSmsPdu 方法呼叫有什麼作用?

答:這個方法可在雲端中備份/還原簡訊。injectSmsPdu 呼叫會啟用還原功能。

針對簡訊篩選功能,onFilterSms 呼叫是否以 SMS UDH 通訊埠篩選為依據?還是電信業者應用程式可以存取「所有」傳入的簡訊?

答:電信業者可存取所有簡訊資料。

支援 32 個位元組的 DeviceAppID-REF-DO 擴充內容似乎與目前的 GP 規格 (只允許 0 或 20 個位元組) 不相容,為什麼要導入這項變更?SHA-1 不足以避免衝突嗎?您是否已向 GP 提出這項變更,因為這可能與現有的 ARA-M/ARF 不相容?

答:為了提供未來可靠的安全性,這個擴充功能除了目前 GP SEAC 標準中唯一的選項 SHA-1 外,也為 DeviceAppID-REF-DO 導入 SHA-256。我們強烈建議您使用 SHA-256。

如果 DeviceAppID 為 0 (空白),您是否會將規則套用至所有未受特定規則涵蓋的裝置應用程式?

答:電信業者 API 必須填入 DeviceAppID-REF-DO。 空白的值是用於測試,不建議用於實際部署。

根據您的規格,系統不接受單獨使用 (不含 DeviceAppID-REF-DO) 的 PKG-REF-DO。但規格表 6-4 仍將其描述為擴充 REF-DO 的定義。這是有意為之嗎?當 REF-DO 中只使用 PKG-REF-DO 時,程式碼的行為為何?

答:最新版本已移除在 REF-DO 中將 PKG-REF-DO 設為單一值項目的選項。PKG-REF-DO 應只與 DeviceAppID-REF-DO 搭配使用。

我們假設我們可以授予所有電信業者權限的存取權,或是精細控管權限。如果是這樣,請問如何定義位元遮罩和實際權限之間的對應關係?每個類別一個權限?每種方法分別具備一項權限嗎?64 個獨立權限是否足以應付長期需求?

答:這項功能僅保留於日後使用,歡迎建議。

您能否進一步針對 Android 定義 DeviceAppID?這是用於簽署指定應用程式的發布者憑證的 SHA-1 (20 個位元組) 雜湊值,因此名稱應反映該用途。(這個名稱可能會讓許多讀者感到困惑,因為這項規則適用於所有使用相同發布商憑證簽署的應用程式)。

答:現有規格支援 DeviceAppID 儲存憑證。我們已盡量降低規格變更,藉此降低採用率。詳情請參閱「UICC 上的規則」。