استئناف التشغيل عند إعادة التشغيل

في Android 11، يمكن تطبيق تحديثات عبر الهواء (OTA) باستخدام آليات التحديث A/B أو التحديث A/B الافتراضي، بالإضافة إلى طُرق الفئة RecoverySystem. بعد إعادة تشغيل الجهاز لتطبيق تحديث عبر الهواء، تفتح ميزة "استئناف التشغيل بعد إعادة التشغيل" (RoR) وحدة تخزين بيانات الاعتماد المشفّرة (CE) على الجهاز.

على الرغم من أنّه يمكن للشركاء إقران هذه العملية بميزة نظام تحديثات عبر الهواء التي تطبّق التحديثات عندما يُتوقَّع أن يكون الجهاز في وضع الخمول في Android 11، لا يحتاج الشركاء في Android 12 إلى ميزة إضافية لنظام تحديثات عبر الهواء. توفّر عملية "استئناف التشغيل بعد إعادة التشغيل" أمانًا وراحة إضافيين للمستخدمين لأنّه يمكن إجراء التحديثات خلال أوقات خمول الجهاز، بينما توفّر وظائف التحديث المتعددة العملاء والمستندة إلى الخادم في Android 12 معًا أمانًا من نوع مستوى أجهزة الجهاز.

على الرغم من أنّه يجب منح إذن الجهاز لميزة android.hardware.reboot_escrow لدعم "استئناف التشغيل بعد إعادة التشغيل" في Android 11، ليس عليك إجراء ذلك لتفعيل ميزة "استئناف التشغيل بعد إعادة التشغيل" المستندة إلى الخادم في Android 12 والإصدارات الأحدث، لأنّها لا تستخدم طبقة تجريد الأجهزة (HAL).

خلفية

بدءًا من Android 7، أتاح Android ميزة التشغيل المباشر، التي تسمح للتطبيقات على الجهاز بالبدء قبل أن يفتح المستخدم وحدة تخزين بيانات الاعتماد المشفّرة. وفّر استخدام ميزة "التشغيل المباشر" تجربة أفضل للمستخدمين قبل أن يُطلب إدخال عامل المعرفة لشاشة القفل (LSKF) بعد عملية التشغيل.

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

نموذج التهديد

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

على وجه التحديد، يجب ألا يتمكّن المهاجم الذي يمتلك الجهاز فعليًا ولديه الإمكانات والقيود التالية من قراءة وحدة تخزين بيانات الاعتماد المشفّرة:

الإمكانات

  • يمكنه استخدام مفتاح التوقيع لأي بائع أو شركة لتوقيع رسائل عشوائية.
  • يمكنه جعل الجهاز يتلقّى تحديثًا عبر الهواء.
  • يمكنه تعديل عملية أي جهاز (مثل معالج التطبيقات، أو ذاكرة الفلاش) باستثناء ما هو موضّح في القيود أدناه. (ومع ذلك، يتضمّن هذا التعديل تأخيرًا لمدة ساعة واحدة على الأقل ودورة طاقة تؤدي إلى إتلاف محتويات ذاكرة الوصول العشوائي (RAM).)

القيود

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

الحل

يوفّر نظام تحديث "استئناف التشغيل بعد إعادة التشغيل" في Android 12 أمانًا ضد المهاجمين المتطوّرين جدًا، ويتم ذلك مع بقاء كلمات المرور وأرقام التعريف الشخصية على الجهاز فقط، ولا يتم إرسالها أو تخزينها مطلقًا على خوادم Google. في ما يلي نظرة عامة على العملية التي تضمن أن تكون مستويات الأمان المقدّمة مشابهة لنظام "استئناف التشغيل بعد إعادة التشغيل" المستند إلى الأجهزة على مستوى الجهاز:

  • يطبّق Android حمايات مشفّرة على البيانات المخزّنة على الجهاز.
  • تتم حماية جميع البيانات باستخدام مفاتيح مخزّنة في بيئة التنفيذ الموثوقة (TEE).
  • لا تتيح بيئة التنفيذ الموثوقة المفاتيح إلا إذا اجتاز نظام التشغيل قيد التشغيل المصادقة المشفرة (التشغيل الآمن).
  • تؤمّن خدمة "استئناف التشغيل بعد إعادة التشغيل" التي تعمل على خوادم Google بيانات الاعتماد المشفّرة من خلال تخزين سر يمكن استرداده لفترة محدودة فقط. ويعمل ذلك في جميع أنحاء نظام Android.
  • يتم استخدام مفتاح مشفّر، محمي برقم تعريف شخصي للمستخدم، لفتح قفل الجهاز وفك تشفير وحدة تخزين بيانات الاعتماد المشفّرة.
    • عندما تتم جدولة إعادة تشغيل ليلية، يطلب Android من المستخدم إدخال رقم التعريف الشخصي، ثم يحسب كلمة مرور اصطناعية (SP).
    • بعد ذلك، يشفّر كلمة المرور الاصطناعية مرّتين: مرّة باستخدام مفتاح K_s مخزّن في ذاكرة الوصول العشوائي، ومرّة أخرى باستخدام مفتاح K_k مخزّن في بيئة التنفيذ الموثوقة.
    • يتم تخزين كلمة المرور الاصطناعية المشفّرة مرّتين على القرص، ويتم محو كلمة المرور الاصطناعية من ذاكرة الوصول العشوائي. يتم إنشاء كلا المفتاحين حديثًا واستخدامهما لإعادة تشغيل واحدة فقط.
  • عندما يحين وقت إعادة التشغيل، يسلّم Android المفتاح K_s إلى الخادم. يتم تشفير الإيصال الذي يحتوي على المفتاح K_k قبل تخزينه على القرص.
  • بعد إعادة التشغيل، يستخدم Android المفتاح K_k لفك تشفير الإيصال، ثم يرسله إلى الخادم لاسترداد المفتاح K_s.
    • يتم استخدام المفتاحين K_k وK_s لفك تشفير كلمة المرور الاصطناعية المخزّنة على القرص.
    • يستخدم Android كلمة المرور الاصطناعية لفتح وحدة تخزين بيانات الاعتماد المشفّرة والسماح ببدء تشغيل التطبيق بشكل طبيعي.
    • يتم تجاهل المفتاحين K_k وK_s.

يمكن إجراء التحديثات التي تحافظ على أمان هاتفك في وقت مناسب لك، مثل أثناء النوم.

إعادة استخدام رقم التعريف الشخصي لشريحة SIM

في ظروف معيّنة، يتم التحقّق من رمز رقم التعريف الشخصي لشريحة SIM من ذاكرة تخزين مؤقت، وهي عملية تُعرف باسم "إعادة استخدام رقم التعريف الشخصي لشريحة SIM".

يجب أيضًا أن تخضع شريحة SIM التي تم تفعيل رقم التعريف الشخصي لها لعملية تحقّق سلسة من رمز رقم التعريف الشخصي (إعادة استخدام رقم التعريف الشخصي لشريحة SIM) بعد إعادة تشغيل غير مراقَبة لاستعادة الاتصال بشبكة الجوّال (المطلوب للمكالمات الهاتفية والرسائل القصيرة وخدمات البيانات). يتم تخزين رقم التعريف الشخصي لشريحة SIM ومعلومات شريحة SIM المطابقة (رقم ICCID ورقم فتحة شريحة SIM) معًا بشكل آمن. لا يمكن استرداد رقم التعريف الشخصي المخزّن واستخدامه للتحقّق إلا بعد إعادة تشغيل غير مراقَبة ناجحة. إذا كان الجهاز محميًا، يتم تخزين رقم التعريف الشخصي لشريحة SIM باستخدام مفاتيح محمية بواسطة عامل المعرفة لشاشة القفل. إذا تم تفعيل رقم التعريف الشخصي لشريحة SIM، تتطلّب التفاعلات مع خادم "استئناف التشغيل بعد إعادة التشغيل" اتصالاً بشبكة Wi-Fi لتحديث عبر الهواء و"استئناف التشغيل بعد إعادة التشغيل" المستند إلى الخادم، ما يضمن توفير الوظائف الأساسية (مع الاتصال بشبكة الجوّال) بعد إعادة التشغيل.

تتم إعادة تشفير رقم التعريف الشخصي لشريحة SIM وتخزينه في كل مرّة يفعّله المستخدم أو يتحقّق منه أو يعدّله بنجاح. يتم تجاهل رقم التعريف الشخصي لشريحة SIM في أي من الحالات التالية:

  • إزالة شريحة SIM أو إعادة ضبطها
  • إيقاف المستخدم لرقم التعريف الشخصي
  • إعادة تشغيل غير مراقَبة لم يتم بدءها من خلال ميزة "استئناف التشغيل بعد إعادة التشغيل"

لا يمكن استخدام رقم التعريف الشخصي لشريحة SIM المخزّن إلا مرّة واحدة بعد إعادة التشغيل التي تم بدءها من خلال ميزة "استئناف التشغيل بعد إعادة التشغيل"، و ذلك لفترة قصيرة جدًا (20 ثانية) إذا تطابقت تفاصيل شريحة SIM. لا يغادر رقم التعريف الشخصي لشريحة SIM المخزّن تطبيق TelephonyManager ولا يمكن استرداده بواسطة الوحدات الخارجية.

إرشادات التنفيذ

في Android 12، توفّر وظائف "استئناف التشغيل بعد إعادة التشغيل" المتعددة العملاء والمستندة إلى الخادم حملاً أخفّ على الشركاء عند إرسال تحديثات عبر الهواء. يمكن إجراء التحديثات الضرورية خلال أوقات توقف الجهاز المناسبة، مثل ساعات النوم المحدّدة.

لضمان عدم مقاطعة المستخدمين أثناء تحديثات عبر الهواء خلال هذه الفترات الزمنية، استخدِم الوضع الداكن للحدّ من انبعاثات الضوء. لإجراء ذلك، اطلب من برنامج إقلاع الجهاز البحث عن السلسلة unattended في سبب إعادة التشغيل. إذا كانت قيمة unattended هي true، اضبط الجهاز على الوضع الداكن. يُرجى العِلم أنّ كل مصنّع معدات أصلية مسؤول عن الحدّ من انبعاثات الصوت والضوء.

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

هناك عملية استدعاء جديدة في مسار العميل المتعدد، وهي isPreparedForUnattendedUpdate، موضّحة أدناه:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

ليس عليك استخدام هذه العملية، لأنّه تم إيقاف طبقة تجريد الأجهزة اعتبارًا من Android 12.

TelephonyManager

يستدعي عميل تحديثات عبر الهواء واجهة برمجة تطبيقات النظام TelephonyManager عندما تكون إعادة التشغيل وشيكة في Android 12. تنقل واجهة برمجة التطبيقات هذه جميع رموز التعريف الشخصية المخزّنة مؤقتًا من الحالة AVAILABLE إلى الحالة REBOOT_READY. تتم حماية واجهة برمجة تطبيقات النظام TelephonyManager من خلال إذن البيان الحالي REBOOT.

 /**
    * The unattended reboot was prepared successfully.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;

   /**
    * The unattended reboot was prepared, but the user will need to manually
    * enter the PIN code of at least one SIM card present in the device.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;

   /**
    * The unattended reboot was not prepared due to generic error.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;

   /** @hide */
   @Retention(RetentionPolicy.SOURCE)
   @IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
           value = {
                   PREPARE_UNATTENDED_REBOOT_SUCCESS,
                   PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
                   PREPARE_UNATTENDED_REBOOT_ERROR
           })
   public @interface PrepareUnattendedRebootResult {}

   /**
    * Prepare TelephonyManager for an unattended reboot. The reboot is
    * required to be done shortly after the API is invoked.
    *
    * Requires system privileges.
    *
    * <p>Requires Permission:
    *   {@link android.Manifest.permission#REBOOT}
    *
    * @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
    * {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
    * at least one SIM card for which the user needs to manually enter the PIN
    * code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
    * of error.
    * @hide
    */
   @SystemApi
   @RequiresPermission(android.Manifest.permission.REBOOT)
   @PrepareUnattendedRebootResult
   public int prepareForUnattendedReboot()

تستخدم حِزم APK المميّزة واجهة برمجة تطبيقات النظام TelephonyManager.

الاختبار

لاختبار واجهة برمجة التطبيقات الجديدة، نفِّذ هذا الأمر:

    adb shell cmd phone unattended-reboot

لا يعمل هذا الأمر إلا عندما يتم تشغيل واجهة الأوامر كجذر (adb root).

Android 11 فقط

ينطبق الجزء المتبقي من هذه الصفحة على Android 11.

اعتبارًا من يوليو 2020، تندرج عمليات استخدام طبقة تجريد الأجهزة لميزة "استئناف التشغيل بعد إعادة التشغيل" ضمن فئتين:

  1. إذا كانت أجهزة نظام على شريحة (SoC) تتيح استمرار ذاكرة الوصول العشوائي بعد عمليات إعادة التشغيل، يمكن لمصنّعي المعدات الأصلية استخدام الـ عملية الاستخدام التلقائية في مشروع Android مفتوح المصدر (AOSP) (الاحتفاظ التلقائي بذاكرة الوصول العشوائي).
  2. إذا كانت أجهزة الجهاز أو نظام على شريحة يتيح بيئة آمنة للأجهزة (معالج أمان منفصل مع ذاكرة الوصول العشوائي وذاكرة القراءة فقط الخاصة به)، يجب بالإضافة إلى ذلك إجراء ما يلي:
    • القدرة على رصد إعادة تشغيل وحدة المعالجة المركزية الرئيسية
    • مصدر مؤقت للأجهزة يستمر بعد عمليات إعادة التشغيل أي يجب أن تكون البيئة الآمنة قادرة على رصد إعادة التشغيل وانتهاء صلاحية مؤقت تم ضبطه قبل إعادة التشغيل.
    • إتاحة تخزين مفتاح محتفظ به في ذاكرة الوصول العشوائي أو ذاكرة القراءة فقط للبيئة الآمنة بطريقة لا يمكن استردادها من خلال الهجمات بلا إنترنت يجب تخزين مفتاح "استئناف التشغيل بعد إعادة التشغيل" بطريقة تجعل من المستحيل على المهاجمين أو المطلعين استرداده.

الاحتفاظ التلقائي بذاكرة الوصول العشوائي

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

مسار تحديث عبر الهواء باستخدام ميزة "استئناف التشغيل بعد إعادة التشغيل"

يجب أن يتضمّن تطبيق عميل تحديثات عبر الهواء على الهاتف الأذونات Manifest.permission.REBOOT و Manifest.permission.RECOVERY لاستدعاء الطُرق اللازمة لاستخدام ميزة "استئناف التشغيل بعد إعادة التشغيل". بعد استيفاء هذا الشرط الأساسي، يتّبع مسار التحديث الخطوات التالية:

  1. ينزّل تطبيق عميل تحديثات عبر الهواء التحديث.
  2. يستدعي تطبيق عميل تحديثات عبر الهواء RecoverySystem#prepareForUnattendedUpdate الذي يؤدي إلى مطالبة المستخدم بإدخال رقم التعريف الشخصي أو النقش أو كلمة المرور على شاشة القفل أثناء عملية فتح القفل التالية.
  3. يفتح المستخدم قفل الجهاز على شاشة القفل، ويصبح الجهاز جاهزًا لتطبيق التحديث.
  4. يستدعي تطبيق عميل تحديثات عبر الهواء RecoverySystem#rebootAndApply، ما يؤدي إلى بدء عملية إعادة التشغيل على الفور.

في نهاية هذا المسار، تتم إعادة تشغيل الجهاز وتفتح آلية "استئناف التشغيل بعد إعادة التشغيل" وحدة تخزين بيانات الاعتماد المشفّرة. بالنسبة إلى التطبيقات، يظهر ذلك كعملية فتح قفل عادية للمستخدم، لذا تتلقّى جميع الإشارات، مثل ACTION_LOCKED_BOOT_COMPLETED و ACTION_BOOT_COMPLETED كما تفعل عادةً.

تعديل إعدادات المنتج

يجب أن يتضمّن المنتج الذي تم وضع علامة عليه على أنّه يتيح ميزة "استئناف التشغيل بعد إعادة التشغيل" في Android 11 عملية استخدام لطبقة تجريد الأجهزة RebootEscrow وتضمين ملف XML الذي يحتوي على علامة الميزة. تعمل عملية الاستخدام التلقائية بشكل جيد على الأجهزة التي تستخدم إعادة التشغيل الجزئية (عندما تظل الطاقة في ذاكرة الوصول العشوائي الديناميكية (DRAM) قيد التشغيل أثناء إعادة التشغيل).

علامة ميزة "الاحتفاظ بإعادة التشغيل"

يجب أيضًا توفّر علامة الميزة:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

عملية الاستخدام التلقائية لطبقة تجريد الأجهزة لميزة "الاحتفاظ بإعادة التشغيل"

لاستخدام عملية الاستخدام التلقائية، يجب حجز 65536 (0x10000) بايت. لا تكتب هذه البايتات مطلقًا في وحدة تخزين غير متطايرة لضمان استمرار الخصائص الأمنية.

تغييرات شجرة أجهزة نواة Linux

في شجرة أجهزة نواة Linux، يجب حجز ذاكرة لمنطقة pmem. يوضّح المثال التالي حجز 0x50000000:

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

تأكَّد من أنّ لديك جهازًا جديدًا في دليل الحظر باسم مثل /dev/block/pmem0 (مثل pmem1 أو pmem2).

تغييرات ملف Device.mk

بافتراض أنّ الجهاز الجديد من الخطوة السابقة يُسمى pmem0، يجب التأكّد من إضافة الإدخالات الجديدة التالية إلى vendor/<oem>/<product>/device.mk:

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default
قواعد SELinux

أضِف هذه الإدخالات الجديدة إلى file_contexts للجهاز:

/dev/block/pmem0  u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default  u:object_r:hal_rebootescrow_default_exec:s0