این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

Resume-on-Reboot

در اندروید 11، به‌روزرسانی‌های OTA را می‌توان با استفاده از به‌روزرسانی A/B یا مکانیزم‌های به‌روزرسانی مجازی A/B ، همراه با روش‌های کلاس RecoverySystem اعمال کرد. پس از راه‌اندازی مجدد دستگاه برای اعمال به‌روزرسانی OTA، Resume-on-Reboot (RoR) قفل حافظه رمزگذاری شده اعتبار (CE) دستگاه را باز می‌کند.

اگرچه شرکا می توانند این فرآیند را با یک ویژگی سیستم OTA جفت کنند که زمانی که انتظار می رود دستگاه در Android 11 بیکار باشد، به روز رسانی ها را اعمال می کند، در Android 12 شرکا به ویژگی سیستم OTA اضافی نیاز ندارند. فرآیند RoR امنیت و راحتی بیشتری را برای کاربران فراهم می‌کند زیرا به‌روزرسانی‌ها را می‌توان در زمان‌های بی‌حرکتی دستگاه انجام داد، در حالی که عملکردهای به‌روزرسانی چند کلاینت و مبتنی بر سرور Android 12 با هم امنیت نوع سخت‌افزاری دستگاه را فراهم می‌کنند.

اگرچه برای پشتیبانی از RoR در اندروید 11 باید مجوز دستگاه را برای ویژگی android.hardware.reboot_escrow ارائه دهید، اما برای فعال کردن RoR مبتنی بر سرور در اندروید 12 و بالاتر، نیازی به انجام این کار ندارید، زیرا آنها از HAL استفاده نمی کنند.

پس زمینه

با شروع اندروید 7، اندروید از Direct Boot پشتیبانی می‌کرد که به برنامه‌های دستگاه امکان می‌دهد قبل از باز شدن قفل حافظه CE توسط کاربر، راه‌اندازی شوند. اجرای پشتیبانی از راه‌اندازی مستقیم، قبل از اینکه فاکتور دانش صفحه قفل (LSKF) پس از بوت وارد شود، تجربه بهتری را برای کاربران فراهم کرد.

RoR اجازه می‌دهد تا هنگام راه‌اندازی مجدد پس از به‌روزرسانی OTA، ذخیره‌سازی CE همه برنامه‌های روی دستگاه، از جمله برنامه‌هایی که از Direct Boot پشتیبانی نمی‌کنند، باز شود. این ویژگی به کاربران این امکان را می‌دهد تا از تمام برنامه‌های نصب شده خود، پس از راه‌اندازی مجدد، اعلان دریافت کنند.

مدل تهدید

پیاده‌سازی RoR باید اطمینان حاصل کند که وقتی دستگاهی به دست مهاجم می‌افتد، بازیابی اطلاعات رمزگذاری‌شده با CE کاربر برای مهاجم بسیار دشوار است، حتی اگر دستگاه روشن باشد، فضای ذخیره‌سازی CE باز است، و قفل دستگاه توسط مهاجم باز می‌شود. کاربر پس از دریافت به روز رسانی OTA. مقاومت حمله خودی باید موثر باشد حتی اگر مهاجم به کلیدهای امضای رمزنگاری پخش دسترسی پیدا کند.

به طور خاص، فضای ذخیره سازی CE نباید توسط مهاجمی که به صورت فیزیکی دستگاه را در اختیار دارد، خوانده شود و این قابلیت ها و محدودیت ها را دارد:

قابلیت ها

می توانید از کلید امضای هر فروشنده یا شرکتی برای امضای پیام های دلخواه استفاده کنید.
می تواند باعث شود دستگاه یک به روز رسانی OTA دریافت کند.
می تواند عملکرد هر سخت افزاری (مانند پردازنده برنامه یا حافظه فلش) را تغییر دهد - به جز مواردی که در محدودیت های زیر شرح داده شده است. (با این حال، چنین اصلاحی شامل تاخیر حداقل یک ساعتی و چرخه برق است که محتویات RAM را از بین می برد.)

محدودیت ها

نمی‌توان عملکرد سخت‌افزار مقاوم در برابر دستکاری (مثلاً Titan M) را تغییر داد.
نمی توان رم دستگاه زنده را خواند.
نمی توان اعتبار کاربر (پین، الگو، رمز عبور) را حدس زد یا باعث وارد شدن آنها نمی شود.

راه حل

سیستم به‌روزرسانی اندروید 12 RoR امنیت را در برابر مهاجمان بسیار پیچیده فراهم می‌کند، و این کار را زمانی انجام می‌دهد که گذرواژه‌ها و پین‌های روی دستگاه روی دستگاه باقی می‌مانند—این‌ها هرگز به سرورهای Google ارسال نمی‌شوند یا در آن‌ها ذخیره نمی‌شوند. این یک نمای کلی از فرآیند است که تضمین می کند سطوح امنیتی ارائه شده مشابه یک سیستم RoR مبتنی بر سخت افزار در سطح دستگاه است:

Android از حفاظت رمزنگاری بر روی داده های ذخیره شده در دستگاه استفاده می کند.
تمام داده ها توسط کلیدهای ذخیره شده در محیط اجرای قابل اعتماد (TEE) محافظت می شوند.
TEE تنها در صورتی کلیدها را آزاد می کند که سیستم عامل در حال اجرا احراز هویت رمزنگاری را بگذراند ( بوت تایید شده ).
سرویس RoR که روی سرورهای Google اجرا می‌شود، داده‌های CE را با ذخیره یک راز که فقط برای مدت محدودی قابل بازیابی است، ایمن می‌کند. این در سراسر اکوسیستم اندروید کار می کند.
یک کلید رمزنگاری که توسط پین کاربر محافظت می‌شود، برای باز کردن قفل دستگاه و رمزگشایی ذخیره‌سازی CE استفاده می‌شود.
- هنگامی که راه اندازی مجدد شبانه برنامه ریزی شده است، اندروید از کاربر می خواهد که پین خود را وارد کند، سپس یک رمز عبور مصنوعی (SP) محاسبه می کند.
- سپس SP را دو بار رمزگذاری می کند: یک بار با یک کلید K_s ذخیره شده در RAM و دوباره با یک کلید K_k ذخیره شده در TEE.
- SP دوگانه رمزگذاری شده روی دیسک ذخیره می شود و SP از RAM پاک می شود. هر دو کلید تازه تولید شده اند و فقط برای یک راه اندازی مجدد استفاده می شوند.
وقتی زمان راه اندازی مجدد فرا می رسد، اندروید K_s به سرور می سپارد. رسید با K_k قبل از اینکه روی دیسک ذخیره شود رمزگذاری می شود.
پس از راه‌اندازی مجدد، Android از K_k برای رمزگشایی رسید استفاده می‌کند، سپس آن را برای بازیابی K_s به سرور ارسال می‌کند.
- K_k و K_s برای رمزگشایی SP ذخیره شده روی دیسک استفاده می شوند.
- Android از SP برای باز کردن قفل حافظه CE و اجازه راه‌اندازی نرمال برنامه استفاده می‌کند.
- K_k و K_s دور ریخته می شوند.

به‌روزرسانی‌هایی که تلفن شما را ایمن نگه می‌دارند، می‌توانند در زمانی که برای شما راحت است اتفاق بیفتند: زمانی که خواب هستید.

پخش مجدد سیم پین

تحت شرایط خاص، کد پین سیم کارت از حافظه پنهان تأیید می شود، فرآیندی که به آن پخش مجدد سیم پین می گویند.

یک سیم کارت با یک پین فعال نیز باید پس از راه اندازی مجدد بدون نظارت برای بازیابی اتصال سلولی (که برای تماس های تلفنی، پیام های پیام کوتاه و خدمات داده لازم است) تأیید کد پین یکپارچه (بازپخش مجدد سیم پین) انجام شود. پین سیم کارت و اطلاعات سیم کارت منطبق با آن (شماره ICCID و اسلات سیم) به طور ایمن با هم ذخیره می شوند. پین ذخیره شده را می توان تنها پس از راه اندازی مجدد موفقیت آمیز بدون نظارت بازیابی و برای تأیید استفاده کرد. اگر دستگاه ایمن باشد، پین سیم کارت با کلیدهای محافظت شده توسط LSKF ذخیره می شود. اگر سیم کارت پین خود را فعال کرده باشد، تعامل با سرور RoR به اتصال WiFi برای به‌روزرسانی OTA و RoR مبتنی بر سرور نیاز دارد که عملکرد اولیه (با اتصال سلولی) را پس از راه‌اندازی مجدد تضمین می‌کند.

هر بار که کاربر با موفقیت آن را فعال، تأیید یا تغییر می دهد، پین سیم کارت دوباره رمزگذاری و ذخیره می شود. در صورت بروز هر یک از موارد زیر، پین سیم کارت حذف می شود:

سیم کارت حذف یا تنظیم مجدد می شود.
کاربر پین را غیرفعال می کند.
راه اندازی مجدد بدون RoR آغاز شده است.

پین سیم کارت ذخیره شده فقط یک بار پس از راه‌اندازی مجدد توسط RoR و فقط برای مدت زمان بسیار کوتاه (20 ثانیه) قابل استفاده است – در صورتی که جزئیات سیم کارت مطابقت داشته باشد. پین سیم کارت ذخیره شده هرگز از برنامه TelephonyManager خارج نمی شود و توسط ماژول های خارجی قابل بازیابی نیست.

دستورالعمل های اجرایی

در Android 12، عملکردهای RoR مبتنی بر چند مشتری و سرور، زمانی که شرکا به‌روزرسانی‌های OTA را فشار می‌دهند، بار سبک‌تری را برای آنها فراهم می‌کند. به‌روزرسانی‌های ضروری ممکن است در زمان‌های از کار افتادن راحت دستگاه، مانند ساعات خواب تعیین‌شده، رخ دهد.

برای اطمینان از اینکه به‌روزرسانی‌های OTA در چنین بازه‌های زمانی کاربران را قطع نمی‌کند، از حالت تاریک برای کاهش انتشار نور استفاده کنید. برای انجام این کار، از بوت لودر دستگاه بخواهید دلیل رشته را unattended جستجو کند. اگر unattended true است، دستگاه را در حالت تاریک قرار دهید. توجه داشته باشید که وظیفه هر OEM کاهش انتشار صدا و نور است.

اگر به اندروید 12 ارتقا می‌دهید یا دستگاه‌های اندروید 12 را راه‌اندازی می‌کنید، برای اجرای عملکرد جدید RoR نیازی به انجام کاری ندارید.

یک تماس جدید در جریان چند مشتری وجود دارد، isPreparedForUnattendedUpdate ، که در زیر نشان داده شده است:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

نیازی به اجرای آن ندارید، زیرا HAL از اندروید 12 منسوخ شده است.

مدیر تلفن

سرویس گیرنده OTA هنگامی که راه اندازی مجدد قریب الوقوع در Android 12 است، API سیستم TelephonyManager را فراخوانی می کند. این API همه کدهای پین حافظه پنهان را از حالت AVAILABLE به حالت REBOOT_READY منتقل می کند. API سیستم 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()

API سیستم TelephonyManager توسط APKهای دارای امتیاز استفاده می شود.

تست کردن

برای تست API جدید، این دستور را اجرا کنید:

    adb shell cmd phone unattended-reboot

این دستور فقط زمانی کار می‌کند که پوسته به‌عنوان root در حال اجرا باشد ( adb root ).

فقط اندروید 11

باقیمانده این صفحه برای اندروید 11 اعمال می شود.

از جولای 2020، اجرای RoR HAL به دو دسته تقسیم می شود:

اگر سخت‌افزار SoC از پایداری RAM در طول راه‌اندازی مجدد پشتیبانی کند، OEM‌ها می‌توانند از پیاده‌سازی پیش‌فرض در AOSP ( پیش‌فرض RAM Escrow ) استفاده کنند.
اگر سخت‌افزار دستگاه یا SoC از یک محفظه سخت‌افزاری امن (یک پردازشگر امنیتی گسسته با RAM و ROM خود) پشتیبانی می‌کند، علاوه بر این باید موارد زیر را انجام دهد:
- قادر به تشخیص راه اندازی مجدد CPU اصلی باشید.
- یک منبع تایمر سخت افزاری داشته باشید که در طول راه اندازی مجدد باقی بماند. یعنی، Enclave باید بتواند راه‌اندازی مجدد را تشخیص دهد و تایمر تنظیم شده قبل از راه‌اندازی مجدد را منقضی کند.
- پشتیبانی از ذخیره یک کلید محتوی در RAM/ROM محصور به طوری که با حملات آفلاین قابل بازیابی نباشد. باید کلید RoR را به گونه ای ذخیره کند که بازیابی آن را برای خودی ها یا مهاجمان غیرممکن کند.

ذخیره پیش فرض RAM

AOSP پیاده سازی RoR HAL با استفاده از پایداری RAM دارد. برای این کار، OEM ها باید اطمینان حاصل کنند که SoC های آنها از پایداری RAM در طول راه اندازی مجدد پشتیبانی می کنند. برخی از SoCها قادر به حفظ محتوای RAM در طول راه اندازی مجدد نیستند، بنابراین به OEM ها توصیه می شود قبل از فعال کردن این HAL پیش فرض با شرکای SoC خود مشورت کنند. مرجع شرعی برای این در بخش زیر است.

جریان به روز رسانی OTA با استفاده از RoR

برنامه مشتری OTA روی تلفن باید دارای مجوزهای Manifest.permission.REBOOT و Manifest.permission.RECOVERY باشد تا روش های لازم برای اجرای RoR را فراخوانی کند. با وجود این پیش نیاز، جریان به روز رسانی این مراحل را دنبال می کند:

برنامه مشتری OTA به روز رسانی را دانلود می کند.
برنامه سرویس گیرنده OTA به RecoverySystem#prepareForUnattendedUpdate می‌گوید که باعث می‌شود در باز کردن قفل بعدی، از کاربر درخواست پین، الگو یا رمز عبور در صفحه قفل شود.
کاربر قفل دستگاه را در صفحه قفل باز می کند و دستگاه آماده اعمال به روز رسانی است.
برنامه سرویس گیرنده OTA به RecoverySystem#rebootAndApply تماس می گیرد، که بلافاصله راه اندازی مجدد راه اندازی می شود.

در پایان این جریان، دستگاه راه‌اندازی مجدد می‌شود و مکانیسم RoR حافظه رمزگذاری شده (CE) را باز می‌کند. برای برنامه‌ها، این به‌عنوان یک قفل عادی کاربر به نظر می‌رسد، بنابراین آنها همه سیگنال‌ها را دریافت می‌کنند، مانند ACTION_LOCKED_BOOT_COMPLETED و ACTION_BOOT_COMPLETED که معمولاً انجام می‌دهند.

تنظیمات محصول را اصلاح کنید

محصولی که به‌عنوان پشتیبانی از ویژگی RoR در Android 11 علامت‌گذاری شده است باید شامل اجرای RebootEscrow HAL و شامل فایل XML نشانگر ویژگی باشد. پیاده‌سازی پیش‌فرض در دستگاه‌هایی که از راه‌اندازی مجدد گرم استفاده می‌کنند به خوبی کار می‌کند (زمانی که برق DRAM در طول راه‌اندازی مجدد روشن می‌ماند).

نشانگر ویژگی escrow را مجدد راه اندازی کنید

نشانگر ویژگی نیز باید وجود داشته باشد:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

راه‌اندازی مجدد پیش‌فرض escrow اجرای HAL

برای استفاده از پیاده سازی پیش فرض، باید 65536 (0x10000) بایت را رزرو کنید. هرگز این بایت ها را در فضای ذخیره سازی غیر فرار ننویسید تا از حفظ ویژگی های امنیتی اطمینان حاصل کنید.

تغییرات درخت دستگاه هسته لینوکس

در درخت دستگاه هسته لینوکس، باید حافظه را برای منطقه 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