फ़ाइल पर आधारित एन्क्रिप्ट (सुरक्षित) करने का तरीका

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

इस लेख में, नए डिवाइसों पर फ़ाइल-आधारित एन्क्रिप्शन को चालू करने का तरीका बताया गया है. साथ ही, यह भी बताया गया है कि उपयोगकर्ताओं को सबसे अच्छा और सबसे सुरक्षित अनुभव देने के लिए, सिस्टम ऐप्लिकेशन, Direct Boot API का इस्तेमाल कैसे कर सकते हैं.

Android 10 और इसके बाद के वर्शन के साथ लॉन्च होने वाले सभी डिवाइसों के लिए, फ़ाइल-आधारित एन्क्रिप्शन का इस्तेमाल करना ज़रूरी है.

चेतावनी: Android 7.0 से 8.1 के वर्शन में, एफ़बीई डिवाइस के स्टोरेज के तौर पर फ़ॉर्मैट किए गए बाहरी स्टोरेज के साथ काम नहीं करता. साथ ही, बाहरी स्टोरेज मीडिया (जैसे, एसडी कार्ड) का इस्तेमाल सिर्फ़ सामान्य स्टोरेज के तौर पर किया जा सकता है. Android 9 और उसके बाद के वर्शन में, एफ़बीई, अडॉप्ट किए जा सकने वाले स्टोरेज के साथ काम करता है.

डायरेक्ट बूट

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

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

एफ़बीई की सुविधा वाले डिवाइस पर, हर उपयोगकर्ता के पास ऐप्लिकेशन के लिए दो स्टोरेज लोकेशन उपलब्ध होती हैं:

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

ध्यान दें: जब भी हो सके, फ़ाइलों को सीई के स्टोरेज में सेव करें.

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

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

Ext4 और F2FS फ़ाइल सिस्टम पर पूरी तरह से फ़ाइल पर आधारित एन्क्रिप्शन की सुविधा, Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में उपलब्ध कराई गई है. इसे सिर्फ़ उन डिवाइसों पर चालू किया जाना चाहिए जो इसकी ज़रूरी शर्तें पूरी करते हैं. एफ़बीई का इस्तेमाल करने वाले मैन्युफ़ैक्चरर, चिप पर सिस्टम (SoC) के आधार पर, इस सुविधा को ऑप्टिमाइज़ करने के तरीके ढूंढ सकते हैं.

एओएसपी में सभी ज़रूरी पैकेज को सीधे तौर पर बूट करने की जानकारी देने के लिए अपडेट किया गया है. हालांकि, डिवाइस बनाने वाली कंपनियां इन ऐप्लिकेशन के पसंद के मुताबिक बनाए गए वर्शन का इस्तेमाल करती हैं. इसलिए, वे यह पक्का करना चाहती हैं कि कम से कम ये सेवाएं देने वाले, डायरेक्ट-बूट के बारे में जानकारी देने वाले पैकेज मौजूद हों:

• टेलीफ़ोन सेवाएं और डायलर
• लॉक स्क्रीन पर पासवर्ड डालने का तरीका

उदाहरण और सोर्स

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

• AOSP डायलर (packages/apps/Dialer)
• डेस्क क्लॉक (पैकेज/ऐप्लिकेशन/डेस्कक्लॉक)
• LatinIME (packages/inputmethods/LatinIME)*
• Settings ऐप्लिकेशन (पैकेज/ऐप्लिकेशन/सेटिंग)*
• SystemUI (फ़्रेमवर्क/बेस/पैकेज/SystemUI)*

* वे सिस्टम ऐप्लिकेशन जो defaultToDeviceProtectedStorage मेनिफ़ेस्ट एट्रिब्यूट का इस्तेमाल करते हैं

एन्क्रिप्शन की जानकारी रखने वाले ऐप्लिकेशन और सेवाओं के और उदाहरण, एओएसपी सोर्स ट्री के फ़्रेमवर्क या पैकेज डायरेक्ट्री में mangrep directBootAware कमांड चलाकर देखा जा सकता है.

डिपेंडेंसी

एओएसपी में एफ़बीई को सुरक्षित तरीके से इस्तेमाल करने के लिए, डिवाइस को इन डिपेंडेंसी को पूरा करना होगा:

• Ext4 एन्क्रिप्शन या F2FS एन्क्रिप्शन के लिए कर्नल सपोर्ट.
• HAL के 1.0 या इसके बाद के वर्शन के साथ Keymaster की सहायता. KeyMaster 0.3 पर कोई काम नहीं करता है, क्योंकि यह ज़रूरी सुविधाएं उपलब्ध नहीं कराता है या एन्क्रिप्शन कुंजियों के लिए काफ़ी सुरक्षा नहीं देता है.
• DE कुंजियों की सुरक्षा देने के लिए कीमास्टर/कीस्टोर और गेटकीपर को ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में लागू किया जाना चाहिए. इससे, बिना अनुमति वाला ओएस (डिवाइस पर फ़्लैश किया गया कस्टम ओएस) सिर्फ़ DE कुंजियों के लिए अनुरोध नहीं कर पाएगा.
• Hardware Root of Trust और वेरिफ़ाइड बूट की-मास्टर शुरू करने की प्रोसेस के लिए यह ज़रूरी है कि वे यह पक्का करें कि बिना मंज़ूरी वाला ऑपरेटिंग सिस्टम DE कुंजियों को ऐक्सेस न कर पाए.

लागू करना

सबसे पहले, डायरेक्ट बूट डेवलपर दस्तावेज़ के मुताबिक, अलार्म घड़ी, फ़ोन, और सुलभता सुविधाओं जैसे ऐप्लिकेशन को android:directBootAware बनाया जाना चाहिए.

कर्नेल सपोर्ट

Ext4 और F2FS एन्क्रिप्शन के लिए, Android के सामान्य कोर 3.18 और इसके बाद के वर्शन में, कोर की सहायता उपलब्ध है. इसे 5.1 या इसके बाद के वर्शन वाले कर्नेल में चालू करने के लिए, इनका इस्तेमाल करें:

CONFIG_FS_ENCRYPTION=y

पुराने कर्नेल के लिए, CONFIG_EXT4_ENCRYPTION=y का इस्तेमाल करें. ऐसा तब करें, जब आपके डिवाइस का userdata फ़ाइल सिस्टम Ext4 हो. अगर आपके डिवाइस का userdata फ़ाइल सिस्टम F2FS है, तो CONFIG_F2FS_FS_ENCRYPTION=y का इस्तेमाल करें.

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

Ext4 या F2FS एन्क्रिप्शन के लिए फ़ंक्शनल सपोर्ट के अलावा, डिवाइस बनाने वाली कंपनियों को फ़ाइल पर आधारित एन्क्रिप्शन को तेज़ करने और उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, क्रिप्टोग्राफ़िक ऐक्सेलरेशन की सुविधा भी चालू करनी चाहिए. उदाहरण के लिए, ARM64 पर आधारित डिवाइसों पर, ARMv8 CE (क्रिप्टोग्राफ़ी एक्सटेंशन) से तेज़ी लाने की सुविधा चालू की जा सकती है. इसके लिए, कर्नेल के कॉन्फ़िगरेशन के इन विकल्पों को सेट करें:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

परफ़ॉर्मेंस को और बेहतर बनाने और बिजली की खपत को कम करने के लिए, डिवाइस बनाने वाली कंपनियां इनलाइन एन्क्रिप्शन हार्डवेयर को लागू करने पर भी विचार कर सकती हैं. यह हार्डवेयर, स्टोरेज डिवाइस से डेटा को भेजने या पाने के दौरान, उसे एन्क्रिप्ट/डिक्रिप्ट करता है. Android के सामान्य कर्नेल (वर्शन 4.14 और उसके बाद वाले वर्शन) में एक ऐसा फ़्रेमवर्क होता है जो हार्डवेयर और वेंडर ड्राइवर के लिए सहायता उपलब्ध होने पर, इनलाइन एन्क्रिप्शन का इस्तेमाल करता है. नीचे दिए गए कर्नेल कॉन्फ़िगरेशन विकल्पों को सेट करके इनलाइन एन्क्रिप्शन फ़्रेमवर्क को चालू किया जा सकता है:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

अगर आपके डिवाइस में यूएफ़एस (यूनिफ़ाइड फ़ाइल सिस्टम) स्टोरेज का इस्तेमाल किया जाता है, तो ये भी चालू करें:

CONFIG_SCSI_UFS_CRYPTO=y

अगर आपके डिवाइस में ईएमएमसी पर आधारित स्टोरेज का इस्तेमाल किया जाता है, तो इन्हें भी चालू करें:

CONFIG_MMC_CRYPTO=y

फ़ाइल के आधार पर एन्क्रिप्ट (सुरक्षित) करने का तरीका चालू करें

किसी डिवाइस पर FBE को चालू करने के लिए इसे डिवाइस के स्टोरेज (userdata) में चालू करना ज़रूरी है. इससे डिवाइस के स्टोरेज पर भी FBE की सुविधा अपने-आप चालू हो जाती है. हालांकि, ज़रूरत पड़ने पर, डिवाइस के स्टोरेज के लिए एन्क्रिप्शन के फ़ॉर्मैट को बदला जा सकता है.

मोबाइल मेमोरी

userdata के लिए fstab लाइन के fs_mgr_flags कॉलम में, fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] विकल्प जोड़कर एफ़बीई को चालू किया जाता है. यह विकल्प, इंटरनल स्टोरेज में एन्क्रिप्शन फ़ॉर्मैट तय करता है. इसमें कोलन से अलग किए गए ज़्यादा से ज़्यादा तीन पैरामीटर शामिल होते हैं:

• contents_encryption_mode पैरामीटर से यह तय होता है कि फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने के लिए, किस क्रिप्टोग्राफ़िक एल्गोरिदम का इस्तेमाल किया जाए. यह aes-256-xts या adiantum हो सकता है. Android 11 के बाद से, डिफ़ॉल्ट एल्गोरिदम तय करने के लिए इसे खाली भी छोड़ा जा सकता है, जो कि aes-256-xts है.
• filenames_encryption_mode पैरामीटर से तय होता है कि फ़ाइल के नामों को एन्क्रिप्ट करने के लिए, किस क्रिप्टोग्राफ़िक एल्गोरिदम का इस्तेमाल किया जाता है. यह वैल्यू, aes-256-cts, aes-256-heh, adiantum या aes-256-hctr2 हो सकती है. अगर इसके बारे में नहीं बताया गया है, तो अगर contents_encryption_mode aes-256-xts है, तो यह aes-256-cts पर डिफ़ॉल्ट रूप से सेट हो जाती है. अगर contents_encryption_mode adiantum है, तो यह adiantum पर डिफ़ॉल्ट रूप से सेट हो जाती है.
• Android 11 के लिए नया पैरामीटर flags पैरामीटर है. यह उन फ़्लैग की सूची है जिन्हें + वर्ण से अलग किया गया है. ये फ़्लैग इस्तेमाल किए जा सकते हैं:
  • v1 फ़्लैग में, वर्शन 1 को एन्क्रिप्ट करने की नीतियों को चुना जाता है. वहीं, v2 फ़्लैग में, वर्शन 2 को एन्क्रिप्ट करने की नीतियों को चुना जाता है. वर्शन 2 की, एन्क्रिप्ट (सुरक्षित) करने की नीतियों के लिए ज़्यादा सुरक्षित और आसान की डेरिवेशन फ़ंक्शन का इस्तेमाल किया जाता है. डिफ़ॉल्ट रूप से, अगर डिवाइस Android 11 या उसके बाद के वर्शन पर लॉन्च किया गया है, तो ro.product.first_api_level के हिसाब से v2 लागू होता है. अगर डिवाइस Android 10 या उससे पहले के वर्शन पर लॉन्च किया गया है, तो v1 लागू होता है.
  • inlinecrypt_optimized फ़्लैग, एन्क्रिप्ट (सुरक्षित) करने के ऐसे फ़ॉर्मैट को चुनता है जो इनलाइन एन्क्रिप्शन हार्डवेयर के लिए ऑप्टिमाइज़ किया गया है. यह हार्डवेयर बहुत ज़्यादा कुंजियों को सही तरीके से हैंडल नहीं करता. ऐसा करने के लिए, हर फ़ाइल के लिए एक के बजाय, हर CE या DE कुंजी के लिए फ़ाइल कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करने की एक कुंजी मिलती है. इसके हिसाब से, आईवी (इनिशियलाइज़ेशन वेक्टर) जनरेशन में बदलाव किया जाता है.
  • emmc_optimized फ़्लैग, inlinecrypt_optimized की तरह ही होता है. हालांकि, यह IV जनरेशन का तरीका भी चुनता है, जिसमें IV को 32 बिट तक सीमित रखा जाता है. इस फ़्लैग का इस्तेमाल सिर्फ़ ऐसे इनलाइन एन्क्रिप्शन हार्डवेयर पर किया जाना चाहिए जो जेडीईसी eMMC v5.2 स्पेसिफ़िकेशन के मुताबिक हो. इसलिए, यह सिर्फ़ 32-बिट आईवी के साथ काम करता है. किसी अन्य इनलाइन एन्क्रिप्शन हार्डवेयर पर, इसके बजाय inlinecrypt_optimized का इस्तेमाल करें. इस फ़्लैग का इस्तेमाल कभी भी यूएफ़एस पर आधारित स्टोरेज के लिए नहीं किया जाना चाहिए; यूएफ़एस स्पेसिफ़िकेशन में, 64-बिट IV के इस्तेमाल की अनुमति दी गई है.
  • जिन डिवाइसों पर हार्डवेयर से रैप की गई कुंजियां काम करती हैं उन पर wrappedkey_v0 फ़्लैग, FBE के लिए हार्डवेयर में रैप की गई कुंजियों को इस्तेमाल करने की सुविधा देता है. इसका इस्तेमाल सिर्फ़ inlinecrypt माउंट विकल्प और inlinecrypt_optimized या emmc_optimized फ़्लैग के साथ किया जा सकता है.
  • dusize_4k फ़्लैग, एन्क्रिप्ट (सुरक्षित) किए जाने वाले डेटा यूनिट का साइज़ 4096 बाइट रखता है, भले ही फ़ाइल सिस्टम ब्लॉक का साइज़ 4096 बाइट न हो. एन्क्रिप्शन डेटा यूनिट का साइज़, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने के तरीके के बारे में जानकारी देता है. यह फ़्लैग, Android 15 से उपलब्ध है. इस फ़्लैग का इस्तेमाल सिर्फ़ इनलाइन एन्क्रिप्शन हार्डवेयर के इस्तेमाल को चालू करने के लिए किया जाना चाहिए. यह हार्डवेयर 4096 बाइट से बड़ी डेटा यूनिट के साथ काम नहीं करता है. यह फ़्लैग 4096 बाइट से बड़े पेज साइज़ और f2fs फ़ाइल सिस्टम का इस्तेमाल करने वाले डिवाइस पर काम करता है.

अगर इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल नहीं किया जा रहा है, तो ज़्यादातर डिवाइसों के लिए fileencryption=aes-256-xts सेटिंग का सुझाव दिया जाता है. अगर इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल किया जा रहा है, तो ज़्यादातर डिवाइसों के लिए यह सेटिंग fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (या इसके बराबर) fileencryption=::inlinecrypt_optimized पर सेट करने की सलाह दी जाती है. जिन डिवाइसों पर एईएस से तेज़ी लाने की सुविधा किसी भी तरह की नहीं है उन पर fileencryption=adiantum सेट करके एईएस के बजाय, Adiantum का इस्तेमाल किया जा सकता है.

Android 14 और इसके बाद के वर्शन वाले डिवाइसों में, फ़ाइल नाम को एन्क्रिप्ट (सुरक्षित) करने के लिए, AES-HCTR2 का इस्तेमाल किया जाता है. यह तरीका ऐसे डिवाइसों पर इस्तेमाल किया जाता है जिनमें फटाफट क्रिप्टोग्राफ़ी की सुविधा होती है. हालांकि, सिर्फ़ नए Android कर्नेल ही AES-HCTR2 पर काम करते हैं. आने वाले समय में, Android के किसी नए वर्शन में यह फ़ाइल के नाम को एन्क्रिप्ट (सुरक्षित) करने का डिफ़ॉल्ट मोड बन जाएगा. अगर आपके कर्नेल में AES-HCTR2 काम करता है, तो filenames_encryption_mode को aes-256-hctr2 पर सेट करके इसे फ़ाइल नाम से एन्क्रिप्ट (सुरक्षित) करने के लिए चालू किया जा सकता है. सबसे आसान मामले में, ऐसा fileencryption=aes-256-xts:aes-256-hctr2 के साथ किया जाएगा.

Android 10 या इससे पहले के वर्शन वाले डिवाइसों पर, FSCRYPT_MODE_PRIVATE फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने के मोड के इस्तेमाल के बारे में बताने के लिए, fileencryption=ice भी स्वीकार किया जाता है. Android के सामान्य कर्नेल में यह मोड लागू नहीं किया गया है. हालांकि, वेंडर कस्टम कर्नेल पैच का इस्तेमाल करके, इसे लागू कर सकते हैं. इस मोड से डिस्क पर जनरेट होने वाला फ़ॉर्मैट, वेंडर के हिसाब से होता था. Android 11 या उसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों पर, अब इस मोड की अनुमति नहीं है. इसके बजाय, एन्क्रिप्ट (सुरक्षित) करने के स्टैंडर्ड फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए.

चेतावनी: डिस्क पर मौजूद फ़ॉर्मैट के बारे में बताने वाला fileencryption विकल्प, ऑन-लाइन अपडेट (ओटीए) की मदद से बदला नहीं जा सकता.

डिफ़ॉल्ट रूप से, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने के लिए, Linux kernel के क्रिप्टोग्राफ़ी एपीआई का इस्तेमाल किया जाता है. अगर आपको इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल करना है, तो inlinecrypt माउंट करने का विकल्प भी जोड़ें. उदाहरण के लिए, fstab वाली पूरी लाइन कुछ इस तरह दिख सकती है:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

ध्यान दें:

• inlinecrypt और fileencryption विकल्प अलग-अलग कॉलम में होते हैं, क्योंकि inlinecrypt एक फ़ाइल सिस्टम माउंट करने का विकल्प है, जबकि fileencryption, Android यूज़रस्पेस के लिए एक फ़्लैग है.
• अगर इनलाइन एन्क्रिप्शन से जुड़ा आपका हार्डवेयर ठीक से काम करता है और wrappedkey_v0 फ़्लैग सेट नहीं है, तो inlinecrypt माउंट करने का विकल्प किसी भी समय डिवाइस को वाइप किए बिना जोड़ा या हटाया जा सकता है. दूसरे शब्दों में, जब तक हार्डवेयर की मदद से एन्क्रिप्ट की गई कुंजियां चालू नहीं होतीं, तब तक inlinecrypt का असर सिर्फ़ लागू करने पर पड़ेगा, डिस्क पर मौजूद फ़ॉर्मैट पर नहीं. आपको डेवलपमेंट के दौरान inlinecrypt को हटाने की जांच करनी चाहिए, ताकि यह पुष्टि की जा सके कि आपका इनलाइन एन्क्रिप्शन हार्डवेयर सही तरीके से काम कर रहा है.

डिवाइस का स्टोरेज

Android 9, FBE और डिवाइस के स्टोरेज को एक साथ इस्तेमाल किया जा सकता है.

userdata के लिए fileencryption fstab विकल्प तय करने पर, इस्तेमाल किए जा सकने वाले स्टोरेज पर FBE और मेटाडेटा एन्क्रिप्शन, दोनों अपने-आप चालू हो जाते हैं. हालांकि, PRODUCT_PROPERTY_OVERRIDES में प्रॉपर्टी सेट करके, इस्तेमाल किए जा सकने वाले स्टोरेज में FBE या मेटाडेटा एन्क्रिप्शन फ़ॉर्मैट को बदला जा सकता है.

Android 11 या उसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों पर, ये प्रॉपर्टी इस्तेमाल करें:

• ro.crypto.volume.options (Android 11 में नया वर्शन), डिवाइस के स्टोरेज के लिए एफ़बीई एन्क्रिप्शन फ़ॉर्मैट चुनता है. इसका सिंटैक्स वही है जो fileencryption fstab विकल्प के आर्ग्युमेंट के तौर पर है और यह उन्हीं डिफ़ॉल्ट का इस्तेमाल करता है. यहां किसका इस्तेमाल करना है, यह जानने के लिए ऊपर fileencryption के लिए दिए गए सुझाव देखें.
• ro.crypto.volume.metadata.encryption, डिवाइस के स्टोरेज के तौर पर सेट अप किए गए स्टोरेज में, मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने का फ़ॉर्मैट चुनता है. मेटाडेटा एन्क्रिप्शन से जुड़ा दस्तावेज़ देखें.

Android 10 या उससे पहले के वर्शन वाले डिवाइसों पर, इन प्रॉपर्टी का इस्तेमाल करें:

• ro.crypto.volume.contents_mode, कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करने का मोड चुनता है. यह कोलन से अलग किए गए ro.crypto.volume.options के पहले फ़ील्ड के बराबर है.
• ro.crypto.volume.filenames_mode, फ़ाइल के नाम को एन्क्रिप्ट (सुरक्षित) करने का तरीका चुनता है. यह ro.crypto.volume.options कोलन से अलग किए गए दूसरे फ़ील्ड के बराबर है. हालांकि, Android 10 या इससे पहले के वर्शन के साथ लॉन्च होने वाले डिवाइसों पर डिफ़ॉल्ट रूप से aes-256-heh है. ज़्यादातर डिवाइसों पर, इसे साफ़ तौर पर बदलकर aes-256-cts पर सेट करना होगा.
• ro.crypto.fde_algorithm और ro.crypto.fde_sector_size, डिवाइस के स्टोरेज के तौर पर सेट अप किए गए स्टोरेज में, मेटाडेटा एन्क्रिप्शन का फ़ॉर्मैट चुनें. मेटाडेटा एन्क्रिप्शन से जुड़ा दस्तावेज़ देखें.

चेतावनी: Android 10 या उससे पहले के वर्शन वाले डिवाइसों पर, डिफ़ॉल्ट रूप से फ़ाइल के नाम को एन्क्रिप्ट करने का मोड, ज़्यादातर डिवाइसों पर काम नहीं करता था. यह मोड, डिवाइस के स्टोरेज पर काम करने वाले स्टोरेज के डिफ़ॉल्ट मोड से अलग होता है. इसलिए, ऐसे डिवाइसों पर, इसे साफ़ तौर पर बदला जाना चाहिए. आम तौर पर, इसे aes-256-cts में बदला जाता है.

Keymaster के साथ इंटिग्रेट करना

Keymaster HAL को early_hal क्लास के हिस्से के तौर पर शुरू किया जाना चाहिए. ऐसा इसलिए है, क्योंकि एफ़बीई के लिए ज़रूरी है कि post-fs-data बूट फ़ेज़ के दौरान, Keymaster अनुरोधों को मैनेज करने के लिए तैयार हो. vold, शुरुआती कुंजियों को तब सेट अप करता है.

डायरेक्ट्री को शामिल न करना

init, सिस्टम DE कुंजी को /data की सभी टॉप लेवल डायरेक्ट्री पर लागू करता है. हालांकि, इसमें वे डायरेक्ट्री शामिल नहीं होती हैं जिन्हें एन्क्रिप्ट (सुरक्षित) न किया गया हो. जैसे, ऐसी डायरेक्ट्री जिसमें सिस्टम DE कुंजी और उपयोगकर्ता CE या DE डायरेक्ट्री शामिल हों. एन्क्रिप्शन पासकोड, फिर से लागू होते हैं और सबडायरेक्ट्री से बदले नहीं जा सकते.

Android 11 और उसके बाद के वर्शन में, init डायरेक्ट्री पर लागू होने वाली कुंजी को, init स्क्रिप्ट में mkdir कमांड के encryption=<action> आर्ग्युमेंट से कंट्रोल किया जा सकता है. <action> की संभावित वैल्यू, Android init language के लिए README में दी गई हैं.

Android 10 में, init को एन्क्रिप्ट करने की कार्रवाइयों को इन जगहों पर हार्डकोड किया गया था:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 और उससे पहले के वर्शन में, जगह की जानकारी:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

इसके लिए उचित इस्तेमाल का उदाहरण सिर्फ़ लेगसी ओटीए की क्षमताओं के साथ किया जा सकता है.

सिस्टम ऐप्लिकेशन में डायरेक्ट बूट की सुविधा का इस्तेमाल करें

ऐप्लिकेशन को डायरेक्ट बूट के बारे में जानकारी देना

सिस्टम ऐप्लिकेशन को तेज़ी से माइग्रेट करने के लिए, दो नए एट्रिब्यूट जोड़े गए हैं. इन्हें ऐप्लिकेशन के लेवल पर सेट किया जा सकता है. defaultToDeviceProtectedStorage एट्रिब्यूट सिर्फ़ सिस्टम ऐप्लिकेशन के लिए उपलब्ध है. directBootAware एट्रिब्यूट सभी के लिए उपलब्ध है.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

ऐप्लिकेशन के लेवल पर directBootAware एट्रिब्यूट की मदद से, ऐप्लिकेशन के सभी कॉम्पोनेंट को 'एन्क्रिप्ट (सुरक्षित) करने का तरीका 'जानकारी है' के तौर पर मार्क किया जाता है.

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

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

• Context.createCredentialProtectedStorageContext()
• Context.isCredentialProtectedStorage()

एक से ज़्यादा उपयोगकर्ताओं के लिए काम करना

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

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

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

वर्क प्रोफ़ाइल के हर यूज़र आईडी के लिए दो कुंजियां भी मिलती हैं: DE और CE. वर्क चैलेंज पूरा होने पर, प्रोफ़ाइल का उपयोगकर्ता अनलॉक हो जाता है. साथ ही, टीईई में मौजूद Keymaster, प्रोफ़ाइल की टीईई कुंजी दे सकता है.

अपडेट मैनेज करना

रिकवरी पार्टीशन, उपयोगकर्ता डेटा वाले पार्टीशन पर, डीई से सुरक्षित स्टोरेज को ऐक्सेस नहीं कर पा रहा है. हमारा सुझाव है कि एफ़बीई लागू करने वाले डिवाइसों में, A/B सिस्टम अपडेट का इस्तेमाल करके ओटीए की सुविधा काम करे. ओटीए को सामान्य कार्रवाई के दौरान लागू किया जा सकता है. इसलिए, एन्क्रिप्ट (सुरक्षित) की गई ड्राइव का डेटा ऐक्सेस करने के लिए, रिकवरी की ज़रूरत नहीं है.

लेगसी ओटीए सलूशन का इस्तेमाल करते समय, जिसमें userdata पार्टिशन में ओटीए फ़ाइल को ऐक्सेस करने के लिए रिकवरी की ज़रूरत होती है:

1. userdata पार्टीशन में, टॉप-लेवल डायरेक्ट्री (उदाहरण के लिए, misc_ne) बनाएं.
2. इस टॉप-लेवल डायरेक्ट्री को अनक्रिप्ट (सुरक्षित नहीं) किया गया है. इसे क्रिप्ट (सुरक्षित) करने के लिए, डायरेक्ट्री को बाहर रखना देखें.
3. ओटीए पैकेज होल्ड करने के लिए, टॉप लेवल डायरेक्ट्री में एक डायरेक्ट्री बनाएं.
4. इस डायरेक्ट्री और उसके कॉन्टेंट के ऐक्सेस को कंट्रोल करने के लिए, SELinux नियम और फ़ाइल कॉन्टेक्स्ट जोड़ें. सिर्फ़ ओटीए अपडेट पाने वाली प्रोसेस या ऐप्लिकेशन के पास इस डायरेक्ट्री में मौजूद डेटा को पढ़ने और उसमें बदलाव करने की अनुमति होनी चाहिए. किसी दूसरे ऐप्लिकेशन या प्रोसेस के पास इस डायरेक्ट्री का ऐक्सेस नहीं होना चाहिए.

पुष्टि करें

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

अगर डिवाइस में Android 11 या उसके बाद वाला वर्शन चल रहा है, तो vts_kernel_encryption_test भी चलाएं:

atest vts_kernel_encryption_test

या:

vts-tradefed run vts -m vts_kernel_encryption_test

इसके अलावा, डिवाइस बनाने वाली कंपनियां नीचे बताए गए मैन्युअल तरीके से भी जांच कर सकती हैं. जिस डिवाइस पर एफ़बीई की सुविधा चालू है उस पर यह तरीका अपनाएं:

• देखें कि ro.crypto.state मौजूद है या नहीं
  • पक्का करें कि ro.crypto.state को एन्क्रिप्ट (सुरक्षित) किया गया हो
• देखें कि ro.crypto.type मौजूद है या नहीं
  • पक्का करें कि ro.crypto.type को file पर सेट किया गया हो

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

adb root; adb shell ls /data/user/10

अन्य डिवाइसों (ज़्यादातर ऐसे डिवाइस जो वाहन से जुड़े नहीं हैं) पर, मुख्य उपयोगकर्ता को उपयोगकर्ता 0 कहा जाता है. इसलिए, यह तरीका अपनाएं:

adb root; adb shell ls /data/user/0

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

डिवाइस बनाने वाली कंपनियों को अपने डिवाइसों या कोर पर, fscrypt के लिए अपस्ट्रीम Linux टेस्ट चलाने का सुझाव भी दिया जाता है. ये टेस्ट, फ़ाइल सिस्टम के xfstests टेस्ट सुइट का हिस्सा हैं. हालांकि, Android पर इन अपस्ट्रीम टेस्ट का आधिकारिक तौर पर इस्तेमाल नहीं किया जा सकता.

AOSP को लागू करने की जानकारी

इस सेक्शन में, AOSP को लागू करने के बारे में जानकारी दी गई है. साथ ही, फ़ाइल के आधार पर एन्क्रिप्शन करने के तरीके के बारे में भी बताया गया है. डिवाइस बनाने वाली कंपनियों को अपने डिवाइसों पर FBE और Direct बूट को इस्तेमाल करने के लिए, यहां कोई बदलाव करने की ज़रूरत नहीं होनी चाहिए.

fscrypt एन्क्रिप्शन

AOSP में, "fscrypt" एन्क्रिप्शन का इस्तेमाल किया जाता है. यह एन्क्रिप्शन, कर्नेल में ext4 और f2fs के साथ काम करता है. आम तौर पर, इसे इनके लिए कॉन्फ़िगर किया जाता है:

• XTS मोड में AES-256 का इस्तेमाल करके, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करना
• CBC-CTS मोड में, AES-256 की मदद से फ़ाइल के नाम एन्क्रिप्ट (सुरक्षित) करें

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

fscrypt एन्क्रिप्शन नीतियों के दो वर्शन का समर्थन करता है: वर्शन 1 और वर्शन 2. पहला वर्शन अब काम नहीं करता. साथ ही, Android 11 और इसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों के लिए, सीडीडी की ज़रूरी शर्तें सिर्फ़ दूसरे वर्शन के साथ काम करती हैं. एन्क्रिप्शन की वर्शन 2 की नीतियां, उपयोगकर्ता के स्पेस से दी गई कुंजियों से असल एन्क्रिप्शन कुंजियां पाने के लिए, HKDF-SHA512 का इस्तेमाल करती हैं.

fscrypt के बारे में ज़्यादा जानकारी के लिए, अपस्ट्रीम कर्नेल का दस्तावेज़ देखें.

स्टोरेज क्लास

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

स्टोरेज क्लास	ब्यौरा	निर्देशिकाएं
एन्क्रिप्शन रहित	/data में मौजूद डायरेक्ट्री, जिन्हें FBE से सुरक्षित करने की ज़रूरत नहीं है या नहीं किया जा सकता. मेटाडेटा एन्क्रिप्शन का इस्तेमाल करने वाले डिवाइसों पर, ये डायरेक्ट्री पूरी तरह से अनएन्क्रिप्ट नहीं होतीं. इसके बजाय, इन्हें मेटाडेटा एन्क्रिप्शन पासकोड से सुरक्षित किया जाता है. यह पासकोड, सिस्टम डीई के बराबर होता है.	/data/apex, जिसमें /data/apex/decompressed और /data/apex/ota_reserved शामिल नहीं हैं, जो सिस्टम DE हैं /data/lost+found /data/preloads /data/unencrypted वे सभी डायरेक्ट्री, जिनकी सबडायरेक्ट्री अलग-अलग FBE कुंजियों का इस्तेमाल करती हैं. उदाहरण के लिए, हर /data/user/${user_id} डायरेक्ट्री, हर उपयोगकर्ता के लिए एक कुंजी का इस्तेमाल करती है. इसलिए, /data/user खुद किसी कुंजी का इस्तेमाल नहीं करता.
सिस्टम DE	डिवाइस पर एन्क्रिप्ट (सुरक्षित) किया गया डेटा, जो किसी खास उपयोगकर्ता से जुड़ा न हो	/data/apex/decompressed /data/apex/ota_reserved /data/app /data/misc /data/system /data/vendor /data की दूसरी सभी सबडायरेक्ट्री, जिनके बारे में इस टेबल में, एक अलग क्लास के तौर पर नहीं बताया गया है
हर बूट के हिसाब से	कुछ समय के लिए काम करने वाली सिस्टम फ़ाइलें, जिन्हें रीबूट करने के बाद भी सेव रखने की ज़रूरत नहीं होती	/data/per_boot
उपयोगकर्ता सीई (इंटरनल)	डिवाइस के स्टोरेज में, हर उपयोगकर्ता के क्रेडेंशियल से एन्क्रिप्ट (सुरक्षित) किया गया डेटा	/data/data (/data/user/0 का उपनाम) /data/media/${user_id} /data/misc_ce/${user_id} /data/system_ce/${user_id} /data/user/${user_id} /data/vendor_ce/${user_id}
उपयोगकर्ता DE (आंतरिक)	डिवाइस के इंटरनल स्टोरेज में, हर उपयोगकर्ता के लिए एन्क्रिप्ट (सुरक्षित) किया गया डेटा	/data/misc_de/${user_id} /data/system_de/${user_id} /data/user_de/${user_id} /data/vendor_de/${user_id}
उपयोगकर्ता के लिए सीई (इस्तेमाल किया जा सकता है)	डिवाइस के स्टोरेज के लिए, हर उपयोगकर्ता के क्रेडेंशियल में एन्क्रिप्ट (सुरक्षित) किया गया डेटा	/mnt/expand/${volume_uuid}/media/${user_id} /mnt/expand/${volume_uuid}/misc_ce/${user_id} /mnt/expand/${volume_uuid}/user/${user_id}
User DE (adoptable)	डिवाइस में सेव किए गए डेटा को एन्क्रिप्ट (सुरक्षित) करने की सुविधा वाले स्टोरेज में, हर उपयोगकर्ता का डेटा	/mnt/expand/${volume_uuid}/misc_de/${user_id} /mnt/expand/${volume_uuid}/user_de/${user_id}

डिजिटल बटन को स्टोर करने और सुरक्षा देने की सुविधा

सभी एफ़बीई कुंजियों को vold मैनेज करता है और उन्हें डिस्क में एन्क्रिप्ट (सुरक्षित) करके सेव किया जाता है. हालांकि, हर बूट की कुंजी को छोड़कर, जो बिलकुल भी सेव नहीं की जाती है. नीचे दी गई टेबल में उन जगहों की सूची दी गई है जहां अलग-अलग एफ़बीई कुंजियां सेव की गई हैं:

कुंजी का प्रकार	मुख्य जगह	मुख्य जगह की स्टोरेज क्लास
सिस्टम डीई पासकोड	/data/unencrypted	एन्क्रिप्शन रहित
उपयोगकर्ता के लिए सीई (इंटरनल) कुंजियां	/data/misc/vold/user_keys/ce/${user_id}	सिस्टम DE
उपयोगकर्ता डीई (इंटरनल) कुंजियां	/data/misc/vold/user_keys/de/${user_id}	सिस्टम DE
उपयोगकर्ता के लिए सीई (अपॉइंट की जा सकने वाली) कुंजियां	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	उपयोगकर्ता सीई (इंटरनल)
उपयोगकर्ता के लिए डीई (स्वीकार की जा सकने वाली) कुंजियां	/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}	उपयोगकर्ता DE (इंटरनल)

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

vold सभी FBE कुंजियों पर एन्क्रिप्शन की एक लेयर भी लागू करता है. डिवाइस के स्टोरेज के लिए CE कुंजियों के अलावा, हर कुंजी को AES-256-GCM की मदद से एन्क्रिप्ट (सुरक्षित) किया जाता है. इसके लिए, उसे अपनी कीस्टोर कुंजी का इस्तेमाल किया जाता है. यह कुंजी, टीईई के बाहर नहीं दिखती. इससे यह पक्का हो जाता है कि एफ़बीई कुंजियों को तब तक अनलॉक नहीं किया जा सकता जब तक कि किसी भरोसेमंद ऑपरेटिंग सिस्टम को चालू न किया गया हो, जैसा कि वेरिफ़ाइड बूट ने लागू किया है. Keystore कुंजी के लिए भी रोलबैक के लिए प्रतिरोध का अनुरोध किया जाता है. इससे उन डिवाइसों पर एफ़बीई कुंजियों को सुरक्षित तरीके से मिटाया जा सकता है जहां Keymaster, रोलबैक के लिए प्रतिरोध की सुविधा देता है. अगर रोलबैक रेज़िस्टेंस की सुविधा उपलब्ध नहीं है, तो secdiscardable फ़ाइल में सेव किए गए 16,384 रैंडम बाइट के SHA-512 हैश का इस्तेमाल, पासकोड के साथ सेव की गई ऐप्लिकेशन आईडी टैग के तौर पर किया जाता है. एफ़बीई कुंजी वापस पाने के लिए, इन सभी बाइट को वापस पाना ज़रूरी है.

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

ऐसा करने के लिए, vold उपयोगकर्ता के सिंथेटिक पासवर्ड से मिली एईएस-256-जीसीएम पासकोड का इस्तेमाल करके, इंटरनल स्टोरेज के लिए हर सीई पासकोड को एन्क्रिप्ट करता है. सिंथेटिक पासवर्ड, एन्क्रिप्शन के लिए इस्तेमाल होने वाला ऐसा पासवर्ड होता है जिसे बदला नहीं जा सकता. यह पासवर्ड, हर उपयोगकर्ता के लिए अलग-अलग और रैंडम तरीके से जनरेट होता है. system_server में मौजूद LockSettingsService, सिंथेटिक पासवर्ड और उसे सुरक्षित करने के तरीकों को मैनेज करता है.

एआई से जनरेट किए गए पासवर्ड को एलएसकेएफ़ की मदद से सुरक्षित करने के लिए, LockSettingsService सबसे पहले एलएसकेएफ़ को scrypt से पास करके स्ट्रेच करता है. इसके लिए, वह करीब 25 मिलीसेकंड का समय और करीब 2 एमबी का मेमोरी इस्तेमाल करता है. LSKF आम तौर पर छोटे होते हैं, इसलिए यह चरण आम तौर पर ज़्यादा सुरक्षा नहीं देता है. सुरक्षा की मुख्य लेयर, सुरक्षित एलिमेंट (एसई) या टीईई की मदद से तय की गई दर है. इस बारे में यहां बताया गया है.

अगर डिवाइस में सेक्‍यूर एलिमेंट (एसई) है, तो LockSettingsService Weaver HAL का इस्तेमाल करके, स्ट्रेच किए गए एलएसकेएफ़ को एसई में सेव किए गए, हाई-एंट्रॉपी वाले रैंडम सीक्रेट से मैप करता है. इसके बाद, LockSettingsService सिंथेटिक पासवर्ड को दो बार एन्क्रिप्ट करता है: पहला, स्ट्रेच किए गए LSKF और वीवर सीक्रेट से बनी सॉफ़्टवेयर कुंजी से. दूसरा, बिना पुष्टि वाली कीस्टोर कुंजी से. इससे एलएसकेएफ़ के अनुमानों के लिए एसई की मदद से लागू होने वाली दर सीमा तय होती है.

अगर डिवाइस में SE नहीं है, तो LockSettingsService इसके बजाय, गेटकीपर पासवर्ड के तौर पर, स्ट्रेच किए गए LSKF का इस्तेमाल करता है. LockSettingsService इसके बाद, सिंथेटिक पासवर्ड को दो बार एन्क्रिप्ट करता है: पहला, स्ट्रेच की गई LSKF और सुरक्षित रूप से हटाई जा सकने वाली फ़ाइल के हैश से मिली सॉफ़्टवेयर कुंजी से और दूसरा, Gatekeeper के रजिस्ट्रेशन से जुड़ी पुष्टि करने वाली कुंजी से. इससे टीईई के नियमों के तहत, LSKF के अनुमानों की सीमा तय करने में मदद मिलती है.

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