สิทธิพิเศษของผู้ให้บริการ UICC

Android 5.1 ได้แนะนำกลไกในการมอบสิทธิพิเศษสำหรับ API ที่เกี่ยวข้องกับเจ้าของแอป Universal Integrated Circuit Card (UICC) แพลตฟอร์ม Android จะโหลดใบรับรองที่จัดเก็บไว้ใน UICC และให้สิทธิ์แอปที่ลงนามโดยใบรับรองเหล่านี้เพื่อเรียกใช้ API พิเศษจำนวนหนึ่ง

Android 7.0 ได้ขยายคุณลักษณะนี้เพื่อรองรับแหล่งที่มาของพื้นที่เก็บข้อมูลอื่นๆ สำหรับกฎสิทธิ์ของผู้ให้บริการ UICC ซึ่งทำให้จำนวนผู้ให้บริการที่สามารถใช้ API ได้เพิ่มขึ้นอย่างมาก สำหรับการอ้างอิง API โปรดดู ที่ CarrierConfigManager ; สำหรับคำแนะนำ โปรดดูที่ การ กำหนดค่าผู้ให้บริการ

ผู้ให้บริการสามารถควบคุม UICC ได้อย่างสมบูรณ์ ดังนั้นกลไกนี้จึงเป็นวิธีที่ปลอดภัยและยืดหยุ่นในการจัดการแอปจากผู้ให้บริการเครือข่ายมือถือ (MNO) ที่โฮสต์บนช่องทางการจัดจำหน่ายแอปทั่วไป (เช่น Google Play) ในขณะที่ยังคงสิทธิพิเศษบนอุปกรณ์และไม่จำเป็นต้องใช้ เพื่อลงนามแอปด้วยใบรับรองแพลตฟอร์มต่ออุปกรณ์หรือติดตั้งล่วงหน้าเป็นแอประบบ

กฎของ UICC

พื้นที่เก็บข้อมูลบน UICC เข้ากันได้กับข้อกำหนด GlobalPlatform Secure Element Access Control ตัวระบุแอปพลิเคชัน (AID) บนการ์ดคือ A00000015141434C00 และใช้คำสั่ง GET DATA มาตรฐานเพื่อดึงกฎที่จัดเก็บไว้ในการ์ด คุณสามารถอัปเดตกฎเหล่านี้ผ่านการอัพเดตการ์ดแบบ over-the-air (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 ) คือสตริงชื่อแพ็กเกจแบบเต็มที่กำหนดไว้ในไฟล์ Manifest เข้ารหัส ASCII ความยาวสูงสุด 127 ไบต์
  • AR-DO ( E3 ) ได้รับการขยายเพื่อรวม PERM-AR-DO ( DB ) ซึ่งเป็นมาสก์บิตขนาด 8 ไบต์ที่แสดงการอนุญาตแยกกัน 64 รายการ

หากไม่มี 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

ไฟล์กฎการเข้าถึง (ARF) รองรับ

Android 7.0 เพิ่มการรองรับการอ่านกฎสิทธิ์ของผู้ให้บริการจากไฟล์กฎการเข้าถึง (ARF)

ครั้งแรก แพลตฟอร์ม Android พยายามเลือกแอปเพล็ตกฎการเข้าถึง (ARA) ตัวระบุแอปพลิเคชัน (AID) A00000015141434C00 หากไม่พบ AID บน UICC ให้กลับไปที่ ARF โดยเลือก PKCS15 AID A000000063504B43532D3135 จากนั้น Android จะอ่านไฟล์กฎการควบคุมการเข้าถึง (ACRF) ที่ 0x4300 และค้นหารายการด้วย 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 ต่อไปนี้

ผู้จัดการโทรศัพท์

SmsManager

วิธีการอนุญาตให้ผู้โทรสร้างข้อความ SMS ขาเข้าใหม่: injectSmsPdu

CarrierConfigManager

วิธีการแจ้งการกำหนดค่ามีการเปลี่ยนแปลง: notifyConfigChangedForSubId สำหรับคำแนะนำ โปรดดูที่ การ กำหนดค่าผู้ให้บริการ

CarrierMessagingService

บริการรับสายจากระบบเมื่อมีการส่งหรือรับ SMS และ MMS ใหม่ หากต้องการขยายคลาสนี้ ให้ประกาศบริการในไฟล์รายการของคุณด้วยสิทธิ์ android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE และรวมตัวกรองเจตนาด้วยการดำเนินการ #SERVICE_INTERFACE วิธีการรวมถึง:

ผู้ให้บริการโทรศัพท์

API ของผู้ให้บริการเนื้อหาเพื่ออนุญาตให้แก้ไข (แทรก ลบ อัปเดต สืบค้น) ไปยังฐานข้อมูลโทรศัพท์ ฟิลด์ค่าถูกกำหนดไว้ที่ Telephony.Carriers ; สำหรับรายละเอียดเพิ่มเติม โปรดดูข้อมูลอ้างอิง Telephony API บน developer.android.com

แพลตฟอร์ม Android

บน UICC ที่ตรวจพบ แพลตฟอร์มจะสร้างวัตถุ UICC ภายในที่มีกฎสิทธิ์ของผู้ให้บริการเป็นส่วนหนึ่งของ UICC UiccCarrierPrivilegeRules.java โหลดกฎ แยกวิเคราะห์จากการ์ด UICC และแคชไว้ในหน่วยความจำ เมื่อต้องการตรวจสอบสิทธิ์ UiccCarrierPrivilegeRules เปรียบเทียบใบรับรองผู้โทรกับกฎของตัวเองทีละรายการ หากนำ UICC ออก กฎจะถูกทำลายพร้อมกับวัตถุ UICC

การตรวจสอบความถูกต้อง

ในการตรวจสอบการใช้งานผ่าน Compatibility Test Suite (CTS) โดยใช้ CtsCarrierApiTestCases.apk คุณต้องมี UICC ของนักพัฒนาซอฟต์แวร์ที่มีกฎ UICC ที่ถูกต้องหรือรองรับ ARF คุณอาจขอให้ผู้จำหน่ายซิมการ์ดที่คุณเลือกเตรียม UICC ของนักพัฒนาด้วย ARF ที่ถูกต้องตามที่อธิบายไว้ในส่วนนี้ และใช้ 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 .

หากต้องการเรียกใช้การทดสอบ API ของผู้ให้บริการ CTS ใน Android 12 อุปกรณ์ต้องใช้ซิมที่มีสิทธิ์ของผู้ให้บริการ CTS ที่ตรงตามข้อกำหนดที่ระบุไว้ใน เวอร์ชันล่าสุด ของข้อกำหนด โปรไฟล์การทดสอบ GSMA TS.48 ของบุคคลที่สาม

ซิมเดียวกันนี้ยังใช้กับเวอร์ชันก่อน Android 12 ได้อีกด้วย

การปรับเปลี่ยนโปรไฟล์ CTS SIM

  1. เพิ่ม : CTS Carrier Privileges ใน ARA-M หรือ ARF ลายเซ็นทั้งสองต้องเข้ารหัสในกฎสิทธิ์ของผู้ให้บริการ:
    1. แฮช1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. แฮช2(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. สร้าง : ADF USIM EF ไม่มีอยู่ใน TS.48 และจำเป็นสำหรับ CTS:
    1. EF_MBDN (6FC7), ขนาดบันทึก: 28, หมายเลขบันทึก: 4
      • เนื้อหา
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8) ขนาดระเบียน:13 จำนวนระเบียน: 1
      • เนื้อหา: 00FF…FF
        1. EF_MBI (6FC9) ขนาดระเบียน: 4 จำนวนระเบียน: 1
      • เนื้อหา: Rec1: 01010101
        1. EF_MWIS (6FCA), ขนาดระเบียน: 5, จำนวนระเบียน: 1
      • เนื้อหา: 000000000000
  2. แก้ไข: ตารางบริการ USIM: เปิดใช้งานบริการ n°47, n°48
    1. EF_UST (6F38)
      • เนื้อหา: 9EFFBF1DFFFE0083410310010400406E01
  3. แก้ไข : ไฟล์ DF-5GS และ DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • เนื้อหา: FFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • เนื้อหา: FFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • เนื้อหา:A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • เนื้อหา:A0020000FF…FF
  4. แก้ไข : สตริงชื่อผู้ให้บริการจะเป็น Android CTS ใน EF ที่เกี่ยวข้องซึ่งมีการกำหนดนี้:
    1. EF_SPN (USIM/6F46)
      • เนื้อหา: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • เนื้อหา: Rec1 430B83413759FE4E934143EA14FF..FF

จับคู่โครงสร้างโปรไฟล์ทดสอบ

ดาวน์โหลดและจับคู่ เวอร์ชันล่าสุด ของโครงสร้างโปรไฟล์การทดสอบทั่วไปต่อไปนี้ โปรไฟล์เหล่านี้จะไม่มีกฎ CTS Carrier Privilege ที่ปรับให้เป็นส่วนตัวหรือการปรับเปลี่ยนอื่น ๆ ที่ระบุไว้ข้างต้น

วิ่งทดสอบ

เพื่อความสะดวก CTS รองรับโทเค็นอุปกรณ์ที่จำกัดการทดสอบให้ทำงานบนอุปกรณ์ที่กำหนดค่าด้วยโทเค็นเดียวกันเท่านั้น การทดสอบ Carrier API CTS รองรับโทเค็นอุปกรณ์ sim-card-with-certs ตัวอย่างเช่น โทเค็นของอุปกรณ์ต่อไปนี้จำกัดการทดสอบ API ของผู้ให้บริการให้ทำงานบนอุปกรณ์ abcd1234 เท่านั้น:

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

เมื่อทำการทดสอบโดยไม่ใช้โทเค็นอุปกรณ์ การทดสอบจะทำงานบนอุปกรณ์ทั้งหมด

คำถามที่พบบ่อย

จะอัปเดตใบรับรองบน ​​UICC ได้อย่างไร

ตอบ: ใช้กลไกการอัปเดต OTA ของการ์ดที่มีอยู่

UICC สามารถอยู่ร่วมกับกฎเกณฑ์อื่นได้หรือไม่?

ตอบ: เป็นเรื่องปกติที่จะมีกฎความปลอดภัยอื่น ๆ ใน UICC ภายใต้ AID เดียวกัน แพลตฟอร์มจะกรองออกโดยอัตโนมัติ

จะเกิดอะไรขึ้นเมื่อ UICC ถูกลบสำหรับแอปที่อาศัยใบรับรองในนั้น

ตอบ: แอปสูญเสียสิทธิ์เนื่องจากกฎที่เกี่ยวข้องกับ UICC จะถูกทำลายเมื่อนำ UICC ออก

มีการจำกัดจำนวนใบรับรองใน UICC หรือไม่

ตอบ: แพลตฟอร์มนี้ไม่จำกัดจำนวนใบรับรอง แต่เนื่องจากเช็คเป็นแบบเชิงเส้น กฎจำนวนมากเกินไปอาจใช้เวลาในการตรวจสอบ

มีการจำกัดจำนวน API ที่เรารองรับด้วยวิธีนี้หรือไม่

ตอบ: ไม่ แต่เราจำกัดขอบเขตเฉพาะ API ที่เกี่ยวข้องกับผู้ให้บริการ

มี API บางตัวที่ห้ามไม่ให้ใช้วิธีนี้หรือไม่? ถ้าเป็นเช่นนั้นคุณจะบังคับใช้อย่างไร (นั่นคือ คุณมีการทดสอบเพื่อตรวจสอบว่า API ใดรองรับวิธีนี้หรือไม่)

ตอบ: ดูส่วน "ความเข้ากันได้ของพฤติกรรม API" ของ เอกสารข้อกำหนดความเข้ากันได้ของ Android (CDD) เรามีการทดสอบ CTS เพื่อให้แน่ใจว่าไม่มีการเปลี่ยนแปลงรูปแบบการอนุญาตของ API

สิ่งนี้ทำงานอย่างไรกับคุณสมบัติหลายซิม?

ตอบ: จะใช้ซิมเริ่มต้นที่ผู้ใช้ระบุ

สิ่งนี้มีปฏิสัมพันธ์หรือทับซ้อนกับเทคโนโลยีการเข้าถึง SE อื่น ๆ เช่น SEEK หรือไม่?

ตอบ: ตัวอย่างเช่น SEEK ใช้ AID เดียวกันกับ UICC ดังนั้นกฎจึงอยู่ร่วมกันและถูกกรองโดย SEEK หรือ UiccCarrierPrivileges

เมื่อใดควรตรวจสอบสิทธิ์ของผู้ให้บริการ

A: หลังจากที่สถานะซิมโหลดออกอากาศ

OEM สามารถปิดการใช้งานส่วนหนึ่งของ API ของผู้ให้บริการได้หรือไม่

ตอบ: ไม่ เราเชื่อว่า API ปัจจุบันเป็นชุดที่น้อยที่สุด และเราวางแผนที่จะใช้บิตมาสก์เพื่อการควบคุมที่ละเอียดยิ่งขึ้นในอนาคต

setOperatorBrandOverride แทนที่สตริงชื่อตัวดำเนินการรูปแบบอื่นทั้งหมดหรือไม่ ตัวอย่างเช่น SE13, UICC SPN หรือ NITZ บนเครือข่าย?

ตอบ: อ้างถึงรายการ SPN ใน TelephonyManager

การเรียกเมธอด injectSmsPdu ทำอะไร

ตอบ: วิธีนี้อำนวยความสะดวกในการสำรอง/กู้คืน SMS ในระบบคลาวด์ การเรียก injectSmsPdu เปิดใช้งานฟังก์ชันการกู้คืน

สำหรับการกรอง SMS การเรียก onFilterSms ขึ้นอยู่กับการกรองพอร์ต SMS UDH หรือไม่ หรือแอพของผู้ให้บริการสามารถเข้าถึง SMS ที่เข้ามาทั้งหมดได้หรือไม่

ตอบ: ผู้ให้บริการสามารถเข้าถึงข้อมูล SMS ทั้งหมดได้

ส่วนขยายของ DeviceAppID-REF-DO เพื่อรองรับ 32 ไบต์ดูเหมือนจะเข้ากันไม่ได้กับข้อมูลจำเพาะ GP ปัจจุบัน (ซึ่งอนุญาต 0 หรือ 20 ไบต์เท่านั้น) เหตุใดคุณจึงแนะนำการเปลี่ยนแปลงนี้ SHA-1 ไม่เพียงพอที่จะหลีกเลี่ยงการชนหรือไม่ คุณได้เสนอการเปลี่ยนแปลงนี้ให้กับ GP แล้ว เนื่องจากอาจไม่สามารถใช้ร่วมกับ ARA-M/ARF ที่มีอยู่เดิมได้หรือไม่

ตอบ: สำหรับการรักษาความปลอดภัยในอนาคต ส่วนขยายนี้แนะนำ SHA-256 สำหรับ DeviceAppID-REF-DO นอกเหนือจาก SHA-1 ซึ่งปัจจุบันเป็นตัวเลือกเดียวในมาตรฐาน GP SEAC เราขอแนะนำอย่างยิ่งให้ใช้ SHA-256

หาก DeviceAppID เป็น 0 (ว่าง) คุณใช้กฎกับแอปอุปกรณ์ทั้งหมดที่ไม่ครอบคลุมโดยกฎเฉพาะหรือไม่

ตอบ: API ของผู้ให้บริการต้องมีการเติมข้อมูล DeviceAppID-REF-DO การว่างเปล่ามีไว้เพื่อวัตถุประสงค์ในการทดสอบและไม่แนะนำสำหรับการปรับใช้ในการปฏิบัติงาน

ตามข้อมูลจำเพาะของคุณ PKG-REF-DO ใช้เพียงอย่างเดียวโดยไม่มี DeviceAppID-REF-DO ไม่ควรยอมรับ แต่ยังคงอธิบายไว้ในตารางที่ 6-4 ว่าเป็นการขยายคำจำกัดความของ REF-DO นี่เป็นความตั้งใจหรือไม่? รหัสทำงานอย่างไรเมื่อใช้เฉพาะ PKG-REF-DO ใน REF-DO

ตอบ: ตัวเลือกของการมี PKG-REF-DO เป็นไอเท็มมูลค่าเดียวใน REF-DO ถูกลบออกในเวอร์ชันล่าสุด PKG-REF-DO ควรเกิดขึ้นร่วมกับ DeviceAppID-REF-DO เท่านั้น

เราคิดว่าเราสามารถให้สิทธิ์การเข้าถึงตามผู้ให้บริการทั้งหมดหรือมีการควบคุมที่ละเอียดยิ่งขึ้น ถ้าเป็นเช่นนั้น อะไรเป็นตัวกำหนดการจับคู่ระหว่าง bit mask และการอนุญาตที่แท้จริง หนึ่งสิทธิ์ต่อชั้นเรียน? หนึ่งสิทธิ์ต่อวิธี? 64 สิทธิ์ที่แยกจากกันเพียงพอในระยะยาวหรือไม่?

ตอบ: สิ่งนี้สงวนไว้สำหรับอนาคต และเรายินดีรับข้อเสนอแนะ

คุณสามารถกำหนด DeviceAppID สำหรับ Android โดยเฉพาะได้หรือไม่? นี่คือค่าแฮช SHA-1 (20 ไบต์) ของใบรับรองผู้เผยแพร่ที่ใช้ลงนามแอปที่กำหนด ดังนั้นชื่อไม่ควรสะท้อนถึงจุดประสงค์นั้นใช่หรือไม่ (ชื่ออาจสร้างความสับสนให้กับผู้อ่านหลายๆ คน ตามกฎแล้วจะใช้กับแอปทั้งหมดที่ลงนามด้วยใบรับรองผู้เผยแพร่เดียวกันนั้น)

ตอบ: ใบรับรองการจัดเก็บ DeviceAppID ได้รับการสนับสนุนโดยข้อมูลจำเพาะที่มีอยู่ เราพยายามลดการเปลี่ยนแปลงข้อมูลจำเพาะเพื่อลดอุปสรรคในการนำไปใช้ สำหรับรายละเอียด โปรดดู กฎเกี่ยวกับ UICC