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

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

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

डायरेक्ट बूट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

निर्भरता

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

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

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

कार्यान्वयन

के अनुसार directBootAware: सबसे पहले, अलार्म घड़ियों, फोन के रूप में इस तरह के एप्लिकेशन, उपयोग जैसी Android बनाया जाना चाहिए प्रत्यक्ष बूट डेवलपर दस्तावेज़।

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

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

आगे करने के लिए प्रदर्शन में सुधार और बिजली के उपयोग को कम करने, उपकरण निर्माताओं भी इनलाइन एन्क्रिप्शन हार्डवेयर, जो encrypts / डेटा decrypts, जबकि यह संग्रहण उपकरण / करने के लिए रास्ते पर है लागू करने पर विचार कर सकते हैं। एंड्रॉइड सामान्य कर्नेल (संस्करण 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 विकल्प जोड़कर सक्षम किया गया है fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] की fs_mgr_flags स्तंभ के लिए fstab के लिए लाइन userdata । यह विकल्प आंतरिक भंडारण पर एन्क्रिप्शन प्रारूप को परिभाषित करता है। इसमें तीन कोलन से अलग किए गए पैरामीटर शामिल हैं:

  • contents_encryption_mode पैरामीटर परिभाषित करता है जो क्रिप्टोग्राफिक एल्गोरिथम एन्क्रिप्ट फ़ाइल की सामग्री के लिए इस्तेमाल किया जाता है। यह या तो हो सकता है aes-256-xts या adiantum । एंड्रॉयड 11 के बाद से यह भी डिफ़ॉल्ट एल्गोरिथ्म, जो निर्दिष्ट करने के लिए खाली छोड़ा जा सकता है aes-256-xts
  • filenames_encryption_mode पैरामीटर परिभाषित करता है जो क्रिप्टोग्राफिक एल्गोरिथम एन्क्रिप्ट फ़ाइल नाम करने के लिए प्रयोग किया जाता है। यह या तो हो सकता है aes-256-cts , 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 एन्क्रिप्शन नीतियों एक अधिक सुरक्षित और लचीला का उपयोग कुंजी व्युत्पत्ति समारोह । डिवाइस (के रूप में द्वारा निर्धारित एंड्रॉयड 11 पर शुरू किया गया या उच्चतर यदि डिफ़ॉल्ट v2 है ro.product.first_api_level ) v1 डिवाइस एंड्रॉयड 10 पर शुरू किया गया या कम है, या।
    • inlinecrypt_optimized झंडा कि इनलाइन एन्क्रिप्शन हार्डवेयर कि चाबी की बड़ी संख्या को कुशलता से संभाल नहीं करता है के लिए अनुकूलित है एक एन्क्रिप्शन प्रारूप का चयन करता है। यह प्रति फ़ाइल एक के बजाय केवल एक फ़ाइल सामग्री एन्क्रिप्शन कुंजी प्रति सीई या डीई कुंजी प्राप्त करके करता है। IVs (आरंभीकरण वैक्टर) की पीढ़ी को तदनुसार समायोजित किया जाता है।
    • emmc_optimized ध्वज के समान है inlinecrypt_optimized , लेकिन यह भी एक चतुर्थ पीढ़ी विधि का चयन करता है कि 32 बिट करने के लिए सीमा IVs। यह ध्वज केवल इनलाइन एन्क्रिप्शन हार्डवेयर पर उपयोग किया जाना चाहिए जो 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 )। एईएस त्वरण के किसी भी रूप के बिना उपकरणों पर, Adiantum की स्थापना करके एईएस के बजाय इस्तेमाल किया जा सकता fileencryption=adiantum

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

अपनाने योग्य भंडारण

एंड्रॉयड 9 के बाद से, FBE और ग्रहणीय भंडारण एक साथ इस्तेमाल किया जा सकता है।

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

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 , सिवाय इसके कि कि एंड्रॉयड 10 या कम के साथ शुरू उपकरणों पर डिफ़ॉल्ट है 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 की कुंजियाँ बूट प्रक्रिया के आरंभ में उत्पन्न और स्थापित की जाती हैं। समय तक on-post-fs के चरण init पूरा करता है, Keymaster अनुरोधों को हैंडल करने के लिए तैयार होना चाहिए। पिक्सेल डिवाइस पर, यह एक स्क्रिप्ट ब्लॉक सुनिश्चित Keymaster शुरू कर दिया है से पहले होने से नियंत्रित किया जाता है /data खड़ा होता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मान्यकरण

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

डिवाइस एंड्रॉयड 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 के साथ फ़ाइल नामों को एन्क्रिप्ट करें

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

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

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

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

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

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

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

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

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