ใน Android 11 สามารถใช้การอัปเดต OTA ได้โดยใช้ การอัปเดต A/B หรือกลไก การอัปเดต A/B เสมือน รวมกับวิธีการคลาส RecoverySystem หลังจากที่อุปกรณ์รีบูตเพื่อใช้การอัปเดต OTA การดำเนินการต่อเมื่อรีบูต (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 การใช้งานการสนับสนุนการบูตโดยตรงทำให้ผู้ใช้ได้รับประสบการณ์ที่ดีขึ้นก่อนที่จะจำเป็นต้องป้อน 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 อย่างราบรื่น (เล่นซ้ำ SIM-PIN) หลังจากการรีบูตโดยไม่ได้ตั้งใจเพื่อคืนค่าการเชื่อมต่อเซลลูลาร์ (จำเป็นสำหรับการโทร ข้อความ SMS และบริการข้อมูล) PIN ของซิมและข้อมูลซิมการ์ดที่ตรงกัน (หมายเลข ICCID และหมายเลขช่องใส่ซิม) จะถูกจัดเก็บไว้อย่างปลอดภัยด้วยกัน PIN ที่เก็บไว้สามารถเรียกคืนและใช้สำหรับการตรวจสอบได้หลังจากรีบูตเครื่องอัตโนมัติสำเร็จแล้วเท่านั้น หากอุปกรณ์มีการรักษาความปลอดภัย PIN ของซิมจะถูกจัดเก็บไว้พร้อมกับปุ่มที่ป้องกันโดย LSKF หากซิมเปิดใช้งาน PIN การโต้ตอบกับเซิร์ฟเวอร์ RoR ต้องใช้ การเชื่อมต่อ WiFi สำหรับการอัพเดต OTA และ RoR บนเซิร์ฟเวอร์ ซึ่งจะทำให้มั่นใจได้ถึงการทำงานพื้นฐาน (ด้วยการเชื่อมต่อมือถือ) หลังจากรีบูต
PIN ของซิมจะถูกเข้ารหัสใหม่และจัดเก็บทุกครั้งที่ผู้ใช้เปิดใช้งาน ตรวจสอบ หรือแก้ไขได้สำเร็จ PIN ของซิมจะถูกยกเลิกหากเกิดเหตุการณ์อย่างใดอย่างหนึ่งต่อไปนี้:
- ซิมถูกถอดออกหรือรีเซ็ต
- ผู้ใช้ปิดการใช้งาน PIN
- เกิดการรีบูตโดยไม่ได้ริเริ่มโดย RoR
PIN ของ SIM ที่เก็บไว้สามารถใช้ได้เพียง ครั้งเดียว หลังจากการรีบูตที่เริ่มต้นโดย RoR และในช่วงเวลาสั้นๆ เท่านั้น (20 วินาที) หาก รายละเอียดของซิมการ์ดตรงกัน PIN ของ SIM ที่เก็บไว้จะไม่ออกจากแอป 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
TelephonyManager
ไคลเอนต์ 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 แบ่งออกเป็น 2 ประเภท:
- หากฮาร์ดแวร์ SoC รองรับการคงอยู่ของ RAM ตลอดการรีบูต OEM สามารถใช้การใช้งานเริ่มต้นใน AOSP ( Default RAM Escrow )
- หากฮาร์ดแวร์ของอุปกรณ์หรือ SoC รองรับกลุ่มฮาร์ดแวร์ที่ปลอดภัย (ตัวประมวลผลร่วมการรักษาความปลอดภัยแบบแยกที่มี RAM และ ROM ของตัวเอง) จะต้องดำเนินการต่อไปนี้เพิ่มเติม:
- สามารถตรวจจับการรีบูต CPU หลักได้
- มีแหล่งตัวจับเวลาฮาร์ดแวร์ที่คงอยู่ตลอดการรีบูต นั่นคือ เครือข่ายต้องสามารถตรวจจับการรีบูตและหมดเวลาของตัวจับเวลาที่ตั้งไว้ก่อนการรีบูต
- รองรับการจัดเก็บคีย์ที่เอสโครว์ไว้ใน 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 ด้วยข้อกำหนดเบื้องต้นนั้น ขั้นตอนของการอัพเดตจะทำตามขั้นตอนเหล่านี้:
- แอปไคลเอ็นต์ 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