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

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

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

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

الخلفية

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

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

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

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

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

الإمكانات

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

القيود

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

الحل

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

  • يوفّر نظام التشغيل Android حماية تشفيرية للبيانات المخزّنة على الجهاز.
  • تتم حماية جميع البيانات باستخدام مفاتيح مخزَّنة في بيئة التنفيذ الموثوقة (TEE).
  • لا يتيح بيئة التنفيذ الموثوقة الوصول إلى المفاتيح إلا إذا اجتاز نظام التشغيل الذي يتم تشغيله مصادقة التشفير (التشغيل المتحقَّق منه).
  • توفّر خدمة RoR التي تعمل على خوادم Google الأمان لبيانات CE من خلال تخزين مفتاح سري يمكن استرداده لفترة زمنية محدودة فقط. تعمل هذه الميزة في جميع أنحاء منظومة Android المتكاملة.
  • يتم استخدام مفتاح تشفير محمي برقم التعريف الشخصي للمستخدم لفتح قفل الجهاز وفك تشفير مساحة تخزين CE.
    • عندما تتم جدولة إعادة التشغيل أثناء الليل، يطلب نظام التشغيل Android من المستخدم إدخال رقم التعريف الشخصي، ثم يحتسب كلمة مرور اصطناعية (SP).
    • بعد ذلك، يتم تشفير SP مرتين: مرة باستخدام مفتاح K_s مخزَّن في ذاكرة الوصول العشوائي، ومرة أخرى باستخدام مفتاح K_k مخزَّن في TEE.
    • يتم تخزين SP المشفَّر مرتين على القرص، ويتم محو SP من ذاكرة الوصول العشوائي. يتم إنشاء كلا المفتاحين حديثًا واستخدامهما لإعادة التشغيل مرة واحدة فقط.
  • عندما يحين وقت إعادة التشغيل، يفوّض نظام التشغيل 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 مع مفاتيح محمية بواسطة LSKF. إذا كان رقم التعريف الشخصي (PIN) لشريحة SIM مفعَّلاً، فإنّ التفاعل مع خادم RoR يتطلّب اتصالاً بشبكة Wi-Fi لإجراء التحديث عبر الأثير (OTA) واستخدام ميزة RoR المستندة إلى الخادم، ما يضمن توفُّر الوظائف الأساسية (مع توفُّر اتصال بشبكة الجوّال) بعد إعادة التشغيل.

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

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

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

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

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

لضمان عدم مقاطعة المستخدمين أثناء هذه الفترات الزمنية بسبب تحديثات OTA، استخدِم الوضع الداكن للحدّ من انبعاثات الضوء. لإجراء ذلك، اطلب من برنامج الإقلاع في الجهاز البحث عن السلسلة reason 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)

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

TelephonyManager

يستدعي عميل OTA واجهة برمجة التطبيقات 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، تندرج عمليات تنفيذ RoR HAL ضمن فئتين:

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

الضمان التلقائي للذاكرة العشوائية

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

مسار التحديث عبر اتصال لاسلكي باستخدام RoR

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

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

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

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

يجب أن يتضمّن المنتج الذي تم وضع علامة عليه بأنّه يتوافق مع ميزة "إعادة التشغيل مع الحماية" في Android 11 عملية تنفيذ لواجهة HAL الخاصة بميزة 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

التنفيذ التلقائي لطبقة تجريد الأجهزة (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