मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने का तरीका

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

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

एफ़बीई चालू होने पर, अडॉप्ट किए जा सकने वाले स्टोरेज पर मेटाडेटा एन्क्रिप्शन हमेशा चालू रहता है. मेटाडेटा एन्क्रिप्शन की सुविधा, इंटरनल स्टोरेज पर भी चालू की जा सकती है. Android 11 या इसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों के डिवाइस के स्टोरेज में, मेटाडेटा एन्क्रिप्शन की सुविधा चालू होनी चाहिए.

डिवाइस के स्टोरेज को लागू करने की सुविधा

नए डिवाइसों के इंटरनल स्टोरेज पर मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने का तरीका सेट अप किया जा सकता है. इसके लिए, metadata फ़ाइल सिस्टम सेट अप करें, इनिट क्रम को बदलें, और डिवाइस की fstab फ़ाइल में मेटाडेटा एन्क्रिप्ट (सुरक्षित) करने की सुविधा चालू करें.

ज़रूरी शर्तें

मेटाडेटा एन्क्रिप्शन को सिर्फ़ तब सेट अप किया जा सकता है, जब डेटा सेगमेंट को पहली बार फ़ॉर्मैट किया गया हो. इसलिए, यह सुविधा सिर्फ़ नए डिवाइसों के लिए है. इसे ओटीए (Over-The-Air) से बदला नहीं जा सकता.

मेटाडेटा एन्क्रिप्ट (सुरक्षित) करने के लिए, आपके kernel में dm-default-key मॉड्यूल चालू होना चाहिए. Android 11 और इसके बाद के वर्शन में, dm-default-key, Android के सामान्य कर्नेल के 4.14 और इसके बाद के वर्शन पर काम करता है. dm-default-key के इस वर्शन में, blk-crypto नाम के ऐसे एन्क्रिप्शन फ़्रेमवर्क का इस्तेमाल किया जाता है जो हार्डवेयर और वेंडर पर निर्भर नहीं करता.

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

इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल न करने पर, आपको FBE दस्तावेज़ में सुझाए गए तरीके के मुताबिक, सीपीयू पर आधारित तेज़ी लाने की सुविधा भी चालू करनी चाहिए.

Android 10 और उससे पहले वाले वर्शन में, dm-default-key Android के सामान्य कर्नेल के साथ काम नहीं करता. इसलिए, 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

इनिट क्रम में बदलाव

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

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

init के /data को माउंट करने की कोशिश करने से पहले, Keymaster चालू और तैयार होना चाहिए.

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 होता है. इसे बदला जा सकता है. इसके लिए, metadata_encryption विकल्प को सेट करें. इसे fs_mgr_flags कॉलम में भी सेट किया जा सकता है:

• जिन डिवाइसों पर एईएस से तेज़ी लाने की सुविधा उपलब्ध नहीं है उन पर, Adiantum एन्क्रिप्शन की सुविधा 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 (एपीआई लेवल 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 विकल्प सेट करके, एन्क्रिप्शन की डिफ़ॉल्ट सेटिंग को बदल दिया है, तो आउटपुट ऊपर दिए गए आउटपुट से थोड़ा अलग होगा. उदाहरण के लिए, अगर आपने Adiantum एन्क्रिप्शन को चालू किया है, तो तीसरा फ़ील्ड aes-xts-plain64 के बजाय xchacha12,aes-adiantum-plain64 होगा.

इसके बाद, मेटाडेटा एन्क्रिप्शन और एफ़बीई के सही होने की पुष्टि करने के लिए, vts_kernel_encryption_test चलाएं:

atest vts_kernel_encryption_test

या:

vts-tradefed run vts -m vts_kernel_encryption_test

सामान्य समस्याएं

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

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

डिवाइस के स्टोरेज के लिए कॉन्फ़िगरेशन

डिवाइस के स्टोरेज में एफ़बीई की सुविधा चालू होने पर भी, Android 9 वर्शन पर, मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने का एक तरीका हमेशा चालू रहता है. ऐसा तब भी होता है, जब डिवाइस के स्टोरेज में मेटाडेटा एन्क्रिप्शन की सुविधा चालू न हो.

AOSP में, इस्तेमाल किए जा सकने वाले स्टोरेज पर मेटाडेटा एन्क्रिप्शन के दो तरीके हैं: dm-crypt पर आधारित पुराना तरीका और dm-default-key पर आधारित नया तरीका. यह पक्का करने के लिए कि आपके डिवाइस के लिए सही तरीके से लागू किया गया है, पक्का करें कि आपने device.mk में PRODUCT_SHIPPING_API_LEVEL के लिए सही वैल्यू सेट की हो. उदाहरण के लिए, अगर आपका डिवाइस Android 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

मौजूदा तरीका

Android 11 या इसके बाद के वर्शन वाले डिवाइसों पर, डिवाइस में जोड़े जा सकने वाले स्टोरेज में मेटाडेटा एन्क्रिप्ट (सुरक्षित) करने के लिए, dm-default-key केर्नेल मॉड्यूल का इस्तेमाल किया जाता है. यह ठीक वैसा ही है जैसे इंटरनल स्टोरेज में किया जाता है. ऊपर दिए गए ज़रूरी शर्तों के हिसाब से, यह तय करें कि आपको कौनसे कर्नेल कॉन्फ़िगरेशन के विकल्प चालू करने हैं. ध्यान दें कि हो सकता है कि डिवाइस के स्टोरेज में काम करने वाला इनलाइन एन्क्रिप्शन हार्डवेयर, डिवाइस के स्टोरेज के लिए उपलब्ध न हो. इसलिए, हो सकता है कि CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y की ज़रूरत पड़े.

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

लेगसी तरीका

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

CONFIG_DM_CRYPT=y

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

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

• ro.crypto.fde_algorithm, मेटाडेटा एन्क्रिप्शन एल्गोरिदम चुनता है. विकल्प aes-128-cbc और adiantum हैं. Adiantum का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब डिवाइस में एईएस एक्सेलरेटर की सुविधा मौजूद न हो.
• ro.crypto.fde_sector_size, क्रिप्टो सेक्टर का साइज़ चुनता है. विकल्प 512, 1024, 2048, और 4096 हैं. एडिएन्टम एन्क्रिप्शन के लिए, 4096 का इस्तेमाल करें.