Google 致力于为黑人社区推动种族平等。查看具体举措
此页面由 Cloud Translation API 翻译。
Switch to English

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

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

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

डायरेक्ट बूट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

निर्भरता

FBE के AOSP कार्यान्वयन को सुरक्षित रूप से उपयोग करने के लिए, एक उपकरण को निम्न निर्भरताओं को पूरा करने की आवश्यकता होती है:

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

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

कार्यान्वयन

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

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

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

CONFIG_FS_ENCRYPTION=y

पुराने कर्नेल, उपयोग के लिए CONFIG_EXT4_ENCRYPTION=y यदि आपके उपकरण की userdata फाइल सिस्टम Ext4, या इस्तेमाल होता है CONFIG_F2FS_FS_ENCRYPTION=y यदि आपके उपकरण की userdata फाइल सिस्टम F2FS है।

यदि आपका उपकरण अपनाने योग्य संग्रहण का समर्थन करेगा या आंतरिक संग्रहण पर मेटाडेटा एन्क्रिप्शन का उपयोग करेगा, तो मेटाडेटा एन्क्रिप्शन के लिए आवश्यक कर्नेल कॉन्फ़िगरेशन विकल्प भी सक्षम करें जैसा कि मेटाडेटा एन्क्रिप्शन दस्तावेज़ में वर्णित है।

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 को गोद लेने योग्य भंडारण पर सक्षम बनाता है; हालाँकि, यदि आवश्यक हो तो गोद लेने योग्य भंडारण पर एन्क्रिप्शन प्रारूप को ओवरराइड किया जा सकता है।

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

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

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

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

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

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

एंड्रॉइड 9 के बाद से, एफबीई और गोद लेने योग्य भंडारण का उपयोग एक साथ किया जा सकता है।

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

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

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

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

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

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

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

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

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

एंड्रॉइड 9 और पहले में, स्थान था:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

इसके लिए एकमात्र ज्ञात स्वीकार्य उपयोग मामला विरासत OTA क्षमताओं के समर्थन में है।

सिस्टम एप्लिकेशन में डायरेक्ट बूट का समर्थन करना

एप्लिकेशन को डायरेक्ट बूट से अवगत कराना

सिस्टम एप्स के तेजी से माइग्रेशन की सुविधा के लिए, दो नई विशेषताएँ हैं जिन्हें एप्लिकेशन स्तर पर सेट किया जा सकता है। defaultToDeviceProtectedStorage विशेषता केवल सिस्टम एप्लिकेशन के लिए उपलब्ध है। directBootAware विशेषता सभी के लिए उपलब्ध है।

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

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

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

इस मोड में चलने पर, निम्न सिस्टम API को जरूरत पड़ने पर CE स्टोरेज द्वारा समर्थित एक कॉन्सेप्ट को स्पष्ट रूप से प्रबंधित करने के लिए उपलब्ध होते हैं, जो उनके डिवाइस प्रोटेक्टेड समकक्षों के बराबर होते हैं।

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

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

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

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

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

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

अद्यतन संभाल रहा है

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

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

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

मान्यकरण

सुविधा के कार्यान्वित संस्करण को सुनिश्चित करने के लिए, पहले CTS एन्क्रिप्शन टेस्ट जैसे DirectBootHostTest और Enc एन्क्रिप्शन Test चलाएं

यदि डिवाइस एंड्रॉइड 11 या उच्चतर चला रहा है, तो vts_kernel_enc एन्क्रिप्शन_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 फाइलसिस्टम परीक्षण सूट का हिस्सा हैं। हालांकि, इन अपस्ट्रीम परीक्षणों को एंड्रॉइड द्वारा आधिकारिक रूप से समर्थित नहीं किया गया है।

AOSP कार्यान्वयन विवरण

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

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

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

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

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

Fscrypt के बारे में अधिक जानकारी के लिए, अपस्ट्रीम कर्नेल प्रलेखन देखें

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

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

  • टोकन टोकन
  • खिंची हुई साख
  • "सेकुलडबल हैश"

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

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

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

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