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

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

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

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

Direct Boot

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

  • โปรแกรมโทรศัพท์ AOSP (packages/apps/Dialer)
  • นาฬิกาตั้งโต๊ะ (packages/apps/DeskClock)
  • LatinIME (packages/inputmethods/LatinIME)*
  • แอปการตั้งค่า (แพ็กเกจ/แอป/การตั้งค่า)*
  • SystemUI (frameworks/base/packages/SystemUI)*

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

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

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

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

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

การใช้งาน

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

การสนับสนุนเคอร์เนล

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

CONFIG_FS_ENCRYPTION=y

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

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

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

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

โดยค่าเริ่มต้น การเข้ารหัสเนื้อหาของไฟล์จะดำเนินการโดยใช้ Cryptography 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 โดยมีไวยากรณ์เหมือนกับอาร์กิวเมนต์ของ ตัวเลือก fstab ของ fileencryption และใช้ค่าเริ่มต้นเดียวกัน ดูคำแนะนำสำหรับ fileencryption ด้านบนเกี่ยวกับสิ่งที่ควรใช้ที่นี่
  • ro.crypto.volume.metadata.encryption เลือกรูปแบบการเข้ารหัสข้อมูลเมตา ในพื้นที่เก็บข้อมูลแบบ Adoptable ดูเอกสารประกอบการเข้ารหัส ข้อมูลเมตา

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

ผสานรวมกับ KeyMint

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

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

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

ใน Android 11 ขึ้นไป คีย์ที่initใช้กับไดเรกทอรีจะควบคุมได้โดยอาร์กิวเมนต์encryption=<action>ของคำสั่ง mkdir ในสคริปต์ init ค่าที่เป็นไปได้ของ <action> มี ระบุไว้ใน README สำหรับภาษาเริ่มต้นของ 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 ผู้ผลิตอุปกรณ์ที่ใช้ตัวเลือกนี้ควรตรวจสอบข้อมูลที่จัดเก็บอย่างละเอียดเพื่อให้แน่ใจว่าไม่มีข้อมูลส่วนบุคคล

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

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

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

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

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

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

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

การเข้ารหัส 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 เพื่อสร้างคีย์การเข้ารหัสจริงจากคีย์ที่จัดหาโดยพื้นที่ผู้ใช้

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

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

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

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

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

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

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

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

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

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