UICC 電信業者權限

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

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

電信業者可以完全控制 UICC,因此這項機制可提供 以安全有彈性的方式,透過行動網路業者 (MNO) 管理應用程式 Google Play 是在通用應用程式發布管道 (例如 Google Play) 上代管 保有裝置特殊權限,也不必自行簽署應用程式 或預先安裝做為系統應用程式。

UICC 規則

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

資料階層

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。

TelephonyManager

TelephonyCallback

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

SubscriptionManager

SmsManager

電信業者 ConfigManager

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

BugreportManager

用於啟動連線能力錯誤報告的方法。這是特別版的 錯誤報告,其中僅包含用於偵錯連線相關資訊 問題: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

佈建管理員

EuiccManager

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

電信業者訊息服務

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

電信業者服務

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

平台會將 CarrierService 與特殊旗標繫結, 貨運公司服務程序 應用程式待命值區。這樣一來,您就能讓電信服務應用程式免於受到應用程式閒置限制的影響,並在裝置記憶體不足時,提高應用程式持續運作的可能性。不過,如果電信業者服務應用程式因任何原因而當機 除非應用程式重新啟動,且繫結處於繫結狀態,否則就會失去上述所有權限 重建。因此,保持電信業者服務應用程式的穩定非常重要。

CarrierService 中的方法包括:

電話服務供應商

允許修改的內容供應器 API (插入、刪除、更新、查詢) 傳送到電話資料庫值欄位會在 Telephony.Carriers 中定義;詳情請參閱 Telephony 類別參考資料

WifiNetworkSuggestion

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

Android 平台

在偵測到的 UICC 上,平台會建構內部 UICC 物件, 在 UICC 中加入電信業者權限規則。 UiccCarrierPrivilegeRules.java 會載入規則,從 UICC 卡解析規則,並將規則快取到記憶體中。時間 需要檢查權限,UiccCarrierPrivilegeRules 會比較 呼叫端憑證和本身的規則。如果移除 UICC,系統會一併刪除 UICC 物件和規則。

驗證

透過 驗證實作結果 Compatibility Test Suite (CTS) (使用 CtsCarrierApiTestCases.apk), 您必須具備正確的 UICC 規則或 ARF 支援的開發人員 UICC。 請您選擇的 SIM 卡供應商備妥開發人員 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 中執行 CTS 電信業者 API 測試 12,裝置需使用搭配 CTS 電信業者的 SIM 卡 權限符合最新版 第三方 GSMA TS.48 測試設定檔規格。

相同的 SIM 卡也能用於 Android 12。

修改 CTS SIM 卡設定檔

  1. 新增:在 存取規則應用程式主要版本 (ARA-M) 或 ARF。兩個簽名都必須 中的編碼方式是:
    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. 建立:ADF USIM 小檔案 (EF) 不存在 TS.48 和 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. 修改:使用電信業者名稱字串「Android CTS」 ,並在包含此標示的個別 EF 中:
    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 能否與其他規則並存?

答:在相同 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通話依據,是 簡訊 UDH 連接埠篩選功能?還是電信業者應用程式可以存取「所有」傳入的簡訊?

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

DeviceAppID-REF-DO 的擴充功能似乎無法支援 32 位元,與目前的 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。 空白畫面僅供測試之用,不建議用於運作 Deployment 規格

根據您的規格,PKG-REF-DO 使用了 不得使用 DeviceAppID-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 上的規則」。