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

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

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

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

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

خلفية

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

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

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

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

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

اختبارات

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

    adb shell cmd phone unattended-reboot

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

Android 11 فقط

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

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

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

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

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

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

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

  1. يقوم تطبيق عميل OTA بتنزيل التحديث.
  2. المكالمات أوتا التطبيق العميل ل 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

في شجرة الجهاز نواة لينكس، ويجب حجز الذاكرة ل 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