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

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

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

Android 10 और उसके बाद के वर्शन के साथ लॉन्च होने वाले सभी डिवाइसों में फ़ाइल-आधारित एन्क्रिप्शन का इस्तेमाल करना ज़रूरी है.

डायरेक्ट बूट

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

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

FBE की सुविधा वाले डिवाइस पर, हर उपयोगकर्ता के डिवाइस की मेमोरी की दो जगहें होती हैं ऐप्स के लिए उपलब्ध:

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

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

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

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

एओएसपी में सभी ज़रूरी पैकेज को सीधे तौर पर बूट करने की जानकारी देने के लिए अपडेट किया गया है. हालांकि, डिवाइस बनाने वाली कंपनियां जब इन ऐप्लिकेशन के कस्टमाइज़ वर्शन का इस्तेमाल करती हैं, तो यह पक्का करना होगा कि कम से कम डायरेक्ट-बूट अवेयर पैकेज उपलब्ध हों नीचे दी गई सेवाएं:

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

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

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

  • AOSP डायलर (पैकेज/ऐप्लिकेशन/डायलर)
  • डेस्क क्लॉक (पैकेज/ऐप्लिकेशन/डेस्कक्लॉक)
  • लैटिनIME (packages/inputmethods/लैटिनIME)*
  • Settings ऐप्लिकेशन (पैकेज/ऐप्लिकेशन/सेटिंग)*
  • SystemUI (फ़्रेमवर्क/बेस/पैकेज/SystemUI)*

* defaultToDeviceProtectedStorage का इस्तेमाल करने वाले सिस्टम ऐप्लिकेशन मेनिफ़ेस्ट एट्रिब्यूट

एन्क्रिप्शन की जानकारी रखने वाले ऐप्लिकेशन और सेवाओं के उदाहरण कमांड mangrep directBootAware को चलाने के बाद एओएसपी के फ़्रेमवर्क या पैकेज डायरेक्ट्री सोर्स ट्री.

डिपेंडेंसी

FBE के एओएसपी को सुरक्षित तरीके से लागू करने के लिए, डिवाइस को ये डिपेंडेंसी:

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

लागू करना

सबसे पहली और खास बात, अलार्म घड़ियां, फ़ोन, और सुलभता सुविधाएं जैसे ऐप्लिकेशन इसे डायरेक्ट बूट करने का तरीका डेवलपर के लिए दस्तावेज़.

कर्नेल सपोर्ट

Android के सामान्य वर्शन में, 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

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

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

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

CONFIG_SCSI_UFS_CRYPTO=y

अगर आपके डिवाइस में ईएमएमसी पर आधारित स्टोरेज का इस्तेमाल किया जाता है, तो इन्हें भी चालू करें: 

CONFIG_MMC_CRYPTO=y

फ़ाइल के आधार पर एन्क्रिप्ट (सुरक्षित) करने का तरीका चालू करना

डिवाइस पर FBE को चालू करने के लिए, इसे डिवाइस के स्टोरेज में चालू करना ज़रूरी है (userdata). इससे, अपनाने वाले डिवाइसों पर FBE की सुविधा भी अपने-आप चालू हो जाती है स्टोरेज; हालांकि, डिवाइस के स्टोरेज के लिए एन्क्रिप्ट (सुरक्षित) करने का फ़ॉर्मैट बदला जा सकता है ऐसा करना ज़रूरी है.

मोबाइल मेमोरी

विकल्प जोड़कर एफ़बीई को चालू किया जाता है fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इसके लिए fstab लाइन के fs_mgr_flags कॉलम तक userdata. यह विकल्प, पेज के अंदरूनी हिस्से पर एन्क्रिप्ट (सुरक्षित) करने का फ़ॉर्मैट बताता है स्टोरेज. इसमें ज़्यादा से ज़्यादा तीन कोलन से अलग किए गए पैरामीटर होते हैं:

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

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

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

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

डिफ़ॉल्ट रूप से, फ़ाइल सामग्री को Linux कर्नेल के क्रिप्टोग्राफ़ी एपीआई. अगर आपको इसके बजाय इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल करना हो, तो 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, और Android 90 के बाद के वर्शन डिवाइस का स्टोरेज एक साथ इस्तेमाल किया जा सकता है.

इसके लिए fileencryption fstab विकल्प तय किया जा रहा है userdata की मदद से, ऐसे डिवाइस पर एफ़बीई और मेटाडेटा एन्क्रिप्शन दोनों अपने-आप चालू हो जाते हैं स्टोरेज. हालांकि, इस लिंक पर FBE और/या मेटाडेटा एन्क्रिप्शन फ़ॉर्मैट को बदला जा सकता है स्टोरेज के लिए इस्तेमाल की जाने वाली सेटिंग चुनने के लिए, PRODUCT_PROPERTY_OVERRIDES.

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

KeyMaster के साथ इंटिग्रेट करना

KeyMaster HAL को early_hal क्लास के हिस्से के तौर पर शुरू किया जाना चाहिए. ऐसा इसलिए होता है, क्योंकि FBE की शर्तों के मुताबिक यह ज़रूरी है कि KeyMaster, post-fs-data का बूट फ़ेज़, जो कि vold के सेट अप होने के दौरान होता है में डाला जाना चाहिए.

डायरेक्ट्री शामिल नहीं हैं

init इन पर सिस्टम DE कुंजी लागू करता है /data की सभी टॉप-लेवल की डायरेक्ट्री. इसमें वे डायरेक्ट्री शामिल नहीं हैं जिन्हें इसे एन्क्रिप्ट नहीं किया जाना चाहिए, जैसे कि वह डायरेक्ट्री जिसमें सिस्टम DE कुंजी मौजूद है और डायरेक्ट्री, जिनमें उपयोगकर्ता CE या DE डायरेक्ट्री शामिल हैं. एन्क्रिप्ट (सुरक्षित) करने वाली कुंजियां बार-बार लागू किया जा सकता है और सबडायरेक्ट्री से इसे बदला नहीं जा सकता.

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

Android 10 में, एन्क्रिप्ट (सुरक्षित) करने की init कार्रवाइयां निम्न स्थान पर हार्डकोड किए गए थे: 

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 और उससे पहले के वर्शन में, यह जगह ये थी: 

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

कुछ डायरेक्ट्री को अपवाद के तौर पर जोड़ा जा सकता है, ताकि एन्क्रिप्ट किया गया है. अगर इस तरह के बदलाव किए जाते हैं, तो डिवाइस निर्माता को SELinux नीतियां, जो केवल ऐसे ऐप्लिकेशन जिन्हें एन्क्रिप्ट नहीं की गई डायरेक्ट्री का इस्तेमाल करना होगा. इसमें सभी चीज़ें शामिल नहीं होनी चाहिए गैर-भरोसेमंद ऐप्लिकेशन.

इसके लिए उचित इस्तेमाल का उदाहरण सिर्फ़ लेगसी ओटीए के साथ किया जा सकता है सुविधाएं.

सिस्टम ऐप्लिकेशन में डायरेक्ट बूट की सुविधा के साथ काम करना

ऐप्लिकेशन को Direct बूट के बारे में जानकारी देना

सिस्टम ऐप्लिकेशन के डेटा को तेज़ी से माइग्रेट करने के लिए, दो नए एट्रिब्यूट जोड़े गए हैं को ऐप्लिकेशन के लेवल पर सेट किया जा सकता है. कॉन्टेंट बनाने defaultToDeviceProtectedStorage एट्रिब्यूट सिर्फ़ इनके लिए उपलब्ध है सिस्टम ऐप्लिकेशन. directBootAware एट्रिब्यूट सभी के लिए उपलब्ध है. 

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

ऐप्लिकेशन के लेवल पर, directBootAware एट्रिब्यूट की वैल्यू को मार्क करने के लिए इस्तेमाल किया जाता है को सुरक्षित रखने के बारे में जागरूक रहें.

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

इस मोड में चलाने पर, नीचे दिए गए सिस्टम एपीआई इसकी मदद से, ज़रूरत पड़ने पर सीई स्टोरेज पर काम करने वाले कॉन्टेक्स्ट को मैनेज किया जा सकता है. सुरक्षा से जुड़ी सभी सुविधाएं मिलती हैं.

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

कई उपयोगकर्ताओं की मदद करना

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

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

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

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

अपडेट मैनेज करना

रिकवरी पार्टिशन, इस डिवाइस पर मौजूद DE-सुरक्षित स्टोरेज को ऐक्सेस नहीं कर पा रहा है उपयोगकर्ता के डेटा का बंटवारा. हमारा सुझाव है कि जिन डिवाइसों पर एफ़बीई लागू किया जा रहा है वे इनके साथ काम करते हों ओटीए, जो A/B सिस्टम अपडेट का इस्तेमाल करता हो. जैसे ओटीए को सामान्य ऑपरेशन के दौरान लागू किया जा सकता है. इसके लिए, रिकवरी की ज़रूरत नहीं है एन्क्रिप्ट (सुरक्षित) की गई ड्राइव में मौजूद डेटा को ऐक्सेस करने की अनुमति दें.

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

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

पुष्टि करें

सुविधा का लागू किया गया वर्शन उम्मीद के मुताबिक काम करे, यह पक्का करने के लिए सबसे पहले चलाएं कई सीटीएस एन्क्रिप्शन की जांच की जा सकती है, जैसे कि DirectBootHostTest और एन्क्रिप्ट (सुरक्षित) करने के तरीके की जांच करनी होगी.

अगर डिवाइस में 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 या eng बिल्ड, पिन, पैटर्न सेट करें या पासवर्ड डालें और डिवाइस को फिर से चालू करें. डिवाइस को अनलॉक करने से पहले, मुख्य उपयोगकर्ता के CE स्टोरेज की जांच करने के लिए, नीचे दिया गया कमांड चलाएं. अगर डिवाइस हेडलेस सिस्टम का इस्तेमाल करता है उपयोगकर्ता मोड (ज़्यादातर Automotive डिवाइस) का इस्तेमाल करते हैं, तो मुख्य उपयोगकर्ता 10 उपयोगकर्ता है. इसलिए, चलाएं: 

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

दूसरे डिवाइसों (ज़्यादातर ऐसे ऑटोमोटिव डिवाइस जो वाहन नहीं हैं) पर मुख्य उपयोगकर्ता उपयोगकर्ता 0 है. इसलिए, चलाएं:

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

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

डिवाइस बनाने वाली कंपनियों को अपने डिवाइसों पर fscrypt के लिए Linux अपस्ट्रीम Linux टेस्ट चलाने के लिए भी बढ़ावा दिया जाता है या कर्नेल. ये परीक्षण xfstests फ़ाइलसिस्टम टेस्ट सुइट का हिस्सा हैं. हालांकि, ये अपस्ट्रीम टेस्ट, Android पर ऑफ़लाइन काम नहीं करते.

एओएसपी को लागू करने की जानकारी

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

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

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

  • XTS मोड में, AES-256 की मदद से फ़ाइल का कॉन्टेंट एन्क्रिप्ट (सुरक्षित) करें
  • CBC-CTS मोड में, AES-256 की मदद से फ़ाइल के नाम एन्क्रिप्ट (सुरक्षित) करें

ऐडिएंटम एन्क्रिप्शन की सुविधा समर्थित हैं. Adiantum एन्क्रिप्शन चालू होने पर, फ़ाइल का कॉन्टेंट और फ़ाइल के नाम, दोनों Adiantum की मदद से एन्क्रिप्ट किए गए हैं.

fscrypt एन्क्रिप्शन नीतियों के दो वर्शन का समर्थन करता है: वर्शन 1 और वर्शन 2. वर्शन 1 अब काम नहीं करता. साथ ही, इनके साथ लॉन्च होने वाले डिवाइसों के लिए CDD की ज़रूरी शर्तें Android 11 और उसके बाद के वर्शन, सिर्फ़ इस वर्शन पर काम करते हैं 2. वर्शन 2 की, एन्क्रिप्ट (सुरक्षित) करने की नीतियों में HKDF-SHA512 का इस्तेमाल किया गया है यूज़रस्पेस से जुड़ी कुंजियों से असली एन्क्रिप्शन कुंजियां पाने के लिए.

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

स्टोरेज क्लास

नीचे दी गई टेबल में, एफ़बीई कुंजियों और उन डायरेक्ट्री की सूची दी गई है जिन्हें वे ज़्यादा सुरक्षित तरीके से सुरक्षित रखते हैं विवरण:

स्टोरेज क्लास ब्यौरा निर्देशिकाएं
एन्क्रिप्शन रहित /data में मौजूद डायरेक्ट्री, जो हो सकती हैं या नहीं होनी चाहिए FBE से सुरक्षित. उन डिवाइसों पर जो मेटाडेटा का इस्तेमाल करते हैं , ये डायरेक्ट्री वाकई एन्क्रिप्ट (सुरक्षित) नहीं की गई हैं, बल्कि इन्हें एन्क्रिप्ट नहीं किया गया है. मेटाडेटा एन्क्रिप्शन कुंजी से सुरक्षित होते हैं. यह कुंजी इसके बराबर है: सिस्टम डी॰
  • /data/apex, इसे छोड़कर /data/apex/decompressed और /data/apex/ota_reserved जो सिस्टम DE हैं
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • वे सभी डायरेक्ट्री, जिनकी सबडायरेक्ट्री अलग-अलग FBE कुंजियों का इस्तेमाल करती हैं. इसके लिए उदाहरण के लिए, हर /data/user/${user_id} डायरेक्ट्री हर उपयोगकर्ता कुंजी का इस्तेमाल करता है, /data/user किसी कुंजी का इस्तेमाल नहीं करता वह भी ऐसा कर सकता है.
सिस्टम DE डिवाइस का एन्क्रिप्ट (सुरक्षित) किया गया डेटा किसी खास उपयोगकर्ता से नहीं जुड़ा होता है
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • /data की अन्य सभी सबडायरेक्ट्री, जो इस टेबल में शामिल हैं कोई दूसरी क्लास होने के तौर पर नहीं बताया गया है
हर बूट के हिसाब से कुछ समय के लिए इस्तेमाल होने वाली सिस्टम फ़ाइलें, जिन्हें फिर से चालू होने से बचने की ज़रूरत नहीं होती /data/per_boot
उपयोगकर्ता CE (इंटरनल) डिवाइस के स्टोरेज पर हर उपयोगकर्ता के लिए, क्रेडेंशियल से एन्क्रिप्ट (सुरक्षित) किया गया डेटा
  • /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}
यूज़र डीई (ऑप्टिमाइज़ किया जा सकने वाला डिवाइस) डिवाइस के स्टोरेज के बारे में, हर उपयोगकर्ता के डिवाइस के हिसाब से एन्क्रिप्ट (सुरक्षित) किया गया डेटा
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

डिजिटल बटन को स्टोर करने और सुरक्षा देने की सुविधा

सभी एफ़बीई कुंजियों को vold मैनेज करता है. साथ ही, उन्हें डिस्क में एन्क्रिप्ट (सुरक्षित) करके सेव किया जाता है, इसमें हर बूट की कुंजी शामिल नहीं होती है, जिसे बिलकुल भी सेव नहीं किया जाता है. नीचे दी गई टेबल उन जगहों की सूची बनाता है जहां अलग-अलग FBE कुंजियां स्टोर की जाती हैं:

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

जैसा कि पिछली टेबल में दिखाया गया है, ज़्यादातर एफ़बीई कुंजियों को उन डायरेक्ट्री में सेव किया जाता है जिनमें किसी अन्य FBE कुंजी से एन्क्रिप्ट किए गए हों. डिवाइस को तब तक अनलॉक नहीं किया जा सकता, जब तक डिवाइस का स्टोरेज खाली न हो क्लास को अनलॉक कर दिया गया है.

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

डिवाइस के स्टोरेज के लिए इस्तेमाल होने वाली CE कुंजियों को ज़्यादा बेहतर सुरक्षा मिलती है. इससे यह पक्का होता है कि डिवाइस को उपयोगकर्ता की लॉक स्क्रीन' के बिना अनलॉक नहीं किया जा सकता नॉलेज फ़ैक्टर (LSKF) (पिन, पैटर्न या पासवर्ड), एक सुरक्षित पासवर्ड रीसेट टोकन या क्लाइंट-साइड और सर्वर-साइड, दोनों कुंजियों को फिर से चालू करने की प्रोसेस फिर से शुरू करें. पासवर्ड रीसेट टोकन सिर्फ़ वर्क प्रोफ़ाइलों के लिए बनाए जा सकते हैं और पूरी तरह से मैनेज किए जा रहे डिवाइस.

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

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

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

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

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