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

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

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

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

ฉากหลัง

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

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

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

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

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

ความสามารถ

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

ข้อจำกัด

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

โซลูชัน

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

• Android จะใช้การป้องกันด้วยการเข้ารหัสกับข้อมูลที่จัดเก็บไว้ในอุปกรณ์
• ข้อมูลทั้งหมดจะได้รับการปกป้องโดยคีย์ที่จัดเก็บไว้ในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)
• TEE จะปล่อยคีย์ก็ต่อเมื่อระบบปฏิบัติการที่ทำงานอยู่ผ่านการตรวจสอบสิทธิ์การเข้ารหัส (การเปิดเครื่องที่ได้รับการยืนยัน)
• บริการ RoR ที่ทำงานบนเซิร์ฟเวอร์ของ Google จะรักษาความปลอดภัยให้กับข้อมูล CE ด้วยการจัดเก็บข้อมูลลับที่สามารถเรียกดูได้เป็นระยะเวลาที่จำกัดเท่านั้น ซึ่งใช้ได้กับระบบนิเวศของ Android
• ระบบจะใช้คีย์การเข้ารหัสที่ป้องกันด้วย PIN ของผู้ใช้เพื่อปลดล็อกอุปกรณ์และถอดรหัสพื้นที่เก็บข้อมูล CE
  • เมื่อกำหนดเวลารีบูตแบบข้ามคืน Android จะแจ้งให้ผู้ใช้ป้อน PIN จากนั้นคำนวณรหัสผ่านสังเคราะห์ (SP)
  • จากนั้นจะเข้ารหัส SP 2 ครั้ง โดยการเข้ารหัสครั้งแรกจะใช้คีย์ K_s ที่เก็บไว้ใน RAM และการเข้ารหัสครั้งที่ 2 จะใช้คีย์ 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 และหมายเลขช่อง SIM) ไว้ด้วยกันอย่างปลอดภัย จะเรียกคืนและใช้ PIN ที่จัดเก็บไว้ได้ ต่อเมื่อการรีบูตโดยไม่ต้องมีการดูแลสำเร็จเท่านั้น หากอุปกรณ์มีการรักษาความปลอดภัย PIN ของซิมจะจัดเก็บไว้พร้อมกับคีย์ที่ได้รับการปกป้องโดย LSKF หากซิมเปิดใช้ PIN อยู่ การโต้ตอบกับเซิร์ฟเวอร์ RoR ต้องมีการเชื่อมต่อ Wi-Fi สำหรับการอัปเดต OTA และ RoR ของเซิร์ฟเวอร์ ซึ่งจะช่วยให้มั่นใจได้ถึงฟังก์ชันการทำงานพื้นฐาน (ด้วยการเชื่อมต่อเครือข่ายมือถือ) หลังจากรีบูต

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

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

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

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

ใน 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

TelephonyManager

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

การทดสอบ

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

    adb shell cmd phone unattended-reboot

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

Android 11 เท่านั้น

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

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

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

วงเงินประกัน 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 ต้องติดตั้งใช้งาน ทั้งหมดที่มี การสร้างแคมเปญ ทั้งหมดที่มีการเปิด Chromebook ใหม่ และมีไฟล์ 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

ใน 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