डीएम-वेरिटी लागू करना

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

संभावित रूप से हानिकारक अनुप्रयोग (पीएचए) रूट विशेषाधिकारों के साथ पहचान कार्यक्रमों से छिप सकते हैं और अन्यथा स्वयं को मुखौटा कर सकते हैं। रूटिंग सॉफ़्टवेयर ऐसा कर सकता है क्योंकि यह अक्सर डिटेक्टरों की तुलना में अधिक विशेषाधिकार प्राप्त होता है, जिससे सॉफ़्टवेयर का पता लगाने वाले कार्यक्रमों में "झूठ" हो जाता है।

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

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

डीएम-सत्य-हैश-टेबल

चित्र 1. डीएम-सत्य हैश तालिका

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

संचालन

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

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

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

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

यदि सत्यापन विफल हो जाता है, तो डिवाइस एक I/O त्रुटि उत्पन्न करता है जो दर्शाता है कि ब्लॉक को पढ़ा नहीं जा सकता है। ऐसा प्रतीत होगा जैसे फ़ाइल सिस्टम दूषित हो गया है, जैसा कि अपेक्षित है।

एप्लिकेशन परिणामी डेटा के बिना आगे बढ़ना चुन सकते हैं, जैसे कि जब वे परिणाम एप्लिकेशन के प्राथमिक कार्य के लिए आवश्यक नहीं होते हैं। हालाँकि, यदि एप्लिकेशन डेटा के बिना जारी नहीं रह सकता है, तो यह विफल हो जाएगा।

आगे त्रुटि सुधार

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

कार्यान्वयन

सारांश

  1. एक ext4 सिस्टम छवि उत्पन्न करें।
  2. उस छवि के लिए हैश ट्री जेनरेट करें
  3. उस हैश ट्री के लिए dm-verity टेबल बनाएं
  4. तालिका हस्ताक्षर बनाने के लिए उस dm-verity तालिका पर हस्ताक्षर करें।
  5. तालिका हस्ताक्षर और dm-verity तालिका को सत्यता मेटाडेटा में बंडल करें
  6. सिस्टम छवि, सत्यता मेटाडेटा और हैश ट्री को संयोजित करें।

हैश ट्री और dm-verity तालिका के विस्तृत विवरण के लिएक्रोमियम प्रोजेक्ट्स - सत्यापित बूट देखें।

हैश ट्री उत्पन्न करना

जैसा कि परिचय में वर्णित है, हैश ट्री dm-verity का अभिन्न अंग है। क्रिप्टसेटअप टूल आपके लिए हैश ट्री जेनरेट करेगा। वैकल्पिक रूप से, एक संगत को यहां परिभाषित किया गया है:

<your block device name> <your block device name> <block size> <block size> <image size in blocks> <image size in blocks + 8> <root hash> <salt>

हैश बनाने के लिए, सिस्टम छवि को परत 0 पर 4k ब्लॉक में विभाजित किया जाता है, प्रत्येक को एक SHA256 हैश सौंपा जाता है। परत 1 केवल उन SHA256 हैश को 4k ब्लॉक में जोड़कर बनाई गई है, जिसके परिणामस्वरूप बहुत छोटी छवि होती है। परत 2 समान रूप से बनाई गई है, परत 1 के SHA256 हैश के साथ।

यह तब तक किया जाता है जब तक कि पिछली परत के SHA256 हैश एक ही ब्लॉक में फिट नहीं हो जाते। जब उस ब्लॉक का SHA256 मिलता है, तो आपके पास पेड़ का रूट हैश होता है।

हैश ट्री का आकार (और संबंधित डिस्क स्थान उपयोग) सत्यापित विभाजन के आकार के साथ बदलता रहता है। व्यवहार में, हैश ट्री का आकार छोटा होता है, अक्सर 30 एमबी से कम।

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

हैश ट्री जेनरेट करने के लिए, लेयर 2 हैश को लेयर 1 के लिए, लेयर 3 के हैश को लेयर 2 के हैश पर संयोजित करें, और इसी तरह। यह सब डिस्क पर लिखें। ध्यान दें कि यह रूट हैश की परत 0 का संदर्भ नहीं देता है।

संक्षेप में, हैश ट्री के निर्माण के लिए सामान्य एल्गोरिथ्म इस प्रकार है:

  1. एक यादृच्छिक नमक (हेक्साडेसिमल एन्कोडिंग) चुनें।
  2. अपनी सिस्टम छवि को 4k ब्लॉकों में खोलें।
  3. प्रत्येक ब्लॉक के लिए, उसका (नमकीन) SHA256 हैश प्राप्त करें।
  4. एक स्तर बनाने के लिए इन हैश को संयोजित करें
  5. स्तर को 0s से 4k ब्लॉक सीमा तक पैड करें।
  6. स्तर को अपने हैश ट्री से जोड़ें।
  7. जब तक आपके पास केवल एक हैश न हो, तब तक अगले स्तर के स्रोत के रूप में पिछले स्तर का उपयोग करके चरण 2-6 दोहराएं।

इसका परिणाम एक सिंगल हैश है, जो आपका रूट हैश है। यह और आपके नमक का उपयोग आपकी dm-verity मैपिंग टेबल के निर्माण के दौरान किया जाता है।

डीएम-वेरिटी मैपिंग टेबल बनाना

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

सत्य लक्ष्य मानचित्रण तालिका फ़ील्ड के विस्तृत विवरण के लिए क्रिप्टसेटअप देखें।

डीएम-सत्यापन तालिका पर हस्ताक्षर करना

तालिका हस्ताक्षर बनाने के लिए dm-verity तालिका पर हस्ताक्षर करें। विभाजन की पुष्टि करते समय, तालिका हस्ताक्षर को पहले मान्य किया जाता है। यह आपकी बूट छवि पर एक निश्चित स्थान पर एक कुंजी के विरुद्ध किया जाता है। एक निश्चित स्थान पर उपकरणों पर स्वत: समावेशन के लिए निर्माताओं के बिल्ड सिस्टम में चाबियों को आम तौर पर शामिल किया जाता है।

इस हस्ताक्षर और कुंजी संयोजन के साथ विभाजन को सत्यापित करने के लिए:

  1. एक RSA-2048 कुंजी को libmincrypt-संगत स्वरूप में /boot विभाजन में /verity_key पर जोड़ें। हैश ट्री को सत्यापित करने के लिए उपयोग की जाने वाली कुंजी के स्थान की पहचान करें।
  2. प्रासंगिक प्रविष्टि के लिए fstab में, fs_mgr झंडे में verify जोड़ें।

तालिका हस्ताक्षर को मेटाडेटा में बंडल करना

तालिका हस्ताक्षर और dm-verity तालिका को सत्यता मेटाडेटा में बंडल करें। मेटाडेटा का संपूर्ण खंड संस्करणबद्ध है, इसलिए इसे बढ़ाया जा सकता है, जैसे कि दूसरे प्रकार के हस्ताक्षर जोड़ने या कुछ क्रम बदलने के लिए।

एक विवेक जांच के रूप में, तालिका मेटाडेटा के प्रत्येक सेट के साथ एक जादुई संख्या जुड़ी होती है जो तालिका की पहचान करने में मदद करती है। चूंकि लंबाई को ext4 सिस्टम इमेज हेडर में शामिल किया गया है, यह डेटा की सामग्री को जाने बिना मेटाडेटा को खोजने का एक तरीका प्रदान करता है।

यह सुनिश्चित करता है कि आपने एक असत्यापित विभाजन को सत्यापित करने के लिए नहीं चुना है। यदि ऐसा है, तो इस जादुई संख्या की अनुपस्थिति सत्यापन प्रक्रिया को रोक देगी। यह संख्या मिलती जुलती है:
0xb001b001

हेक्स में बाइट मान हैं:

  • पहला बाइट = b0
  • दूसरा बाइट = 01
  • तीसरा बाइट = b0
  • चौथा बाइट = 01

निम्नलिखित आरेख सत्यता मेटाडेटा के टूटने को दर्शाता है:

<magic number>|<version>|<signature>|<table length>|<table>|<padding>
\-------------------------------------------------------------------/
\----------------------------------------------------------/   |
                            |                                  |
                            |                                 32K
                       block content

और यह तालिका उन मेटाडेटा क्षेत्रों का वर्णन करती है।

तालिका 1. सत्यता मेटाडेटा फ़ील्ड

खेत उद्देश्य आकार मूल्य
जादुई संख्या fs_mgr द्वारा एक विवेक जांच के रूप में उपयोग किया जाता है 4 निवाले 0xb001b001
संस्करण मेटाडेटा ब्लॉक के संस्करण के लिए उपयोग किया जाता है 4 निवाले वर्तमान में 0
हस्ताक्षर PKCS1.5 गद्देदार रूप में तालिका के हस्ताक्षर 256 बाइट्स
टेबल की लंबाई dm-verity तालिका की लंबाई बाइट्स में 4 निवाले
मेज़ पहले वर्णित डीएम-सत्यापन तालिका टेबल की लंबाई बाइट्स
गद्दी यह संरचना 0-गद्देदार से 32k लंबाई में है 0

डीएम-सत्यता का अनुकूलन

dm-verity से सर्वश्रेष्ठ प्रदर्शन प्राप्त करने के लिए, आपको यह करना चाहिए:

  • कर्नेल में, ARMv7 के लिए NEON SHA-2 और ARMv8 के लिए SHA-2 एक्सटेंशन चालू करें।
  • अपने डिवाइस के लिए सर्वोत्तम कॉन्फ़िगरेशन खोजने के लिए विभिन्न रीड-फ़ॉरवर्ड और प्रीफ़ेच_क्लस्टर सेटिंग्स के साथ प्रयोग करें।