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

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

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

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

يضيف Android 7.0 دعمًا لقراءة قواعد امتياز الناقل من ملف قاعدة الوصول (ARF).

المحاولات الأولى منصة أندرويد لتحديد قاعدة وصول الصغير (ARA) معرف التطبيق (AID) A00000015141434C00 . إذا لم تجد AID على UICC، فإنه يرتد إلى ARF عن طريق تحديد PKCS15 AID A000000063504B43532D3135 . الروبوت ثم يقرأ ملف قواعد التحكم بالوصول (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 . لمزيد من التفاصيل، يرجى الرجوع إلى الاتصالات الهاتفية إشارة 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

للحصول على الروبوت 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 .

ابتداء من الروبوت 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 الاختبارات API الناقل في الروبوت 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 خدمة الجدول: تمكين خدمات رقم 47، رقم 48
    1. EF_UST (6F38)
      • المحتوى: 9EFFBF1DFFFE0083410310010400406E01
  3. تعديل: 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
  4. تعديل: يجب أن تكون السلاسل اسم الناقل الروبوت CTS في التماثلية منها تحتوي على هذه التسمية:
    1. EF_SPN (USIM / 6F46)
      • المحتوى: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM / 6FC5)
      • المحتوى: Rec1 430B83413759FE4E934143EA14FF..FF

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

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

اختبارات التشغيل

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

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

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

التعليمات

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لتصفية SMS، هو onFilterSms الدعوة بناء على ترشيح ميناء SMS UDH؟ أو هل تتمتع تطبيقات شركات الجوال بإمكانية الوصول إلى جميع الرسائل القصيرة الواردة؟

ج: يمكن لشركات الاتصالات الوصول إلى جميع بيانات الرسائل القصيرة.

تمديد DeviceAppID-REF-DO يبدو لدعم 32 بايت لتكون متوافقة مع المواصفات GP الحالية (التي تسمح 0 أو 20 بايت فقط)، لذلك لماذا إدخال هذا التغيير؟ أليس SHA-1 كافياً لتجنب الاصطدامات؟ هل اقترحت هذا التغيير على GP بالفعل ، حيث قد يكون هذا غير متوافق مع ARA-M / ARF الحالي؟

A: لتوفير الأمن واقية من المستقبل، وهذا التمديد يدخل SHA-256 ل DeviceAppID-REF-DO بالإضافة إلى SHA-1، الذي هو حاليا الخيار الوحيد في مستوى GP SEAC. نوصي بشدة باستخدام SHA-256.

إذا DeviceAppID هو 0 (فارغ)، هل تطبيق القاعدة على جميع الأجهزة تطبيقات التي لا تشملها قاعدة محددة؟

تتطلب الناقل واجهات برمجة التطبيقات: A DeviceAppID-REF-DO يتم ملؤها. أن تكون فارغًا مخصص لأغراض الاختبار ولا يوصى به لعمليات النشر التشغيلية.

وفقا للمواصفات الخاصة بك، PKG-REF-DO تستخدم فقط في حد ذاته، دون DeviceAppID-REF-DO ، لا ينبغي أن يكون مقبولا. لكنه ما زال هو موضح في الجدول 6-4 عن طريق توسيع تعريف REF-DO . هل هذا عن قصد؟ كيف تتصرف عندما كود فقط PKG-REF-DO يستخدم في REF-DO ؟

الخيار من وجود: A PKG-REF-DO كبند قيمة واحد في REF-DO تمت إزالة في الإصدار الأخير. PKG-REF-DO ينبغي أن يحدث فقط في تركيبة مع DeviceAppID-REF-DO .

نفترض أنه يمكننا منح الوصول إلى جميع الأذونات المستندة إلى شركة الاتصالات أو أن يكون لدينا تحكم أكثر دقة. إذا كان الأمر كذلك ، ما الذي يحدد التعيين بين قناع البت والأذونات الفعلية؟ إذن واحد لكل فصل؟ إذن واحد لكل طريقة؟ هل 64 أذونات منفصلة كافية على المدى الطويل؟

ج: هذا مخصص للمستقبل ونرحب بالاقتراحات.

يمكنك زيادة تحديد DeviceAppID لالروبوت على وجه التحديد؟ هذه هي قيمة تجزئة SHA-1 (20 بايت) لشهادة الناشر المستخدمة للتوقيع على التطبيق المحدد ، لذا ألا يجب أن يعكس الاسم هذا الغرض؟ (قد يكون الاسم محيرًا للعديد من القراء لأن القاعدة تنطبق بعد ذلك على جميع التطبيقات الموقعة بشهادة الناشر نفسها.)

ج: إن DeviceAppID تخزين شهادات معتمد من قبل المواصفات الحالية. حاولنا تقليل تغييرات المواصفات لتقليل حاجز التبني. لمزيد من التفاصيل، انظر القواعد المتعلقة UICC .