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