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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

डायरेक्ट बूट

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

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

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

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

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

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

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

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

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

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

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

  • एओएसपी डायलर (पैकेज/ऐप्स/डायलर)
  • डेस्क क्लॉक (पैकेज/ऐप्स/डेस्कक्लॉक)
  • लैटिनाइम (पैकेज/इनपुट पद्धति/लैटिनाइम)*
  • सेटिंग्स ऐप (पैकेज/ऐप्स/सेटिंग्स)*
  • सिस्टमयूआई (ढांचे/आधार/पैकेज/सिस्टमयूआई)*

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

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

निर्भरता

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

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

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

कार्यान्वयन

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

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

Ext4 और F2FS एन्क्रिप्शन के लिए कर्नेल समर्थन Android सामान्य कर्नेल, संस्करण 3.18 और उच्चतर में उपलब्ध है। इसे कर्नेल में सक्षम करने के लिए जो संस्करण 5.1 या उच्चतर है, उपयोग करें:

CONFIG_FS_ENCRYPTION=y

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

यदि आपका उपकरण UFS-आधारित संग्रहण का उपयोग करता है, तो यह भी सक्षम करें:

CONFIG_SCSI_UFS_CRYPTO=y

यदि आपका उपकरण eMMC-आधारित संग्रहण का उपयोग करता है, तो यह भी सक्षम करें:

CONFIG_MMC_CRYPTO=y

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

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

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

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

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

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

उपयोगकर्ता डेटा के लिए fileencryption userdata विकल्प निर्दिष्ट करना भी स्वचालित रूप से गोद लेने योग्य भंडारण पर FBE और मेटाडेटा एन्क्रिप्शन दोनों को सक्षम करता है। हालांकि, आप PRODUCT_PROPERTY_OVERRIDES में प्रॉपर्टी सेट करके एडॉप्टेबल स्टोरेज पर FBE और/या मेटाडेटा एन्क्रिप्शन फॉर्मेट को ओवरराइड कर सकते हैं।

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

  • ro.crypto.volume.options (एंड्रॉइड 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 aes-256-heh है। अधिकांश उपकरणों पर, इसे स्पष्ट रूप से aes-256-cts पर ओवरराइड करने की आवश्यकता होती है।
  • ro.crypto.fde_algorithm और ro.crypto.fde_sector_size अपनाने योग्य भंडारण पर मेटाडेटा एन्क्रिप्शन प्रारूप का चयन करें। मेटाडेटा एन्क्रिप्शन दस्तावेज़ देखें।

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

कुंजी की पीढ़ी और कर्नेल कीरिंग के प्रबंधन को vold द्वारा नियंत्रित किया जाता है। FBE के AOSP कार्यान्वयन के लिए आवश्यक है कि डिवाइस Keymaster HAL संस्करण 1.0 या बाद के संस्करण का समर्थन करे। Keymaster HAL के पुराने संस्करणों के लिए कोई समर्थन नहीं है।

पहले बूट पर, उपयोगकर्ता 0 की कुंजियाँ बूट प्रक्रिया के आरंभ में उत्पन्न और स्थापित की जाती हैं। जब तक init का on-post-fs चरण पूरा हो जाता है, तब तक कीमास्टर अनुरोधों को संभालने के लिए तैयार होना चाहिए। पिक्सेल उपकरणों पर, यह एक स्क्रिप्ट ब्लॉक के द्वारा नियंत्रित किया जाता है जो सुनिश्चित करता है कि कीमास्टर को /data माउंट होने से पहले शुरू किया गया है।

एन्क्रिप्शन नीति

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

एंड्रॉइड 11 और उच्चतर में, एन्क्रिप्शन नीति को अब एक केंद्रीकृत स्थान में हार्डकोड नहीं किया गया है, बल्कि init स्क्रिप्ट में mkdir कमांड के तर्कों द्वारा परिभाषित किया गया है। सिस्टम के साथ एन्क्रिप्टेड निर्देशिकाएं DE कुंजी encryption=Require होती है, जबकि अनएन्क्रिप्टेड निर्देशिकाएं (या निर्देशिका जिनकी उपनिर्देशिका प्रति-उपयोगकर्ता कुंजी के साथ एन्क्रिप्ट की जाती हैं) encryption=None का उपयोग करती हैं।

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

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

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

  • 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. OTA पैकेज रखने के लिए शीर्ष-स्तरीय निर्देशिका के भीतर एक निर्देशिका बनाएँ।
  4. इस फ़ोल्डर और इसकी सामग्री तक पहुंच को नियंत्रित करने के लिए एक SELinux नियम और फ़ाइल संदर्भ जोड़ें। केवल ओटीए अपडेट प्राप्त करने वाली प्रक्रिया या एप्लिकेशन इस फ़ोल्डर को पढ़ने और लिखने में सक्षम होना चाहिए। किसी अन्य एप्लिकेशन या प्रक्रिया की इस फ़ोल्डर तक पहुंच नहीं होनी चाहिए।

मान्यकरण

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

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

atest vts_kernel_encryption_test

या:

vts-tradefed run vts -m vts_kernel_encryption_test

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

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

इसके अतिरिक्त, परीक्षक प्राथमिक उपयोगकर्ता पर एक लॉकस्क्रीन सेट के साथ उपयोगकर्ता userdebug इंस्टेंस को बूट कर सकते हैं। फिर डिवाइस में adb खोल और रूट बनने के लिए su का उपयोग करें। सुनिश्चित करें कि /data/data में एन्क्रिप्टेड फ़ाइल नाम हैं; अगर ऐसा नहीं होता है, तो कुछ गलत है।

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

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

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

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

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

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

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

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

कुंजी व्युत्पत्ति

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

  • प्रामाणिक टोकन
  • फैला हुआ क्रेडेंशियल
  • "सेकडिस्कार्डेबल हैश"

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

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

secdiscardable hash एक यादृच्छिक 16 केबी फ़ाइल का 512-बिट हैश है जो अन्य जानकारी के साथ संग्रहीत किया जाता है, जिसका उपयोग कुंजी को फिर से संगठित करने के लिए किया जाता है, जैसे कि बीज। जब कुंजी हटा दी जाती है, या इसे नए तरीके से एन्क्रिप्ट किया जाता है, तो यह फ़ाइल सुरक्षित रूप से हटा दी जाती है; यह अतिरिक्त सुरक्षा सुनिश्चित करती है कि एक हमलावर को कुंजी को पुनर्प्राप्त करने के लिए इस सुरक्षित रूप से हटाई गई फ़ाइल के हर बिट को पुनर्प्राप्त करना होगा। यह KM_TAG_APPLICATION_ID पर लागू होने वाली सभी गारंटियों के साथ KM_TAG_APPLICATION_ID में कुंजी से क्रिप्टोग्राफ़िक रूप से बाध्य है।

ज्यादातर मामलों में, FBE कुंजियाँ कर्नेल में एक अतिरिक्त कुंजी व्युत्पत्ति चरण से गुजरती हैं ताकि वास्तव में एन्क्रिप्शन करने के लिए उपयोग की जाने वाली उपकुंजियाँ उत्पन्न हो सकें, उदाहरण के लिए प्रति-फ़ाइल या प्रति-मोड कुंजियाँ। संस्करण 2 एन्क्रिप्शन नीतियों के लिए, इसके लिए HKDF-SHA512 का उपयोग किया जाता है।