Android 5.1 引入了一種機制,為與通用積體電路卡 (UICC) 應用程式擁有者相關的 API 授予特殊權限。 Android 平台載入儲存在 UICC 上的證書,並向由這些證書簽署的應用程式授予呼叫少數特殊 API 的權限。
Android 7.0 擴展了此功能,支援 UICC 運營商權限規則的其他儲存來源,從而大大增加了可以使用 API 的運營商數量。有關 API 參考,請參閱CarrierConfigManager ;有關說明,請參閱運營商配置。
運營商對UICC 擁有完全控制權,因此該機制提供了一種安全靈活的方式來管理來自移動網絡運營商(MNO) 的託管在通用應用程序分發渠道(例如穀歌 Play)上的應用程序,同時保留裝置上的特殊權限,而無需使用每個裝置平台憑證對應用程式進行簽署或預先安裝為系統應用程式。
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
),它是代表 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。
電話管理器
- 請營運商應用程式向 UICC 詢問質詢/回應的方法:
getIccAuthentication
。 - 檢查呼叫應用程式是否已被授予運營商權限的方法:
hasCarrierPrivileges
。 - 覆蓋品牌和編號的方法:
- UICC直接溝通方法:
- 將設備模式設定為全域的方法:
setPreferredNetworkTypeToGlobal
。 - 取得設備或網路身分的方法:
- 國際行動裝置識別碼 (IMEI):
getImei
- 行動裝置識別碼(MEID):
getMeid
- 網路存取識別碼 (NAI):
getNai
- SIM 序號:
getSimSerialNumber
- 國際行動裝置識別碼 (IMEI):
- 取得營運商配置的方法:
getCarrierConfig
- 取得資料傳輸的網路類型方法:
getDataNetworkType
- 取得語音服務網路類型的方法:
getVoiceNetworkType
- 取得UICC SIM(USIM)應用資訊的方法:
- SIM 序號:
getSimSerialNumber
- 卡資訊:
getUiccCardsInfo
- GID1(群組ID等級1):
getGroupIdLevel1
- 第 1 行的電話號碼字串:
getLine1Number
- 禁止的公共陸地移動網絡 (PLMN):
getForbiddenPlmns
- 等效家庭 PLMN:
getEquivalentHomePlmns
- SIM 序號:
- 取得或設定語音信箱號碼的方法:
- 傳送特殊撥號代碼的方法:
sendDialerSpecialCode
- 重置無線數據機的方法:
rebootModem
- 取得或設定網路選擇模式的方法:
- 請求網路掃描的方法:
requestNetworkScan
- 取得或設定允許/首選網路類型的方法:
- 檢查每個用戶設定是否啟用行動數據或漫遊的方法:
- 檢查或設定資料連線原因的方法:
- 取得緊急號碼清單的方法:
getEmergencyNumberList
- 控制機會網絡的方法:
- 設定或清除蜂窩訊號強度更新請求的方法:
電話回撥
TelephonyCallback
具有帶有回調方法的接口,可在註冊狀態更改時通知調用應用程式:
- 訊息等待指示器發生變化:
onMessageWaitingIndicatorChanged
- 呼叫轉移指示器改變:
onCallForwardingIndicatorChanged
- IP 多媒體系統 (IMS) 呼叫斷開原因已變更:
onImsCallDisconnectCauseChanged
- 精確資料連線狀態改變:
onPreciseDataConnectionStateChanged
- 目前緊急號碼清單已更改:
onEmergencyNumberListChanged
- 活動資料訂閱 ID 已變更:
onActiveDataSubscriptionIdChanged
- 營運商網路發生變化:
onCarrierNetworkChange
- 網路註冊或位置/路由/追蹤區域更新失敗:
onRegistrationFailed
- 限制資訊變更:
onBarringInfoChanged
- 目前實體通道配置已更改:
onPhysicalChannelConfigChanged
訂閱管理器
- 獲取各種訂閱資訊的方法:
- 取得活躍訂閱數量的方法:
getActiveSubscriptionInfoCount
- 管理訂閱組的方法:
- 取得或設定業者與特定訂戶之間的計費關係計畫描述的方法:
- 暫時覆蓋運營商和特定訂戶之間的計費關係計劃以被視為不計量的方法:
setSubscriptionOverrideUnmetered
- 暫時涵蓋營運商和特定訂戶之間的計費關係計劃以被視為擁塞的方法:
setSubscriptionOverrideCongested
- 檢查具有給定上下文的應用程式是否有權根據其元資料管理給定訂閱的方法:
canManageSubscription
簡訊管理器
- 讓呼叫者建立新傳入 SMS 訊息的方法:
injectSmsPdu
。 - 發送基於文字的 SMS 訊息而不寫入 SMS 提供者的方法:
sendTextMessageWithoutPersisting
營運商配置管理器
- 通知配置變更的方法:
notifyConfigChangedForSubId
。 - 取得預設訂閱的電信商配置的方法:
getConfig
- 取得指定訂閱的營運商配置的方法:
getConfigForSubId
有關說明,請參閱運營商配置。
錯誤報告管理器
啟動連接錯誤報告的方法,這是錯誤報告的專門版本,僅包含用於調試連接相關問題的資訊: startConnectivityBugreport
網路統計管理器
- 查詢網路使用摘要方法:
querySummary
- 查詢網路使用歷史的方法:
queryDetails
- 註冊或取消註冊網路使用回呼的方法:
ImsMm電話管理器
- 註冊或註銷IMS MmTel註冊回調的方法:
ImsRcsManager
- 註冊或註銷IMS RCS註冊回呼的方法:
- 取得 IMS 註冊狀態或傳輸類型的方法:
供應管理器
- 註冊和取消註冊 IMS 功能配置更新回呼的方法:
- 與 IMS MmTel 或 RCS 功能的設定狀態相關的方法:
Euicc管理器
切換到(啟用)給定訂閱的方法: switchToSubscription
營運商訊息服務
當發送或接收新的 SMS 和 MMS 時接收來自系統的呼叫的服務。要擴展此類,請使用android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
權限在清單文件中聲明該服務,並包含帶有#SERVICE_INTERFACE
操作的意圖過濾器。方法包括:
- 過濾入站簡訊的方法:
onFilterSms
- 攔截設備發送的簡訊方法:
onSendTextSms
- 攔截裝置發送的二進位簡訊的方法:
onSendDataSms
- 攔截設備發送的長短信的方法:
onSendMultipartTextSms
- 攔截裝置發送的彩信方法:
onSendMms
- 下載收到的彩信的方法:
onDownloadMms
承運服務
向系統公開特定於運營商的功能的服務。若要擴充此類,請使用android.Manifest.permission#BIND_CARRIER_SERVICES
權限在應用程式清單檔案中聲明該服務,並使用CARRIER_SERVICE_INTERFACE
操作包含一個意圖過濾器。如果服務具有長期綁定,請在服務的元資料中將android.service.carrier.LONG_LIVED_BINDING
設為true
。
平台將CarrierService
與特殊標誌綁定,讓Carrier服務程序在特殊的應用程式備用桶中運作。這使運營商服務應用程式免受應用程式空閒限制,並使其在設備記憶體較低時更有可能保持活動狀態。但是,如果運營商服務應用程式因任何原因崩潰,它將失去所有上述權限,直到應用程式重新啟動並重新建立綁定。因此維持營運商服務應用的穩定性至關重要。
CarrierService
中的方法包括:
- 若要覆蓋並設定運營商特定配置:
onLoadConfig
- 透過營運商應用程式通知系統即將發生的營運商網路有意更改:
notifyCarrierNetworkChange
電話服務提供者
內容提供者 API,允許對電話資料庫進行修改(插入、刪除、更新、查詢)。值字段在Telephony.Carriers
中定義;有關更多詳細信息,請參閱Telephony
類參考
Wifi網路建議
建構WifiNetworkSuggestion
物件時,可以使用以下方法設定訂閱ID或訂閱群組:
- 設定訂閱ID的方法:
setSubscriptionId
- 設定訂閱組的方法:
setSubscriptionGroup
安卓平台
在偵測到的 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 測試設定檔規格中指定的要求。
同樣的 SIM 卡也可用於 Android 12 之前的版本。
修改 CTS SIM 設定檔
- 新增:存取規則應用主控 (ARA-M) 或 ARF 中的 CTS 運營商權限。兩個簽名都必須在運營商特權規則中進行編碼:
-
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
-
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
-
- 建立: TS.48 中不存在且 CTS 需要的 ADF USIM 基本檔案 (EF):
- EF_MBDN (6FC7),記錄大小:28,記錄數量:4
- 內容
- 記錄1:566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-n:FF…FF
- 內容
- EF_EXT6 (6FC8),記錄大小:13,記錄數量:1
- 內容:00FF…FF
- EF_MBI (6FC9),記錄大小:4,記錄數量:1
- 內容:Rec1:01010101
- EF_MWIS (6FCA),記錄大小:5,記錄數量:1
- 內容:0000000000
- 內容:00FF…FF
- EF_MBDN (6FC7),記錄大小:28,記錄數量:4
- 修改: USIM服務表:啟用服務n°47、n°48
- EF_UST (6F38)
- 內容:
9EFFBF1DFFFE0083410310010400406E01
- 內容:
- EF_UST (6F38)
- 修改: DF-5GS 和 DF-SAIP 文件
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- 內容:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- 內容:
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- 內容:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- 內容:
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- 內容:
A0020000FF…FF
- 內容:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- 內容:
A0020000FF…FF
- 內容:
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- 修改:在包含此名稱的各個 EF 中使用運營商名稱字串Android CTS :
- EF_SPN(USIM/6F46)
- 內容:
01416E64726F696420435453FF..FF
- 內容:
- EF_PNN(USIM/6FC5)
- 內容:
Rec1 430B83413759FE4E934143EA14FF..FF
- 內容:
- EF_SPN(USIM/6F46)
匹配測試設定檔結構
下載並符合以下通用測試設定檔結構的最新版本。這些設定檔不會有個人化的 CTS 業者特權規則或上面列出的其他修改。
運行測試
為了方便起見,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 證書的應用程式被刪除時會發生什麼?
答:應用程式會失去其權限,因為與 UICC 關聯的規則在 UICC 刪除時被破壞。
UICC 上的證書數量有限制嗎?
A:平台不限制證書數量;但由於檢查是線性的,過多的規則可能會導致檢查延遲。
我們可以使用此方法支援的 API 數量是否有限制?
答:不可以,但我們將範圍限制為與營運商相關的 API。
是否有一些 API 被禁止使用此方法?如果是這樣,你如何執行它們? (也就是說,您是否有測試來驗證此方法支援哪些 API?)
答:請參閱 Android 相容性定義文件 (CDD) 的API 行為相容性部分。我們進行了一些 CTS 測試,以確保 API 的權限模型不會變更。
它如何與多 SIM 卡功能配合使用?
A:使用使用者指定的預設SIM卡。
這是否與其他 SE 存取技術(例如 SEEK)相互作用或重疊?
答:舉個例子,SEEK 使用與 UICC 上相同的 AID。因此,規則共存並透過 SEEK 或UiccCarrierPrivileges
進行過濾。
什麼時候是檢查運營商特權的好時機?
A:SIM狀態載入廣播後。
OEM 可以停用部分電信商 API 嗎?
A:不會。我們認為目前的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(目前 GP SEAC 標準中的唯一選項)之外,此擴充功能還為DeviceAppID-REF-DO
引入了 SHA-256。我們強烈建議使用 SHA-256。
如果DeviceAppID
為 0(空),是否將該規則套用於特定規則未涵蓋的所有裝置應用程式?
答:運營商 API 需要填入DeviceAppID-REF-DO
。為空旨在用於測試目的,不建議用於操作部署。
根據您的規範,不應接受僅單獨使用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 個單獨的權限足夠嗎?
A:這是為將來保留的,我們歡迎提出建議。
能否進一步專門為Android定義DeviceAppID
?這是用於簽署給定應用程式的發布者憑證的 SHA-1(20 位元組)雜湊值,因此該名稱不應該反映該目的嗎? (該名稱可能會讓許多讀者感到困惑,因為該規則適用於使用同一發布者憑證簽署的所有應用程式。)
A:現有規格支援DeviceAppID
儲存憑證。我們試圖盡量減少規範更改,以降低採用的障礙。詳情請參閱UICC 規則。