คีย์ที่รวมไว้ในฮาร์ดแวร์

เช่นเดียวกับซอฟต์แวร์เข้ารหัสดิสก์และไฟล์ส่วนใหญ่ การเข้ารหัสพื้นที่เก็บข้อมูลของ Android อาศัยคีย์การเข้ารหัสแบบดิบที่อยู่ในหน่วยความจำระบบเพื่อให้การเข้ารหัสทำงานได้ แม้ว่าการเข้ารหัสจะดำเนินการโดยฮาร์ดแวร์เฉพาะแทนที่จะเป็นซอฟต์แวร์ แต่โดยทั่วไปแล้วซอฟต์แวร์ยังคงต้องจัดการคีย์การเข้ารหัสแบบดิบ

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

Android 11 จึงได้เปิดตัวการรองรับ สำหรับ คีย์ที่รวมด้วยฮาร์ดแวร์ ในกรณีที่มีการรองรับฮาร์ดแวร์ คีย์ที่รวมด้วยฮาร์ดแวร์คือคีย์พื้นที่เก็บข้อมูลที่ฮาร์ดแวร์เฉพาะเท่านั้นที่รู้จักในรูปแบบดิบ ส่วนซอฟต์แวร์จะเห็นและใช้คีย์เหล่านี้ในรูปแบบที่รวม (เข้ารหัส) เท่านั้น ฮาร์ดแวร์นี้ต้องสามารถสร้างและนำเข้าคีย์พื้นที่เก็บข้อมูล รวมคีย์พื้นที่เก็บข้อมูลในรูปแบบชั่วคราวและระยะยาว สร้างคีย์ย่อย โปรแกรมคีย์ย่อยหนึ่งรายการลงในเครื่องมือเข้ารหัสแบบอินไลน์โดยตรง และส่งคืนคีย์ย่อยแยกต่างหากไปยังซอฟต์แวร์

หมายเหตุ: เครื่องมือเข้ารหัสแบบอินไลน์ (หรือ ฮาร์ดแวร์เข้ารหัสแบบอินไลน์) หมายถึงฮาร์ดแวร์ที่เข้ารหัส/ถอดรหัสข้อมูลขณะที่ข้อมูลกำลังเดินทางไปยัง/จากอุปกรณ์พื้นที่เก็บข้อมูล โดยปกติแล้วจะเป็นตัวควบคุมโฮสต์ UFS หรือ eMMC ที่ใช้ส่วนขยายการเข้ารหัสที่กำหนดโดยข้อกำหนด JEDEC ที่เกี่ยวข้อง

การออกแบบ

ส่วนนี้จะนำเสนอการออกแบบฟีเจอร์คีย์ที่รวมด้วยฮาร์ดแวร์ รวมถึงการรองรับฮาร์ดแวร์ที่จำเป็นสำหรับฟีเจอร์นี้ การอธิบายนี้จะเน้นที่การเข้ารหัสตามไฟล์ (FBE) แต่ โซลูชันนี้ใช้กับการเข้ารหัสข้อมูลเมตาได้ด้วย

วิธีหนึ่งในการหลีกเลี่ยงไม่ให้ต้องใช้คีย์การเข้ารหัสแบบดิบในหน่วยความจำระบบคือการเก็บคีย์ไว้ในช่องคีย์ของเครื่องมือเข้ารหัสแบบอินไลน์เท่านั้น อย่างไรก็ตาม วิธีนี้มีปัญหาบางอย่างดังนี้

• จำนวนคีย์การเข้ารหัสอาจเกินจำนวนช่องคีย์
• โดยปกติแล้วเครื่องมือเข้ารหัสแบบอินไลน์จะสูญเสียเนื้อหาในช่องคีย์หากมีการรีเซ็ตตัวควบคุมโฮสต์พื้นที่เก็บข้อมูล การรีเซ็ตตัวควบคุมโฮสต์พื้นที่เก็บข้อมูลเป็น ขั้นตอนการกู้คืนข้อผิดพลาดมาตรฐานที่จะดำเนินการหากเกิดข้อผิดพลาดบางประเภทในพื้นที่เก็บข้อมูล และข้อผิดพลาดดังกล่าวอาจเกิดขึ้นได้ทุกเมื่อ ดังนั้น เมื่อมีการใช้การเข้ารหัสแบบอินไลน์ ระบบปฏิบัติการจะต้องพร้อมที่จะตั้งโปรแกรมช่องคีย์ใหม่ โดยไม่ต้องให้ผู้ใช้ดำเนินการเสมอ
• เครื่องมือเข้ารหัสแบบอินไลน์ใช้ได้เฉพาะในการเข้ารหัส/ถอดรหัสข้อมูลทั้งบล็อกของ ในดิสก์ อย่างไรก็ตาม ในกรณีของ FBE ซอฟต์แวร์ยังคงต้องสามารถทำงานเข้ารหัสอื่นๆ ได้ เช่น การเข้ารหัสชื่อไฟล์และการสร้างตัวระบุคีย์ ซอฟต์แวร์ยังคงต้องเข้าถึงคีย์ FBE แบบดิบเพื่อทำงานอื่นๆ เหล่านี้

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

ลำดับชั้นของคีย์

คุณสามารถสร้างคีย์จากคีย์อื่นๆ ได้โดยใช้ฟังก์ชันการสร้างคีย์ (KDF) เช่น HKDF, ซึ่งจะทำให้เกิด ลำดับชั้นของคีย์

แผนภาพต่อไปนี้แสดงลำดับชั้นของคีย์ทั่วไปสำหรับ FBE เมื่อ ไม่ได้ ใช้คีย์ที่รวมด้วยฮาร์ดแวร์

คีย์คลาส FBE คือคีย์การเข้ารหัสแบบดิบที่ Android ส่งไปยังเคอร์เนล Linux เพื่อปลดล็อกชุดไดเรกทอรีที่เข้ารหัสไว้ เช่น พื้นที่เก็บข้อมูลที่เข้ารหัสด้วยข้อมูลเข้าสู่ระบบสำหรับผู้ใช้ Android รายใดรายหนึ่ง (ในเคอร์เนล คีย์นี้เรียกว่า คีย์หลัก fscrypt) เคอร์เนลจะสร้างคีย์ย่อยต่อไปนี้จากคีย์นี้

• ตัวระบุคีย์ คีย์นี้ไม่ได้ใช้สำหรับการเข้ารหัส แต่เป็นค่า ที่ใช้ระบุคีย์ที่ใช้ปกป้องไฟล์หรือไดเรกทอรีหนึ่งๆ
• คีย์การเข้ารหัสเนื้อหาไฟล์
• คีย์การเข้ารหัสชื่อไฟล์

ในทางตรงกันข้าม แผนภาพต่อไปนี้แสดงลำดับชั้นของคีย์สำหรับ FBE เมื่อมีการใช้คีย์ที่รวมด้วยฮาร์ดแวร์

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

• อินเทอร์เฟซหนึ่งรายการเพื่อสร้าง inline_encryption_key และตั้งโปรแกรมลงในช่องคีย์ของเครื่องมือเข้ารหัสแบบอินไลน์โดยตรง ซึ่งช่วยให้เข้ารหัส/ถอดรหัสเนื้อหาไฟล์ ได้โดยไม่ต้องให้ซอฟต์แวร์เข้าถึงคีย์แบบดิบ ในเคอร์เนลทั่วไปของ Android อินเทอร์เฟซนี้สอดคล้องกับการดำเนินการ blk_crypto_ll_ops::keyslot_program ซึ่งต้อง ดำเนินการโดยไดรเวอร์พื้นที่เก็บข้อมูล
• อินเทอร์เฟซหนึ่งรายการเพื่อสร้างและส่งคืน sw_secret ("ความลับของซอฟต์แวร์" -- ก่อนหน้านี้เรียกว่า "ความลับแบบดิบ") ซึ่งเป็นคีย์ที่ Linux ใช้เพื่อสร้างคีย์ย่อยสำหรับการเข้ารหัสทุกอย่างนอกเหนือจากการเข้ารหัสเนื้อหาไฟล์ ในเคอร์เนลทั่วไปของ Android อินเทอร์เฟซนี้สอดคล้องกับการดำเนินการ blk_crypto_ll_ops::derive_sw_secret ซึ่งต้อง ดำเนินการโดยไดรเวอร์พื้นที่เก็บข้อมูล

ฮาร์ดแวร์ต้องใช้ KDF ที่เข้ารหัสลับอย่างรัดกุมเพื่อสร้าง inline_encryption_key และ sw_secret จากคีย์พื้นที่เก็บข้อมูลแบบดิบ KDF นี้ต้องเป็นไปตามแนวทางปฏิบัติแนะนำด้านการเข้ารหัสลับ โดยต้องมีความปลอดภัยอย่างน้อย 256 บิต ซึ่งเพียงพอสำหรับอัลกอริทึมที่จะใช้ในภายหลัง นอกจากนี้ KDF ยังต้องใช้ป้ายกำกับและบริบทที่แตกต่างกันเมื่อสร้างคีย์ย่อยแต่ละประเภทเพื่อให้แน่ใจว่าคีย์ย่อยที่ได้จะแยกกันด้วยการเข้ารหัสลับ นั่นคือ การรู้คีย์ย่อยรายการหนึ่งจะไม่เปิดเผยคีย์ย่อยรายการอื่นๆ ไม่จำเป็นต้องใช้การยืดคีย์เนื่องจากคีย์พื้นที่เก็บข้อมูลแบบดิบเป็นคีย์แบบสุ่มที่สม่ำเสมออยู่แล้ว

ในทางเทคนิคแล้ว คุณสามารถใช้ KDF ใดก็ได้ที่ตรงตามข้อกำหนดด้านความปลอดภัย อย่างไรก็ตาม เพื่อวัตถุประสงค์ในการทดสอบ vts_kernel_encryption_test ใช้ KDF เดียวกันในซอฟต์แวร์เพื่อสร้างข้อความเข้ารหัสบนดิสก์ซ้ำ และยืนยันว่าข้อความนั้นถูกต้อง เราขอแนะนำให้ฮาร์ดแวร์ใช้ KDF เริ่มต้นที่การทดสอบตรวจสอบ เพื่อให้ทดสอบได้ง่ายและมั่นใจว่ามีการใช้ KDF ที่ปลอดภัยและผ่านการตรวจสอบแล้ว สำหรับฮาร์ดแวร์ที่ใช้ KDF อื่น โปรดดู ทดสอบคีย์ที่รวม เพื่อดูวิธีกำหนดค่าการทดสอบ ตามนั้น

การรวมคีย์

ระบบได้กำหนดการรวมคีย์ไว้ 2 ประเภทเพื่อให้เป็นไปตามเป้าหมายด้านความปลอดภัยของคีย์ที่รวมด้วยฮาร์ดแวร์

• การรวมแบบชั่วคราว: ฮาร์ดแวร์จะเข้ารหัสคีย์แบบดิบโดยใช้คีย์ ที่สร้างขึ้นแบบสุ่มทุกครั้งที่บูตและไม่ได้เปิดเผย ภายนอกฮาร์ดแวร์โดยตรง
• การรวมระยะยาว: ฮาร์ดแวร์จะเข้ารหัสคีย์แบบดิบโดยใช้คีย์ที่ไม่ซ้ำกันและถาวรซึ่งสร้างขึ้นในฮาร์ดแวร์และไม่ได้เปิดเผยภายนอกฮาร์ดแวร์โดยตรง

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

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

ฮาร์ดแวร์ต้องใช้ 2 อินเทอร์เฟซต่อไปนี้เพื่อรองรับการจัดการคีย์ที่รวมด้วยวิธีที่แตกต่างกัน 2 วิธีนี้

• อินเทอร์เฟซเพื่อสร้างและนำเข้าคีย์พื้นที่เก็บข้อมูล โดยส่งคืนคีย์ใน รูปแบบที่รวมระยะยาว vold ใช้**อินเทอร์เฟซการสร้าง** เพื่อสร้างคีย์พื้นที่เก็บข้อมูลใหม่สำหรับ Android อินเทอร์เฟซการนำเข้าถูกใช้โดย vts_kernel_encryption_test เพื่อนำเข้าคีย์ทดสอบ
• อินเทอร์เฟซเพื่อแปลงคีย์พื้นที่เก็บข้อมูลที่รวมระยะยาวเป็นคีย์พื้นที่เก็บข้อมูลที่รวมแบบชั่วคราว ทั้ง vold และ vts_kernel_encryption_test ใช้ทั้งอินเทอร์เฟซนี้เพื่อปลดล็อกพื้นที่เก็บข้อมูล

อัลกอริทึมการรวมคีย์เป็นรายละเอียดการใช้งาน แต่ควรใช้ AEAD ที่รัดกุม เช่น AES-256-GCM ที่มี IV แบบสุ่ม

การเปลี่ยนแปลงซอฟต์แวร์ที่จำเป็น

AOSP มีเฟรมเวิร์กพื้นฐานสำหรับการรองรับคีย์ที่รวมด้วยฮาร์ดแวร์อยู่แล้ว ซึ่ง รวมถึงการรองรับในคอมโพเนนต์พื้นที่ผู้ใช้ เช่น vold รวมถึง การรองรับเคอร์เนล Linux ใน blk-crypto, fscrypt และ dm-default-key

การเปลี่ยนแปลงเคอร์เนล Linux

คุณต้องแก้ไขไดรเวอร์เคอร์เนล Linux สำหรับตัวควบคุมพื้นที่เก็บข้อมูลของอุปกรณ์ที่รองรับการเข้ารหัสแบบอินไลน์เพื่อให้รองรับคีย์ที่รวมด้วยฮาร์ดแวร์

สำหรับเคอร์เนล android17 ขึ้นไป

• ตั้งค่า BLK_CRYPTO_KEY_TYPE_HW_WRAPPED ใน blk_crypto_profile::key_types_supported
• ทำให้ blk_crypto_ll_ops::keyslot_program รองรับการตั้งโปรแกรม คีย์ที่รวมด้วยฮาร์ดแวร์
• ทำให้ blk_crypto_ll_ops::keyslot_evict รองรับการนำคีย์ที่รวมด้วยฮาร์ดแวร์ออก
• ใช้ blk_crypto_ll_ops::derive_sw_secret, blk_crypto_ll_ops::import_key และ blk_crypto_ll_ops::generate_keyblk_crypto_ll_ops::prepare_key

สำหรับเคอร์เนล android14, android15 และ android16

• ตั้งค่า BLK_CRYPTO_KEY_TYPE_HW_WRAPPED ใน blk_crypto_profile::key_types_supported
• ทำให้ blk_crypto_ll_ops::keyslot_program รองรับการตั้งโปรแกรม คีย์ที่รวมด้วยฮาร์ดแวร์
• ทำให้ blk_crypto_ll_ops::keyslot_evict รองรับการนำคีย์ที่รวมด้วยฮาร์ดแวร์ออก
• ใช้ blk_crypto_ll_ops::derive_sw_secret

สำหรับเคอร์เนล android12 และ android13

• ตั้งค่า BLK_CRYPTO_FEATURE_WRAPPED_KEYS ใน blk_keyslot_manager::features
• ทำให้ blk_ksm_ll_ops::keyslot_program รองรับการตั้งโปรแกรม คีย์ที่รวมด้วยฮาร์ดแวร์
• ทำให้ blk_ksm_ll_ops::keyslot_evict รองรับการนำคีย์ที่รวมด้วยฮาร์ดแวร์ออก
• ใช้ blk_ksm_ll_ops::derive_raw_secret

สำหรับเคอร์เนล android11

• ตั้งค่า BLK_CRYPTO_FEATURE_WRAPPED_KEYS ใน keyslot_manager::features
• ทำให้ keyslot_mgmt_ll_ops::keyslot_program รองรับการตั้งโปรแกรม คีย์ที่รวมด้วยฮาร์ดแวร์
• ทำให้ keyslot_mgmt_ll_ops::keyslot_evict รองรับการนำคีย์ที่รวมด้วยฮาร์ดแวร์ออก
• ใช้ keyslot_mgmt_ll_ops::derive_raw_secret

การเปลี่ยนแปลง KeyMint (เดิม)

ในคีย์ที่รวมด้วยฮาร์ดแวร์ (wrappedkey) เวอร์ชันปัจจุบัน การสร้าง การนำเข้า และการเตรียมคีย์ที่รวมด้วยฮาร์ดแวร์จะใช้ ioctl ของเคอร์เนล Linux BLKCRYPTOGENERATEKEY, BLKCRYPTOIMPORTKEY และ BLKCRYPTOPREPAREKEY ioctl เหล่านี้สอดคล้องกับเมธอดใน struct blk_crypto_ll_ops ไดรเวอร์พื้นที่เก็บข้อมูลจะใช้เมธอดเหล่านี้และสื่อสารกับฮาร์ดแวร์การรวมคีย์เพื่อดำเนินการตามที่ขอ ดูข้อมูลเพิ่มเติมเกี่ยวกับ ioctl เหล่านี้ได้ใน เอกสารประกอบเคอร์เนล Linux

ioctl เหล่านี้ได้รับการเพิ่มใน Linux 6.16 ในอุปกรณ์ที่ไม่ได้เปิดตัวด้วยโซลูชันที่ใช้ ioctl ระบบจะใช้โซลูชันอื่นที่ใช้ Android KeyMint (หรือ KeyMaster ก่อนหน้านี้) โซลูชันเดิม (wrappedkey_v0) ไม่สามารถใช้งานร่วมกับเคอร์เนล Linux หลักหรือโซลูชันปัจจุบัน โซลูชันเดิมใช้ฟังก์ชันการทำงาน KeyMint ต่อไปนี้

• การรองรับ TAG_STORAGE_KEY ทั้งสำหรับการสร้างและการนำเข้าคีย์
• การรองรับเมธอด convertStorageKeyToEphemeral

ฟังก์ชันการทำงาน KeyMint นี้จำเป็นเฉพาะในอุปกรณ์ที่ใช้โซลูชันเดิม ซึ่งสอดคล้องกับ wrappedkey_v0 ในไฟล์ fstab

อุปกรณ์ที่ใช้โซลูชันปัจจุบัน ซึ่งสอดคล้องกับ wrappedkey ในไฟล์ fstab ไม่จำเป็นต้องใช้ฟังก์ชันการทำงาน KeyMint นี้

ทดสอบคีย์ที่รวม

แม้ว่าการเข้ารหัสด้วยคีย์ที่รวมด้วยฮาร์ดแวร์จะทดสอบได้ยากกว่าการเข้ารหัสด้วยคีย์แบบดิบ แต่ก็ยังสามารถทดสอบได้โดยการนำเข้าคีย์ทดสอบและใช้การสร้างคีย์ซ้ำที่ฮาร์ดแวร์ใช้ ได้ใช้การดำเนินการนี้แล้ว ใน vts_kernel_encryption_test หากต้องการเรียกใช้การทดสอบนี้ ให้เรียกใช้คำสั่งต่อไปนี้

atest -v vts_kernel_encryption_test

อ่านบันทึกการทดสอบและตรวจสอบว่าระบบไม่ได้ข้ามกรณีทดสอบคีย์ที่รวมด้วยฮาร์ดแวร์ (เช่น FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy และ DmDefaultKeyTest.TestHwWrappedKey) เนื่องจากตรวจไม่พบการรองรับคีย์ที่รวมด้วยฮาร์ดแวร์ เนื่องจากในกรณีนั้นผลการทดสอบจะยังคงเป็น "ผ่าน"

โดยค่าเริ่มต้น vts_kernel_encryption_test จะถือว่าฮาร์ดแวร์ใช้ KDF ที่เรียกว่า kdf1 KDF นี้อยู่ในตระกูล KDF โหมดตัวนับจาก NIST SP 800-108 และใช้ AES-256-CMAC เป็นฟังก์ชันแบบสุ่มเทียม ดูข้อมูลเพิ่มเติมเกี่ยวกับ CMAC ได้ในข้อกำหนด CMAC KDF จะใช้บริบทและป้ายกำกับที่เฉพาะเจาะจงเมื่อสร้างคีย์ย่อยแต่ละรายการ ฮาร์ดแวร์ควรใช้ KDF นี้ รวมถึงการเลือกบริบท ป้ายกำกับ และการจัดรูปแบบสตริงอินพุตแบบคงที่ที่แน่นอนเมื่อสร้างคีย์ย่อยแต่ละรายการ

อย่างไรก็ตาม vts_kernel_encryption_test ยังใช้ KDF เพิ่มเติม kdf2 ถึง kdf4 ด้วย KDF เหล่านี้มีความปลอดภัยเท่ากับ kdf1 และแตกต่างกันเฉพาะในการเลือกบริบท ป้ายกำกับ และการจัดรูปแบบสตริงอินพุตแบบคงที่ KDF เหล่านี้มีไว้เพื่อรองรับฮาร์ดแวร์ที่แตกต่างกัน

สำหรับอุปกรณ์ที่ใช้ KDF อื่น ให้ตั้งค่าพร็อพเพอร์ตี้ระบบ ro.crypto.hw_wrapped_keys.kdf ใน PRODUCT_VENDOR_PROPERTIES เป็นชื่อของ KDF ตามที่กำหนดไว้ในซอร์สโค้ดการทดสอบ ซึ่งจะทำให้ vts_kernel_encryption_test ตรวจสอบ KDF นั้นแทนที่จะเป็น kdf1 เช่น หากต้องการเลือก kdf2 ให้ใช้คำสั่งต่อไปนี้

PRODUCT_VENDOR_PROPERTIES += ro.crypto.hw_wrapped_keys.kdf=kdf2

สำหรับอุปกรณ์ที่ใช้ KDF ที่การทดสอบไม่รองรับ ให้เพิ่มการใช้งาน KDF นั้นลงในการทดสอบและตั้งชื่อที่ไม่ซ้ำกัน

เปิดใช้คีย์ที่รวม

เมื่อการรองรับคีย์ที่รวมด้วยฮาร์ดแวร์ของอุปกรณ์ทำงานอย่างถูกต้อง ให้ทำการเปลี่ยนแปลงต่อไปนี้ในไฟล์ fstab ของอุปกรณ์เพื่อให้ Android ใช้คีย์ดังกล่าวสำหรับการเข้ารหัส FBE และข้อมูลเมตา

• FBE: เพิ่มแฟล็ก wrappedkey (หรือ wrappedkey_v0 สำหรับเวอร์ชันเดิม) ลงในพารามิเตอร์ fileencryption เช่น ใช้ fileencryption=::inlinecrypt_optimized+wrappedkey. ดูรายละเอียดเพิ่มเติมได้ในเอกสารประกอบ FBE
• การเข้ารหัสข้อมูลเมตา: เพิ่มแฟล็ก wrappedkey (หรือ wrappedkey_v0 สำหรับเวอร์ชันเดิม) ลงใน metadata_encryption พารามิเตอร์ เช่น ใช้ metadata_encryption=:wrappedkey ดูรายละเอียดเพิ่มเติมได้ใน เอกสารประกอบการเข้ารหัสข้อมูลเมตา

ในแต่ละกรณีจะมีแฟล็ก 2 เวอร์ชัน

• wrappedkey ซึ่ง Android 17 ขึ้นไปรองรับ จะเปิดใช้คีย์ที่รวมด้วยฮาร์ดแวร์เวอร์ชันปัจจุบัน เวอร์ชันนี้สามารถใช้งานร่วมกับเคอร์เนล Linux หลักได้
• wrappedkey_v0 ซึ่ง Android 11 ขึ้นไปรองรับ จะเปิดใช้ คีย์ที่รวมด้วยฮาร์ดแวร์เวอร์ชันเดิม เวอร์ชันนี้ไม่สามารถใช้งานร่วมกับเคอร์เนล Linux หลักได้ โดยจะพร็อกซีการดำเนินการบางอย่างผ่าน KeyMint และใช้รูปแบบที่ไม่เป็นมาตรฐานในดิสก์ ดูข้อมูลเพิ่มเติมได้ที่ การเปลี่ยนแปลง KeyMint (เดิม).

ในอุปกรณ์ที่เปิดตัวด้วย Android 17 ขึ้นไป ให้ใช้ wrappedkey

ในอุปกรณ์ที่เปิดตัวด้วย wrappedkey_v0 แล้ว ให้ใช้ wrappedkey_v0 ต่อไปเพื่อความเข้ากันได้แบบย้อนกลับ