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),這是代表 64 個個別權限的 8 位元組位元遮罩。

如果沒有 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。

TelephonyManager

TelephonyCallback

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

SubscriptionManager

SmsManager

CarrierConfigManager

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

BugreportManager

啟動連線錯誤報告的方法,這是錯誤報告的特殊版本,只包含用於偵錯連線相關問題的資訊: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

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

CarrierMessagingService

這項服務會在系統傳送或接收新的簡訊和多媒體訊息時,接收系統的呼叫。如要擴充這個類別,請在資訊清單檔案中宣告這項服務,並使用 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 透過 相容性測試套件 (CTS) 驗證實作項目,您必須具備含有正確 UICC 規則或 ARF 支援的開發人員 UICC。請選擇 SIM 卡供應商,並要求對方準備具有正確 ARF 的開發人員 UICC (如本節所述),然後使用該 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 卡,且符合第三方 最新版本 GSMA TS.48 測試設定檔規格中指定的規定。

Android 12 之前的版本也可以使用同一張 SIM 卡。

修改 CTS SIM 卡設定檔

  1. 新增:存取規則應用程式主控 (ARA-M) 或 ARF 中的 CTS 運送商權限。這兩個簽章都必須在貨運公司權限規則中編碼:
    1. 雜湊 1(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:566F696365204D61696CFFFFFFFF06915155555555FF…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。舉例來說,下列裝置權杖會限制只能在裝置 abcd1234 上執行電信業者 API 測試:

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

如未提供裝置權杖,測試會在所有裝置上執行。

常見問題

如何更新 UICC 上的憑證?

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

UICC 規則可以與其他規則並用嗎?

答:在相同 AID 下,UICC 上有其他安全規則也沒關係,平台會自動篩除這些規則。

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

答:應用程式會失去權限,因為與 UICC 相關聯的規則會在移除 UICC 時遭到破壞。

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

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

使用這個方法時,支援的 API 數量是否有限制?

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

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

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

這項功能如何與多 SIM 卡功能搭配運作?

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

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

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

何時是檢查電信業者權限的好時機?

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

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

答:不會。我們認為目前的 API 是最精簡的組合,並計畫在日後使用位元遮罩,以更精細地控制權限。

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

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

injectSmsPdu 方法呼叫有什麼作用?

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

如果是簡訊篩選,onFilterSms 呼叫是否以簡訊 UDH 連接埠篩選為依據?還是電信業者應用程式可以存取所有收到的簡訊?

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

DeviceAppID-REF-DO 的擴充功能支援 32 個位元組,似乎與目前的 GP 規格 (僅允許 0 或 20 個位元組) 不相容,因此您為何要導入這項變更?SHA-1 不足以避免碰撞嗎?你是否已向 GP 提議這項變更?因為這項變更可能與現有的 ARA-M/ARF 回溯不相容。

答:為提供可因應未來需求的安全性,這個擴充功能除了 SHA-1 之外,還為 DeviceAppID-REF-DO 導入 SHA-256,目前 GP SEAC 標準僅提供 SHA-1 選項。強烈建議使用 SHA-256。

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

答:必須填入 DeviceAppID-REF-DO,才能使用電信業者 API。 留空是為了測試用途,不建議用於作業部署。

根據您的規格,PKG-REF-DO 應單獨使用,不應接受 DeviceAppID-REF-DO。但規格的表 6-4 仍將其描述為擴充 REF-DO 的定義。這是刻意設計的嗎?如果只在 REF-DO 中使用 PKG-REF-DO,程式碼的行為會如何?

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

我們假設可以授予所有以電信業者為準的權限, 或進行更精細的控管。如果是,那麼位元遮罩與實際權限之間的對應關係為何?每個課程只能有一個權限嗎?每個方法只能有一個權限嗎?從長遠來看,64 個獨立權限是否足夠?

答:這項功能預計在日後推出,歡迎提供建議。

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

答:現有規格支援DeviceAppID儲存憑證。我們盡量減少規格變更,降低採用門檻。詳情請參閱「UICC 規則」。