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

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

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

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

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