Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Đặ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 đ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ởi 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 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. Đối với một tài liệu tham khảo API, xem CarrierConfigManager ; để được hướng dẫn, xem Carrier Cấu hình .

Các nhà cung cấp dịch vụ có toàn quyền kiểm soát UICC, do đó, cơ chế này cung cấp một cách an toàn và linh hoạt để quản lý các ứng dụng từ nhà khai thác 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 mỗi 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

Lưu trữ trên UICC tương thích với các GlobalPlatform an toàn đặc tả phần tử Access Control . Từ định ứng dụng (AID) trên thẻ là A00000015141434C00 , và các tiêu chuẩn GET DATA lệnh được sử dụng để lấy quy tắ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

Các quy tắc UICC sử dụng cấu trúc phân cấp dữ liệu sau (kế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 một nối của REF-DOAR-DO :

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

Nếu PKG-REF-DO là không có mặt, bất kỳ ứng dụng có chữ ký của các chứng chỉ được cấp quyền truy cập; nếu không thì cả chứng chỉ và tên gói cần phải khớp.

Ví dụ về quy tắc

Tên ứng dụng là com.google.android.apps.myapp và giấy chứng nhận 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 (ARF)

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).

Những nỗ lực đầu tiên nền tảng Android để chọn nhận dạng ứng dụng (AID) quy tắc truy cập Applet (ARA) A00000015141434C00 . Nếu nó không tìm ra AID trên UICC, nó rơi trở lại ARF bằng cách chọn PKCS15 AID A000000063504B43532D3135 . Android sau đó đọc các tập tin quy tắc kiểm soát truy cập (ACRF) tại 0x4300 và ngoại hình cho các mục với AID FFFFFFFFFFFF . Các mục nhập có AID khác nhau 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.

Nội dung ACRF mẫu trong chuỗi hex:

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

Nội dung tệp điều kiện kiểm soát truy cập ví dụ (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ỉ cho ACCF, trong đó có giấy chứng nhận băm 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.

TelephonyManager

SmsManager

Phương pháp để cho phép người gọi để tạo ra các tin nhắn SMS mới: injectSmsPdu .

CarrierConfigManager

Phương pháp thông báo cấu hình đã thay đổi: notifyConfigChangedForSubId . Để được hướng dẫn, xem Carrier Cấu hình .

CarrierMessagingService

Dịch vụ nhận cuộc gọi từ hệ thống khi gửi hoặc nhận SMS và MMS mới. Để mở rộng lớp này, tuyên bố các dịch vụ trong file manifest của bạn với android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE phép và bao gồm một bộ lọc ý với #SERVICE_INTERFACE hành động. Các phương pháp bao gồm:

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

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

Nền tảng Android

Trên một UICC được phát hiện, nền tảng này 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 quy tắc, phân tích chúng khỏi thẻ UICC, và lưu trữ chúng trong bộ nhớ. Khi kiểm tra đặc quyền là cần thiết, UiccCarrierPrivilegeRules so sánh giấy chứng nhận người gọi với các quy tắc riêng của mình từng người một. Nếu UICC bị loại bỏ, các quy tắc sẽ bị hủy cùng với đối tượng UICC.

Thẩm định

Để xác nhận việc thực hiện thông qua Compatibility Test Suite (CTS) sử dụng CtsCarrierApiTestCases.apk , bạn phải có một UICC nhà phát triển với các quy tắc UICC đúng hay hỗ trợ ARF. Bạn có thể 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 và thấp hơn, CtsCarrierApiTestCases.apk được ký bởi aosp-testkey , với giá trị hash 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 CTS thử nghiệm tàu sân API trong Android 12, các thiết bị cần sử dụng một SIM với CTS đặc quyền hãng đáp ứng yêu cầu quy định trong phiên bản mới nhất của bên thứ ba thông tin GSMA TS.48 Kiểm tra đặc điểm kỹ thuật.

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

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

  1. Địa chỉ: Ưu đãi CTS Carrier trong ARA-M hay ARF. Cả hai chữ ký phải được mã hóa trong các quy tắc đặc quyền của nhà cung cấp dịch vụ:
    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
  1. Tạo: ADF USIM EFS không có mặt 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
  2. Sửa: USIM Dịch vụ Bảng: Kích hoạt dịch vụ n ° 47, n ° 48
    1. EF_UST (6F38)
      • Nội dung: 9EFFBF1DFFFE0083410310010400406E01
  3. Sửa đổi: DF-5GS và DF-SAIP tập tin
    1. DF-5GS - EF_5GS3GPPLOCI (USIM / 5FC0 / 4F01)
      • Nội dung: FFFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM / 5FC0 / 4F02)
      • Nội dung: FFFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    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
  4. Sửa đổi: Carrier Tên chuỗi chịu Android CTS trong EFS tương ứng chứa định 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ơ kiểm tra

Tải về và phù hợp với phiên bản mới nhất của các cấu trúc hồ sơ kiểm tra tổng quát sau. Những hồ sơ này sẽ không có quy tắc Đặc quyền của nhà cung cấp dịch vụ 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 bài kiểm tra chỉ chạy trên các thiết bị được định cấu hình với cùng mã thông báo. Kiểm tra Carrier API CTS hỗ trợ các thiết bị thẻ sim-card-with-certs . Ví dụ, các thiết bị sau thẻ kiểm tra API Giới Hạn tàu sân bay để 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 tắc khác không?

A: Sẽ tốt khi có các quy tắc bảo mật khác trên UICC theo cùng một AID; nền tảng 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 vào các chứng chỉ trên đó?

Đ: Ứng dụng mất đặ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?

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

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?

A: 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 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ó kiểm tra để xác thực API nào được hỗ trợ với phương pháp này không?)

A: Hãy xem phần "API hành vi tương thích" của Definition Document Compatibility Android (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 không bị thay đổi.

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

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

Điều này theo bất kỳ cách nào có tương tác hoặc chồng chéo với các công nghệ truy cập SE khác, chẳng hạn như SEEK?

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

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

A: Sau khi trạng thái SIM được tải chương trình phát sóng.

OEM có thể vô hiệu hóa một phần API của nhà cung cấp dịch vụ không?

A: 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 mức độ chi tiết tốt hơn trong tương lai.

Liệu setOperatorBrandOverride ghi đè TẤT CẢ các hình thức khác của chuỗi tên nhà khai thác? Ví dụ: SE13, UICC SPN hoặc NITZ dựa trên mạng?

A: Tham khảo mục SPN trong TelephonyManager

Không những gì injectSmsPdu gọi phương thức làm gì?

Đ: 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. Các injectSmsPdu cuộc gọi cho phép chức năng khôi phục.

Để lọc tin nhắn SMS, là onFilterSms gọi dựa trên lọc cổng SMS UDH? Hay các ứng dụng của nhà cung cấp dịch vụ có quyền truy cập TẤT CẢ SMS đến?

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

Việc gia hạn DeviceAppID-REF-DO để hỗ trợ 32 byte dường như không phù hợp với spec GP hiện tại (cho phép 0 hoặc 20 byte chỉ), vậy tại sao bạn giới thiệu sự 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ó?

A: Đối với cung cấp an ninh tương lai chứng minh, phần mở rộng này giới thiệu SHA-256 cho DeviceAppID-REF-DO ngoài SHA-1, mà hiện nay là lựa chọn duy nhất trong tiêu chuẩn GP SEAC. Chúng tôi thực sự 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 cho tất cả các thiết bị ứng dụng không được bao phủ bởi một quy tắc cụ thể?

A: Carrier API yêu cầu DeviceAppID-REF-DO được dân cư. Để trống là nhằm mục đích thử nghiệm và không được khuyến nghị cho các triển khai hoạt động.

Theo spec của bạn, PKG-REF-DO sử dụng chỉ bằng cách riêng của mình, mà không DeviceAppID-REF-DO , không nên được chấp nhận. Nhưng nó vẫn còn được mô tả trong Bảng 6-4 như mở rộng định nghĩa của REF-DO . Đây có phải là mục đích không? Làm thế nào để cư xử mã khi chỉ PKG-REF-DO được sử dụng trong REF-DO ?

A: Các tùy chọn của việc có PKG-REF-DO là một item giá trị duy nhất trong REF-DO được loại bỏ 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 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 sự? Một quyền cho mỗi lớp? Một quyền cho mỗi phương thức? 64 quyền riêng biệt về lâu dài có đủ không?

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

Bạn có thể tiếp tục xác định DeviceAppID dành cho Android đặc biệt? Đâ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 đã cho, vì vậy, tên không phải phản ánh mục đích đó sao? (Tên có thể gây nhầm lẫn cho nhiều người đọc vì quy tắc sau đó có thể á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 đó.)

A: DeviceAppID chứng chỉ lưu trữ được hỗ trợ bởi spec 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 để giảm rào cản cho việc áp dụng. Để biết chi tiết, xem Quy định về UICC .