ดำเนินการต่อเมื่อรีบูต

ใน Android 11 สามารถใช้การอัปเดต OTA ได้โดยใช้การอัปเดต A/B หรือกลไก การอัปเดต A/B เสมือนรวมกับ RecoverySystem วิธีการของชั้นเรียน หลังจากรีบูตอุปกรณ์เพื่อใช้การอัปเดต OTA การดำเนินการต่อเมื่อรีบูต (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 จะปลดล็อกโดย ผู้ใช้รายนั้น การใช้การสนับสนุน Direct Boot ช่วยให้ผู้ใช้ได้รับ ประสบการณ์ก่อนที่จะป้อน "ปัจจัยความรู้สำหรับหน้าจอล็อก" (LSKF) หลังจากเปิดเครื่อง

RoR ช่วยให้ปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมดในอุปกรณ์ได้ ซึ่งรวมถึง แอปที่ไม่รองรับ Direct Boot เมื่อเริ่มต้นการรีบูตหลังจาก การอัปเดต 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 ครั้ง กล่าวคือ 1 ครั้งโดยใช้คีย์ 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 ของซิมการ์ดจะได้รับการยืนยันจากแคช ซึ่งเป็นกระบวนการที่เรียกว่าการเล่นซ้ำ SIM-PIN

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

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

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

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

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

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

เพื่อให้มั่นใจว่าการอัปเดต OTA ในช่วงเวลาดังกล่าวจะไม่รบกวนผู้ใช้ ใช้โหมดมืดเพื่อลดการปล่อยแสง โดยเตรียมอุปกรณ์ ค้นหา Bootloader สำหรับเหตุผลสตริง 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

เครื่องมือจัดการโทรศัพท์

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

 /**
    * 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 System API

การทดสอบ

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

    adb shell cmd phone unattended-reboot

คำสั่งนี้จะทำงานเมื่อ Shell ทำงานเป็นราก (adb root) เท่านั้น

Android 11 เท่านั้น

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

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

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

บัญชีดูแล RAM เริ่มต้น

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

ขั้นตอนการอัปเดต 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_เสร็จสมบูรณ์ และ ACTION_BOOT_เสร็จสมบูรณ์ ตามปกติ

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

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

ในแผนผังอุปกรณ์ของเคอร์เนลของ 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