मेटाडेटा एन्क्रिप्शन

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

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

जब भी FBE सक्षम किया जाता है तो मेटाडेटा एन्क्रिप्शन हमेशा गोद लेने योग्य संग्रहण पर सक्षम होता है। मेटाडेटा एन्क्रिप्शन को आंतरिक संग्रहण पर भी सक्षम किया जा सकता है। Android 11 या उच्चतर के साथ लॉन्च किए गए डिवाइस में आंतरिक संग्रहण पर मेटाडेटा एन्क्रिप्शन सक्षम होना चाहिए।

आंतरिक भंडारण पर कार्यान्वयन

आप metadata फ़ाइल सिस्टम को सेट करके, इनिट अनुक्रम को बदलकर, और डिवाइस की fstab फ़ाइल में मेटाडेटा एन्क्रिप्शन को सक्षम करके नए उपकरणों के आंतरिक संग्रहण पर मेटाडेटा एन्क्रिप्शन सेट कर सकते हैं।

आवश्यक शर्तें

मेटाडेटा एन्क्रिप्शन केवल तभी सेट किया जा सकता है जब डेटा विभाजन को पहले स्वरूपित किया गया हो। परिणामस्वरूप, यह सुविधा केवल नए उपकरणों के लिए है; यह ऐसा कुछ नहीं है जिसे ओटीए को बदलना चाहिए।

मेटाडेटा एन्क्रिप्शन के लिए आवश्यक है कि आपके कर्नेल में dm-default-key मॉड्यूल सक्षम हो। एंड्रॉइड 11 और उच्चतर में, dm-default-key एंड्रॉइड सामान्य कर्नेल, संस्करण 4.14 और उच्चतर द्वारा समर्थित है। dm-default-key की का यह संस्करण एक हार्डवेयर और विक्रेता-स्वतंत्र एन्क्रिप्शन फ्रेमवर्क का उपयोग करता है जिसे ब्लेक-क्रिप्टो कहा जाता है।

dm-default-key को सक्षम करने के लिए, उपयोग करें:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
CONFIG_DM_DEFAULT_KEY=y

dm-default-key इनलाइन एन्क्रिप्शन हार्डवेयर का उपयोग करता है (हार्डवेयर जो डेटा को एन्क्रिप्ट/डिक्रिप्ट करता है, जबकि यह स्टोरेज डिवाइस से/के रास्ते में है) उपलब्ध होने पर। यदि आप इनलाइन एन्क्रिप्शन हार्डवेयर का उपयोग नहीं कर रहे हैं, तो कर्नेल की क्रिप्टोग्राफ़ी API में फ़ॉलबैक सक्षम करना भी आवश्यक है:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

इनलाइन एन्क्रिप्शन हार्डवेयर का उपयोग नहीं करते समय आपको FBE दस्तावेज़ीकरण में अनुशंसित किसी भी उपलब्ध CPU-आधारित त्वरण को भी सक्षम करना चाहिए।

एंड्रॉइड 10 और उससे कम में, dm-default-key की को एंड्रॉइड कॉमन कर्नेल द्वारा समर्थित नहीं किया गया था। इसलिए यह विक्रेताओं पर निर्भर था कि वे dm-default-key को लागू करें।

मेटाडेटा फ़ाइल सिस्टम सेट करें

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

fstab.hardware में मेटाडेटा फ़ाइल सिस्टम के लिए एक प्रविष्टि शामिल होनी चाहिए जो उस विभाजन पर रहती है जो इसे /metadata पर माउंट करती है, यह सुनिश्चित करने के लिए कि यह बूट समय पर स्वरूपित है, formattable ध्वज सहित। f2fs फाइल सिस्टम छोटे विभाजन पर काम नहीं करता है; हम इसके बजाय ext4 का उपयोग करने की सलाह देते हैं। उदाहरण के लिए:

/dev/block/bootdevice/by-name/metadata              /metadata          ext4        noatime,nosuid,nodev,discard                          wait,check,formattable

यह सुनिश्चित करने के लिए कि /metadata आरोह बिंदु मौजूद है, निम्न पंक्ति को BoardConfig-common.mk में जोड़ें:

BOARD_USES_METADATA_PARTITION := true

इनिट अनुक्रम में परिवर्तन

जब मेटाडेटा एन्क्रिप्शन का उपयोग किया जाता है, तो vold /data माउंट होने से पहले चलना चाहिए। यह सुनिश्चित करने के लिए कि यह काफी पहले शुरू हो गया है, निम्नलिखित श्लोक init.hardware.rc में जोड़ें:

# We need vold early for metadata encryption
on early-fs
    start vold

init /data को माउंट करने का प्रयास करने से पहले कीमास्टर को चलना और तैयार होना चाहिए।

init.hardware.rc में पहले से ही एक mount_all निर्देश होना चाहिए जो /data on late-fs श्लोक में ही माउंट करता है। इस लाइन से पहले, wait_for_keymaster सेवा को निष्पादित करने के लिए निर्देश जोड़ें:

on late-fs
   … 
    # Wait for keymaster
    exec_start wait_for_keymaster

    # Mount RW partitions which need run fsck
    mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

मेटाडेटा एन्क्रिप्शन चालू करना

अंत में userdata के लिए fstab प्रविष्टि के fs_mgr_flags कॉलम में keydirectory=/metadata/vold/metadata_encryption जोड़ें। उदाहरण के लिए, एक पूर्ण fstab लाइन इस तरह दिख सकती है:

/dev/block/bootdevice/by-name/userdata              /data              f2fs        noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized,keydirectory=/metadata/vold/metadata_encryption,quota,formattable

डिफ़ॉल्ट रूप से, आंतरिक संग्रहण पर मेटाडेटा एन्क्रिप्शन एल्गोरिथम AES-256-XTS है। इसे metadata_encryption विकल्प सेट करके ओवरराइड किया जा सकता है, वह भी fs_mgr_flags कॉलम में:

• एईएस त्वरण की कमी वाले उपकरणों पर, एडियंटम एन्क्रिप्शन को metadata_encryption=adiantum सेट करके सक्षम किया जा सकता है।
• हार्डवेयर-रैप्ड कुंजियों का समर्थन करने वाले उपकरणों पर, मेटाडेटा एन्क्रिप्शन कुंजी को metadata_encryption=aes-256-xts:wrappedkey_v0 (या समकक्ष metadata_encryption=:wrappedkey_v0 , जैसा कि aes-256-xts डिफ़ॉल्ट एल्गोरिथम है) सेट करके हार्डवेयर-रैप किया जा सकता है।

चूंकि Android 11 में कर्नेल इंटरफ़ेस dm-default-key में बदल गया है, इसलिए आपको यह भी सुनिश्चित करना होगा कि आपने device.mk में PRODUCT_SHIPPING_API_LEVEL के लिए सही मान सेट किया है। उदाहरण के लिए, यदि आपका डिवाइस Android 11 (API स्तर 30) के साथ लॉन्च होता है, तो device.mk में शामिल होना चाहिए:

PRODUCT_SHIPPING_API_LEVEL := 30

आप शिपिंग API स्तर की परवाह किए बिना नए dm-default-key API के उपयोग को बाध्य करने के लिए निम्न सिस्टम गुण भी सेट कर सकते हैं:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.dm_default_key.options_format.version=2

मान्यकरण

यह सत्यापित करने के लिए कि मेटाडेटा एन्क्रिप्शन सक्षम है और ठीक से काम कर रहा है, नीचे वर्णित परीक्षण चलाएँ। नीचे वर्णित सामान्य मुद्दों से भी सावधान रहें।

परीक्षण

यह सत्यापित करने के लिए कि आंतरिक संग्रहण पर मेटाडेटा एन्क्रिप्शन सक्षम है, निम्न आदेश चलाकर प्रारंभ करें:

adb root
adb shell dmctl table userdata

आउटपुट के समान होना चाहिए:

Targets in the device-mapper table for userdata:
0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors

यदि आप डिवाइस के fstab में metadata_encryption विकल्प सेट करके डिफ़ॉल्ट एन्क्रिप्शन सेटिंग्स को ओवरराइड करते हैं, तो आउटपुट ऊपर से थोड़ा अलग होगा। उदाहरण के लिए, यदि आपने एडियंटम एन्क्रिप्शन को सक्षम किया है, तो तीसरा फ़ील्ड xchacha12,aes-adiantum-plain64 aes-xts-plain64 ।

इसके बाद, मेटाडेटा एन्क्रिप्शन और FBE की शुद्धता को सत्यापित करने के लिए vts_kernel_encryption_test चलाएँ:

atest vts_kernel_encryption_test

या:

vts-tradefed run vts -m vts_kernel_encryption_test

सामान्य मुद्दे

mount_all पर कॉल के दौरान, जो मेटाडेटा-एन्क्रिप्टेड /data विभाजन को माउंट करता है, init vdc टूल को निष्पादित करता है। vdc टूल मेटाडेटा-एन्क्रिप्टेड डिवाइस को सेट करने और पार्टीशन को माउंट करने के लिए vold ओवर binder से कनेक्ट होता है। इस कॉल की अवधि के लिए, init अवरुद्ध है, और init गुणों को पढ़ने या सेट करने का प्रयास mount_all समाप्त होने तक अवरुद्ध रहेगा। यदि, इस स्तर पर, vold के काम का कोई हिस्सा प्रत्यक्ष या अप्रत्यक्ष रूप से किसी संपत्ति को पढ़ने या स्थापित करने पर अवरुद्ध हो जाता है, तो गतिरोध का परिणाम होगा। यह सुनिश्चित करना महत्वपूर्ण है कि वोल्ड कुंजी को पढ़ने, vold के साथ बातचीत करने और डेटा निर्देशिका को आगे बढ़ाए बिना init के साथ बातचीत करने का काम पूरा कर सकता है।

यदि vold के चलने पर mount_all पूरी तरह से शुरू नहीं होता है, तो यह वॉल्ड को तब तक प्रतिक्रिया नहीं देगा जब तक कि उसने init से कुछ गुणों को नहीं पढ़ा है, जिसके परिणामस्वरूप वास्तव में गतिरोध का वर्णन किया गया है। निष्पादन_स्टार्ट प्रतीक्षा_फॉर_कीमास्टर को प्रासंगिक exec_start wait_for_keymaster इनवोकेशन के ऊपर सेट आउट के रूप में mount_all सुनिश्चित करता है कि कीमास्टर पूरी तरह से पहले से चल रहा है और इसलिए इस गतिरोध से बचा जाता है।

गोद लेने योग्य भंडारण पर विन्यास

एंड्रॉइड 9 के बाद से, जब भी एफबीई सक्षम होता है, तब भी मेटाडेटा एन्क्रिप्शन का एक रूप गोद लेने योग्य भंडारण पर हमेशा सक्षम होता है, भले ही आंतरिक भंडारण पर मेटाडेटा एन्क्रिप्शन सक्षम न हो।

एओएसपी में, गोद लेने योग्य भंडारण पर मेटाडेटा एन्क्रिप्शन के दो कार्यान्वयन हैं: dm-crypt पर आधारित एक पदावनत, और dm-default-key पर आधारित एक नया। यह सुनिश्चित करने के लिए कि आपके डिवाइस के लिए सही कार्यान्वयन चुना गया है, सुनिश्चित करें कि आपने device.mk में PRODUCT_SHIPPING_API_LEVEL के लिए सही मान सेट किया है। उदाहरण के लिए, यदि आपका डिवाइस Android 11 (API स्तर 30) के साथ लॉन्च होता है, तो device.mk में शामिल होना चाहिए:

PRODUCT_SHIPPING_API_LEVEL := 30

आप शिपिंग API स्तर की परवाह किए बिना नई वॉल्यूम मेटाडेटा एन्क्रिप्शन विधि (और नया डिफ़ॉल्ट FBE नीति संस्करण) के उपयोग के लिए बाध्य करने के लिए निम्न सिस्टम गुण भी सेट कर सकते हैं:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.volume.metadata.method=dm-default-key \
    ro.crypto.dm_default_key.options_format.version=2 \
    ro.crypto.volume.options=::v2

वर्तमान विधि

एंड्रॉइड 11 या उच्चतर के साथ लॉन्च होने वाले उपकरणों पर, गोद लेने योग्य भंडारण पर मेटाडेटा एन्क्रिप्शन dm-default-key कर्नेल मॉड्यूल का उपयोग करता है, जैसे आंतरिक भंडारण पर। उपरोक्त पूर्वापेक्षाएँ देखें जिसके लिए कर्नेल कॉन्फ़िगरेशन विकल्प सक्षम करना है। ध्यान दें कि डिवाइस के आंतरिक संग्रहण पर काम करने वाला इनलाइन एन्क्रिप्शन हार्डवेयर गोद लेने योग्य संग्रहण पर अनुपलब्ध हो सकता है, और इस प्रकार CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y की आवश्यकता हो सकती है।

डिफ़ॉल्ट रूप से, dm-default-key वॉल्यूम मेटाडेटा एन्क्रिप्शन विधि 4096-बाइट क्रिप्टो सेक्टरों के साथ एईएस-256-एक्सटीएस एन्क्रिप्शन एल्गोरिदम का उपयोग करती है। एल्गोरिथ्म को ro.crypto.volume.metadata.encryption सिस्टम गुण सेट करके ओवरराइड किया जा सकता है। इस प्रॉपर्टी के मान का सिंटैक्स वही है जो ऊपर वर्णित metadata_encryption fstab विकल्प है। उदाहरण के लिए, एईएस त्वरण की कमी वाले उपकरणों पर, एडियंटम एन्क्रिप्शन को ro.crypto.volume.metadata.encryption=adiantum सेट करके सक्षम किया जा सकता है।

विरासत विधि

एंड्रॉइड 10 या उससे कम के साथ लॉन्च होने वाले उपकरणों पर, गोद लेने योग्य भंडारण पर मेटाडेटा एन्क्रिप्शन dm-crypt कर्नेल मॉड्यूल का उपयोग करता है dm-default-key बजाय:

CONFIG_DM_CRYPT=y

dm-default-key विधि के विपरीत, dm-crypt विधि फ़ाइल सामग्री को दो बार एन्क्रिप्ट करने का कारण बनती है: एक बार एफबीई कुंजी के साथ और एक बार मेटाडेटा एन्क्रिप्शन कुंजी के साथ। यह दोहरा एन्क्रिप्शन प्रदर्शन को कम करता है और मेटाडेटा एन्क्रिप्शन के सुरक्षा लक्ष्यों को प्राप्त करने के लिए आवश्यक नहीं है, क्योंकि Android सुनिश्चित करता है कि FBE कुंजी मेटाडेटा एन्क्रिप्शन कुंजी के रूप में समझौता करने के लिए कम से कम कठिन हैं। विक्रेता डबल एन्क्रिप्शन से बचने के लिए कर्नेल अनुकूलन कर सकते हैं, विशेष रूप से allow_encrypt_override विकल्प को लागू करके जो एंड्रॉइड dm-crypt को पास करेगा जब सिस्टम प्रॉपर्टी ro.crypto.allow_encrypt_override को true पर सेट किया जाता है। ये अनुकूलन Android सामान्य कर्नेल द्वारा समर्थित नहीं हैं।

डिफ़ॉल्ट रूप से, dm- dm-crypt वॉल्यूम मेटाडेटा एन्क्रिप्शन विधि ESSIV और 512-बाइट क्रिप्टो सेक्टरों के साथ AES-128-CBC एन्क्रिप्शन एल्गोरिथम का उपयोग करती है। इसे निम्नलिखित सिस्टम गुण (जो FDE के लिए भी उपयोग किया जाता है) सेट करके ओवरराइड किया जा सकता है:

• ro.crypto.fde_algorithm मेटाडेटा एन्क्रिप्शन एल्गोरिथम का चयन करता है। विकल्प aes-128-cbc और adiantum । एडियंटम का उपयोग केवल तभी किया जा सकता है जब डिवाइस में एईएस त्वरण का अभाव हो।
• ro.crypto.fde_sector_size क्रिप्टो सेक्टर आकार का चयन करता है। विकल्प 512, 1024, 2048, और 4096 हैं। एडियंटम एन्क्रिप्शन के लिए, 4096 का उपयोग करें।