UICC 承運人特權

Android 5.1 引入了一種機制來授予與通用集成電路卡 (UICC) 應用程序所有者相關的 API 的特殊權限。 Android 平台加載存儲在 UICC 上的證書，並授予由這些證書籤名的應用程序調用少數特殊 API 的權限。

Android 7.0 擴展了此功能以支持 UICC 運營商權限規則的其他存儲源，從而顯著增加了可以使用 API 的運營商數量。對於API參考，請參閱CarrierConfigManager ;有關說明，請參閱載波配置。

運營商對 UICC 擁有完全控制權，因此該機制提供了一種安全靈活的方式來管理託管在通用應用分發渠道（例如 Google Play）上的移動網絡運營商 (MNO) 的應用，同時保留對設備的特殊特權，而無需使用每設備平台證書籤署應用程序或作為系統應用程序預安裝。

UICC規則

存儲在UICC是可以兼容的全球平台安全組件的訪問控制規範。卡上的應用標識符（AID）是A00000015141434C00 ，標準GET DATA命令用於獲取存儲在卡上的規則。您可以通過卡無線 (OTA) 更新來更新這些規則。

數據層次結構

UICC 規則使用以下數據層次結構（括號中的兩個字符字母和數字組合是對象標記）。每個規則是REF-AR-DO （ E2 ）和由串聯的REF-DO和AR-DO ：

• REF-DO （ E1 ）包含DeviceAppID-REF-DO或的級聯DeviceAppID-REF-DO和PKG-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

訪問規則文件 (ARF) 支持

Android 7.0 添加了對從訪問規則文件 (ARF) 讀取運營商權限規則的支持。

Android平台首先嘗試選擇訪問規則小應用程序（ARA）應用標識符（AID） A00000015141434C00 。如果它沒有找到在UICC幫助下，通過選擇PKCS15 AID回落到ARF A000000063504B43532D3135 。安卓然後讀取的訪問控制規則文件（ACRF） 0x4300和外觀與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。

電話經理

• 方法是允許承運人應用要求UICC的挑戰/響應： getIccAuthentication 。
• 方法檢查調用應用程序是否被授予特權的載體： hasCarrierPrivileges 。
• 覆蓋品牌和號碼的方法：
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• 直接 UICC 通信的方法：
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• 方法來設置設備模式為全球： setPreferredNetworkTypeToGlobal 。

短信管理器

方法允許呼叫者創建新收到的短信： injectSmsPdu 。

運營商配置管理器

方法通知配置變化： notifyConfigChangedForSubId 。有關說明，請參閱載波配置。

運營商信息服務

發送或接收新短信和彩信時從系統接聽電話的服務。為了擴展這個類中，聲明與您的清單文件中的服務android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE許可，包括與意圖過濾器#SERVICE_INTERFACE行動。方法包括：

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

電話供應商

允許修改（插入、刪除、更新、查詢）電話數據庫的內容提供者 API。值的字段是在定義Telephony.Carriers ;有關詳細信息，請參閱電話上developer.android.com API參考。

安卓平台

在檢測到的 UICC 上，平台構建內部 UICC 對象，其中包括作為 UICC 一部分的運營商特權規則。 UiccCarrierPrivilegeRules.java負載規則，分析它們從UICC卡，並在內存中緩存它們。當需要特權檢查， UiccCarrierPrivilegeRules比較有自己的規則，一個接一個來電者證書。如果移除 UICC，規則將與 UICC 對像一起銷毀。

驗證

為了驗證通過執行兼容性測試套件（CTS）使用CtsCarrierApiTestCases.apk ，你必須有正確的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測試，設備需要使用SIM卡CTS載體特權滿足第三方的最新版本規定的要求GSMA TS.48測試檔案規範。

相同的 SIM 卡也可用於 Android 12 之前的版本。

修改 CTS SIM 配置文件

1. 地址：CTS載波權限在ARA-M或ARF。兩個簽名都必須在運營商特權規則中進行編碼：
   1. 哈希1(SHA1)：61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
   2. 哈希2(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服務表：啟用服務N°47，N°48
   1. EF_UST (6F38)
      • 內容：9EFFBF1DFFFE0083410310010400406E01
4. 修改：DF-5GS和DF-SAIP文件
   1. DF-5GS - EF_5GS3GPLOCI (USIM/5FC0/4F01)
      • 內容：FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
   2. DF-5GS - EF_5GSN3GPLOCI (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 運營商特權規則或上面列出的其他修改。

• GSMA TS.48 通用測試配置文件結構
• eSIM DER 格式的 TS.48 配置文件示例

運行測試

為方便起見，CTS 支持設備令牌，該令牌將測試限制為僅在配置有相同令牌的設備上運行。電信API CTS測試支持令牌設備sim-card-with-certs 。例如，令牌限制載體API測試以下設備只在設備運行abcd1234 ：

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

在不使用設備令牌的情況下運行測試時，測試會在所有設備上運行。

常問問題

如何在 UICC 上更新證書？

A：使用現有的卡OTA更新機制。

UICC 可以與其他規則共存嗎？

A：同一個AID下的UICC有其他安全規則也可以；平台會自動過濾掉它們。

為依賴於其上的證書的應用程序移除 UICC 時會發生什麼？

A：應用程序失去權限是因為與 UICC 相關的規則在 UICC 刪除時被破壞。

UICC上的證書數量有限制嗎？

A：平台不限制證書數量；但是因為檢查是線性的，太多的規則可能會導致檢查延遲。

我們可以使用此方法支持的 API 數量是否有限制？

答：不可以，但我們將範圍限制為與運營商相關的 API。

是否有一些 API 禁止使用此方法？如果是這樣，你如何執行它們？ （也就是說，您是否有測試來驗證此方法支持哪些 API？）

答：見的“API行為相容性”部分的Android兼容性定義文件（CDD） 。我們有一些 CTS 測試來確保 API 的權限模型沒有改變。

這如何與多 SIM 卡功能配合使用？

A：使用用戶指定的默認 SIM 卡。

這是否以任何方式與其他 SE 訪問技術（例如 SEEK）交互或重疊？

答：例如，SEEK 使用與 UICC 上相同的 AID。因此，規則的並存，並通過要么尋求或過濾UiccCarrierPrivileges 。

什麼時候是檢查運營商特權的好時機？

- 答：SIM卡狀態加載後廣播。

OEM 能否禁用部分運營商 API？

A：不會。我們認為目前的API是最小集，未來我們計劃使用位掩碼進行更細粒度的控制。

不setOperatorBrandOverride覆蓋所有其他形式的運營商名稱字符串的？例如，SE13、UICC SPN 或基於網絡的 NITZ？

答：請參閱在SPN進入TelephonyManager

什麼是injectSmsPdu方法調用呢？

A：這種方式方便了雲端的短信備份/恢復。該injectSmsPdu呼叫啟用恢復功能。

對於短信過濾，是onFilterSms調用基於SMS UDH端口過濾？或者運營商應用程序是否可以訪問所有傳入的短信？

答：運營商可以訪問所有短信數據。

的延伸DeviceAppID-REF-DO ，以支持32字節似乎是不符合當前的GP規範（其允許0或20個字節僅），那麼，為什麼你引入這種變化？ SHA-1 不足以避免衝突嗎？您是否已經向 GP 提出了此更改，因為這可能與現有的 ARA-M/ARF 向後不兼容？

答：為了提供面向未來的安全性，這擴展引入SHA-256 DeviceAppID-REF-DO除了SHA-1，這是目前在GP SEAC標準的唯一選擇。我們強烈建議使用 SHA-256。

如果DeviceAppID為0（空），你將規則應用於所有設備的應用程序不屬於特定規則？

答：電信API需要DeviceAppID-REF-DO進行填充。為空是為了測試目的，不建議用於操作部署。

根據您的規格， PKG-REF-DO使用的只是本身不帶DeviceAppID-REF-DO ，不應該被接受。但它在表6-4為延伸的定義還描述REF-DO 。這是故意的嗎？如何在只有代碼的行為PKG-REF-DO在使用REF-DO ？

具有此選項：一個PKG-REF-DO作為一個單一的值項REF-DO在最新版本中被刪除。 PKG-REF-DO應該只發生在與組合DeviceAppID-REF-DO 。

我們假設我們可以授予對所有基於運營商的權限的訪問權限或更細粒度的控制。如果是這樣，什麼定義了位掩碼和實際權限之間的映射？每個班級一個權限？每個方法一個權限？從長遠來看，64 個單獨的權限是否足夠？

A：這是留著以後用的，歡迎大家提出建議。

你可以進一步定義DeviceAppID為Android特別？這是用於簽署給定應用程序的發布者證書的 SHA-1（20 字節）哈希值，因此名稱不應該反映該目的嗎？ （該名稱可能會讓許多讀者感到困惑，因為該規則適用於使用同一發布者證書籤名的所有應用程序。）

答： DeviceAppID存儲的證書是由現有的規格支持。我們試圖最大限度地減少規範更改以降低採用的障礙。有關詳細信息，請參閱在UICC規則。