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

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 Project (AOSP) และจำเป็นต้องเปิดใช้งานบนอุปกรณ์ที่ตรงตามข้อกำหนดเท่านั้น ผู้ผลิตที่เลือกใช้ FBE อาจต้องการค้นหาวิธีการเพิ่มประสิทธิภาพคุณลักษณะตามระบบบนชิป (SoC) ที่ใช้

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

• บริการโทรศัพท์และตัวเรียกเลขหมาย
• วิธีการป้อนข้อมูลเพื่อป้อนรหัสผ่านลงในหน้าจอล็อค

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

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

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 เป็นต้นมา 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

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 สำหรับภาษาเริ่มต้นของ 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 API ต่อไปนี้จะพร้อมใช้งานเพื่อจัดการบริบทที่ได้รับการสนับสนุนโดยพื้นที่จัดเก็บข้อมูล CE อย่างชัดเจนเมื่อจำเป็น ซึ่งเทียบเท่ากับอุปกรณ์ที่มีการป้องกัน

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

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

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

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

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

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

การจัดการการอัปเดต

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

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

ผู้ผลิตอุปกรณ์ยังได้รับการสนับสนุนให้สำรวจการรัน การทดสอบอัปสตรีม 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 รองรับนโยบายการเข้ารหัสสองเวอร์ชัน: เวอร์ชัน 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 ไม่สามารถปลดล็อคได้ เว้นแต่ระบบปฏิบัติการที่เชื่อถือได้จะบู๊ตแล้ว ตามที่บังคับใช้โดย Verified Boot มีการร้องขอ การต้านทานการย้อนกลับ บนคีย์ Keystore ซึ่งอนุญาตให้ลบคีย์ FBE อย่างปลอดภัยบนอุปกรณ์ที่ Keymaster รองรับการต้านทานการย้อนกลับ เพื่อเป็นแนวทางสำรองอย่างดีที่สุดเมื่อไม่สามารถใช้การต้านทานการย้อนกลับได้ แฮช SHA-512 จำนวน 16384 ไบต์แบบสุ่มที่จัดเก็บไว้ในไฟล์ secdiscardable ที่เก็บไว้ข้างคีย์จึงถูกใช้เป็น แท็ก 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 ดังที่อธิบายไว้ด้านล่าง

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

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

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