साल 2026 से, हम अपने ट्रंक स्टेबल डेवलपमेंट मॉडल के साथ अलाइन होने के लिए, दूसरी और चौथी तिमाही में AOSP पर सोर्स कोड पब्लिश करेंगे. इससे यह पक्का किया जा सकेगा कि प्लैटफ़ॉर्म, पूरे सिस्टम के लिए स्थिर बना रहे. हमारा सुझाव है कि AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. android-latest-release मेनिफ़ेस्ट ब्रांच, हमेशा AOSP पर पुश की गई सबसे नई रिलीज़ का रेफ़रंस देगी. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका

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

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

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

डायरेक्ट बूट

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

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

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

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

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

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

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

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

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

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

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

AOSP डायलर (packages/apps/Dialer)
Desk Clock (packages/apps/DeskClock)
LatinIME (packages/inputmethods/LatinIME)*
सेटिंग ऐप्लिकेशन (packages/apps/Settings)*
SystemUI (frameworks/base/packages/SystemUI)*

* defaultToDeviceProtectedStorage manifest एट्रिब्यूट का इस्तेमाल करने वाले सिस्टम ऐप्लिकेशन

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

डिपेंडेंसी

FBE के AOSP वर्शन को सुरक्षित तरीके से इस्तेमाल करने के लिए, डिवाइस को इन ज़रूरी शर्तों को पूरा करना होगा:

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

लागू करना

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

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

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

CONFIG_FS_ENCRYPTION=y

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

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

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

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

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

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने की सुविधा चालू करना

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

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

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. अगर कोई वैल्यू तय नहीं की गई है, तो डिफ़ॉल्ट वैल्यू aes-256-cts होती है. हालांकि, अगर contents_encryption_mode aes-256-xts है, तो डिफ़ॉल्ट वैल्यू adiantum होती है.contents_encryption_modeadiantum
Android 11 में नया flags पैरामीटर जोड़ा गया है. यह फ़्लैग की एक सूची है, जिसे + वर्ण से अलग किया गया है. इन फ़्लैग का इस्तेमाल किया जा सकता है:
- v1 फ़्लैग, एन्क्रिप्ट (सुरक्षित) करने की नीति के वर्शन 1 को चुनता है. वहीं, v2 फ़्लैग, एन्क्रिप्ट (सुरक्षित) करने की नीति के वर्शन 2 को चुनता है. वर्शन 2 में एन्क्रिप्शन की दो नीतियां, ज़्यादा सुरक्षित और फ़्लेक्सिबल की डेरीवेशन फ़ंक्शन का इस्तेमाल करती हैं. अगर डिवाइस को Android 11 या इसके बाद के वर्शन पर लॉन्च किया गया है (ro.product.first_api_level से तय किया गया है), तो डिफ़ॉल्ट रूप से v2 का इस्तेमाल किया जाता है. अगर डिवाइस को Android 10 या इससे पहले के वर्शन पर लॉन्च किया गया है, तो डिफ़ॉल्ट रूप से v1 का इस्तेमाल किया जाता है.
- inlinecrypt_optimized फ़्लैग, एन्क्रिप्शन के ऐसे फ़ॉर्मैट को चुनता है जिसे इनलाइन एन्क्रिप्शन हार्डवेयर के लिए ऑप्टिमाइज़ किया गया है. यह हार्डवेयर, बड़ी संख्या में कुंजियों को असरदार तरीके से मैनेज नहीं करता. यह ऐसा इसलिए करता है, क्योंकि यह हर फ़ाइल के लिए एक की के बजाय, हर सीई या डीई की के लिए सिर्फ़ एक फ़ाइल कॉन्टेंट एन्क्रिप्शन की बनाता है. इसके हिसाब से, IV (इनिशियलाइज़ेशन वेक्टर) जनरेट करने की प्रोसेस में बदलाव किया जाता है.
- emmc_optimized फ़्लैग, inlinecrypt_optimized फ़्लैग जैसा ही होता है. हालांकि, यह IV जनरेट करने का ऐसा तरीका भी चुनता है जो IV को 32 बिट तक सीमित करता है. इस फ़्लैग का इस्तेमाल सिर्फ़ ऐसे इनलाइन एन्क्रिप्शन हार्डवेयर पर किया जाना चाहिए जो JEDEC eMMC v5.2 के निर्देशों का पालन करता हो. इसलिए, यह सिर्फ़ 32-बिट IV के साथ काम करता है. इनलाइन एन्क्रिप्शन की सुविधा वाले अन्य हार्डवेयर पर, इसके बजाय inlinecrypt_optimized का इस्तेमाल करें. इस फ़्लैग का इस्तेमाल, UFS पर आधारित स्टोरेज पर कभी नहीं किया जाना चाहिए. UFS स्पेसिफ़िकेशन, 64-बिट IV के इस्तेमाल की अनुमति देता है.
- हार्डवेयर से सुरक्षित इनलाइन एन्क्रिप्शन कुंजियों की सुविधा वाले डिवाइसों पर, FBE कुंजियों को हार्डवेयर से सुरक्षित बनाया जा सकता है. इसके लिए, wrappedkey या wrappedkey_v0 फ़्लैग जोड़ें. wrappedkey, Google Play Billing Library का नया वर्शन है. wrappedkey_v0 का इस्तेमाल सिर्फ़ उन डिवाइसों पर किया जाना चाहिए जिन पर wrappedkey काम नहीं करता या जिन पर wrappedkey_v0 पहले से लॉन्च किया गया है. ज़्यादा जानकारी के लिए, रैप किए गए कुंजियों को चालू करना लेख पढ़ें.
- dusize_4k फ़्लैग, एन्क्रिप्शन डेटा यूनिट के साइज़ को 4096 बाइट पर सेट करता है. ऐसा तब भी होता है, जब फ़ाइल सिस्टम ब्लॉक का साइज़ 4096 बाइट नहीं होता है. एन्क्रिप्शन डेटा यूनिट का साइज़, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने की ग्रेन्यूलैरिटी होती है. यह फ़्लैग, Android 15 से उपलब्ध है. इस फ़्लैग का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब आपको ऐसे डिवाइस पर इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल करना हो जो 4,096 बाइट से बड़ी डेटा यूनिट के साथ काम नहीं करता. साथ ही, उस डिवाइस में 4,096 बाइट से बड़ा पेज साइज़ इस्तेमाल किया जाता हो और वह 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 और इससे पुराने वर्शन के साथ लॉन्च किए गए डिवाइसों पर, fileencryption=ice फ़ाइल के कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करने के मोड के इस्तेमाल के बारे में बताने के लिए, fileencryption=ice को भी स्वीकार किया जाता है.FSCRYPT_MODE_PRIVATE Android के सामान्य कर्नल में यह मोड लागू नहीं किया गया है. हालांकि, वेंडर इसे कस्टम कर्नल पैच का इस्तेमाल करके लागू कर सकते हैं. इस मोड से डिस्क पर सेव किया गया फ़ॉर्मैट, वेंडर के हिसाब से होता था. Android 11 या इसके बाद के वर्शन पर लॉन्च होने वाले डिवाइसों में, अब इस मोड का इस्तेमाल नहीं किया जा सकता. इसके बजाय, स्टैंडर्ड एन्क्रिप्शन फ़ॉर्मैट का इस्तेमाल करना होगा.

डिफ़ॉल्ट रूप से, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करने के लिए, Linux कर्नल के क्रिप्टोग्राफ़ी एपीआई का इस्तेमाल किया जाता है. अगर आपको इसके बजाय, इनलाइन एनक्रिप्शन हार्डवेयर का इस्तेमाल करना है, तो 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 userspace के लिए एक फ़्लैग है.
अगर आपका इनलाइन एन्क्रिप्शन हार्डवेयर ठीक से काम करता है और न तो wrappedkey और न ही wrappedkey_v0 सेट है, तो डिवाइस को वाइप किए बिना, inlinecrypt माउंट विकल्प को कभी भी जोड़ा या हटाया जा सकता है. दूसरे शब्दों में कहें, तो जब तक हार्डवेयर-रैप्ड कुंजियां चालू नहीं होती हैं, तब तक inlinecrypt का असर सिर्फ़ लागू करने पर पड़ना चाहिए, न कि डिस्क पर मौजूद फ़ॉर्मैट पर. आपको डेवलपमेंट के दौरान inlinecrypt को हटाने की सुविधा की जांच करनी चाहिए, ताकि यह पुष्टि की जा सके कि आपका इनलाइन एन्क्रिप्शन हार्डवेयर सही तरीके से काम कर रहा है.

एडॉप्टेबल स्टोरेज

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

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

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

ro.crypto.volume.options (Android 11 में नया) डिवाइस के स्टोरेज के तौर पर सेट अप किए गए स्टोरेज पर, FBE एन्क्रिप्शन फ़ॉर्मैट को चुनता है. इसका सिंटैक्स, 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 पर सेट किया जाता है.

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

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

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

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

Android 11 और इसके बाद के वर्शन में, init की सुविधा को डायरेक्ट्री पर लागू करने वाली कुंजी को encryption=<action> आर्ग्युमेंट से कंट्रोल किया जा सकता है. यह आर्ग्युमेंट, init स्क्रिप्ट में mkdir कमांड के साथ इस्तेमाल किया जाता है. <action> की संभावित वैल्यू के बारे में जानकारी, Android की शुरुआती भाषा के लिए 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 एट्रिब्यूट, ऐप्लिकेशन के डिफ़ॉल्ट स्टोरेज की जगह को CE स्टोरेज के बजाय DE स्टोरेज पर रीडायरेक्ट करता है. इस फ़्लैग का इस्तेमाल करने वाले सिस्टम ऐप्लिकेशन को, डिफ़ॉल्ट जगह पर सेव किए गए सभी डेटा की सावधानीपूर्वक जांच करनी चाहिए. साथ ही, संवेदनशील डेटा के पाथ बदलकर CE स्टोरेज का इस्तेमाल करना चाहिए. इस विकल्प का इस्तेमाल करने वाले डिवाइस बनाने वाली कंपनियों को, स्टोर किए जा रहे डेटा की सावधानीपूर्वक जांच करनी चाहिए. इससे यह पक्का किया जा सकेगा कि इसमें कोई निजी जानकारी शामिल न हो.

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

Context.createCredentialProtectedStorageContext()
Context.isCredentialProtectedStorage()

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

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

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

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

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

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

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

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

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

सत्यापन

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

अगर डिवाइस में 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 पर सेट हो

इसके अलावा, टेस्टर यह पुष्टि कर सकते हैं कि बूट होने के बाद पहली बार डिवाइस को अनलॉक करने से पहले, CE स्टोरेज लॉक है. इसके लिए, userdebug या eng बिल्ड का इस्तेमाल करें. साथ ही, मुख्य उपयोगकर्ता के लिए पिन, पैटर्न या पासवर्ड सेट करें और डिवाइस को रीबूट करें. डिवाइस को अनलॉक करने से पहले, मुख्य उपयोगकर्ता के सीई स्टोरेज की जांच करने के लिए, यह निर्देश चलाएं. अगर डिवाइस में बिना ग्राफ़िक यूज़र इंटरफ़ेस वाला सिस्टम यूज़र मोड (ज़्यादातर Automotive डिवाइस) इस्तेमाल किया जाता है, तो मुख्य उपयोगकर्ता 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 और डायरेक्ट बूट का इस्तेमाल करने के लिए, यहां कोई बदलाव करने की ज़रूरत नहीं होनी चाहिए.

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

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

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

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

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

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

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

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

स्टोरेज क्लास	ब्यौरा	निर्देशिकाएं
एन्क्रिप्ट (सुरक्षित) नहीं है	`/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` खुद किसी कुंजी का इस्तेमाल नहीं करता.
सिस्टम डीई	डिवाइस पर एन्क्रिप्ट (सुरक्षित) किया गया ऐसा डेटा जो किसी खास उपयोगकर्ता से न जुड़ा हो	`/data/apex/decompressed` `/data/apex/ota_reserved` `/data/app` `/data/misc` `/data/system` `/data/vendor` `/data` की वे सभी अन्य सबडायरेक्ट्री जिनके बारे में इस टेबल में यह नहीं बताया गया है कि उनकी क्लास अलग है
हर बूट के हिसाब से	सिस्टम की ऐसी फ़ाइलें जो रीबूट होने के बाद भी मौजूद नहीं रहती हैं	`/data/per_boot`
User CE (internal)	हर उपयोगकर्ता के क्रेडेंशियल से एन्क्रिप्ट (सुरक्षित) किया गया डेटा, डिवाइस के स्टोरेज में सेव होता है	`/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}`

कुंजी को सेव करना और उसकी सुरक्षा करना

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

कुंजी का प्रकार	कुंजी की जगह	कुंजी की जगह की स्टोरेज क्लास
सिस्टम डीई कुंजी	`/data/unencrypted`	एन्क्रिप्ट (सुरक्षित) नहीं है
उपयोगकर्ता की सीई (इंटरनल) कुंजियां	`/data/misc/vold/user_keys/ce/${user_id}`	सिस्टम डीई
उपयोगकर्ता की डीई (इंटरनल) कुंजियां	`/data/misc/vold/user_keys/de/${user_id}`	सिस्टम डीई
उपयोगकर्ता के लिए उपलब्ध सीई (अपनाने योग्य) कुंजियां	`/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}`	User CE (internal)
उपयोगकर्ता के लिए उपलब्ध DE (adoptable) कुंजियां	`/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}`	उपयोगकर्ता DE (इंटरनल)

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

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

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

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

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

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

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

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