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

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

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

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

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

पृष्ठभूमि

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

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

खतरा मॉडल

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

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

क्षमताओं

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

सीमाओं

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

समाधान

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

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

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

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

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

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

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

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

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

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

एंड्रॉइड 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)

आपको इसे लागू करने की आवश्यकता नहीं है, क्योंकि एचएएल को एंड्रॉइड 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()

TelephonyManager सिस्टम API का उपयोग विशेषाधिकार प्राप्त APK द्वारा किया जाता है।

परिक्षण

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

    adb shell cmd phone unattended-reboot

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

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

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

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

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

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

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

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

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

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

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

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

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

रीबूट एस्क्रो फीचर मार्कर

फीचर मार्कर भी मौजूद होना चाहिए:

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 कर्नेल के युक्ति ट्री में, आपको 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

सेलिनक्स नियम

इन नई प्रविष्टियों को डिवाइस के 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