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

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

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

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

ข้อควรระวัง: ใน Android 7.0-8.1 FBE ใช้ร่วมกับพื้นที่เก็บข้อมูลแบบนํามาใช้ได้และพื้นที่เก็บข้อมูลภายนอกไม่ได้ สื่อพื้นที่เก็บข้อมูล (เช่น การ์ด SD) สามารถใช้เป็นพื้นที่เก็บข้อมูลแบบดั้งเดิมเท่านั้น ใน Android 9 และสูงกว่า FBE สามารถใช้งานร่วมกับพื้นที่เก็บข้อมูลแบบ Adable ได้

Direct Boot

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

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

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

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

หมายเหตุ: หากเป็นไปได้ ไฟล์ควรอยู่ในพื้นที่เก็บข้อมูล CE

การแยกนี้จะทำให้โปรไฟล์งานปลอดภัยยิ่งขึ้น เนื่องจากช่วยให้มีมากกว่า 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 ทำให้เกิด vold พร้อมกับคำสั่งใหม่หลายรายการ เพื่อรองรับการจัดการคีย์สำหรับคีย์ CE และ DE ของผู้ใช้หลายคน นอกจากนี้ การเปลี่ยนแปลงหลักไปใช้ตามไฟล์ ความสามารถในการเข้ารหัสในเคอร์เนล แพ็กเกจระบบจำนวนมาก รวมถึง มีการแก้ไขหน้าจอล็อกและ SystemUI ให้รองรับ FBE และ Direct ฟีเจอร์เปิดเครื่อง ซึ่งได้แก่

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

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

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

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

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

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

การใช้งาน

สิ่งแรกและสำคัญที่สุดคือแอปต่างๆ เช่น นาฬิกาปลุก โทรศัพท์ และฟีเจอร์การช่วยเหลือพิเศษ ควรทำให้เป็น android:directBootAware ตาม 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

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

นอกจากการสนับสนุนการทำงานสำหรับการเข้ารหัส 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 โดยอัตโนมัติใน Adable พื้นที่เก็บข้อมูล; แต่อาจมีการลบล้างรูปแบบการเข้ารหัสในพื้นที่เก็บข้อมูลแบบปรับใช้ได้ หากจำเป็น

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

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, เป็นรายการแฟล็กที่คั่นด้วย + อักขระ ระบบรองรับแฟล็กต่อไปนี้
  • แฟล็ก v1 จะเลือกนโยบายการเข้ารหัสเวอร์ชัน 1 เวลา Flag v2 เลือกนโยบายการเข้ารหัสเวอร์ชัน 2 เวอร์ชัน นโยบายการเข้ารหัส 2 รายการจะใช้ฟังก์ชันการดึงคีย์ที่ปลอดภัยและยืดหยุ่นมากขึ้น ค่าเริ่มต้นคือ v2 หาก อุปกรณ์ที่เปิดตัวใน Android 11 ขึ้นไป (ตามที่กำหนดโดย ro.product.first_api_level) หรือ v1 หาก เปิดตัวอุปกรณ์บน Android 10 หรือ ด้านล่าง
  • แฟล็ก inlinecrypt_optimized จะเลือกการเข้ารหัส ที่เหมาะสำหรับฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ที่ไม่ จัดการกับแป้นจำนวนมากได้อย่างมีประสิทธิภาพ ซึ่งทำได้โดยการดึงข้อมูล คีย์การเข้ารหัสเนื้อหาไฟล์เพียง 1 คีย์ต่อคีย์ CE หรือ DE มากกว่า 1 รายการ 1 ครั้งต่อไฟล์ การสร้าง IV (เวกเตอร์เริ่มต้น) คือ ปรับให้สอดคล้องกัน
  • การแจ้งว่าไม่เหมาะสม emmc_optimized คล้ายกับ inlinecrypt_optimized แต่โมเดลก็ยังเลือก IV ด้วย เมธอดที่จํากัด IV ไว้ที่ 32 บิต การตั้งค่าสถานะนี้ควร สามารถใช้กับฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ซึ่งเป็นไปตาม ข้อมูลจำเพาะของ JEDEC eMMC v5.2 จึงรองรับเพียง 32 บิตเท่านั้น IV สำหรับฮาร์ดแวร์การเข้ารหัสแบบอินไลน์อื่นๆ ให้ใช้ inlinecrypt_optimized แทน ไม่ควรตั้งค่าสถานะนี้ ใช้กับพื้นที่เก็บข้อมูลแบบ UFS ข้อกำหนด UFS ช่วยให้สามารถใช้ IV 64 บิต
  • บนอุปกรณ์ที่รองรับการห่อด้วยฮาร์ดแวร์ คีย์, แฟล็ก wrappedkey_v0 จะช่วยให้ใช้ คีย์ที่หุ้มด้วยฮาร์ดแวร์สำหรับ FBE ตัวเลือกนี้สามารถใช้คู่กันเท่านั้น ด้วยตัวเลือกตัวยึด inlinecrypt และ inlinecrypt_optimizedหรือemmc_optimized แจ้ง
  • แฟล็ก dusize_4k จะบังคับขนาดของหน่วยข้อมูลการเข้ารหัส เป็น 4096 ไบต์แม้ว่าขนาดบล็อกของระบบไฟล์จะไม่ใช่ 4096 ไบต์ ขนาดหน่วยข้อมูลการเข้ารหัสคือรายละเอียดของไฟล์ การเข้ารหัสเนื้อหา แฟล็กนี้ใช้ได้ตั้งแต่ Android 15. ควรใช้แฟล็กนี้เพื่อเปิดใช้เท่านั้น การใช้ฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ที่ไม่รองรับข้อมูล หน่วยโฆษณาที่มีขนาดใหญ่กว่า 4096 ไบต์ในอุปกรณ์ที่ใช้ขนาดหน้า ใหญ่กว่า 4096 ไบต์และใช้ระบบไฟล์ 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 ขึ้นไป จะไม่อนุญาตโหมดนี้อีกต่อไป และ และต้องใช้รูปแบบการเข้ารหัสมาตรฐานแทน

ข้อควรระวัง: เนื่องจากตัวเลือก fileencryption กำหนดรูปแบบบนดิสก์ ไม่สามารถเปลี่ยนแปลงโดย OTA

โดยค่าเริ่มต้น การเข้ารหัสเนื้อหาไฟล์จะดำเนินการโดยใช้เคอร์เนลของ Linux Cryptography API หากต้องการใช้ฮาร์ดแวร์การเข้ารหัสแบบอินไลน์แทน เพิ่มตัวเลือกต่อเชื่อม 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

หมายเหตุ

• ตัวเลือก inlinecrypt และ fileencryption ไปในคอลัมน์ต่างๆ เนื่องจาก inlinecrypt เป็น ตัวเลือกการต่อเชื่อมระบบไฟล์ ในขณะที่ fileencryption เป็นแฟล็ก สำหรับพื้นที่ผู้ใช้ Android
• หากฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ทำงานอย่างถูกต้อง และ ไม่ได้ตั้งค่าแฟล็ก wrappedkey_v0 เพิ่มหรือนำตัวเลือกต่อเชื่อม inlinecrypt ออกได้ทุกเมื่อ โดยไม่ต้องล้างข้อมูลอุปกรณ์ กล่าวคือ เว้นแต่ เปิดใช้คีย์ที่ปกปิดด้วยฮาร์ดแวร์ inlinecrypt ควร มีผลกับการใช้งานเท่านั้น ไม่ใช่รูปแบบบนดิสก์ คุณควร ทดสอบการนำ inlinecrypt ออกระหว่างการพัฒนาเพื่อยืนยัน ว่าฮาร์ดแวร์การเข้ารหัสแบบอินไลน์ทำงานได้อย่างถูกต้อง

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

นับตั้งแต่ Android 9, FBE และ พื้นที่เก็บข้อมูลแบบ Adoptable สามารถใช้ร่วมกันได้

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

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

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

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

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

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

การผสานรวมกับ 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 แอประบบที่ใช้แฟล็กนี้ต้องตรวจสอบข้อมูลทั้งหมดที่จัดเก็บไว้ในค่าเริ่มต้นอย่างละเอียด ตำแหน่ง และเปลี่ยนเส้นทางของข้อมูลที่ละเอียดอ่อนเพื่อใช้พื้นที่เก็บข้อมูล CE อุปกรณ์ ผู้ผลิตที่ใช้ตัวเลือกนี้ควรตรวจสอบข้อมูลอย่างละเอียด จัดเก็บเพื่อให้แน่ใจว่าไม่มีข้อมูลส่วนบุคคล

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

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

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

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

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

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

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

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

พาร์ติชันการกู้คืนไม่สามารถเข้าถึงพื้นที่เก็บข้อมูลที่ได้รับการป้องกันโดย DE ใน พาร์ติชันข้อมูลผู้ใช้ ขอแนะนำให้ใช้อุปกรณ์ 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 และไดเรกทอรีที่คีย์ FBE ป้องกัน รายละเอียด:

ประเภทพื้นที่เก็บข้อมูล	คำอธิบาย	ไดเรกทอรี
ไม่ได้เข้ารหัส	ไดเรกทอรีใน /data ที่ต้องมีหรือไม่จำเป็นต้องเป็น ได้รับการปกป้องโดย FBE ในอุปกรณ์ที่ใช้ข้อมูลเมตา การเข้ารหัส ไดเรกทอรีเหล่านี้ไม่ได้เข้ารหัสอย่างแท้จริง แต่ ได้รับการปกป้องด้วยคีย์การเข้ารหัสข้อมูลเมตาซึ่งเทียบเท่ากับ ระบบ 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 ในตารางนี้ ไม่ได้บอกว่ามีชั้นเรียนอื่น
ต่อบูท	ไฟล์ระบบชั่วคราวที่ไม่จำเป็นต้องผ่านกระบวนการรีบูต	/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 ของผู้ใช้ (นำมาใช้ได้)	ข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบต่อผู้ใช้ในพื้นที่เก็บข้อมูลแบบ Adable	/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}

การจัดเก็บและการปกป้องคีย์

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

ประเภทคีย์	ตำแหน่งที่ตั้งคีย์	ประเภทพื้นที่เก็บข้อมูลของตำแหน่งคีย์
คีย์ DE ของระบบ	/data/unencrypted	ไม่ได้เข้ารหัส
คีย์ CE (ภายใน) ของผู้ใช้	/data/misc/vold/user_keys/ce/${user_id}	ระบบ DE
คีย์ DE (ภายใน) ของผู้ใช้	/data/misc/vold/user_keys/de/${user_id}	ระบบ 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 ปลดล็อกไม่ได้เว้นแต่ ระบบปฏิบัติการที่เชื่อถือได้มีการเปิดเครื่องตามที่บังคับใช้โดยการเปิดเครื่องที่ได้รับการยืนยัน ย้อนกลับ มีการขอความต้านทานบนคีย์คีย์สโตร์ด้วย ซึ่งทำให้คีย์ FBE สามารถ ถูกลบอย่างปลอดภัยในอุปกรณ์ที่ Keymaster รองรับการต้านทานการย้อนกลับ อาส SHA-512 ซึ่งเป็นตัวเลือกสำรองที่ใช้ความพยายามมากที่สุดเมื่อไม่มีข้อมูลการต้านทานย้อนกลับ แฮชของไบต์แบบสุ่ม 16,384 ไบต์ที่จัดเก็บไว้ในไฟล์ secdiscardable ข้างคีย์จะใช้เป็น รหัสแอปพลิเคชัน ของคีย์คีย์สโตร์ คุณจะต้องกู้คืนไบต์เหล่านี้ทั้งหมดเพื่อกู้คืน คีย์ 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 ที่เพิ่มขึ้นอย่างที่สองอย่างที่สองคือคีย์สโตร์ที่ไม่ได้เชื่อมโยงกับการตรวจสอบสิทธิ์ ซึ่งจะระบุการจำกัดอัตราการคาดเดาของ LSKF ที่บังคับใช้กับ SE

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

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