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

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)*
• แอปการตั้งค่า (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

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

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

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

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

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

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

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

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

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

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

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

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

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

การระบุตัวเลือก 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 เดิม

รองรับการเปิดเครื่องโดยตรงในแอประบบ

ทำให้แอปทราบถึง Direct Boot

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

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

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

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

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

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

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