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

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

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

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

บูตโดยตรง

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

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

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

  • ที่จัดเก็บข้อมูล Credential Encrypted (CE) ซึ่งเป็นที่จัดเก็บเริ่มต้นและใช้ได้เฉพาะหลังจากที่ผู้ใช้ปลดล็อกอุปกรณ์แล้ว
  • ที่จัดเก็บข้อมูลแบบเข้ารหัสด้วยอุปกรณ์ (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 ให้คำสั่งใหม่หลายคำสั่งแก่ vold เพื่อสนับสนุนการจัดการคีย์สำหรับคีย์ CE และ DE ของผู้ใช้หลายราย นอกเหนือจากการเปลี่ยนแปลงหลักในการใช้ความสามารถ เข้ารหัสตามไฟล์ ในเคอร์เนลแล้ว แพ็คเกจระบบจำนวนมากรวมถึงหน้าจอล็อกและ SystemUI ยังได้รับการแก้ไขเพื่อรองรับคุณสมบัติ FBE และ Direct Boot ซึ่งรวมถึง:

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

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

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

การพึ่งพา

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

  • รองรับเคอร์เนล สำหรับการเข้ารหัส Ext4 หรือการเข้ารหัส F2FS
  • รองรับ Keymaster ด้วย HAL เวอร์ชัน 1.0 หรือ 2.0 ไม่มีการสนับสนุนสำหรับ Keymaster 0.3 เนื่องจากไม่ได้ให้ความสามารถที่จำเป็นหรือรับประกันการป้องกันที่เพียงพอสำหรับคีย์การเข้ารหัส
  • Keymaster/ Keystore และ Gatekeeper จะต้องใช้งานใน Trusted Execution Environment (TEE) เพื่อให้การป้องกันสำหรับคีย์ DE เพื่อให้ OS ที่ไม่ได้รับอนุญาต (ระบบปฏิบัติการแบบกำหนดเองที่แฟลชบนอุปกรณ์) ไม่สามารถขอคีย์ DE ได้ง่ายๆ
  • ต้องใช้ Hardware Root of Trust และ Verified Boot ที่ผูกไว้กับการเริ่มต้นคีย์มาสเตอร์เพื่อให้แน่ใจว่าข้อมูลรับรองการเข้ารหัสอุปกรณ์ไม่สามารถเข้าถึงได้โดยระบบปฏิบัติการที่ไม่ได้รับอนุญาต

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

การดำเนินการ

ประการแรกและสำคัญที่สุด แอปต่างๆ เช่น นาฬิกาปลุก โทรศัพท์ คุณลักษณะการช่วยสำหรับการเข้าถึง ควรทำเป็น android:directBootAware ตามเอกสารสำหรับนักพัฒนา Direct Boot

การสนับสนุนเคอร์เนล

การสนับสนุนเคอร์เนลสำหรับการเข้ารหัส Ext4 และ F2FS มีอยู่ในเคอร์เนลทั่วไปของ Android เวอร์ชัน 3.18 และสูงกว่า หากต้องการเปิดใช้งานในเคอร์เนลที่เป็นเวอร์ชัน 5.1 หรือสูงกว่า ให้ใช้:

CONFIG_FS_ENCRYPTION=y

สำหรับเคอร์เนลรุ่นเก่า ให้ใช้ CONFIG_EXT4_ENCRYPTION=y หากระบบไฟล์ข้อมูลผู้ใช้ของอุปกรณ์เป็น Ext4 หรือใช้ CONFIG_F2FS_FS_ENCRYPTION=y หากระบบไฟล์ข้อมูลผู้ใช้ของอุปกรณ์ของ userdata เป็น userdata

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

นอกเหนือจากการรองรับการทำงานสำหรับการเข้ารหัส 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-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 แทนที่จะเป็นหนึ่งไฟล์ต่อไฟล์ การสร้าง IVs (เวกเตอร์การเริ่มต้น) จะถูกปรับตามนั้น
    • แฟ emmc_optimized คล้ายกับ inlinecrypt_optimized แต่ยังเลือกวิธีการสร้าง IV ที่จำกัด IVs ไว้ที่ 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 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 เลือกรูปแบบการเข้ารหัสข้อมูลเมตาบนพื้นที่จัดเก็บข้อมูลที่ปรับใช้ได้ ดู เอกสารการเข้ารหัสข้อมูลเมตา

การทำงานร่วมกับคีย์มาสเตอร์

การสร้างคีย์และการจัดการเคอร์เนลคีย์ริงถูกจัดการโดย vold การใช้งาน AOSP ของ FBE ต้องการให้อุปกรณ์รองรับ Keymaster HAL เวอร์ชัน 1.0 หรือใหม่กว่า ไม่มีการสนับสนุนสำหรับ Keymaster HAL เวอร์ชันก่อนหน้า

ในการบู๊ตครั้งแรก คีย์ของผู้ใช้ 0 จะถูกสร้างขึ้นและติดตั้งในช่วงต้นของกระบวนการบู๊ต เมื่อขั้นตอน on-post-fs ของ init เสร็จสิ้น Keymaster จะต้องพร้อมที่จะจัดการกับคำขอ บนอุปกรณ์ Pixel สิ่งนี้ได้รับการจัดการโดยให้มีบล็อกสคริปต์เพื่อให้แน่ใจว่า Keymaster เริ่มทำงานก่อน /data จะถูกเมาต์

นโยบายการเข้ารหัส

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

ใน Android 11 ขึ้นไป นโยบายการเข้ารหัสจะไม่ถูกฮาร์ดโค้ดในตำแหน่งส่วนกลางอีกต่อไป แต่ถูกกำหนดโดยอาร์กิวเมนต์ของคำสั่ง mkdir ในสคริปต์ init ไดเร็กทอรีที่เข้ารหัสด้วยคีย์ DE ของระบบ ใช้ encryption=Require ในขณะที่ไดเร็กทอรีที่ไม่ได้เข้ารหัส (หรือไดเร็กทอรีที่เข้ารหัสไดเร็กทอรีย่อยด้วยคีย์ต่อผู้ใช้) ใช้ encryption=None

ใน Android 10 นโยบายการเข้ารหัสถูกฮาร์ดโค้ดในตำแหน่งนี้:

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

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

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

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

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

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

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

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

กำลังดำเนินการอัปเดต

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

ที่มาของคีย์

คีย์เข้ารหัสตามไฟล์ ซึ่งเป็นคีย์ 512 บิต ถูกเข้ารหัสโดยคีย์อื่น (คีย์ AES-GCM 256 บิต) ที่อยู่ใน TEE ในการใช้คีย์ TEE นี้ ต้องปฏิบัติตามข้อกำหนดสามประการ:

  • โทเค็นการตรวจสอบสิทธิ์
  • หนังสือรับรองที่ยืดออก
  • “แฮชที่ทิ้งได้”

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

ข้อมูลรับรองแบบ ขยายคือข้อมูลรับรอง ผู้ใช้หลังจากเพิ่มข้อมูลและขยายด้วยอัลกอริธึมการ scrypt ข้อมูลประจำตัวจะถูกแฮชเพียงครั้งเดียวในบริการการตั้งค่าการล็อกก่อนที่จะถูกส่งไปยัง vold เพื่อส่งต่อไปยัง scrypt สิ่งนี้ถูกผูกไว้กับคีย์ใน TEE แบบเข้ารหัสด้วยการรับประกันทั้งหมดที่ใช้กับ KM_TAG_APPLICATION_ID หากผู้ใช้ไม่มีหนังสือรับรอง ก็จะไม่มีการใช้ข้อมูลรับรองแบบขยายและไม่จำเป็นต้องใช้

แฮชที่ทิ้งได้คือ secdiscardable hash ขนาด 512 บิตของไฟล์ขนาด 16 KB แบบสุ่มที่จัดเก็บไว้ข้างๆ ข้อมูลอื่นๆ ที่ใช้ในการสร้างคีย์ใหม่ เช่น เมล็ดพันธุ์ ไฟล์นี้ถูกลบอย่างปลอดภัยเมื่อคีย์ถูกลบ หรือถูกเข้ารหัสด้วยวิธีใหม่ การป้องกันที่เพิ่มเข้ามานี้ทำให้มั่นใจได้ว่าผู้โจมตีจะต้องกู้คืนไฟล์ที่ถูกลบอย่างปลอดภัยทุกบิตเพื่อกู้คืนคีย์ สิ่งนี้ถูกผูกไว้กับคีย์ใน TEE แบบเข้ารหัสด้วยการรับประกันทั้งหมดที่ใช้กับ KM_TAG_APPLICATION_ID

ในกรณีส่วนใหญ่ คีย์ FBE ยังผ่านขั้นตอนการสร้างคีย์เพิ่มเติมในเคอร์เนล เพื่อสร้างคีย์ย่อยที่ใช้จริงในการเข้ารหัส เช่น ต่อไฟล์หรือคีย์ต่อโหมด สำหรับนโยบายการเข้ารหัสเวอร์ชัน 2 จะใช้ HKDF-SHA512 สำหรับสิ่งนี้