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

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

เมื่อเรียกใช้ในโหมดนี้ ระบบจะใช้ 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 และไดเรกทอรีที่คีย์เหล่านั้นปกป้องโดยละเอียด

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

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

ดังที่แสดงในตารางก่อนหน้า คีย์ 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 จะใช้คีย์คีย์สโตร์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ การลงทะเบียน Gatekeeper ซึ่งจะช่วยให้การจำกัดอัตราที่บังคับใช้โดย TEE ของการคาดเดา LSKF

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