वेरिफ़ाइड बूट

वेरिफ़ाइड बूट की सुविधा के तहत, बूट किए जा रहे Android वर्शन के सभी एक्ज़ीक्यूटेबल कोड और डेटा की क्रिप्टोग्राफ़िक तरीके से पुष्टि करना ज़रूरी है. ऐसा तब किया जाता है, जब तक कि उनका इस्तेमाल न किया जाए. इसमें कर्नल (boot पार्टिशन से लोड किया गया), डिवाइस ट्री (dtbo पार्टिशन से लोड किया गया), system पार्टिशन, vendor पार्टिशन वगैरह शामिल हैं.

boot और dtbo जैसे छोटे पार्टीशन को सिर्फ़ एक बार पढ़ा जाता है. इनकी पुष्टि आम तौर पर, पूरे कॉन्टेंट को मेमोरी में लोड करके और फिर उसके हैश की गिनती करके की जाती है. इसके बाद, कैलकुलेट की गई हैश वैल्यू की तुलना, अनुमानित हैश वैल्यू से की जाती है. अगर वैल्यू मेल नहीं खाती है, तो Android लोड नहीं होगा. ज़्यादा जानकारी के लिए, बूट फ़्लो देखें.

बड़े पार्टीशन, मेमोरी में फ़िट नहीं होते. जैसे, फ़ाइल सिस्टम. ये हैश ट्री का इस्तेमाल कर सकते हैं. इसमें पुष्टि की प्रक्रिया लगातार चलती रहती है. ऐसा तब होता है, जब डेटा को मेमोरी में लोड किया जाता है. इस मामले में, हैश ट्री के रूट हैश की गणना रन टाइम के दौरान की जाती है. साथ ही, इसकी तुलना अनुमानित रूट हैश वैल्यू से की जाती है. Android में, बड़े पार्टीशन की पुष्टि करने के लिए dm-verity driver शामिल होता है. अगर किसी समय कैलकुलेट किया गया रूट हैश, अनुमानित रूट हैश वैल्यू से मेल नहीं खाता है, तो डेटा का इस्तेमाल नहीं किया जाता है. साथ ही, Android में गड़बड़ी की स्थिति आ जाती है. ज़्यादा जानकारी के लिए, dm-verity corruption देखें.

अनुमानित हैश को आम तौर पर, पुष्टि किए गए हर पार्टीशन के आखिर या शुरुआत में, किसी खास पार्टीशन में या दोनों में सेव किया जाता है. खास तौर पर, इन हैश पर सीधे तौर पर या किसी अन्य तरीके से, रूट ऑफ़ ट्रस्ट के हस्ताक्षर होते हैं. उदाहरण के लिए, AVB लागू करने की सुविधा में दोनों तरीकों का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, Android वेरिफ़ाइड बूट देखें.

रोलबैक सुरक्षा

अपडेट करने की प्रोसेस पूरी तरह से सुरक्षित होने के बावजूद, ऐसा हो सकता है कि Android कर्नल का कोई ऐसा एक्सप्लॉइट मैन्युअल तरीके से Android का पुराना और ज़्यादा जोखिम वाला वर्शन इंस्टॉल कर दे जो लगातार बना रहता है. इसके बाद, वह जोखिम वाले वर्शन में रीबूट हो जाता है. इसके बाद, वह 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 मोड पर वापस आ जाता है.