امتيازات الناقل 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

دعم ملف قاعدة الوصول (ARF)

يضيف 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 واجهات برمجة التطبيقات التالية.

مدير الهاتف

SmsManager

طريقة للسماح للمتصل بإنشاء رسائل SMS injectSmsPdu جديدة:

CarrierConfigManager

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

CarrierMessagingService

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

مزود الهاتف

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

منصة أندرويد

في 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 .

لتشغيل اختبارات API لمشغل 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. التجزئة 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
  1. إنشاء : معاملات ADF USIM غير موجودة في 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
  2. تعديل: USIM Service Table: Enable Services n ° 47، n ° 48
    1. EF_UST (6F38)
      • المحتوى: 9EFFBF1DFFFE0083410310010400406E01
  3. تعديل : ملفات DF-5GS و DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM / 5FC0 / 4F01)
      • المحتوى: FFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM / 5FC0 / 4F02)
      • المحتوى: FFFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    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
  4. تعديل : يجب أن تكون سلاسل اسم الناقل هي 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 . على سبيل المثال ، يقوم الرمز المميز التالي للجهاز بتقييد اختبارات واجهة برمجة تطبيقات الناقل للتشغيل فقط على الجهاز abcd1234 :

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

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

التعليمات

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ج: راجع إدخال SPN في TelephonyManager

ماذا يفعل استدعاء طريقة 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 (فارغة) ، فهل تطبق القاعدة على جميع تطبيقات الجهاز التي لا تغطيها قاعدة معينة؟

ج: تتطلب واجهات برمجة التطبيقات (APIs) الخاصة بالحامل أن يتم ملؤها 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 .