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

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

وقد وسّع الإصدار 7.0 من نظام التشغيل Android نطاق هذه الميزة لتشمل مصادر تخزين أخرى لقواعد امتيازات مشغّل شبكة الجوّال في بطاقة 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 أولاً اختيار معرّف تطبيق قاعدة الوصول (ARA) A00000015141434C00. إذا لم يتم العثور على معرّف التطبيق على بطاقة UICC، سيتم الرجوع إلى ARF من خلال اختيار معرّف تطبيق 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

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

CarrierConfigManager

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

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

BugreportManager

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

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

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

CarrierMessagingService

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

  • طريقة فلترة الرسائل القصيرة الواردة: onFilterSms
  • طريقة اعتراض الرسائل النصية القصيرة SMS المُرسَلة من الجهاز: onSendTextSms
  • طريقة اعتراض رسائل SMS الثنائية المرسَلة من الجهاز: 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 هذه لتنفيذ الاختبارات. لا تتطلّب بطاقة UICC توفّر خدمة شبكة جوّال نشطة لاجتياز اختبارات 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.

لتشغيل اختبارات واجهة برمجة التطبيقات الخاصة بمشغّلي شبكات الجوّال في &quot;مجموعة أدوات اختبار التوافق&quot; (CTS) على نظام التشغيل Android 12، يجب أن يستخدم الجهاز شريحة SIM تتضمّن امتيازات مشغّلي شبكات الجوّال في &quot;مجموعة أدوات اختبار التوافق&quot; تستوفي المتطلبات المحدّدة في أحدث إصدار من مواصفات GSMA TS.48 Test Profile التابعة لجهات خارجية.

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

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

  1. إضافة: امتيازات مشغّل CTS في تطبيق قاعدة الوصول الرئيسية (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. ‫Hash2(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
      • المحتوى: 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 أو التعديلات الأخرى المذكورة أعلاه.

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

لتوفير الراحة، يتيح اختبار التوافق مع نظام التشغيل Android استخدام رمز مميّز للجهاز يقتصر على تشغيل الاختبارات على الأجهزة التي تم ضبطها باستخدام الرمز المميز نفسه. تتيح اختبارات 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 معرّف التطبيق نفسه المستخدَم على بطاقة UICC. وبالتالي، تتواجد القواعد معًا ويتم فلترتها باستخدام SEEK أو UiccCarrierPrivileges.

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

ج: بعد بث حالة شريحة SIM التي تم تحميلها.

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

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

هل تلغي setOperatorBrandOverride جميع أشكال سلاسل أسماء المشغّلين الأخرى؟ على سبيل المثال، SE13 أو UICC SPN أو 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.