रिज्यूमे-ऑन-रिबूट

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

हालाँकि भागीदार इस प्रक्रिया को एक ओटीए सिस्टम सुविधा के साथ जोड़ सकते हैं जो एंड्रॉइड 11 में डिवाइस के निष्क्रिय होने की उम्मीद होने पर अपडेट लागू करता है, एंड्रॉइड 12 में भागीदारों को अतिरिक्त ओटीए सिस्टम सुविधा की आवश्यकता नहीं है। RoR प्रक्रिया उपयोगकर्ताओं को अतिरिक्त सुरक्षा और सुविधा प्रदान करती है क्योंकि अपडेट डिवाइस के निष्क्रिय समय के दौरान किए जा सकते हैं, जबकि एंड्रॉइड 12 मल्टी-क्लाइंट और सर्वर-आधारित अपडेट कार्यक्षमताएं मिलकर डिवाइस हार्डवेयर-स्तरीय प्रकार की सुरक्षा प्रदान करती हैं।

हालाँकि आपको Android 11 में RoR का समर्थन करने के लिए android.hardware.reboot_escrow सुविधा के लिए डिवाइस की अनुमति प्रदान करनी होगी, आपको Android 12 और उच्चतर में सर्वर-आधारित RoR को सक्षम करने के लिए ऐसा करने की आवश्यकता नहीं है, क्योंकि वे HAL का उपयोग नहीं करते हैं।

पृष्ठभूमि

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

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

खतरा मॉडल

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

विशेष रूप से, सीई स्टोरेज को उस हमलावर द्वारा नहीं पढ़ा जाना चाहिए जिसके पास भौतिक रूप से डिवाइस है, और जिसमें ये क्षमताएं और सीमाएं हैं:

क्षमताओं

• मनमाने संदेशों पर हस्ताक्षर करने के लिए किसी विक्रेता या कंपनी की हस्ताक्षर कुंजी का उपयोग कर सकते हैं।
• डिवाइस को OTA अपडेट प्राप्त होने का कारण बन सकता है।
• किसी भी हार्डवेयर (जैसे एप्लिकेशन प्रोसेसर, या फ्लैश मेमोरी) के संचालन को संशोधित कर सकता है - नीचे दी गई सीमाओं में दिए गए विवरण को छोड़कर। (हालांकि, इस तरह के संशोधन में कम से कम एक घंटे की देरी और एक पावर चक्र शामिल होता है जो रैम सामग्री को नष्ट कर देता है।)

सीमाएँ

• छेड़छाड़-प्रतिरोधी हार्डवेयर (उदाहरण के लिए, टाइटन एम) के संचालन को संशोधित नहीं किया जा सकता।
• लाइव डिवाइस की रैम को नहीं पढ़ सकता।
• उपयोगकर्ता के क्रेडेंशियल्स (पिन, पैटर्न, पासवर्ड) का अनुमान नहीं लगा सकते या अन्यथा उन्हें दर्ज नहीं कर सकते।

समाधान

एंड्रॉइड 12 आरओआर अपडेट सिस्टम बहुत परिष्कृत हमलावरों के खिलाफ सुरक्षा प्रदान करता है, और ऐसा तब होता है जब ऑन-डिवाइस पासवर्ड और पिन डिवाइस पर रहते हैं - उन्हें कभी भी Google सर्वर पर नहीं भेजा या संग्रहीत किया जाता है। यह उस प्रक्रिया का अवलोकन है जो सुनिश्चित करता है कि प्रदान किए गए सुरक्षा स्तर हार्डवेयर-आधारित, डिवाइस-स्तरीय RoR सिस्टम के समान हैं:

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

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

सिम-पिन रीप्ले

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

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

हर बार जब उपयोगकर्ता इसे सफलतापूर्वक सक्षम, सत्यापित या संशोधित करता है तो सिम पिन को फिर से एन्क्रिप्ट और संग्रहीत किया जाता है। यदि निम्न में से कोई भी घटित होता है तो सिम पिन हटा दिया जाता है:

• सिम हटा दी गई है या रीसेट कर दी गई है.
• उपयोगकर्ता पिन अक्षम कर देता है.
• एक गैर-आरओआर-आरंभित रिबूट हुआ है।

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

कार्यान्वयन दिशानिर्देश

एंड्रॉइड 12 में, मल्टी-क्लाइंट और सर्वर-आधारित आरओआर फ़ंक्शन ओटीए अपडेट पुश करने पर भागीदारों को हल्का भार प्रदान करते हैं। आवश्यक अपडेट सुविधाजनक डिवाइस डाउनटाइम के दौरान हो सकते हैं, जैसे निर्दिष्ट नींद के घंटों के दौरान।

यह सुनिश्चित करने के लिए कि ऐसी समय अवधि के दौरान ओटीए अपडेट उपयोगकर्ताओं को बाधित न करें, प्रकाश उत्सर्जन को कम करने के लिए डार्क मोड का उपयोग करें। ऐसा करने के लिए, डिवाइस बूटलोडर को unattended स्ट्रिंग कारण की खोज करने को कहें। यदि unattended true है, तो डिवाइस को डार्क मोड में रखें। ध्यान दें कि ध्वनि और प्रकाश उत्सर्जन को कम करना प्रत्येक ओईएम की जिम्मेदारी है।

यदि आप या तो Android 12 में अपग्रेड कर रहे हैं, या Android 12 डिवाइस लॉन्च कर रहे हैं, तो आपको नई RoR कार्यक्षमता को लागू करने के लिए कुछ भी करने की आवश्यकता नहीं है।

मल्टी-क्लाइंट प्रवाह में एक नई कॉल है, isPreparedForUnattendedUpdate , जो नीचे दिखाया गया है:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

आपको इसे लागू करने की आवश्यकता नहीं है, क्योंकि HAL को Android 12 के रूप में अप्रचलित कर दिया गया है।

टेलीफोनी प्रबंधक

एंड्रॉइड 12 में रीबूट आसन्न होने पर ओटीए क्लाइंट TelephonyManager सिस्टम एपीआई को आमंत्रित करता है। यह एपीआई सभी कैश्ड पिन कोड को AVAILABLE स्थिति से REBOOT_READY स्थिति में ले जाता है। TelephonyManager सिस्टम API मौजूदा 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()

टेलीफ़ोनीमैनेजर सिस्टम एपीआई का उपयोग विशेषाधिकार प्राप्त एपीके द्वारा किया जाता है।

परिक्षण

नए एपीआई का परीक्षण करने के लिए, इस आदेश को निष्पादित करें:

    adb shell cmd phone unattended-reboot

यह कमांड केवल तभी काम करता है जब शेल रूट ( adb root ) के रूप में चल रहा हो।

केवल एंड्रॉइड 11

इस पृष्ठ का शेष भाग Android 11 पर लागू होता है।

जुलाई 2020 तक, RoR HAL का कार्यान्वयन दो श्रेणियों में आता है:

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

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

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

RoR का उपयोग करके OTA अपडेट का प्रवाह

फ़ोन पर OTA क्लाइंट ऐप में RoR को लागू करने के लिए आवश्यक तरीकों को कॉल करने के लिए मैनिफ़ेस्ट.परमिशन.REBOOT और Manifest.permission.RECOVERY अनुमतियाँ होनी चाहिए। उस शर्त के साथ, अद्यतन का प्रवाह इन चरणों का पालन करता है:

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

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

उत्पाद कॉन्फ़िगरेशन संशोधित करें

Android 11 में RoR सुविधा का समर्थन करने वाले उत्पाद के रूप में चिह्नित उत्पाद में RebootEscrow HAL का कार्यान्वयन और फीचर मार्कर XML फ़ाइल शामिल होनी चाहिए। डिफ़ॉल्ट कार्यान्वयन उन उपकरणों पर अच्छी तरह से काम करता है जो वार्म रिबूट का उपयोग करते हैं (जब रिबूट के दौरान 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) बाइट्स आरक्षित करनी होंगी। यह सुनिश्चित करने के लिए कि सुरक्षा गुण बने रहें, इन बाइट्स को कभी भी गैर-वाष्पशील भंडारण में न लिखें।

लिनक्स कर्नेल डिवाइस ट्री बदलता है

लिनक्स कर्नेल के डिवाइस ट्री में, आपको 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 ) जैसे नाम वाला एक नया उपकरण है।

डिवाइस.एमके परिवर्तन

यह मानते हुए कि पिछले चरण से आपके नए उपकरण का नाम 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