في Android 11، يمكن تطبيق تحديثات التحديث عبر الهواء باستخدام تحديث أ/ب. أو الآليات الافتراضية لتحديث A/B إلى جانب RecoverySystem طرق الفئات. بعد إعادة تشغيل الجهاز لتطبيق تحديث عبر الهواء، تؤدي عملية الاستئناف عند إعادة التشغيل (RoR) إلى فتح قفل وحدة تخزين بيانات الاعتماد المشفّرة (CE) للجهاز.
على الرغم من أنّه يمكن للشركاء إقران هذه العملية بميزة نظام OTA تُطبّق التحديثات عندما يكون الجهاز في وضع السكون في Android 11، لا يحتاج الشركاء إلى ميزة إضافية لنظام OTA في Android 12. توفّر عملية RoR أمانًا إضافيًا وراحة للمستخدمين لأنّه يمكن إجراء التحديثات أثناء أوقات عدم استخدام الجهاز، في حين أنّ وظائف التحديث المتعدّدة العملاء والخوادم في Android 12 يوفّرن معًا أمانًا من النوع على مستوى أجهزة Android.
على الرغم من أنّه يجب منح إذن الجهاز لميزة android.hardware.reboot_escrow
لتفعيل ميزة "الوصول المباشر إلى الشبكة" في Android 11، ليس عليك إجراء ذلك لتفعيل
ميزة "الوصول المباشر إلى الشبكة" المستندة إلى الخادم في Android 12 والإصدارات الأحدث، لأنّها
لا تستخدِم HAL.
خلفية
بدءًا من نظام التشغيل Android 7، كان التشغيل المباشر متوافقًا مع Android، التي تتيح بدء تشغيل التطبيقات على الجهاز قبل فتح قفل تخزين CE بواسطة المستخدم. أدى تنفيذ دعم التمهيد المباشر إلى تزويد المستخدمين بتجربة قبل إدخال عامل المعرفة لشاشة القفل (LSKF) بعد التشغيل.
تسمح ميزة RoR بفتح قفل تخزين CE لجميع التطبيقات على الجهاز، بما في ذلك تطبيقات لا تدعم التشغيل المباشر، عندما تبدأ إعادة التشغيل بعد تحديث عبر اتصال لاسلكي وتتيح هذه الميزة للمستخدمين تلقّي الإشعارات من جميع التطبيقات المثبّتة، بعد إعادة التشغيل.
نموذج التهديد
يجب أن يتأكد تنفيذ تسجيل الردود الإيجابية من أنه عندما يسقط الجهاز في يد المهاجم يصبح من الصعب للغاية على المهاجم استعادة حالة التشفير التام بين الأطراف. البيانات المشفّرة، حتى إذا كان الجهاز قيد التشغيل، وتم فتح قفل مساحة تخزين CE يجري المستخدم فتح قفل الجهاز بعد تلقّي تحديث عبر الهواء. النشرة الإخبارية يجب أن تكون مقاومة الهجوم فعالة حتى إذا تمكن المهاجم من الوصول إلى بث مفاتيح التوقيع المشفّر.
وعلى وجه التحديد، يجب ألا يقرأ مهاجم تخزين البريد الإلكتروني ما إذا كان قد تم فعليًا اختراقه بالجهاز، ويشتمل على الإمكانيات والقيود التالية:
الإمكانات
- يمكنه استخدام مفتاح التوقيع الخاص بأي مورّد أو شركة لتوقيع رسائل عشوائية.
- قد يؤدي إلى تلقّي الجهاز تحديثًا عبر الهواء.
- يمكنه تعديل تشغيل أي أجهزة (مثل معالج التطبيقات أو ذاكرة فلاش) باستثناء ما هو موضّح بالتفصيل في الحدود أدناه. (ومع ذلك، يتضمن هذا التعديل تأخيرًا لمدة ساعة على الأقل تؤدي إلى تدمير محتوى ذاكرة الوصول العشوائي).
القيود
- لا يمكنه تعديل تشغيل أجهزة مقاومة للتلاعب (على سبيل المثال، Titan M).
- لا يمكن قراءة ذاكرة الوصول العشوائي للجهاز المباشر.
- لا يمكنه تخمين بيانات اعتماد المستخدم (رقم التعريف الشخصي أو النقش أو كلمة المرور) أو سبب آخر أن يتم إدخالها.
الحل
يوفر نظام تحديث RoR في Android 12 أمانًا ضد المهاجمين المتقدّمين جدًا، ويفعل ذلك مع إبقاء كلمات المرور وأرقام التعريف الشخصي على الجهاز، ولا يتم إرسالها أو تخزينها على خوادم Google. إليك نظرة عامة على العملية التي تضمن تشابه مستويات الأمان المقدَّمة مع نظام RoR المستنِد إلى الأجهزة على مستوى الجهاز:
- يطبّق Android إجراءات الحماية المشفّرة على البيانات المخزّنة على الجهاز.
- تتم حماية جميع البيانات بواسطة مفاتيح يتم تخزينها في بيئة التنفيذ الموثوقة (TEE).
- لا يُطلق TEE المفاتيح إلا إذا اجتاز نظام التشغيل الذي يعمل عليه مصادقة التشفير (التشغيل المتحقَّق منه).
- تعمل خدمة RoR التي تعمل على خوادم Google على تأمين بيانات CE من خلال تخزين مفتاح سرّي يمكن استردادها لفترة محدودة فقط وتعمل هذه الميزة على جميع الأجهزة التي تعمل بنظام Android.
- يُستخدم مفتاح التشفير المحمي برقم التعريف الشخصي للمستخدم لفتح قفل الجهاز
وفك تشفير وحدة تخزين CE.
- عند جدولة إعادة التشغيل خلال الليل، يطلب 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 المحفوظة إلا مرة واحدة بعد إعادة التشغيل التي يتم بدءها تلقائيًا. لمدة زمنية قصيرة جدًا (20 ثانية) فقط: إذا كانت تفاصيل شريحة SIM مطابقة البطاقة. لا يتم نقل رقم التعريف الشخصي لشريحة SIM المُخزَّنة من تطبيق TechnicalManager مطلقًا ولا لا يمكن استردادها بواسطة وحدات خارجية.
إرشادات التنفيذ
في Android 12، توفّر وظائف RoR المستندة إلى الخادم والعملاء المتعدّدين حملًا أخفّ على الشركاء عند طرح التحديثات عبر الهواء. يمكن أن يتم إجراء التحديثات اللازمة خلال فترات توقف الجهاز عن العمل، مثلاً أثناء ساعات النوم المحددة.
والتأكّد من أنّ التحديثات عبر الهواء خلال هذه الفترات الزمنية لا تقاطع المستخدمين،
استخدام الوضع الداكن للتخفيف من انبعاثات الضوء. لإجراء ذلك، اطلب من
برنامج الإقلاع في الجهاز البحث عن السلسلة reason 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 نهائيًا اعتبارًا من الإصدار 12 من نظام التشغيل Android.
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 المميّزة واجهة برمجة التطبيقات لنظام TechnicalManager.
الاختبار
لاختبار واجهة برمجة التطبيقات الجديدة، نفِّذ الأمر التالي:
adb shell cmd phone unattended-reboot
لا يعمل هذا الأمر إلا عند تشغيل واجهة الأوامر كجذر (adb root).
Android 11 فقط
تنطبق بقية هذه الصفحة على نظام التشغيل Android 11.
منذ تموز (يوليو) 2020، تنقسم عمليات تنفيذ RoR HAL إلى فئتين:
- إذا كان جهاز SoC يتوافق مع الاحتفاظ بذاكرة الوصول العشوائي (RAM) بعد عمليات إعادة التشغيل، يمكن لمصنّعي المعدّات الأصلية استخدام التنفيذ التلقائي في AOSP (Default RAM Escrow).
- إذا كان جهاز الجهاز أو المنظومة على الرقاقة (SoC) يتيحان إنشاء منطقة آمنة للأجهزة (معالج أمان تكميلي منفصل مزوّد بذاكرة وصول عشوائي (RAM) وذاكرة قراءة فقط (ROM) خاصة به)، يجب أن ينفِّذ الجهاز بالإضافة إلى ذلك ما يلي:
- القدرة على اكتشاف إعادة تشغيل وحدة المعالجة المركزية الرئيسية.
- توفّر مصدر موقّت للأجهزة يظل على مدار عمليات إعادة التشغيل. وهي أن أن يكون قادرًا على اكتشاف إعادة التشغيل وانتهاء صلاحية مؤقت تم تعيينه قبل إعادة التشغيل.
- أن تتيح تخزين مفتاح مُودع في ذاكرة الوصول العشوائي (RAM) أو ذاكرة القراءة فقط (ROM) للمنطقة المحصورة بحيث لا يمكن استرداده من خلال هجمات بلا إنترنت يجب تخزين مفتاح RoR بطريقة تصعِّب على المستخدمين الداخليين أو المهاجمين استرداده.
ضمان ذاكرة الوصول العشوائي التلقائية
يتضمّن AOSP تنفيذًا لواجهة برمجة التطبيقات لـ RoR باستخدام ميزة الاحتفاظ بالبيانات في ذاكرة الوصول العشوائي. لكي تعمل هذه الميزة، على المصنّعين الأصليّين للأجهزة التأكّد من أنّ وحدات المعالجة المركزية المتكاملة (SoC) تتيح الاحتفاظ ببيانات ذاكرة الوصول العشوائي (RAM) أثناء عمليات إعادة التشغيل. ولا تستطيع بعض تقنيات المنظومة على رقاقة الاحتفاظ بمحتويات ذاكرة الوصول العشوائي (RAM) عبر إعادة التشغيل، لذا وننصح المصنّعين الأصليّين للأجهزة باستشارة شركائهم من المنظومة على الرقاقة (SoC) قبل تفعيل طبقة تجريد الأجهزة (HAL) التلقائية هذه. يمكنك الاطّلاع على المرجع الأساسي لهذا الإجراء في القسم التالي.
خطوات التحديث عبر الهواء باستخدام إعادة التوجيه
يجب أن يكون لدى تطبيق عميل OTA على الهاتف الإذنان
Manifest.permission.REBOOT
وManifest.permission.RECOVERY لاستدعاء الطرق اللازمة لتطبيق إعادة التشغيل السريع. ومع وجود هذا الشرط الأساسي، فإن تدفق
يتبع تحديث الخطوات التالية:
- ينزِّل تطبيق العميل للتحديث عبر الهواء.
- يُجري تطبيق عميل OTA مكالمات إلى
RecoverySystem#prepareForUnattendedUpdate، ما يؤدي إلى توجيه طلب إلى المستخدم لإدخال رقم التعريف الشخصي أو النقش أو كلمة المرور على شاشة القفل أثناء عملية فتح القفل التالية. - يفتح المستخدم قفل الجهاز من شاشة القفل، ويصبح الجهاز جاهزًا لتطبيق التحديث.
- يتصل تطبيق عميل "عبر الهواء" بالحساب
RecoverySystem#rebootAndApply، والذي يتم فورًا يؤدي إلى إعادة التشغيل.
وفي نهاية هذه العملية، تتم إعادة تشغيل الجهاز وتجاوز عائد الإنفاق الإعلاني. آلية فتح قفل تخزين بيانات الاعتماد المشفر (CE). بالنسبة إلى التطبيقات، سيتم تظهر كفتح عادي لأي مستخدم، لذلك يتلقّى جميع الإشارات، مثل ACTION_LOCKED_BOOT_COMPLETED أو ACTION_BOOT_مكتمل وهو ما يفعلونه عادةً.
تعديل إعدادات المنتجات
يجب أن يتضمّن المنتج الذي تم وضع علامة عليه بأنّه متوافق مع ميزة "إعادة التشغيل الآمن" في 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