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

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

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

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

डायरेक्ट बूट

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

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

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

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

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

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

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

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

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

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

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

• AOSP डायलर (packages/apps/Dialer)
• डेस्क क्लॉक (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Settings ऐप्लिकेशन (पैकेज/ऐप्लिकेशन/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

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

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

डिपेंडेंसी

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

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

लागू करना

सबसे पहले, डायरेक्ट बूट डेवलपर दस्तावेज़ के मुताबिक, अलार्म घड़ी, फ़ोन, और सुलभता सुविधाओं जैसे ऐप्लिकेशन को 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

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

CONFIG_MMC_CRYPTO=y

फ़ाइल के आधार पर एन्क्रिप्शन की सुविधा चालू करना

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

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

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 होगी.
• flags पैरामीटर, Android 11 में नया है. यह + वर्ण से अलग किए गए फ़्लैग की सूची है. ये फ़्लैग इस्तेमाल किए जा सकते हैं:
  • v1 फ़्लैग, एन्क्रिप्शन (सुरक्षित) करने की नीति के वर्शन 1 को चुनता है; v2 फ़्लैग, एन्क्रिप्शन (सुरक्षित) करने की नीति के वर्शन 2 को चुनता है. एन्क्रिप्शन की नीति के वर्शन 2 में, कुंजी बनाने वाले फ़ंक्शन का इस्तेमाल किया जाता है. यह ज़्यादा सुरक्षित और सुविधाजनक होता है. डिफ़ॉल्ट रूप से, अगर डिवाइस को Android 11 या उसके बाद के वर्शन पर लॉन्च किया गया है, तो ro.product.first_api_level के हिसाब से v2 लागू होता है. अगर डिवाइस को Android 10 या उससे पहले के वर्शन पर लॉन्च किया गया है, तो v1 लागू होता है.
  • inlinecrypt_optimized फ़्लैग, एन्क्रिप्शन का ऐसा फ़ॉर्मैट चुनता है जो इनलाइन एन्क्रिप्शन हार्डवेयर के लिए ऑप्टिमाइज़ किया गया हो. यह हार्डवेयर, बड़ी संख्या में कुंजियों को सही तरीके से मैनेज नहीं करता. यह ऐसा करने के लिए, हर सीई या डीई कुंजी के लिए, हर फ़ाइल के बजाय सिर्फ़ एक फ़ाइल कॉन्टेंट एन्क्रिप्शन कुंजी का इस्तेमाल करता है. इसके हिसाब से, आईवी (इनिशियलाइज़ेशन वेक्टर) जनरेशन में बदलाव किया जाता है.
  • emmc_optimized फ़्लैग, inlinecrypt_optimized से मिलता-जुलता है. हालांकि, यह आईवी जनरेट करने का एक ऐसा तरीका भी चुनता है जो आईवी को 32 बिट तक सीमित करता है. इस फ़्लैग का इस्तेमाल सिर्फ़ ऐसे इनलाइन एन्क्रिप्शन हार्डवेयर पर किया जाना चाहिए जो जेडीईसी eMMC v5.2 स्पेसिफ़िकेशन के मुताबिक हो. इसलिए, यह सिर्फ़ 32-बिट आईवी के साथ काम करता है. इनलाइन एन्क्रिप्शन वाले अन्य हार्डवेयर पर, इसके बजाय inlinecrypt_optimized का इस्तेमाल करें. इस फ़्लैग का इस्तेमाल, यूएफ़एस (यूनिफ़ाइड फ़ाइल सिस्टम) पर कभी नहीं किया जाना चाहिए. यूएफ़एस स्पेसिफ़िकेशन में, 64-बिट आईवी का इस्तेमाल करने की अनुमति है.
  • हार्डवेयर से सुरक्षित की गई कुंजियों के साथ काम करने वाले डिवाइसों पर, wrappedkey_v0 फ़्लैग से एफ़बीई के लिए, हार्डवेयर से सुरक्षित की गई कुंजियों का इस्तेमाल करने की सुविधा चालू होती है. इसका इस्तेमाल सिर्फ़ 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) है. जिन डिवाइसों में एईएस (AES) एक्सेलेरेशन का कोई भी तरीका नहीं है उन पर 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 फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने के मोड के इस्तेमाल के बारे में बताने के लिए भी स्वीकार किया जाता है.FSCRYPT_MODE_PRIVATE Android के सामान्य कर्नेल में यह मोड लागू नहीं किया गया है. हालांकि, वेंडर कस्टम कर्नेल पैच का इस्तेमाल करके, इसे लागू कर सकते हैं. इस मोड से डिस्क पर जनरेट होने वाला फ़ॉर्मैट, वेंडर के हिसाब से होता था. Android 11 या इसके बाद के वर्शन वाले डिवाइसों पर, इस मोड का इस्तेमाल नहीं किया जा सकता. इसके बजाय, स्टैंडर्ड एन्क्रिप्शन फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है.

डिफ़ॉल्ट रूप से, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने के लिए, 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

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

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

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, डिवाइस के स्टोरेज के तौर पर सेट अप किए गए स्टोरेज में, मेटाडेटा एन्क्रिप्शन का फ़ॉर्मैट चुनें. मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने के बारे में दस्तावेज़ देखें.

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

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

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

init, /data की सभी टॉप-लेवल डायरेक्ट्री पर सिस्टम डीई पासकोड लागू करता है. हालांकि, उन डायरेक्ट्री पर ऐसा नहीं किया जाता जिन्हें डिक्रिप्ट नहीं किया जाना चाहिए. जैसे, वह डायरेक्ट्री जिसमें सिस्टम डीई पासकोड और उपयोगकर्ता सीई या डीई डायरेक्ट्री शामिल होती हैं. एन्क्रिप्शन पासकोड, फिर से लागू होते हैं और उन्हें सबडायरेक्ट्री से बदला नहीं जा सकता.

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

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

• 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 और EncryptionTest.

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

atest vts_kernel_encryption_test

या:

vts-tradefed run vts -m vts_kernel_encryption_test

इसके अलावा, डिवाइस बनाने वाली कंपनियां ये मैन्युअल टेस्ट कर सकती हैं. FBE की सुविधा चालू होने पर, डिवाइस पर:

• देखें कि 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 को लागू करने के बारे में जानकारी दी गई है. साथ ही, फ़ाइल के आधार पर एन्क्रिप्शन करने के तरीके के बारे में भी बताया गया है. डिवाइस बनाने वाली कंपनियों को अपने डिवाइसों पर एफ़बीई और डायरेक्ट बूट का इस्तेमाल करने के लिए, यहां कोई बदलाव करने की ज़रूरत नहीं है.

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

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

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

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

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

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

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

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

स्टोरेज क्लास	ब्यौरा	निर्देशिकाएं
एन्क्रिप्शन रहित	/data में मौजूद ऐसी डायरेक्ट्री जिन्हें एफ़बीई से सुरक्षित नहीं किया जा सकता या जिन्हें सुरक्षित करने की ज़रूरत नहीं है. मेटाडेटा एन्क्रिप्शन का इस्तेमाल करने वाले डिवाइसों पर, ये डायरेक्ट्री पूरी तरह से अनएन्क्रिप्ट नहीं होतीं. इसके बजाय, इन्हें मेटाडेटा एन्क्रिप्शन पासकोड से सुरक्षित किया जाता है. यह पासकोड, सिस्टम डीई के बराबर होता है.	/data/apex, जिसमें /data/apex/decompressed और /data/apex/ota_reserved शामिल नहीं हैं, जो सिस्टम DE हैं /data/lost+found /data/preloads /data/unencrypted वे सभी डायरेक्ट्री जिनकी सबडायरेक्ट्री, अलग-अलग एफ़बीई पासकोड का इस्तेमाल करती हैं. उदाहरण के लिए, हर /data/user/${user_id} डायरेक्ट्री, हर उपयोगकर्ता के लिए एक कुंजी का इस्तेमाल करती है. इसलिए, /data/user खुद किसी कुंजी का इस्तेमाल नहीं करता.
System 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}	System DE
उपयोगकर्ता डीई (इंटरनल) कुंजियां	/data/misc/vold/user_keys/de/${user_id}	System DE
उपयोगकर्ता के लिए सीई (अपॉइंट की जा सकने वाली) कुंजियां	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	उपयोगकर्ता सीई (इंटरनल)
उपयोगकर्ता के लिए डीई (स्वीकार की जा सकने वाली) कुंजियां	/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}	उपयोगकर्ता DE (इंटरनल)

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

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

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

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

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

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

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

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