हार्डवेयर से सुरक्षित की गई कुंजियां

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

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

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

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

डिज़ाइन

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

सिस्टम मेमोरी में रॉ एन्क्रिप्शन की की ज़रूरत से बचने का एक तरीका यह है कि उन्हें सिर्फ़ इनलाइन क्रिप्टो इंजन के कीस्लॉट में रखा जाए. हालांकि, इस तरीके में कुछ समस्याएं आती हैं:

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

इन समस्याओं से बचने के लिए, स्टोरेज की की को हार्डवेयर-रैप्ड की में बदल दिया जाता है. इन्हें सिर्फ़ खास हार्डवेयर से अनरैप किया जा सकता है और इस्तेमाल किया जा सकता है. इससे, की की संख्या पर कोई पाबंदी नहीं होती. इसके अलावा, की हैरारकी में बदलाव किया जाता है और इसे आंशिक तौर पर इस हार्डवेयर में ले जाया जाता है. इससे, सॉफ़्टवेयर को एक सबकी वापस की जा सकती है. इसका इस्तेमाल उन टास्क के लिए किया जा सकता है जिनके लिए इनलाइन क्रिप्टो इंजन का इस्तेमाल नहीं किया जा सकता.

की हैरारकी

की डिराइव करने वाले फ़ंक्शन (केडीएफ़) जैसे कि एचकेडीएफ़ का इस्तेमाल करके, अन्य की से की डिराइव की जा सकती हैं. इससे की हैरारकी बनती है.

नीचे दिए गए डायग्राम में, एफ़बीई के लिए सामान्य की हैरारकी दिखाई गई है. इसमें हार्डवेयर-रैप्ड की का इस्तेमाल नहीं किया गया है:

एफ़बीई क्लास की, रॉ एन्क्रिप्शन की होती है. Android, इसे Linux कर्नेल को पास करता है, ताकि एन्क्रिप्ट की गई डायरेक्ट्री के किसी खास सेट को अनलॉक किया जा सके. जैसे, Android के किसी खास उपयोगकर्ता के लिए, क्रेडेंशियल-एन्क्रिप्ट किया गया स्टोरेज. (कर्नेल में, इस की को एफ़एससीआरवाईपीटी मास्टर की कहा जाता है.) कर्नेल, इस की से ये सबकी डिराइव करता है:

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

इसके उलट, नीचे दिए गए डायग्राम में, एफ़बीई के लिए की हैरारकी दिखाई गई है. इसमें हार्डवेयर-रैप्ड की का इस्तेमाल किया गया है:

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

• inline_encryption_key डिराइव करने और इसे सीधे इनलाइन क्रिप्टो इंजन के कीस्लॉट में प्रोग्राम करने के लिए एक इंटरफ़ेस. इससे, सॉफ़्टवेयर के पास रॉ की का ऐक्सेस न होने पर भी, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट/डिक्रिप्ट किया जा सकता है. Android के सामान्य कर्नेल में, यह इंटरफ़ेस blk_crypto_ll_ops::keyslot_program ऑपरेशन से जुड़ा होता है. इसे स्टोरेज ड्राइवर से लागू किया जाना चाहिए.
• sw_secret ("सॉफ़्टवेयर सीक्रेट" \-- इसे पहले "रॉ सीक्रेट" कहा जाता था) डिराइव करने और वापस करने के लिए एक इंटरफ़ेस. यह वह की है जिसका इस्तेमाल Linux फ़ाइल के कॉन्टेंट को एन्क्रिप्ट करने के अलावा, अन्य सभी चीज़ों के लिए सबकी डिराइव करने के लिए करता है. Android के सामान्य कर्नेल में, यह इंटरफ़ेस blk_crypto_ll_ops::derive_sw_secret ऑपरेशन से जुड़ा होता है. इसे स्टोरेज ड्राइवर से लागू किया जाना चाहिए.

रॉ स्टोरेज की से inline_encryption_key और sw_secret डिराइव करने के लिए, हार्डवेयर को क्रिप्टोग्राफ़िक तरीके से सुरक्षित केडीएफ़ का इस्तेमाल करना होगा. इस केडीएफ़ को क्रिप्टोग्राफ़ी के सबसे सही तरीकों का पालन करना होगा. इसकी सुरक्षा की ताकत कम से कम 256 बिट होनी चाहिए. इसका मतलब है कि बाद में इस्तेमाल किए जाने वाले किसी भी एल्गोरिदम के लिए यह काफ़ी है. साथ ही, हर तरह की सबकी डिराइव करते समय, इसे अलग-अलग लेबल और कॉन्टेक्स्ट का इस्तेमाल करना होगा, ताकि यह पक्का किया जा सके कि डिराइव की गई सबकी क्रिप्टोग्राफ़िक तरीके से अलग-अलग हैं. इसका मतलब है कि इनमें से किसी एक के बारे में जानकारी होने से, दूसरी के बारे में पता नहीं चलता. की स्ट्रेचिंग की ज़रूरत नहीं है, क्योंकि रॉ स्टोरेज की पहले से ही यूनिफ़ॉर्मली रैंडम की होती है.

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

की रैपिंग

हार्डवेयर-रैप्ड की की सुरक्षा से जुड़े लक्ष्यों को पूरा करने के लिए, की रैपिंग के दो टाइप तय किए गए हैं:

• कुछ समय के लिए रैपिंग: हार्डवेयर, रॉ की को एन्क्रिप्ट करने के लिए, ऐसी की का इस्तेमाल करता है जो हर बूट पर रैंडम तरीके से जनरेट होती है. यह की, हार्डवेयर के बाहर सीधे तौर पर नहीं दिखती.
• लंबे समय के लिए रैपिंग: हार्डवेयर, रॉ की को एन्क्रिप्ट करने के लिए, हार्डवेयर में मौजूद एक यूनीक और परसिस्टेंट की का इस्तेमाल करता है. यह की, हार्डवेयर के बाहर सीधे तौर पर नहीं दिखती.

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

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

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

• स्टोरेज की की जनरेट और इंपोर्ट करने के लिए इंटरफ़ेस. ये की, लंबे समय के लिए रैप्ड फ़ॉर्म में वापस की जाती हैं. जनरेट इंटरफ़ेस का इस्तेमाल, vold Android के लिए नए स्टोरेज की जनरेट करने के लिए करता है. इंपोर्ट इंटरफ़ेस का इस्तेमाल, vts_kernel_encryption_test टेस्ट की इंपोर्ट करने के लिए करता है.
• लंबे समय के लिए रैप्ड स्टोरेज की को, कुछ समय के लिए रैप्ड स्टोरेज की में बदलने के लिए एक इंटरफ़ेस. इस इंटरफ़ेस का इस्तेमाल, vold और vts_kernel_encryption_test दोनों, स्टोरेज को अनलॉक करने के लिए करते हैं.

की रैपिंग एल्गोरिदम, लागू करने से जुड़ी जानकारी है. हालांकि, इसमें AES-256-GCM जैसे मज़बूत एईएडी का इस्तेमाल किया जाना चाहिए. साथ ही, इसमें रैंडम आईवी का इस्तेमाल किया जाना चाहिए.

सॉफ़्टवेयर में किए जाने वाले ज़रूरी बदलाव

AOSP में, हार्डवेयर-रैप्ड की के लिए बुनियादी फ़्रेमवर्क पहले से मौजूद है. इसमें, उपयोगकर्ता स्पेस कॉम्पोनेंट जैसे कि vold में सपोर्ट के साथ-साथ, Linux कर्नेल में blk-crypto, fscrypt और dm-default-key में सपोर्ट शामिल है.

Linux कर्नेल में किए जाने वाले बदलाव

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

android17 और इसके बाद के वर्शन वाले कर्नेल के लिए:

• में BLK_CRYPTO_KEY_TYPE_HW_WRAPPED सेट करेंblk_crypto_profile::key_types_supported.
• blk_crypto_ll_ops::keyslot_program में, हार्डवेयर-रैप्ड की को प्रोग्राम करने के लिए सपोर्ट जोड़ें.
• blk_crypto_ll_ops::keyslot_evict में, हार्डवेयर-रैप्ड की को हटाने के लिए सपोर्ट जोड़ें.
• blk_crypto_ll_ops::derive_sw_secret, blk_crypto_ll_ops::import_key, blk_crypto_ll_ops::generate_key, और blk_crypto_ll_ops::prepare_key लागू करें.

android14, android15, और android16 कर्नेल के लिए:

• में BLK_CRYPTO_KEY_TYPE_HW_WRAPPED सेट करेंblk_crypto_profile::key_types_supported.
• blk_crypto_ll_ops::keyslot_program में, हार्डवेयर-रैप्ड की को प्रोग्राम करने के लिए सपोर्ट जोड़ें.
• blk_crypto_ll_ops::keyslot_evict में, हार्डवेयर-रैप्ड की को हटाने के लिए सपोर्ट जोड़ें.
• blk_crypto_ll_ops::derive_sw_secret लागू करें.

android12 और android13 कर्नेल के लिए:

• में BLK_CRYPTO_FEATURE_WRAPPED_KEYS सेट करेंblk_keyslot_manager::features.
• blk_ksm_ll_ops::keyslot_program में, हार्डवेयर-रैप्ड की को प्रोग्राम करने के लिए सपोर्ट जोड़ें.
• blk_ksm_ll_ops::keyslot_evict में, हार्डवेयर-रैप्ड की को हटाने के लिए सपोर्ट जोड़ें.
• blk_ksm_ll_ops::derive_raw_secret लागू करें.

android11 कर्नेल के लिए:

• में BLK_CRYPTO_FEATURE_WRAPPED_KEYS सेट करेंkeyslot_manager::features.
• keyslot_mgmt_ll_ops::keyslot_program में, हार्डवेयर-रैप्ड की को प्रोग्राम करने के लिए सपोर्ट जोड़ें.
• keyslot_mgmt_ll_ops::keyslot_evict में, हार्डवेयर-रैप्ड की को हटाने के लिए सपोर्ट जोड़ें.
• keyslot_mgmt_ll_ops::derive_raw_secret लागू करें.

KeyMint में किए जाने वाले बदलाव (लेगसी)

हार्डवेयर-रैप्ड की (wrappedkey) के मौजूदा वर्शन में, हार्डवेयर-रैप्ड की को जनरेट करने, इंपोर्ट करने, और तैयार करने के लिए, Linux कर्नेल ioctl BLKCRYPTOGENERATEKEY, BLKCRYPTOIMPORTKEY, और BLKCRYPTOPREPAREKEY का इस्तेमाल किया जाता है. ये ioctl, struct blk_crypto_ll_ops में मौजूद तरीकों से जुड़े होते हैं. स्टोरेज ड्राइवर, इन तरीकों को लागू करता है और अनुरोध किए गए ऑपरेशन को पूरा करने के लिए, की रैपिंग हार्डवेयर से कम्यूनिकेट करता है. इन ioctl के बारे में ज़्यादा जानने के लिए, Linux कर्नेल का दस्तावेज़ देखें..

ये ioctl, Linux 6.16 में जोड़े गए थे. जिन डिवाइसों को ioctl-आधारित समाधान के साथ लॉन्च नहीं किया गया था उनमें Android KeyMint (या पहले KeyMaster) का इस्तेमाल करके, एक अलग समाधान का इस्तेमाल किया जाता है. लेगसी समाधान (wrappedkey_v0), मेनलाइन Linux कर्नेल या मौजूदा समाधान के साथ काम नहीं करता. लेगसी समाधान में, KeyMint के इन फ़ंक्शन का इस्तेमाल किया जाता है:

• की जनरेट करने और इंपोर्ट करने, दोनों के लिए TAG_STORAGE_KEY के लिए सपोर्ट.
• convertStorageKeyToEphemeral तरीके के लिए सपोर्ट.

KeyMint के इस फ़ंक्शन की ज़रूरत सिर्फ़ उन डिवाइसों पर होती है जो लेगसी समाधान का इस्तेमाल करते हैं. यह fstab फ़ाइल में wrappedkey_v0 से जुड़ा होता है.

जिन डिवाइसों में मौजूदा समाधान का इस्तेमाल किया जाता है उन्हें KeyMint के इस फ़ंक्शन को लागू करने की ज़रूरत नहीं होती. यह fstab फ़ाइल में wrappedkey से जुड़ा होता है.

रैप्ड की की जांच करना

रॉ की की मदद से एन्क्रिप्शन की तुलना में, हार्डवेयर-रैप्ड की की मदद से एन्क्रिप्शन की जांच करना मुश्किल है. हालांकि, टेस्ट की इंपोर्ट करके और हार्डवेयर से की डिराइव करने की प्रोसेस को फिर से लागू करके, इसकी जांच की जा सकती है. इसे में vts_kernel_encryption_testलागू किया गया है. इस टेस्ट को चलाने के लिए, यह कमांड चलाएं:

atest -v vts_kernel_encryption_test

टेस्ट लॉग पढ़ें और पुष्टि करें कि हार्डवेयर-रैप्ड की के टेस्ट केस (उदाहरण के लिए, FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy और DmDefaultKeyTest.TestHwWrappedKey) को स्किप नहीं किया गया है. ऐसा इसलिए, क्योंकि हार्डवेयर-रैप्ड की के लिए सपोर्ट का पता न चलने पर भी, टेस्ट के नतीजे "पास" ही दिखते हैं.

डिफ़ॉल्ट रूप से, vts_kernel_encryption_test यह मानकर चलता है कि हार्डवेयर, केडीएफ़ को लागू करता है. इसे kdf1 कहा जाता है. यह केडीएफ़, NIST SP 800-108 के केडीएफ़ के काउंटर मोड फ़ैमिली से जुड़ा है. साथ ही, यह स्यूडोरैंडम फ़ंक्शन के तौर पर AES-256-CMAC का इस्तेमाल करता है. सीएमएसी के बारे में ज़्यादा जानने के लिए, सीएमएसी की खास जानकारी देखें. केडीएफ़, हर सबकी डिराइव करते समय, खास कॉन्टेक्स्ट और लेबल का इस्तेमाल करता है. हार्डवेयर को इस केडीएफ़ को लागू करना चाहिए. इसमें, हर सबकी डिराइव करते समय, कॉन्टेक्स्ट, लेबल, और फ़िक्स्ड इनपुट स्ट्रिंग के फ़ॉर्मैट का सही विकल्प शामिल होना चाहिए.

हालांकि, vts_kernel_encryption_test में, kdf2 से लेकर kdf4 तक के अन्य केडीएफ़ भी लागू किए जाते हैं. ये kdf1 की तरह ही सुरक्षित हैं. इनमें सिर्फ़ कॉन्टेक्स्ट, लेबल, और फ़िक्स्ड इनपुट स्ट्रिंग के फ़ॉर्मैट का अंतर है. ये सिर्फ़ अलग-अलग हार्डवेयर के लिए मौजूद हैं.

जिन डिवाइसों में किसी दूसरे केडीएफ़ का इस्तेमाल किया जाता है उनके लिए, PRODUCT_VENDOR_PROPERTIES में ro.crypto.hw_wrapped_keys.kdf सिस्टम प्रॉपर्टी को, टेस्ट के सोर्स कोड में तय किए गए केडीएफ़ के नाम पर सेट करें. इससे vts_kernel_encryption_test, kdf1 के बजाय उस केडीएफ़ की जांच करता है. उदाहरण के लिए, kdf2 चुनने के लिए, यह कमांड इस्तेमाल करें:

PRODUCT_VENDOR_PROPERTIES += ro.crypto.hw_wrapped_keys.kdf=kdf2

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

रैप्ड की की सुविधा चालू करना

जब डिवाइस में हार्डवेयर-रैप्ड की के लिए सपोर्ट सही तरीके से काम कर रहा हो, तब डिवाइस की fstab फ़ाइल में ये बदलाव करें, ताकि Android, एफ़बीई और मेटाडेटा एन्क्रिप्शन के लिए इसका इस्तेमाल कर सके:

• एफ़बीई: wrappedkey (या लेगसी वर्शन के लिए wrappedkey_v0) फ़्लैग को fileencryption पैरामीटर में जोड़ें. उदाहरण के लिए, fileencryption=::inlinecrypt_optimized+wrappedkey का इस्तेमाल करें. ज़्यादा जानकारी के लिए, एफ़बीई का दस्तावेज़ देखें.
• मेटाडेटा एन्क्रिप्शन: wrappedkey फ़्लैग (या wrappedkey_v0 लेगसी वर्शन के लिए) को metadata_encryption पैरामीटर में जोड़ें. उदाहरण के लिए, metadata_encryption=:wrappedkey का इस्तेमाल करें. ज़्यादा जानकारी के लिए, मेटाडेटा एन्क्रिप्शन का दस्तावेज़ देखें.

हर मामले में, फ़्लैग के दो वर्शन होते हैं:

• wrappedkey, Android 17 और इसके बाद के वर्शन पर काम करता है. इससे हार्डवेयर-रैप्ड की का मौजूदा वर्शन चालू होता है. यह वर्शन मेनलाइन Linux कर्नेल के साथ काम करता है.
• wrappedkey_v0, Android 11 और इसके बाद के वर्शन पर काम करता है. इससे हार्डवेयर-रैप्ड की का लेगसी वर्शन चालू होता है. यह वर्शन, मेनलाइन Linux कर्नेल के साथ काम नहीं करता. यह KeyMint के ज़रिए कुछ ऑपरेशन प्रॉक्सी करता है और डिस्क पर नॉन-स्टैंडर्ड फ़ॉर्मैट का इस्तेमाल करता है. ज़्यादा जानकारी के लिए, KeyMint में किए जाने वाले बदलाव (लेगसी) देखें.

Android 17 या इसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों पर, wrappedkey का इस्तेमाल करें.

जिन डिवाइसों को पहले ही wrappedkey_v0 के साथ लॉन्च किया गया है उनमें, बैकवर्ड कंपैटिबिलिटी के लिए wrappedkey_v0 का इस्तेमाल जारी रखें.