يتطلب التمهيد الذي تم التحقق منه التحقق بشكل مشفر من جميع التعليمات البرمجية والبيانات القابلة للتنفيذ والتي تعد جزءًا من إصدار Android الذي يتم تشغيله قبل استخدامه. يتضمن ذلك النواة (المحملة من قسم boot ) ، وشجرة الجهاز (المحملة من قسم dtbo ) ، وقسم system ، وقسم vendor ، وما إلى ذلك.
عادةً ما يتم التحقق من الأقسام الصغيرة ، مثل boot و dtbo ، التي تتم قراءتها مرة واحدة فقط عن طريق تحميل المحتويات بالكامل في الذاكرة ثم حساب التجزئة الخاصة بها. ثم تتم مقارنة قيمة التجزئة المحسوبة هذه بقيمة التجزئة المتوقعة . إذا لم تتطابق القيمة ، فلن يتم تحميل Android. لمزيد من التفاصيل ، راجع Boot Flow .
قد تستخدم الأقسام الأكبر حجمًا التي لا تتناسب مع الذاكرة (مثل أنظمة الملفات) شجرة تجزئة حيث يكون التحقق عملية مستمرة تحدث أثناء تحميل البيانات في الذاكرة. في هذه الحالة ، يتم حساب تجزئة الجذر لشجرة التجزئة أثناء وقت التشغيل ويتم فحصها مقابل قيمة تجزئة الجذر المتوقعة . يشتمل Android على برنامج تشغيل dm-verity للتحقق من الأقسام الأكبر. إذا لم تتطابق تجزئة الجذر المحسوبة في وقت ما مع قيمة تجزئة الجذر المتوقعة ، فلن يتم استخدام البيانات ويدخل Android في حالة خطأ. لمزيد من التفاصيل ، انظر dm-verity الفساد .
عادةً ما يتم تخزين التجزئة المتوقعة إما في نهاية أو بداية كل قسم تم التحقق منه ، في قسم مخصص ، أو كليهما. بشكل حاسم ، يتم توقيع هذه التجزئة (إما بشكل مباشر أو غير مباشر) من خلال جذر الثقة. على سبيل المثال ، يدعم تطبيق AVB كلا الأسلوبين ، راجع Android Verified Boot للحصول على التفاصيل.
حماية التراجع
حتى مع عملية التحديث الآمنة تمامًا ، من الممكن أن يقوم استغلال Android kernel غير المستمر بتثبيت إصدار أقدم وأكثر ضعفًا من Android يدويًا ، وإعادة التشغيل في الإصدار الضعيف ، ثم استخدام إصدار Android هذا لتثبيت استغلال مستمر. من هناك ، يمتلك المهاجم الجهاز بشكل دائم ويمكنه فعل أي شيء ، بما في ذلك تعطيل التحديثات.
تسمى الحماية ضد هذه الفئة من الهجمات الحماية من التراجع. عادةً ما يتم تنفيذ الحماية ضد التراجع عن طريق استخدام تخزين واضح للعبث لتسجيل أحدث إصدار من Android ورفض تشغيل Android إذا كان أقل من الإصدار المسجل. يتم عادةً تعقب الإصدارات على أساس كل قسم.
لمزيد من التفاصيل حول كيفية معالجة AVB للحماية من التراجع ، راجع AVB README .
معالجة أخطاء التحقق
يمكن أن تفشل عملية التحقق إما في وقت التمهيد (على سبيل المثال ، إذا كانت التجزئة المحسوبة على قسم boot لا تتطابق مع التجزئة المتوقعة) أو في وقت التشغيل (على سبيل المثال ، إذا واجه dm-verity خطأ في التحقق على قسم system ). إذا فشل التحقق في وقت التمهيد ، فلن يتمكن الجهاز من التمهيد ويحتاج المستخدم النهائي إلى اتباع الخطوات لاستعادة الجهاز.
إذا فشل التحقق في وقت التشغيل ، فسيكون التدفق أكثر تعقيدًا بعض الشيء. إذا كان الجهاز يستخدم dm-verity ، فيجب تكوينه في وضع restart . في وضع restart ، إذا تمت مصادفة خطأ في التحقق ، تتم إعادة تشغيل الجهاز فورًا بعلامة محددة للإشارة إلى السبب. يجب أن يلاحظ مُحمل الإقلاع هذه العلامة ويقوم بتبديل dm-verity لاستخدام وضع I / O Error ( eio ) والبقاء في هذا الوضع حتى يتم تثبيت تحديث جديد.
عند التشغيل في وضع eio ، يعرض الجهاز شاشة خطأ تخبر المستخدم أنه تم اكتشاف تلف وأن الجهاز قد لا يعمل بشكل صحيح. تظهر الشاشة حتى يتجاهلها المستخدم. في وضع eio ، لن يقوم برنامج تشغيل dm-verity بإعادة تشغيل الجهاز في حالة مواجهة خطأ في التحقق ، وبدلاً من ذلك يتم إرجاع خطأ EIO ويحتاج التطبيق إلى التعامل مع الخطأ.
القصد من ذلك هو إما تشغيل مُحدِّث النظام (بحيث يمكن تثبيت نظام تشغيل جديد بدون أخطاء تلف) أو يمكن للمستخدم الحصول على أكبر قدر ممكن من بياناته من الجهاز. بمجرد تثبيت نظام التشغيل الجديد ، يلاحظ محمل الإقلاع نظام التشغيل المثبت حديثًا ويعود إلى وضع restart .