रीबूट पर फिर से शुरू करें

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 स्टोरेज को अनलॉक करने और ऐप्लिकेशन को सामान्य तरीके से चालू करने के लिए, एसपी का इस्तेमाल करता है.
  • K_k और K_s को खारिज कर दिया गया है.

आपके फ़ोन को सुरक्षित रखने वाले अपडेट आपके लिए सुविधाजनक समय पर हो सकते हैं: जब आप सोते समय हों.

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

सिम-पिन को फिर से चलाने की सुविधा

कुछ स्थितियों में सिम कार्ड के पिन कोड की पुष्टि कैश मेमोरी से की जाती है. इस प्रोसेस को 'सिम-पिन फिर से चलाना' कहते हैं.

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

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

• सिम को हटा दिया गया है या रीसेट कर दिया गया है.
• उपयोगकर्ता इस पिन को बंद कर देता है.
• आरओआर से शुरू नहीं किया गया डिवाइस फिर से चालू हुआ है.

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

लागू करने के लिए दिशा-निर्देश

Android 12 में, मल्टी-क्लाइंट और सर्वर-आधारित RoR फ़ंक्शन, पार्टनर को ओटीए अपडेट पुश करते समय कम लोड देते हैं. डिवाइस के बंद रहने के दौरान ज़रूरी अपडेट हो सकते हैं, जैसे कि सोने के तय समय के दौरान.

यह पक्का करने के लिए कि इस समयावधि के दौरान ओटीए अपडेट होने से उपयोगकर्ताओं को परेशानी न हो, कम रोशनी के उत्सर्जन को कम करने के लिए, गहरे रंग वाले मोड का इस्तेमाल करें. ऐसा करने के लिए, डिवाइस को बूटलोडर खोजने के लिए स्ट्रिंग की वजह 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 सिस्टम एपीआई का इस्तेमाल, खास सुविधाओं वाले APK करते हैं.

टेस्ट करना

नए एपीआई की जांच करने के लिए, यह निर्देश चलाएं:

    adb shell cmd phone unattended-reboot

यह निर्देश सिर्फ़ तब काम करता है, जब शेल रूट (adb root) के तौर पर चल रहा हो.

सिर्फ़ Android 11 के लिए

इस पेज का बाकी हिस्सा, Android 11 पर लागू होता है.

जुलाई 2020 से, आरओआर एचएएल को लागू करने की दो कैटगरी हैं:

1. अगर SoC हार्डवेयर, रीबूट के दौरान भी रैम में डेटा सेव रखने की सुविधा देता है, तो OEM, AOSP (डिफ़ॉल्ट रैम एस्क्रो) में डिफ़ॉल्ट तौर पर लागू होने की सुविधा का इस्तेमाल कर सकते हैं.
2. अगर डिवाइस हार्डवेयर या SoC, सुरक्षित हार्डवेयर एनक्लेव (अपनी रैम और ROM वाला अलग सिक्योरिटी को-प्रोसेसर) के साथ काम करता है, तो उसे ये काम भी करने होंगे:
   • मुख्य सीपीयू (CPU) रीबूट का पता लगाने में सक्षम बनें.
   • हार्डवेयर टाइमर का ऐसा सोर्स हो जो फिर से चालू होने के दौरान भी बना रहता है. इसका मतलब है कि एन्क्लेव को रीबूट का पता लगाना चाहिए और रीबूट से पहले सेट किए गए टाइमर की समयसीमा खत्म करनी चाहिए.
   • एन्क्लेव के रैम/रोम में, एस्क्रो की गई कुंजी को इस तरह से सेव करने की सुविधा हो कि उसे ऑफ़लाइन अटैक से वापस नहीं पाया जा सके. यह ज़रूरी है कि आरओआर कुंजी को इस तरह से सेव किया जाए जिससे इनसाइडर या हमलावरों के लिए उसे वापस पाना नामुमकिन हो.

डिफ़ॉल्ट रैम वाला एस्क्रो

AOSP में, रैम में डेटा सेव रखने की सुविधा का इस्तेमाल करके RoR HAL लागू किया गया है. यह काम करे, इसके लिए OEM को यह पक्का करना होगा कि उनके SoCs, फिर से चालू होने के दौरान रैम के हिसाब से काम करते हों. कुछ SoC, रीबूट के दौरान रैम कॉन्टेंट को सेव नहीं कर पाते. इसलिए, OEM को इस डिफ़ॉल्ट एचएएल को चालू करने से पहले, अपने SoC पार्टनर से सलाह लेने का सुझाव दिया जाता है. इसके लिए, नीचे दिए गए सेक्शन में कैननिकल रेफ़रंस दिया गया है.

आरओआर का इस्तेमाल करके ओटीए अपडेट का फ़्लो

फ़ोन पर मौजूद ओटीए क्लाइंट ऐप्लिकेशन के पास, Manifest.permission.REBOOT और Manifest.permission.RECOVERY अनुमतियां होनी चाहिए, ताकि आरओआर को लागू करने के लिए ज़रूरी तरीकों को कॉल किया जा सके. ज़रूरी शर्तें पूरी करने के बाद, अपडेट का फ़्लो इस तरह से होता है:

1. OTA क्लाइंट ऐप्लिकेशन, अपडेट को डाउनलोड करता है.
2. ओटीए क्लाइंट ऐप्लिकेशन, RecoverySystem#prepareForUnattendedUpdate को कॉल करता है. इससे, उपयोगकर्ता को अगली बार अनलॉक करते समय, स्क्रीन लॉक पर पिन, पैटर्न या पासवर्ड डालने के लिए कहा जाता है.
3. उपयोगकर्ता लॉकस्क्रीन पर जाकर डिवाइस को अनलॉक करता है और डिवाइस, अपडेट लागू करने के लिए तैयार हो जाता है.
4. OTA क्लाइंट ऐप्लिकेशन, RecoverySystem#rebootAndApply को कॉल करता है, जो तुरंत रीबूट ट्रिगर होता है.

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

प्रॉडक्ट कॉन्फ़िगरेशन में बदलाव करना

Android 11 में RoR सुविधा के साथ काम करने वाले प्रॉडक्ट के तौर पर मार्क किए गए प्रॉडक्ट में, RebootEscrow 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 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