Google is committed to advancing racial equity for Black communities. See how.
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

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

Android 5.1 เปิดตัวกลไกในการให้สิทธิพิเศษสำหรับ API ที่เกี่ยวข้องกับเจ้าของแอปการ์ดวงจรรวมสากล (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 มาตรฐานใช้เพื่อดึงข้อมูลกฎที่เก็บไว้ในการ์ด คุณสามารถอัปเดตกฎเหล่านี้ผ่านการอัปเดตการ์ดผ่านอากาศ (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 แรก 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 ต่อไปนี้

TelephonyManager

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) ประกอบด้วยการทดสอบสำหรับ API ของผู้ให้บริการใน CtsCarrierApiTestCases.apk เนื่องจากคุณสมบัตินี้ขึ้นอยู่กับใบรับรองใน UICC คุณจึงต้องเตรียม UICC เพื่อผ่านการทดสอบเหล่านี้

การเตรียม UICC

ตามค่าเริ่มต้น CtsCarrierApiTestCases.apk จะลงนามโดยคีย์นักพัฒนา Android โดยมีค่าแฮช 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . การทดสอบยังพิมพ์แฮชใบรับรองที่คาดไว้หากใบรับรองบน ​​UICC ไม่ตรงกัน

ตัวอย่างผลลัพธ์:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.
Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

ในการตรวจสอบความถูกต้องของการนำไปใช้งานผ่าน CTS โดยใช้ CtsCarrierApiTestCases.apk คุณต้องมี UICC สำหรับนักพัฒนาที่มีกฎ UICC ที่ถูกต้องหรือการสนับสนุน ARF คุณอาจขอให้ผู้จำหน่ายซิมการ์ดที่คุณเลือกเตรียม UICC ให้กับนักพัฒนาซอฟต์แวร์ด้วย ARF ที่ถูกต้องตามที่อธิบายไว้ในส่วนนี้และใช้ UICC นั้นเพื่อเรียกใช้การทดสอบ UICC ไม่ต้องการบริการเซลลูลาร์ที่ใช้งานอยู่เพื่อผ่านการทดสอบ CTS

กำลังดำเนินการทดสอบ

เพื่อความสะดวก 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

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

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

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

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

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 (ว่างเปล่า) คุณใช้กฎกับแอปของอุปกรณ์ทั้งหมดที่ไม่ครอบคลุมโดยกฎเฉพาะหรือไม่

ตอบ: Carrier 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