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

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

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

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

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

पहली इमेज. डीएम-वेरिटी हैश टेबल

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

कार्रवाई

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

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

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

इसके बजाय, dm-verity हर ब्लॉक की अलग-अलग पुष्टि करता है. ऐसा सिर्फ़ तब किया जाता है, जब हर ब्लॉक को ऐक्सेस किया जाता है. मेमोरी में पढ़े जाने पर, ब्लॉक साथ-साथ हैश किया जाता है. हैश है फिर पेड़ की पुष्टि की. ब्लॉक पढ़ना बहुत महंगा है ऑपरेशन है, तो इस ब्लॉक-लेवल की पुष्टि की वजह से शुरू होने वाला इंतज़ार का समय तुलनात्मक रूप से नाममात्र.

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

ऐप्लिकेशन, नतीजों के डेटा के बिना भी काम कर सकते हैं. जैसे, जब उन नतीजों की ज़रूरत ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए न हो. हालांकि, अगर डेटा के बिना ऐप्लिकेशन आगे नहीं बढ़ सकता, तो यह काम नहीं करेगा.

फ़ॉरवर्ड करने से जुड़ी गड़बड़ी में सुधार

Android 7.0 और इसके बाद के वर्शन में, फ़ॉरवर्ड गड़बड़ी सुधार (एफ़ईसी) की सुविधा के साथ dm-verity को बेहतर बनाया गया है. एओएसपी को लागू करने की शुरुआत Reed-Solomon की गड़बड़ी को ठीक करने वाला कोड और स्पेस का ओवरहेड कम करने और उसे बढ़ाने के लिए इंटरलीविंग नाम की तकनीक को इंटरलीविंग कहते हैं वापस पाया जा सकता है. एफ़ईसी के बारे में ज़्यादा जानकारी के लिए, गड़बड़ी ठीक करने की सुविधा के साथ, 'सही तरीके से बूट हुआ' सुविधा को सख्ती से लागू करना देखें.

लागू करना

खास जानकारी

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

The Chromium Projects - वेरिफ़ाइड बूट की जानकारी देखें का इस्तेमाल करें.

हैश ट्री जनरेट करना

जैसा कि शुरुआती जानकारी में बताया गया है, हैश ट्री dm-verity का ज़रूरी हिस्सा है. cryptsetup टूल आपके लिए हैश ट्री जनरेट करता है. इसके अलावा, यहां एक कंपेटिबल प्रॉपर्टी के बारे में बताया गया है:

<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 हैश असाइन किया गया है. सिर्फ़ उन SHA256 हैश को जोड़ने से लेयर 1 बनती है जिससे इमेज बहुत छोटी हो जाती है. लेयर 2, लेयर 1 के SHA256 हैश के साथ एक जैसी बनाई जाती है.

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

पुष्टि किए गए पार्टीशन के साइज़ के हिसाब से, हैश ट्री का साइज़ (और उससे जुड़े डिस्क स्पेस का इस्तेमाल) अलग-अलग होता है. आम तौर पर, हैश ट्री का साइज़ छोटा होता है. यह अक्सर 30 एमबी से कम होता है.

अगर किसी लेयर में ऐसा ब्लॉक है जो पिछली लेयर के हैश से पूरी तरह से अपने-आप नहीं भरता है, तो आपको उम्मीद के मुताबिक 4K रिज़ॉल्यूशन पाने के लिए, उसे शून्य से पैड करना चाहिए. इससे आपको यह पता चलता है कि हैश ट्री को हटाया नहीं गया है और इसके बजाय, उसे खाली डेटा के साथ पूरा किया गया है.

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

आपको याद दिला दें कि हैश ट्री बनाने के लिए सामान्य एल्गोरिदम यहां दिया गया है:

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

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

dm-verity मैपिंग टेबल बनाएं

डीएम-वेरिटी मैपिंग टेबल बनाएं, ताकि ब्लॉक डिवाइस या टारगेट की पहचान की जा सके और हैश ट्री की जगह के लिए (जो एक ही मान है.) इस मैपिंग का इस्तेमाल, fstab जनरेट करने और बूट करने के लिए किया जाता है. टेबल से आपको यह भी पता चलता है कि ब्लॉक का साइज़ और hash_start, हैश ट्री की शुरुआत की जगह (खास तौर पर, इमेज की शुरुआत से उसका ब्लॉक नंबर).

cryptsetup देखें वेरिटी टारगेट को मैप करने वाली टेबल के फ़ील्ड की पूरी जानकारी.

dm-verity टेबल पर हस्ताक्षर करें

टेबल सिग्नेचर बनाने के लिए, dm-verity टेबल पर हस्ताक्षर करें. किसी partition की पुष्टि करते समय, सबसे पहले टेबल के हस्ताक्षर की पुष्टि की जाती है. यह कार्रवाई, आपकी बूट इमेज में तय जगह पर मौजूद पासकोड के आधार पर की जाती है. कुंजियों को आमतौर पर डिवाइस बनाने वाली कंपनी का तय समयावधि में डिवाइसों पर अपने-आप शामिल होने के लिए सिस्टम बनाना स्थान.

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

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

टेबल सिग्नेचर को मेटाडेटा में बंडल करना

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

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

इससे यह पक्का हो जाता है कि आपने किसी ऐसे पार्टीशन की पुष्टि नहीं की है जिसकी पुष्टि नहीं हुई है. अगर ऐसा है, तो इस मैजिक नंबर के बिना पुष्टि की प्रक्रिया रुक जाती है. यह संख्या इससे मिलती-जुलती है 0xb001b001.

हेक्स में बाइट वैल्यू इस तरह हैं:

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

इस डायग्राम में, पुष्टि करने वाले मेटाडेटा के बारे में बताया गया है:

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

इस टेबल में, उन मेटाडेटा फ़ील्ड के बारे में बताया गया है.

टेबल 1. मेटाडेटा फ़ील्ड की पुष्टि करना

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

डीएम-वेरिटी ऑप्टिमाइज़ करें

डीएम-वेरिटी का सबसे अच्छा परफ़ॉर्मेंस पाने के लिए आपको ये काम करने चाहिए:

• कर्नेल में, ARMv7 के लिए NEON SHA-2 और ARMv8 के लिए SHA-2 एक्सटेंशन चालू करें.
• अपने डिवाइस के लिए सबसे अच्छा कॉन्फ़िगरेशन ढूंढने के लिए, read-ahead और prefetch_cluster की अलग-अलग सेटिंग आज़माएं.