หน้านี้ได้รับการแปลโดย Cloud Translation API

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 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 จะปล่อยคีย์ก็ต่อเมื่อระบบปฏิบัติการที่รันอยู่ผ่านการพิสูจน์ตัวตนด้วยการเข้ารหัส ( การบูตที่ตรวจสอบแล้ว )
บริการ 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 ที่ราบรื่น (การเล่น SIM-PIN ซ้ำ) หลังจากรีบูตเครื่องโดยไม่ต้องใส่เพื่อกู้คืนการเชื่อมต่อเซลลูลาร์ (จำเป็นสำหรับการโทรศัพท์ ข้อความ SMS และบริการข้อมูล) PIN ของ SIM และข้อมูล SIM การ์ดที่ตรงกัน (หมายเลข ICCID และ SIM slot number) จะถูกเก็บไว้ด้วยกันอย่างปลอดภัย PIN ที่เก็บไว้สามารถเรียกคืนและใช้สำหรับการยืนยันหลังจากการรีบูตแบบอัตโนมัติสำเร็จเท่านั้น หากอุปกรณ์มีการรักษาความปลอดภัย รหัส PIN ของซิมจะถูกจัดเก็บด้วยคีย์ที่ป้องกันโดย LSKF หาก SIM เปิดใช้งาน 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

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

แอนดรอยด์ 11 เท่านั้น

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

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

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

RAM Escrow เริ่มต้น

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

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

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

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

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

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

ผลิตภัณฑ์ที่ทำเครื่องหมายว่าสนับสนุนฟีเจอร์ RoR ใน Android 11 ต้องมีการใช้งาน RebootEscrow HAL และรวมไฟล์ XML ของตัวทำเครื่องหมายฟีเจอร์ การใช้งานเริ่มต้นจะทำงานได้ดีบนอุปกรณ์ที่ใช้การรีบูตแบบอบอุ่น (เมื่อพลังงานไปยัง DRAM ยังคงเปิดอยู่ในระหว่างการรีบูต)

รีบูตเครื่องหมายคุณลักษณะ escrow

ต้องมีเครื่องหมายคุณลักษณะอยู่ด้วย:

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

พื้นหลัง

รูปแบบภัยคุกคาม

ความสามารถ

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

ข้อจำกัด

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

สารละลาย

Android ใช้การป้องกันการเข้ารหัสกับข้อมูลที่จัดเก็บไว้ในอุปกรณ์
ข้อมูลทั้งหมดได้รับการปกป้องโดยคีย์ที่จัดเก็บไว้ใน สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)
TEE จะปล่อยคีย์ก็ต่อเมื่อระบบปฏิบัติการที่รันอยู่ผ่านการพิสูจน์ตัวตนด้วยการเข้ารหัส ( การบูตที่ตรวจสอบแล้ว )
บริการ 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
เกิดการรีบูตที่ไม่ได้เริ่มต้นโดย RoR

แนวทางการดำเนินการ

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

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

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

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

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

แอนดรอยด์ 11 เท่านั้น

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

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

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

RAM Escrow เริ่มต้น

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

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

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

รีบูตเครื่องหมายคุณลักษณะ escrow

ต้องมีเครื่องหมายคุณลักษณะอยู่ด้วย:

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

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

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

การเปลี่ยนแปลง 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

พื้นหลัง

รูปแบบภัยคุกคาม

ความสามารถ

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

ข้อจำกัด

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

สารละลาย

Android ใช้การป้องกันการเข้ารหัสกับข้อมูลที่จัดเก็บไว้ในอุปกรณ์
ข้อมูลทั้งหมดได้รับการปกป้องโดยคีย์ที่จัดเก็บไว้ใน สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)
TEE จะปล่อยคีย์ก็ต่อเมื่อระบบปฏิบัติการที่รันอยู่ผ่านการพิสูจน์ตัวตนด้วยการเข้ารหัส ( การบูตที่ตรวจสอบแล้ว )
บริการ 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
เกิดการรีบูตที่ไม่ได้เริ่มต้นโดย RoR

แนวทางการดำเนินการ

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

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

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

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

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

แอนดรอยด์ 11 เท่านั้น

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

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

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

RAM Escrow เริ่มต้น

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

แอปไคลเอนต์ OTA ดาวน์โหลดการอัปเดต
OTA client app calls to RecoverySystem#prepareForUnattendedUpdate which triggers the user to be prompted for their PIN, pattern, or password on the lock screen during the next unlock.
The user unlocks the device at the lockscreen, and the device is ready to have the update applied.
OTA client app calls to RecoverySystem#rebootAndApply , which immediately triggers a reboot.

At the end of this flow, the device reboots and the RoR mechanism unlocks the credential encrypted (CE) storage. To apps, this appears as a normal user unlock, so they receive all the signals, such as ACTION_LOCKED_BOOT_COMPLETED and ACTION_BOOT_COMPLETED that they normally do.

Modifying product configurations

A product marked as supporting the RoR feature in Android 11 must include an implementation of the RebootEscrow HAL and include the feature marker XML file. The default implementation works well on devices that use warm reboot (when the power to DRAM remains on during reboot).

Reboot escrow feature marker

The feature marker must also be present:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

Default reboot escrow HAL implementation

To use the default implementation, you must reserve 65536 (0x10000) bytes. Never write these bytes to non-volatile storage to ensure that the security properties persist.

Linux kernel device tree changes

In the Linux kernel's device tree, you must reserve memory for a pmem region. The following example shows 0x50000000 being reserved:

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

Verify that you have a new device in the block directory with a name like /dev/block/pmem0 (such as pmem1 or pmem2 ).

Device.mk changes

Assuming that your new device from the previous step is named pmem0 , you must ensure the following new entries get added to 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 rules

Add these new entries to the device's 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