UICC運營商特權

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

Android 7.0擴展了此功能，以支持UICC運營商特權規則的其他存儲源，從而大大增加了可以使用API​​的運營商的數量。有關API參考，請參見CarrierConfigManager 。有關說明，請參閱運營商配置。

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

UICC規則

UICC上的存儲與GlobalPlatform安全元素訪問控制規範兼容。卡上的應用程序標識符（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 ），這是一個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

訪問規則文件（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
• 將設備模式設置為global的方法： setPreferredNetworkTypeToGlobal 。

短信管理器

允許呼叫者創建新的傳入SMS消息的方法： injectSmsPdu 。

CarrierConfigManager

通知配置更改的方法： notifyConfigChangedForSubId 。有關說明，請參閱運營商配置。

CarrierMessagingService

發送或接收新的SMS和MMS時從系統接收呼叫的服務。要擴展此類，請在清單文件中使用android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE權限聲明服務，並在#SERVICE_INTERFACE操作中包含意圖過濾器。方法包括：

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

電話提供商

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

Android平台

在檢測到的UICC上，平台構造內部UICC對象，這些對象包括運營商特權規則作為UICC的一部分。 UiccCarrierPrivilegeRules.java加載規則，從UICC卡解析規則，並將其緩存在內存中。當需要特權檢查時， UiccCarrierPrivilegeRules會將呼叫者證書與其自己的規則一一比較。如果刪除了UICC，則規則將與UICC對像一起銷毀。

驗證方式

兼容性測試套件（CTS）在CtsCarrierApiTestCases.apk包含針對運營商API的CtsCarrierApiTestCases.apk 。由於此功能取決於UICC上的證書，因此您必須準備UICC才能通過這些測試。

準備UICC

默認情況下， CtsCarrierApiTestCases.apk由Android開發人員密鑰簽名，哈希值為61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 。如果UICC上的證書不匹配，測試還將打印出預期的證書哈希。

輸出示例：

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.
Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

為了使用CtsCarrierApiTestCases.apk通過CTS驗證實現，您必須具有具有正確UICC規則或ARF支持的開發人員UICC。您可以要求您選擇的SIM卡供應商按照本節所述準備具有正確ARF的開發人員UICC，然後使用該UICC運行測試。 UICC不需要活動的蜂窩服務即可通過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時被破壞了。

UICC上的證書數量是否有限制？

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

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

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

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

答：請參閱Android兼容性定義文檔（CDD）的“ API行為兼容性”部分。我們進行了一些CTS測試，以確保未更改API的權限模型。

多SIM卡功能如何運作？

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

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

答：例如，SEEK使用與UICC相同的AID。因此，規則共存並由SEEK或UiccCarrierPrivileges過濾。

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

答：在SIM狀態加載後播放。

OEM是否可以禁用部分運營商API？

答：不能。我們認為當前的API是最小的API，並且我們計劃在將來使用位掩碼進行更精細的粒度控制。

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

答：請參閱TelephonyManager中的SPN條目

injectSmsPdu方法調用做什麼？

答：此方法有助於在雲中備份和還原SMS。 injectSmsPdu調用啟用還原功能。

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

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

DeviceAppID-REF-DO的擴展名支持32個字節似乎與當前的GP規範（僅允許0或20個字節）不兼容，那麼為什麼要引入此更改？ SHA-1是否足以避免衝突？您是否已經提議對GP進行更改，因為它可能與現有的ARA-M / ARF向後不兼容？

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

如果DeviceAppID為0（空），您是否將該規則應用於特定規則未涵蓋的所有設備應用程序？

答：運營商API要求DeviceAppID-REF-DO 。空為測試目的，不建議用於操作部署。

根據您的規範，不應接受僅使用沒有設備DeviceAppID-REF-DO PKG-REF-DO 。但是它仍然在表6-4中描述為擴展REF-DO的定義。這是故意的嗎？當在REF-DO僅使用PKG-REF-DO時，代碼的行為如何？

具有此選項：一個PKG-REF-DO作為一個單一的值項REF-DO在最新版本中被刪除。 PKG-REF-DO僅應與DeviceAppID-REF-DO結合使用。

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

答：這是為將來保留的，我們歡迎您提出建議。

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

答：現有規範支持存儲證書的DeviceAppID 。我們試圖最小化規格更改以降低採用的障礙。有關詳細信息，請參見UICC上的規則。