في Android 11، يمكن تطبيق التحديثات عبر الهواء باستخدام آليات تحديث A/B أو تحديث A/B الافتراضي، مع اتّباع طُرق فئة RecoverySystem . بعد إعادة تشغيل الجهاز لتطبيق تحديث عبر الهواء، يؤدي ميزة "استئناف التشغيل عند إعادة التشغيل" (RoR) إلى فتح قفل مساحة تخزين "التخزين المشفَّر للمصادقة" (CE) على الجهاز.
على الرغم من أنّه يمكن للشركاء إقران هذه العملية بإحدى ميزات نظام التحديث عبر الهواء التي تطبّق التحديثات عندما يكون من المتوقّع أن يكون الجهاز غير نشِط لفترة قصيرة على نظام Android 11، إلا أنّ الشركاء الذين يستخدمون الإصدار 12 من Android لا يحتاجون إلى ميزة إضافية للنظام عبر الهواء. توفّر عملية RoR أمانًا إضافيًا وراحة للمستخدمين لأنّه يمكن إجراء التحديثات أثناء أوقات عدم استخدام الجهاز، في حين أنّ وظائف التحديث المتعدّدة العملاء والأنظمة المستندة إلى الخادم في Android 12 يوفّرن معًا أمانًا من النوع على مستوى أجهزة Android.
على الرغم من أنّه يجب منح إذن الجهاز لميزة android.hardware.reboot_escrow
لتفعيل ميزة "الوصول المباشر إلى الشبكة" في Android 11، لا تحتاج إلى إجراء ذلك لتفعيل
ميزة "الوصول المباشر إلى الشبكة" المستندة إلى الخادم في Android 12 والإصدارات الأحدث، لأنّها
لا تستخدِم HAL.
خلفية
بدءًا من الإصدار 7 من Android، أصبح من الممكن تفعيل ميزة Direct Boot في Android، التي تتيح تشغيل التطبيقات على الجهاز قبل أن يفتح المستخدم قفل مساحة التخزين في ذاكرة التخزين المؤقت للتطبيقات. وقد وفّر تنفيذ دعم التشغيل المباشر للمستخدمين تجربة أفضل قبل أن يتم إدخال عامل المعرفة لشاشة القفل (LSKF) بعد التشغيل.
تتيح RoR إمكانية فتح قفل مساحة تخزين CE لجميع التطبيقات على الجهاز، بما في ذلك التطبيقات التي لا تتوافق مع "التشغيل المباشر"، وذلك عند بدء إعادة التشغيل بعد إجراء تحديث عبر الهواء. وتمكّن هذه الميزة المستخدمين من تلقي الإشعارات من جميع التطبيقات المثبتة لديهم بعد إعادة التشغيل.
نموذج التهديد
يجب أن يضمن تنفيذ ميزة "إعادة التشغيل الآمن" أنّه عندما يقع الجهاز في أيدي أحد المهاجمين، سيكون من الصعب جدًا عليه استرداد بيانات المستخدم المشفَّرة باستخدام تقنية "التشفير من جهة العميل"، حتى إذا كان الجهاز مفعَّلاً، وتم فتح قفل مساحة التخزين المشفَّرة باستخدام تقنية "التشفير من جهة العميل"، وفتح المستخدم قفل الجهاز بعد تلقّي تحديث عبر الهواء. يجب أن تكون مقاومة هجمات الموظفين الداخليين فعالة حتى إذا تمكن المهاجم من الوصول إلى مفاتيح التوقيع التشفيري المخصّصة للبث.
على وجه التحديد، يجب ألّا يقرأ مهاجم يملك الجهاز فعليًا مساحة تخزين CE، وأن يكون لديه الإمكانات والقيود التالية:
الإمكانات
- يمكن استخدام مفتاح التوقيع الخاص بأي مورّد أو شركة لتوقيع رسائل عشوائية.
- قد يؤدي إلى تلقّي الجهاز تحديثًا عبر الهواء.
- يمكنه تعديل تشغيل أي أجهزة (مثل معالج التطبيقات أو ذاكرة فلاش) باستثناء ما هو موضّح بالتفصيل في الحدود أدناه. (ومع ذلك، يتضمن هذا التعديل تأخيرًا لمدة ساعة على الأقل ودورة طاقة تدمر محتويات ذاكرة الوصول العشوائي).
القيود
- لا يمكن تعديل عملية تشغيل الأجهزة المقاومة للتلاعب (مثل Titan M).
- لا يمكن قراءة ذاكرة الوصول العشوائي للجهاز المباشر.
- لا يمكنه تخمين بيانات اعتماد المستخدم (رقم التعريف الشخصي أو النقش أو كلمة المرور) أو التسبب في إدخالها بأي طريقة أخرى.
الحل
يوفر نظام تحديث RoR في Android 12 أمانًا ضد المهاجمين المتقدّمين جدًا، ويفعل ذلك مع إبقاء كلمات المرور وأرقام التعريف الشخصي على الجهاز، ولا يتم إرسالها أو تخزينها على خوادم Google. في ما يلي نظرة عامة على العملية التي تضمن أن تكون مستويات الأمان المقدمة مماثلة لنظام RoR المستند إلى الأجهزة على مستوى الجهاز:
- يطبِّق Android إجراءات الحماية المشفَّرة على البيانات المخزَّنة على الجهاز.
- تتم حماية جميع البيانات بواسطة مفاتيح يتم تخزينها في بيئة التنفيذ الموثوقة (TEE).
- لا يُطلق TEE المفاتيح إلا إذا اجتاز نظام التشغيل الذي يعمل المصادقة التشفيرية (التشغيل المتحقَّق منه).
- تعمل خدمة RoR التي تعمل على خوادم Google على تأمين بيانات CE من خلال تخزين سر يمكن استرداده لفترة محدودة فقط. وتعمل هذه الميزة على جميع الأجهزة التي تعمل بنظام Android.
- يتم استخدام مفتاح تشفير محمي برقم تعريف شخصي للمستخدم لفتح قفل الجهاز
وفك تشفير مساحة التخزين في ميزة "التخزين المؤقت للتطبيقات".
- عند جدولة إعادة التشغيل أثناء الليل، يطلب Android من المستخدم إدخال رقم التعريف الشخصي، ثم يحسب كلمة مرور اصطناعية (SP).
- بعد ذلك، يتم تشفير المعالج المتعدّد النوى مرتين: مرة باستخدام مفتاح
K_sالمخزَّن في ذاكرة الوصول العشوائي (RAM) ومرّة أخرى باستخدام مفتاحK_kالمخزَّن في وحدة TEE. - يتم تخزين مقدم الخدمة المشفر مزدوجًا على القرص، ويتم مسح مقدم الخدمة من ذاكرة الوصول العشوائي. يتم إنشاء كلا المفتاحَين حديثًا ويتم استخدامهما لإعادة تشغيل واحدة فقط.
- عندما يحين وقت إعادة التشغيل، يكلف Android
K_sبالخادم. يتم تشفير الإيصال الذي يتضمّنK_kقبل تخزينه على القرص. - بعد إعادة التشغيل، يستخدم Android
K_kلفك تشفير الإيصال، ثم يرسله إلى الخادم لاستردادK_s.- يتم استخدام
K_kوK_sلفك تشفير مقدِّم الخدمة المُخزَّن على القرص. - يستخدم Android مقدِّم الخدمة لإتاحة مساحة تخزين CE والسماح بدء تشغيل التطبيق كالمعتاد.
- يتم تجاهل
K_kوK_s.
- يتم استخدام
يمكن أن يتم تثبيت التحديثات التي تحافظ على أمان هاتفك في الوقت المناسب لائق لك: أثناء النوم.
إعادة تشغيل رقم التعريف الشخصي لشريحة SIM
في حالات معينة، يتم التحقق من رمز رقم التعريف الشخصي لشريحة SIM من ذاكرة التخزين المؤقت، وهي عملية تسمى إعادة تشغيل رقم التعريف الشخصي لشريحة SIM.
يجب أيضًا أن تخضع شريحة SIM التي تتضمّن رقم تعريف شخصي لتفعيل عملية إثبات الهوية بسلاسة باستخدام رمز رقم التعريف الشخصي (إعادة تشغيل شريحة SIM ورقم التعريف الشخصي) بعد إعادة التشغيل بدون رقابة لاستعادة إمكانية الاتصال بشبكة الجوّال (المطلوبة للمكالمات الهاتفية ورسائل SMS وخدمات البيانات). يتم تخزين رقم التعريف الشخصي لشريحة SIM ومعلومات شريحة SIM المطابقة (رقم ICCID ورقم قاعدة شريحة SIM) معًا بشكل آمن. ولا يمكن استرداد رقم التعريف الشخصي المخزن واستخدامه لإثبات الملكية إلا بعد إعادة تشغيل الجهاز بنجاح دون رقابة. إذا كان الجهاز آمنًا، يتم تخزين رقم التعريف الشخصي لشريحة SIM مع مفاتيح محمية ببروتوكول LSKF. إذا كانت شريحة SIM مفعَّلة فيها ميزة "رقم التعريف الشخصي"، يتطلب التفاعل مع خادم RoR اتصالاً بشبكة Wi-Fi لتلقّي التحديثات عبر الهواء وإعادة تشغيل الجهاز باستخدام ميزة RoR المستندة إلى الخادم، ما يضمن وظائفه الأساسية (مع إمكانية الاتصال بشبكة الجوّال) بعد إعادة التشغيل.
تتم إعادة تشفير رقم التعريف الشخصي لبطاقة SIM وتخزينه في كل مرة يفعّل فيها المستخدم رقم التعريف الشخصي أو يتحقّق منه أو يعدّله بنجاح. يتم إلغاء رقم التعريف الشخصي لشريحة SIM في حالة حدوث أي مما يلي:
- تمت إزالة شريحة SIM أو إعادة ضبطها.
- إيقاف المستخدم لرقم التعريف الشخصي
- حدثت عملية إعادة تشغيل بدون تسجيل إذن الوصول.
لا يمكن استخدام رقم التعريف الشخصي لشريحة SIM المحفوظة إلا مرة واحدة بعد إعادة التشغيل التي تبدأ بـ RoR، ولمدّة زمنية قصيرة جدًا (20 ثانية) في حال تطابق تفاصيل شريحة SIM. لا يغادر رقم التعريف الشخصي لشريحة SIM المخزَّن تطبيق TelephonyManager مطلقًا، ولا يمكن للوحدات الخارجية استرجاعه.
إرشادات التنفيذ
في Android 12، توفّر دوال RoR المتعددة العملاء والمستندة إلى الخادم حِملًا أسهل للشركاء عند إصدار التحديثات عبر الهواء. يمكن أن يتم إجراء التحديثات اللازمة أثناء فترات توقف الجهاز عن العمل، مثلاً خلال ساعات النوم المخصصة.
لضمان عدم انقطاع تحديثات 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.
TelephonyManager
يستدعي برنامج OTA واجهة برمجة تطبيقات نظام TelephonyManager عند اقتراب موعد إعادة التشغيل في Android 12. تنقل واجهة برمجة التطبيقات هذه جميع رموز التعريف الشخصية المخزّنة مؤقتًا من
حالة AVAILABLE إلى حالة REBOOT_READY. إنّ TelephonyManager system
API محمي من خلال إذن 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()
تستخدم حِزم APK المزوّدة بامتيازات واجهة برمجة تطبيقات نظام TelephonyManager.
الاختبار
لاختبار واجهة برمجة التطبيقات الجديدة، نفِّذ الأمر التالي:
adb shell cmd phone unattended-rebootلا يعمل هذا الأمر إلا عند تشغيل واجهة الأوامر كجذر (adb root).
Android 11 فقط
ينطبق باقي هذه الصفحة على الإصدار 11 من نظام Android.
اعتبارًا من تموز (يوليو) 2020، تندرج عمليات تنفيذ RoR HAL ضمن فئتين:
- إذا كان جهاز SoC يتوافق مع الاحتفاظ بذاكرة الوصول العشوائي (RAM) بعد عمليات إعادة التشغيل، يمكن لمصنّعي الأجهزة الأصليين استخدام التنفيذ التلقائي في AOSP (Default RAM Escrow).
- إذا كانت معدّات الجهاز أو المنظومة على الرقاقة (SoC) تتوافق مع هيكل آمن للأجهزة (معالج أمان مساعد منفصل مزوّد بذاكرة وصول عشوائي وذاكرة القراءة فقط)، يجب أيضًا تنفيذ ما يلي:
- القدرة على اكتشاف إعادة تشغيل وحدة المعالجة المركزية الرئيسية.
- توفّر مصدر موقّت للأجهزة يظل على مدار عمليات إعادة التشغيل. وهذا يعني أنّه يجب أن يكون بالإمكان في الحجز المُعزَّز رصد عملية إعادة التشغيل وإنهاء صلاحية الموقّت الذي تم ضبطه قبل إعادة التشغيل.
- أن تتيح تخزين مفتاح مُودع في ذاكرة الوصول العشوائي (RAM) أو ذاكرة القراءة فقط (ROM) للمنطقة المحصورة بحيث لا يمكن استرداده من خلال هجمات بلا إنترنت يجب تخزين مفتاح RoR بطريقة تصعِّب على المستخدمين الداخليين أو المهاجمين استرداده.
ضمان ذاكرة الوصول العشوائي التلقائية
لدى AOSP تنفيذ خاص بـ RR HAL باستخدام ثبات ذاكرة الوصول العشوائي. ولكي ينجح ذلك، يجب أن يتأكّد المصنّعون الأصليون للأجهزة (OEM) من أنّ المنظومة على الرقاقة (SoC) تتوافق مع ثبات ذاكرة الوصول العشوائي أثناء عمليات إعادة التشغيل. يتعذّر على بعض تقنيات المنظومة على رقاقة (SoC) الاحتفاظ بمحتوى ذاكرة الوصول العشوائي (RAM) أثناء إعادة التشغيل، لذا ننصح المصنّعين الأصليين للأجهزة باستشارة شركاء المنظومة على الرقاقة (SoC) قبل تفعيل هذا المستوى التلقائي من HAL. يمكنك الاطّلاع على المرجع الأساسي لهذا الإجراء في القسم التالي.
تدفق تحديث التحديث عبر الهواء باستخدام RoR
يجب أن يكون لدى تطبيق عميل OTA على الهاتف الإذنان
Manifest.permission.REBOOT
وManifest.permission.RECOVERY لاستدعاء الطرق اللازمة لتطبيق إعادة التشغيل السريع. بعد استيفاء هذا الشرط المسبق، يتم تنفيذ الخطوات التالية في عملية التحديث:
- ينزِّل تطبيق العميل للتحديث عبر الهواء.
- يتصل تطبيق عميل "عبر الهواء" بالحساب
RecoverySystem#prepareForUnattendedUpdate، ما يُطلب من المستخدم إدخال رقم التعريف الشخصي أو النقش أو كلمة المرور على شاشة القفل أثناء عملية فتح القفل في المرة التالية. - يفتح المستخدم قفل الجهاز من شاشة القفل، ويصبح الجهاز جاهزًا لتطبيق التحديث.
- يطلب تطبيق العميل لنظام التشغيل من خلال الهواء
RecoverySystem#rebootAndApply، ما يؤدي بدوره إلى إعادة التشغيل على الفور.
وفي نهاية هذا المسار، تتم إعادة تشغيل الجهاز وتُتيح آلية RoR مساحة تخزين بيانات الاعتماد المشفّرة (CE). بالنسبة إلى التطبيقات، يظهر هذا الإجراء على أنّه عملية إلغاء قفل عادية للمستخدم، وبالتالي تتلقّى التطبيقات جميع الإشارات، مثل ACTION_LOCKED_BOOT_COMPLETED و ACTION_BOOT_COMPLETED التي تتلقّاها عادةً.
تعديل إعدادات المنتجات
يجب أن يتضمّن المنتج الذي تم وضع علامة عليه على أنّه متوافق مع ميزة "إعادة التشغيل الآمن" في Android 11 ملف XML لتمييز الميزة ويجب أن يتضمّن تنفيذًا لواجهة برمجة التطبيقات RebootEscrow HAL. تعمل طريقة التنفيذ التلقائية بشكل جيد على الأجهزة التي تستخدم إعادة التشغيل البطيء (عندما تظلّ طاقة ذاكرة 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 للضمان التلقائي لإعادة التشغيل
لاستخدام التنفيذ التلقائي، يجب حجز 65536 (0x10000) بايت. لا تكتب أبدًا وحدات البايت هذه إلى وحدة تخزين غير متطايرة لضمان استمرار خصائص الأمان.
التغييرات في شجرة أجهزة نواة 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