Đặc quyền của nhà mạng đối với UICC

Android 5.1 đã giới thiệu một cơ chế cấp đặc quyền cho các API liên quan đến chủ sở hữu của các ứng dụng thẻ vi mạch tích hợp đa năng (UICC). Nền tảng Android tải các chứng chỉ được lưu trữ trên UICC và cấp quyền cho các ứng dụng được ký bằng những chứng chỉ này để gọi một số API đặc biệt.

Android 7.0 đã mở rộng tính năng này để hỗ trợ các nguồn lưu trữ khác cho các quy tắc đặc quyền của nhà mạng UICC, giúp tăng đáng kể số lượng nhà mạng có thể sử dụng các API này. Để biết thông tin tham khảo về API, hãy xem CarrierConfigManager; để biết hướng dẫn, hãy xem Cấu hình nhà mạng.

Nhà mạng có toàn quyền kiểm soát UICC, vì vậy cơ chế này mang đến một cách thức an toàn và linh hoạt để quản lý các ứng dụng của nhà mạng di động (MNO) được lưu trữ trên các kênh phân phối ứng dụng chung (chẳng hạn như Google Play) trong khi vẫn giữ được các đặc quyền trên thiết bị và không cần ký ứng dụng bằng chứng chỉ nền tảng cho từng thiết bị hoặc cài đặt sẵn dưới dạng ứng dụng hệ thống.

Quy tắc về UICC

Bộ nhớ trên UICC tương thích với quy cách Kiểm soát quyền truy cập vào phần tử bảo mật GlobalPlatform. Giá trị nhận dạng ứng dụng (AID) trên thẻ là A00000015141434C00 và lệnh tiêu chuẩn GET DATA được dùng để tìm nạp các quy tắc được lưu trữ trên thẻ. Bạn có thể cập nhật các quy tắc này thông qua các bản cập nhật thẻ qua mạng không dây (OTA).

Hệ phân cấp dữ liệu

Các quy tắc UICC sử dụng hệ thống phân cấp dữ liệu sau (tổ hợp chữ cái và số có 2 ký tự trong dấu ngoặc đơn là thẻ đối tượng). Mỗi quy tắc là REF-AR-DO (E2) và bao gồm một chuỗi nối của REF-DO và AR-DO:

  • REF-DO (E1) chứa DeviceAppID-REF-DO hoặc một chuỗi nối của DeviceAppID-REF-DO và PKG-REF-DO.
    • DeviceAppID-REF-DO (C1) lưu trữ chữ ký SHA-1 (20 byte) hoặc SHA-256 (32 byte) của chứng chỉ.
    • PKG-REF-DO (CA) là chuỗi tên gói đầy đủ được xác định trong tệp kê khai, được mã hoá bằng ASCII, độ dài tối đa là 127 byte.
  • AR-DO (E3) được mở rộng để bao gồm PERM-AR-DO (DB), là một mặt nạ bit 8 byte đại diện cho 64 quyền riêng biệt.

Nếu không có PKG-REF-DO, mọi ứng dụng được ký bằng chứng chỉ đều được cấp quyền truy cập; nếu không, cả chứng chỉ và tên gói đều phải khớp.

Ví dụ về quy tắc

Tên ứng dụng là com.google.android.apps.myapp và chứng chỉ SHA-1 ở dạng chuỗi thập lục phân là:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

Quy tắc về UICC trong chuỗi hex là:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

Hỗ trợ tệp quy tắc truy cập

Android 7.0 bổ sung tính năng hỗ trợ đọc các quy tắc đặc quyền của nhà mạng từ tệp quy tắc truy cập (ARF).

Nền tảng Android trước tiên sẽ cố gắng chọn AID A00000015141434C00 của ứng dụng quy tắc truy cập (ARA). Nếu không tìm thấy AID trên UICC, thì ứng dụng sẽ quay lại ARF bằng cách chọn AID PKCS15 A000000063504B43532D3135. Sau đó, Android sẽ đọc tệp quy tắc kiểm soát quyền truy cập (ACRF) tại 0x4300 và tìm các mục có AID FFFFFFFFFFFF. Các mục có AID khác nhau sẽ bị bỏ qua, vì vậy, các quy tắc cho các trường hợp sử dụng khác có thể cùng tồn tại.

Ví dụ về nội dung ACRF ở dạng chuỗi hex:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

Ví dụ về nội dung tệp điều kiện kiểm soát quyền truy cập (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

Trong ví dụ trên, 0x4310 là địa chỉ của ACCF, chứa hàm băm chứng chỉ 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Các ứng dụng được ký bằng chứng chỉ này sẽ được cấp đặc quyền của nhà mạng.

Các API đã bật

Android hỗ trợ các API sau.

TelephonyManager

TelephonyCallback

TelephonyCallback có các giao diện với một phương thức gọi lại để thông báo cho ứng dụng gọi khi các trạng thái đã đăng ký thay đổi:

SubscriptionManager

SmsManager

  • Phương thức cho phép người gọi tạo tin nhắn SMS đến mới: injectSmsPdu.
  • Phương thức gửi tin nhắn SMS dựa trên văn bản mà không cần ghi vào trình cung cấp SMS: sendTextMessageWithoutPersisting

CarrierConfigManager

  • Phương thức thông báo cấu hình đã thay đổi: notifyConfigChangedForSubId.
  • Phương thức để nhận cấu hình nhà mạng cho gói thuê bao mặc định: getConfig
  • Phương thức để nhận cấu hình nhà mạng cho gói thuê bao đã chỉ định: getConfigForSubId

Để biết hướng dẫn, hãy xem phần Cấu hình nhà mạng.

BugreportManager

Phương thức bắt đầu báo cáo lỗi kết nối. Đây là một phiên bản chuyên biệt của báo cáo lỗi, chỉ bao gồm thông tin để gỡ lỗi các vấn đề liên quan đến kết nối: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

Phương thức chuyển sang (bật) gói thuê bao đã cho: switchToSubscription

CarrierMessagingService

Dịch vụ nhận các lệnh gọi từ hệ thống khi tin nhắn SMS và MMS mới được gửi hoặc nhận. Để mở rộng lớp này, hãy khai báo dịch vụ trong tệp kê khai bằng quyền android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE và thêm một bộ lọc ý định có thao tác #SERVICE_INTERFACE. Bạn có thể thực hiện các phương thức như:

  • Phương thức lọc tin nhắn SMS đến: onFilterSms
  • Phương thức chặn tin nhắn SMS văn bản được gửi từ thiết bị: onSendTextSms
  • Phương thức chặn tin nhắn SMS nhị phân được gửi từ thiết bị: onSendDataSms
  • Phương thức chặn tin nhắn SMS dài được gửi từ thiết bị: onSendMultipartTextSms
  • Phương thức chặn tin nhắn MMS được gửi từ thiết bị: onSendMms
  • Cách tải tin nhắn MMS đã nhận xuống: onDownloadMms

CarrierService

Dịch vụ cung cấp các chức năng dành riêng cho nhà mạng cho hệ thống. Để mở rộng lớp này, hãy khai báo dịch vụ trong tệp kê khai ứng dụng bằng quyền android.Manifest.permission#BIND_CARRIER_SERVICES và đưa bộ lọc ý định vào với thao tác CARRIER_SERVICE_INTERFACE. Nếu dịch vụ có một liên kết tồn tại lâu dài, hãy đặt android.service.carrier.LONG_LIVED_BINDING thành true trong siêu dữ liệu của dịch vụ.

Nền tảng này liên kết CarrierService với các cờ đặc biệt để cho phép dịch vụ của nhà mạng chạy trong một nhóm ứng dụng ở trạng thái chờ đặc biệt. Điều này giúp ứng dụng dịch vụ của nhà mạng không phải chịu hạn chế về trạng thái chờ của ứng dụng và có nhiều khả năng vẫn hoạt động khi bộ nhớ thiết bị sắp hết. Tuy nhiên, nếu ứng dụng dịch vụ của hãng vận chuyển gặp sự cố vì bất kỳ lý do nào, ứng dụng đó sẽ mất tất cả các đặc quyền nêu trên cho đến khi khởi động lại và thiết lập lại mối liên kết. Vì vậy, điều quan trọng là phải duy trì sự ổn định của ứng dụng dịch vụ nhà mạng.

Các phương thức trong CarrierService bao gồm:

  • Để ghi đè và đặt cấu hình cụ thể của nhà mạng: onLoadConfig
  • Để thông báo cho hệ thống về việc ứng dụng nhà mạng sắp thay đổi mạng của nhà mạng theo ý muốn: notifyCarrierNetworkChange

Nhà cung cấp dịch vụ điện thoại

API nhà cung cấp nội dung để cho phép sửa đổi (chèn, xoá, cập nhật, truy vấn) đối với cơ sở dữ liệu điện thoại. Các trường giá trị được xác định tại Telephony.Carriers; để biết thêm thông tin chi tiết, hãy tham khảo tài liệu tham khảo về lớp Telephony

WifiNetworkSuggestion

Khi tạo một đối tượng WifiNetworkSuggestion, hãy dùng các phương thức sau để đặt mã nhận dạng gói thuê bao hoặc nhóm gói thuê bao:

Nền tảng Android

Trên một UICC được phát hiện, nền tảng sẽ tạo các đối tượng UICC nội bộ bao gồm các quy tắc đặc quyền của nhà mạng trong UICC. UiccCarrierPrivilegeRules.java tải các quy tắc, phân tích cú pháp các quy tắc đó từ thẻ UICC và lưu các quy tắc đó vào bộ nhớ đệm. Khi cần kiểm tra đặc quyền, UiccCarrierPrivilegeRules sẽ so sánh chứng chỉ của phương thức gọi với các quy tắc của chính nó từng quy tắc một. Nếu UICC bị xoá, các quy tắc sẽ bị huỷ cùng với đối tượng UICC.

Xác nhận kết quả

Để xác thực việc triển khai thông qua Bộ kiểm tra tính tương thích (CTS) bằng CtsCarrierApiTestCases.apk, bạn phải có UICC của nhà phát triển với các quy tắc UICC hoặc khả năng hỗ trợ ARF phù hợp. Yêu cầu nhà cung cấp thẻ SIM mà bạn chọn chuẩn bị một UICC cho nhà phát triển có ARF phù hợp như mô tả trong phần này và sử dụng UICC đó để chạy các kiểm thử. UICC không yêu cầu dịch vụ di động đang hoạt động để vượt qua các bài kiểm thử CTS.

Chuẩn bị UICC

Đối với Android 11 trở xuống, CtsCarrierApiTestCases.apk được aosp-testkey ký bằng giá trị băm 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81.

Kể từ Android 12, CtsCarrierApiTestCases.apk được ký bằng cts-uicc-2021-testkey, giá trị băm 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.

Để chạy các bài kiểm thử API nhà mạng CTS trong Android 12, thiết bị cần sử dụng một SIM có đặc quyền nhà mạng CTS đáp ứng các yêu cầu được chỉ định trong phiên bản mới nhất của thông số kỹ thuật Hồ sơ kiểm thử GSMA TS.48 của bên thứ ba.

Bạn cũng có thể dùng cùng một SIM cho các phiên bản trước Android 12.

Sửa đổi hồ sơ SIM CTS

  1. Thêm: Đặc quyền của nhà mạng CTS trong ứng dụng chính của quy tắc truy cập (ARA-M) hoặc ARF. Cả hai chữ ký đều phải được mã hoá trong các quy tắc về đặc quyền của nhà mạng:
    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. Tạo: Các tệp cơ bản (EF) ADF USIM không có trong TS.48 và cần thiết cho CTS:
    1. EF_MBDN (6FC7), kích thước bản ghi: 28, số bản ghi: 4 
      • Nội dung
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), kích thước bản ghi:13, số bản ghi: 1 
      • Nội dung: 00FF…FF
        1. EF_MBI (6FC9), kích thước bản ghi: 4, số bản ghi: 1
      • Nội dung: Rec1: 01010101
        1. EF_MWIS (6FCA), kích thước bản ghi: 5, số bản ghi: 1
      • Nội dung: 0000000000
  3. Sửa đổi: Bảng dịch vụ USIM: Bật các dịch vụ số 47, số 48
    1. EF_UST (6F38)
      • Nội dung: 9EFFBF1DFFFE0083410310010400406E01
  4. Sửa đổi: Tệp DF-5GS và DF-SAIP
    1. DF-5GS – EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Nội dung: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS – EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Nội dung: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS – EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Nội dung: A0020000FF…FF
    4. DF-SAIP – EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Nội dung: A0020000FF…FF
  5. Sửa đổi: Sử dụng chuỗi tên nhà mạng Android CTS trong các EF tương ứng có chứa tên gọi này:
    1. EF_SPN (USIM/6F46)
      • Nội dung: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Nội dung: Rec1 430B83413759FE4E934143EA14FF..FF

Khớp cấu trúc hồ sơ kiểm thử

Tải xuống và so khớp phiên bản mới nhất của các cấu trúc hồ sơ kiểm thử chung sau đây. Những hồ sơ này sẽ không có quy tắc đặc quyền của nhà mạng CTS được cá nhân hoá hoặc các sửa đổi khác như đã nêu ở trên.

Chạy chương trình kiểm thử

Để thuận tiện, CTS hỗ trợ mã thông báo thiết bị giúp hạn chế các kiểm thử chỉ chạy trên những thiết bị được định cấu hình bằng cùng một mã thông báo. Các kiểm thử CTS của Carrier API hỗ trợ mã thông báo thiết bị sim-card-with-certs. Ví dụ: mã thông báo thiết bị sau đây chỉ cho phép chạy các kiểm thử API của nhà mạng trên thiết bị abcd1234:

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

Khi bạn chạy một kiểm thử mà không dùng mã thông báo thiết bị, kiểm thử sẽ chạy trên tất cả các thiết bị.

Câu hỏi thường gặp

Làm cách nào để cập nhật chứng chỉ trên UICC?

A: Sử dụng cơ chế cập nhật OTA hiện có cho thẻ.

UICC có thể cùng tồn tại với các quy tắc khác không?

Đáp: Bạn có thể đặt các quy tắc bảo mật khác trên UICC trong cùng một AID; nền tảng sẽ tự động lọc các quy tắc đó.

Điều gì sẽ xảy ra khi UICC bị xoá đối với một ứng dụng dựa vào các chứng chỉ trên đó?

Đáp: Ứng dụng sẽ mất các đặc quyền vì các quy tắc liên kết với UICC sẽ bị huỷ khi UICC bị xoá.

Có giới hạn về số lượng chứng chỉ trên UICC không?

Đáp: Nền tảng này không giới hạn số lượng chứng chỉ; nhưng vì quy trình kiểm tra là tuyến tính, nên quá nhiều quy tắc có thể gây ra độ trễ cho quy trình kiểm tra.

Có giới hạn nào về số lượng API mà chúng tôi có thể hỗ trợ bằng phương thức này không?

Đáp: Không, nhưng chúng tôi giới hạn phạm vi đối với các API liên quan đến hãng vận chuyển.

Có API nào bị cấm sử dụng phương thức này không? Nếu có, bạn thực thi các quy tắc đó như thế nào? (tức là bạn có các kiểm thử để xác thực những API được hỗ trợ bằng phương thức này không?)

Đáp: Hãy xem phần Khả năng tương thích về hành vi của API trong Tài liệu định nghĩa về khả năng tương thích (CDD) của Android. Chúng tôi có một số kiểm thử CTS để đảm bảo rằng mô hình quyền của các API không thay đổi.

Tính năng này hoạt động như thế nào với tính năng nhiều SIM?

Đáp: SIM mặc định do người dùng chỉ định sẽ được sử dụng.

Liệu công nghệ này có tương tác hoặc trùng lặp với các công nghệ truy cập SE khác theo cách nào đó hay không, chẳng hạn như SEEK?

Đáp: Ví dụ: SEEK sử dụng cùng một AID như trên UICC. Do đó, các quy tắc cùng tồn tại và được lọc theo SEEK hoặc UiccCarrierPrivileges.

Thời điểm thích hợp để kiểm tra đặc quyền của nhà mạng là khi nào?

Đáp: Sau khi trạng thái SIM được tải xuống.

Nhà sản xuất thiết bị gốc (OEM) có thể tắt một phần của API nhà mạng không?

Đáp: Không. Chúng tôi tin rằng các API hiện tại là tập hợp tối thiểu và chúng tôi dự định sử dụng mặt nạ bit để kiểm soát độ chi tiết tốt hơn trong tương lai.

setOperatorBrandOverride có ghi đè TẤT CẢ các dạng chuỗi tên toán tử khác không? Ví dụ: SE13, UICC SPN hoặc NITZ dựa trên mạng?

Có, chế độ ghi đè thương hiệu của nhà mạng có mức độ ưu tiên cao nhất. Khi được đặt, giá trị này sẽ thay thế TẤT CẢ các dạng chuỗi tên toán tử khác.

Phương thức injectSmsPdu gọi có chức năng gì?

Đáp: Phương thức này hỗ trợ việc sao lưu/khôi phục tin nhắn SMS trên đám mây. Lệnh gọi injectSmsPdu cho phép chức năng khôi phục.

Đối với tính năng lọc SMS, lệnh gọi onFilterSms có dựa trên tính năng lọc cổng UDH của SMS không? Hoặc các ứng dụng của nhà mạng có quyền truy cập vào TẤT CẢ tin nhắn SMS đến không?

Đáp: Nhà mạng có quyền truy cập vào tất cả dữ liệu SMS.

Việc mở rộng DeviceAppID-REF-DO để hỗ trợ 32 byte có vẻ không tương thích với quy cách GP hiện tại (chỉ cho phép 0 hoặc 20 byte). Vậy tại sao bạn lại giới thiệu thay đổi này? SHA-1 có đủ để tránh xung đột không? Bạn đã đề xuất thay đổi này cho GP chưa, vì thay đổi này có thể không tương thích ngược với ARA-M/ARF hiện có?

Đáp: Để đảm bảo an toàn trong tương lai, tiện ích này giới thiệu SHA-256 cho DeviceAppID-REF-DO ngoài SHA-1. Hiện tại, SHA-1 là lựa chọn duy nhất trong tiêu chuẩn GP SEAC. Bạn nên sử dụng SHA-256.

Nếu DeviceAppID là 0 (trống), bạn có áp dụng quy tắc cho tất cả các ứng dụng trên thiết bị không thuộc một quy tắc cụ thể không?

Đáp: Các API của hãng vận chuyển yêu cầu bạn điền thông tin về DeviceAppID-REF-DO. Việc để trống là dành cho mục đích kiểm thử và không được khuyến khích cho các hoạt động triển khai.

Theo quy cách của bạn, PKG-REF-DO chỉ được dùng một mình mà không có DeviceAppID-REF-DO thì không được chấp nhận. Nhưng nó vẫn được mô tả trong Bảng 6-4 của quy cách là mở rộng định nghĩa của REF-DO. Việc này có chủ đích không? Mã này hoạt động như thế nào khi chỉ có PKG-REF-DO được dùng trong REF-DO?

Đáp: Lựa chọn có PKG-REF-DO dưới dạng một mục có giá trị duy nhất trong REF-DO đã bị xoá trong phiên bản mới nhất. PKG-REF-DO chỉ được xuất hiện khi kết hợp với DeviceAppID-REF-DO.

Chúng tôi giả định rằng chúng tôi có thể cấp quyền truy cập vào tất cả các quyền dựa trên nhà mạng hoặc có quyền kiểm soát chi tiết hơn. Nếu có, điều gì xác định mối liên kết giữa mặt nạ bit và các quyền thực tế? Mỗi lớp học có một quyền? Mỗi phương thức có một quyền? Liệu 64 quyền riêng biệt có đủ trong thời gian dài không?

Đáp: Đây là tính năng dành cho tương lai và chúng tôi rất mong nhận được đề xuất của bạn.

Bạn có thể xác định thêm DeviceAppID cho Android một cách cụ thể không? Đây là giá trị băm SHA-1 (20 byte) của chứng chỉ Nhà xuất bản dùng để ký ứng dụng đã cho, vậy tên này có phản ánh mục đích đó không? (Tên này có thể gây nhầm lẫn cho nhiều người đọc vì quy tắc này sẽ áp dụng cho tất cả các ứng dụng được ký bằng cùng một chứng chỉ Nhà xuất bản.)

Đáp: DeviceAppID lưu trữ chứng chỉ được hỗ trợ theo quy cách hiện có. Chúng tôi đã cố gắng giảm thiểu các thay đổi về quy cách để giảm rào cản khi áp dụng. Để biết thông tin chi tiết, hãy xem Quy tắc về UICC.