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

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

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

บูตโดยตรง

การเข้ารหัสไฟล์ที่ใช้ช่วยให้คุณลักษณะใหม่ที่นำมาใช้ใน Android 7.0 ที่เรียกว่า 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 ( ระบบ / Vold ) จะมีฟังก์ชันสำหรับการจัดการอุปกรณ์จัดเก็บข้อมูลและไดรฟ์บน Android การเพิ่ม FBE ให้คำสั่งใหม่หลายคำสั่งแก่ vold เพื่อสนับสนุนการจัดการคีย์สำหรับคีย์ CE และ DE ของผู้ใช้หลายราย นอกเหนือจากการเปลี่ยนแปลงหลักที่จะใช้ การเข้ารหัสไฟล์ที่ใช้ ความสามารถในเคอร์เนล, แพคเกจระบบมากมายรวมทั้ง lockscreen และ SystemUI ได้รับการแก้ไขให้การสนับสนุนคุณสมบัติ FBE และตรง 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 และยามจะต้องดำเนินการใน Trusted Execution สิ่งแวดล้อม (TEE) เพื่อให้การป้องกันสำหรับคีย์ DE เพื่อให้ไม่ได้รับอนุญาตระบบปฏิบัติการ (OS ที่กำหนดเองประกายบนอุปกรณ์) ไม่สามารถเพียงแค่ขอคีย์ DE
  • รากฮาร์ดแวร์ของความน่าเชื่อถือและ Boot ที่ตรวจสอบแล้วผูกไว้กับ initialisation Keymaster เป็นสิ่งจำเป็นเพื่อให้มั่นใจว่าข้อมูลประจำตัวของอุปกรณ์การเข้ารหัสไม่สามารถเข้าถึงได้โดยระบบปฏิบัติการที่ไม่ได้รับอนุญาต

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

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

แรกและสำคัญที่สุดปพลิเคชันเช่นนาฬิกาปลุก, โทรศัพท์คุณลักษณะการเข้าถึงควรจะทำหุ่นยนต์: directBootAware ตาม 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

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

นอกเหนือจากการรองรับการทำงานสำหรับการเข้ารหัส 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 เกลือขีด จำกัด ที่ 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 และ การจัดเก็บ adoptable สามารถใช้ร่วมกัน

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

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

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

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

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

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

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

การประยุกต์ใช้การเข้ารหัสลับตระหนักถึงปฏิสัมพันธ์ระหว่างผู้ใช้ในลักษณะนี้: 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. เพิ่มไดเรกทอรีระดับบนสุดนี้เพื่อยกเว้นนโยบายการเข้ารหัส (ดู นโยบายการเข้ารหัส บน)
  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 อินสแตนซ์กับชุด lockscreen ในผู้ใช้หลัก แล้ว adb เปลือกลงในอุปกรณ์และการใช้ 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 ดูที่ เอกสาร kernel ต้นน้ำ

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

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

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

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

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

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

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