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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

الخلفية

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

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

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

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

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

الإمكانات

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

القيود

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

الحل

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

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

يمكن أن يتم تثبيت التحديثات التي تحافظ على أمان هاتفك في الوقت المناسب لائق لك: أثناء النوم.

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

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

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

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

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

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

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

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

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

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

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

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

لست بحاجة إلى تنفيذ ذلك، لأنّ HAL قد تم إيقافه نهائيًا اعتبارًا من ‎Android 12.

TelephonyManager

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

 /**
    * 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

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

Android 11 فقط

تنطبق بقية هذه الصفحة على نظام التشغيل Android 11.

اعتبارًا من تموز (يوليو) 2020، تندرج عمليات تنفيذ RoR HAL ضمن فئتين:

1. إذا كان جهاز SoC يتوافق مع الاحتفاظ بذاكرة الوصول العشوائي (RAM) بعد عمليات إعادة التشغيل، يمكن لمصنّعي المعدّات الأصلية استخدام التنفيذ التلقائي في AOSP (Default RAM Escrow).
2. إذا كان جهاز الجهاز أو المنظومة على الرقاقة (SoC) يتيحان إنشاء منطقة آمنة للأجهزة (معالج أمان تكميلي منفصل مزوّد بذاكرة وصول عشوائي (RAM) وذاكرة قراءة فقط (ROM) خاصة به)، يجب أن ينفِّذ الجهاز بالإضافة إلى ذلك ما يلي:
   • أن يكون بإمكانه رصد إعادة تشغيل وحدة المعالجة المركزية الرئيسية
   • أن يكون لديك مصدر موقّت للأجهزة يستمر بعد عمليات إعادة التشغيل وهذا يعني أنّه يجب أن يكون بالإمكان في الحجز الآمن رصد عملية إعادة التشغيل وإنهاء صلاحية الموقّت الذي تم ضبطه قبل إعادة التشغيل.
   • أن تتيح تخزين مفتاح مُودع في ذاكرة الوصول العشوائي (RAM) أو ذاكرة القراءة فقط (ROM) للمنطقة المحصورة بحيث لا يمكن استرداده من خلال هجمات بلا إنترنت يجب تخزين مفتاح RoR بطريقة تصعِّب على المستخدمين الداخليين أو المهاجمين استرداده.

المبلغ التلقائي المحجوز مؤقتًا في الحساب لوحدة ذاكرة الوصول العشوائي

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

خطوات التحديث عبر اتصال لاسلكي باستخدام إعادة التحميل

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

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

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

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

يجب أن يتضمّن المنتج الذي تم وضع علامة عليه على أنّه متوافق مع ميزة "إعادة التشغيل الآمن" في Android 11 تكاملًا مع واجهة برمجة التطبيقات RebootEscrow HAL وملف 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

تنفيذ HAL التلقائي لميزة إعادة التشغيل الآمنة

لاستخدام التنفيذ التلقائي، يجب حجز 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