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

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

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

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

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

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

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

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

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

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

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

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

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

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