Android Pie के साथ लॉन्च होने वाले फ़ोन पर Android Oreo की रोलबैक सुरक्षा आवश्यक है

एंड्रॉइड पाई (एंड्रॉइड 9) आज ही लाइव हुआ Google Pixel, Google Pixel 2 और के लिए फिर भी आवश्यक फ़ोन. हम साक्षात्कारों (Google Pixel 3) के रिलीज़ के बारे में जितना सीख सकते हैं सीख रहे हैं केवल जेस्चर नेविगेशन होगा!), द AOSP कोड ड्रॉप, और अंत में संगतता परिभाषा दस्तावेज़ (सीडीडी)। हमने एक के बारे में पोस्ट किया "हैवीवेट" ऐप्स के लिए नई सुविधा आज पहले, लेकिन अब हमने पाया है कि Google ने Android Oreo में पेश किए गए एक फीचर पर अपने शब्दों को बदल दिया है: रोलबैक सुरक्षा. यह सुविधा किसके द्वारा संभव हुई है Android सत्यापित बूट 2.0 (जिसे केवल सत्यापित बूट के रूप में भी जाना जाता है), हालाँकि, OEM को Oreo रिलीज़ में AVB 2.0 को लागू करने की आवश्यकता नहीं थी। अब, Google अनिवार्य कर रहा है कि एंड्रॉइड पाई के साथ लॉन्च होने वाले सभी डिवाइस सत्यापित बूट और विस्तार से, रोलबैक सुरक्षा का समर्थन करें।

Android Oreo में रोलबैक सुरक्षा

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

यह सुविधा Google Pixel 2, रेज़र फोन और वनप्लस 6 जैसे उपकरणों पर मौजूद है, लेकिन सैमसंग गैलेक्सी S9 जैसे कई अन्य उपकरणों पर मौजूद नहीं है (हालाँकि सैमसंग अपना स्वयं का रूप पेश करता है) नॉक्स में रोलबैक सुरक्षा.) अब, Google एंड्रॉइड पाई के साथ लॉन्च होने वाले किसी भी डिवाइस के लिए इस सुविधा को अनिवार्य बना रहा है।

एंड्रॉइड पाई में सत्यापित बूट

संगतता परिभाषा दस्तावेज़ में "डिवाइस इंटीग्रिटी" अनुभाग में अद्यतन शब्दों के अनुसार, एंड्रॉइड 9 के साथ लॉन्च होने वाले डिवाइस को सत्यापित बूट का समर्थन करना चाहिए।

9.10. डिवाइस की अखंडता

निम्नलिखित आवश्यकताएँ सुनिश्चित करती हैं कि डिवाइस की अखंडता की स्थिति में पारदर्शिता है। डिवाइस कार्यान्वयन:

• [सी-0-1] सिस्टम एपीआई विधि PersistentDataBlockManager.getFlashLockState() के माध्यम से सही ढंग से रिपोर्ट करना होगा कि क्या उनकी बूटलोडर स्थिति सिस्टम छवि को फ्लैश करने की अनुमति देती है। FLASH_LOCK_UNKNOWN स्थिति एंड्रॉइड के पुराने संस्करण से अपग्रेड करने वाले डिवाइस कार्यान्वयन के लिए आरक्षित है जहां यह नई सिस्टम एपीआई विधि मौजूद नहीं थी।
• [सी-0-2] डिवाइस अखंडता के लिए सत्यापित बूट का समर्थन करना चाहिए।

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

...

• [सी-1-10] एंड्रॉइड द्वारा उपयोग किए जाने वाले विभाजनों के लिए रोलबैक सुरक्षा लागू करनी होगी (उदाहरण के लिए बूट, सिस्टम विभाजन) और न्यूनतम स्वीकार्य ओएस निर्धारित करने के लिए उपयोग किए जाने वाले मेटाडेटा को संग्रहीत करने के लिए छेड़छाड़-स्पष्ट भंडारण का उपयोग करें संस्करण।
• लगातार फर्मवेयर (जैसे मॉडेम, कैमरा) वाले किसी भी घटक के लिए रोलबैक सुरक्षा लागू करनी चाहिए न्यूनतम स्वीकार्य निर्धारण के लिए उपयोग किए जाने वाले मेटाडेटा को संग्रहीत करने के लिए छेड़छाड़-स्पष्ट भंडारण का उपयोग करना चाहिए संस्करण।

जैसा कि आप बुलेट बिंदुओं के अंतिम दो सेट में देख सकते हैं, ध्यान देने योग्य एक चेतावनी है। एंड्रॉइड द्वारा उपयोग किए जाने वाले विभाजन (बूट, सिस्टम, विक्रेता, आदि) के लिए रोलबैक सुरक्षा आवश्यक है, लेकिन लगातार फर्मवेयर (मॉडेम, कैमरा, आदि) वाले विभाजन के लिए नहीं। विभाजनों का पूर्व सेट वह है जहाँ अधिकांश सुरक्षा कमजोरियाँ खोजी जाती हैं और उन्हें ठीक किया जाता है, इसलिए यह देखना अच्छा है कि इन विभाजनों की सुरक्षा करना अनिवार्य है। हालाँकि, ऐसे कारनामे हुए हैं जो लगातार फर्मवेयर के साथ विभाजन को भी लक्षित करते हैं, इसलिए हम अनिश्चित हैं कि Google उन पर रोलबैक सुरक्षा को अनिवार्य क्यों नहीं कर रहा है।

XDA के वरिष्ठ सदस्य एनपीजॉन्सनLineageOS टीम के एक सदस्य का अनुमान है कि लगातार फर्मवेयर वाले विभाजनों पर रोलबैक सुरक्षा की आवश्यकता होगी सेकेंडरी बूटलोडर (एसबीएल) और एक्स्टेंसिबल बूटलोडर (एक्सबीएल) टाई-इन की आवश्यकता होती है क्योंकि ये विभाजन बूट में पहले माउंट किए गए हैं प्रक्रिया। छोटे ओईएम के लिए अनुकूलित मॉडेम और अन्य लगातार विभाजनों से मेल खाने के लिए अनुकूलित एक्सबीएल लागू करना महंगा होगा, इसलिए शायद Google डिवाइस निर्माताओं के लिए सीडीडी में नवीनतम आवश्यकताओं को पूरा करना आसान बनाने के लिए इसे एक आवश्यकता नहीं बना रहा है।

कैसे जांचें कि आपका फ़ोन AVB 2.0 को सपोर्ट करता है या नहीं

दो ADB शेल कमांड हैं जिनका उपयोग आप यह जांचने के लिए कर सकते हैं कि आपका फ़ोन AVB 2.0 को सपोर्ट करता है या नहीं।

adb shell
dumpsys package | grep "verified_boot"

या

adb shell
getprop | grep "avb"

यदि पहले कमांड का आउटपुट "android.software.verified_boot" है तो AVB 2.0 समर्थित है। यदि दूसरे कमांड का आउटपुट "[ro.boot.avb_version]" और "[ro.boot.vbmeta.avb_version]" दिखाता है और प्रत्येक के लिए एक संस्करण संख्या सूचीबद्ध करता है, तो यह समर्थित है।

सत्यापित बूट और कस्टम विकास

एंड्रॉइड सत्यापित बूट वास्तव में अधिकांश कस्टम ROM उपयोगकर्ताओं को प्रभावित नहीं करता है, हालांकि यह सुरक्षा की एक अतिरिक्त परत जोड़ता है जिसे आपको कुछ मामलों में काम करना पड़ता है। उदाहरण के लिए, जेनेरिक सिस्टम छवि को चमकाना AVB को अक्षम करने की आवश्यकता है. वनप्लस 6 पर विक्रेता जैसे कुछ विभाजनों को संशोधित करने के लिए AVB को भी अक्षम करने की आवश्यकता है, जैसा कि मैंने हाल ही में सीखा है. के अनुसार एनपीजॉन्सन, उचित रूप से कार्यान्वित AVB 2.0 कस्टम बूट छवियों के लिए लॉक किए गए बूटलोडर के साथ काम करना संभव बनाता है। हम देखेंगे कि एंड्रॉइड पाई के साथ शिपिंग करने वाले उपकरणों पर एवीबी 2.0 का समावेश परिदृश्य को कैसे प्रभावित करता है, लेकिन हमें उम्मीद है कि इसके परिणामस्वरूप ऐसी स्थितियां नहीं होंगी हाल ही में ईंटों से पिटाई का डर Xiaomi Redmi Note 5 Pro समुदाय में। अनिवार्य AVB 2.0 Google के लिए एक और तरीका है एंड्रॉइड प्लेटफ़ॉर्म सुरक्षा में सुधार करें, लेकिन हमारे विचार में सबसे बड़ा परिवर्तन है नियमित सुरक्षा पैच को अनिवार्य करने के लिए ओईएम समझौतों पर फिर से काम करना.