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

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

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

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

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

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

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

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

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

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

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

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

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

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