การเข้ารหัสตามไฟล์

Android 7.0 ขึ้นไปรองรับการเข้ารหัสตามไฟล์ (FBE) การเข้ารหัสตามไฟล์ช่วยให้เข้ารหัสไฟล์ต่างๆ ด้วยคีย์ต่างๆ ที่ปลดล็อกแยกต่างหากได้

บทความนี้อธิบายวิธีเปิดใช้การเข้ารหัสตามไฟล์ในอุปกรณ์ใหม่และวิธีที่แอประบบสามารถใช้ Direct Boot API เพื่อมอบประสบการณ์การใช้งานที่ดีที่สุดและปลอดภัยที่สุดแก่ผู้ใช้

อุปกรณ์ทั้งหมดที่เปิดตัวด้วย Android 10 ขึ้นไปจะต้องใช้การเข้ารหัสตามไฟล์

Direct Boot

การเข้ารหัสตามไฟล์จะเปิดใช้ฟีเจอร์ใหม่ที่เปิดตัวใน Android 7.0 ที่เรียกว่า Direct Boot การบูตโดยตรงช่วยให้อุปกรณ์ที่เข้ารหัสบูตไปยังหน้าจอล็อกได้โดยตรง ก่อนหน้านี้ในอุปกรณ์ที่เข้ารหัสโดยใช้ Full-disk encryption (FDE) ผู้ใช้ต้องระบุข้อมูลเข้าสู่ระบบก่อนที่จะเข้าถึงข้อมูลได้ ซึ่งทำให้โทรศัพท์ทำงานโดยใช้ฟังก์ชันพื้นฐานทั้งหมดยกเว้นขั้นพื้นฐานได้ ตัวอย่างเช่น นาฬิกาปลุกไม่ทำงาน บริการการช่วยเหลือพิเศษไม่พร้อมใช้งาน และโทรศัพท์ก็รับสายไม่ได้ แต่ก็จำกัดให้ใช้เพียงแป้นโทรศัพท์ฉุกเฉินพื้นฐานเท่านั้น

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

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

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

การแยกนี้ช่วยให้โปรไฟล์งานปลอดภัยยิ่งขึ้น เนื่องจากจะทําให้มีการปกป้องผู้ใช้มากกว่า 1 รายในเวลาเดียวกัน เนื่องจากการเข้ารหัสไม่ได้อิงตามรหัสผ่านเมื่อเปิดเปิดเครื่องเพียงอย่างเดียวอีกต่อไป

Direct Boot API อนุญาตให้แอปที่รองรับการเข้ารหัสเข้าถึงแต่ละพื้นที่เหล่านี้ได้ การเปลี่ยนแปลงที่เกิดขึ้นกับวงจรของแอปมีไว้เพื่อรองรับความจำเป็นในการแจ้งให้แอปทราบเมื่อมีการปลดล็อกพื้นที่เก็บข้อมูล CE ของผู้ใช้เพื่อตอบสนองต่อการป้อนข้อมูลเข้าสู่ระบบครั้งแรกที่หน้าจอล็อก หรือในกรณีที่เป็นโปรไฟล์งาน ให้ระบุคำถามเพื่อยืนยัน อุปกรณ์ที่ใช้ Android 7.0 ต้องรองรับ API และวงจรใหม่เหล่านี้ ไม่ว่าจะใช้ FBE หรือไม่ก็ตาม อย่างไรก็ตาม หากไม่มี FBE พื้นที่เก็บข้อมูล DE และ CE จะอยู่ในสถานะ "ปลดล็อก" เสมอ

การใช้งานการเข้ารหัสตามไฟล์ในระบบไฟล์ Ext4 และ F2FS ทั้งหมดมีอยู่ในโปรเจ็กต์โอเพนซอร์ส Android (AOSP) และจำเป็นต้องเปิดใช้เฉพาะในอุปกรณ์ที่มีคุณสมบัติตรงตามข้อกำหนดเท่านั้น ผู้ผลิตที่เลือกใช้ FBE จะสำรวจวิธีต่างๆ ในการเพิ่มประสิทธิภาพฟีเจอร์โดยอิงตามระบบวงจรรวมบนชิป (SoC) ที่ใช้

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

  • บริการโทรศัพท์และเครื่องมือโทร
  • วิธีการป้อนรหัสผ่านในหน้าจอล็อก

ตัวอย่างและแหล่งที่มา

Android รองรับการใช้งานข้อมูลอ้างอิงของการเข้ารหัสตามไฟล์ ซึ่ง Vold (ระบบ/ไฟล์ Vold) มีฟังก์ชันสำหรับการจัดการอุปกรณ์จัดเก็บข้อมูลและวอลุ่มบน Android การเพิ่ม FBE ทำให้เกิดคำสั่งใหม่หลายรายการเพื่อรองรับการจัดการคีย์สำหรับคีย์ CE และ DE ของผู้ใช้หลายคน นอกจากการเปลี่ยนแปลงหลักๆ ในการใช้ความสามารถในการเข้ารหัสตามไฟล์ในเคอร์เนลแล้ว ยังมีการแก้ไขแพ็กเกจระบบจำนวนมากรวมถึงหน้าจอล็อกและ SystemUI ด้วย ให้รองรับฟีเจอร์ FBE และ Direct Boot ซึ่งรวมถึงฟีเจอร์ต่อไปนี้

  • แป้นโทรศัพท์ AOSP (แพ็กเกจ/แอป/โปรแกรมโทรออก)
  • นาฬิกาตั้งโต๊ะ (แพ็กเกจ/แอป/DeskClock)
  • ละติน (แพ็กเกจ/วิธีการป้อนข้อมูล/ละติน)*
  • แอปการตั้งค่า (แพ็กเกจ/แอป/การตั้งค่า)*
  • SystemUI (frameworks/base/packages/SystemUI)*

* แอประบบที่ใช้defaultToDeviceProtectedStorage แอตทริบิวต์ไฟล์ Manifest

ดูตัวอย่างแอปและบริการอื่นๆ ที่รองรับการเข้ารหัสได้ด้วยการเรียกใช้คําสั่ง mangrep directBootAware ในไดเรกทอรีเฟรมเวิร์กหรือแพ็กเกจของซอร์สโค้ด AOSP

การขึ้นต่อกัน

หากต้องการใช้ FBE ใน AOSP อย่างปลอดภัย อุปกรณ์ต้องมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้

  • การรองรับเคอร์เนลสำหรับการเข้ารหัส Ext4 หรือการเข้ารหัส F2FS
  • Keymaster รองรับ HAL เวอร์ชัน 1.0 ขึ้นไป เราไม่รองรับ Keymaster 0.3 เนื่องจากไม่มีความสามารถที่จำเป็นหรือรับประกันการป้องกันที่เพียงพอสำหรับคีย์การเข้ารหัส
  • Keymaster/Keystore และ Gatekeeper ต้องติดตั้งใช้งานในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) เพื่อให้การป้องกันคีย์ DE เพื่อไม่ให้ระบบปฏิบัติการที่ไม่ได้รับอนุญาต (ระบบปฏิบัติการที่กำหนดเองซึ่งแฟลชลงในอุปกรณ์) ขอคีย์ DE ได้
  • ต้องมีรูทของความน่าเชื่อถือของฮาร์ดแวร์และการเปิดเครื่องที่ได้รับการยืนยันที่เชื่อมโยงกับการเริ่มต้นใช้งาน Keymaster เพื่อให้มั่นใจว่าระบบปฏิบัติการที่ไม่ได้รับอนุญาตจะเข้าถึงคีย์ DE ไม่ได้

การใช้งาน

อย่างแรกและสำคัญที่สุด แอปต่างๆ เช่น นาฬิกาปลุก โทรศัพท์ และฟีเจอร์การเข้าถึง ควรเป็น android:directBootAware ตามเอกสารสำหรับนักพัฒนาซอฟต์แวร์ Direct Boot

การรองรับเคอร์เนล

การรองรับการเข้ารหัส Ext4 และ F2FS ของเคิร์กัลมีอยู่ในเคอร์เนลทั่วไปของ Android เวอร์ชัน 3.18 ขึ้นไป หากต้องการเปิดใช้ในเคอร์เนลเวอร์ชัน 5.1 ขึ้นไป ให้ใช้ 

CONFIG_FS_ENCRYPTION=y

สำหรับเคอร์เนลรุ่นเก่า ให้ใช้ CONFIG_EXT4_ENCRYPTION=y หากระบบไฟล์ userdata ของอุปกรณ์คือ Ext4 หรือใช้ CONFIG_F2FS_FS_ENCRYPTION=y หากระบบไฟล์ userdata ของอุปกรณ์คือ F2FS

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

นอกเหนือจากการรองรับฟังก์ชันการทำงานสำหรับการเข้ารหัส Ext4 หรือ F2FS แล้ว ผู้ผลิตอุปกรณ์ควรเปิดใช้การเร่งการเข้ารหัสเพื่อเพิ่มความเร็วในการเข้ารหัสตามไฟล์และปรับปรุงประสบการณ์ของผู้ใช้ด้วย ตัวอย่างเช่น ในอุปกรณ์ที่ใช้ ARM64 คุณจะเปิดใช้การเร่งความเร็ว ARMv8 CE (Cryptography Extensions) ได้โดยการกําหนดตัวเลือกการกําหนดค่าเคอร์เนลต่อไปนี้ 

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

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

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

เปิดใช้การเข้ารหัสตามไฟล์

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

ที่เก็บข้อมูลภายใน

FBE เปิดใช้อยู่โดยการเพิ่มตัวเลือก fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] ลงในคอลัมน์ fs_mgr_flags ของบรรทัด fstab สำหรับ userdata ตัวเลือกนี้จะกำหนดรูปแบบการเข้ารหัสในที่จัดเก็บข้อมูลภายใน ซึ่งมีพารามิเตอร์ที่คั่นด้วยโคลอนได้สูงสุด 3 รายการ ได้แก่

  • พารามิเตอร์ contents_encryption_mode กำหนดว่าจะใช้อัลกอริทึมการเข้ารหัสใดเพื่อเข้ารหัสเนื้อหาไฟล์ โดยอาจเป็น aes-256-xts หรือ adiantum ตั้งแต่ Android 11 เป็นต้นไป คุณจะปล่อยค่านี้ว่างไว้เพื่อระบุอัลกอริทึมเริ่มต้นซึ่งก็คือ aes-256-xts ก็ได้
  • พารามิเตอร์ filenames_encryption_mode จะระบุอัลกอริทึมการเข้ารหัสที่จะใช้ในการเข้ารหัสชื่อไฟล์ โดยอาจเป็น aes-256-cts, aes-256-heh, adiantum หรือ aes-256-hctr2 หากไม่ได้ระบุ ค่าเริ่มต้นจะเป็น aes-256-cts หาก contents_encryption_mode เป็น aes-256-xts หรือ adiantum หาก contents_encryption_mode เป็น adiantum
  • พารามิเตอร์ flags ซึ่งเป็นรายการใหม่ใน Android 11 เป็นรายการแฟล็กที่คั่นด้วยอักขระ + ระบบรองรับ Flag ต่อไปนี้
    • Flag v1 จะเลือกนโยบายการเข้ารหัสเวอร์ชัน 1 ส่วน Flag v2 จะเลือกนโยบายการเข้ารหัสเวอร์ชัน 2 นโยบายการเข้ารหัสเวอร์ชัน 2 ใช้ฟังก์ชันการสร้างคีย์ที่ปลอดภัยและยืดหยุ่นมากขึ้น ค่าเริ่มต้นคือ v2 หากอุปกรณ์เปิดตัวใน Android 11 ขึ้นไป (ตามที่ ro.product.first_api_level กำหนด) หรือ v1 หากอุปกรณ์เปิดตัวใน Android 10 หรือต่ำกว่า
    • Flag inlinecrypt_optimized จะเลือกรูปแบบการเข้ารหัสที่เพิ่มประสิทธิภาพสำหรับฮาร์ดแวร์การเข้ารหัสในบรรทัดที่ไม่จัดการคีย์จํานวนมากได้อย่างมีประสิทธิภาพ โดยดึงข้อมูลคีย์การเข้ารหัสเนื้อหาไฟล์เพียง 1 คีย์ต่อคีย์ CE หรือ DE แทนที่จะใช้ 1 คีย์ต่อไฟล์ ระบบจะปรับการสร้าง IV (เวกเตอร์การเริ่มต้น) ให้เหมาะสม
    • Flag emmc_optimized คล้ายกับ inlinecrypt_optimized แต่ก็เลือกวิธีการสร้าง IV ที่จำกัด IV ไว้ที่ 32 บิตเช่นกัน แฟล็กนี้ควรใช้เฉพาะกับฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ที่เป็นไปตามข้อกำหนดจำเพาะของ JEDEC eMMC v5.2 และรองรับ IV แบบ 32 บิตเท่านั้น ในฮาร์ดแวร์การเข้ารหัสในบรรทัดอื่นๆ ให้ใช้ inlinecrypt_optimized แทน ไม่ควรใช้ Flag นี้กับพื้นที่เก็บข้อมูลแบบ UFS เนื่องจากข้อกำหนด UFS อนุญาตให้ใช้ IV แบบ 64 บิต
    • ในอุปกรณ์ที่รองรับคีย์ที่รวมไว้ในฮาร์ดแวร์ แฟล็ก wrappedkey_v0 จะเปิดใช้คีย์ที่รวมไว้ในฮาร์ดแวร์สำหรับ FBE ตัวเลือกนี้ใช้ได้กับตัวเลือกการต่อเชื่อม inlinecrypt และแฟล็ก inlinecrypt_optimized หรือ emmc_optimized เท่านั้น
    • Flag dusize_4k จะบังคับให้ขนาดหน่วยข้อมูลการเข้ารหัสเป็น 4096 ไบต์ แม้ว่าขนาดบล็อกของระบบไฟล์จะไม่ใช่ 4096 ไบต์ก็ตาม ขนาดหน่วยข้อมูลการเข้ารหัสคือความละเอียดของการเข้ารหัสเนื้อหาไฟล์ แฟล็กนี้พร้อมใช้งานใน Android 15 ควรใช้แฟล็กนี้เพื่อเปิดใช้การใช้ฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ที่ไม่รองรับหน่วยข้อมูลที่มีขนาดใหญ่กว่า 4,096 ไบต์ในอุปกรณ์ที่ใช้หน้าขนาดใหญ่กว่า 4,096 ไบต์และใช้ระบบไฟล์ f2fs เท่านั้น

หากคุณไม่ได้ใช้ฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ การตั้งค่าที่แนะนำสำหรับอุปกรณ์ส่วนใหญ่คือ fileencryption=aes-256-xts หากคุณใช้ฮาร์ดแวร์การเข้ารหัสในบรรทัด การตั้งค่าที่แนะนำสำหรับอุปกรณ์ส่วนใหญ่คือ fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (หรือเทียบเท่า fileencryption=::inlinecrypt_optimized) ในอุปกรณ์ที่ไม่มีการเพิ่มประสิทธิภาพ AES ในรูปแบบใดๆ คุณสามารถใช้ Adiantum แทน AES ได้โดยการตั้งค่า fileencryption=adiantum

ตั้งแต่ Android 14 เป็นต้นไป AES-HCTR2 เป็นโหมดการเข้ารหัสชื่อไฟล์ที่แนะนำสำหรับอุปกรณ์ที่มีคำสั่งการเข้ารหัสลับแบบเร่ง อย่างไรก็ตาม มีเพียงเคอร์เนล Android เวอร์ชันใหม่เท่านั้นที่รองรับ AES-HCTR2 ในรุ่น Android ในอนาคต เราวางแผนที่จะกำหนดให้การเข้ารหัสชื่อไฟล์เป็นโหมดเริ่มต้น หากเคอร์เนลรองรับ AES-HCTR2 คุณจะเปิดใช้การเข้ารหัสชื่อไฟล์ได้โดยการตั้งค่า filenames_encryption_mode เป็น aes-256-hctr2 ในกรณีแบบง่ายที่สุด fileencryption=aes-256-xts:aes-256-hctr2

ในอุปกรณ์ที่เปิดตัวด้วย Android 10 หรือต่ำกว่า ระบบจะยอมรับ fileencryption=ice ด้วยเพื่อระบุการใช้โหมดการเข้ารหัสเนื้อหาไฟล์ FSCRYPT_MODE_PRIVATE เคอร์เนลทั่วไปของ Android ไม่ได้ใช้โหมดนี้ แต่ผู้ให้บริการอาจใช้โหมดนี้ได้โดยใช้แพตช์เคอร์เนลที่กำหนดเอง รูปแบบบนดิสก์ที่โหมดนี้สร้างขึ้นเป็นแบบเฉพาะผู้ให้บริการ ในอุปกรณ์ที่ใช้ Android 11 ขึ้นไป ระบบจะไม่อนุญาตให้ใช้โหมดนี้อีกต่อไปและต้องใช้รูปแบบการเข้ารหัสมาตรฐานแทน

โดยค่าเริ่มต้น การเข้ารหัสเนื้อหาไฟล์จะดำเนินการโดยใช้ API การเข้ารหัสของเคอร์เนลของ Linux หากต้องการใช้ฮาร์ดแวร์การเข้ารหัสแบบอินไลน์แทน ให้เพิ่มตัวเลือกการต่อเชื่อม inlinecrypt ด้วย ตัวอย่างเช่น บรรทัด fstab แบบเต็มอาจมีลักษณะดังนี้ 

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

พื้นที่เก็บข้อมูลแบบ Adoptable

ตั้งแต่ Android 9 เป็นต้นไป คุณจะใช้ FBE และพื้นที่เก็บข้อมูลที่นำมาใช้ได้ร่วมกันได้

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

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

  • ro.crypto.volume.options (ใหม่ใน Android 11) เลือกรูปแบบการเข้ารหัส FBE ในที่จัดเก็บข้อมูลแบบ Adoptable โดยจะมีไวยากรณ์เหมือนกับอาร์กิวเมนต์ของตัวเลือก fileencryption fstab และใช้ค่าเริ่มต้นเดียวกัน ดูคำแนะนำสำหรับ fileencryption ด้านบนสำหรับการใช้ที่นี่
  • ro.crypto.volume.metadata.encryption จะเลือกรูปแบบการเข้ารหัสข้อมูลเมตาในพื้นที่เก็บข้อมูลแบบ Adable ดูเอกสารประกอบเกี่ยวกับการเข้ารหัสข้อมูลเมตา

ในอุปกรณ์ที่เปิดตัวด้วย Android 10 หรือต่ำกว่า ให้ใช้พร็อพเพอร์ตี้ต่อไปนี้

  • ro.crypto.volume.contents_mode เลือกโหมดการเข้ารหัสเนื้อหา ค่านี้เทียบเท่ากับช่องที่คั่นด้วยโคลอนแรกของ ro.crypto.volume.options
  • ro.crypto.volume.filenames_mode เลือกโหมดการเข้ารหัสชื่อไฟล์ ซึ่งเทียบเท่ากับช่องที่ 2 ที่คั่นด้วยโคลอนของ ro.crypto.volume.options ยกเว้นค่าเริ่มต้นในอุปกรณ์ที่เปิดตัวด้วย Android 10 หรือต่ำกว่าจะเป็น aes-256-heh ในอุปกรณ์ส่วนใหญ่ คุณต้องลบล้างค่านี้เป็น aes-256-cts อย่างชัดเจน
  • ro.crypto.fde_algorithm และ ro.crypto.fde_sector_size เลือกรูปแบบการเข้ารหัสข้อมูลเมตาในพื้นที่เก็บข้อมูลแบบ Adoptable ดูเอกสารประกอบเกี่ยวกับการเข้ารหัสข้อมูลเมตา

ผสานรวมกับ Keymaster

HAL ของ Keymaster ควรเริ่มต้นโดยเป็นส่วนหนึ่งของคลาส early_hal เนื่องจาก FBE กําหนดให้ Keymaster พร้อมที่จะจัดการคําขอในpost-fs-dataระยะการบูต ซึ่งเป็นเวลาที่ vold ตั้งค่าคีย์เริ่มต้น

ยกเว้นไดเรกทอรี

init ใช้คีย์ DE ของระบบกับไดเรกทอรีระดับบนสุดทั้งหมดของ /data ยกเว้นไดเรกทอรีที่ต้องไม่มีการเข้ารหัส เช่น ไดเรกทอรีที่มีคีย์ DE ของระบบและไดเรกทอรีที่มีไดเรกทอรี CE หรือ DE ของผู้ใช้ คีย์การเข้ารหัสจะมีผลซ้ำๆ และไดเรกทอรีย่อยจะลบล้างไม่ได้

ใน Android 11 ขึ้นไป คุณสามารถควบคุมคีย์ที่initใช้กับไดเรกทอรีได้ด้วยอาร์กิวเมนต์ encryption=<action> ของคำสั่ง mkdir ในสคริปต์ init ค่าที่เป็นไปได้ของ <action> มีการระบุไว้ในREADME สำหรับภาษา init ของ Android

ใน Android 10 การดำเนินการเข้ารหัส init ได้รับการฮาร์ดโค้ดไว้ในตำแหน่งต่อไปนี้ 

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

ใน Android 9 และเวอร์ชันก่อนหน้า ตำแหน่งคือ 

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

กรณีการใช้งานเดียวที่เรายอมรับได้คือการรองรับความสามารถ OTA แบบเดิม

รองรับ Direct Boot ในแอประบบ

ทำให้แอปรับรู้ Direct Boot

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

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

แอตทริบิวต์ directBootAware ที่ระดับแอปเป็นตัวย่อสำหรับการทําเครื่องหมายคอมโพเนนต์ทั้งหมดในแอปว่ารองรับการเข้ารหัส

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

เมื่อทํางานในโหมดนี้ API ของระบบต่อไปนี้จะพร้อมใช้งานเพื่อจัดการบริบทที่ระบบจัดเก็บข้อมูล CE สนับสนุนโดยเฉพาะเมื่อจําเป็น ซึ่งเทียบเท่ากับ API ของอุปกรณ์ที่ได้รับการปกป้อง

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

รองรับผู้ใช้หลายคน

ผู้ใช้แต่ละรายในสภาพแวดล้อมแบบผู้ใช้หลายคนจะได้รับคีย์การเข้ารหัสแยกกัน ผู้ใช้ทุกคนจะได้รับคีย์ 2 รายการ ได้แก่ คีย์ DE และคีย์ CE ผู้ใช้ 0 ต้องเข้าสู่ระบบอุปกรณ์ก่อนเนื่องจากเป็นผู้ใช้พิเศษ ซึ่งเกี่ยวข้องกับการใช้งานการดูแลระบบอุปกรณ์

แอปที่รับรู้ถึง Crypto จะโต้ตอบกับผู้ใช้ทั้งหมดในลักษณะนี้ INTERACT_ACROSS_USERS และ INTERACT_ACROSS_USERS_FULL อนุญาตให้แอปดำเนินการกับผู้ใช้ทั้งหมดในอุปกรณ์ อย่างไรก็ตาม แอปเหล่านั้นจะเข้าถึงได้เฉพาะไดเรกทอรีที่เข้ารหัสด้วย CE สำหรับผู้ใช้ที่ปลดล็อกแล้วเท่านั้น

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

รหัสผู้ใช้โปรไฟล์งานแต่ละรหัสจะมีคีย์ 2 รายการ ได้แก่ DE และ CE เมื่อทำภารกิจสำเร็จแล้ว ระบบจะปลดล็อกผู้ใช้โปรไฟล์และ Keymaster (ใน TEE) จะมอบคีย์ TEE ของโปรไฟล์

จัดการการอัปเดต

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

เมื่อใช้โซลูชัน OTA แบบเดิมซึ่งต้องมีการกู้คืนเพื่อเข้าถึงไฟล์ OTA ในพาร์ติชัน userdata ให้ทำดังนี้

  1. สร้างไดเรกทอรีระดับบนสุด (เช่น misc_ne) ในพาร์ติชัน userdata
  2. กำหนดค่าไดเรกทอรีระดับบนสุดนี้ให้เป็นไม่เข้ารหัส (ดูการยกเว้นไดเรกทอรี)
  3. สร้างไดเรกทอรีภายในไดเรกทอรีระดับบนสุดเพื่อเก็บแพ็กเกจ OTA
  4. เพิ่มกฎ SELinux และบริบทไฟล์เพื่อควบคุมการเข้าถึงไดเรกทอรีนี้และเนื้อหา เฉพาะกระบวนการหรือแอปที่ได้รับการอัปเดต OTA เท่านั้นที่ควรอ่านและเขียนลงในไดเรกทอรีนี้ได้ แอปหรือกระบวนการอื่นไม่ควรมีสิทธิ์เข้าถึงไดเรกทอรีนี้

การตรวจสอบความถูกต้อง

ก่อนอื่นให้เรียกใช้การทดสอบการเข้ารหัส CTS หลายรายการ เช่น DirectBootHostTest และ EncryptionTest เพื่อให้แน่ใจว่าฟีเจอร์เวอร์ชันที่ติดตั้งใช้งานทำงานได้ตามที่ต้องการ

หากอุปกรณ์ใช้ Android 11 ขึ้นไป ให้เรียกใช้ vts_kernel_encryption_test ด้วยดังนี้ 

atest vts_kernel_encryption_test

หรือ

vts-tradefed run vts -m vts_kernel_encryption_test

นอกจากนี้ ผู้ผลิตอุปกรณ์ยังทำการทดสอบด้วยตนเองต่อไปนี้ได้ ในอุปกรณ์ที่เปิดใช้ FBE

  • ตรวจสอบว่ามี ro.crypto.state อยู่
    • ตรวจสอบว่ามีการเข้ารหัส ro.crypto.state
  • ตรวจสอบว่ามี ro.crypto.type อยู่
    • ตรวจสอบว่าตั้งค่า ro.crypto.type เป็น file แล้ว

นอกจากนี้ ผู้ทดสอบยังตรวจสอบได้ว่าพื้นที่เก็บข้อมูล CE ล็อกอยู่ก่อนที่จะปลดล็อกอุปกรณ์เป็นครั้งแรกนับตั้งแต่เปิดเครื่อง หากต้องการดำเนินการดังกล่าว ให้ใช้บิลด์ userdebug หรือ eng ตั้งค่า PIN, รูปแบบ หรือรหัสผ่านกับผู้ใช้หลัก แล้วรีบูตอุปกรณ์ ก่อนปลดล็อกอุปกรณ์ ให้เรียกใช้คำสั่งต่อไปนี้เพื่อตรวจสอบพื้นที่เก็บข้อมูล CE ของผู้ใช้หลัก หากอุปกรณ์ใช้โหมดผู้ใช้ระบบแบบไม่มีส่วนหัว (อุปกรณ์ยานยนต์ส่วนใหญ่) ผู้ใช้หลักคือผู้ใช้ 10 ให้เรียกใช้คำสั่งต่อไปนี้ 

adb root; adb shell ls /data/user/10

ในอุปกรณ์อื่นๆ (อุปกรณ์ที่ไม่ใช่ยานยนต์ส่วนใหญ่) ผู้ใช้หลักคือผู้ใช้ 0 ดังนั้นเรียกใช้:

adb root; adb shell ls /data/user/0

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

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

รายละเอียดการใช้งาน AOSP

ส่วนนี้จะให้รายละเอียดเกี่ยวกับการใช้งาน AOSP และอธิบายวิธีการทำงานของการเข้ารหัสตามไฟล์ ผู้ผลิตอุปกรณ์ไม่จำเป็นต้องทำการเปลี่ยนแปลงใดๆ ที่นี่เพื่อใช้ FBE และ Direct Boot ในอุปกรณ์

การเข้ารหัส fscrypt

การใช้งาน AOSP ใช้การเข้ารหัส "fscrypt" (ext4 และ f2fs รองรับ) ในเคอร์เนล และมักจะได้รับการกําหนดค่าดังนี้

  • เข้ารหัสเนื้อหาไฟล์ด้วย AES-256 ในโหมด XTS
  • เข้ารหัสชื่อไฟล์ด้วย AES-256 ในโหมด CBC-CTS

นอกจากนี้ ยังรองรับการเข้ารหัส Adiantum ด้วย เมื่อเปิดใช้การเข้ารหัส Adiantum ทั้งเนื้อหาไฟล์และชื่อไฟล์จะได้รับการเข้ารหัสด้วย Adiantum

fscrypt รองรับนโยบายการเข้ารหัส 2 เวอร์ชัน ได้แก่ เวอร์ชัน 1 และ 2 เวอร์ชัน 1 เลิกใช้งานแล้วและข้อกำหนด CDD สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 11 ขึ้นไปจะเข้ากันได้กับเวอร์ชัน 2 เท่านั้น นโยบายการเข้ารหัสเวอร์ชัน 2 ใช้ HKDF-SHA512 เพื่อรับคีย์การเข้ารหัสจริงจากคีย์ที่ Userspace มีให้

ดูข้อมูลเพิ่มเติมเกี่ยวกับ fscrypt ได้ที่เอกสารประกอบเคอร์เนลต้นทาง

คลาสพื้นที่เก็บข้อมูล

ตารางต่อไปนี้แสดงคีย์ FBE และไดเรกทอรีที่ปกป้องโดยละเอียด

ประเภทพื้นที่เก็บข้อมูล คำอธิบาย ไดเรกทอรี
ไม่ได้เข้ารหัส ไดเรกทอรีใน /data ที่ไม่สามารถหรือไม่จำเป็นต้องได้รับการคุ้มครองโดย FBE ในอุปกรณ์ที่ใช้การเข้ารหัสข้อมูลเมตา ไดเรกทอรีเหล่านี้จะไม่มีการเข้ารหัสอย่างแท้จริง แต่จะได้รับการปกป้องด้วยคีย์การเข้ารหัสข้อมูลเมตาซึ่งเทียบเท่ากับ System DE
  • /data/apex ยกเว้น /data/apex/decompressed และ /data/apex/ota_reserved ซึ่งเป็น DE ของระบบ
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • ไดเรกทอรีทั้งหมดที่มีไดเรกทอรีย่อยใช้คีย์ FBE ที่แตกต่างกัน ตัวอย่างเช่น เนื่องจากไดเรกทอรี /data/user/${user_id} แต่ละรายการใช้คีย์ต่อผู้ใช้ /data/user จึงไม่ใช้คีย์ใดๆ
ระบบ DE ข้อมูลที่เข้ารหัสในอุปกรณ์ซึ่งไม่ได้เชื่อมโยงกับผู้ใช้ที่เฉพาะเจาะจง
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • ไดเรกทอรีย่อยอื่นๆ ทั้งหมดของ /data ที่ตารางนี้ไม่ได้กล่าวถึงการมีคลาสอื่น
ต่อการเปิดเครื่อง 1 ครั้ง ไฟล์ระบบชั่วคราวที่ไม่จําเป็นต้องอยู่รอดหลังจากการรีบูต /data/per_boot
CE ของผู้ใช้ (ภายใน) ข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบต่อผู้ใช้ในที่จัดเก็บข้อมูลภายใน
  • /data/data (ชื่อแทนของ /data/user/0)
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
ผู้ใช้ DE (ภายใน) ข้อมูลที่เข้ารหัสในอุปกรณ์ต่อผู้ใช้ในที่จัดเก็บข้อมูลภายใน
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
CE ของผู้ใช้ (นำไปใช้ได้) ข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบต่อผู้ใช้ในพื้นที่เก็บข้อมูลแบบ Adoptable
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
ผู้ใช้ DE (นำมาใช้ได้) ข้อมูลที่เข้ารหัสในอุปกรณ์ต่อผู้ใช้ในพื้นที่เก็บข้อมูลที่พร้อมใช้งาน
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

พื้นที่เก็บข้อมูลและการป้องกันคีย์

vold จะจัดการคีย์ FBE ทั้งหมดและจัดเก็บคีย์ที่เข้ารหัสไว้ในดิสก์ ยกเว้นคีย์ต่อบูตที่ไม่ได้จัดเก็บไว้เลย ตารางต่อไปนี้แสดงตำแหน่งที่เก็บคีย์ FBE ต่างๆ

ประเภทคีย์ ตำแหน่งของกุญแจ คลาสพื้นที่เก็บข้อมูลของตำแหน่งคีย์
คีย์ DE ของระบบ /data/unencrypted ไม่ได้เข้ารหัส
คีย์ CE (ภายใน) ของผู้ใช้ /data/misc/vold/user_keys/ce/${user_id} System DE
คีย์ DE (ภายใน) ของผู้ใช้ /data/misc/vold/user_keys/de/${user_id} System DE
คีย์ CE (นำมาใช้ได้) ของผู้ใช้ /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} CE ของผู้ใช้ (ภายใน)
คีย์ DE (นำไปใช้ได้) ของผู้ใช้ /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} ผู้ใช้ DE (ภายใน)

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

vold ยังใช้เลเยอร์การเข้ารหัสกับคีย์ FBE ทั้งหมดด้วย คีย์ทุกรายการนอกเหนือจากคีย์ CE สำหรับพื้นที่เก็บข้อมูลภายในได้รับการเข้ารหัสด้วย AES-256-GCM โดยใช้คีย์ Keystore ของตนเองที่ไม่ได้เปิดเผยภายนอก TEE วิธีนี้ช่วยให้มั่นใจว่าคีย์ FBE จะปลดล็อกไม่ได้เว้นแต่ระบบปฏิบัติการที่เชื่อถือได้จะมีการเปิดเครื่องตามที่บังคับใช้โดยการเปิดเครื่องที่ได้รับการยืนยัน ระบบจะขอการป้องกันการย้อนกลับในคีย์ของ Keystore ด้วย ซึ่งจะช่วยให้ลบคีย์ FBE ได้อย่างปลอดภัยในอุปกรณ์ที่ Keymaster รองรับการป้องกันการย้อนกลับ ระบบจะใช้แฮช SHA-512 ของไบต์แบบสุ่ม 16384 ไบต์ที่จัดเก็บไว้ในไฟล์ secdiscardable ที่เก็บไว้พร้อมกับคีย์เป็นแท็กรหัสแอปของคีย์ใน Keystore เป็นทางเลือกสำรองในกรณีที่การป้องกันการย้อนกลับไม่พร้อมใช้งาน คุณต้องกู้คืนไบต์ทั้งหมดเหล่านี้เพื่อกู้คืนคีย์ FBE

คีย์ CE สำหรับที่จัดเก็บข้อมูลภายในจะได้รับการป้องกันที่รัดกุมยิ่งขึ้นเพื่อให้แน่ใจว่าจะปลดล็อกไม่ได้หากไม่ทราบปัจจัยความรู้สำหรับหน้าจอล็อก (LSKF) (PIN, รูปแบบ หรือรหัสผ่าน), โทเค็นการรีเซ็ตรหัสผ่านที่ปลอดภัย หรือทั้งคีย์ฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์สำหรับการดำเนินการกลับมาทำงานอีกครั้งเมื่อรีบูต ระบบอนุญาตให้สร้างโทเค็นสำหรับรีเซ็ตรหัสผ่านสำหรับโปรไฟล์งานและอุปกรณ์ที่มีการจัดการครบวงจรเท่านั้น

vold จะเข้ารหัสคีย์ CE แต่ละรายการสำหรับพื้นที่เก็บข้อมูลภายในโดยใช้คีย์ AES-256-GCM ที่มาจากรหัสผ่านสังเคราะห์ของผู้ใช้ รหัสผ่านสังเคราะห์คือความลับการเข้ารหัสที่มีความผันผวนสูงซึ่งเปลี่ยนแปลงไม่ได้ซึ่งสร้างขึ้นแบบสุ่มสําหรับผู้ใช้แต่ละราย LockSettingsService ใน system_server จะจัดการรหัสผ่านที่สังเคราะห์และวิธีปกป้องรหัสผ่าน

หากต้องการปกป้องรหัสผ่านที่สังเคราะห์ด้วย LSKF LockSettingsService จะขยาย LSKF ก่อนโดยส่งผ่านผ่าน scrypt โดยกำหนดเวลาไว้ที่ประมาณ 25 มิลลิวินาทีและการใช้หน่วยความจำประมาณ 2 MiB เนื่องจากโดยปกติแล้ว LSKF จะมีความยาวไม่มาก ขั้นตอนนี้จึงมักไม่ค่อยมีความปลอดภัยมากนัก ชั้นความปลอดภัยหลักของความปลอดภัยคือองค์ประกอบความปลอดภัย (SE) หรือการจำกัดอัตราที่บังคับใช้ TEE ที่อธิบายไว้ด้านล่าง

หากอุปกรณ์มีองค์ประกอบความปลอดภัย (SE) LockSettingsService จะแมป LSKF แบบขยายกับข้อมูลลับแบบสุ่มที่มีเอนโทรปีสูงซึ่งจัดเก็บไว้ใน SE โดยใช้ Weaver HAL จากนั้น LockSettingsService จะเข้ารหัสรหัสผ่านสังเคราะห์ 2 ครั้ง ครั้งแรกคือคีย์ซอฟต์แวร์ที่ได้มาจาก LSKF และข้อมูลลับของ Weaver ที่ยืดออกไป และครั้งที่ 2 จะใช้คีย์ Keystore ที่ไม่ได้ผูกกับการตรวจสอบสิทธิ์ ซึ่งจะระบุการจำกัดอัตราการคาดเดาของ LSKF ที่บังคับใช้กับ SE

หากอุปกรณ์ไม่มี SE LockSettingsServiceจะใช้ LSKF ที่ขยายเป็นรหัสผ่าน Gatekeeper แทน LockSettingsService จากนั้นเข้ารหัสรหัสผ่านที่สังเคราะห์ขึ้น 2 ครั้ง โดยครั้งแรกจะใช้คีย์ซอฟต์แวร์ที่มาจาก LSKF ที่ขยายและแฮชของไฟล์ที่ทิ้งได้ และครั้งที่ 2 จะใช้คีย์คีย์สโตร์ที่เชื่อมโยงกับการรับรองให้กับการลงทะเบียน Gatekeeper ซึ่งจะจำกัดอัตราการเดา LSKF ที่ TEE บังคับใช้

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