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

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

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

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

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

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

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

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

मेटाडेटा एन्क्रिप्शन के लिए आवश्यक है कि आपके कर्नेल में 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 उपलब्ध होने पर इनलाइन एन्क्रिप्शन हार्डवेयर (हार्डवेयर जो स्टोरेज डिवाइस के रास्ते में/से डेटा को एन्क्रिप्ट/डिक्रिप्ट करता है) का उपयोग करता है। यदि आप इनलाइन एन्क्रिप्शन हार्डवेयर का उपयोग नहीं कर रहे हैं, तो कर्नेल की क्रिप्टोग्राफी एपीआई में फ़ॉलबैक को सक्षम करना भी आवश्यक है:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

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

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

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

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

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

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

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

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

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

init.hardware.rc में पहले से ही एक mount_all निर्देश होना चाहिए जो on late-fs श्लोक में /data स्वयं माउंट करता है। इस पंक्ति से पहले, 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 है। इसे fs_mgr_flags कॉलम में metadata_encryption विकल्प सेट करके ओवरराइड किया जा सकता है:

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

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

PRODUCT_SHIPPING_API_LEVEL := 30

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

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 विकल्प सेट करके डिफ़ॉल्ट एन्क्रिप्शन सेटिंग्स को ओवरराइड करते हैं, तो आउटपुट उपरोक्त से थोड़ा अलग होगा। उदाहरण के लिए, यदि आपने एडियंटम एन्क्रिप्शन सक्षम किया है, तो तीसरा फ़ील्ड aes-xts-plain64 के बजाय xchacha12,aes-adiantum-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 टूल को निष्पादित करता है। वीडीसी टूल मेटाडेटा-एन्क्रिप्टेड डिवाइस को सेट करने और विभाजन को माउंट करने के लिए vold ओवर binder से कनेक्ट होता है। इस कॉल की अवधि के लिए, init अवरुद्ध है, और init गुणों को पढ़ने या सेट करने का प्रयास mount_all समाप्त होने तक अवरुद्ध रहेगा। यदि, इस स्तर पर, vold के काम का कोई भी हिस्सा किसी संपत्ति को पढ़ने या सेट करने पर प्रत्यक्ष या अप्रत्यक्ष रूप से अवरुद्ध हो जाता है, तो गतिरोध उत्पन्न होगा। यह सुनिश्चित करना महत्वपूर्ण है कि vold कुंजियों को पढ़ने, कीमास्टर के साथ इंटरैक्ट करने और init के साथ आगे इंटरैक्ट किए बिना डेटा डायरेक्टरी को माउंट करने का काम पूरा कर सकता है।

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

अपनाने योग्य भंडारण पर कॉन्फ़िगरेशन

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

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

PRODUCT_SHIPPING_API_LEVEL := 30

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

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-default-key के बजाय dm-crypt कर्नेल मॉड्यूल का उपयोग करता है:

CONFIG_DM_CRYPT=y

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

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

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