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

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

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

تتحكّم شركات الجوّال بشكل كامل في شريحة 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

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

SubscriptionManager

SmsManager

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

CarrierConfigManager

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

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

BugreportManager

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

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

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، استخدِم الخطوات التالية لضبط معرّف اشتراك أو مجموعة اشتراكات:

نظام 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. التجزئة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 الأساسية (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 للسماح بمعالجة ملف 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.