फ़ाइल-आधारित एन्क्रिप्शन

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

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

एंड्रॉइड 10 और उच्चतर के साथ लॉन्च होने वाले सभी उपकरणों को फ़ाइल-आधारित एन्क्रिप्शन का उपयोग करना आवश्यक है।

डायरेक्ट बूट

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

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

एफबीई-सक्षम डिवाइस पर, डिवाइस के प्रत्येक उपयोगकर्ता के पास अनुप्रयोगों के लिए दो भंडारण स्थान उपलब्ध हैं:

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

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

डायरेक्ट बूट एपीआई एन्क्रिप्शन-जागरूक एप्लिकेशन को इनमें से प्रत्येक क्षेत्र तक पहुंचने की अनुमति देता है। जब किसी उपयोगकर्ता के सीई स्टोरेज को लॉक स्क्रीन पर पहली बार क्रेडेंशियल दर्ज करने के जवाब में अनलॉक किया जाता है, या कार्य प्रोफ़ाइल के मामले में कार्य चुनौती प्रदान की जाती है, तो एप्लिकेशन को सूचित करने की आवश्यकता को समायोजित करने के लिए एप्लिकेशन जीवनचक्र में परिवर्तन होते हैं। एंड्रॉइड 7.0 चलाने वाले उपकरणों को इन नए एपीआई और जीवनचक्रों का समर्थन करना चाहिए, भले ही वे एफबीई लागू करें या नहीं। हालाँकि, FBE के बिना, DE और CE स्टोरेज हमेशा अनलॉक स्थिति में रहेगा।

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

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

  • टेलीफोनी सेवाएँ और डायलर
  • लॉक स्क्रीन में पासवर्ड दर्ज करने की इनपुट विधि

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

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

  • AOSP डायलर (पैकेज/ऐप्स/डायलर)
  • डेस्क घड़ी (पैकेज/ऐप्स/डेस्कक्लॉक)
  • लैटिनआईएमई (पैकेज/इनपुटमेथड्स/लैटिनआईएमई)*
  • सेटिंग्स ऐप (पैकेज/ऐप्स/सेटिंग्स)*
  • SystemUI (फ्रेमवर्क/आधार/पैकेज/SystemUI)*

* सिस्टम एप्लिकेशन जो defaultToDeviceProtectedStorage मेनिफेस्ट विशेषता का उपयोग करते हैं

एन्क्रिप्शन के प्रति जागरूक अनुप्रयोगों और सेवाओं के अधिक उदाहरण AOSP स्रोत ट्री के फ्रेमवर्क या पैकेज निर्देशिका में mangrep directBootAware कमांड चलाकर पाए जा सकते हैं।

निर्भरताएँ

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

  • Ext4 एन्क्रिप्शन या F2FS एन्क्रिप्शन के लिए कर्नेल समर्थन
  • एचएएल संस्करण 1.0 या उच्चतर के साथ कीमास्टर समर्थन । कीमास्टर 0.3 के लिए कोई समर्थन नहीं है क्योंकि यह आवश्यक क्षमताएं प्रदान नहीं करता है या एन्क्रिप्शन कुंजी के लिए पर्याप्त सुरक्षा का आश्वासन नहीं देता है।
  • DE कुंजियों के लिए सुरक्षा प्रदान करने के लिए कीमास्टर/ कीस्टोर और गेटकीपर को एक विश्वसनीय निष्पादन वातावरण (TEE) में लागू किया जाना चाहिए ताकि एक अनधिकृत OS (डिवाइस पर फ्लैश किया गया कस्टम OS) आसानी से DE कुंजियों का अनुरोध न कर सके।
  • कीमास्टर इनिशियलाइज़ेशन से जुड़े ट्रस्ट के हार्डवेयर रूट और सत्यापित बूट की आवश्यकता यह सुनिश्चित करने के लिए है कि DE कुंजियाँ किसी अनधिकृत ऑपरेटिंग सिस्टम द्वारा पहुंच योग्य नहीं हैं।

कार्यान्वयन

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

कर्नेल समर्थन

Ext4 और F2FS एन्क्रिप्शन के लिए कर्नेल समर्थन एंड्रॉइड सामान्य कर्नेल, संस्करण 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

प्रदर्शन को और बेहतर बनाने और बिजली के उपयोग को कम करने के लिए, डिवाइस निर्माता इनलाइन एन्क्रिप्शन हार्डवेयर को लागू करने पर भी विचार कर सकते हैं, जो स्टोरेज डिवाइस के रास्ते में/से डेटा को एन्क्रिप्ट/डिक्रिप्ट करता है। एंड्रॉइड सामान्य कर्नेल (संस्करण 4.14 और उच्चतर) में एक ढांचा होता है जो हार्डवेयर और विक्रेता ड्राइवर समर्थन उपलब्ध होने पर इनलाइन एन्क्रिप्शन का उपयोग करने की अनुमति देता है। इनलाइन एन्क्रिप्शन फ्रेमवर्क को निम्नलिखित कर्नेल कॉन्फ़िगरेशन विकल्प सेट करके सक्षम किया जा सकता है:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

यदि आपका डिवाइस यूएफएस-आधारित स्टोरेज का उपयोग करता है, तो इसे भी सक्षम करें:

CONFIG_SCSI_UFS_CRYPTO=y

यदि आपका डिवाइस ईएमएमसी-आधारित स्टोरेज का उपयोग करता है, तो इसे भी सक्षम करें:

CONFIG_MMC_CRYPTO=y

फ़ाइल-आधारित एन्क्रिप्शन सक्षम करना

किसी डिवाइस पर एफबीई को सक्षम करने के लिए इसे आंतरिक स्टोरेज ( userdata ) पर सक्षम करने की आवश्यकता होती है। यह स्वचालित रूप से अपनाने योग्य भंडारण पर एफबीई को भी सक्षम बनाता है; हालाँकि, यदि आवश्यक हो तो अपनाने योग्य भंडारण पर एन्क्रिप्शन प्रारूप को ओवरराइड किया जा सकता है।

आंतरिक स्टोरेज

userdata के लिए fstab लाइन के fs_mgr_flags कॉलम में विकल्प fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] जोड़कर FBE को सक्षम किया गया है। यह विकल्प आंतरिक भंडारण पर एन्क्रिप्शन प्रारूप को परिभाषित करता है। इसमें तीन कोलन-पृथक पैरामीटर शामिल हैं:

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

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

एंड्रॉइड 14 के बाद से, एईएस-एचसीटीआर2 त्वरित क्रिप्टोग्राफी निर्देशों वाले उपकरणों के लिए फ़ाइल नाम एन्क्रिप्शन का पसंदीदा तरीका है। हालाँकि, केवल नए Android कर्नेल ही AES-HCTR2 का समर्थन करते हैं। भविष्य के एंड्रॉइड रिलीज़ में, इसे फ़ाइल नाम एन्क्रिप्शन के लिए डिफ़ॉल्ट मोड बनने की योजना बनाई गई है। यदि आपके कर्नेल में AES-HCTR2 समर्थन है, तो इसे filenames_encryption_mode aes-256-hctr2 पर सेट करके फ़ाइल नाम एन्क्रिप्शन के लिए सक्षम किया जा सकता है। सबसे सरल मामले में यह fileencryption=aes-256-xts:aes-256-hctr2 के साथ किया जाएगा।

एंड्रॉइड 10 या उससे पहले के संस्करण के साथ लॉन्च होने वाले उपकरणों पर, FSCRYPT_MODE_PRIVATE फ़ाइल सामग्री एन्क्रिप्शन मोड के उपयोग को निर्दिष्ट करने के लिए fileencryption=ice को भी स्वीकार किया जाता है। यह मोड एंड्रॉइड सामान्य कर्नेल द्वारा लागू नहीं किया गया है, लेकिन इसे कस्टम कर्नेल पैच का उपयोग करके विक्रेताओं द्वारा लागू किया जा सकता है। इस मोड द्वारा निर्मित ऑन-डिस्क प्रारूप विक्रेता-विशिष्ट था। एंड्रॉइड 11 या उच्चतर के साथ लॉन्च होने वाले उपकरणों पर, इस मोड की अब अनुमति नहीं है और इसके बजाय एक मानक एन्क्रिप्शन प्रारूप का उपयोग किया जाना चाहिए।

डिफ़ॉल्ट रूप से, फ़ाइल सामग्री एन्क्रिप्शन लिनक्स कर्नेल की क्रिप्टोग्राफी एपीआई का उपयोग करके किया जाता है। यदि आप इसके बजाय इनलाइन एन्क्रिप्शन हार्डवेयर का उपयोग करना चाहते हैं, तो 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 और/या मेटाडेटा एन्क्रिप्शन प्रारूपों को ओवरराइड कर सकते हैं।

एंड्रॉइड 11 या उच्चतर के साथ लॉन्च होने वाले उपकरणों पर, निम्नलिखित गुणों का उपयोग करें:

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

एंड्रॉइड 10 या उससे पहले के संस्करण के साथ लॉन्च होने वाले उपकरणों पर, निम्नलिखित गुणों का उपयोग करें:

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

कीमास्टर के साथ एकीकरण

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

निर्देशिकाओं को छोड़कर

init सिस्टम DE कुंजी को /data की सभी शीर्ष-स्तरीय निर्देशिकाओं पर लागू करता है, उन निर्देशिकाओं को छोड़कर जिन्हें अनएन्क्रिप्टेड किया जाना चाहिए जैसे कि वह निर्देशिका जिसमें सिस्टम DE कुंजी होती है और निर्देशिकाएँ जिनमें उपयोगकर्ता CE या DE निर्देशिकाएँ होती हैं। एन्क्रिप्शन कुंजियाँ पुनरावर्ती रूप से लागू होती हैं और उपनिर्देशिकाओं द्वारा ओवरराइड नहीं की जा सकतीं।

एंड्रॉइड 11 और उच्चतर में, init निर्देशिकाओं पर लागू होने वाली कुंजी को init स्क्रिप्ट में mkdir कमांड के encryption=<action> तर्क द्वारा नियंत्रित किया जा सकता है। <action> के संभावित मान Android init भाषा के लिए README में प्रलेखित हैं।

एंड्रॉइड 10 में, init एन्क्रिप्शन क्रियाओं को निम्नलिखित स्थान पर हार्डकोड किया गया था:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

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

इस मोड में चलते समय, आवश्यकता पड़ने पर सीई स्टोरेज द्वारा समर्थित संदर्भ को स्पष्ट रूप से प्रबंधित करने के लिए निम्नलिखित सिस्टम एपीआई उपलब्ध होते हैं, जो उनके डिवाइस संरक्षित समकक्षों के बराबर होते हैं।

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

एकाधिक उपयोगकर्ताओं का समर्थन करना

बहु-उपयोगकर्ता परिवेश में प्रत्येक उपयोगकर्ता को एक अलग एन्क्रिप्शन कुंजी मिलती है। प्रत्येक उपयोगकर्ता को दो कुंजी मिलती हैं: एक DE और एक CE कुंजी। उपयोगकर्ता 0 को पहले डिवाइस में लॉग इन करना होगा क्योंकि यह एक विशेष उपयोगकर्ता है। यह डिवाइस एडमिनिस्ट्रेशन उपयोग के लिए प्रासंगिक है।

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

एक एप्लिकेशन डीई क्षेत्रों में स्वतंत्र रूप से बातचीत करने में सक्षम हो सकता है, लेकिन एक उपयोगकर्ता अनलॉक होने का मतलब यह नहीं है कि डिवाइस पर सभी उपयोगकर्ता अनलॉक हो गए हैं। एप्लिकेशन को इन क्षेत्रों तक पहुंचने का प्रयास करने से पहले इस स्थिति की जांच करनी चाहिए।

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

अद्यतनों को संभालना

पुनर्प्राप्ति विभाजन उपयोगकर्ताडेटा विभाजन पर DE-संरक्षित संग्रहण तक पहुंचने में असमर्थ है। एफबीई लागू करने वाले उपकरणों को ए/बी सिस्टम अपडेट का उपयोग करके ओटीए का समर्थन करने की दृढ़ता से अनुशंसा की जाती है। चूंकि ओटीए को सामान्य ऑपरेशन के दौरान लागू किया जा सकता है, इसलिए एन्क्रिप्टेड ड्राइव पर डेटा तक पहुंचने के लिए पुनर्प्राप्ति की कोई आवश्यकता नहीं है।

लीगेसी ओटीए समाधान का उपयोग करते समय, जिसे userdata विभाजन पर ओटीए फ़ाइल तक पहुंचने के लिए पुनर्प्राप्ति की आवश्यकता होती है:

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

मान्यकरण

यह सुनिश्चित करने के लिए कि सुविधा का कार्यान्वित संस्करण इरादा के अनुसार काम करता है, पहले कई सीटीएस एन्क्रिप्शन परीक्षण चलाएं, जैसे डायरेक्टबूटहोस्टटेस्ट और एन्क्रिप्शनटेस्ट

यदि डिवाइस एंड्रॉइड 11 या उच्चतर चला रहा है, तो vts_kernel_encryption_test भी चलाएं:

atest vts_kernel_encryption_test

या:

vts-tradefed run vts -m vts_kernel_encryption_test

इसके अलावा, डिवाइस निर्माता निम्नलिखित मैन्युअल परीक्षण भी कर सकते हैं। FBE सक्षम डिवाइस पर:

  • जांचें कि ro.crypto.state मौजूद है
    • सुनिश्चित करें कि ro.crypto.state एन्क्रिप्टेड है
  • जांचें कि ro.crypto.type मौजूद है
    • सुनिश्चित करें कि ro.crypto.type file पर सेट है

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

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

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

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

सत्यापित करें कि सूचीबद्ध फ़ाइल नाम बेस64-एन्कोडेड हैं, यह दर्शाता है कि फ़ाइल नाम एन्क्रिप्ट किए गए हैं और उन्हें डिक्रिप्ट करने की कुंजी अभी तक उपलब्ध नहीं है। यदि फ़ाइल नाम सादे टेक्स्ट में सूचीबद्ध हैं, तो कुछ गलत है।

डिवाइस निर्माताओं को अपने डिवाइस या कर्नेल पर fscrypt के लिए अपस्ट्रीम लिनक्स परीक्षण चलाने का पता लगाने के लिए भी प्रोत्साहित किया जाता है। ये परीक्षण xfstests फ़ाइल सिस्टम परीक्षण सूट का हिस्सा हैं। हालाँकि, ये अपस्ट्रीम परीक्षण आधिकारिक तौर पर एंड्रॉइड द्वारा समर्थित नहीं हैं।

एओएसपी कार्यान्वयन विवरण

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

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

AOSP कार्यान्वयन कर्नेल में "fscrypt" एन्क्रिप्शन (ext4 और f2fs द्वारा समर्थित) का उपयोग करता है और सामान्य रूप से इसे कॉन्फ़िगर किया जाता है:

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

एडियंटम एन्क्रिप्शन भी समर्थित है। जब एडिएंटम एन्क्रिप्शन सक्षम होता है, तो फ़ाइल सामग्री और फ़ाइल नाम दोनों एडिएंटम के साथ एन्क्रिप्ट किए जाते हैं।

fscrypt एन्क्रिप्शन नीतियों के दो संस्करणों का समर्थन करता है: संस्करण 1 और संस्करण 2। संस्करण 1 को हटा दिया गया है, और एंड्रॉइड 11 और उच्चतर के साथ लॉन्च होने वाले उपकरणों के लिए सीडीडी आवश्यकताएं केवल संस्करण 2 के साथ संगत हैं। संस्करण 2 एन्क्रिप्शन नीतियां वास्तविक प्राप्त करने के लिए HKDF-SHA512 का उपयोग करती हैं यूजरस्पेस द्वारा प्रदत्त कुंजियों से एन्क्रिप्शन कुंजियाँ।

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

भंडारण वर्ग

निम्न तालिका FBE कुंजियों और उनके द्वारा सुरक्षित की जाने वाली निर्देशिकाओं को अधिक विस्तार से सूचीबद्ध करती है:

भंडारण वर्ग विवरण निर्देशिका
अनएन्क्रिप्ट /data में निर्देशिकाएं जिन्हें एफबीई द्वारा संरक्षित करने की आवश्यकता नहीं है या नहीं। मेटाडेटा एन्क्रिप्शन का उपयोग करने वाले उपकरणों पर, ये निर्देशिकाएं वास्तव में अनएन्क्रिप्टेड नहीं हैं, बल्कि मेटाडेटा एन्क्रिप्शन कुंजी द्वारा संरक्षित हैं जो सिस्टम डीई के बराबर है।
  • /data/apex , /data/apex/decompressed और /data/apex/ota_reserved छोड़कर जो सिस्टम DE हैं
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • सभी निर्देशिकाएँ जिनकी उपनिर्देशिकाएँ भिन्न FBE कुंजियों का उपयोग करती हैं। उदाहरण के लिए, चूंकि प्रत्येक /data/user/${user_id} निर्देशिका प्रति-उपयोगकर्ता कुंजी का उपयोग करती है, /data/user स्वयं किसी कुंजी का उपयोग नहीं करती है।
सिस्टम डी.ई डिवाइस-एन्क्रिप्टेड डेटा किसी विशेष उपयोगकर्ता से जुड़ा नहीं है
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • /data की अन्य सभी उपनिर्देशिकाएँ जिनका यह तालिका भिन्न वर्ग के रूप में उल्लेख नहीं करती है
प्रति-बूट अल्पकालिक सिस्टम फ़ाइलें जिन्हें रीबूट से बचने की आवश्यकता नहीं है /data/per_boot
उपयोगकर्ता सीई (आंतरिक) आंतरिक भंडारण पर प्रति-उपयोगकर्ता क्रेडेंशियल-एन्क्रिप्टेड डेटा
  • /data/data ( /data/user/0 का उपनाम)
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
उपयोगकर्ता DE (आंतरिक) आंतरिक भंडारण पर प्रति-उपयोगकर्ता डिवाइस-एन्क्रिप्टेड डेटा
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
उपयोगकर्ता सीई (गोद लेने योग्य) अपनाने योग्य भंडारण पर प्रति-उपयोगकर्ता क्रेडेंशियल-एन्क्रिप्टेड डेटा
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
उपयोगकर्ता DE (गोद लेने योग्य) अपनाने योग्य भंडारण पर प्रति-उपयोगकर्ता डिवाइस-एन्क्रिप्टेड डेटा
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

कुंजी भंडारण और सुरक्षा

सभी एफबीई कुंजियाँ vold द्वारा प्रबंधित की जाती हैं और प्रति-बूट कुंजी को छोड़कर, जो बिल्कुल भी संग्रहीत नहीं होती हैं, एन्क्रिप्टेड ऑन-डिस्क संग्रहीत की जाती हैं। निम्न तालिका उन स्थानों को सूचीबद्ध करती है जिनमें विभिन्न FBE कुंजियाँ संग्रहीत हैं:

कुंजी प्रकार मुख्य स्थान मुख्य स्थान का भंडारण वर्ग
सिस्टम DE कुंजी /data/unencrypted अनएन्क्रिप्ट
उपयोगकर्ता CE (आंतरिक) कुंजियाँ /data/misc/vold/user_keys/ce/${user_id} सिस्टम डी.ई
उपयोगकर्ता DE (आंतरिक) कुंजियाँ /data/misc/vold/user_keys/de/${user_id} सिस्टम डी.ई
उपयोगकर्ता CE (गोद लेने योग्य) कुंजियाँ /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} उपयोगकर्ता सीई (आंतरिक)
उपयोगकर्ता DE (गोद लेने योग्य) कुंजियाँ /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} उपयोगकर्ता DE (आंतरिक)

जैसा कि पिछली तालिका में दिखाया गया है, अधिकांश FBE कुंजियाँ उन निर्देशिकाओं में संग्रहीत होती हैं जो किसी अन्य FBE कुंजी द्वारा एन्क्रिप्ट की जाती हैं। कुंजियाँ तब तक अनलॉक नहीं की जा सकतीं जब तक कि उन्हें रखने वाला भंडारण वर्ग अनलॉक न हो जाए।

vold सभी FBE कुंजियों पर एन्क्रिप्शन की एक परत भी लागू करता है। आंतरिक भंडारण के लिए CE कुंजी के अलावा प्रत्येक कुंजी को अपनी स्वयं की कीस्टोर कुंजी का उपयोग करके AES-256-GCM के साथ एन्क्रिप्ट किया गया है जो TEE के बाहर प्रदर्शित नहीं होती है। यह सुनिश्चित करता है कि FBE कुंजियाँ तब तक अनलॉक नहीं की जा सकतीं जब तक कि कोई विश्वसनीय ऑपरेटिंग सिस्टम बूट न ​​हो, जैसा कि सत्यापित बूट द्वारा लागू किया गया है। कीस्टोर कुंजी पर रोलबैक प्रतिरोध का भी अनुरोध किया जाता है, जो एफबीई कुंजी को उन उपकरणों पर सुरक्षित रूप से हटाने की अनुमति देता है जहां कीमास्टर रोलबैक प्रतिरोध का समर्थन करता है। रोलबैक प्रतिरोध अनुपलब्ध होने पर सर्वोत्तम प्रयास के रूप में, कुंजी के साथ संग्रहीत secdiscardable फ़ाइल में संग्रहीत 16384 यादृच्छिक बाइट्स के SHA-512 हैश का उपयोग कीस्टोर कुंजी के एप्लिकेशन आईडी टैग के रूप में किया जाता है। FBE कुंजी को पुनर्प्राप्त करने के लिए इन सभी बाइट्स को पुनर्प्राप्त करने की आवश्यकता है।

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

इसे प्राप्त करने के लिए, vold उपयोगकर्ता के सिंथेटिक पासवर्ड से प्राप्त AES-256-GCM कुंजी का उपयोग करके आंतरिक भंडारण के लिए प्रत्येक CE कुंजी को एन्क्रिप्ट करता है। सिंथेटिक पासवर्ड एक अपरिवर्तनीय उच्च-एन्ट्रॉपी क्रिप्टोग्राफ़िक रहस्य है जो प्रत्येक उपयोगकर्ता के लिए यादृच्छिक रूप से उत्पन्न होता है। system_server में LockSettingsService सिंथेटिक पासवर्ड और इसे संरक्षित करने के तरीकों का प्रबंधन करता है।

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

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

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

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