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

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

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

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

خلفية

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

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

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

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

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

قدرات

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

محددات

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

حل

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

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

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

إعادة تشغيل SIM-PIN

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

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

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

  • تتم إزالة بطاقة SIM أو إعادة تعيينها.
  • يقوم المستخدم بتعطيل PIN.
  • حدثت عملية إعادة تمهيد غير بنظام RoR.

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

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

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

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

مدير الهاتف

يستدعي عميل OTA واجهة برمجة تطبيقات نظام TelephonyManager عندما تكون إعادة التشغيل وشيكة في Android 12. تنقل واجهة برمجة التطبيقات هذه جميع رموز PIN المخزنة مؤقتًا من حالة AVAILABLE إلى حالة REBOOT_READY . واجهة برمجة تطبيقات نظام TelephonyManager محمية بإذن 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()

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

اختبارات

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

    adb shell cmd phone unattended-reboot

يعمل هذا الأمر فقط عندما تعمل الصدفة كجذر ( adb root ).

Android 11 فقط

باقي هذه الصفحة ينطبق على Android 11.

اعتبارًا من يوليو 2020 ، تنقسم تطبيقات RoR HAL إلى فئتين:

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

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

لدى AOSP تنفيذ RoR HAL باستخدام استمرارية ذاكرة الوصول العشوائي. لكي ينجح هذا ، يجب على مصنعي المعدات الأصلية التأكد من أن SoCs تدعم استمرارية ذاكرة الوصول العشوائي عبر عمليات إعادة التشغيل. يتعذر على بعض SoCs الاحتفاظ بمحتويات ذاكرة الوصول العشوائي عبر إعادة التشغيل ، لذلك يُنصح مصنعي المعدات الأصلية باستشارة شركاء SoC قبل تمكين HAL الافتراضي هذا. المرجع الأساسي لهذا في القسم التالي.

تدفق تحديث OTA باستخدام RoR

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

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

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

تعديل تكوينات المنتج

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

إعادة تشغيل علامة ميزة الضمان

يجب أن تكون علامة الميزة موجودة أيضًا:

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 kernel

في شجرة جهاز Linux kernel ، يجب حجز ذاكرة لمنطقة 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