Android 11 में, A/B अपडेट का इस्तेमाल करके ओटीए अपडेट लागू किए जा सकते हैं या वर्चुअल A/B अपडेट करने के तरीके. इन्हें इनके साथ जोड़ा जाता है RecoverySystem क्लास विधियों का उपयोग करें. ओटीए अपडेट लागू करने के लिए, डिवाइस को फिर से चालू करने के बाद, फिर से चालू करने की प्रोसेस (आरओआर) से, डिवाइस के क्रेडेंशियल एन्क्रिप्टेड (सीई) स्टोरेज को अनलॉक कर दिया जाता है.
हालांकि, पार्टनर इस प्रोसेस को, लागू होने वाली ओटीए सिस्टम की सुविधा के साथ जोड़ सकते हैं Android 11 में, डिवाइस के कुछ समय से इस्तेमाल में न होने पर अपडेट Android 12 के पार्टनर को किसी अतिरिक्त ओटीए सिस्टम की ज़रूरत नहीं है सुविधा. आरओआर प्रोसेस से उपयोगकर्ताओं को ज़्यादा सुरक्षा और सुविधा मिलती है, क्योंकि ये अपडेट डिवाइस के कुछ समय तक इस्तेमाल में न रहने के दौरान किए जा सकते हैं. हालांकि, Android 12 के लिए एक से ज़्यादा क्लाइंट और सर्वर पर आधारित अपडेट की सुविधाएं, एक साथ डिवाइस उपलब्ध कराती हैं हार्डवेयर-लेवल टाइप की सुरक्षा.
हालांकि, android.hardware.reboot_escrow के लिए आपको डिवाइस की अनुमति देनी होगी
Android 11 में RoR के साथ काम करती है, तो इसे चालू करने के लिए आपको ऐसा करने की ज़रूरत नहीं है
Android 12 और उसके बाद के वर्शन में सर्वर के हिसाब से आरओआर की सुविधा देता है, क्योंकि
एचएएल का इस्तेमाल नहीं करते.
बैकग्राउंड
Android 7 और Android पर काम करने वाले डायरेक्ट बूट की सुविधा, इससे डिवाइस पर मौजूद ऐप्लिकेशन, सीई स्टोरेज को अनलॉक होने से पहले चालू हो जाते हैं उपयोगकर्ता है. डायरेक्ट बूट सहायता के लागू होने से उपयोगकर्ताओं को बेहतर आपको लॉक स्क्रीन नॉलेज फ़ैक्टर (LSKF) से पहले का अनुभव चाहिए बूट के बाद.
आरओआर की मदद से किसी डिवाइस पर सभी ऐप्लिकेशन के CE स्टोरेज को अनलॉक किया जा सकता है. इसमें ये चीज़ें भी शामिल हैं जो डायरेक्ट बूट सुविधा का समर्थन नहीं करते हैं, क्योंकि ओटीए अपडेट. यह सुविधा उपयोगकर्ताओं को अपने सभी इंस्टॉल किए गए ऐप्लिकेशन, सिस्टम को फिर से चालू करने के बाद.
थ्रेट मॉडल
आरओआर लागू करने से यह पक्का करना ज़रूरी है कि जब कोई डिवाइस हमलावर के है, तो हमलावर के लिए उपयोगकर्ता के CE- एन्क्रिप्ट (सुरक्षित) किया गया डेटा, भले ही डिवाइस चालू हो, सीई स्टोरेज अनलॉक हो, और ओटीए अपडेट मिलने के बाद, उपयोगकर्ता डिवाइस को अनलॉक कर सकता है. इनसाइडर हालांकि, जब हमलावर क्रिप्टोग्राफ़िक साइनिंग पासकोड ब्रॉडकास्ट करें.
खास तौर पर, किसी ऐसे हमलावर को CE स्टोरेज को पढ़ना नहीं चाहिए जिसके पास साथ ही, इस डिवाइस में ये काम किए जा सकते हैं और कुछ सीमाएं भी तय की गई हैं:
क्षमताएं
- आर्बिट्रेरी मैसेज पर हस्ताक्षर करने के लिए, किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल कर सकता है.
- इसकी वजह से डिवाइस पर ओटीए अपडेट मिल सकता है.
- किसी भी हार्डवेयर (जैसे कि ऐप्लिकेशन प्रोसेसर, या फ़्लैश मेमोरी) - हालांकि, जैसा कि नीचे सीमाओं में बताया गया है. (हालांकि, इस तरह के बदलाव में कम से कम एक घंटे की देरी और पावर साइकल जो रैम के कॉन्टेंट को खत्म कर देता है.)
सीमाएं
- छेड़छाड़ से बचाने वाले हार्डवेयर के काम करने के तरीके में बदलाव नहीं कर सकता. उदाहरण के लिए, Titan M).
- लाइव डिवाइस की रैम नहीं पढ़ी जा सकती.
- उपयोगकर्ता के क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) या किसी और वजह का अनुमान नहीं लगा सका उन्हें डाला जा सकता है.
समाधान
Android 12 के आरओआर अपडेट सिस्टम से सुरक्षा मिलती है करने की पहचान करने में मदद मिलती है. साथ ही, उपयोगकर्ता के डिवाइस पर मौजूद पासवर्ड और पिन डिवाइस में ही रहते हैं—उन्हें Google के सर्वर पर न तो भेजा जाता है और न ही वहां सेव किया जाता है. यह उस प्रोसेस की खास जानकारी है जिससे पक्का होता है कि दिए गए सुरक्षा लेवल, हार्डवेयर-आधारित, डिवाइस-लेवल के RoR सिस्टम की तरह:
- Android, किसी डिवाइस पर सेव किए गए डेटा पर क्रिप्टोग्राफ़िक सुरक्षा लागू करता है.
- सारे डेटा को भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट में स्टोर की गई कुंजियों से सुरक्षित किया जाता है (टीईई).
- टीईई सिर्फ़ तब कुंजियों को रिलीज़ करता है, जब ऑपरेटिंग सिस्टम ठीक से काम कर रहा होता है क्रिप्टोग्राफ़िक ऑथेंटिकेशन (पुष्टि किया गया बूट).
- Google के सर्वर पर चल रही आरओआर सेवा, सीक्रेट स्टोर करके CE डेटा को सुरक्षित करती है जिसे सिर्फ़ सीमित समय के लिए वापस लाया जा सकता है. यह सुविधा, Android नेटवर्क पर काम करती है.
- उपयोगकर्ता के पिन की मदद से सुरक्षित की गई क्रिप्टोग्राफ़िक कुंजी का इस्तेमाल, डिवाइस को अनलॉक करने के लिए किया जाता है
और CE स्टोरेज को डिक्रिप्ट करें.
- जब रात में डिवाइस को फिर से चालू करने का समय शेड्यूल किया जाता है, तो Android, उपयोगकर्ता को साइन इन करने का अनुरोध करता है फिर एक सिंथेटिक पासवर्ड (SP) का हिसाब लगाता है.
- इसके बाद, यह एसपी को दो बार एन्क्रिप्ट करता है: पहली बार, रैम में सेव की गई
K_sकुंजी से और फिर से TEE में सेव की गईK_kकुंजी के साथ. - डबल-एन्क्रिप्टेड एसपी को डिस्क में सेव किया जाता है और एसपी को रैम से वाइप कर दिया जाता है. दोनों कुंजियां हाल ही में जनरेट की जाती हैं और सिर्फ़ एक बार फिर से चालू करने के लिए इस्तेमाल की जाती हैं.
- फिर से चालू होने पर, Android, सर्वर को
K_sअसाइन कर देता है. रसीद के साथK_k, डिस्क पर सेव होने से पहले एन्क्रिप्ट (सुरक्षित) हो जाता है. - डिवाइस फिर से चालू होने के बाद, Android
K_kका इस्तेमाल करके रसीद को डिक्रिप्ट करता है. इसके बाद, इसे इस पते पर भेज देता है:K_sको फिर से पाने के लिए सर्वर.- डिस्क पर सेव किए गए एसपी को डिक्रिप्ट करने के लिए,
K_kऔरK_sका इस्तेमाल किया जाता है. - Android, CE स्टोरेज को अनलॉक करने और ऐप्लिकेशन को सामान्य तरीके से चालू करने के लिए, एसपी का इस्तेमाल करता है.
K_kऔरK_sको खारिज कर दिया गया है.
- डिस्क पर सेव किए गए एसपी को डिक्रिप्ट करने के लिए,
आपके फ़ोन को सुरक्षित रखने वाले अपडेट अपनी सुविधा के हिसाब से कभी भी किए जा सकते हैं आपके लिए: जब आप सोते हैं.
सिम-पिन को फिर से चलाने की सुविधा
कुछ स्थितियों में सिम कार्ड के पिन कोड की पुष्टि कैश मेमोरी से की जाती है, इस प्रोसेस को 'सिम-पिन फिर से चलाएं' कहते हैं.
चालू पिन वाले सिम कार्ड को बिना किसी रुकावट के पिन कोड से भी गुज़रना होगा मोबाइल डेटा को पहले जैसा करने के लिए, डिवाइस को फिर से चालू करने के बाद पुष्टि करना (सिम-पिन को फिर से चलाना) कनेक्टिविटी (फ़ोन कॉल, एसएमएस मैसेज, और डेटा सेवाओं के लिए ज़रूरी). सिम का पिन और उससे मेल खाने वाले सिम कार्ड की जानकारी (आईसीआईडी और सिम स्लॉट नंबर) एक साथ सुरक्षित तरीके से सेव करके रखा जाता है. सेव किए गए पिन को वापस पाया और इस्तेमाल किया जा सकता है और बिना निगरानी के फिर से चालू होने के बाद ही पुष्टि करने के लिए कहें. अगर डिवाइस इस स्थिति में, सिम के पिन को LSKF से सुरक्षित की गई कुंजियों के साथ सेव किया जाता है. अगर सिम में अगर पिन चालू है, तो आरओआर सर्वर के साथ इंटरैक्शन के लिए वाई-फ़ाई कनेक्शन ज़रूरी है को अपडेट करता है, जो सर्वर-आधारित RoR के लिए मोबाइल इंटरनेट कनेक्शन) से जुड़ा होता है.
सिम के पिन को फिर से एन्क्रिप्ट (सुरक्षित) किया जाता है और उसे सेव किया जाता है, जब भी उपयोगकर्ता किसी सुविधा को चालू करता है, पुष्टि या बदलाव करता है. इनमें से कोई भी एक होने पर सिम का पिन खारिज कर दिया जाएगा होता है:
- सिम हटाया गया है या उसे रीसेट किया गया है.
- उपयोगकर्ता इस पिन को बंद कर देता है.
- आरओआर से शुरू नहीं किया गया डिवाइस फिर से चालू हुआ है.
सेव किए गए सिम के पिन का इस्तेमाल, आरओआर से फिर से चालू होने के बाद एक बार ही किया जा सकता है. यह बहुत कम समय (20 सेकंड) के लिए ही मान्य है–अगर सिम की जानकारी कार्ड मिलान. सेव किए गए सिम का पिन, TelephonyManager ऐप्लिकेशन के साथ हमेशा रहता है बाहरी मॉड्यूल से फिर से नहीं पाया जा सकता.
लागू करने के लिए दिशा-निर्देश
Android 12 में, एक से ज़्यादा क्लाइंट और सर्वर पर आधारित आरओआर को जब पार्टनर ओटीए अपडेट पुश करते हैं, तो फ़ंक्शन से उन्हें कम लोड मिलता है. ज़रूरी अपडेट डिवाइस के बंद रहने के दौरान हो सकते हैं, जैसे कि सोने के तय घंटे.
यह पक्का करने के लिए कि इस समयावधि के दौरान ओटीए अपडेट होने की वजह से लोगों को परेशानी न हो,
रोशनी के उत्सर्जन को कम करने के लिए, गहरे रंग वाले मोड का इस्तेमाल किया जा रहा है. ऐसा करने के लिए, डिवाइस के पास
स्ट्रिंग वजह unattended के लिए बूटलोडर की खोज. अगर unattended, true है, तो
डिवाइस को गहरे रंग वाले मोड में रखें. ध्यान दें कि यह हर OEM की ज़िम्मेदारी है
इससे साउंड और लाइट के उत्सर्जन को कम किया जा सकेगा.
अगर आपको Android 12 में अपग्रेड करना है या लॉन्च हो रहा है Android 12 वाले डिवाइसों पर, आपको कुछ भी करने की ज़रूरत नहीं है आरओआर की नई सुविधा लागू की जा सकती है.
एक से ज़्यादा क्लाइंट वाले फ़्लो में, isPreparedForUnattendedUpdate, वाला एक नया कॉल है,
नीचे दी गई जानकारी देखें:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
आपको इसे लागू करने की ज़रूरत नहीं है, क्योंकि एचएएल अब काम नहीं करता Android 12.
टेलीफ़ोनीमैनेजर
डिवाइस को फिर से चालू होने पर, ओटीए क्लाइंट TelephonyManager सिस्टम एपीआई को शुरू करता है
Android 12 में. यह एपीआई, कैश मेमोरी में सेव किए गए सभी पिन कोड को यहां से ले जाता है
AVAILABLE स्थिति को REBOOT_READY राज्य में बदला जाता है. TelephonyManager सिस्टम
एपीआई को मौजूदा REBOOT से सुरक्षित किया गया है
मेनिफ़ेस्ट अनुमति.
/**
* The unattended reboot was prepared successfully.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;
/**
* The unattended reboot was prepared, but the user will need to manually
* enter the PIN code of at least one SIM card present in the device.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;
/**
* The unattended reboot was not prepared due to generic error.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;
/** @hide */
@Retention(RetentionPolicy.SOURCE)
@IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
value = {
PREPARE_UNATTENDED_REBOOT_SUCCESS,
PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
PREPARE_UNATTENDED_REBOOT_ERROR
})
public @interface PrepareUnattendedRebootResult {}
/**
* Prepare TelephonyManager for an unattended reboot. The reboot is
* required to be done shortly after the API is invoked.
*
* Requires system privileges.
*
* <p>Requires Permission:
* {@link android.Manifest.permission#REBOOT}
*
* @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
* {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
* at least one SIM card for which the user needs to manually enter the PIN
* code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
* of error.
* @hide
*/
@SystemApi
@RequiresPermission(android.Manifest.permission.REBOOT)
@PrepareUnattendedRebootResult
public int prepareForUnattendedReboot()
TelephonyManager सिस्टम एपीआई का इस्तेमाल, खास अधिकार वाले APKs के लिए किया जाता है.
टेस्ट करना
नए एपीआई की जांच करने के लिए, इस निर्देश को एक्ज़ीक्यूट करें:
adb shell cmd phone unattended-reboot
यह निर्देश सिर्फ़ तब काम करता है, जब शेल रूट (adb root) के तौर पर चल रहा हो.
सिर्फ़ Android 11 के लिए
इस पेज का बाकी हिस्सा, Android 11 पर लागू होता है.
जुलाई 2020 से, आरओआर एचएएल को लागू करने की दो कैटगरी हैं:
- अगर SoC हार्डवेयर, सभी रीबूट में रैम के हिसाब से काम करता है, तो OEM एओएसपी (डिफ़ॉल्ट रैम एस्क्रो) में डिफ़ॉल्ट रूप से लागू किया जाता है.
- अगर डिवाइस हार्डवेयर या SoC, सुरक्षित हार्डवेयर एनक्लेव (अलग-अलग तरह) के साथ काम करता है
को-प्रोसेसर उपलब्ध कराता है, तो उसे अलग-अलग ऐप्लिकेशन
फ़ॉलो किया जा रहा है:
- मुख्य सीपीयू (CPU) रीबूट का पता लगाने में सक्षम बनें.
- हार्डवेयर टाइमर का ऐसा सोर्स रखें जो फिर से चालू होने के दौरान भी बना रहता है. इसका मतलब है कि एनक्लेव ऐसा होना चाहिए जो फिर से चालू होने का पता लगा सके और डिवाइस को फिर से चालू करें.
- किसी एस्क्रो की गई कुंजी को एनक्लेव रैम/रोम में इस तरह सेव करने की सुविधा नहीं देती कि वह को ऑफ़लाइन हमलों से फिर से ठीक किया जा सकता है. उसे RoR कुंजी को इस तरह से सेव करना चाहिए कि अंदर के लोगों या हमलावरों के लिए उसे वापस पाना नामुमकिन हो जाता है.
डिफ़ॉल्ट रैम वाला एस्क्रो
एओएसपी ने रैम परसिस्टेंस का इस्तेमाल करके, आरओआर एचएएल को लागू किया है. यह तरीका काम करे, इसके लिए OEM को यह पक्का करना होगा कि उनके SoCs में रैम का एक जैसा बना रहे चालू किया जाता है. कुछ SoC, रैम के कॉन्टेंट को फिर से चालू होने के दौरान सेव नहीं कर पाते. इसलिए, ओईएम को सलाह दी जाती है कि वे इस डिफ़ॉल्ट एचएएल को चालू करने से पहले अपने SoC पार्टनर से सलाह लें. नीचे दिए गए सेक्शन में इसके लिए कैननिकल रेफ़रंस दिया गया है.
आरओआर का इस्तेमाल करके ओटीए अपडेट का फ़्लो
फ़ोन पर मौजूद OTA क्लाइंट ऐप्लिकेशन में
Manifest.permission.REBOOT
और कॉल करने के लिए Manifest.permission.RECOVERY अनुमतियां
आरओआर लागू करता है. इस शर्त को पूरा करने के बाद,
अपडेट करने के लिए यह तरीका अपनाएं:
- OTA क्लाइंट ऐप्लिकेशन, अपडेट को डाउनलोड करता है.
- OTA क्लाइंट ऐप्लिकेशन से
RecoverySystem#prepareForUnattendedUpdateको कॉल किया जाता है जो वह उपयोगकर्ता को उसके पिन, पैटर्न या पासवर्ड के लिए संकेत देने के लिए ट्रिगर करता है अगली बार अनलॉक करने के दौरान स्क्रीन लॉक कर सकते हैं. - उपयोगकर्ता, लॉकस्क्रीन पर डिवाइस को अनलॉक करता है और डिवाइस तैयार है अपडेट लागू करने के लिए.
- OTA क्लाइंट ऐप्लिकेशन से,
RecoverySystem#rebootAndApplyको कॉल किया जाता है. यह कॉल तुरंत रीस्टार्ट ट्रिगर करता है.
इस फ़्लो के खत्म होने पर, डिवाइस फिर से चालू हो जाता है और आरओआर मैकेनिज़्म, क्रेडेंशियल एन्क्रिप्ट किए गए (सीई) स्टोरेज को अनलॉक करता है. ऐप्लिकेशन के लिए, यह किसी सामान्य उपयोगकर्ता के अनलॉक की तरह दिखता है, इसलिए उन्हें सभी सिग्नल मिलते हैं, जैसे कि ACTION_LOCKED_BOOT_COMPLETED और ACTION_BOOT_COMPLETED जो वे आम तौर पर करते हैं.
प्रॉडक्ट कॉन्फ़िगरेशन में बदलाव करें
Android 11 की आरओआर सुविधा के साथ काम करने वाले प्रॉडक्ट के तौर पर मार्क किए गए प्रॉडक्ट में, रीबूटऐस्करो एचएएल को लागू करना और सुविधा मार्कर की एक्सएमएल फ़ाइल शामिल करना. डिफ़ॉल्ट रूप से, यह तरीका उन डिवाइस पर ठीक से काम करता है जो वॉर्म रीबूट का इस्तेमाल करते हैं (जब रीबूट के दौरान DRAM की पावर चालू रहती है).
एस्क्रो सुविधा को फिर से चालू करने का मार्कर
सुविधा का मार्कर भी मौजूद होना चाहिए:
PRODUCT_COPY_FILES += \
frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml
डिफ़ॉल्ट तौर पर फिर से चालू करने के लिए एस्क्रो एचएएल लागू करना
डिफ़ॉल्ट तरीके का इस्तेमाल करने के लिए, आपको 65536 (0x10000) बाइट रिज़र्व करना होगा. कोई तारीख नहीं इन बाइट को नॉन-वोलाटाइल स्टोरेज में लिखो, ताकि यह पक्का किया जा सके कि सिक्योरिटी प्रॉपर्टी बने रहें.
Linux कर्नेल डिवाइस ट्री में बदलाव
Linux कर्नेल के डिवाइस ट्री में, आपको pmem क्षेत्र के लिए मेमोरी रिज़र्व करनी होगी.
यहां दिए गए उदाहरण में, 0x50000000 को रिज़र्व किया गया है:
reserved-memory {
my_reservation@0x50000000 {
no-map;
reg = <0x50000000 0x10000>;
}
}
reboot_escrow@0 {
compatible = "pmem-region";
reg = <0x50000000 0x10000>;
};
पुष्टि करें कि ब्लॉक डायरेक्ट्री में आपके पास इस तरह का नाम वाला नया डिवाइस है
/dev/block/pmem0 (जैसे कि pmem1 या pmem2).
Device.mk में किए गए बदलाव
यह मानते हुए कि पिछले चरण में मौजूद आपके नए डिवाइस का नाम pmem0 है, आपको ऐसा करना होगा
पक्का करें कि vendor/<oem>/<product>/device.mk में ये नई एंट्री जोड़ दी जाएं:
# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
android.hardware.rebootescrow-service.default
SELinux नियम
डिवाइस के file_contexts में इन नई एंट्री को जोड़ें:
/dev/block/pmem0 u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default u:object_r:hal_rebootescrow_default_exec:s0