Đặc quyền của nhà cung cấp dịch vụ UICC

Android 5.1 đã giới thiệu cơ chế cấp các đặc quyền đặc biệt cho các API liên quan đến chủ sở hữu ứng dụng thẻ mạch tích hợp phổ quát (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 các chứng chỉ này ký để thực hiện lệnh gọi tớ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à cung cấp dịch vụ UICC, tăng đáng kể số lượng nhà cung cấp dịch vụ có thể sử dụng API. Để tham khảo API, hãy xem CarrierConfigManager ; để biết hướng dẫn, hãy xem Cấu hình nhà cung cấp dịch vụ .

Nhà cung cấp dịch vụ có toàn quyền kiểm soát UICC, vì vậy cơ chế này cung cấp một cách an toàn và linh hoạt để quản lý ứng dụng từ nhà điều hà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 thiết để ký ứng dụng bằng chứng chỉ nền tảng trên mỗi thiết bị hoặc cài đặt sẵn dưới dạng ứng dụng hệ thống.

Quy định về UICC

Bộ lưu trữ trên UICC tương thích với thông số Kiểm soát truy cập phần tử bảo mật GlobalPlatform . Mã định danh ứng dụng (AID) trên thẻ là A00000015141434C00 và lệnh GET DATA tiêu chuẩn được sử 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ập nhật thẻ qua mạng (OTA).

Phân cấp dữ liệu

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ố gồm hai ký tự trong ngoặc đơn là thẻ đối tượng). Mỗi quy tắc là REF-AR-DO ( E2 ) và bao gồm sự kết hợp của REF-DOAR-DO :

  • REF-DO ( E1 ) chứa DeviceAppID-REF-DO hoặc sự kết hợp của DeviceAppID-REF-DOPKG-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ã hóa ASCII, độ dài tối đa 127 byte.
  • AR-DO ( E3 ) được mở rộng để bao gồm PERM-AR-DO ( DB ), là 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 thì mọi ứng dụng được ký bởi chứng chỉ đều được cấp quyền truy cập; nếu không thì 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 hex 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 hỗ trợ đọc các quy tắc đặc quyền của nhà cung cấp dịch vụ 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 ứng dụng quy tắc truy cập (ARA) AID A00000015141434C00 . Nếu nó không tìm thấy AID trên UICC, nó sẽ quay trở lại ARF bằng cách chọn PKCS15 AID A000000063504B43532D3135 . Sau đó, Android đọc tệp quy tắc kiểm soát truy cập (ACRF) ở 0x4300 và tìm kiếm các mục có AID FFFFFFFFFFFF . Các mục nhập có AID khác nhau sẽ bị bỏ qua, do đó 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ụ nội dung ACRF trong 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 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ởi chứng chỉ này được cấp đặc quyền của nhà cung cấp dịch vụ.

API đã bật

Android hỗ trợ các API sau.

Trình quản lý điện thoại

Điện ThoạiGọi Lại

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

Trình quản lý đăng ký

Trình quản lý tin nhắn

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

CarrierConfigManager

  • Phương thức thông báo cấu hình thay đổi: notifyConfigChangedForSubId .
  • Phương pháp lấy cấu hình nhà cung cấp dịch vụ cho thuê bao mặc định: getConfig
  • Phương thức lấy cấu hình nhà cung cấp dịch vụ cho thuê bao được chỉ định: getConfigForSubId

Để biết hướng dẫn, hãy xem Cấu hình nhà cung cấp dịch vụ .

Trình quản lý báo cáo lỗi

Phương pháp bắt đầu báo cáo lỗi kết nối, đây là 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

Trình quản lý thống kê mạng

ImsMmTelQuản lý

ImsRcsTrình quản lý

Trình quản lý cấp phép

EuiccQuản lý

Phương thức chuyển sang (kích hoạt) đăng ký đã cho: switchToSubscription

Dịch vụ nhắn tin của nhà cung cấp dịch vụ

Dịch vụ nhận cuộc gọi từ hệ thống khi có tin nhắn SMS, 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 của bạn với quyền android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE và bao gồm bộ lọc ý định với hành động #SERVICE_INTERFACE . Các phương pháp bao gồm:

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

Dịch vụ vận chuyển

Dịch vụ cung cấp các chức năng dành riêng cho nhà cung cấp dịch vụ 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 với quyền android.Manifest.permission#BIND_CARRIER_SERVICES và bao gồm bộ lọc ý định bằng hành động CARRIER_SERVICE_INTERFACE . Nếu dịch vụ có ràng buộc 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 liên kết CarrierService bằng các cờ đặc biệt để cho phép quy trình dịch vụ của nhà cung cấp dịch vụ chạy trong nhóm dự phòng ứng dụng đặc biệt. Điều này giúp ứng dụng dịch vụ của nhà cung cấp dịch vụ không bị hạn chế khi không hoạt động và khiến ứng dụng có nhiều khả năng tồn tại hơn khi bộ nhớ thiết bị sắp hết. Tuy nhiên, nếu ứng dụng dịch vụ của nhà mạng gặp sự cố vì bất kỳ lý do gì, nó sẽ mất tất cả các đặc quyền trên cho đến khi ứng dụng khởi động lại và liên kết được thiết lập lại. Vì vậy, điều quan trọng là giữ cho ứng dụng dịch vụ của nhà cung cấp dịch vụ ổn định.

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

  • Để ghi đè và đặt cấu hình cụ thể của nhà cung cấp dịch vụ: onLoadConfig
  • Để thông báo cho hệ thống về sự thay đổi mạng của nhà cung cấp dịch vụ sắp tới có chủ ý bằng ứng dụng của nhà cung cấp dịch vụ: notifyCarrierNetworkChange

Nhà cung cấp điện thoại

API nhà cung cấp nội dung để cho phép sửa đổi (chèn, xóa, cập nhật, truy vấn) 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 chi tiết, hãy tham khảo tài liệu tham khảo lớp Telephony

WifiMạngĐề xuất

Khi xây dựng đối tượng WifiNetworkSuggestion , hãy sử dụng các phương pháp sau để đặt ID đăng ký hoặc nhóm đăng ký:

Nền tảng Android

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

Thẩm định

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

Chuẩn bị UICC

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

Bắt đầu từ Android 12, CtsCarrierApiTestCases.apk được ký bởi 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 thử nghiệm API nhà cung cấp dịch vụ CTS trong Android 12, thiết bị cần sử dụng SIM có đặc quyền của nhà cung cấp dịch vụ 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ố Hồ sơ thử nghiệm GSMA TS.48 của bên thứ ba.

SIM tương tự cũng có thể được sử dụng cho các phiên bản trước Android 12.

Sửa đổi cấu hình SIM CTS

  1. Thêm: Đặc quyền của nhà cung cấp dịch vụ CTS trong ứng dụng chính của quy tắc truy cập (ARA-M) hoặc ARF. Cả hai chữ ký phải được mã hóa theo quy tắc đặc quyền của nhà cung cấp dịch vụ:
    1. Giá trị băm1(SHA1) 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. 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 ADF USIM (EF) 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: Kích hoạt dịch vụ n°47, n°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à cung cấp dịch vụ Android CTS trong các EF tương ứng có chứa ký hiệu này:
    1. EF_SPN (USIM/6F46)
      • Nội dung: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Nội dung: Rec1 430B83413759FE4E934143EA14FF..FF

Phù hợp với cấu trúc hồ sơ thử nghiệm

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

Chạy thử nghiệm

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

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

Khi chạy thử nghiệm mà không sử dụng mã thông báo thiết bị, thử nghiệm 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 thẻ hiện có.

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

Đáp: Việc có các quy tắc bảo mật khác trên UICC dưới cùng một AID là điều bình thường; nền tảng sẽ tự động lọc chúng ra.

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

Trả lời: Ứng dụng sẽ mất các đặc quyền vì các quy tắc liên quan đến UICC bị hủy khi xóa UICC.

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

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

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

Đáp: Không, nhưng chúng tôi giới hạn phạm vi ở các API liên quan đến nhà cung cấp dịch vụ.

Có một số API bị cấm sử dụng phương pháp này không? Nếu vậy, làm thế nào để bạn thực thi chúng? (nghĩa là bạn có các bài kiểm tra để xác thực API nào được hỗ trợ bằng phương pháp này không?)

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

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

Trả lời: SIM mặc định do người dùng chỉ định sẽ được sử dụng.

Điều 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, chẳng hạn như SEEK theo bất kỳ cách nào không?

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

Khi nào là thời điểm tốt để kiểm tra đặc quyền của nhà cung cấp dịch vụ?

A: Sau khi phát sóng trạng thái SIM.

OEM có thể vô hiệu hóa một phần API của nhà cung cấp dịch vụ 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ó, việc ghi đè thương hiệu của nhà điều hành có mức độ ưu tiên cao nhất. Khi được đặt, nó sẽ ghi đè TẤT CẢ các dạng chuỗi tên toán tử khác.

Lệnh gọi phương thức injectSmsPdu có tác dụng gì?

Trả lời: Phương pháp này tạo điều kiện thuận lợi cho việc sao lưu/khôi phục SMS trên đám mây. Lệnh gọi injectSmsPdu kích hoạt chức năng khôi phục.

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

Đáp: Các nhà cung cấp dịch vụ có quyền truy cập vào tất cả dữ liệu SMS.

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

Đáp: Để cung cấp khả năng bảo mật vững chắc trong tương lai, tiện ích mở rộng này giới thiệu SHA-256 cho DeviceAppID-REF-DO bên cạnh SHA-1, hiện là tùy chọn duy nhất trong tiêu chuẩn GP SEAC. Chúng tôi khuyên 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 này cho tất cả các ứng dụng trên thiết bị không nằm trong quy tắc cụ thể không?

Đáp: API của nhà cung cấp dịch vụ yêu cầu phải điền DeviceAppID-REF-DO . Việc để trống nhằm mục đích thử nghiệm và không được khuyến nghị cho việc triển khai hoạt động.

Theo thông số kỹ thuật của bạn, PKG-REF-DO chỉ được sử dụng mà không có DeviceAppID-REF-DO , không nên được chấp nhận. Nhưng nó vẫn được mô tả trong Bảng 6-4 của đặc tả như là mở rộng định nghĩa của REF-DO . Đây có phải là mục đích? Mã hoạt động như thế nào khi chỉ sử dụng PKG-REF-DO trong REF-DO ?

Trả lời: Tùy chọn có PKG-REF-DO làm mục giá trị duy nhất trong REF-DO đã bị xóa trong phiên bản mới nhất. PKG-REF-DO chỉ nên xảy ra 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à cung cấp dịch vụ hoặc có quyền kiểm soát chi tiết hơn. Nếu vậy, điều gì xác định ánh xạ giữa mặt nạ bit và các quyền thực tế? Một quyền cho mỗi lớp? Một quyền cho mỗi phương pháp? 64 quyền riêng biệt có đủ về lâu dài không?

Đáp: Điều này được dành riêng cho tương lai và chúng tôi hoan nghênh các đề xuất.

Bạn có thể xác định thêm cụ thể DeviceAppID cho Android không? Đây là giá trị băm SHA-1 (20 byte) của chứng chỉ Nhà xuất bản được sử dụng để ký ứng dụng nhất định, vậy tên 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ì khi đó quy tắc sẽ được á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 đó.)

Trả lời: Chứng chỉ lưu trữ DeviceAppID được hỗ trợ bởi thông số kỹ thuật hiện có. Chúng tôi đã cố gắng giảm thiểu những thay đổi về thông số kỹ thuật để giảm bớt rào cản cho việc áp dụng. Để biết chi tiết, xem Quy định về UICC .