ใน Keymaster 1 คีย์ Keymaster ทั้งหมดมีการเชื่อมโยงแบบเข้ารหัสกับอุปกรณ์ รูทของความน่าเชื่อถือ หรือคีย์การเปิดเครื่องที่ได้รับการยืนยัน ใน Keymaster 2 และ 3 ทั้งหมด คีย์จะเชื่อมโยงกับระบบปฏิบัติการและระดับแพตช์ของอิมเมจระบบด้วย ซึ่งทำให้มั่นใจว่าผู้โจมตีที่ค้นพบจุดอ่อนใน เวอร์ชันของซอฟต์แวร์ TEE ของระบบหรือ TEE ต้องไม่ย้อนกลับไปยังช่องโหว่ และใช้คีย์ที่สร้างด้วยเวอร์ชันใหม่ นอกจากนี้ เมื่อคีย์ โดยใช้เวอร์ชันที่กำหนดและระดับแพตช์ในอุปกรณ์ที่อัปเกรดแล้ว เป็นเวอร์ชันใหม่หรือระดับแพตช์ ระบบจะอัปเกรดคีย์ก่อนที่จะใช้งานได้ และคีย์เวอร์ชันก่อนหน้าใช้งานไม่ได้ ด้วยวิธีนี้ เนื่องจากอุปกรณ์ อัปเกรดแล้ว แป้นจะ "ประแจ" ส่งต่อไปพร้อมกับอุปกรณ์ แต่ การย้อนกลับอุปกรณ์ไปเป็นรุ่นก่อนหน้าจะทำให้คีย์ ไม่สามารถใช้งานได้
เพื่อรองรับโครงสร้างโมดูลของ Treble และยุติการเชื่อมโยง system.img ไปยัง Boot.img, Keymaster 4 เปลี่ยนรูปแบบการเชื่อมโยงเวอร์ชันคีย์ให้มี ระดับแพตช์สำหรับแต่ละพาร์ติชัน การดำเนินการนี้ช่วยให้อัปเดตแต่ละพาร์ติชันได้ ได้อย่างอิสระ ขณะเดียวกันก็ยังให้การป้องกันย้อนกลับได้
ใน Android 9 ระบบ boot
, system
และ vendor
โดยแต่ละพาร์ติชันจะมีระดับแพตช์ของตัวเอง
- อุปกรณ์ที่มีการเปิดเครื่องที่ได้รับการยืนยันของ Android (AVB) สามารถวางระดับแพตช์ได้ทั้งหมด
และเวอร์ชันของระบบใน vbmeta เพื่อให้ Bootloader ส่งไปยัง
Keymaster สำหรับพาร์ติชันที่มีการเชื่อมโยง ข้อมูลเวอร์ชันสำหรับพาร์ติชันจะ
อยู่ใน vbmeta ที่เชื่อมถึงกัน โดยทั่วไป ข้อมูลเวอร์ชันควรอยู่ในรูปแบบ
vbmeta struct
ที่มีข้อมูลการยืนยัน (แฮชหรือ แฮชทรี) สำหรับพาร์ติชันที่กำหนด - ในอุปกรณ์ที่ไม่มี AVB
- การใช้งานการเปิดเครื่องที่ได้รับการยืนยันต้องระบุแฮชของเวอร์ชัน ข้อมูลเมตาไปยัง Bootloader เพื่อให้ Bootloader ระบุแฮชให้กับ Keymaster ได้
boot.img
สามารถจัดเก็บระดับแพตช์ในส่วนหัวต่อไปได้system.img
สามารถจัดเก็บระดับแพตช์และเวอร์ชันของระบบปฏิบัติการแบบอ่านอย่างเดียวได้ต่อไป พร็อพเพอร์ตี้vendor.img
จัดเก็บระดับแพตช์ในพร็อพเพอร์ตี้อ่านอย่างเดียวro.vendor.build.version.security_patch
- Bootloader ระบุแฮชของข้อมูลทั้งหมดที่ตรวจสอบโดยการเปิดเครื่องที่ได้รับการยืนยันได้ เป็นคีย์มาสเตอร์
- ใน Android 9 ให้ใช้แท็กต่อไปนี้เพื่อระบุข้อมูลเวอร์ชันสำหรับ
พาร์ติชันต่อไปนี้
VENDOR_PATCH_LEVEL
:vendor
พาร์ติชันBOOT_PATCH_LEVEL
:boot
พาร์ติชันOS_PATCH_LEVEL
และOS_VERSION
: พาร์ติชันsystem
(OS_VERSION
ถูกนำออกจาก ส่วนหัวboot.img
-
การติดตั้งใช้งาน Keymaster ควรจัดการระดับแพตช์ทั้งหมดแยกกัน คีย์คือ
สามารถใช้ได้หากข้อมูลเวอร์ชันทั้งหมดตรงกับค่าที่เชื่อมโยงกับคีย์ และ
IKeymaster::upgradeDevice()
เลื่อนไปที่ระดับแพตช์ที่สูงขึ้นหาก ที่จำเป็น
การเปลี่ยนแปลง HAL
เพื่อสนับสนุนการเชื่อมโยงเวอร์ชันและเอกสารรับรองเวอร์ชัน Android 7.1 ได้เพิ่ม
แท็ก Tag::OS_VERSION
และ Tag::OS_PATCHLEVEL
และแท็ก
เมธอด configure
และ upgradeKey
แท็กเวอร์ชัน
จะถูกเพิ่มโดยอัตโนมัติจากการใช้งาน Keymaster 2+ ในข้อมูลทั้งหมดที่สร้างขึ้นใหม่
(หรืออัปเดต) นอกจากนี้ ความพยายามใดๆ ที่จะใช้คีย์ที่ไม่มีระบบปฏิบัติการ
เวอร์ชันหรือระดับแพตช์ที่ตรงกับเวอร์ชันของระบบปฏิบัติการปัจจุบันหรือระดับแพตช์
จะถูกปฏิเสธด้วย ErrorCode::KEY_REQUIRES_UPGRADE
ตามลำดับ
Tag::OS_VERSION
คือค่า UINT
ที่แสดงค่า
ส่วนหลัก ส่วนเล็กๆ และส่วนย่อยของเวอร์ชันระบบ Android ในรูปแบบ MMmmss
โดยที่ MM คือเวอร์ชันหลัก mm คือเวอร์ชันย่อย และ ss คือเวอร์ชันย่อย
เวอร์ชัน ตัวอย่างเช่น 6.1.2 จะแสดงเป็น 060102
Tag::OS_PATCHLEVEL
คือค่า UINT
ที่แสดงค่า
ปีและเดือนที่อัปเดตระบบครั้งล่าสุดเป็น YYYYMM โดยที่ YYYY คือค่า
ปีแบบ 4 หลัก และ MM คือเลขเดือน 2 หลัก เช่น มีนาคม 2016 จะเป็น
แสดงเป็น 201603
คีย์การอัปเกรด
เพื่อให้สามารถอัปเกรดคีย์เป็นระบบปฏิบัติการเวอร์ชันใหม่และระดับแพตช์ของระบบ
รูปภาพ Android 7.1 เพิ่มเมธอด upgradeKey
ลงใน HAL:
คีย์มาสเตอร์ 3
upgradeKey(vec keyBlobToUpgrade, vec upgradeParams) generates(ErrorCode error, vec upgradedKeyBlob);
คีย์มาสเตอร์ 2
keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev, const keymaster_key_blob_t* key_to_upgrade, const keymaster_key_param_set_t* upgrade_params, keymaster_key_blob_t* upgraded_key);
dev
คือโครงสร้างของอุปกรณ์keyBlobToUpgrade
เป็นคีย์ที่ต้องอัปเกรดupgradeParams
เป็นพารามิเตอร์ที่จำเป็นสำหรับการอัปเกรดคีย์ เหล่านี้ จะรวมTag::APPLICATION_ID
และTag::APPLICATION_DATA
ซึ่งจำเป็นสำหรับการถอดรหัสคีย์ BLOB หากมีการระบุระหว่างการสร้างupgradedKeyBlob
คือพารามิเตอร์เอาต์พุตที่ใช้ในการแสดงผล คีย์ Blob ใหม่
หากมีการเรียก upgradeKey
ด้วย BLOB คีย์ที่แยกวิเคราะห์ไม่ได้ หรือ
หากไม่ถูกต้อง ระบบจะแสดงผล ErrorCode::INVALID_KEY_BLOB
หาก
จะถูกเรียกด้วยคีย์ที่มีระดับแพตช์มากกว่าค่าระบบปัจจุบัน
จะแสดง ErrorCode::INVALID_ARGUMENT
หากมีการเรียกด้วยคีย์
ที่มีเวอร์ชันของระบบปฏิบัติการมากกว่าค่าระบบปัจจุบันและค่าระบบ
ไม่ใช่ 0 จะแสดงค่า ErrorCode::INVALID_ARGUMENT
เวอร์ชันของระบบปฏิบัติการ
การอัปเกรดจากที่ไม่ใช่ 0 เป็น 0 ได้ ในกรณีที่เกิดข้อผิดพลาด
การสื่อสารกับโลกที่ปลอดภัย จะแสดงค่าข้อผิดพลาดที่เหมาะสม (เช่น
ErrorCode::SECURE_HW_ACCESS_DENIED
,
ErrorCode::SECURE_HW_BUSY
) มิเช่นนั้น ระบบจะส่งคืน
ErrorCode::OK
และแสดงผล BLOB คีย์ใหม่ใน
upgradedKeyBlob
keyBlobToUpgrade
ยังคงใช้ได้หลังจาก upgradeKey
และโดยหลักการแล้ว อาจจะใช้งานได้อีกครั้งหากอุปกรณ์ถูกดาวน์เกรด ใน
การฝึกปฏิบัติ คีย์สโตร์มักจะเรียกใช้ deleteKey
ใน
BLOB ของ keyBlobToUpgrade
ไม่นานหลังการโทรไปยัง
upgradeKey
หาก keyBlobToUpgrade
มีแท็ก
Tag::ROLLBACK_RESISTANT
จากนั้น upgradedKeyBlob
ควร
ได้ด้วย (และควรป้องกันการย้อนกลับ)
การกำหนดค่าที่ปลอดภัย
หากต้องการใช้การเชื่อมโยงเวอร์ชัน TA ของ keymaster จำเป็นต้องมีวิธีรับการเชื่อมโยงเวอร์ชันอย่างปลอดภัย เวอร์ชันปัจจุบันของระบบปฏิบัติการและระดับแพตช์ (ข้อมูลเวอร์ชัน) และเพื่อให้มั่นใจว่า ข้อมูลที่โฆษณาได้รับนั้นจะตรงกับข้อมูลเกี่ยวกับการเรียกใช้ ระบบ
OS_VERSION
เพื่อรองรับการนำส่งข้อมูลเวอร์ชันที่ปลอดภัยให้แก่ TA
เพิ่มช่องในส่วนหัวของรูปภาพเปิดเครื่องแล้ว บิลด์ของอิมเมจการเปิดเครื่อง
ระบบจะป้อนข้อมูลในช่องนี้โดยอัตโนมัติ OEM และผู้ติดตั้งใช้งาน TA หลัก
ต้องทำงานร่วมกันเพื่อแก้ไข Bootloader ของอุปกรณ์เพื่อดึงข้อมูลเวอร์ชัน
จากอิมเมจการเปิดเครื่องและส่งไปยัง TA ก่อนแท็กที่ไม่ปลอดภัย
เมื่อบูตระบบ เพื่อป้องกันไม่ให้ผู้โจมตีแทรกแซงการจัดสรร
ข้อมูลเวอร์ชันให้ TA อีกครั้ง
คุณยังต้องตรวจสอบว่าอิมเมจระบบมีเวอร์ชันเดียวกัน เป็นอิมเมจการเปิดเครื่อง ด้วยเหตุนี้ เราจึงได้เพิ่มวิธีการกำหนดค่า เป็น HAL ของคีย์มาสเตอร์:
keymaster_error_t (*configure)(const struct keymaster2_device* dev, const keymaster_key_param_set_t* params);
อาร์กิวเมนต์ params
ประกอบด้วย Tag::OS_VERSION
และ
Tag::OS_PATCHLEVEL
ไคลเอ็นต์ Keymaster2 เรียกใช้เมธอดนี้
หลังจากเปิด HAL แต่ก่อนที่จะเรียกใช้วิธีการอื่นๆ หากมีวิธีการอื่น
จะถูกเรียกก่อนกำหนดค่า ส่วน TA จะแสดงผล
ErrorCode::KEYMASTER_NOT_CONFIGURED
เมื่อมีการเรียก configure
เป็นครั้งแรกหลังจากอุปกรณ์เปิดเครื่อง
ควรตรวจสอบว่าข้อมูลเวอร์ชันที่ระบุตรงกับข้อมูลที่ได้จาก
Bootloader หากข้อมูลเวอร์ชันไม่ตรงกัน
configure
ส่งคืน ErrorCode::INVALID_ARGUMENT
และรายการทั้งหมด
เมธอดคีย์มาสเตอร์อื่นๆ ยังคงแสดงผลอยู่
ErrorCode::KEYMASTER_NOT_CONFIGURED
หากข้อมูลตรงกัน
configure
แสดงผล ErrorCode::OK
และคีย์มาสเตอร์อื่นๆ
เริ่มทำงานตามปกติ
การเรียก configure
ครั้งต่อๆ ไปจะให้ค่าเดียวกับที่แสดงผลโดย
การเรียกครั้งแรก และไม่เปลี่ยนสถานะของคีย์มาสเตอร์ โปรดทราบว่ากระบวนการนี้
กำหนดให้ OTA ทั้งหมดอัปเดตทั้งอิมเมจระบบและอิมเมจเปิดเครื่อง ก็จะไม่สามารถอัปเดตได้
แยกต่างหากเพื่อให้ข้อมูลเวอร์ชันซิงค์กัน
เนื่องจากระบบจะเรียก configure
โดยระบบที่เป็นเจ้าของเนื้อหานั้นๆ
เพื่อทำการตรวจสอบ ก็มีกรอบเวลาที่แคบสำหรับผู้โจมตีที่จะ
โจมตีอิมเมจระบบและบังคับให้ระบุข้อมูลเวอร์ชันที่
ตรงกับอิมเมจการเปิดเครื่อง แต่ไม่ใช่เวอร์ชันจริงของระบบ
ชุดค่าผสมของการยืนยันอิมเมจการเปิดเครื่อง การตรวจสอบ dm-verity ของอิมเมจระบบ
เนื้อหา และความจริงที่มีการเรียก configure
ในช่วงต้นของ
การบูตระบบควรทำให้หน้าต่างของโอกาสนี้ยากต่อการแสวงหาประโยชน์