রিবুট করার পরে আবার চালু করা

Android 11-এ, A/B আপডেট বা ভার্চুয়াল A/B আপডেট মেকানিজম ব্যবহার করে OTA আপডেট প্রয়োগ করা যেতে পারে, এর সাথে RecoverySystem ক্লাস পদ্ধতিও ব্যবহার করা হয়। OTA আপডেট প্রয়োগ করার জন্য ডিভাইস রিবুট করার পরে, রিবুট করার পরে আবার চালু হওয়া (RoR) ফিচারটি ডিভাইসের ক্রেডেনশিয়াল এনক্রিপ্টেড (CE) স্টোরেজ আনলক করে।

যদিও পার্টনাররা এই প্রসেসকে OTA সিস্টেম ফিচারের সাথে পেয়ার করতে পারেন যা Android 11-এ ডিভাইসটি যখন আইডল থাকার কথা তখন আপডেট প্রয়োগ করে, Android 12-এ পার্টনারদের অতিরিক্ত OTA সিস্টেম ফিচারের প্রয়োজন নেই। RoR প্রসেস ব্যবহারকারীদের জন্য অতিরিক্ত নিরাপত্তা ও সুবিধা প্রদান করে কারণ ডিভাইস যখন অলস থাকে তখন আপডেট করা যায়, যেখানে Android 12 মাল্টি-ক্লায়েন্ট ও সার্ভার-ভিত্তিক আপডেট ফাংশনালিটি একসাথে ডিভাইস হার্ডওয়্যার-লেভেল টাইপ নিরাপত্তা প্রদান করে।

Android 11-এ RoR কাজ করার জন্য আপনাকে android.hardware.reboot_escrow ফিচারের জন্য ডিভাইসের অনুমতি দিতে হবে, তবে Android 12 ও এর পরের যেকোনও ভার্সনে সার্ভার-ভিত্তিক RoR চালু করার জন্য আপনাকে এটি করতে হবে না, কারণ সেগুলি HAL ব্যবহার করে না।

ব্যাকগ্রাউন্ড

Android 7 থেকে শুরু করে, Android সরাসরি বুট কাজ করে, যা কোনও ডিভাইসে অ্যাপকে CE স্টোরেজ ব্যবহারকারীর দ্বারা আনলক করার আগে স্টার্ট-আপ করতে সক্ষম করে। ডাইরেক্ট বুট সাপোর্ট প্রয়োগ করার ফলে ব্যবহারকারীরা বুট করার পরে লক স্ক্রিন নলেজ ফ্যাক্টর (LSKF) প্রয়োজন হওয়ার আগে আরও ভালো অভিজ্ঞতা পেয়েছেন।

OTA আপডেট করার পরে রিবুট শুরু হলে, RoR ডিভাইসে থাকা সব অ্যাপের CE স্টোরেজ আনলক করার অনুমতি দেয়, যার মধ্যে ডাইরেক্ট বুট কাজ করে না এমন অ্যাপও রয়েছে। এই ফিচারের মাধ্যমে, রিবুট করার পরে ব্যবহারকারীরা তাদের ইনস্টল করা সব অ্যাপ থেকে বিজ্ঞপ্তি পাবেন।

হুমকির মডেল

RoR-এর প্রয়োগে এটি নিশ্চিত করতে হবে যে, কোনও ডিভাইস আক্রমণকারীর হাতে পড়লে, আক্রমণকারীর পক্ষে ব্যবহারকারীর CE-এনক্রিপ্ট করা ডেটা রিকভার করা অত্যন্ত কঠিন হবে, এমনকি ডিভাইস চালু থাকলেও, CE স্টোরেজ আনলক করা থাকলেও এবং OTA আপডেট পাওয়ার পরে ব্যবহারকারী ডিভাইস আনলক করলেও। আক্রমণকারী ব্রডকাস্ট ক্রিপ্টোগ্রাফিক সই করার কী অ্যাক্সেস করতে পারলেও, ইন্টার্নাল আক্রমণ প্রতিরোধ কার্যকর হতে হবে।

বিশেষ করে, কোনও আক্রমণকারী যার কাছে ডিভাইসটি শারীরিকভাবে আছে এবং যার কাছে এই ক্ষমতা এবং সীমাবদ্ধতা রয়েছে, সে যেন CE স্টোরেজ পড়তে না পারে:

ক্ষমতা

• যেকোনও মেসেজে স্বাক্ষর করার জন্য যেকোনও ভেন্ডর বা কোম্পানির সাইনিং কী ব্যবহার করতে পারে।
• এর ফলে ডিভাইসে OTA আপডেট আসতে পারে।
• নিচে সীমাবদ্ধতা বিভাগে উল্লেখ করা বিষয়গুলি ছাড়া - যেকোনও হার্ডওয়্যারের (যেমন, অ্যাপ্লিকেশন প্রসেসর, বা ফ্ল্যাশ মেমরি) অপারেশন পরিবর্তন করতে পারে। (তবে, এই ধরনের পরিবর্তনের জন্য কমপক্ষে এক ঘণ্টা দেরি হয় এবং পাওয়ার সাইকেল RAM কন্টেন্ট ধ্বংস করে দেয়।)

সীমাবদ্ধতা

• টেম্পার-প্রতিরোধী হার্ডওয়্যারের (যেমন, Titan M) অপারেশন পরিবর্তন করতে পারে না।
• লাইভ ডিভাইসের RAM পড়তে পারছে না।
• ব্যবহারকারীর ক্রেডেনশিয়াল (পিন, প্যাটার্ন, পাসওয়ার্ড) অনুমান করা যাবে না অথবা অন্য কোনওভাবে সেগুলি ইনপুট করা যাবে না।

সমাধান

Android 12 RoR আপডেট সিস্টেম অত্যন্ত অত্যাধুনিক আক্রমণকারীদের বিরুদ্ধে নিরাপত্তা প্রদান করে এবং অন-ডিভাইস পাসওয়ার্ড এবং পিন ডিভাইসে থাকাকালীন এটি করে—সেগুলি কখনই Google সার্ভারে পাঠানো বা স্টোর করা হয় না। নিচে সেই প্রসেসের একটি ওভারভিউ দেওয়া হল যা নিশ্চিত করে যে প্রদত্ত নিরাপত্তা লেভেল হার্ডওয়্যার-ভিত্তিক, ডিভাইস-লেভেল RoR সিস্টেমের মতো একই রকম হয়:

• ডিভাইসে সেভ করা ডেটার ক্ষেত্রে Android ক্রিপ্টোগ্রাফিক সুরক্ষা প্রয়োগ করে।
• ট্রাস্টেড এক্সিকিউশন এনভায়রনমেন্ট (TEE)-এ স্টোর করা 'কী'-এর মাধ্যমে সব ডেটা সুরক্ষিত থাকে।
• চলমান অপারেটিং সিস্টেম ক্রিপ্টোগ্রাফিক যাচাইকরণ (যাচাই করা বুট) পাস করলেই TEE শুধুমাত্র কী রিলিজ করে।
• Google সার্ভারে রান করা RoR পরিষেবা, CE ডেটা সুরক্ষিত করে, এর জন্য একটি সিক্রেট স্টোর করে যা শুধুমাত্র সীমিত সময়ের জন্য ফিরিয়ে আনা যায়। এটি Android ইকোসিস্টেম জুড়ে কাজ করে।
• ক্রিপ্টোগ্রাফিক কী, যা ব্যবহারকারীর পিন দিয়ে সুরক্ষিত, সেটি ডিভাইস আনলক করতে এবং CE স্টোরেজ ডিক্রিপ্ট করতে ব্যবহার করা হয়।
  • ওভারনাইট রিবুট শিডিউল করা হলে, Android ব্যবহারকারীকে তার পিন লিখতে প্রম্পট করে, তারপর একটি সিন্থেটিক পাসওয়ার্ড (SP) গণনা করে।
  • তারপরে এটি SP-কে দু'বার এনক্রিপ্ট করে: একবার RAM-এ সেভ করা কী K_s দিয়ে এবং আবার TEE-তে সেভ করা কী K_k দিয়ে।
  • ডবল এনক্রিপ্ট করা SP ডিস্কে স্টোর করা হয় এবং RAM থেকে SP মুছে দেওয়া হয়। দুটি কীই নতুন করে তৈরি করা হয় এবং শুধুমাত্র একবার রিবুট করার জন্য ব্যবহার করা হয়।
• রিবুট করার সময় হলে, Android K_s-এর দায়িত্ব সার্ভারকে দেয়। K_k-এর সাথে রসিদ ডিস্কে স্টোর করার আগে এনক্রিপ্ট করা হয়।
• রিবুট করার পরে, Android রসিদ ডিক্রিপ্ট করতে K_k ব্যবহার করে, তারপরে K_s পাওয়ার জন্য সেটি সার্ভারে পাঠায়।
  • ডিস্কে সেভ করা SP ডিক্রিপ্ট করতে K_k ও K_s ব্যবহার করা হয়।
  • CE স্টোরেজ আনলক করতে এবং সাধারণ অ্যাপ স্টার্ট-আপের অনুমতি দিতে Android SP ব্যবহার করে।
  • K_k ও K_s বাতিল করা হয়েছে।

আপনার ফোন সুরক্ষিত রাখার জন্য আপডেট এমন সময়ে হতে পারে যা আপনার জন্য সুবিধাজনক: আপনি যখন ঘুমান।

সিম-পিন রিপ্লে

নির্দিষ্ট কিছু শর্তে, সিম কার্ডের পিন কোড ক্যাশে থেকে যাচাই করা হয়, এই প্রসেসকে সিম-পিন রিপ্লে বলা হয়।

এছাড়াও, চালু করা পিন সহ সিম কার্ডকে অবশ্যই একটি নির্বিঘ্নে পিন কোড যাচাইকরণ (একটি সিম-পিন রিপ্লে) করতে হবে, যাতে আনঅ্যাটেন্ডেড রিবুট করার পরে সেলুলার কানেক্টিভিটি (ফোন কল, এসএমএস মেসেজ এবং ডেটা পরিষেবার জন্য প্রয়োজন) পুনরুদ্ধার করা যায়। সিম পিন ও এর সাথে ম্যাচ করা সিম কার্ডের তথ্য (ICCID ও সিম স্লটের নম্বর) একসাথে নিরাপদে স্টোর করা হয়। সফলভাবে অটোমেটিক রিবুট করার পরেই শুধুমাত্র যাচাইকরণের জন্য সেভ করা পিনটি পুনরুদ্ধার ও ব্যবহার করা যাবে। ডিভাইস সুরক্ষিত হলে, LSKF দ্বারা সুরক্ষিত কী সহ সিম পিন স্টোর করা হয়। সিমের পিন চালু করা থাকলে, OTA আপডেট ও সার্ভার-ভিত্তিক RoR-এর জন্য RoR সার্ভারের সাথে ইন্টার‍্যাক্ট করতে ওয়াই-ফাই কানেকশন প্রয়োজন, যা রিবুট করার পরে (মোবাইল কানেক্টিভিটির সাথে) প্রাথমিক কার্যকারিতা নিশ্চিত করে।

ব্যবহারকারী প্রতিবার সিম কার্ড পিন চালু, যাচাই বা পরিবর্তন করলে, সেটি আবার এনক্রিপ্ট করে সেভ করা হয়। নিম্নলিখিত কোনও একটি ঘটনা ঘটলে সিম কার্ডের পিন বাতিল করা হয়:

• সিম কার্ড সরানো বা রিসেট করা হয়েছে।
• ব্যবহারকারী পিন বন্ধ করে দেন।
• RoR-এর মাধ্যমে শুরু করা হয়নি এমন একটি রিবুট হয়েছে।

RoR-এর মাধ্যমে শুরু করা রিবুট করার পরে, সেভ করা সিম পিন শুধুমাত্র একবার ব্যবহার করা যাবে এবং খুব অল্প সময়ের জন্য (২০ সেকেন্ড)–যদি সিম কার্ডের বিবরণ ম্যাচ করে। সেভ করা সিম কার্ডের পিন TelephonyManager অ্যাপের বাইরে যায় না এবং এক্সটার্নাল মডিউল এটি আর কখনওই ফিরিয়ে আনতে পারে না।

প্রয়োগ করার নির্দেশিকা

Android 12-এ, মাল্টি-ক্লায়েন্ট ও সার্ভার-ভিত্তিক RoR ফাংশন OTA আপডেট পুশ করার সময় পার্টনারদের উপর কম লোড দেয়। প্রয়োজনীয় আপডেট ডিভাইস ডাউনটাইম চলাকালীন হতে পারে, যেমন নির্ধারিত ঘুমের সময়।

এই সময়সীমার মধ্যে OTA আপডেট যাতে ব্যবহারকারীদের বাধা না দেয় তা নিশ্চিত করতে, আলোর নির্গমন কমাতে ডার্ক মোড ব্যবহার করুন। এটি করতে, ডিভাইসের বুটলোডারকে কারণ স্ট্রিং unattended সার্চ করতে দিন। unattended true হলে, ডিভাইসটি ডার্ক মোডে রাখুন। মনে রাখবেন যে সাউন্ড ও লাইট নির্গমন কমানোর দায়িত্ব প্রতিটি OEM-এর।

আপনি Android 12-এ আপগ্রেড করলে অথবা Android 12 ডিভাইস লঞ্চ করলে, নতুন RoR কার্যকারিতা প্রয়োগ করার জন্য আপনাকে কিছু করতে হবে না।

মাল্টি-ক্লায়েন্ট ফ্লোতে একটি নতুন কল আছে, isPreparedForUnattendedUpdate, যা নিচে দেখানো হয়েছে:

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

আপনাকে এটি প্রয়োগ করতে হবে না, কারণ Android 12 থেকে HAL সিস্টেম আর ব্যবহার করা হয় না।

TelephonyManager

Android 12-এ রিবুট করার প্রয়োজন হলে OTA ক্লায়েন্ট TelephonyManager সিস্টেম API ব্যবহার করে। এই API সব ক্যাশে করা পিন কোডকে 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()

বিশেষ সুবিধা প্রাপ্ত APK-এর মাধ্যমে TelephonyManager সিস্টেম API ব্যবহার করা হয়।

পরীক্ষা করা

নতুন API পরীক্ষা করতে, এই কমান্ডটি চালান:

    adb shell cmd phone unattended-reboot

এই কমান্ড শুধুমাত্র তখনই কাজ করে যখন শেল রুট (adb root) হিসেবে রান করে।

শুধুমাত্র Android 11

এই পৃষ্ঠার বাকি অংশ Android 11-এর ক্ষেত্রে প্রযোজ্য।

জুলাই, ২০২০ পর্যন্ত, RoR HAL-এর প্রয়োগকে দুটি বিভাগে ভাগ করা যায়:

1. SoC হার্ডওয়্যার যদি রিবুট করা জুড়ে RAM পারসিস্টেন্স কাজ করে, তাহলে OEM-রা AOSP-তে ডিফল্ট ইমপ্লিমেন্টেশন (ডিফল্ট RAM এসক্রো) ব্যবহার করতে পারবে।
2. ডিভাইস হার্ডওয়্যার বা SoC যদি সুরক্ষিত হার্ডওয়্যার এনক্লেভ (নিজস্ব RAM ও ROM সহ আলাদা নিরাপত্তা কোপ্রসেসর) সাপোর্ট করে, তাহলে অতিরিক্ত হিসেবে এটি নিম্নলিখিত কাজগুলি করতে হবে:
   • মূল CPU রিবুট শনাক্ত করতে পারা।
   • এমন হার্ডওয়্যার টাইমার সোর্স থাকতে হবে যা রিবুট করার পরেও থেকে যায়। অর্থাৎ, এনক্লেভকে রিবুট শনাক্ত করতে হবে এবং রিবুটের আগে সেট করা টাইমারকে এক্সপায়ার করতে হবে।
   • এনক্লেভ RAM/ROM-এ এসক্রো করা কী স্টোর করার সুবিধা যাতে অফলাইন অ্যাটাকের মাধ্যমে এটি ফিরিয়ে আনা না যায়। এটি RoR কী এমনভাবে স্টোর করবে যাতে ইনসাইডার বা আক্রমণকারীদের পক্ষে এটি রিকভার করা অসম্ভব হয়ে যায়।

ডিফল্ট RAM এস্ক্রো

AOSP-তে RAM পারসিস্টেন্স ব্যবহার করে RoR HAL-এর প্রয়োগ করা হয়েছে। এটি কাজ করার জন্য, OEM-কে অবশ্যই নিশ্চিত করতে হবে যে তাদের SoC রিবুট জুড়ে RAM পারসিস্টেন্স সাপোর্ট করে। কিছু SoC রিবুট করার পরে RAM কন্টেন্ট সেভ করতে পারে না, তাই এই ডিফল্ট HAL চালু করার আগে OEM-দের SoC পার্টনারদের সাথে পরামর্শ করার পরামর্শ দেওয়া হয়। নিম্নলিখিত বিভাগে এর ক্যাননিকাল রেফারেন্স।

RoR ব্যবহার করে OTA আপডেট করার ফ্লো

RoR প্রয়োগ করার জন্য প্রয়োজনীয় পদ্ধতি কল করতে, ফোনে OTA ক্লায়েন্ট অ্যাপের কাছে অবশ্যই Manifest.permission.REBOOT ও Manifest.permission.RECOVERY অনুমতি থাকতে হবে। এই পূর্বশর্ত পূরণ করা হলে, আপডেট করার প্রক্রিয়া এইসব ধাপ অনুসরণ করে:

1. OTA ক্লায়েন্ট অ্যাপ আপডেট ডাউনলোড করে।
2. OTA ক্লায়েন্ট অ্যাপ RecoverySystem#prepareForUnattendedUpdate-কে কল করে, যা ব্যবহারকারীকে তার পিন, প্যাটার্ন বা পাসওয়ার্ড দেওয়ার জন্য প্রম্পট করে। এটি পরবর্তী আনলক করার সময় লক স্ক্রিনে দেখানো হয়।
3. ব্যবহারকারী লকস্ক্রিনে ডিভাইস আনলক করেন এবং আপডেট প্রয়োগ করার জন্য ডিভাইস রেডি হয়ে যায়।
4. OTA ক্লায়েন্ট অ্যাপ RecoverySystem#rebootAndApply-এ কল করে, যা অবিলম্বে রিবুট ট্রিগার করে।

এই ফ্লোয়ের শেষে, ডিভাইস রিবুট হয় এবং RoR মেকানিজম ক্রেডেনশিয়াল এনক্রিপ্টেড (CE) স্টোরেজ আনলক করে। অ্যাপের কাছে এটি সাধারণ ব্যবহারকারীর আনলক হিসেবেই মনে হয়, তাই তারা 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

ডিফল্ট রিবুট এস্ক্রো HAL প্রয়োগ

ডিফল্ট প্রয়োগ ব্যবহার করতে, আপনাকে অবশ্যই ৬৫৫৩৬ (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