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 استفاده نمی کنند.

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

زمینه

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

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

مدل تهدید

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

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

توانایی ها

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

محدودیت ها

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

راه حل

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

  • اندروید برای داده‌های ذخیره‌شده در دستگاه، حفاظت‌های رمزنگاری را اعمال می‌کند.
  • تمام داده ها توسط کلیدهای ذخیره شده در محیط اجرای قابل اعتماد (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 به دو دسته تقسیم می شود:

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

پیش‌فرض RAM Escrow

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

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

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

  1. برنامه مشتری OTA به روز رسانی را دانلود می کند.
  2. برنامه مشتری OTA با RecoverySystem#prepareForUnattendedUpdate تماس می‌گیرد که باعث می‌شود در باز کردن قفل بعدی، پین، الگو یا رمز عبور از کاربر در صفحه قفل درخواست شود.
  3. کاربر قفل دستگاه را در صفحه قفل باز می کند و دستگاه آماده اعمال به روز رسانی است.
  4. برنامه مشتری 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