กลับมาทำงานต่อเมื่อรีบูต

ใน Android 11 คุณสามารถใช้การอัปเดต OTA โดยใช้กลไกการอัปเดต A/B หรือการอัปเดต A/B แบบเสมือน ร่วมกับเมธอดคลาส RecoverySystem หลังจากที่อุปกรณ์รีบูตเพื่อใช้การอัปเดต OTA แล้ว Resume-on-Reboot (RoR) จะปลดล็อกที่เก็บข้อมูลที่เข้ารหัสด้วยข้อมูลเข้าสู่ระบบ (CE) ของอุปกรณ์

แม้ว่าพาร์ทเนอร์จะจับคู่กระบวนการนี้กับฟีเจอร์ระบบ OTA ที่ใช้การอัปเดตเมื่อคาดว่าอุปกรณ์จะไม่มีการใช้งานใน Android 11 แต่ใน Android 12 พาร์ทเนอร์ไม่จำเป็นต้องใช้ฟีเจอร์ระบบ OTA เพิ่มเติม กระบวนการ RoR ช่วยเพิ่มความปลอดภัยและความสะดวกสบายให้แก่ผู้ใช้เนื่องจาก สามารถทำการอัปเดตได้ในระหว่างที่อุปกรณ์ไม่ได้ใช้งาน ขณะที่ฟังก์ชันการอัปเดตแบบหลายไคลเอ็นต์และแบบเซิร์ฟเวอร์ของ Android 12 จะทำงานร่วมกันเพื่อมอบความปลอดภัยระดับฮาร์ดแวร์ของอุปกรณ์

แม้ว่าคุณจะต้องให้สิทธิ์ของอุปกรณ์เพื่อให้android.hardware.reboot_escrow ฟีเจอร์รองรับ RoR ใน Android 11 แต่คุณไม่จำเป็นต้องทำเช่นนี้เพื่อเปิดใช้ RoR ที่อิงตามเซิร์ฟเวอร์ใน Android 12 ขึ้นไป เนื่องจากฟีเจอร์ดังกล่าวไม่ได้ใช้ HAL

ฉากหลัง

ตั้งแต่ Android 7 เป็นต้นมา Android รองรับการบูตโดยตรง ซึ่งช่วยให้แอปในอุปกรณ์เริ่มทำงานได้ก่อนที่ผู้ใช้จะปลดล็อกพื้นที่เก็บข้อมูล CE การรองรับการบูตโดยตรงช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีขึ้น ก่อนที่จะต้องป้อนปัจจัยความรู้ของหน้าจอล็อก (LSKF) หลังการบูต

RoR ช่วยให้ปลดล็อกที่เก็บข้อมูล CE ของแอปทั้งหมดในอุปกรณ์ได้ ซึ่งรวมถึง แอปที่ไม่รองรับการบูตโดยตรง เมื่อมีการรีบูตหลังจากการอัปเดต OTA ฟีเจอร์นี้ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปทั้งหมดที่ติดตั้งไว้ หลังจากรีบูต

โมเดลภัยคุกคาม

การติดตั้งใช้งาน RoR ต้องรับประกันว่าเมื่ออุปกรณ์ตกไปอยู่ในมือของผู้โจมตี ผู้โจมตีจะกู้คืนข้อมูลที่เข้ารหัส CE ของผู้ใช้ได้ยากมาก แม้ว่าอุปกรณ์จะเปิดอยู่ ที่เก็บข้อมูล CE จะปลดล็อก และผู้ใช้จะปลดล็อกอุปกรณ์หลังจากได้รับการอัปเดต OTA แล้วก็ตาม ความต้านทานการโจมตีจากภายในต้องมีประสิทธิภาพแม้ว่าผู้โจมตีจะได้รับสิทธิ์เข้าถึงคีย์การลงนามแบบเข้ารหัสที่ใช้ในการออกอากาศก็ตาม

กล่าวโดยละเอียดคือ ผู้โจมตีที่เข้าถึงอุปกรณ์ได้โดยตรงต้องอ่านที่เก็บข้อมูล CE ไม่ได้ และต้องมีความสามารถและข้อจำกัดต่อไปนี้

ความสามารถ

• ใช้คีย์การลงนามของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามข้อความที่กำหนดเอง
• อาจทำให้อุปกรณ์ได้รับการอัปเดต OTA
• สามารถแก้ไขการทำงานของฮาร์ดแวร์ใดๆ (เช่น โปรเซสเซอร์แอปพลิเคชัน หรือหน่วยความจำแฟลช) ยกเว้นตามที่ระบุไว้ในข้อจำกัดด้านล่าง (อย่างไรก็ตาม การแก้ไขดังกล่าวจะทำให้เกิดความล่าช้าอย่างน้อย 1 ชั่วโมง และ การเปิด/ปิดเครื่องที่จะล้างเนื้อหาใน RAM)

ข้อจำกัด

• แก้ไขการทำงานของฮาร์ดแวร์ที่ป้องกันการดัดแปลงไม่ได้ (เช่น Titan M)
• อ่าน RAM ของอุปกรณ์ที่ใช้งานจริงไม่ได้
• คาดเดาข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) หรือทำให้มีการป้อนข้อมูลดังกล่าวไม่ได้

โซลูชัน

ระบบอัปเดต RoR ของ Android 12 ช่วยรักษาความปลอดภัย จากผู้โจมตีที่มีความซับซ้อนสูงมาก และดำเนินการดังกล่าวในขณะที่รหัสผ่านและ PIN ในอุปกรณ์ยังคงอยู่ในอุปกรณ์ โดยจะไม่มีการส่งหรือจัดเก็บไว้ในเซิร์ฟเวอร์ของ Google ต่อไปนี้เป็นภาพรวมของกระบวนการที่ช่วยให้มั่นใจได้ว่าระดับความปลอดภัยที่ระบุจะ คล้ายกับระบบ RoR ระดับอุปกรณ์ที่ใช้ฮาร์ดแวร์

• Android ใช้การป้องกันด้วยการเข้ารหัสกับข้อมูลที่จัดเก็บไว้ในอุปกรณ์
• ข้อมูลทั้งหมดได้รับการปกป้องโดยคีย์ที่จัดเก็บไว้ในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)
• TEE จะปล่อยคีย์ก็ต่อเมื่อระบบปฏิบัติการที่ทำงานผ่าน การตรวจสอบสิทธิ์ด้วยการเข้ารหัส (การเปิดเครื่องที่ได้รับการยืนยัน)
• บริการ RoR ที่ทำงานในเซิร์ฟเวอร์ของ Google จะรักษาความปลอดภัยของข้อมูล CE โดยการจัดเก็บข้อมูลลับ ที่เรียกข้อมูลได้ในช่วงเวลาที่จำกัดเท่านั้น ซึ่งใช้ได้กับระบบนิเวศของ Android
• ระบบจะใช้คีย์การเข้ารหัสที่ได้รับการปกป้องด้วย PIN ของผู้ใช้เพื่อปลดล็อกอุปกรณ์ และถอดรหัสพื้นที่เก็บข้อมูล CE
  • เมื่อกำหนดเวลาการรีบูตข้ามคืนแล้ว Android จะแจ้งให้ผู้ใช้ป้อน PIN จากนั้นจะคำนวณรหัสผ่านสังเคราะห์ (SP)
  • จากนั้นจะเข้ารหัส SP 2 ครั้ง โดยครั้งแรกจะใช้คีย์ K_s ที่จัดเก็บไว้ใน RAM และอีกครั้งจะใช้คีย์ K_k ที่จัดเก็บไว้ใน TEE
  • ระบบจะจัดเก็บ SP ที่เข้ารหัส 2 ชั้นไว้ในดิสก์ และล้าง SP ออกจาก RAM คีย์ทั้ง 2 รายการสร้างขึ้นใหม่และใช้สำหรับรีบูตเพียงครั้งเดียว
• เมื่อถึงเวลารีบูต Android จะมอบความไว้วางใจให้ K_s แก่เซิร์ฟเวอร์ ใบเสร็จ ที่มี K_k จะได้รับการเข้ารหัสก่อนที่จะจัดเก็บไว้ในดิสก์
• หลังจากรีบูตแล้ว Android จะใช้ K_k เพื่อถอดรหัสใบเสร็จ จากนั้นจะส่งใบเสร็จไปยังเซิร์ฟเวอร์เพื่อดึงข้อมูล K_s
  • K_k และ K_s ใช้เพื่อถอดรหัส SP ที่จัดเก็บไว้ในดิสก์
  • Android ใช้ SP เพื่อปลดล็อกที่เก็บข้อมูล CE และอนุญาตให้แอปเริ่มต้นทำงานตามปกติ
  • ระบบจะทิ้งK_kและK_s

การอัปเดตที่ช่วยรักษาความปลอดภัยของโทรศัพท์จะเกิดขึ้นในเวลาที่คุณสะดวก นั่นก็คือขณะที่คุณนอนหลับ

การเล่นซ้ำด้วย PIN ของซิม

ในบางกรณี ระบบจะยืนยันรหัส PIN ของซิมการ์ดจากแคช ซึ่งเป็นกระบวนการที่เรียกว่าการเล่นซ้ำ PIN ของซิม

ซิมการ์ดที่เปิดใช้ PIN จะต้องผ่านการยืนยันรหัส PIN ที่ราบรื่น (การเล่นซ้ำของ PIN ของซิม) หลังจากรีบูตโดยไม่มีการดูแลเพื่อกู้คืนการเชื่อมต่อเครือข่ายมือถือ (จำเป็นสำหรับการโทร ข้อความ SMS และบริการข้อมูล) ระบบจะจัดเก็บ PIN ของซิมและข้อมูลซิมการ์ดที่ตรงกัน (ICCID และหมายเลขช่องใส่ซิม ) ไว้ด้วยกันอย่างปลอดภัย คุณจะเรียกข้อมูลและใช้ PIN ที่จัดเก็บไว้ เพื่อการยืนยันได้หลังจากรีบูตโดยไม่ต้องมีการโต้ตอบสำเร็จแล้วเท่านั้น หากอุปกรณ์ได้รับการรักษาความปลอดภัย ระบบจะจัดเก็บ PIN ของซิมพร้อมกับคีย์ที่ได้รับการปกป้องโดย LSKF หาก SIM เปิดใช้ PIN การโต้ตอบกับเซิร์ฟเวอร์ RoR ต้องใช้การเชื่อมต่อ Wi-Fi สำหรับการอัปเดต OTA และ RoR ที่อิงตามเซิร์ฟเวอร์ ซึ่งจะช่วยให้มั่นใจได้ถึงฟังก์ชันพื้นฐาน (ที่มี การเชื่อมต่อเครือข่ายมือถือ) หลังจากรีบูต

ระบบจะเข้ารหัส PIN ของซิมอีกครั้งและจัดเก็บไว้ทุกครั้งที่ผู้ใช้เปิดใช้ ยืนยัน หรือแก้ไข PIN ของซิมสำเร็จ ระบบจะทิ้ง PIN ของซิมหากเกิดกรณีใดกรณีหนึ่งต่อไปนี้

• มีการนำซิมออกหรือรีเซ็ต
• ผู้ใช้ปิดใช้ PIN
• เกิดการรีบูตที่ไม่ได้เริ่มต้นโดย RoR

คุณจะใช้ PIN ของซิมที่จัดเก็บไว้ได้เพียงครั้งเดียวหลังจากรีบูตที่ RoR เริ่มต้น และ ใช้ได้ในช่วงเวลาสั้นๆ เท่านั้น (20 วินาที) หากรายละเอียดของซิม การ์ดตรงกัน PIN ของซิมที่จัดเก็บไว้จะไม่ออกจากแอป TelephonyManager และโมดูลภายนอกจะเรียกข้อมูลไม่ได้

หลักเกณฑ์การใช้งาน

ใน Android 12 ฟังก์ชัน RoR แบบหลายไคลเอ็นต์และแบบเซิร์ฟเวอร์จะช่วยลดภาระงานของพาร์ทเนอร์เมื่อพุชการอัปเดต OTA การอัปเดตที่จำเป็นอาจเกิดขึ้นในช่วงเวลาที่อุปกรณ์หยุดทำงานซึ่งสะดวกสำหรับคุณ เช่น ในช่วง เวลาที่กำหนดสำหรับการนอนหลับ

โปรดใช้โหมดมืดเพื่อลดการปล่อยแสง เพื่อให้การอัปเดต OTA ในช่วงเวลาดังกล่าวไม่ขัดจังหวะผู้ใช้ โดยให้ Bootloader ของอุปกรณ์ ค้นหาสตริง reason unattended หาก unattended เป็น true ให้ตั้งค่าอุปกรณ์เป็นโหมดมืด โปรดทราบว่า OEM แต่ละรายมีหน้าที่รับผิดชอบในการ ลดการปล่อยเสียงและแสง

หากอัปเกรดเป็น Android 12 หรือเปิดตัวอุปกรณ์ Android 12 คุณไม่จำเป็นต้องดำเนินการใดๆ เพื่อใช้ฟังก์ชัน RoR ใหม่

มีการเรียกใหม่ 1 รายการในโฟลว์แบบหลายไคลเอ็นต์ isPreparedForUnattendedUpdate ดังที่แสดงด้านล่าง

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

คุณไม่จำเป็นต้องใช้ HAL นี้เนื่องจากมีการเลิกใช้งานตั้งแต่ Android 12 เป็นต้นไป

TelephonyManager

ไคลเอ็นต์ OTA จะเรียกใช้ TelephonyManager API ของระบบเมื่อใกล้ถึงเวลาที่ต้องรีบูต ใน Android 12 API นี้จะย้ายรหัส PIN ที่แคชไว้ทั้งหมดจากสถานะ AVAILABLE ไปยังสถานะ REBOOT_READY TelephonyManager ระบบ API ได้รับการปกป้องโดยสิทธิ์ในไฟล์ Manifest ของ 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 ที่มีสิทธิ์จะใช้ API ของระบบ TelephonyManager

การทดสอบ

หากต้องการทดสอบ API ใหม่ ให้เรียกใช้คำสั่งนี้

    adb shell cmd phone unattended-reboot

คำสั่งนี้จะทำงานได้เมื่อเชลล์ทำงานเป็นรูท (adb root) เท่านั้น

Android 11 เท่านั้น

ส่วนที่เหลือของหน้านี้มีผลกับ Android 11

การติดตั้งใช้งาน HAL ของ RoR ณ เดือนกรกฎาคม 2020 แบ่งออกเป็น 2 หมวดหมู่ ได้แก่

1. หากฮาร์ดแวร์ SoC รองรับการคงอยู่ของ RAM เมื่อรีบูต OEM สามารถใช้ การติดตั้งใช้งานเริ่มต้นใน AOSP (การฝาก RAM เริ่มต้น) ได้
2. หากฮาร์ดแวร์ของอุปกรณ์หรือ SoC รองรับการแยกฮาร์ดแวร์ที่ปลอดภัย (หน่วยประมวลผลร่วมด้านความปลอดภัยแบบแยก ที่มี RAM และ ROM ของตัวเอง) อุปกรณ์จะต้องดำเนินการต่อไปนี้ด้วย
   • ตรวจหาการรีบูต CPU หลักได้
   • มีแหล่งที่มาของตัวจับเวลาฮาร์ดแวร์ที่ยังคงอยู่เมื่อรีบูต กล่าวคือ Enclave ต้องตรวจจับการรีบูตและหมดเวลาที่ตั้งไว้ก่อนการรีบูตได้
   • รองรับการจัดเก็บคีย์ที่ฝากไว้ใน RAM/ROM ของเอ็นเคลฟ เพื่อให้ไม่สามารถกู้คืนได้ด้วยการโจมตีแบบออฟไลน์ โดยต้องจัดเก็บคีย์ RoR ในลักษณะที่ ทำให้ผู้ไม่หวังดีหรือผู้โจมตีไม่สามารถกู้คืนได้

การฝาก RAM เริ่มต้น

AOSP มีการติดตั้งใช้งาน HAL ของ RoR โดยใช้การคงอยู่ของ RAM หากต้องการให้ฟีเจอร์นี้ทำงานได้ OEM ต้องตรวจสอบว่า SoC รองรับการคงอยู่ของ RAM เมื่อรีบูต SoC บางตัวไม่สามารถเก็บเนื้อหา RAM ไว้ได้เมื่อรีบูต ดังนั้น เราขอแนะนำให้ OEM ปรึกษาพาร์ทเนอร์ SoC ก่อนเปิดใช้ HAL เริ่มต้นนี้ การอ้างอิงที่แน่นอนสำหรับเรื่องนี้อยู่ในส่วนต่อไปนี้

ขั้นตอนการอัปเดต OTA โดยใช้ RoR

แอปไคลเอ็นต์ OTA ในโทรศัพท์ต้องมีสิทธิ์ Manifest.permission.REBOOT และ Manifest.permission.RECOVERY เพื่อเรียกใช้เมธอดที่จำเป็นในการ ใช้ RoR เมื่อมีข้อกำหนดเบื้องต้นดังกล่าวแล้ว ขั้นตอนการอัปเดตจะเป็นดังนี้

1. แอปไคลเอ็นต์ OTA จะดาวน์โหลดการอัปเดต
2. แอปไคลเอ็นต์ OTA จะเรียกใช้ RecoverySystem#prepareForUnattendedUpdate ซึ่ง จะทริกเกอร์ให้ระบบแจ้งให้ผู้ใช้ป้อน PIN, รูปแบบ หรือรหัสผ่านใน หน้าจอล็อกระหว่างการปลดล็อกครั้งถัดไป
3. ผู้ใช้ปลดล็อกอุปกรณ์ที่หน้าจอล็อก และอุปกรณ์พร้อม ที่จะรับการอัปเดต
4. แอปไคลเอ็นต์ OTA จะเรียกใช้ RecoverySystem#rebootAndApply ซึ่งจะทริกเกอร์การรีบูตทันที

เมื่อสิ้นสุดขั้นตอนการทำงานนี้ อุปกรณ์จะรีบูตและกลไก RoR จะปลดล็อกที่เก็บข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบ (CE) สำหรับแอป การปลดล็อกนี้ จะปรากฏเป็นการปลดล็อกของผู้ใช้ตามปกติ ดังนั้นแอปจะได้รับสัญญาณทั้งหมด เช่น ACTION_LOCKED_BOOT_COMPLETED และ ACTION_BOOT_COMPLETED ตามปกติ

แก้ไขการกำหนดค่าผลิตภัณฑ์

ผลิตภัณฑ์ที่ทำเครื่องหมายว่ารองรับฟีเจอร์ RoR ใน Android 11 ต้องมีการติดตั้งใช้งาน HAL ของ RebootEscrow และมีไฟล์ 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 การฝากรีบูตเริ่มต้น

หากต้องการใช้การติดตั้งใช้งานเริ่มต้น คุณต้องจอง 65536 (0x10000) ไบต์ ห้าม เขียนไบต์เหล่านี้ลงในที่เก็บข้อมูลแบบไม่ลบเลือนเพื่อให้มั่นใจว่าคุณสมบัติด้านความปลอดภัย จะยังคงอยู่

การเปลี่ยนแปลงแผนผังอุปกรณ์เคอร์เนล Linux

ใน Device Tree ของเคอร์เนล 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