در Android 11، به‌روزرسانی‌های OTA را می‌توان بااستفاده از سازوکارهای به‌روزرسانی A/B یا به‌روزرسانی مجازی A/B، همراه با روش‌های کلاس RecoverySystem اعمال کرد. پس‌از بازراه‌اندازی دستگاه برای اعمال به‌روزرسانی OTA، «ازسرگیری پس‌از بازراه‌اندازی» (RoR) فضای ذخیره‌سازی «رمزگذاری اطلاعات اعتباری» (CE) دستگاه را باز می‌کند.
اگرچه شرکا می‌توانند این فرایند را با ویژگی سیستم OTA جفت کنند که به‌روزرسانی‌ها را زمانی اعمال می‌کند که انتظار می‌رود دستگاه در Android 11 غیرفعال باشد، در Android 12 شرکا به ویژگی سیستم OTA اضافی نیاز ندارند. فرایند RoR امنیت و راحتی بیشتری برای کاربران فراهم می‌کند زیرا به‌روزرسانی‌ها را می‌توان در زمان‌های بیکاری دستگاه انجام داد، درحالی‌که Android 12 عملکردهای به‌روزرسانی چندکاربره و مبتنی بر سرور با هم امنیت نوع سخت‌افزار دستگاه را فراهم می‌کنند.
اگرچه برای پشتیبانی از RoR در Android 11 باید اجازه دستگاه را برای ویژگی android.hardware.reboot_escrow ارائه دهید، برای فعال کردن RoR مبتنی بر سرور در Android 12 و بالاتر نیازی به انجام این کار ندارید، زیرا این نسخه‌ها از HAL استفاده نمی‌کنند.
پس‌زمینه
از Android 7 به بعد، Android از راه‌اندازی مستقیم پشتیبانی می‌کند، که به برنامه‌های دستگاه امکان می‌دهد قبل‌از اینکه کاربر قفل فضای ذخیره‌سازی CE را باز کند، راه‌اندازی شوند. پیاده‌سازی پشتیبانی «راه‌اندازی مستقیم» تجربه بهتری را برای «کاربران» فراهم کرد، زیرا دیگر لازم نبود «عامل آگاهی صفحه قفل» (LSKF) پس‌از راه‌اندازی وارد شود.
RoR اجازه می‌دهد قفل فضای ذخیره‌سازی CE همه برنامه‌های دستگاه باز شود، ازجمله برنامه‌هایی که از «راه‌اندازی مستقیم» پشتیبانی نمی‌کنند، وقتی بازراه‌اندازی پس‌از به‌روزرسانی OTA شروع می‌شود. این ویژگی به کاربران امکان می‌دهد تا پس‌از راه‌اندازی مجدد، از همه برنامه‌های نصب‌شده‌شان اعلان دریافت کنند.
مدل تهدید
پیاده‌سازی RoR باید تضمین کند که وقتی دستگاه به دست مهاجم می‌افتد، حتی اگر دستگاه روشن باشد، فضای ذخیره‌سازی CE باز باشد، و کاربر دستگاه را پس‌از دریافت به‌روزرسانی OTA باز کند، بازیابی داده‌های رمزگذاری‌شده CE کاربر برای مهاجم بسیار دشوار باشد. مقاومت دربرابر حمله داخلی باید مؤثر باشد، حتی اگر مهاجم به کلیدهای امضای رمزنگاری‌شده همه‌فرستی دسترسی پیدا کند.
به‌طور مشخص، مهاجمی که به‌طور فیزیکی دستگاه را دراختیار دارد و دارای این قابلیت‌ها و محدودیت‌ها است نباید بتواند فضای ذخیره‌سازی CE را بخواند:
قابلیت‌ها
- می‌تواند از کلید امضای هر فروشنده یا شرکتی برای امضای پیام‌های دلخواه استفاده کند.
- می‌تواند باعث شود دستگاه به‌روزرسانی OTA دریافت کند.
- می‌تواند عملکرد هر سخت‌افزاری (مثل پردازنده برنامه یا حافظه فلش) را تغییر دهد - به‌جز مواردی که در بخش محدودیت‌ها در زیر به‌تفصیل شرح داده شده است. (بااین‌حال، چنین اصلاحی هم شامل حداقل یک ساعت تأخیر و هم شامل چرخه قدرت است که محتویات RAM را ازبین می‌برد.)
محدودیت‌ها
- نمی‌توان عملکرد سخت‌افزار مقاوم دربرابر دستکاری (برای مثال، Titan M) را تغییر داد.
- نمی‌توان RAM دستگاه فعال را خواند.
- نمی‌تواند اطلاعات کاربری کاربر (پین، الگو، گذرواژه) را حدس بزند یا به روش دیگری باعث شود این اطلاعات وارد شود.
راه‌حل
سیستم به‌روزرسانی Android 12 RoR امنیت را دربرابر مهاجمان بسیار پیچیده فراهم می‌کند، و این کار را درحالی انجام می‌دهد که گذرواژه‌ها و پین‌های درون‌دستگاهی در دستگاه باقی می‌مانند—هرگز به سرورهای Google ارسال یا در آن‌ها ذخیره نمی‌شوند. این نمای کلی از فرایندی است که تضمین می‌کند سطوح امنیتی ارائه‌شده مشابه سیستم RoR سخت‌افزاری در سطح دستگاه باشد:
- Android از داده‌های ذخیره‌شده در دستگاه با رمزنگاری محافظت می‌کند.
- همه داده‌ها با کلیدهای ذخیره‌شده در محیط اجرای امن (TEE) محافظت می‌شوند.
- «محیط اجرای مطمئن» فقط درصورتی کلیدها را منتشر می‌کند که سیستم‌عامل درحال اجرا اصالت‌سنجی رمزنگاری (راه‌اندازی تأییدشده) را بگذراند.
- سرویس RoR که در سرورهای Google اجرا می‌شود، داده‌های CE را با ذخیره کردن رمزی که فقط برای مدت محدودی قابل‌بازیابی است ایمن می‌کند. این ویژگی در سراسر بوم‌سازگان Android کار می‌کند.
- از کلید رمزنگاری که با پین کاربر محافظت می‌شود برای باز کردن قفل دستگاه
و رمزگشایی فضای ذخیره‌سازی CE استفاده می‌شود.
- وقتی بازراه‌اندازی شبانه زمان‌بندی می‌شود، Android از کاربر می‌خواهد پین خود را وارد کند، سپس گذرواژه ترکیبی (SP) را محاسبه می‌کند.
- سپس SP را دو بار رمزگذاری می‌کند: یک‌بار با کلید
K_sذخیره‌شده در RAM، و بار دیگر با کلیدK_kذخیره‌شده در TEE. - «اصل خدمات» با رمزگذاری مضاعف روی دیسک ذخیره می‌شود و «اصل خدمات» از «حافظه دسترسی تصادفی» پاک می‌شود. هر دو کلید به‌تازگی تولید شده‌اند و فقط برای یک بازراه‌اندازی استفاده می‌شوند.
- وقتی زمان بازراه‌اندازی فرا می‌رسد، Android
K_sرا به سرور می‌سپارد. رسید باK_kقبل‌از ذخیره شدن در دیسک رمزگذاری می‌شود. - پس‌از بازراه‌اندازی، Android از
K_kبرای رمزگشایی رسید استفاده می‌کند، سپس آن را برای سرور ارسال می‌کند تاK_sرا بازیابی کند.- از
K_kوK_sبرای رمزگشایی SP ذخیره‌شده در دیسک استفاده می‌شود. - Android از SP برای باز کردن قفل فضای ذخیره‌سازی CE و امکان راه‌اندازی عادی برنامه استفاده می‌کند.
-
K_kوK_sدور انداخته شدند.
- از
به‌روزرسانی‌هایی که امنیت تلفنتان را حفظ می‌کنند می‌توانند در زمان مناسبی برای شما انجام شوند: وقتی خوابید.
بازپخش پین سیم‌کارت
تحت شرایط خاصی، کد پین سیم‌کارت از حافظه نهان درستی‌سنجی می‌شود، این فرایند «بازپخش پین سیم‌کارت» نامیده می‌شود.
سیم‌کارت دارای پین فعال‌شده باید پس‌از بازراه‌اندازی بدون حضور کاربر، درستی‌سنجی کد پین یکپارچه (بازپخش پین سیم‌کارت) را نیز انجام دهد تا اتصال‌پذیری سلولی (لازم برای تماس تلفنی، پیامک، و خدمات داده) بازیابی شود. پین سیم‌کارت و اطلاعات سیم‌کارت منطبق با آن (ICCID و شماره شکاف سیم‌کارت) به‌طور ایمن باهم ذخیره می‌شوند. پین ذخیره‌شده را فقط پس‌از بازراه‌اندازی بدون حضور کاربر می‌توان بازیابی و برای درستی‌سنجی استفاده کرد. اگر دستگاه ایمن باشد، پین سیم‌کارت با کلیدهای محافظت‌شده توسط LSKF ذخیره می‌شود. اگر پین سیم‌کارت فعال باشد، تعامل با سرور «بازراه‌اندازی پس‌از راه‌اندازی مجدد» برای به‌روزرسانی ازطریق هوا و «بازراه‌اندازی پس‌از راه‌اندازی مجدد» مبتنی بر سرور به اتصال Wi-Fi نیاز دارد تا عملکرد اصلی (با اتصال شبکه تلفن همراه) پس‌از بازراه‌اندازی تضمین شود.
هر بار که کاربر باموفقیت پین سیم‌کارت را فعال، درستی‌سنجی، یا اصلاح می‌کند، پین سیم‌کارت دوباره رمزگذاری و ذخیره می‌شود. اگر هریک از موارد زیر اتفاق بیفتد، پین سیم‌کارت حذف می‌شود:
- سیم‌کارت برداشته شده یا بازنشانی شده باشد.
- کاربر پین را غیرفعال می‌کند.
- بازراه‌اندازی‌ای که با RoR شروع نشده است روی داده است.
پین سیم‌کارت ذخیره‌شده را فقط می‌توان یک‌بار پس‌از بازراه‌اندازی آغازشده توسط RoR استفاده کرد، و فقط برای مدت زمان بسیار کوتاهی (۲۰ ثانیه)–اگر جزئیات سیم‌کارت مطابقت داشته باشد. پین سیم‌کارت ذخیره‌شده هرگز از برنامه TelephonyManager خارج نمی‌شود و واحدهای خارجی نمی‌توانند آن را بازیابی کنند.
رهنمودهای پیاده‌سازی
در Android 12، عملکردهای چندکاربره و سرورمحور RoR هنگام ارسال به‌روزرسانی‌های OTA بار کمتری به شرکا تحمیل می‌کند. به‌روزرسانی‌های ضروری می‌تواند در زمان‌های مناسبی که دستگاه دراختیار نیست، مثلاً درطول ساعات خواب تعیین‌شده، انجام شود.
برای اطمینان از اینکه به‌روزرسانی‌های OTA در این دوره‌های زمانی باعث اختلال در کار کاربران نمی‌شود،
از حالت تاریک برای کاهش انتشار نور استفاده کنید. برای انجام این کار، bootloader دستگاه را طوری تنظیم کنید که رشته دلیل 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 منسوخ شده است.
TelephonyManager
وقتی بازراه‌اندازی در Android 12 قریب‌الوقوع باشد، کارخواه OTA میانای برنامه‌سازی کاربردی سیستم TelephonyManager را فراخوانی می‌کند. این «میانای برنامه‌سازی کاربردی» همه کدهای پین ذخیره‌شده در حافظه نهان را از وضعیت 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 API توسط فایل‌های APK دارای امتیاز استفاده می‌شود.
آزمایش
برای آزمایش کردن «میانای برنامه‌نویسی کاربردی» جدید، این فرمان را اجرا کنید:
adb shell cmd phone unattended-rebootاین فرمان فقط زمانی کار می‌کند که پوسته به‌عنوان ریشه (adb root) درحال اجرا باشد.
فقط Android 11
بقیه این صفحه برای Android 11 اعمال می‌شود.
از ژوئیه ۲۰۲۰، پیاده‌سازی‌های RoR HAL در دو دسته قرار می‌گیرند:
- اگر سخت‌افزار SoC از پایداری RAM در بازراه‌اندازی‌ها پشتیبانی کند، OEMها می‌توانند از پیاده‌سازی پیش‌فرض در AOSP (حساب امانی RAM پیش‌فرض) استفاده کنند.
- اگر سخت‌افزار دستگاه یا SoC از یک منطقه امن سخت‌افزاری (یک
هم‌پردازنده امنیتی مجزا با RAM و ROM خود) پشتیبانی می‌کند، علاوه بر این باید موارد زیر را انجام دهد:
- بتواند بازراه‌اندازی CPU اصلی را تشخیص دهد.
- منبع زمان‌سنج سخت‌افزاری داشته باشد که درطول بازراه‌اندازی‌ها حفظ شود. یعنی، قلمرو باید بتواند بازراه‌اندازی را تشخیص دهد و زمان‌سنج تنظیم‌شده قبل‌از بازراه‌اندازی را منقضی کند.
- از ذخیره کلید امانی در RAM/ROM محصور پشتیبانی می‌کند به‌طوری‌که نمی‌توان آن را با حمله‌های آفلاین بازیابی کرد. باید کلید RoR را به‌گونه‌ای ذخیره کند که بازیابی آن برای افراد داخلی یا مهاجمان غیرممکن باشد.
امانت‌گذاری پیش‌فرض RAM
AOSP پیاده‌سازی RoR HAL را بااستفاده از ماندگاری RAM دارد. برای اینکه این ویژگی کار کند، سازندگان تجهیزات اصلی باید مطمئن شوند که SoC آن‌ها از پایداری RAM در بازراه‌اندازی‌ها پشتیبانی می‌کند. برخی‌از «سیستم‌های روی تراشه» نمی‌توانند محتوای RAM را درطول بازراه‌اندازی حفظ کنند، بنابراین توصیه می‌شود «تولیدکنندگان تجهیزات اصلی» قبل‌از فعال کردن این HAL پیش‌فرض با شرکای «سیستم روی تراشه» خود مشورت کنند. مرجع متعارف برای این در بخش زیر.
جریان به‌روزرسانی ازطریق هوا بااستفاده از RoR
برنامه مشتری OTA در تلفن باید اجازه‌های
Manifest.permission.REBOOT
و Manifest.permission.RECOVERY را برای فراخوانی روش‌های لازم برای
پیاده‌سازی RoR داشته باشد. با وجود این پیش‌نیاز، جریان به‌روزرسانی این مراحل را دنبال می‌کند:
- برنامه کارخواه OTA به‌روزرسانی را بارگیری می‌کند.
- برنامه مشتری OTA با
RecoverySystem#prepareForUnattendedUpdateتماس می‌گیرد که باعث می‌شود از کاربر خواسته شود پین، الگو، یا گذرواژه خود را در صفحه قفل در باز کردن قفل بعدی وارد کند. - کاربر قفل دستگاه را در صفحه قفل باز می‌کند و دستگاه آماده است تا به‌روزرسانی اعمال شود.
- برنامه کارخواه «ازطریق هوا» با
RecoverySystem#rebootAndApplyتماس می‌گیرد که بلافاصله باعث راه‌اندازی مجدد می‌شود.
در پایان این جریان، دستگاه بازراه‌اندازی می‌شود و سازوکار RoR فضای ذخیره‌سازی رمزگذاری‌شده اطلاعات اعتباری (CE) را باز می‌کند. برای برنامه‌ها، این به‌صورت باز کردن قفل کاربر عادی ظاهر می‌شود، بنابراین همه نشان‌ها، مثل ACTION_LOCKED_BOOT_COMPLETED و ACTION_BOOT_COMPLETED را که معمولاً دریافت می‌کنند دریافت می‌کنند.
پیکربندی‌های محصول را تغییر دهد
محصولی که در Android 11 به‌عنوان پشتیبان ویژگی RoR علامت‌گذاری شده است باید پیاده‌سازی RebootEscrow 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 امانت بازراه‌اندازی پیش‌فرض
برای استفاده از پیاده‌سازی پیش‌فرض، باید ۶۵۵۳۶ (۰x۱۰۰۰۰) بایت را رزرو کنید. هرگز این بایت‌ها را در فضای ذخیره‌سازی غیرفرار ننویسید تا ویژگی‌های امنیتی پایدار بماند.
تغییرات درخت دستگاه هسته 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