रीबूट होने पर फिर से शुरू करना

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

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

खतरे का मॉडल

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

खास तौर पर, सीई स्टोरेज को हमलावर के पास नहीं होना चाहिए. हमलावर के पास डिवाइस के साथ-साथ ये सुविधाएं और सीमाएं होनी चाहिए:

क्षमताएं

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

सीमाएं

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

समाधान

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

  • Android, डिवाइस पर सेव किए गए डेटा को क्रिप्टोग्राफ़िक तरीके से सुरक्षित करता है.
  • सारे डेटा को भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट में स्टोर की गई कुंजियों से सुरक्षित किया जाता है (टीईई).
  • टीईई सिर्फ़ तब कुंजियां जारी करता है, जब चल रहे ऑपरेटिंग सिस्टम की क्रिप्टोग्राफ़िक पुष्टि (वेरिफ़ाइड बूट) हो जाती है.
  • Google के सर्वर पर चल रही आरओआर सेवा, सीक्रेट स्टोर करके CE डेटा को सुरक्षित करती है जिसे सिर्फ़ सीमित समय के लिए वापस लाया जा सकता है. यह सभी Android नेटवर्क पर काम करता है.
  • डिवाइस को अनलॉक करने और सीई स्टोरेज को डिक्रिप्ट करने के लिए, क्रिप्टोग्राफ़िक कुंजी का इस्तेमाल किया जाता है. यह कुंजी, उपयोगकर्ता के पिन से सुरक्षित होती है.
    • रात भर डिवाइस को रीबूट करने के लिए शेड्यूल करने पर, Android उपयोगकर्ता को अपना पिन डालने के लिए कहता है. इसके बाद, वह सिंथेटिक पासवर्ड (एसपी) का हिसाब लगाता है.
    • इसके बाद, यह एसपी को दो बार एन्क्रिप्ट करता है: एक बार, रैम में सेव की गई कुंजी K_s से और फिर TEE में सेव की गई कुंजी K_k से.
    • डबल-एन्क्रिप्टेड एसपी को डिस्क पर सेव किया जाता है और एसपी को रैम से वाइप कर दिया जाता है. दोनों कुंजियां हाल ही में जनरेट की जाती हैं और सिर्फ़ एक बार फिर से चालू करने के लिए इस्तेमाल की जाती हैं.
  • फिर से चालू होने पर, Android, सर्वर को K_s असाइन कर देता है. K_k वाली रसीद, डिस्क पर सेव करने से पहले एन्क्रिप्ट (सुरक्षित) हो जाती है.
  • रीबूट करने के बाद, Android रसीद को डिक्रिप्ट करने के लिए K_k का इस्तेमाल करता है. इसके बाद, K_s को वापस पाने के लिए, उसे सर्वर पर भेजता है.
    • डिस्क पर सेव किए गए एसपी को डिक्रिप्ट करने के लिए, K_k और K_s का इस्तेमाल किया जाता है.
    • Android, सीई स्टोरेज को अनलॉक करने और सामान्य ऐप्लिकेशन को स्टार्ट करने की अनुमति देने के लिए, एसपी का इस्तेमाल करता है.
    • K_k और K_s को खारिज कर दिया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिफ़ॉल्ट तरीके का इस्तेमाल करने के लिए, आपको 65,536 (0x10,000) बाइट्स रिज़र्व करने होंगे. कोई तारीख नहीं इन बाइट को नॉन-वोलाटाइल स्टोरेज में लिखो, ताकि यह पक्का किया जा सके कि सिक्योरिटी प्रॉपर्टी बने रहें.

Linux kernel डिवाइस ट्री में हुए बदलाव

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