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

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

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

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

บูตโดยตรง

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

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

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

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

การแยกส่วนนี้ทำให้โปรไฟล์งานมีความปลอดภัยมากขึ้น เนื่องจากทำให้ผู้ใช้หลายคนได้รับการปกป้องพร้อมกัน เนื่องจากการเข้ารหัสไม่ได้ขึ้นอยู่กับรหัสผ่านเวลาบูตเพียงอย่างเดียวอีกต่อไป

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

การใช้งานการเข้ารหัสตามไฟล์อย่างสมบูรณ์บนระบบไฟล์ Ext4 และ F2FS มีให้ในโครงการ Android Open Source (AOSP) และจำเป็นต้องเปิดใช้งานบนอุปกรณ์ที่ตรงตามข้อกำหนดเท่านั้น ผู้ผลิตที่เลือกใช้ FBE อาจต้องการสำรวจวิธีการเพิ่มประสิทธิภาพคุณลักษณะตามระบบบนชิป (SoC) ที่ใช้

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

• บริการโทรศัพท์และ Dialer
• วิธีป้อนรหัสผ่านในหน้าจอล็อก

ตัวอย่างและที่มา

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

• AOSP Dialer (แพ็คเกจ/แอพ/Dialer)
• นาฬิกาตั้งโต๊ะ (แพ็คเกจ/แอพ/DeskClock)
• LatinIME (แพ็คเกจ/วิธีการป้อนข้อมูล/LatinIME)*
• แอปการตั้งค่า (แพ็คเกจ/แอป/การตั้งค่า)*
• SystemUI (เฟรมเวิร์ก/ฐาน/แพ็คเกจ/SystemUI)*

* แอปพลิเคชันระบบที่ใช้แอตทริบิวต์รายการ defaultToDeviceProtectedStorage

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

การพึ่งพา

หากต้องการใช้งาน AOSP ของ FBE อย่างปลอดภัย อุปกรณ์จำเป็นต้องเป็นไปตามการขึ้นต่อกันต่อไปนี้:

• การสนับสนุนเคอร์เนล สำหรับการเข้ารหัส Ext4 หรือการเข้ารหัส F2FS
• การสนับสนุนคีย์มาสเตอร์ ด้วย HAL เวอร์ชัน 1.0 หรือสูงกว่า ไม่มีการสนับสนุนสำหรับ Keymaster 0.3 เนื่องจากไม่มีความสามารถที่จำเป็นหรือรับประกันการป้องกันที่เพียงพอสำหรับคีย์การเข้ารหัส
• ต้องติดตั้ง Keymaster/ Keystore และ Gatekeeper ใน Trusted Execution Environment (TEE) เพื่อป้องกันคีย์ DE เพื่อให้ OS ที่ไม่ได้รับอนุญาต (OS แบบกำหนดเองที่แฟลชบนอุปกรณ์) ไม่สามารถขอคีย์ DE ได้
• จำเป็นต้อง มีรูทฮาร์ดแวร์ของ Trust และ Verified Boot ที่เชื่อมโยงกับการกำหนดค่าเริ่มต้นของ Keymaster เพื่อให้แน่ใจว่าคีย์ 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 (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 ตัวเลือกนี้กำหนดรูปแบบการเข้ารหัสในที่จัดเก็บข้อมูลภายใน ประกอบด้วยพารามิเตอร์ที่คั่นด้วยโคลอนสูงสุดสามตัว:

• พารามิเตอร์ 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 แทนที่จะเป็นคีย์เดียวต่อไฟล์ การสร้าง 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

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

เนื่องจาก Android 14 (AOSP รุ่นทดลอง) 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

พื้นที่เก็บข้อมูลที่ยอมรับได้

ตั้งแต่ Android 9, FBE และ พื้นที่เก็บข้อมูลที่นำ มาใช้ร่วมกันได้

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

บนอุปกรณ์ที่เปิดตัวด้วย Android 11 ขึ้นไป ให้ใช้คุณสมบัติต่อไปนี้:

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

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

การผสานรวมกับคีย์มาสเตอร์

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

ไม่รวมไดเร็กทอรี

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

ใน Android 11 ขึ้นไป คีย์ที่ init ใช้กับไดเร็กทอรีสามารถควบคุมได้โดยอาร์กิวเมนต์ encryption=<action> ของคำสั่ง mkdir ในสคริปต์เริ่มต้น ค่าที่เป็นไปได้ของ <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 ทราบ

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

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

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

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

เมื่อทำงานในโหมดนี้ System APIs ต่อไปนี้จะพร้อมใช้งานเพื่อจัดการ Context ที่สนับสนุนโดย CE storage อย่างชัดเจนเมื่อจำเป็น ซึ่งเทียบเท่ากับ Device Protected counterparts

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

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

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

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

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

ID ผู้ใช้ของโปรไฟล์งานแต่ละรายการจะได้รับคีย์ 2 รายการ ได้แก่ DE และ CE เมื่อตรงตามความท้าทายในการทำงาน ผู้ใช้โปรไฟล์จะถูกปลดล็อกและ Keymaster (ใน TEE) สามารถให้คีย์ TEE ของโปรไฟล์ได้

การจัดการการปรับปรุง

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

เมื่อใช้โซลูชัน OTA รุ่นเก่า ซึ่งต้องการการกู้คืนเพื่อเข้าถึงไฟล์ OTA บนพาร์ติ userdata :

1. สร้างไดเร็กทอรีระดับบนสุด (เช่น misc_ne ) ในพาร์ติชัน userdata
2. กำหนดค่าไดเร็กทอรีระดับบนสุดนี้ให้ไม่มีการเข้ารหัส (ดูที่ Excluding directory )
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

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

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

รายละเอียดการใช้งาน AOSP

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

การเข้ารหัส fscrypt

การใช้งาน AOSP ใช้การเข้ารหัส "fscrypt" (รองรับโดย ext4 และ f2fs) ในเคอร์เนล และโดยปกติจะกำหนดค่าเป็น:

• เข้ารหัสเนื้อหาไฟล์ด้วย AES-256 ในโหมด XTS
• เข้ารหัสชื่อไฟล์ด้วย AES-256 ในโหมด CBC-CTS

รองรับ การเข้ารหัส Adiantum เมื่อเปิดใช้งานการเข้ารหัส Adiantum ทั้งเนื้อหาไฟล์และชื่อไฟล์จะถูกเข้ารหัสด้วย Adiantum

fscrypt รองรับนโยบายการเข้ารหัสสองเวอร์ชัน: เวอร์ชัน 1 และเวอร์ชัน 2 เวอร์ชัน 1 เลิกใช้งานแล้ว และข้อกำหนด CDD สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 11 และสูงกว่านั้นเข้ากันได้กับเวอร์ชัน 2 เท่านั้น นโยบายการเข้ารหัสเวอร์ชัน 2 ใช้ HKDF-SHA512 เพื่อรับค่าจริง คีย์เข้ารหัสจากคีย์ที่ userspace ให้มา

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

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

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

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

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

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

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

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

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

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

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

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

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