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

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

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

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

Direct Boot

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

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

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

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

การแยกนี้ทำให้โปรไฟล์งานปลอดภัยยิ่งขึ้น เนื่องจากช่วยให้ผู้ใช้มากกว่า 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)
• Desk Clock (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• แอปการตั้งค่า (packages/apps/Settings)*
• 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 ได้โดยง่าย
• ต้องใช้รูทของความน่าเชื่อถือของฮาร์ดแวร์และการเปิดเครื่องที่ได้รับการยืนยันที่เชื่อมโยงกับการเริ่มต้น KeyMint เพื่อให้มั่นใจว่าระบบปฏิบัติการที่ไม่ได้รับอนุญาตจะเข้าถึงคีย์ 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

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

นอกเหนือจากการรองรับการเข้ารหัส 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 คือรายการแฟล็กที่คั่นด้วยอักขระ + ระบบรองรับแฟล็กต่อไปนี้
  • แฟล็ก 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 บิต
  • ในอุปกรณ์ที่รองรับคีย์การเข้ารหัสในบรรทัดที่ห่อหุ้มด้วยฮาร์ดแวร์ คุณสามารถทำให้คีย์ FBE ห่อหุ้มด้วยฮาร์ดแวร์ได้โดย การเพิ่มแฟล็ก wrappedkey หรือ wrappedkey_v0 wrappedkey เป็นเวอร์ชันที่ใหม่กว่า ส่วน wrappedkey_v0 ควรใช้ในอุปกรณ์ที่ไม่รองรับ wrappedkey หรือเปิดตัวด้วย wrappedkey_v0 อยู่แล้วเท่านั้น ดูข้อมูลเพิ่มเติมได้ที่ เปิดใช้ คีย์ที่ห่อหุ้ม
  • แฟล็ก 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 ขึ้นไป ระบบจะไม่อนุญาตให้ใช้โหมดนี้อีกต่อไป และต้องใช้รูปแบบการเข้ารหัสมาตรฐานแทน

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

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

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

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

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

ผสานรวมกับ 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 สำหรับภาษา 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 เดิม

รองรับการบูตโดยตรงในแอปของระบบ

ทำให้แอปรับรู้การบูตโดยตรง

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

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

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

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

เมื่อเรียกใช้ในโหมดนี้ ระบบจะมี 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

ในอุปกรณ์อื่นๆ (อุปกรณ์ส่วนใหญ่ที่ไม่ใช่ Automotive) ผู้ใช้หลักคือผู้ใช้ 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 เพื่อสร้างคีย์การเข้ารหัสจริงจากคีย์ที่ผู้ใช้ระบุ

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

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

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

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

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

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

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

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

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

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