Android 11 में, ओटीए अपडेट लागू करने के लिए, A/B अपडेट या वर्चुअल A/B अपडेट तरीके का इस्तेमाल किया जा सकता है. साथ ही, इसे RecoverySystem क्लास के तरीकों के साथ इस्तेमाल किया जा सकता है. ओटीए अपडेट लागू करने के लिए, डिवाइस को फिर से चालू करने के बाद, फिर से चालू करने पर फिर से चालू करने (आरओआर) से डिवाइस का क्रेडेंशियल एन्क्रिप्टेड (सीई) स्टोरेज अनलॉक हो जाता है.
पार्टनर इस प्रोसेस को ओटीए सिस्टम की सुविधा के साथ जोड़ सकते हैं. यह सुविधा, Android 11 पर डिवाइस के कुछ समय से इस्तेमाल में न होने पर अपडेट लागू करती है. हालांकि, Android 12 में पार्टनर को किसी अन्य ओटीए सिस्टम सुविधा की ज़रूरत नहीं होती. आरओआर प्रोसेस से लोगों को ज़्यादा सुरक्षा और सुविधा मिलती है, क्योंकि डिवाइस के इस्तेमाल में न होने पर ये अपडेट किए जा सकते हैं. वहीं, Android 12 के मल्टी-क्लाइंट और सर्वर पर आधारित अपडेट से जुड़ी सुविधाएं, डिवाइस के हार्डवेयर लेवल की सुरक्षा देती हैं.
Android 11 में आरओआर के साथ काम करने के लिए, आपको android.hardware.reboot_escrow सुविधा के लिए डिवाइस को अनुमति देनी होगी. हालांकि, Android 12 और उसके बाद के वर्शन में सर्वर-आधारित RoR की सुविधा को चालू करने के लिए आपको ऐसा करने की ज़रूरत नहीं है, क्योंकि इनमें एचएएल का इस्तेमाल नहीं किया जाता है.
बैकग्राउंड
Android 7 और Android 7 में, Android पर डायरेक्ट बूट की सुविधा काम करती है. इसकी मदद से, किसी डिवाइस पर मौजूद ऐप्लिकेशन, उपयोगकर्ता के सीई स्टोरेज को अनलॉक किए जाने से पहले चालू हो जाते हैं. डिवाइस को बूट करने की सुविधा लागू करने से, डिवाइस को बूट करने के बाद 'लॉक स्क्रीन नॉलेज फ़ैक्टर (एलएसकेएफ़)' का इस्तेमाल होने से पहले, उपयोगकर्ताओं को बेहतर अनुभव मिलता है.
RoR की मदद से डिवाइस पर सभी ऐप्लिकेशन के CE स्टोरेज को अनलॉक किया जा सकता है. इनमें वे ऐप्लिकेशन भी शामिल हैं जो डायरेक्ट बूट के साथ काम नहीं करते हैं. ऐसा ओटीए अपडेट के बाद, डिवाइस को फिर से चालू करने पर होता है. इस सुविधा से, डिवाइस को फिर से चालू करने के बाद, लोगों को इंस्टॉल किए गए अपने सभी ऐप्लिकेशन से सूचनाएं मिलेंगी.
थ्रेट मॉडल
आरओआर लागू करने से यह पक्का करना ज़रूरी है कि जब कोई डिवाइस हमलावर के हाथ में आ जाए, तो हमलावर के लिए उपयोगकर्ता के सीई से एन्क्रिप्ट (सुरक्षित) किए गए डेटा को वापस पाना बहुत मुश्किल हो. भले ही, डिवाइस चालू हो, सीई स्टोरेज अनलॉक हो, और ओटीए अपडेट मिलने के बाद उपयोगकर्ता, डिवाइस को अनलॉक कर दे. अगर हमलावर को ब्रॉडकास्ट क्रिप्टोग्राफ़िक साइनिंग पासकोड का ऐक्सेस मिल जाता है, तब भी इनसाइडर अटैक रेज़िस्टेंस असरदार होना चाहिए.
खास तौर पर, किसी ऐसे हमलावर को CE स्टोरेज को पढ़ना नहीं चाहिए जिसके पास डिवाइस है. साथ ही, उसके पास ये काम करने की क्षमता और सीमाएं हैं:
क्षमताएं
- आर्बिट्रेरी मैसेज पर हस्ताक्षर करने के लिए, किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल कर सकता है.
- इसकी वजह से डिवाइस पर ओटीए अपडेट मिल सकता है.
- नीचे सीमाओं में बताए गए विकल्पों को छोड़कर, किसी भी हार्डवेयर (जैसे कि ऐप्लिकेशन प्रोसेसर या फ़्लैश मेमोरी) के काम करने के तरीके में बदलाव कर सकता है. (हालांकि, इस तरह के बदलाव में कम से कम एक घंटे की देरी और रैम की सामग्री को खत्म कर देने वाला पावर साइकल, दोनों शामिल होते हैं.)
सीमाएं
- छेड़छाड़ से बचाने वाले हार्डवेयर के काम करने के तरीके में बदलाव नहीं कर सकता. उदाहरण के लिए, Titan M.
- लाइव डिवाइस की रैम नहीं पढ़ी जा सकती.
- उपयोगकर्ता के क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) का अनुमान नहीं लगा पाएगा या किसी अन्य वजह से उन्हें शामिल नहीं कर पाएगा.
समाधान
Android 12 के आरओआर से जुड़ा अपडेट सिस्टम, बेहद खास हमलावरों के ख़िलाफ़ सुरक्षा उपलब्ध कराता है. ऐसा तब भी होता है, जब डिवाइस में सेव किए गए पासवर्ड और पिन, डिवाइस में ही रहते हैं. इस तरह, उन्हें न तो Google के सर्वर पर भेजा जाता है और न ही वहां सेव किया जाता है. यह प्रोसेस की खास जानकारी है, जो यह पक्का करती है कि दिए गए सुरक्षा लेवल, हार्डवेयर-आधारित, डिवाइस-लेवल के आरओआर सिस्टम की तरह हों:
- Android, किसी डिवाइस पर सेव किए गए डेटा पर क्रिप्टोग्राफ़िक सुरक्षा लागू करता है.
- सारे डेटा को ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में सेव की गई कुंजियों से सुरक्षित किया जाता है.
- TEE सिर्फ़ तभी कुंजियां रिलीज़ करता है, जब चल रहा ऑपरेटिंग सिस्टम क्रिप्टोग्राफ़िक ऑथेंटिकेशन (पुष्टि किया गया बूट) को पास कर लेता है.
- Google के सर्वर पर चलने वाली आरओआर सेवा, CE डेटा को सुरक्षित रखती है. इसके लिए, सीक्रेट टोकन को सेव किया जाता है, जिसे सिर्फ़ कुछ समय के लिए वापस पाया जा सकता है. यह सुविधा, Android नेटवर्क पर काम करती है.
- क्रिप्टोग्राफ़िक कुंजी का इस्तेमाल डिवाइस को अनलॉक करने और सीई स्टोरेज को डिक्रिप्ट करने के लिए किया जाता है. यह पासकोड, उपयोगकर्ता के पिन की मदद से सुरक्षित होता है.
- जब डिवाइस को रात भर में फिर से चालू किया जाता है, तो Android, उपयोगकर्ता से पिन डालने का अनुरोध करता है. इसके बाद, यह सिंथेटिक पासवर्ड (SP) का हिसाब लगाता है.
- इसके बाद, यह एसपी को दो बार एन्क्रिप्ट करता है: पहली बार, रैम में सेव की गई
K_sकुंजी से और फिर टीईई में सेव की गईK_kकुंजी से. - डबल-एन्क्रिप्टेड एसपी को डिस्क में सेव किया जाता है और एसपी को रैम से वाइप कर दिया जाता है. दोनों कुंजियां हाल ही में जनरेट की जाती हैं और सिर्फ़ एक बार फिर से चालू करने के लिए इस्तेमाल की जाती हैं.
- फिर से चालू होने पर, Android, सर्वर को
K_sअसाइन कर देता है.K_kवाली रसीद को डिस्क पर सेव करने से पहले एन्क्रिप्ट (सुरक्षित) किया जाता है. - डिवाइस को फिर से चालू करने के बाद, Android रसीद को डिक्रिप्ट करने के लिए
K_kका इस्तेमाल करता है. इसके बाद,K_sको वापस पाने के लिए इसे सर्वर पर भेज देता है.- डिस्क पर सेव किए गए एसपी को डिक्रिप्ट करने के लिए,
K_kऔरK_sका इस्तेमाल किया जाता है. - Android, CE स्टोरेज को अनलॉक करने और ऐप्लिकेशन को सामान्य तरीके से चालू करने के लिए, एसपी का इस्तेमाल करता है.
K_kऔरK_sको खारिज कर दिया गया है.
- डिस्क पर सेव किए गए एसपी को डिक्रिप्ट करने के लिए,
आपके फ़ोन को सुरक्षित रखने वाले अपडेट आपके लिए सुविधाजनक समय पर हो सकते हैं: जब आप सोते समय हों.
सिम-पिन को फिर से चलाने की सुविधा
कुछ स्थितियों में सिम कार्ड के पिन कोड की पुष्टि कैश मेमोरी से की जाती है. इस प्रोसेस को 'सिम-पिन फिर से चलाना' कहते हैं.
मोबाइल इंटरनेट कनेक्शन (फ़ोन कॉल, एसएमएस मैसेज, और डेटा सेवाओं के लिए ज़रूरी है) को फिर से चालू करने के लिए, डिवाइस को फिर से चालू करने के बाद, डिवाइस को फिर से चालू करने के बाद, पिन वाले सिम कार्ड की पुष्टि आसानी से (सिम-पिन से दोबारा करना) करनी होगी. सिम का पिन और उससे मेल खाने वाले सिम कार्ड की जानकारी (आईसीआईडी और सिम स्लॉट नंबर) को एक साथ सुरक्षित तरीके से सेव किया जाता है. डिवाइस को फिर से चालू करने के बाद ही, सेव किए गए पिन का पता लगाया जा सकता है और उसे पुष्टि के लिए इस्तेमाल किया जा सकता है. अगर डिवाइस सुरक्षित है, तो सिम के पिन को LSKF से सुरक्षित की गई कुंजियों के साथ सेव किया जाता है. अगर सिम में पिन चालू है, तो आरओआर सर्वर के साथ इंटरैक्शन करने के लिए ओटीए अपडेट के लिए वाई-फ़ाई कनेक्शन की ज़रूरी है. साथ ही, सर्वर-आधारित आरओआर से डिवाइस को फिर से चालू करने के बाद बुनियादी फ़ंक्शन (सेल्युलर कनेक्टिविटी के साथ) पक्का होता है.
सिम के पिन को दोबारा एन्क्रिप्ट (सुरक्षित) किया जाता है और उसे हर बार सेव किया जाता है. ऐसा तब किया जाता है, जब उपयोगकर्ता इसे चालू करता है, पुष्टि करता है या बदलाव करता है. निम्न में से किसी एक स्थिति में होने पर सिम पिन को छोड़ दिया जाता है:
- सिम हटाया गया है या उसे रीसेट किया गया है.
- उपयोगकर्ता इस पिन को बंद कर देता है.
- आरओआर से शुरू नहीं किया गया डिवाइस फिर से चालू हुआ है.
सेव किए गए सिम के पिन का इस्तेमाल, आरओआर के ज़रिए फिर से चालू किए जाने के बाद सिर्फ़ एक बार किया जा सकता है. साथ ही, इसका इस्तेमाल कुछ ही समय (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 के बाद से एचएएल काम नहीं करता है.
टेलीफ़ोनीमैनेजर
जब Android 12 को फिर से चालू करना हो, तब ओटीए क्लाइंट, TelephonyManager सिस्टम एपीआई को शुरू करता है. यह एपीआई, कैश मेमोरी में सेव किए गए सभी पिन कोड को 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, सुरक्षित हार्डवेयर एनक्लेव (अपनी रैम और ROM वाला अलग सिक्योरिटी को-प्रोसेसर) के साथ काम करता है, तो उसे ये काम भी करने होंगे:
- मुख्य सीपीयू (CPU) रीबूट का पता लगाने में सक्षम बनें.
- हार्डवेयर टाइमर का ऐसा सोर्स रखें जो फिर से चालू होने के दौरान भी बना रहता है. इसका मतलब है कि एन्क्लेव को फिर से चालू होने का पता लगाने और सिस्टम को फिर से चालू करने से पहले सेट किए गए टाइमर की समयसीमा खत्म हो जानी चाहिए.
- किसी एस्क्रो की गई कुंजी को एनक्लेव रैम/रोम में इस तरह सेव करना कि उसे ऑफ़लाइन हमलों से वापस न पाया जा सके. यह ज़रूरी है कि आरओआर कुंजी को इस तरह से सेव किया जाए जिससे इनसाइडर या हमलावरों के लिए उसे वापस पाना नामुमकिन हो.
डिफ़ॉल्ट रैम वाला एस्क्रो
एओएसपी ने रैम परसिस्टेंस का इस्तेमाल करके, आरओआर एचएएल को लागू किया है. यह काम करे, इसके लिए OEM को यह पक्का करना होगा कि उनके SoCs, फिर से चालू होने के दौरान रैम के हिसाब से काम करें. कुछ SoC, रैम से जुड़े कॉन्टेंट को फिर से चालू नहीं कर पाते. इसलिए, OEM को इस डिफ़ॉल्ट एचएएल को चालू करने से पहले, अपने SoC पार्टनर से सलाह लेनी चाहिए. नीचे दिए गए सेक्शन में इसके लिए कैननिकल रेफ़रंस दिया गया है.
आरओआर का इस्तेमाल करके ओटीए अपडेट का फ़्लो
फ़ोन पर मौजूद ओटीए क्लाइंट ऐप्लिकेशन के पास, आरओआर को लागू करने के ज़रूरी तरीकों को कॉल करने के लिए, Manifest.permission.REBOOT
और Manifest.permission.RECOVERY की अनुमतियां होनी चाहिए. इस ज़रूरी शर्त को ध्यान में रखते हुए, अपडेट
करने के लिए ये तरीके अपनाए जाते हैं:
- OTA क्लाइंट ऐप्लिकेशन, अपडेट को डाउनलोड करता है.
- OTA क्लाइंट ऐप्लिकेशन,
RecoverySystem#prepareForUnattendedUpdateपर कॉल करता है. इससे अगली बार अनलॉक करने पर, उपयोगकर्ता को लॉक स्क्रीन पर पिन, पैटर्न या पासवर्ड डालने के लिए कहा जाता है. - उपयोगकर्ता, लॉकस्क्रीन पर डिवाइस को अनलॉक करता है और डिवाइस, अपडेट को लागू करने के लिए तैयार है.
- OTA क्लाइंट ऐप्लिकेशन,
RecoverySystem#rebootAndApplyको कॉल करता है, जो तुरंत रीबूट ट्रिगर होता है.
इस फ़्लो के खत्म होने पर, डिवाइस फिर से चालू हो जाता है और आरओआर सिस्टम, क्रेडेंशियल के एन्क्रिप्ट किए गए (सीई) स्टोरेज को अनलॉक कर देता है. ऐप्लिकेशन को यह सामान्य अनलॉक की तरह दिखता है, ताकि उन्हें ऐसे सभी सिग्नल मिल सकें जो ACTION_LOCKED_BOOT_COMPLETED और ACTION_BOOT_COMPLETED आम तौर पर करते हैं.
प्रॉडक्ट कॉन्फ़िगरेशन में बदलाव करें
Android 11 में, आरओआर की सुविधा के साथ काम करने वाले प्रॉडक्ट के तौर पर मार्क किए गए प्रॉडक्ट में, Escrow HAL को फिर से चालू करने की सुविधा को लागू करना ज़रूरी है. साथ ही, उसमें फ़ीचर मार्कर की एक्सएमएल फ़ाइल भी शामिल करनी होगी. डिफ़ॉल्ट रूप से, यह सेटिंग उन डिवाइसों पर अच्छे से काम करती है जो वॉर्म रीबूट का इस्तेमाल करते हैं. ऐसा तब होता है, जब रीबूट के दौरान डीरैम की पावर चालू रहती है.
एस्क्रो सुविधा को फिर से चालू करने का मार्कर
सुविधा का मार्कर भी मौजूद होना चाहिए:
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