خيارات المطوّرين الآمنة

بموجب مستند تعريف معايير التوافق مع Android، يجب أن يوفّر المصنّعون الأصليون للأجهزة طريقة لتفعيل تطوير التطبيقات. ومع ذلك، فإنّ توفير خيارات المطوّرين المشابهة لتلك المتوفّرة على الأجهزة الجوّالة داخل السيارات يجعل هذه السيارات عرضة للهجمات. يمكن للمصنّع الأصلي للأجهزة الآن حصر إمكانية الوصول إلى خيارات المطوّرين باستخدام آلية رمز تشفير مصادَق عليه. على وجه التحديد، يمكن للمصنّع الأصلي للأجهزة إجراء ما يلي:

• تحديد القيود التلقائية قبل عملية التشغيل الأولى
• منح المطوّرين إذن الوصول بشكل آمن باستخدام رموز التشفير إذا كان ذلك مفضّلاً
• تطبيق تغييرات القيود بعد مصادقة المطوّر ومنحه إذن الوصول

توضّح هذه الصفحة عملية تنفيذ مرجعية تتألف من تطبيق للتحكّم في قيود تصحيح الأخطاء ونقطة نهاية لإصدار الرموز عن بُعد.

المصطلحات

بالإضافة إلى المصطلحات، تُستخدَم هذه المصطلحات في هذه الصفحة:

• توقيع JSON على الويب (JWS)، كما هو محدّد في RFC 7515
• المعهد الوطني للمعايير والتكنولوجيا (NIST)

تصميم

يمكن للمصنّعين الأصليين للأجهزة منح المطوّرين إذن الوصول باستخدام رموز توقيع JSON على الويب (JWS) (RFC7515). في عملية التنفيذ المرجعية، يصدر المصنّعون الأصليون للأجهزة رموز الوصول ويستخدمها تطبيق التحكّم في القيود. تم تصميم رموز الوصول لمقاومة هجمات إعادة التشغيل والرموز المزوّرة.

الشكل 1. تصميم

التكامل والإعداد

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

يمكن ضبط القيود التلقائية لمستخدم النظام بلا واجهة مستخدم رسومية باستخدام السلسلة config_defaultFirstUserRestrictions في frameworks/base/core/res/res/values/config.xml، على سبيل المثال:

<!-- User restrictions set when the first user is created.
         Note: Also update appropriate overlay files. -->
    <string-array translatable="false" name="config_defaultFirstUserRestrictions">
        <item>no_debugging_features</item>
        <item>no_install_unknown_sources</item>
        <item>no_install_unknown_sources_globally</item>
    </string-array>

يمكن ضبط القيود التلقائية للسائقين والركاب والضيوف في frameworks/base/core/res/res/xml/config_user_types.xml. يمكن للمصنّع الأصلي للأجهزة تراكب هذه السلاسل لضبط القيود التلقائية على كل نوع من أنواع المستخدمين على التوالي، على سبيل المثال:

<user-types>
    <full-type name="android.os.usertype.full.SECONDARY" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
    <full-type name="android.os.usertype.full.GUEST" >
        <default-restrictions
            no_debugging_features="true"
            no_install_unknown_sources="true"/>
    </full-type>
</user-types>

وحدة التحكّم في الإعدادات المفضّلة لرقم الإصدار

في AAOS، يتولّى BuildNumberPreferenceController.java الموجود في packages/apps/Car/Settings/src/com/android/car/settings/system/BuildNumberPreferenceController.java معالجة تفاعل المستخدم مع صف رقم الإصدار في "الإعدادات".

عند ضبط قيد المستخدم no_debugging_features (UserManager.DISALLOW_DEBUGGING_FEATURES)، يمنع BuildNumberPreferenceController العد التنازلي للمطوّرين في إصدارات الإنتاج (user) عند النقر:

@Override
protected boolean handlePreferenceClicked(Preference preference) {
    if (DevelopmentSettingsUtil.isDevelopmentSettingsEnabled(getContext())) {
        return true;
    }

    // Enforce restriction on production (user) builds
    if (Build.IS_USER && mUserManager.hasUserRestriction(UserManager.DISALLOW_DEBUGGING_FEATURES)) {
        showToast(R.string.dev_access_blocked_toast);
        return true;
    }

    mDevHitCountdown--;
    if (mDevHitCountdown == 0) {
        DevelopmentSettingsUtil.setDevelopmentSettingsEnabled(getContext(), true);
        showToast(R.string.show_dev_on);
    }
    return true;
}

يضمن استخدام Build.IS_USER أن تفرض إصدارات الإنتاج عملية الإغلاق الأمني بشكل صارم، بينما لا يزال بإمكان فرق الهندسة الداخلية في إصدارات userdebug الوصول إلى خيارات المطوّرين باستخدام إيماءة النقر 7 مرات للاختبار بدون إلغاء الأوامر يدويًا في واجهة سطر الأوامر (CLI).

وحدة التحكّم في قيود تصحيح الأخطاء

تتوفّر عملية تنفيذ مرجعية لوحدة التحكّم في قيود تصحيح الأخطاء (DRC) في AOSP على packages/apps/Car/DebuggingRestrictionController.

تتيح وحدة التحكّم في قيود تصحيح الأخطاء للمصنّعين الأصليين للأجهزة رفع قيد no_debugging_features مؤقتًا وبشكل ديناميكي على مركبات الإنتاج لفنيي الخدمة والمطوّرين المصرّح لهم. بدلاً من ترك أدوات تصحيح الأخطاء مفتوحة بشكل دائم أو طلب إعادة تثبيت البرامج الثابتة، يطلب تطبيق وحدة التحكّم في قيود تصحيح الأخطاء داخل السيارة من المستخدم المصادقة باستخدام نظام الخلفية الخاص بالمصنّع الأصلي للأجهزة وإرسال رمز الدخول موقَّع بطريقة مشفَّرة لتفعيل adb وخيارات المطوّرين لجلسة تشخيص محدودة.

تتألف عملية التنفيذ المرجعية لوحدة التحكّم في قيود تصحيح الأخطاء من مكوّنين أساسيين:

• تطبيق عميل وحدة التحكّم في قيود تصحيح الأخطاء داخل السيارة (app/): هو تطبيق نظام بأذونات مميّزة (يحمل الإذن MANAGE_USERS) على الوحدة الرئيسية يصادق المطوّرين ويتحقق من توقيع شهادة معيار X.509 واسم المضيف والرقم الخاص وانتهاء صلاحية رموز JWS المميزة الواردة، ويُبدّل قيد no_debugging_features بشكل ديناميكي باستخدام UserManager.
• نقطة نهاية إصدار الرموز السحابية (server/): هي خدمة ويب للواجهة الخلفية (يمكن نشرها كوظائف Firebase السحابية) تصادق بيانات اعتماد المطوّرين وتصدر رموز وصول JWS الموقَّعة بطريقة مشفَّرة باستخدام خوارزمية RS256 مع نافذة انتهاء صلاحية محدودة.

للحصول على تعليمات الإعداد الكاملة وأدوات إنشاء الشهادات وخطوات النشر، يُرجى الاطّلاع على الـ دليل دمج وحدة التحكّم في قيود تصحيح الأخطاء.

الاختبار

تنصح Google المصنّعين الأصليين للأجهزة بالبدء بعملية التنفيذ المرجعية والتوسّع منها.

1. بعد ضبط القيود في ملفات التراكب، عليك تجميع AAOS و التحقق من التدفقات المحدّدة. استخدِم التطبيق المرجعي والخدمة المحلية المفعّلة لـ JWS للتحقق من إعدادات الوصول.
2. اختياري: اضبط النظام لاستخدام خدمتك السحابية المفعّلة لـ JWS. تأكَّد من أنّك تلاحظ التدفق المتوقّع على خدمة الخلفية.