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

Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

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

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

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

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

डायरेक्ट बूट

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

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

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

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

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

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

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

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

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

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

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

लागू करना

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

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

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-बिट आईवी के साथ काम करता है. इनलाइन एन्क्रिप्शन वाले अन्य हार्डवेयर पर, inlinecrypt_optimized का इस्तेमाल करें. इस फ़्लैग का इस्तेमाल, यूएफ़एस पर आधारित स्टोरेज पर कभी नहीं किया जाना चाहिए. यूएफ़एस की खास जानकारी में, 64-बिट आईवी के इस्तेमाल की अनुमति है.
- हार्डवेयर-रैप्ड इनलाइन एन्क्रिप्शन कुंजियों के साथ काम करने वाले डिवाइसों पर, एफ़बीई कुंजियों को हार्डवेयर-रैप्ड बनाया जा सकता है. इसके लिए, wrappedkey या wrappedkey_v0 फ़्लैग जोड़ना होगा. wrappedkey, आधुनिक वर्शन है; wrappedkey_v0 का इस्तेमाल सिर्फ़ उन डिवाइसों पर किया जाना चाहिए जो wrappedkey के साथ काम नहीं करते या जो पहले से ही wrappedkey_v0 के साथ लॉन्च किए गए हैं. ज़्यादा जानकारी के लिए, रैप की गई कुंजियां चालू करना लेख पढ़ें.
- dusize_4k फ़्लैग, एन्क्रिप्ट (सुरक्षित) किए गए डेटा की यूनिट का साइज़ 4,096 बाइट पर सेट करता है. भले ही, फ़ाइल सिस्टम के ब्लॉक का साइज़ 4,096 बाइट न हो. एन्क्रिप्शन डेटा यूनिट का साइज़, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने की बारीकी को दिखाता है. यह फ़्लैग, Android 15 से उपलब्ध है. इस फ़्लैग का इस्तेमाल सिर्फ़ इनलाइन एन्क्रिप्शन हार्डवेयर को चालू करने के लिए किया जाना चाहिए. यह हार्डवेयर, 4,096 बाइट से बड़ी डेटा यूनिट के साथ काम नहीं करता. यह ऐसे डिवाइस पर काम करता है जिसमें पेज का साइज़ 4,096 बाइट से ज़्यादा होता है और जो f2fs फ़ाइल सिस्टम का इस्तेमाल करता है.

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

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

ध्यान दें:

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

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

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

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

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

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

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

Context.createCredentialProtectedStorageContext()
Context.isCredentialProtectedStorage()

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

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

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

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

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

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

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

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

userdata पार्टिशन में, टॉप-लेवल डायरेक्ट्री (उदाहरण के लिए, misc_ne) बनाएं.
इस टॉप-लेवल डायरेक्ट्री को एन्क्रिप्ट (सुरक्षित) न करने के लिए कॉन्फ़िगर करें. इसके लिए, डायरेक्ट्री को एन्क्रिप्ट (सुरक्षित) न करना देखें.
ओटीए पैकेज सेव करने के लिए, टॉप-लेवल डायरेक्ट्री में एक डायरेक्ट्री बनाएं.
इस डायरेक्ट्री और इसके कॉन्टेंट के ऐक्सेस को कंट्रोल करने के लिए, 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 एन्क्रिप्शन

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

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

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

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

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

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

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

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

कुंजी का स्टोरेज और सुरक्षा

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

कुंजी का प्रकार	मुख्य जगह	कुंजी की जगह की स्टोरेज क्लास
सिस्टम डीई कुंजी	`/data/unencrypted`	एन्क्रिप्ट (सुरक्षित) नहीं है
उपयोगकर्ता की सीई (इंटरनल) कुंजियां	`/data/misc/vold/user_keys/ce/${user_id}`	सिस्टम DE
उपयोगकर्ता DE (इंटरनल) कुंजियां	`/data/misc/vold/user_keys/de/${user_id}`	सिस्टम DE
उपयोगकर्ता की सीई (अडॉप्टेबल) कुंजियां	`/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}`	User DE (internal)

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

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

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

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

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

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

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

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