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

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

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

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

خلفية

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

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

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

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

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

الإمكانات

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

القيود

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

الحل

يعزّز نظام تحديث RoR للإصدار 12 من نظام التشغيل Android مستوى الأمان. ضد المهاجمين المتطورين للغاية، ويحدث ذلك عندما تستخدم كلمات المرور تظل أرقام التعريف الشخصية على الجهاز، ولا يتم أبدًا إرسالها إلى خوادم 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 مقدِّم الخدمة لإتاحة مساحة تخزين CE والسماح بدء تشغيل التطبيق كالمعتاد.
    • تم تجاهل K_k وK_s.

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

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

في حالات معينة، يتم التحقق من رمز رقم التعريف الشخصي لشريحة SIM من ذاكرة التخزين المؤقت، عملية تسمى إعادة تشغيل SIM-PIN.

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

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

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

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

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

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

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

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

Android 11 فقط

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

منذ تموز (يوليو) 2020، تنقسم عمليات تنفيذ RoR HAL إلى فئتين:

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

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

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

تدفق تحديث التحديث عبر الهواء باستخدام RoR

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

  1. يعمل تطبيق عميل "عبر الهواء" على تنزيل التحديث.
  2. يتصل تطبيق عميل "عبر الهواء" برقم "RecoverySystem#prepareForUnattendedUpdate" الذي تؤدي إلى مطالبة المستخدم بإدخال رقم التعريف الشخصي أو النقش أو كلمة المرور على شاشة القفل أثناء فتح القفل في المرة التالية.
  3. يفتح المستخدم قفل الجهاز على شاشة القفل ويصبح الجهاز جاهزًا. ليتم تطبيق التحديث.
  4. يتصل تطبيق عميل "عبر الهواء" بالحساب 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