امتيازات الناقل 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 هو عنوان 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . تُمنح التطبيقات الموقعة بواسطة هذه الشهادة امتيازات مشغل شبكة الجوّال.

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

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

مدير الهاتف

الاتصال الهاتفي

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

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

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 . تشمل الطرق:

  • طريقة تصفية رسائل SMS الواردة: onFilterSms
  • طريقة اعتراض الرسائل النصية القصيرة المرسلة من الجهاز: onSendTextSms
  • طريقة اعتراض رسائل SMS الثنائية المرسلة من الجهاز: onSendDataSms
  • طريقة اعتراض رسائل SMS الطويلة المرسلة من الجهاز: onSendMultipartTextSms
  • طريقة اعتراض رسائل الوسائط المتعددة المرسلة من الجهاز: 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

WifiNetwork اقتراح

عند إنشاء كائن 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. 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. 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 في EFs المعنية التي تحتوي على هذا التعيين:
    1. EF_SPN (USIM / 6F46)
      • المحتوى: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM / 6FC5)
      • المحتوى: Rec1 430B83413759FE4E934143EA14FF..FF

مطابقة هيكل ملف الاختبار

قم بتنزيل أحدث إصدار من هياكل ملفات تعريف الاختبار العامة التالية ومطابقتها. لن تحتوي ملفات التعريف هذه على قاعدة امتياز CTS Carrier أو تعديلات أخرى مذكورة أعلاه.

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

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

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

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

التعليمات

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

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

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

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

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

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

هل يوجد حد لعدد الشهادات في UICC؟

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

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

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

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

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

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

ج: يتم استخدام بطاقة 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 .