एंड्रॉइड 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 का उपयोग करें।