पुष्टि किए गए बूट के लिए, क्रिप्टोग्राफ़ी की मदद से, इस्तेमाल किए जाने से पहले, Android वर्शन के उस हिस्से के सभी कोड और डेटा की पुष्टि करना ज़रूरी है जिसे बूट किया जा रहा है. इसमें ये चीज़ें शामिल हैं: boot पार्टीशन से लोड किया गया कर्नेल, dtbo पार्टीशन से लोड किया गया डिवाइस ट्री, system पार्टीशन, vendor पार्टीशन वगैरह.
boot और dtbo जैसे छोटे से छोटे सेगमेंट, आम तौर पर सिर्फ़ एक बार पढ़े जाते हैं. इनकी पुष्टि करने के लिए, पूरे कॉन्टेंट को मेमोरी में लोड किया जाता है और फिर उसका हैश कैलकुलेट किया जाता है. इसके बाद, कैलकुलेट की गई हैश वैल्यू की तुलना,
अनुमानित हैश वैल्यू से की जाती है. अगर वैल्यू मेल नहीं खाती है, तो Android लोड नहीं होगा.
ज़्यादा जानकारी के लिए, बूट फ़्लो देखें.
बड़े पार्टीशन, जैसे कि फ़ाइल सिस्टम, मेमोरी में फ़िट नहीं होते. ऐसे में, हैश ट्री का इस्तेमाल किया जा सकता है. इसमें, मेमोरी में डेटा लोड होने के साथ-साथ पुष्टि की प्रोसेस भी लगातार चलती रहती है. इस मामले में, हैश ट्री के रूट हैश का हिसाब, रन टाइम के दौरान लगाया जाता है. साथ ही, इसकी तुलना रूट हैश की अनुमानित वैल्यू से की जाती है. Android में dm-verity driver शामिल होता है, ताकि बड़े पार्टीशन की पुष्टि की जा सके. अगर किसी समय पर कैलकुलेट किया गया रूट हैश, रूट हैश की अनुमानित वैल्यू से मेल नहीं खाता है, तो डेटा का इस्तेमाल नहीं किया जाता और Android में गड़बड़ी की स्थिति दिखती है. ज़्यादा जानकारी के लिए, dm-verity के डेटा में गड़बड़ी देखें.
आम तौर पर, एक्सपेक्टेड हैश, पुष्टि किए गए हर पार्टीशन के आखिर या शुरुआत में, किसी खास पार्टीशन में या दोनों में से किसी एक में सेव किए जाते हैं. अहम बात यह है कि इन हैश पर, ट्रस्ट रूट ने सीधे तौर पर या किसी दूसरे तरीके से हस्ताक्षर किया है. उदाहरण के लिए, एवीबी लागू करने के लिए, दोनों तरीकों का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, Android Verified Boot देखें.
रोलबैक से सुरक्षा
अपडेट करने की पूरी तरह से सुरक्षित प्रोसेस के बावजूद, ऐसा हो सकता है कि कभी न खत्म होने वाला Android कर्नेल एक्सप्लॉइट, Android का पुराना और ज़्यादा संवेदनशील वर्शन मैन्युअल तरीके से इंस्टॉल कर दे. इसके बाद, वह पुराने वर्शन में रीबूट हो जाए और फिर उस Android वर्शन का इस्तेमाल करके, कभी न खत्म होने वाला एक्सप्लॉइट इंस्टॉल कर दे. इसके बाद, हमलावर के पास डिवाइस का हमेशा के लिए मालिकाना हक हो जाता है और वह अपडेट बंद करने के साथ-साथ, कुछ भी कर सकता है.
इस तरह के हमलों से सुरक्षा पाने की सुविधा को रोलबैक सुरक्षा कहा जाता है. आम तौर पर, रोलबैक सुरक्षा की सुविधा को लागू करने के लिए, Android के सबसे नए वर्शन को रिकॉर्ड करने के लिए, बदलाव का पता चलने वाले स्टोरेज का इस्तेमाल किया जाता है. साथ ही, अगर Android का वर्शन रिकॉर्ड किए गए वर्शन से पुराना है, तो उसे बूट करने से मना कर दिया जाता है. आम तौर पर, वर्शन को हर पार्टीशन के हिसाब से ट्रैक किया जाता है.
AVB, रोलबैक सुरक्षा को कैसे मैनेज करता है, इस बारे में ज़्यादा जानने के लिए AVB का README देखें.
पुष्टि करने से जुड़ी गड़बड़ियों को मैनेज करना
पुष्टि करने की प्रोसेस, बूट के समय या रन टाइम पर पूरी नहीं हो सकती. उदाहरण के लिए, अगर boot पार्टीशन पर कैलकुलेट किया गया हैश, उम्मीद के मुताबिक हैश से मेल नहीं खाता है या dm-verity को system पार्टीशन पर पुष्टि करने से जुड़ी गड़बड़ी का पता चलता है. अगर बूट के समय पुष्टि नहीं हो पाती है, तो डिवाइस बूट नहीं हो पाएगा. साथ ही, असली उपयोगकर्ता को डिवाइस को वापस पाने के लिए कुछ चरणों को पूरा करना होगा.
अगर रन-टाइम पर पुष्टि नहीं हो पाती है, तो फ़्लो थोड़ा मुश्किल हो जाता है. अगर डिवाइस में dm-verity का इस्तेमाल किया जाता है, तो उसे restart मोड में कॉन्फ़िगर किया जाना चाहिए. restart मोड में, अगर पुष्टि करने में कोई गड़बड़ी होती है, तो डिवाइस को तुरंत रीस्टार्ट कर दिया जाता है. साथ ही, इसकी वजह बताने के लिए एक खास फ़्लैग सेट किया जाता है. बूट लोड करने वाले प्रोग्राम को इस फ़्लैग का पता चलना चाहिए और dm-verity को I/O गड़बड़ी (eio) मोड का इस्तेमाल करने के लिए स्विच करना चाहिए. साथ ही, यह मोड तब तक चालू रहना चाहिए, जब तक नया अपडेट इंस्टॉल नहीं हो जाता.
eio मोड में बूट करने पर, डिवाइस पर गड़बड़ी वाली स्क्रीन दिखती है. इससे उपयोगकर्ता को पता चलता है कि फ़ाइल में गड़बड़ी का पता चला है और हो सकता है कि डिवाइस ठीक से काम न करे. स्क्रीन तब तक दिखती है, जब तक उपयोगकर्ता उसे खारिज नहीं कर देता. eio मोड में, पुष्टि करने से जुड़ी कोई गड़बड़ी होने पर, dm-verity ड्राइवर डिवाइस को रीस्टार्ट नहीं करेगा. इसके बजाय, EIO गड़बड़ी का मैसेज दिखेगा और ऐप्लिकेशन को इस गड़बड़ी को ठीक करना होगा.
इसका मकसद यह है कि सिस्टम अपडेटर चल सके, ताकि बिना गड़बड़ी वाले नए ओएस को इंस्टॉल किया जा सके या उपयोगकर्ता अपने ज़्यादा से ज़्यादा डेटा को डिवाइस से हटा सके. नया ओएस इंस्टॉल होने के बाद, बूट लोडर को नए ओएस का पता चलता है और वह restart मोड पर वापस स्विच हो जाता है.