Resume-on-Reboot

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

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

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

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

พื้นหลัง

เริ่มต้นด้วย Android 7 Android รองรับ Direct Boot ซึ่งช่วยให้แอปบนอุปกรณ์สามารถเริ่มทำงานก่อนที่ผู้ใช้จะปลดล็อกที่เก็บข้อมูล CE การปรับใช้การสนับสนุน Direct Boot ช่วยให้ผู้ใช้ได้รับประสบการณ์ที่ดีขึ้นก่อนที่จะต้องป้อน Lock Screen Knowledge Factor (LSKF) หลังจากการบู๊ต

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

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

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

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

ความสามารถ

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

ข้อจำกัด

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

สารละลาย

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

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

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

เล่นซ้ำ SIM-PIN

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

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

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

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

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

แนวทางปฏิบัติ

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

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

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

ผู้จัดการโทรศัพท์

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

API ระบบ TelephonyManager ถูกใช้โดย APK ที่มีสิทธิ์

การทดสอบ

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

    adb shell cmd phone unattended-reboot

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

Android 11 เท่านั้น

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

ณ เดือนกรกฎาคม 2020 การใช้งาน RoR HAL แบ่งออกเป็นสองประเภท:

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

Escrow RAM เริ่มต้น

AOSP มีการนำ RoR HAL ไปใช้โดยใช้การคงอยู่ของ 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 ต้องมีการใช้งาน 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

การเริ่มต้นใช้งาน escrow 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