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

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

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 Dialer (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

ทรัพยากร Dependency

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

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

การใช้งาน

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

การรองรับเคอร์เนล

การรองรับการเข้ารหัส 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 (Cryptography Extensions) ได้โดยการกําหนดตัวเลือกการกําหนดค่าเคอร์เนลต่อไปนี้

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

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

CONFIG_SCSI_UFS_CRYPTO=y

หากอุปกรณ์ใช้พื้นที่เก็บข้อมูลแบบ eMMC ให้เปิดใช้สิ่งต่อไปนี้ด้วย

CONFIG_MMC_CRYPTO=y

เปิดใช้การเข้ารหัสตามไฟล์

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

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

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

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

ผสานรวมกับ Keymaster

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

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

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

ใน Android 11 ขึ้นไป คุณสามารถควบคุมคีย์ที่initใช้กับไดเรกทอรีได้ด้วยอาร์กิวเมนต์ encryption=<action> ของคำสั่ง mkdir ในสคริปต์ init ค่าที่เป็นไปได้ของ <action> มีการระบุไว้ในREADME สำหรับภาษา init ของ Android

ใน Android 10 การดำเนินการเข้ารหัส init ได้รับการฮาร์ดโค้ดไว้ในตำแหน่งต่อไปนี้

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

ใน Android 9 หรือเก่ากว่า ตำแหน่งจะอยู่ที่

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

กรณีการใช้งานที่ยอมรับได้เพียงกรณีเดียวที่ทราบคือเพื่อรองรับความสามารถ OTA เดิม

รองรับ Direct Boot ในแอประบบ

ทำให้แอปรับรู้ Direct Boot

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

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

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

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

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

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

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

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

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

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

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

ตรวจสอบว่าชื่อไฟล์ที่แสดงอยู่เข้ารหัสฐาน 64 ซึ่งบ่งบอกว่าชื่อไฟล์ได้รับการเข้ารหัสและยังไม่มีคีย์สําหรับถอดรหัส หากชื่อไฟล์แสดงเป็นข้อความธรรมดา แสดงว่ามีปัญหา

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

รายละเอียดการใช้งาน 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 และไดเรกทอรีที่ปกป้องโดยละเอียด

พื้นที่เก็บข้อมูลและการป้องกันคีย์

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

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

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

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

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

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