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

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

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

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

กฎของ UICC

การจัดเก็บข้อมูลบน UICC เข้ากันได้กับ GlobalPlatform การรักษาความปลอดภัยข้อมูลจำเพาะขององค์ประกอบการควบคุมการเข้าถึง ระบุโปรแกรมประยุกต์ (AID) บนบัตรเป็น A00000015141434C00 และมาตรฐานการ GET DATA คำสั่งที่ใช้ในการดึงข้อมูลกฎระเบียบที่เก็บไว้ในการ์ด คุณสามารถอัปเดตกฎเหล่านี้ผ่านการอัพเดตการ์ดแบบ over-the-air (OTA)

ลำดับชั้นข้อมูล

กฎ UICC ใช้ลำดับชั้นข้อมูลต่อไปนี้ (การรวมตัวอักษรสองอักขระและตัวเลขในวงเล็บคือแท็กอ็อบเจ็กต์) แต่ละกฎ REF-AR-DO ( E2 ) และประกอบด้วย concatenation ของ REF-DO และ AR-DO :

  • REF-DO ( E1 ) มี DeviceAppID-REF-DO หรือเรียงต่อกันของ DeviceAppID-REF-DO และ PKG-REF-DO
    • DeviceAppID-REF-DO ( C1 ) ร้านค้า SHA-1 (20 bytes) หรือ SHA-256 (32 bytes) ลายเซ็นของใบรับรอง
    • PKG-REF-DO ( CA ) เป็นสตริงชื่อแพคเกจเต็มรูปแบบที่กำหนดไว้ในประจักษ์ ASCII เข้ารหัสความยาวสูงสุด 127 ไบต์
  • AR-DO ( E3 ) จะขยายไปยังรวมถึง PERM-AR-DO ( DB ) ซึ่งเป็นหน้ากากบิต 8 ไบต์คิดเป็น 64 สิทธิ์แยกต่างหาก

หาก PKG-REF-DO ไม่เป็นปัจจุบันแอพพ์ลงนามโดยใบรับรองจะได้รับการเข้าถึง มิฉะนั้นทั้งใบรับรองและชื่อแพ็คเกจจะต้องตรงกัน

ตัวอย่างกฎ

ชื่อ app เป็น 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)

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

CarrierMessagingService

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

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

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

แพลตฟอร์ม Android

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

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

ในการตรวจสอบการดำเนินงานที่ผ่านการ ทดสอบความเข้ากัน 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

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

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

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

  1. เพิ่มสิทธิประโยชน์ CTS Carrier ใน 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 EFS ไม่ได้อยู่ใน 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. แก้ไข: สตริง Carrier ชื่อจะเป็น Android CTS ใน EFS ที่เกี่ยวข้องที่มีการแต่งตั้งนี้:
    1. EF_SPN (USIM/6F46)
      • เนื้อหา: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • เนื้อหา: Rec1 430B83413759FE4E934143EA14FF..FF

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

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

วิ่งทดสอบ

เพื่อความสะดวก CTS รองรับโทเค็นของอุปกรณ์ที่จำกัดการทดสอบให้ทำงานบนอุปกรณ์ที่กำหนดค่าด้วยโทเค็นเดียวกันเท่านั้น การทดสอบผู้ให้บริการ 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 ใดรองรับวิธีนี้หรือไม่)

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

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

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

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

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

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

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

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

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

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

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

ไม่อะไร injectSmsPdu โทรวิธีทำอย่างไร

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

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

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

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

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

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

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

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

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

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

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

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

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