ใน 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 แบ่งออกเป็นสองประเภท:
- หากฮาร์ดแวร์ SoC รองรับการคงอยู่ของ RAM ในการรีบูต OEM สามารถใช้การใช้งานเริ่มต้นใน AOSP ( Default RAM Escrow )
- หากฮาร์ดแวร์ของอุปกรณ์หรือ 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 ด้วยข้อกำหนดเบื้องต้นนั้น โฟลว์ของการอัปเดตจะทำตามขั้นตอนเหล่านี้:
- แอพไคลเอนต์ OTA ดาวน์โหลดการอัปเดต
- แอปไคลเอ็นต์ OTA จะเรียกใช้
RecoverySystem#prepareForUnattendedUpdateซึ่งจะทริกเกอร์ผู้ใช้ให้ป้อน PIN, รูปแบบ หรือรหัสผ่านบนหน้าจอล็อกระหว่างการปลดล็อกครั้งถัดไป - ผู้ใช้ปลดล็อกอุปกรณ์ที่หน้าจอล็อก และอุปกรณ์พร้อมที่จะใช้การอัปเดต
- แอปไคลเอ็นต์ 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