Android 11 में, ओटीए अपडेट A/B अपडेट या वर्चुअल A/B अपडेट के तरीकों का इस्तेमाल करके लागू किए जा सकते हैं. इसके लिए, RecoverySystem क्लास के तरीकों का इस्तेमाल किया जाता है. ओटीए अपडेट लागू करने के लिए डिवाइस रीबूट होने के बाद, डिवाइस को फिर से चालू करने पर (आरओआर) सुविधा, डिवाइस के क्रेडेंशियल एन्क्रिप्टेड (सीई) स्टोरेज को अनलॉक कर देती है.
पार्टनर इस प्रोसेस को ओटीए सिस्टम की सुविधा के साथ जोड़ सकते हैं. यह सुविधा, Android 11 में डिवाइस के खाली होने पर अपडेट लागू करती है. हालांकि, Android 12 में पार्टनर को ओटीए सिस्टम की किसी अन्य सुविधा की ज़रूरत नहीं है. आरओआर प्रोसेस से, उपयोगकर्ताओं को ज़्यादा सुरक्षा और सुविधा मिलती है. ऐसा इसलिए, क्योंकि डिवाइस के इस्तेमाल में न होने के दौरान अपडेट किए जा सकते हैं. वहीं, Android 12 के मल्टी-क्लाइंट और सर्वर-आधारित अपडेट की सुविधाओं से, डिवाइस के हार्डवेयर लेवल पर सुरक्षा मिलती है.
Android 11 में आरओआर की सुविधा इस्तेमाल करने के लिए, आपको android.hardware.reboot_escrow
सुविधा के लिए डिवाइस की अनुमति देनी होगी. हालांकि, Android 12 और उसके बाद के वर्शन में, सर्वर पर आधारित आरओआर की सुविधा चालू करने के लिए, आपको ऐसा करने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि ये वर्शन एचएएल का इस्तेमाल नहीं करते.
बैकग्राउंड
Android 7 से, Android में डायरेक्ट बूट की सुविधा काम करती है. इससे, उपयोगकर्ता के सीई स्टोरेज को अनलॉक करने से पहले ही, डिवाइस पर ऐप्लिकेशन शुरू हो जाते हैं. डिवाइस को सीधे चालू करने की सुविधा लागू करने से, उपयोगकर्ताओं को बेहतर अनुभव मिला. इससे, डिवाइस चालू होने के बाद, लॉक स्क्रीन पर मौजूद पासवर्ड (एलएसकेएफ़) डालने की ज़रूरत नहीं पड़ी.
आरओआर की मदद से, किसी डिवाइस पर मौजूद सभी ऐप्लिकेशन के सीई स्टोरेज को अनलॉक किया जा सकता है. इसमें ऐसे ऐप्लिकेशन भी शामिल हैं जो डायरेक्ट बूट की सुविधा के साथ काम नहीं करते. ऐसा तब होता है, जब ओटीए अपडेट के बाद रीबूट की प्रक्रिया शुरू की जाती है. इस सुविधा की मदद से, उपयोगकर्ताओं को रीबूट के बाद, अपने सभी इंस्टॉल किए गए ऐप्लिकेशन से सूचनाएं मिलती हैं.
खतरे का मॉडल
आरओआर लागू करने के लिए यह ज़रूरी है कि जब कोई डिवाइस, हमलावर के हाथों में पड़ जाए, तो वह उपयोगकर्ता के सीई से एन्क्रिप्ट किए गए डेटा को वापस पाने में काफ़ी मुश्किल हो. भले ही, डिवाइस चालू हो, सीई स्टोरेज अनलॉक हो, और उपयोगकर्ता ने ओटीए अपडेट मिलने के बाद डिवाइस अनलॉक कर दिया हो. संगठन के अंदरूनी व्यक्ति से होने वाले हमले से बचाव करने की सुविधा, तब भी काम करनी चाहिए, जब हमलावर को ब्रॉडकास्ट की गई क्रिप्टोग्राफ़िक हस्ताक्षर कुंजियों का ऐक्सेस मिल जाए.
खास तौर पर, सीई स्टोरेज को हमलावर के पास नहीं होना चाहिए. हमलावर के पास डिवाइस के साथ-साथ ये सुविधाएं और सीमाएं होनी चाहिए:
सुविधाएं
- किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल करके, किसी भी मैसेज को साइन किया जा सकता है.
- इससे डिवाइस को ओटीए अपडेट मिल सकता है.
- किसी भी हार्डवेयर (जैसे, ऐप्लिकेशन प्रोसेसर या फ़्लैश मेमोरी) के काम करने के तरीके में बदलाव कर सकता है. हालांकि, ऐसा सिर्फ़ नीचे दी गई सीमाओं के मुताबिक किया जा सकता है. (हालांकि, इस तरह के बदलाव में कम से कम एक घंटे की देरी होती है. साथ ही, इसमें पावर साइकल भी शामिल होता है, जिससे रैम में मौजूद कॉन्टेंट नष्ट हो जाता है.)
सीमाएं
- छेड़छाड़ से सुरक्षित हार्डवेयर (उदाहरण के लिए, Titan M) के काम करने के तरीके में बदलाव नहीं किया जा सकता.
- लाइव डिवाइस की रैम को नहीं पढ़ा जा सकता.
- उपयोगकर्ता के क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) का अनुमान न लगा सके या उन्हें किसी और तरीके से डालने के लिए मजबूर न कर सके.
समाधान
Android 12 में मौजूद आरओआर अपडेट सिस्टम, डिवाइस पर मौजूद पासवर्ड और पिन को सुरक्षित रखता है. यह सिस्टम, डिवाइस पर मौजूद पासवर्ड और पिन को कभी भी Google के सर्वर पर नहीं भेजता और न ही सेव करता है. यहां उस प्रोसेस के बारे में खास जानकारी दी गई है जिससे यह पक्का किया जाता है कि डिवाइस के लिए उपलब्ध कराए गए सुरक्षा लेवल, हार्डवेयर पर आधारित डिवाइस-लेवल के RoR सिस्टम से मिलते-जुलते हों:
- Android, डिवाइस पर सेव किए गए डेटा को क्रिप्टोग्राफ़िक तरीके से सुरक्षित करता है.
- सारा डेटा, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में सेव की गई कुंजियों से सुरक्षित होता है.
- टीईई सिर्फ़ तब कुंजियां जारी करता है, जब चल रहे ऑपरेटिंग सिस्टम की क्रिप्टोग्राफ़िक पुष्टि (वेरिफ़ाइड बूट) हो जाती है.
- Google के सर्वर पर चलने वाली RoR सेवा, सीई डेटा को सुरक्षित रखने के लिए एक गुप्त पासकोड सेव करती है. इस पासकोड को सिर्फ़ कुछ समय के लिए वापस लाया जा सकता है. यह सुविधा, Android नेटवर्क पर काम करती है.
- डिवाइस को अनलॉक करने और सीई स्टोरेज को डिक्रिप्ट करने के लिए, क्रिप्टोग्राफ़िक कुंजी का इस्तेमाल किया जाता है. यह कुंजी, उपयोगकर्ता के पिन से सुरक्षित होती है.
- रात भर डिवाइस को रीबूट करने के लिए शेड्यूल करने पर, Android उपयोगकर्ता को अपना पिन डालने के लिए कहता है. इसके बाद, वह सिंथेटिक पासवर्ड (एसपी) कैलकुलेट करता है.
- इसके बाद, यह एसपी को दो बार एन्क्रिप्ट करता है: एक बार, रैम में सेव की गई कुंजी
K_sसे और फिर TEE में सेव की गई कुंजीK_kसे. - दो बार एन्क्रिप्ट किया गया एसपी, डिस्क पर सेव किया जाता है और एसपी, रैम से मिट जाता है. दोनों कुंजियां, हाल ही में जनरेट की गई हैं और इनका इस्तेमाल सिर्फ़ एक बार रीबूट करने के लिए किया जाता है.
- रीबूट करने के समय, Android
K_sको सर्वर को सौंप देता है.K_kवाली रसीद, डिस्क पर सेव करने से पहले एन्क्रिप्ट हो जाती है. - रीबूट करने के बाद, Android
K_kका इस्तेमाल करके रसीद को डिक्रिप्ट करता है. इसके बाद,K_sको वापस पाने के लिए, उसे सर्वर पर भेजता है.K_kऔरK_sका इस्तेमाल, डिस्क पर सेव किए गए एसपी को डिक्रिप्ट करने के लिए किया जाता है.- Android, CE स्टोरेज को अनलॉक करने और सामान्य ऐप्लिकेशन को स्टार्टअप करने की अनुमति देने के लिए, SP का इस्तेमाल करता है.
K_kऔरK_sको खारिज कर दिया जाता है.
आपके फ़ोन को सुरक्षित रखने वाले अपडेट, आपके लिए सही समय पर लागू किए जा सकते हैं. जैसे, जब आप सो रहे हों.
सिम पिन फिर से चलाना
कुछ खास स्थितियों में, सिम कार्ड के पिन कोड की पुष्टि कैश मेमोरी से की जाती है. इसे सिम-पिन रीप्ले कहते हैं.
पिन कोड की पुष्टि करने की सुविधा चालू होने पर, सिम कार्ड को फिर से चालू करने के बाद भी पिन कोड की पुष्टि करनी होगी. इसे सिम-पिन रीप्ले कहा जाता है. ऐसा करने से, फ़ोन कॉल, मैसेज, और डेटा सेवाओं के लिए ज़रूरी सेल्युलर कनेक्टिविटी वापस आ जाती है. सिम पिन और उससे मैच होने वाली सिम कार्ड की जानकारी (आईसीसीआईडी और सिम स्लॉट का नंबर), दोनों को सुरक्षित तरीके से सेव किया जाता है. सेव किए गए पिन को वापस पाने और पुष्टि करने के लिए, डिवाइस को बिना किसी मदद के रीबूट करना ज़रूरी है. अगर डिवाइस को सुरक्षित किया गया है, तो सिम पिन को LSKF से सुरक्षित की गई कुंजियों के साथ सेव किया जाता है. अगर सिम का पिन चालू है, तो ओटीए अपडेट और सर्वर-आधारित आरओआर के लिए, आरओआर सर्वर के साथ इंटरैक्ट करने के लिए वाई-फ़ाई कनेक्शन ज़रूरी है. इससे रीबूट करने के बाद, मोबाइल इंटरनेट की मदद से बुनियादी सुविधाएं काम करती हैं.
जब भी उपयोगकर्ता सिम पिन को चालू करता है, उसकी पुष्टि करता है या उसमें बदलाव करता है, तब उसे फिर से एन्क्रिप्ट (सुरक्षित) किया जाता है और स्टोर किया जाता है. इनमें से कोई भी स्थिति होने पर, सिम पिन को हटा दिया जाता है:
- सिम को हटाया गया है या रीसेट किया गया है.
- उपयोगकर्ता, पिन को बंद कर देता है.
- RoR के अलावा किसी और वजह से रीबूट हुआ है.
आरओआर की वजह से रीबूट होने के बाद, सेव किए गए सिम पिन का इस्तेमाल सिर्फ़ एक बार और बहुत कम समय (20 सेकंड) के लिए किया जा सकता है. ऐसा तब ही किया जा सकता है, जब सिम कार्ड की जानकारी मेल खाती हो. स्टोर किया गया सिम पिन, TelephonyManager ऐप्लिकेशन में ही रहता है. साथ ही, इसे बाहरी मॉड्यूल से वापस नहीं पाया जा सकता.
लागू करने के दिशा-निर्देश
Android 12 में, मल्टी-क्लाइंट और सर्वर-आधारित RoR फ़ंक्शन, पार्टनर को ओटीए अपडेट पुश करते समय कम लोड देते हैं. ज़रूरी अपडेट, डिवाइस के इस्तेमाल में न होने के दौरान किए जा सकते हैं. जैसे, डिवाइस के बंद रहने के तय समय के दौरान.
इस तरह के समय के दौरान, ओटीए अपडेट से उपयोगकर्ताओं को परेशानी न हो, इसके लिए डार्क मोड का इस्तेमाल करें. इससे लाइट का उत्सर्जन कम होगा. ऐसा करने के लिए, डिवाइस के बूटलोडर में स्ट्रिंग reason 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 में रीबूट होने पर, ओटीए क्लाइंट 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 सिस्टम एपीआई का इस्तेमाल, खास सुविधाओं वाले APK करते हैं.
टेस्ट करना
नए एपीआई की जांच करने के लिए, यह निर्देश चलाएं:
adb shell cmd phone unattended-rebootयह निर्देश सिर्फ़ तब काम करता है, जब शेल रूट (adb root) के तौर पर चल रहा हो.
सिर्फ़ Android 11 के लिए
इस पेज का बाकी हिस्सा, Android 11 पर लागू होता है.
जुलाई 2020 तक, RoR HAL को लागू करने के तरीके दो कैटगरी में आते हैं:
- अगर SoC हार्डवेयर, रीबूट के दौरान भी रैम में डेटा सेव रखने की सुविधा देता है, तो OEM, AOSP में डिफ़ॉल्ट तौर पर लागू होने वाली सुविधा (डिफ़ॉल्ट रैम एस्क्रो) का इस्तेमाल कर सकते हैं.
- अगर डिवाइस का हार्डवेयर या SoC, सुरक्षित हार्डवेयर एन्क्लेव (अपनी रैम और रोम वाला एक अलग सुरक्षा कोप्रोसेसर) के साथ काम करता है, तो उसे ये काम भी करने होंगे:
- मुख्य सीपीयू के रीबूट का पता लगाने में सक्षम हो.
- हार्डवेयर टाइमर सोर्स होना चाहिए, जो रीबूट होने के बाद भी काम करता रहे. इसका मतलब है कि एन्क्लेव को रीबूट का पता लगाना चाहिए और रीबूट से पहले सेट किए गए टाइमर की समयसीमा खत्म करनी चाहिए.
- एन्क्रिप्ट की गई कुंजी को एन्क्लेव के रैम/रोम में सेव करने की सुविधा, ताकि उसे ऑफ़लाइन अटैक से वापस न पाया जा सके. यह RoR पासकोड को इस तरह से सेव करना चाहिए कि अंदरूनी लोग या हमलावर उसे वापस न पा सकें.
डिफ़ॉल्ट तौर पर, आरएएम को एस्क्रो में रखने की सुविधा
AOSP में, रैम में डेटा सेव रखने की सुविधा का इस्तेमाल करके RoR HAL लागू किया गया है. यह सुविधा काम करे, इसके लिए OEM को यह पक्का करना होगा कि उनके SoC, रीबूट के दौरान भी रैम में डेटा सेव रखने की सुविधा के साथ काम करते हों. कुछ SoC, रीबूट के दौरान रैम कॉन्टेंट को सेव नहीं कर पाते. इसलिए, OEM को इस डिफ़ॉल्ट एचएएल को चालू करने से पहले, अपने SoC पार्टनर से सलाह लेने का सुझाव दिया जाता है. इसके लिए, नीचे दिए गए सेक्शन में कैननिकल रेफ़रंस दिया गया है.
RoR का इस्तेमाल करके ओटीए अपडेट का फ़्लो
फ़ोन पर मौजूद ओटीए क्लाइंट ऐप्लिकेशन के पास, Manifest.permission.REBOOT और Manifest.permission.RECOVERY अनुमतियां होनी चाहिए, ताकि आरओआर को लागू करने के लिए ज़रूरी तरीकों को कॉल किया जा सके. ज़रूरी शर्तें पूरी करने के बाद, अपडेट का फ़्लो इस तरह से होता है:
- ओटीए क्लाइंट ऐप्लिकेशन, अपडेट डाउनलोड करता है.
- ओटीए क्लाइंट ऐप्लिकेशन,
RecoverySystem#prepareForUnattendedUpdateको कॉल करता है. इससे, उपयोगकर्ता को अगली बार अनलॉक करते समय, स्क्रीन लॉक पर पिन, पैटर्न या पासवर्ड डालने के लिए कहा जाता है. - उपयोगकर्ता लॉकस्क्रीन पर जाकर डिवाइस को अनलॉक करता है और डिवाइस, अपडेट लागू करने के लिए तैयार हो जाता है.
- ओटीए क्लाइंट ऐप्लिकेशन,
RecoverySystem#rebootAndApplyको कॉल करता है, जिससे डिवाइस तुरंत रीबूट हो जाता है.
इस प्रोसेस के आखिर में, डिवाइस रीबूट हो जाता है और आरओआर (रोल-ऑन-रिबूट) प्रोसेस, क्रेडेंशियल एन्क्रिप्टेड (सीई) स्टोरेज को अनलॉक कर देती है. ऐप्लिकेशन के लिए, यह सामान्य उपयोगकर्ता अनलॉक के तौर पर दिखता है. इसलिए, उन्हें वे सभी सिग्नल मिलते हैं जो आम तौर पर मिलते हैं. जैसे, ACTION_LOCKED_BOOT_COMPLETED और ACTION_BOOT_COMPLETED.
प्रॉडक्ट कॉन्फ़िगरेशन में बदलाव करना
Android 11 में RoR सुविधा के साथ काम करने वाले प्रॉडक्ट के तौर पर मार्क किए गए प्रॉडक्ट में, RebootEscrow HAL को लागू करना ज़रूरी है. साथ ही, उसमें सुविधा मार्कर एक्सएमएल फ़ाइल भी शामिल होनी चाहिए. डिफ़ॉल्ट तौर पर लागू होने वाला तरीका, उन डिवाइसों पर बेहतर तरीके से काम करता है जिनमें वॉर्म रीबूट (जब रीबूट के दौरान DRAM की पावर चालू रहती है) का इस्तेमाल किया जाता है.
रिसर्चर के लिए रिबूट करने की सुविधा का मार्कर
फ़ीचर मार्कर भी मौजूद होना चाहिए:
PRODUCT_COPY_FILES += \
frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml
डिफ़ॉल्ट तौर पर रीबूट एस्क्रो एचएएल लागू करना
डिफ़ॉल्ट तरीके का इस्तेमाल करने के लिए, आपको 65,536 (0x10,000) बाइट्स रिज़र्व करने होंगे. इन बाइट को कभी भी नॉन-वॉल्व्यू स्टोरेज में न लिखें, ताकि यह पक्का किया जा सके कि सुरक्षा से जुड़ी प्रॉपर्टी बनी रहें.
Linux kernel डिवाइस ट्री में हुए बदलाव
Linux kernel के डिवाइस ट्री में, आपको 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