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

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

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

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

डायरेक्ट बूट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिपेंडेंसी

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

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

लागू करना

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

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

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

CONFIG_FS_ENCRYPTION=y

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

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

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

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

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

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

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

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

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

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

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

अगर इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल नहीं किया जा रहा है, तो ज़्यादातर डिवाइसों के लिए सुझाई गई सेटिंग fileencryption=aes-256-xts है. अगर इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल किया जा रहा है, तो ज़्यादातर डिवाइसों के लिए सुझाई गई सेटिंग fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized है. इसके अलावा, fileencryption=::inlinecrypt_optimized का इस्तेमाल भी किया जा सकता है. जिन डिवाइसों में एईएस ऐक्सेलरेटर नहीं है उनमें एईएस के बजाय 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 और इससे पुराने वर्शन के साथ लॉन्च किए गए डिवाइसों पर, fileencryption=ice फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने के मोड के तौर पर fileencryption=ice का इस्तेमाल किया जा सकता है.FSCRYPT_MODE_PRIVATE Android के सामान्य कर्नल में यह मोड लागू नहीं किया गया है. हालांकि, वेंडर इसे कस्टम कर्नल पैच का इस्तेमाल करके लागू कर सकते हैं. इस मोड से डिस्क पर सेव किया गया फ़ॉर्मैट, वेंडर के हिसाब से होता था. Android 11 या इसके बाद के वर्शन के साथ लॉन्च किए गए डिवाइसों पर, इस मोड का इस्तेमाल नहीं किया जा सकता. इसके बजाय, एन्क्रिप्शन के स्टैंडर्ड फ़ॉर्मैट का इस्तेमाल करना होगा.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 और इससे पहले के वर्शन में, यह फ़ोल्डर यहां मौजूद था:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

इस सुविधा का इस्तेमाल सिर्फ़ लेगसी ओटीए की सुविधाओं के साथ किया जा सकता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Validation

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

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

atest vts_kernel_encryption_test

या:

vts-tradefed run vts -m vts_kernel_encryption_test

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

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

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

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

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

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

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

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

AOSP में लागू करने से जुड़ी जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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