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

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

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

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

خلفية

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

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

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

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

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

الإمكانات

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

القيود

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

الحل

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

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

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

في نظام التشغيل 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 نهائيًا اعتبارًا من الإصدار 12 من نظام التشغيل Android.

مدير الاتصال الهاتفي

يستدعي برنامج 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 المميّزة واجهة برمجة التطبيقات لنظام TechnicalManager.

الاختبار

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

    adb shell cmd phone unattended-reboot

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

Android 11 فقط

ينطبق باقي هذه الصفحة على الإصدار 11 من نظام Android.

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

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

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

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

خطوات التحديث عبر الهواء باستخدام إعادة التوجيه

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

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

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

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

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