امتيازات مشغِّل شبكة الجوّال في UICC

وفّر نظام التشغيل Android 5.1 آلية لمنح امتيازات خاصة لواجهات برمجة التطبيقات المرتبطة بأصحاب تطبيقات بطاقات الدوائر المتكاملة العالمية (UICC). يُحمِّل نظام Android الأساسي الشهادات المخزَّنة على واجهة UICC ويمنح الإذن للتطبيقات الموقَّعة من خلال هذه الشهادات لإجراء اتصالات بمجموعة من واجهات برمجة التطبيقات الخاصة.

وفّر نظام التشغيل Android 7.0 هذه الميزة لاستخدام مصادر تخزين أخرى لقواعد امتيازات مشغّلي شبكة الجوَّال في شريحة UICC، ما أدّى إلى زيادة عدد مشغّلي شبكة الجوَّال الذين يمكنهم استخدام واجهات برمجة التطبيقات بشكل كبير. للحصول على مرجع لواجهة برمجة التطبيقات، يُرجى الاطّلاع على CarrierConfigManager للحصول على تعليمات، يُرجى الاطّلاع على إعدادات مشغِّل شبكة الجوّال.

تتحكّم شركات الجوّال بشكل كامل في شريحة UICC، لذا توفّر هذه الآلية طريقة آمنة ومرنة لإدارة التطبيقات من مشغّل شبكة الجوّال (MNO) المستضافة على قنوات توزيع التطبيقات العامة (مثل Google Play) مع الاحتفاظ بامتيازات خاصة على الأجهزة وبدون الحاجة إلى توقيع التطبيقات باستخدام شهادة النظام لكل جهاز أو تثبيتها مسبقًا كتطبيق نظام.

القواعد المتعلقة بـ UICC

تتوافق مساحة التخزين في واجهة UICC مع مواصفات GlobalPlatform للتحكم في الوصول إلى العناصر الآمنة. معرّف التطبيق (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) هي سلسلة اسم الحزمة الكاملة المعرفة في ملف البيان، وهي مُشفَّرة بترميز 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 الأساسي أولاً اختيار معرّف AIDA00000015141434C00 لتطبيق قاعدة الوصول (ARA). إذا لم يعثر على معرّف AID في شريحة UICC، سيعود إلى ARF عن طريق اختيار معرّف AID بتنسيق PKCS15 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. تحصل التطبيقات الموقَّعة بهذه الشهادة على امتيازات مشغّل شبكة الجوّال.

واجهات برمجة التطبيقات التي تم تفعيلها

يتوافق Android مع واجهات برمجة التطبيقات التالية.

TelephonyManager

معاودة الاتصال الهاتفي

TelephonyCallback يحتوي على واجهات تتضمّن طريقة للردّ بهدف إعلام التطبيق المتصل عند تغيير الحالات المسجّلة:

SubscriptionManager

SmsManager

  • طريقة السماح للمتصل بإنشاء رسائل قصيرة واردة جديدة: injectSmsPdu.
  • طريقة إرسال رسالة SMS تستند إلى النص بدون كتابتها إلى مقدِّم خدمة الرسائل القصيرة: sendTextMessageWithoutPersisting

CarrierConfigManager

  • طريقة إرسال إشعارات بشأن تغيير الإعدادات: notifyConfigChangedForSubId.
  • طريقة الحصول على إعدادات مشغّل شبكة الجوّال للاشتراك التلقائي: getConfig
  • طريقة الحصول على إعدادات مشغّل شبكة الجوّال للاشتراك المحدّد: getConfigForSubId

للحصول على التعليمات، يُرجى الاطّلاع على مقالة ضبط إعدادات مشغّل شبكة الجوَّال.

إدارة تقرير الأخطاء

طريقة بدء تقرير خطأ الاتصال، وهو إصدار متخصص من تقرير الأخطاء لا يتضمن سوى معلومات لتصحيح المشاكل المتعلقة بالاتصال: startConnectivityBugreport

مدير NetworkStats

ImsMmTelManager

ImsRcsManager

إدارة توفير المتطلبات اللازمة

EuiccManager

طريقة التبديل إلى الاشتراك المحدّد (تفعيله): switchToSubscription

CarrierMessagingService

الخدمة التي تتلقّى مكالمات من النظام عند إرسال رسائل SMS ورسائل وسائط متعددة جديدة أو تلقّيها. لتوسيع نطاق هذه الفئة، يجب إدراج الخدمة في ملف البيان باستخدام الإذن android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE وتضمين فلتر أهداف يتضمّن الإجراء#SERVICE_INTERFACE. وتشمل الطُرق ما يلي:

  • طريقة فلترة الرسائل القصيرة الواردة: onFilterSms
  • طريقة اعتراض الرسائل القصيرة SMS المُرسَلة من الجهاز: onSendTextSms
  • طريقة اعتراض الرسائل القصيرة الثنائية المُرسَلة من الجهاز: onSendDataSms
  • طريقة اعتراض الرسائل القصيرة الطويلة المُرسَلة من الجهاز: onSendMultipartTextSms
  • طريقة اعتراض رسائل الوسائط المتعددة المُرسَلة من الجهاز: onSendMms
  • طريقة تنزيل رسائل الوسائط المتعددة المستلَمة: onDownloadMms

CarrierService

خدمة تعرض وظائف خاصة بمشغّل شبكة الجوّال للنظام ل توسيع نطاق هذه الفئة، يجب الإفصاح عن الخدمة في ملف بيان التطبيق باستخدام الإذن android.Manifest.permission#BIND_CARRIER_SERVICES وتضمين فلتر أهداف يتضمّن الإجراء CARRIER_SERVICE_INTERFACE. إذا كانت الخدمة لها عملية ربط دائمة، اضبط android.service.carrier.LONG_LIVED_BINDING على true في البيانات الوصفية للخدمة.

تربط المنصة CarrierService بعلامات خاصة للسماح بتشغيل عملية خدمة مشغّل شبكة الجوّال في مجموعة التطبيقات الاحتياطية الخاصة. ويؤدي ذلك إلى إعفاء تطبيق خدمة مشغّل شبكة الجوّال من قيود التطبيقات غير النشطة ويزيد من احتمال بقائه قيد التشغيل عندما تكون ملفوظة الجهاز منخفضة. ومع ذلك، إذا تعطّل تطبيق خدمة مشغّل شبكة الجوّال لأي سبب، يفقد جميع الامتيازات المذكورة أعلاه إلى أن تتم إعادة تشغيل التطبيق وإعادة تثبيت الربط. لذلك، من المهم الحفاظ على استقرار تطبيق "خدمات مشغِّل شبكة الجوّال".

تشمل الطرق في CarrierService ما يلي:

  • لإلغاء الإعدادات الخاصة بمشغّل شبكة الجوّال وضبطها: onLoadConfig
  • لإعلام النظام بتغيير مقصود قادم في شبكة مشغِّل شبكة الجوّال من قِبل تطبيق مشغِّل شبكة الجوّال: notifyCarrierNetworkChange

مقدّم خدمة الاتصال الهاتفي

واجهات برمجة تطبيقات مقدّمي المحتوى للسماح بإجراء تعديلات (إدراج وحذف وتعديل واستعلام) على قاعدة بيانات الهاتف يتم تحديد حقول القيم على Telephony.Carriers. لمزيد من التفاصيل، يُرجى الرجوع إلى مرجع الفئة Telephony

WifiNetworkSuggestion

عند إنشاء عنصر WifiNetworkSuggestion، استخدِم ال methods التالية لضبط معرّف اشتراك أو مجموعة اشتراكات:

نظام Android الأساسي

في بطاقة UICC التي يتم رصدها، تُنشئ المنصة عناصر UICC داخلية تشمل قواعد امتيازات مشغّل شبكة الجوّال كجزء من بطاقة UICC. UiccCarrierPrivilegeRules.java يحمِّل هذا الإجراء القواعد ويحلّلها من بطاقة UICC ويخزّنها مؤقتًا في الذاكرة. وعند الحاجة إلى التحقّق من الامتياز، يقارن UiccCarrierPrivilegeRules شهادة المتصل بقواعدها الخاصة واحدة تلو الأخرى. في حال إزالة بطاقة UICC، يتم إتلاف القواعد مع عنصر UICC.

التحقُّق

للتحقّق من التنفيذ من خلال مجموعة أدوات اختبار التوافق (CTS) باستخدام CtsCarrierApiTestCases.apk، يجب أن يكون لديك شريحة UICC للمطوّر تتضمّن قواعد UICC الصحيحة أو تتيح استخدام ARF. اطلب من موفِّر شريحة SIM الذي تختاره إعداد شريحة UICC للمطوّرين تتضمّن ملف ARF المناسب كما هو موضّح في هذا القسم، واستخدِم شريحة UICC هذه لإجراء الاختبارات. لا يتطلّب ملف تعريف العميل المتكامل (USIM) خدمة شبكة جوّال نشطة لاجتياز اختبارات CTS.

تجهيز شريحة UICC

في الإصدار 11 من نظام التشغيل Android والإصدارات الأقدم، تم توقيع 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 في نظام التشغيل Android 12، يجب أن يستخدم الجهاز شريحة SIM مع امتيازات مشغّل شبكة الجوّال CTS تستوفي المتطلبات المحدّدة في أحدث إصدار من مواصفات ملف تعريف اختبار GSMA TS.48 التابع لجهة خارجية.

يمكن أيضًا استخدام شريحة SIM نفسها مع الإصدارات الأقدم من Android 12.

تعديل ملف تعريف شريحة SIM الخاص بمجموعة أدوات اختبار التوافق (CTS)

  1. الإضافة: امتيازات مشغّل شبكة الجوّال لاختبار CTS في ملف master لقاعدة الوصول إلى التطبيق (ARA-M) أو ملف ARF يجب أن يكون كلا التوقيعَين مرمّزَين في قواعد امتيازات مشغّل شبكة الجوّال:
    1. Hash1(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 الأساسية (EFs) غير المتوفّرة في TS.48 والمطلوبة لإجراء اختبار التوافق (CTS):
    1. EF_MBDN (6FC7)، حجم السجلّ: 28، رقم السجلّ: 4 
      • المحتوى
        1. التسجيل 1: 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
      • المحتوى: 0000000000
  3. تعديل: جدول خدمات شريحة USIM: تفعيل الخدمات رقم 47 ورقم 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 أو إجراء أي تعديلات أخرى مُدرَجة أعلاه في هذه الملفات الشخصية.

إجراء الاختبارات

لتسهيل الأمر، يتيح CTS استخدام رمز مميّز للجهاز يفرض عدم تنفيذ الاختبار إلا على الأجهزة التي تم ضبطها باستخدام الرمز المميّز نفسه. تتوافق اختبارات التحقّق من الامتثال (CTS) لواجهة برمجة التطبيقات Carrier API مع الرمز المميّز للجهاز sim-card-with-certs. على سبيل المثال، يحظر الرمز المميّز للجهاز التالي اختبارات واجهة برمجة التطبيقات لمشغّل شبكة الجوّال على الجهاز فقط abcd1234:

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

عند إجراء اختبار بدون استخدام رمز أمان الجهاز، يتم تنفيذ الاختبار على جميع الأجهزة.

الأسئلة الشائعة

كيف يمكن تعديل الشهادات على شريحة UICC؟

أ: استخدام آلية تحديث البطاقة الحالية عبر اتصال لاسلكي

هل يمكن لتطبيق UICC العمل مع قواعد أخرى؟

ج: لا بأس بوجود قواعد أمان أخرى على شريحة UICC ضمن رقم تعريف الجهاز نفسه، فتصفّحها المنصة تلقائيًا.

ماذا يحدث عند إزالة شريحة UICC لتطبيق يعتمد على الشهادات المضمّنة فيها؟

أ: يفقد التطبيق امتيازاته لأنّ القواعد المرتبطة بكرت UICC يتم إزالتها عند إزالة هذا الكرت.

هل هناك حدّ أقصى لعدد الشهادات على شريحة UICC؟

ج: لا تفرض المنصة قيودًا على عدد الشهادات، ولكن بما أنّ عملية الفحص خطية، قد يؤدي تزايد عدد القواعد إلى تأخير الفحص.

هل هناك حدّ لعدد واجهات برمجة التطبيقات التي يمكننا إتاحتها باستخدام هذه الطريقة؟

الإجابة: لا، ولكننا نقتصر على واجهات برمجة التطبيقات ذات الصلة بمشغّلي شبكات الجوّال.

هل هناك بعض واجهات برمجة التطبيقات المحظورة من استخدام هذه الطريقة؟ إذا كان الأمر كذلك، كيف تتم تنفيذها؟ (أي هل لديك اختبارات للتحقّق من واجهات برمجة التطبيقات التي تتوفّر بها هذه الطريقة؟)

أ: يُرجى الاطّلاع على القسم توافق سلوك واجهة برمجة التطبيقات في مستند تحديد التوافق مع Android (CDD). لدينا بعض اختبارات CTS للتأكد من عدم تغيير نموذج الإذن لواجهات برمجة التطبيقات.

كيف تعمل هذه الميزة مع ميزة "شريحة SIM متعددة"؟

أ: يتم استخدام شريحة SIM التلقائية التي حدّدها المستخدم.

هل تتفاعل هذه التكنولوجيا بأي شكل من الأشكال مع تكنولوجيات غيرها متعلّقة بالوصول إلى محتوى الوسائط التفاعلية، مثل SEEK؟

ج: على سبيل المثال، يستخدم SEEK معرّف AID نفسه المُستخدَم في شريحة UICC. بالتالي، تكون القواعد مترابطة وتتم فلترتها إما باستخدام SeeK أو UiccCarrierPrivileges.

ما هو الوقت المناسب للتحقّق من امتيازات مشغّل شبكة الجوّال؟

أ: بعد بث حالة شريحة SIM.

هل يمكن لمصنّعي الأجهزة الأصليين إيقاف جزء من واجهات برمجة تطبيقات مشغّلي شبكات الجوّال؟

الجواب: لا، نحن نعتقد أنّ واجهات برمجة التطبيقات الحالية هي الحدّ الأدنى من المتطلبات، ونخطط لاستخدام قناع البت للتحكّم في الدقة بشكل أدق في المستقبل.

هل تلغي setOperatorBrandOverride جميع أشكال سلاسل أسماء عوامل التشغيل الأخرى؟ على سبيل المثال، SE13 أو SPN في شريحة UICC أو NITZ المستند إلى الشبكة؟

نعم، إنّ إلغاء العلامة التجارية للمشغّل له الأولوية القصوى. وعند ضبطه، يتم إلغاء جميع الأشكال الأخرى لسلاسل أسماء عوامل التشغيل.

ما هي وظيفة طلب الإجراء injectSmsPdu؟

أ: تسهِّل هذه الطريقة الاحتفاظ بنسخة احتياطية من الرسائل القصيرة أو استعادتها في السحابة الإلكترونية. يؤدي استدعاء injectSmsPdu إلى تفعيل وظيفة الاستعادة.

بالنسبة إلى فلترة الرسائل القصيرة، هل تستند المكالمة onFilterSms إلى فلترة منفذ UDH للرسائل القصيرة؟ أم هل يمكن لتطبيقات مشغّلي شبكات الجوّال الوصول إلى جميع الرسائل القصيرة الواردة؟

الإجابة: يمكن لمشغّلي شبكات الجوّال الوصول إلى جميع بيانات الرسائل القصيرة.

يبدو أنّ إضافة 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 (فارغ)، هل تطبّق القاعدة على جميع تطبيقات الجهاز التي لا تندرج ضمن قاعدة معيّنة؟

أ: تتطلّب واجهات برمجة تطبيقات مشغّلي شبكات الجوَّال تعبئة 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.

نفترض أنّه يمكننا منح إذن الوصول إلى جميع الأذونات المستندة إلى مشغّل شبكة الجوّال أو أنّه يمكننا التحكّم بشكل أدق. إذا كان الأمر كذلك، فما الذي يحدد التعيين بين قناع البت والأذونات الفعلية؟ هل تريد الحصول على إذن واحد لكل صف؟ هل يُسمح بإذن واحد لكل طريقة؟ هل 64 إذنًا منفصلاً كافٍ على المدى الطويل؟

أ: هذا الخيار محجوز للمستقبل، ونرحب بالاقتراحات.

هل يمكنك تحديد DeviceAppID لنظام Android على وجه التحديد؟ هذه هي قيمة تجزئة SHA-1 (20 بايت) لشهادة الناشر المستخدَمة لتوقيع التطبيق المحدّد، لذا ألا يجب أن يعكس الاسم هذا الغرض؟ (قد يكون الاسم مربكًا للعديد من القرّاء لأنّ القاعدة تنطبق بعد ذلك على جميع التطبيقات الموقَّعة باستخدام شهادة الناشر نفسها).

ج: تتوافق شهادات التخزين DeviceAppID مع المواصفات الحالية، لذا حاولنا تقليل التغييرات في المواصفات للحدّ من حاجز الاستخدام. لمعرفة التفاصيل، يُرجى الاطّلاع على القواعد المتعلقة ببطاقة UICC.