बूट का सत्यापन

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

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

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

अपेक्षित हैश आमतौर पर या तो एक समर्पित विभाजन में या प्रत्येक सत्यापित विभाजन के अंत या शुरुआत में संग्रहीत किया जाता है, या दोनों। विश्वसनीय रूप से, ट्रस्ट के मूल द्वारा इन हैश पर हस्ताक्षर किए जाते हैं (या तो प्रत्यक्ष या अप्रत्यक्ष रूप से)। एक उदाहरण के रूप में, AVB कार्यान्वयन दोनों दृष्टिकोणों का समर्थन करता है, विवरण के लिए Android सत्यापित बूट देखें।

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

यहां तक ​​कि पूरी तरह से सुरक्षित अपडेट प्रक्रिया के साथ, गैर-लगातार एंड्रॉइड कर्नेल शोषण के लिए मैन्युअल रूप से एंड्रॉइड के पुराने, अधिक कमजोर संस्करण को स्थापित करना, कमजोर संस्करण में रिबूट करना और फिर उस एंड्रॉइड संस्करण का उपयोग लगातार शोषण को स्थापित करना संभव है। वहां से हमलावर स्थायी रूप से डिवाइस का मालिक है और अपडेट को अक्षम करने सहित कुछ भी कर सकता है।

हमलों के इस वर्ग के खिलाफ संरक्षण को रोलबैक संरक्षण कहा जाता है। रोलबैक सुरक्षा आमतौर पर एंड्रॉइड के सबसे हाल के संस्करण को रिकॉर्ड करने के लिए टैम्पर-एविडेंस स्टोरेज का उपयोग करके कार्यान्वित की जाती है और एंड्रॉइड को बूट करने से इनकार करते हैं यदि यह रिकॉर्ड किए गए संस्करण से कम है। संस्करणों को आमतौर पर प्रति-विभाजन के आधार पर ट्रैक किया जाता है।

AVB रोलबैक सुरक्षा कैसे संभालती है, इस बारे में अधिक जानकारी के लिए, AVB README देखें

सत्यापन त्रुटियों को संभालना

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

यदि सत्यापन रन-टाइम में विफल रहता है, तो प्रवाह थोड़ा अधिक जटिल है। यदि डिवाइस dm-verity का उपयोग करता है, तो इसे restart मोड में कॉन्फ़िगर किया जाना चाहिए। restart मोड में, यदि सत्यापन त्रुटि का सामना करना पड़ता है, तो कारण को इंगित करने के लिए डिवाइस को तुरंत एक विशिष्ट ध्वज सेट के साथ पुनरारंभ किया जाता है। बूट लोडर को इस ध्वज को देखना चाहिए और I / O त्रुटि ( eio ) मोड का उपयोग करने के लिए dm-verity पर स्विच करना चाहिए और एक नया अपडेट स्थापित होने तक इस मोड में रहना चाहिए।

eio मोड में बूट करते समय, डिवाइस उपयोगकर्ता को यह बताते हुए एक त्रुटि स्क्रीन दिखाता है कि भ्रष्टाचार का पता चला है और डिवाइस सही ढंग से काम नहीं कर सकता है। उपयोगकर्ता द्वारा खारिज किए जाने तक स्क्रीन दिखाता है। eio मोड में dm-verity ड्राइवर डिवाइस को रिस्टार्ट नहीं करेगा यदि कोई सत्यापन त्रुटि सामने आई है, इसके बजाय एक EIO त्रुटि वापस आ गई है और एप्लिकेशन को त्रुटि से निपटने की आवश्यकता है।

आशय यह है कि या तो सिस्टम अपडेटर चलेगा (इसलिए भ्रष्टाचार त्रुटियों के बिना एक नया ओएस स्थापित किया जा सकता है) या उपयोगकर्ता डिवाइस से जितना संभव हो उतना अपने डेटा को प्राप्त कर सकता है। एक बार नया ओएस स्थापित हो जाने के बाद, बूट लोडर नए स्थापित ओएस को नोटिस करता है और restart मोड पर वापस आ जाता है।