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

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

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

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

प्रत्यक्ष बूट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

निर्भरता

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

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

कार्यान्वयन

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

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

Ext4 और F2FS एन्क्रिप्शन के लिए कर्नेल समर्थन Android सामान्य कर्नेल, संस्करण 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 को userdata के लिए fstab लाइन के fs_mgr_flags कॉलम में विकल्प fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] जोड़कर सक्षम किया गया है। यह विकल्प आंतरिक संग्रहण पर एन्क्रिप्शन प्रारूप को परिभाषित करता है। इसमें तीन कोलन से अलग किए गए पैरामीटर शामिल हैं:

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

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

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 और एडॉप्टेबल स्टोरेज को एक साथ इस्तेमाल किया जा सकता है।

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

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

  • ro.crypto.volume.options (एंड्रॉइड 11 में नया) अपनाने योग्य भंडारण पर एफबीई एन्क्रिप्शन प्रारूप का चयन करता है। इसका सिंटैक्स 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 अपनाने योग्य भंडारण पर मेटाडेटा एन्क्रिप्शन प्रारूप का चयन करें। मेटाडेटा एन्क्रिप्शन दस्तावेज़ देखें।

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

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

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

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

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

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 और इससे पहले के संस्करण में, स्थान था:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

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

सिस्टम अनुप्रयोगों में डायरेक्ट बूट का समर्थन करना

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

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

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

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

मान्यकरण

यह सुनिश्चित करने के लिए कि सुविधा का क्रियान्वित संस्करण अपेक्षित रूप से कार्य करता है, पहले कई CTS एन्क्रिप्शन परीक्षण चलाएँ, जैसे 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 के लिए अपस्ट्रीम लिनक्स परीक्षण चलाने का पता लगाने के लिए भी प्रोत्साहित किया जाता है। ये परीक्षण xfstest फाइलसिस्टम टेस्ट सूट का हिस्सा हैं। हालाँकि, ये अपस्ट्रीम परीक्षण Android द्वारा आधिकारिक रूप से समर्थित नहीं हैं।

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

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

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

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

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

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

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

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

भंडारण वर्ग

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

भंडारण वर्ग विवरण निर्देशिका
सिस्टम डे डिवाइस-एन्क्रिप्टेड डेटा किसी विशेष उपयोगकर्ता से बंधा नहीं है /data/system , /data/app , और /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}

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

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

कुंजी प्रकार प्रमुख स्थान प्रमुख स्थान का संग्रहण वर्ग
सिस्टम डे कुंजी /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 कुंजियों को तब तक अनलॉक नहीं किया जा सकता जब तक कि एक विश्वसनीय ऑपरेटिंग सिस्टम को बूट नहीं किया जाता है, जैसा कि सत्यापित बूट द्वारा लागू किया गया है। कीस्टोर कुंजी पर रोलबैक प्रतिरोध का भी अनुरोध किया गया है, जो FBE कुंजियों को उन उपकरणों पर सुरक्षित रूप से हटाने की अनुमति देता है जहां कीमास्टर रोलबैक प्रतिरोध का समर्थन करता है। जब रोलबैक प्रतिरोध अनुपलब्ध होता है तो सर्वोत्तम प्रयास के लिए वापसी के रूप में, 16384 यादृच्छिक बाइट्स के SHA-512 हैश को कुंजी के साथ संग्रहीत secdiscardable फ़ाइल में संग्रहीत किया जाता है, जिसे कीस्टोर कुंजी के एप्लिकेशन आईडी टैग के रूप में उपयोग किया जाता है। FBE कुंजी को पुनर्प्राप्त करने के लिए इन सभी बाइट्स को पुनर्प्राप्त करने की आवश्यकता है।

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

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

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

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

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

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