वेरिफ़ाइड बूट का इस्तेमाल करना

वेरिफ़ाइड बूट के लिए, बूट किए जा रहे 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 मोड पर वापस आ जाता है.