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

Android 11 में, ओटीए अपडेट A/B अपडेट या वर्चुअल A/B अपडेट के तरीकों का इस्तेमाल करके लागू किए जा सकते हैं. इसके लिए, RecoverySystem क्लास के तरीकों का इस्तेमाल किया जाता है. ओटीए अपडेट लागू करने के लिए, डिवाइस को फिर से चालू करने के बाद, फिर से चालू करने की प्रोसेस (आरओआर) से, डिवाइस के क्रेडेंशियल एन्क्रिप्टेड (सीई) स्टोरेज को अनलॉक कर दिया जाता है.

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

Android 11 में आरओआर की सुविधा इस्तेमाल करने के लिए, आपको android.hardware.reboot_escrow सुविधा के लिए डिवाइस की अनुमति देनी होगी. हालांकि, Android 12 और उसके बाद के वर्शन में, सर्वर पर आधारित आरओआर की सुविधा चालू करने के लिए, आपको ऐसा करने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि ये वर्शन एचएएल का इस्तेमाल नहीं करते.

बैकग्राउंड

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

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

थ्रेट मॉडल

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

खास तौर पर, किसी ऐसे हमलावर को CE स्टोरेज को पढ़ना नहीं चाहिए जिसके पास साथ ही, इस डिवाइस में ये काम किए जा सकते हैं और कुछ सीमाएं भी तय की गई हैं:

क्षमताएं

• किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल करके, किसी भी मैसेज पर हस्ताक्षर किया जा सकता है.
• इसकी वजह से डिवाइस पर ओटीए अपडेट मिल सकता है.
• किसी भी हार्डवेयर (जैसे, ऐप्लिकेशन प्रोसेसर या फ़्लैश मेमोरी) के काम करने के तरीके में बदलाव कर सकता है. हालांकि, ऐसा सिर्फ़ नीचे दी गई सीमाओं के मुताबिक किया जा सकता है. (हालांकि, इस तरह के बदलाव में कम से कम एक घंटे की देरी और पावर साइकल जो रैम के कॉन्टेंट को खत्म कर देता है.)

सीमाएं

• छेड़छाड़ से सुरक्षित हार्डवेयर (उदाहरण के लिए, Titan M) के काम करने के तरीके में बदलाव नहीं किया जा सकता.
• लाइव डिवाइस की रैम को पढ़ा नहीं जा सकता.
• उपयोगकर्ता के क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) का अनुमान न लगा सके या उन्हें किसी और तरीके से डालने के लिए मजबूर न कर सके.

समाधान

Android 12 में मौजूद आरओआर अपडेट सिस्टम, डिवाइस पर मौजूद पासवर्ड और पिन को सुरक्षित रखता है. यह सिस्टम, डिवाइस पर मौजूद पासवर्ड और पिन को कभी भी Google के सर्वर पर नहीं भेजता और न ही सेव करता है. यह उस प्रोसेस की खास जानकारी है जिससे पक्का होता है कि दिए गए सुरक्षा लेवल, हार्डवेयर-आधारित, डिवाइस-लेवल के आरओआर सिस्टम की तरह:

• Android, किसी डिवाइस पर सेव किए गए डेटा पर क्रिप्टोग्राफ़िक सुरक्षा लागू करता है.
• सारा डेटा, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में सेव की गई कुंजियों से सुरक्षित होता है.
• टीईई सिर्फ़ तब कुंजियों को रिलीज़ करता है, जब ऑपरेटिंग सिस्टम ठीक से काम कर रहा होता है क्रिप्टोग्राफ़िक ऑथेंटिकेशन (पुष्टि किया गया बूट).
• Google के सर्वर पर चलने वाली RoR सेवा, सीई डेटा को सुरक्षित रखने के लिए एक गुप्त पासकोड सेव करती है. इस पासकोड को सिर्फ़ कुछ समय के लिए वापस पाया जा सकता है. यह सभी 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 के बाद से एचएएल का इस्तेमाल नहीं किया जा सकता.

टेलीफ़ोनीमैनेजर

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 तक, RoR HAL को लागू करने के तरीके दो कैटगरी में आते हैं:

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

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

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

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

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

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

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

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

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

डिफ़ॉल्ट तौर पर, फिर से चालू करने के लिए एस्क्रो एचएएल लागू करना

डिफ़ॉल्ट तरीके का इस्तेमाल करने के लिए, आपको 65536 (0x10000) बाइट रिज़र्व करना होगा. इन बाइट को कभी भी नॉन-वॉल्व्यूस्ट स्टोरेज में न लिखें, ताकि सुरक्षा से जुड़ी प्रॉपर्टी बनी रहें.

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