สิทธิพิเศษของผู้ให้บริการ 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

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

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 ต่อไปนี้

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

โทรกลับ

TelephonyCallback มีอินเทอร์เฟซพร้อมวิธีการโทรกลับเพื่อแจ้งแอปที่โทรเมื่อสถานะที่ลงทะเบียนเปลี่ยนแปลง:

  • ตัวบ่งชี้การรอข้อความเปลี่ยนไป: onMessageWaitingIndicatorChanged
  • ตัวบ่งชี้การโอนสายเปลี่ยนไป: onCallForwardingIndicatorChanged
  • สาเหตุ การตัดการเชื่อมต่อการโทรของระบบมัลติมีเดีย IP (IMS) เปลี่ยนไป: onImsCallDisconnectCauseChanged
  • สถานะการเชื่อมต่อข้อมูลที่แม่นยำเปลี่ยนไป: onPreciseDataConnectionStateChanged
  • รายการหมายเลขฉุกเฉินปัจจุบันมีการเปลี่ยนแปลง: onEmergencyNumberListChanged
  • เปลี่ยน ID การสมัครรับข้อมูลที่ใช้งานอยู่: onActiveDataSubscriptionIdChanged
  • เปลี่ยนเครือข่ายผู้ให้บริการ: onCarrierNetworkChange
  • การลงทะเบียนเครือข่ายหรือการอัปเดตตำแหน่ง/การกำหนดเส้นทาง/การติดตามล้มเหลว: onRegistrationFailed
  • การเปลี่ยนแปลงข้อมูลการจำกัด: onBarringInfoChanged
  • การกำหนดค่าช่องทางจริงปัจจุบันมีการเปลี่ยนแปลง: onPhysicalChannelConfigChanged

ตัวจัดการการสมัครสมาชิก

SmsManager

  • วิธีการให้ผู้โทรสร้างข้อความ SMS ขาเข้าใหม่: injectSmsPdu
  • วิธีการส่งข้อความ SMS แบบข้อความโดยไม่ต้องเขียนถึงผู้ให้บริการ SMS: sendTextMessageWithoutPersisting

CarrierConfigManager

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

สำหรับคำแนะนำ โปรดดูที่ การ กำหนดค่าผู้ให้บริการ

BugreportManager

วิธีการเริ่มรายงานจุดบกพร่องในการเชื่อมต่อ ซึ่งเป็นรุ่นเฉพาะของรายงานจุดบกพร่องที่มีเฉพาะข้อมูลสำหรับการดีบักปัญหาที่เกี่ยวข้องกับการเชื่อมต่อ: startConnectivityBugreport

NetworkStatsManager

  • วิธีการสืบค้นข้อมูลสรุปการใช้เครือข่าย: querySummary
  • วิธีการสืบค้นประวัติการใช้เครือข่าย: queryDetails
  • วิธีการลงทะเบียนหรือยกเลิกการลงทะเบียนเรียกกลับการใช้งานเครือข่าย:

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

วิธีการเปลี่ยนเป็น (เปิดใช้งาน) การสมัครสมาชิกที่กำหนด: switchToSubscription

CarrierMessagingService

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

  • วิธีการกรองข้อความ SMS ขาเข้า: onFilterSms
  • วิธีการสกัดกั้นข้อความ SMS ที่ส่งจากอุปกรณ์: onSendTextSms
  • วิธีการสกัดกั้นข้อความ SMS ไบนารีที่ส่งจากอุปกรณ์: onSendDataSms
  • วิธีการสกัดกั้นข้อความ SMS ยาว ๆ ที่ส่งจากอุปกรณ์: onSendMultipartTextSms
  • วิธีการสกัดกั้นข้อความ MMS ที่ส่งจากเครื่อง: onSendMms
  • วิธีการดาวน์โหลดข้อความ MMS ที่ได้รับ: onDownloadMms

CarrierService

บริการที่แสดงฟังก์ชันการทำงานเฉพาะของผู้ให้บริการไปยังระบบ หากต้องการขยายคลาสนี้ ให้ประกาศบริการในไฟล์รายการแอปด้วยสิทธิ์ android.Manifest.permission#BIND_CARRIER_SERVICES และรวมตัวกรองเจตนาด้วยการดำเนินการ CARRIER_SERVICE_INTERFACE หากบริการมีผลผูกพันที่ยาวนาน ให้ตั้งค่า android.service.carrier.LONG_LIVED_BINDING true ในข้อมูลเมตาของบริการ

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

วิธีการใน CarrierService รวมถึง:

  • ในการแทนที่และตั้งค่าคอนฟิกูเรชันเฉพาะของผู้ให้บริการ: onLoadConfig
  • เพื่อแจ้งระบบของการเปลี่ยนแปลงเครือข่ายผู้ให้บริการโดยเจตนาโดยแอปพลิเคชันผู้ให้บริการ: notifyCarrierNetworkChange

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

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

ข้อเสนอแนะเครือข่าย Wifi

เมื่อสร้างอ็อบเจ็กต์ WifiNetworkSuggestion ให้ใช้วิธีการต่อไปนี้เพื่อตั้งค่า ID การสมัครสมาชิกหรือกลุ่มการสมัคร:

  • วิธีตั้งค่า ID การสมัครสมาชิก: setSubscriptionId
  • Metohd เพื่อตั้งค่ากลุ่มการสมัคร: setSubscriptionGroup

แพลตฟอร์ม 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 ในแอปพลิเคชันหลักกฎการเข้าถึง (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
  2. สร้าง: ไฟล์ระดับประถมศึกษา 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
  3. แก้ไข: ตารางบริการ USIM: เปิดใช้งานบริการ n°47, n°48
    1. EF_UST (6F38)
      • เนื้อหา: 9EFFBF1DFFFE0083410310010400406E01
  4. แก้ไข: ไฟล์ DF-5GS และ DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • เนื้อหา: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • เนื้อหา: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    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
  5. แก้ไข: ใช้สตริงชื่อผู้ให้บริการ 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 บนเครือข่าย?

ใช่ การแทนที่แบรนด์ของผู้ปฏิบัติงานมีลำดับความสำคัญสูงสุด เมื่อตั้งค่าแล้ว จะแทนที่สตริงชื่อโอเปอเรเตอร์รูปแบบอื่นๆ ทั้งหมด

การเรียกเมธอด 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