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