Đặc quyền của nhà mạng UICC

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

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

Quy tắc trên UICC

Bộ nhớ trên UICC tương thích với GlobalPlatform Thông số kỹ thuật Kiểm soát truy cập phần tử bảo mật. Mã nhận dạng ứng dụng (AID) trên thẻ là A00000015141434C00 và GET DATA 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 không dây (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 đây (chữ cái gồm hai ký tự và tổ hợp số trong 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 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ữ SHA-1 (20 byte) hoặc chữ ký SHA-256 (32 byte) của chứng chỉ.
    • PKG-REF-DO (CA) là tên gói đầy đủ chuỗi được xác định trong tệp kê khai, được mã hoá ASCII, độ dài tối đa 127 byte.
  • AR-DO (E3) đã được gia hạn để bao gồm PERM-AR-DO (DB), là một bit 8 byte mặt nạ biểu thị 64 quyền riêng biệt.

Nếu không có PKG-REF-DO thì tức là mọi ứng dụng được chứng chỉ ký được cấp quyền truy cập; nếu không, cả chứng chỉ và tên gói đều cần 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 trong 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 hỗ trợ đọc các quy tắc đặc quyền của nhà mạng từ quyền truy cập tệp quy tắc (ARF).

Trước tiên, nền tảng Android cố gắng chọn ứng dụng quy tắc truy cập (ARA) AID A00000015141434C00. Nếu Google không tìm thấy AID trên UICC, nó sẽ quay lại ARF bằng cách chọn PKCS15 AID 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 nhập bằng AID FFFFFFFFFFFF. Các mục có nhiều mã nhận dạng (AID) sẽ bị bỏ qua, do đó 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 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 của 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. Chiến dịch Quảng cáo ứ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.

TelephonyManager

Điện thoại gọi lại

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

SubscriptionManager

SmsManager

Trình quản lý cấu hình mạng di động

  • 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à mạng cho gói thuê bao mặc định: getConfig
  • Phương thức để tải cấu hình của nhà mạng cho gói thuê bao đã chỉ định: getConfigForSubId

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

Trình quản lý 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 kết nối liên quan vấn đề: startConnectivityBugreport

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

ImsMmTelManager

ImsRcsManager

Người quản lý cấp phép

Trình quản lý Euicc

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

Dịch vụ nhắn tin của nhà mạng

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

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

Nhà cung cấp dịch vụ

Dịch vụ cung cấp các chức năng dành riêng cho nhà mạng cho hệ thống. Người nhận 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à thêm một bộ lọc ý định bằng thao tác CARRIER_SERVICE_INTERFACE. Nếu dịch vụ có một mối liên kết dài hạn, 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 bằng cờ đặc biệt để cho phép của quy trình dịch vụ vận chuyển này chạy trong một nhóm chế độ chờ ứng dụng. Việc này sẽ miễn trừ ứng dụng dịch vụ của nhà mạng hạn chế ứng dụng ở trạng thái rảnh và tăng khả năng ứng dụng vẫn hoạt động khi thiết bị sắp hết bộ nhớ. 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ì, thì 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 tái lập. Vì vậy, điều tối quan trọng là phải giữ cho ứng dụng dịch vụ của nhà mạng hoạt động ổn định.

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

  • Cách ghi đè và đặt cấu hình dành riêng cho nhà mạng: onLoadConfig
  • Để thông báo cho hệ thống về việc cố ý thay đổi mạng của nhà mạng bằng cách ứng dụng của nhà mạng: notifyCarrierNetworkChange

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

Các API trình cung cấp nội dung cho phép sửa đổi (chèn, xoá, cập nhật, truy vấn) vào 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 về lớp Telephony

Đề xuất mạng Wi-Fi

Khi tạo một đối tượng WifiNetworkSuggestion, hãy sử dụng các hàm 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ộ thêm các quy tắc đặc quyền của nhà mạng vào UICC. UiccCarrierPrivilegeRules.java tải quy tắc, phân tích cú pháp các quy tắc đó từ thẻ UICC và lưu chúng vào bộ nhớ đệm. Thời gian cần kiểm tra đặc quyền, UiccCarrierPrivilegeRules sẽ so sánh chứng chỉ phương thức gọi với từng quy tắc riêng. Nếu UICC bị xoá, giá trị 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 quá trình triển khai thông qua Bộ kiểm tra tính tương thích (CTS) sử dụng CtsCarrierApiTestCases.apk, bạn phải có một UICC dành cho nhà phát triển với đúng quy tắc UICC hoặc dịch vụ hỗ trợ ARF. Hỏi 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 bên phải ARF như mô tả trong phần này và sử dụng UICC đó để chạy kiểm thử. Chiến lược phát hành đĩa đơn 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 là do aosp-testkey ký, có 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 là người ký 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.

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

Bạn cũng có thể dùng chính 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 trong CTS trong chính ứng dụng 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 đặc quyền của nhà mạng:
    1. Hàm băm1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hàm băm2(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) của 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ụ 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. Mã: DF-5GS
      • 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 EF tương ứng có chứa ký hiệu sau:
    1. EF_SPN (USIM/6F46)
      • Nội dung: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Nội dung: Rec1 430B83413759FE4E934143EA14FF..FF

Khớp với 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 cá nhân hoá quy tắc Đặc quyền của nhà mạng CTS hoặc các nội dung sửa đổi khác được liệt kê ở 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ị để hạn chế để chỉ chạy trên các thiết bị được định cấu hình với cùng một mã thông báo. CTS API của nhà mạng kiểm thử có 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 giới hạn việc kiểm tra API của nhà mạng chỉ chạy trên thiết bị abcd1234:

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

Khi chạy một chương trình kiểm thử mà không sử dụng mã thông báo của thiết bị, chương trình kiểm thử sẽ chạy trên tất 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?

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

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ể có 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 bỏ chúng.

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

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

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 có tính tuyến tính, nên quá nhiều quy tắc có thể phải chờ kiểm tra.

Có giới hạn nào về số lượng API mà chúng tôi có thể hỗ trợ trong vấn đề này không? 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à mạng.

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

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

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

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

Quyền truy cập này có tương tác hoặc chồng chéo với quyền truy cập nào khác trong Đông Nam Á không công nghệ, ví dụ: SEEK?

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

Khi nào nên kiểm tra đặc quyền của nhà mạng?

Đáp: Sau khi phát đi thông báo trạng thái SIM.

Nhà sản xuất thiết bị gốc có thể tắt một phần API của 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 bạn có thể lập kế hoạch 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Ả biểu mẫu khác không trên toán tử chuỗi tên? Ví dụ: SE13, UICC SPN hay NITZ dựa trên mạng?

Có, nội dung ghi đè thương hiệu của nhà vận hành có mức độ ưu tiên cao nhất. Khi được đặt, chính sách này 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ó chức năng gì?

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

Đối với tính năng lọc tin nhắn SMS, lệnh gọi onFilterSms dựa trên Lọc cổng UDH SMS? Hay ứng dụng của nhà mạng có quyền truy cập TẤT CẢ tin nhắn đế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ẻ là không tương thích với thông số kỹ thuật GP hiện tại (chỉ cho phép 0 hoặc 20 byte), vậy tại sao có phải bạn đang áp dụng thay đổi này không? SHA-1 chưa đủ để tránh va chạm? Bạn đã đề xuất thay đổi này cho GP chưa, vì điều này có thể tương thích ngược với ARA-M/ARF hiện có không?

Đáp: Để cung cấp tính năng bảo mật phù hợp trong tương lai, tiện ích này ra mắt thuật toán SHA-256 cho DeviceAppID-REF-DO cùng với SHA-1 (hiện là lựa chọn duy nhất theo tiêu chuẩn GP SEAC. Bạn nên sử dụng thuật toán SHA-256.

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

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

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

Đáp: Tuỳ chọn sử dụng PKG-REF-DO làm giá trị duy nhất mục trong REF-DO đã bị xoá trong phiên bản mới nhất. PKG-REF-DO chỉ nên xảy ra kết hợp với DeviceAppID-REF-DO.

Chúng tôi giả định rằng mình 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ó thì điều gì sẽ xác định việc ánh xạ giữa các bit và các quyền thực tế là gì? Mỗi lớp có một quyền? Một quyền cho mỗi không? Về lâu dài, liệu có đủ 64 quyền riêng biệt không?

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

Bạn có thể định nghĩa thêm về DeviceAppID cho Android cụ thể là như thế nào? Đây là giá trị băm SHA-1 (20 byte) của Nhà xuất bản chứng chỉ dùng để ký ứng dụng đã cho, vì vậy tên này không được phản ánh có mục đích gì? (Tên này có thể gây nhầm lẫn cho nhiều độc giả vì quy tắc này đang áp dụng áp dụng cho tất 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ợ bởi thông số kỹ thuật hiện có. Chúng tôi cố gắng giảm thiểu các thay đổi về thông số kỹ thuật nhằm giảm bớt rào cản cho việc áp dụng. Để biết thông tin chi tiết, hãy xem Quy tắc về UICC.