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

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

แม้ว่าพาร์ทเนอร์จะสามารถจับคู่กระบวนการนี้กับฟีเจอร์ระบบ OTA ที่ใช้การอัปเดตเมื่อคาดว่าอุปกรณ์ไม่มีการใช้งานใน Android 11 แต่พาร์ทเนอร์ Android 12 ใน 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 ไว้ในอุปกรณ์ด้วย นี่คือภาพรวมของกระบวนการเพื่อตรวจสอบว่าระดับความปลอดภัยที่ระบุคล้ายกับระบบ 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 แล้ว

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

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

เล่น PIN ซ้ำของซิม

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

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

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

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

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

มีการเรียกใช้ใหม่ 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 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

คำสั่งนี้จะทำงานเมื่อ 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_COMPLETED และ ACTION_BOOT_COMPLETED ตามปกติ

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

ผลิตภัณฑ์ที่ทําเครื่องหมายว่ารองรับฟีเจอร์ 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