في Android 11، يمكن تطبيق التحديثات عبر الهواء باستخدام آليات تحديث A/B أو تحديث A/B الافتراضي إلى جانب طرق فئة RecoverySystem. بعد إعادة تشغيل الجهاز لتطبيق تحديث OTA، يؤدي الاستئناف عند إعادة التشغيل (RoR) إلى فتح قفل وحدة تخزين بيانات الاعتماد المشفرة (CE) للجهاز.
على الرغم من أنّه يمكن للشركاء إقران هذه العملية بإحدى ميزات نظام التحديث عبر الهواء التي تطبّق التحديثات عندما يكون من المتوقّع أن يكون الجهاز غير مستخدَم في نظام التشغيل Android 11، إلا أنّ الشركاء الذين يستخدمون الإصدار 12 من Android لا يحتاجون إلى ميزة إضافية للنظام الخاص بالتحديث عبر الهواء. توفّر عملية RoR مزيدًا من الأمان والراحة للمستخدمين، لأنّه يمكن إجراء التحديثات أثناء أوقات عدم النشاط على الأجهزة، فيما توفّر وظائف التحديث المتعددة العملاء والمستندة إلى الخادم في نظام التشغيل Android 12 أمانًا على مستوى الأجهزة.
على الرغم من أنّه عليك منح إذن الوصول إلى الجهاز في ما يخص ميزة android.hardware.reboot_escrow لإتاحة RoR في نظام التشغيل Android 11، لست بحاجة إلى منح إذن الوصول إلى المحتوى المستند إلى الخادم في الإصدار 12 من نظام التشغيل Android والإصدارات الأحدث، لأنّها لا تستخدم HAL.
معلومات أساسية
بدايةً من نظام التشغيل Android 7، كان نظام Android يوفّر ميزة التشغيل المباشر، والتي تتيح بدء تشغيل التطبيقات على الجهاز قبل أن يفتح المستخدم قفل مساحة تخزين CE. وقد وفّر تنفيذ دعم التشغيل المباشر للمستخدمين تجربة أفضل قبل الدخول إلى معيار المعرفة لشاشة القفل (LSKF) بعد التشغيل.
تتيح ميزة RoR إمكانية فتح قفل مساحة تخزين CE لجميع التطبيقات على الجهاز، بما في ذلك التطبيقات التي لا تتوافق مع ميزة "التشغيل المباشر"، وذلك عند بدء إعادة التشغيل بعد إجراء تحديث عبر الهواء. وتمكّن هذه الميزة المستخدمين من تلقي الإشعارات من جميع التطبيقات المثبتة لديهم بعد إعادة التشغيل.
نموذج التهديد
يجب أن يتأكد تطبيق RoR عند وقوع أي جهاز في أيدي المهاجم أنه سيكون من الصعب للغاية على المهاجم استرداد بيانات المستخدم المشفرة بموجب CE، حتى إذا كان الجهاز قيد التشغيل، وتم إلغاء قفل وحدة تخزين CE، وإلغاء قفل الجهاز بعد تلقي تحديث عبر الهواء. يجب أن تكون مقاومة الهجوم الداخلي فعالة حتى إذا تمكن المهاجم من الوصول إلى مفاتيح التوقيع المشفّرة للبث.
على وجه التحديد، يجب ألا يقرأ المهاجم الذي يمتلك الجهاز فعليًا الجهاز ولديه الإمكانات والقيود التالية:
الإمكانات
- يمكنه استخدام مفتاح التوقيع الخاص بأي مورّد أو شركة لتوقيع رسائل عشوائية.
- قد يؤدي إلى تلقّي الجهاز تحديثًا عبر الهواء.
- يمكنه تعديل تشغيل أي جهاز (مثل معالج التطبيقات أو ذاكرة الفلاش) باستثناء ما هو موضح بالتفصيل في القيود أدناه. (ومع ذلك، يتضمن هذا التعديل تأخيرًا لمدة ساعة على الأقل ودورة طاقة تدمر محتويات ذاكرة الوصول العشوائي).
القيود
- لا يمكن تعديل عملية تشغيل الأجهزة المقاومة للتلاعب (مثل Titan M).
- لا يمكن قراءة ذاكرة الوصول العشوائي للجهاز المباشر.
- لا يمكنه تخمين بيانات اعتماد المستخدم (رقم التعريف الشخصي أو النقش أو كلمة المرور) أو التسبب في إدخالها بأي طريقة أخرى.
الحل
يوفّر نظام تحديث Android 12 RR مستوى أمان ضد المهاجمين المتطورين، ويحافظ على أمان كلمات المرور وأرقام التعريف الشخصية المحفوظة على الجهاز، ولا يتم مطلقًا إرسالها إلى خوادم Google أو تخزينها عليها. في ما يلي نظرة عامة على العملية التي تضمن أن تكون مستويات الأمان المقدمة مشابهة لنظام RoR المستند إلى الأجهزة على مستوى الجهاز:
- يطبِّق Android إجراءات الحماية المشفَّرة على البيانات المخزَّنة على الجهاز.
- تتم حماية جميع البيانات من خلال مفاتيح مُخزنة في بيئة تنفيذ موثوق بها (TEE).
- لا تصدر بيئة التنفيذ الموثوقة (TEE) المفاتيح إلا في حال اجتاز نظام التشغيل قيد المصادقة التشفير (التشغيل المتحقَّق منه).
- تعمل خدمة RoR التي تعمل على خوادم Google على تأمين بيانات CE من خلال تخزين سر يمكن استرداده لفترة محدودة فقط. وتتوفّر هذه الميزة على منظومة Android المتكاملة.
- يُستخدم مفتاح التشفير المحمي برقم التعريف الشخصي للمستخدم لفتح قفل الجهاز
وفك تشفير وحدة تخزين CE.
- عند جدولة إعادة التشغيل ليلاً، يطلب Android من المستخدم إدخال رقم التعريف الشخصي، ثم يحتسب كلمة مرور اصطناعية.
- بعد ذلك، يتم تشفير مقدِّم الخدمة مرتين: مرة باستخدام مفتاح
K_sمخزَّن في ذاكرة الوصول العشوائي، ومرة أخرى مع مفتاح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 لتحديث تحديث عبر الهواء (OTA) ومعدّل تسجيل البيانات (RoR) المستند إلى الخادم، والذي يضمن الوظائف الأساسية (مع إمكانية الاتصال بشبكة الجوّال) بعد إعادة التشغيل.
وتتم إعادة تشفير رقم التعريف الشخصي لشريحة SIM وتخزينه في كل مرة يفعّل فيها المستخدم هذا الرقم أو يثبته بنجاح أو يعدّله. يتم إلغاء رقم التعريف الشخصي لشريحة SIM في حالة حدوث أي مما يلي:
- تمت إزالة شريحة SIM أو إعادة ضبطها.
- عطِّل المستخدم رقم التعريف الشخصي.
- حدثت عملية إعادة تشغيل بدون تسجيل إذن الوصول.
لا يمكن استخدام رقم التعريف الشخصي لشريحة SIM المحفوظة إلا مرة واحدة بعد إعادة التشغيل التي تبدأ بـ RoR، ولمدّة زمنية قصيرة جدًا (20 ثانية) في حال تطابق تفاصيل شريحة SIM. وعند تخزين رقم التعريف الشخصي لشريحة SIM الخاصة به، لا يتم نقله من تطبيق "الاتصال الهاتفي" ولا يمكن استرداده بواسطة الوحدات الخارجية.
إرشادات التنفيذ
في Android 12، توفِّر دوال RoR المتعدّدة العملاء والمستندة إلى الخادم حِملًا أخفّ للشركاء عند إصدار التحديثات عبر الهواء. يمكن أن يتم إجراء التحديثات اللازمة أثناء فترات توقف الجهاز عن العمل، مثلاً خلال ساعات النوم المخصصة.
لضمان ألا تؤدي التحديثات عبر الهواء خلال هذه الفترات الزمنية إلى مقاطعة المستخدمين،
استخدِم الوضع الداكن للتخفيف من انبعاثات الضوء. لإجراء ذلك، اطلب من برنامج
تحميل الجهاز أن يبحث عن سبب السلسلة unattended. إذا كانت قيمة unattended هي true،
يُرجى وضع الجهاز في "الوضع الداكن". يُرجى العِلم أنّ كل مصنّع أصلي للجهاز يقع على عاتقه مسؤولية
التخفيف من انبعاثات الصوت والضوء.
إذا كنت بصدد الترقية إلى Android 12 أو إطلاق أجهزة تعمل بالإصدار 12 من نظام التشغيل Android، لن تحتاج إلى اتخاذ أي إجراء لتنفيذ وظائف RoR الجديدة.
هناك استدعاء واحد جديد في المسار المتعدد العملاء،
isPreparedForUnattendedUpdate، كما هو موضّح أدناه:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
لا تحتاج إلى تنفيذ ذلك، لأنّه تم إيقاف HAL نهائيًا اعتبارًا من Android 12.
مدير الاتصال الهاتفي
يستدعي برنامج OTA واجهة برمجة تطبيقات نظام TelephonyManager عند اقتراب موعد إعادة التشغيل في Android 12. تنقل واجهة برمجة التطبيقات هذه جميع رموز أرقام التعريف الشخصية المخزّنة مؤقتًا
من الحالة AVAILABLE إلى الحالة REBOOT_READY. تتم حماية واجهة برمجة تطبيقات نظام TelephonyManager من خلال إذن بيان 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()
تستخدم حِزم APK المميّزة واجهة برمجة التطبيقات لنظام TechnicalManager.
الاختبار
لاختبار واجهة برمجة التطبيقات الجديدة، نفِّذ الأمر التالي:
adb shell cmd phone unattended-reboot
لا يعمل هذا الأمر إلا عند تشغيل واجهة الأوامر كجذر (adb root).
Android 11 فقط
ينطبق باقي هذه الصفحة على الإصدار 11 من نظام Android.
منذ تموز (يوليو) 2020، تنقسم عمليات تنفيذ RoR HAL إلى فئتين:
- إذا كان جهاز المنظومة على الرقاقة (SoC) يتوافق مع ثبات ذاكرة الوصول العشوائي (RAM) على جميع عمليات إعادة التشغيل، يمكن للمصنّعين الأصليين للأجهزة استخدام التنفيذ التلقائي في AOSP (ضمان ذاكرة الوصول العشوائي التلقائية).
- إذا كانت معدّات الجهاز أو المنظومة على الرقاقة (SoC) تتوافق مع هيكل آمن للأجهزة (معالج أمان مساعد منفصل مزوّد بذاكرة وصول عشوائي وذاكرة القراءة فقط)، يجب أيضًا تنفيذ ما يلي:
- القدرة على اكتشاف إعادة تشغيل وحدة المعالجة المركزية الرئيسية.
- توفّر مصدر موقّت للأجهزة يظل على مدار عمليات إعادة التشغيل. وهذا يعني أنه يجب أن يكون الحصن قادرًا على اكتشاف إعادة التشغيل وانتهاء صلاحية المؤقت الذي تم ضبطه قبل إعادة التشغيل.
- إتاحة تخزين مفتاح محفوظ في ذاكرة الوصول العشوائي (RAM) أو ذاكرة التخزين المؤقت (ROM) للحصن على نحو لا يمكن استرداده من خلال الهجمات التي تتم بلا اتصال بالإنترنت. يجب عليه تخزين مفتاح RoR بطريقة تجعل من المستحيل على المداخلين أو المهاجمين استعادته.
ضمان ذاكرة الوصول العشوائي التلقائية
لدى AOSP تنفيذ خاص بـ RR HAL باستخدام ثبات ذاكرة الوصول العشوائي. ولكي ينجح ذلك، يجب أن يتأكّد المصنّعون الأصليون للأجهزة (OEM) من أنّ المنظومة على الرقاقة (SoC) تتوافق مع ثبات ذاكرة الوصول العشوائي خلال عمليات إعادة التشغيل. يتعذّر على بعض تقنيات المنظومة على رقاقة (SoC) الاحتفاظ بمحتوى ذاكرة الوصول العشوائي (RAM) أثناء إعادة التشغيل، لذلك ننصح المصنّعين الأصليين للأجهزة باستشارة شركاء المنظومة على الرقاقة (SoC) قبل تفعيل هذا المستوي الصحّي التلقائي. المرجع الأساسي لذلك في القسم التالي.
تدفق تحديث التحديث عبر الهواء باستخدام RoR
يجب أن يحصل تطبيق عميل "عبر الهواء" على الهاتف على
إذنَي
Manifest.permission.REBOOT
وManifest.permission.RECOVERY لطلب الطرق اللازمة
لتنفيذ تسجيل الأحداث الإقليمية. مع وجود هذا الشرط الأساسي، يتبع تدفق
التحديث الخطوات التالية:
- يعمل تطبيق عميل "عبر الهواء" على تنزيل التحديث.
- يتصل تطبيق عميل "عبر الهواء" بالحساب
RecoverySystem#prepareForUnattendedUpdate، ما يُطلب من المستخدم إدخال رقم التعريف الشخصي أو النقش أو كلمة المرور على شاشة القفل أثناء عملية فتح القفل في المرة التالية. - يفتح المستخدم قفل الجهاز على شاشة القفل، ويصبح الجهاز جاهزًا لتطبيق التحديث.
- يستدعي تطبيق العميل عبر الهواء (OTA) الاتصال بـ
RecoverySystem#rebootAndApply، ما يؤدي إلى إعادة التشغيل في الحال.
وفي نهاية هذا المسار، تتم إعادة تشغيل الجهاز وتُتيح آلية RoR مساحة تخزين بيانات الاعتماد المشفّرة (CE). بالنسبة إلى التطبيقات، يبدو أنّ عملية فتح القفل تتم بواسطة المستخدم العادي، لذلك يتلقّى التطبيق جميع الإشارات التي يتم إجراؤها عادةً، مثل ACTION_LOCKED_BOOT_COMPLETED وACTION_BOOT_COMPLETED.
تعديل إعدادات المنتجات
يجب أن يتضمّن المنتج الذي تم تصنيفه على أنّه متوافق مع ميزة RoR في الإصدار 11 من نظام التشغيل Android تنفيذًا لـ abuseEscrow 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 للضمان التلقائي لإعادة التشغيل
لاستخدام التطبيق التلقائي، يجب حجز 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