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
:
- สร้างไดเร็กทอรีระดับบนสุด (เช่น
misc_ne
) ในพาร์ติชันuserdata
- กำหนดค่าไดเร็กทอรีระดับบนสุดนี้ให้ไม่มีการเข้ารหัส (ดูที่ Excluding directory )
- สร้างไดเร็กทอรีภายในไดเร็กทอรีระดับบนสุดเพื่อเก็บแพ็คเกจ OTA
- เพิ่มกฎ 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 และไดเร็กทอรีที่ป้องกันโดยละเอียด:
คลาสพื้นที่เก็บข้อมูล | คำอธิบาย | ไดเรกทอรี |
---|---|---|
ระบบดีอี | ข้อมูลที่เข้ารหัสอุปกรณ์ไม่ได้เชื่อมโยงกับผู้ใช้รายใดรายหนึ่ง | /data/system , /data/app และไดเร็กทอรีย่อยอื่นๆ ของ /data |
ต่อการบูต | ไฟล์ระบบชั่วคราวที่ไม่จำเป็นต้องอยู่รอดในการรีบูต | /data/per_boot |
CE ผู้ใช้ (ภายใน) | ข้อมูลประจำตัวที่เข้ารหัสต่อผู้ใช้ในที่จัดเก็บข้อมูลภายใน |
|
ผู้ใช้ DE (ภายใน) | ข้อมูลที่เข้ารหัสตามอุปกรณ์ต่อผู้ใช้ในที่จัดเก็บข้อมูลภายใน |
|
ผู้ใช้ CE (ยอมรับได้) | ข้อมูลประจำตัวที่เข้ารหัสต่อผู้ใช้ในที่เก็บข้อมูลที่ปรับใช้ได้ |
|
ผู้ใช้ DE (นำมาใช้ได้) | ข้อมูลที่เข้ารหัสตามอุปกรณ์ต่อผู้ใช้ในที่เก็บข้อมูลที่ปรับใช้ได้ |
|
การจัดเก็บและการป้องกันคีย์
คีย์ FBE ทั้งหมดได้รับการจัดการโดย vold
และจัดเก็บแบบเข้ารหัสบนดิสก์ ยกเว้นคีย์สำหรับการบู๊ตซึ่งไม่ได้เก็บไว้เลย ตารางต่อไปนี้แสดงตำแหน่งที่จัดเก็บคีย์ FBE ต่างๆ:
ประเภทกุญแจ | ตำแหน่งที่สำคัญ | คลาสพื้นที่เก็บข้อมูลของตำแหน่งสำคัญ |
---|---|---|
คีย์ระบบ DE | /data/unencrypted | ไม่ได้เข้ารหัส |
คีย์ผู้ใช้ CE (ภายใน) | /data/misc/vold/user_keys/ce/${user_id} | ระบบดีอี |
คีย์ผู้ใช้ DE (ภายใน) | /data/misc/vold/user_keys/de/${user_id} | ระบบดีอี |
คีย์ผู้ใช้ CE (นำมาใช้ได้) | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} | CE ผู้ใช้ (ภายใน) |
คีย์ผู้ใช้ DE (ปรับใช้ได้) | /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} | ผู้ใช้ DE (ภายใน) |
ตามที่แสดงในตารางก่อนหน้านี้ คีย์ 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