امتيازات الناقل UICC

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

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

واجهات برمجة التطبيقات الممكّنة

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

مدير الهاتف

رد الاتصال الهاتفي

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

مدير الاشتراكات

com.SmsManager

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

CarrierConfigManager

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

للحصول على التعليمات، راجع تكوين الناقل .

BugreportManager

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

مدير إحصائيات الشبكة

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

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

خدمة الرسائل الناقلة

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

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

خدمة الناقل

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

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

تتضمن الطرق الموجودة في CarrierService ما يلي:

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

مزود الهاتف

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

اقتراح شبكة واي فاي

عند إنشاء كائن WifiNetworkSuggestion ، استخدم الطرق التالية لتعيين معرف الاشتراك أو مجموعة الاشتراك:

منصة أندرويد

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

تصديق

للتحقق من صحة التنفيذ من خلال مجموعة اختبار التوافق (CTS) باستخدام CtsCarrierApiTestCases.apk ، يجب أن يكون لديك مطور UICC لديه قواعد UICC الصحيحة أو دعم ARF. اطلب من بائع بطاقة SIM الذي تختاره إعداد مطور 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

لتشغيل اختبارات واجهة برمجة تطبيقات الناقل CTS في Android 12، يحتاج الجهاز إلى استخدام بطاقة SIM مع امتيازات الناقل CTS التي تلبي المتطلبات المحددة في أحدث إصدار من مواصفات ملف تعريف اختبار GSMA TS.48 التابع لجهة خارجية.

يمكن أيضًا استخدام نفس بطاقة SIM للإصدارات السابقة لنظام 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. 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-ن: FF…FF
    2. EF_EXT6 (6FC8)، حجم السجل: 13، رقم السجل: 1
      • المحتوى: 00FF…FF
        1. EF_MBI (6FC9)، حجم السجل: 4، رقم السجل: 1
      • المحتوى: التوصية 1: 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 في EFs المعنية التي تحتوي على هذا التعيين:
    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؟

ج: استخدم آلية التحديث عبر الهواء للبطاقة الحالية.

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

ج: من الجيد أن يكون لديك قواعد أمان أخرى على UICC تحت نفس معرف AID؛ تقوم المنصة بتصفية هذه العناصر تلقائيًا.

ماذا يحدث عند إزالة UICC لتطبيق يعتمد على الشهادات الموجودة عليه؟

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

هل هناك حد لعدد الشهادات في UICC؟

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

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

ج: لا، لكننا نحصر النطاق في واجهات برمجة التطبيقات ذات الصلة بشركة الاتصالات.

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

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

كيف يعمل هذا مع ميزة SIM المتعددة؟

ج: يتم استخدام بطاقة SIM الافتراضية التي حددها المستخدم.

هل يتفاعل هذا أو يتداخل بأي شكل من الأشكال مع تقنيات الوصول الأخرى إلى SE، على سبيل المثال، SEEK؟

ج: على سبيل المثال، يستخدم SEEK نفس AID الموجود في UICC. لذلك تتعايش القواعد ويتم تصفيتها بواسطة SEEK أو UiccCarrierPrivileges .

متى يكون الوقت المناسب للتحقق من امتيازات الناقل؟

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

هل يمكن لمصنعي المعدات الأصلية تعطيل جزء من واجهات برمجة تطبيقات الناقل؟

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

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

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

ماذا يفعل استدعاء الأسلوب injectSmsPdu ؟

ج: تسهل هذه الطريقة النسخ الاحتياطي/الاستعادة للرسائل النصية القصيرة في السحابة. يقوم استدعاء injectSmsPdu بتمكين وظيفة الاستعادة.

بالنسبة لتصفية الرسائل النصية القصيرة، هل تعتمد مكالمة onFilterSms على تصفية منفذ SMS 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 .