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

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

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

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

डायरेक्ट बूट

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

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

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

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

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

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

Ext4 और F2FS फ़ाइल सिस्टम पर, अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका को पूरी तरह से लागू करने की सुविधा, Android ओपन सोर्स प्रोजेक्ट (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 मेनिफ़ेस्ट एट्रिब्यूट का इस्तेमाल करते हैं

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

डिपेंडेंसी

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

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

लागू करना

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

कर्नेल के लिए सहायता

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

CONFIG_FS_ENCRYPTION=y

पुराने कर्नेल के लिए, अगर आपके डिवाइस का userdata फ़ाइल सिस्टम Ext4 है, तो CONFIG_EXT4_ENCRYPTION=y का इस्तेमाल करें. अगर आपके डिवाइस का 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

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

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

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

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

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

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

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

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

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

कई लोगों के लिए एक साथ इस्तेमाल करने की सुविधा

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

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

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

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

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

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

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

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

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

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

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

एओएसपी को लागू करने से जुड़ी जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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