Mã hoá dựa trên tệp

Android 7.0 trở lên hỗ trợ tính năng mã hoá dựa trên tệp (FBE). Tính năng mã hoá dựa trên tệp cho phép mã hoá nhiều tệp bằng nhiều khoá có thể mở khoá độc lập.

Bài viết này mô tả cách bật tính năng mã hoá dựa trên tệp trên thiết bị mới và cách các ứng dụng hệ thống có thể sử dụng API Khởi động trực tiếp để mang đến cho người dùng trải nghiệm tốt nhất và an toàn nhất có thể.

Tất cả thiết bị chạy Android 10 trở lên đều phải sử dụng phương thức mã hoá dựa trên tệp.

Khởi động trực tiếp

Phương thức mã hoá dựa trên tệp hỗ trợ một tính năng mới được giới thiệu trong Android 7.0 có tên là Khởi động trực tiếp. Tính năng Khởi động trực tiếp cho phép các thiết bị đã mã hoá khởi động thẳng vào màn hình khoá. Trước đây, trên các thiết bị được mã hoá bằng tính năng mã hoá toàn bộ đĩa (FDE), người dùng cần cung cấp thông tin đăng nhập trước khi có thể truy cập vào bất kỳ dữ liệu nào, khiến điện thoại không thể thực hiện tất cả các thao tác, ngoại trừ những thao tác cơ bản nhất. Ví dụ: chuông báo không hoạt động, dịch vụ hỗ trợ tiếp cận không dùng được và điện thoại không thể nhận cuộc gọi mà chỉ có thể thực hiện các thao tác quay số khẩn cấp cơ bản.

Nhờ có tính năng mã hoá dựa trên tệp (FBE) và các API mới giúp ứng dụng nhận biết được trạng thái mã hoá, các ứng dụng này có thể hoạt động trong một bối cảnh hạn chế. Điều này có thể xảy ra trước khi người dùng cung cấp thông tin đăng nhập của họ, trong khi vẫn bảo vệ thông tin riêng tư của người dùng.

Trên thiết bị hỗ trợ FBE, mỗi người dùng thiết bị có hai vị trí lưu trữ dành cho ứng dụng:

• Bộ nhớ được mã hoá dành cho thông tin đăng nhập (CE), đây là vị trí lưu trữ mặc định và chỉ có sẵn sau khi người dùng mở khoá thiết bị.
• Bộ nhớ được mã hoá của thiết bị (DE), đây là vị trí lưu trữ có sẵn cả trong chế độ Khởi động trực tiếp và sau khi người dùng mở khoá thiết bị.

Việc tách biệt này giúp hồ sơ công việc an toàn hơn vì cho phép bảo vệ nhiều người dùng cùng một lúc, do quá trình mã hoá không còn chỉ dựa vào mật khẩu thời gian khởi động.

API Khởi động trực tiếp cho phép các ứng dụng có khả năng nhận biết quá trình mã hoá truy cập vào từng khu vực này. Có những thay đổi đối với vòng đời của ứng dụng để đáp ứng nhu cầu thông báo cho ứng dụng khi bộ nhớ CE của người dùng được mở khoá, nhằm phản hồi việc nhập thông tin xác thực lần đầu tại màn hình khoá hoặc trong trường hợp hồ sơ công việc cung cấp thử thách công việc. Các thiết bị chạy Android 7.0 phải hỗ trợ các API và vòng đời mới này, bất kể chúng có triển khai FBE hay không. Tuy nhiên, nếu không có FBE, bộ nhớ DE và CE luôn ở trạng thái mở khoá.

Dự án nguồn mở Android (AOSP) cung cấp một bản triển khai hoàn chỉnh của tính năng mã hoá dựa trên tệp trên hệ thống tệp Ext4 và F2FS. Bạn chỉ cần bật tính năng này trên các thiết bị đáp ứng yêu cầu. Các nhà sản xuất chọn sử dụng FBE có thể khám phá các cách tối ưu hoá tính năng này dựa trên hệ thống trên chip (SoC) được sử dụng.

Tất cả các gói cần thiết trong AOSP đã được cập nhật để nhận biết chế độ khởi động trực tiếp. Tuy nhiên, khi nhà sản xuất thiết bị sử dụng phiên bản tuỳ chỉnh của các ứng dụng này, họ muốn đảm bảo rằng ít nhất có các gói nhận biết chế độ khởi động trực tiếp cung cấp các dịch vụ sau:

• Dịch vụ điện thoại và Trình quay số
• Phương thức nhập mật khẩu vào màn hình khoá

Ví dụ và nguồn

Android cung cấp một phương thức triển khai tham chiếu của tính năng mã hoá dựa trên tệp, trong đó vold (system/vold) cung cấp chức năng quản lý thiết bị lưu trữ và ổ đĩa trên Android. Việc bổ sung FBE cung cấp cho vold một số lệnh mới để hỗ trợ quản lý khoá cho các khoá CE và DE của nhiều người dùng. Ngoài những thay đổi cốt lõi để sử dụng khả năng mã hoá dựa trên tệp trong nhân hệ điều hành, nhiều gói hệ thống (bao gồm cả màn hình khoá và SystemUI) đã được sửa đổi để hỗ trợ các tính năng FBE và Khởi động trực tiếp. Các loại tài khoản bao gồm:

• Trình quay số AOSP (packages/apps/Dialer)
• Đồng hồ để bàn (gói/ứng dụng/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Ứng dụng Cài đặt (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

* Các ứng dụng hệ thống sử dụng thuộc tính tệp kê khai defaultToDeviceProtectedStorage

Bạn có thể tìm thấy thêm ví dụ về các ứng dụng và dịch vụ có nhận biết mã hoá bằng cách chạy lệnh mangrep directBootAware trong thư mục khung hoặc gói của cây nguồn AOSP.

Phần phụ thuộc

Để sử dụng phương thức triển khai FBE của AOSP một cách an toàn, thiết bị cần đáp ứng các phần phụ thuộc sau:

• Hỗ trợ nhân cho mã hoá Ext4 hoặc mã hoá F2FS.
• Hỗ trợ KeyMint (hoặc Keymaster 1.0 trở lên). Keymaster 0.3 không được hỗ trợ vì không cung cấp các chức năng cần thiết hoặc không đảm bảo khả năng bảo vệ đầy đủ cho khoá mã hoá.
• KeyMint/Keymaster và Gatekeeper phải được triển khai trong Môi trường thực thi đáng tin cậy (TEE) để bảo vệ khoá DE, nhờ đó, một hệ điều hành trái phép (hệ điều hành tuỳ chỉnh được cài đặt vào thiết bị) không thể chỉ yêu cầu khoá DE.
• Gốc tin cậy phần cứng và Xác minh quy trình khởi động liên kết với quá trình khởi chạy KeyMint là bắt buộc để đảm bảo rằng hệ điều hành trái phép không thể truy cập vào các khoá DE.

Triển khai

Trước tiên, các ứng dụng như đồng hồ báo thức, điện thoại và bộ tính năng hỗ trợ tiếp cận phải được đặt thành android:directBootAware theo tài liệu dành cho nhà phát triển về Khởi động trực tiếp.

Hỗ trợ nhân hệ điều hành

Tính năng hỗ trợ mã hoá Ext4 và F2FS của nhân hệ điều hành có trong các nhân hệ điều hành Android phổ biến, phiên bản 3.18 trở lên. Để bật tính năng này trong nhân hệ điều hành phiên bản 5.1 trở lên, hãy dùng:

CONFIG_FS_ENCRYPTION=y

Đối với các hạt nhân cũ hơn, hãy sử dụng CONFIG_EXT4_ENCRYPTION=y nếu hệ thống tệp userdata của thiết bị là Ext4 hoặc sử dụng CONFIG_F2FS_FS_ENCRYPTION=y nếu hệ thống tệp userdata của thiết bị là F2FS.

Nếu thiết bị của bạn hỗ trợ bộ nhớ thích ứng hoặc sử dụng tính năng mã hoá siêu dữ liệu trên bộ nhớ trong, hãy bật cả các tuỳ chọn cấu hình hạt nhân cần thiết cho việc mã hoá siêu dữ liệu như mô tả trong tài liệu về mã hoá siêu dữ liệu.

Ngoài việc hỗ trợ chức năng mã hoá Ext4 hoặc F2FS, nhà sản xuất thiết bị cũng nên bật tính năng tăng tốc mã hoá để tăng tốc độ mã hoá dựa trên tệp và cải thiện trải nghiệm người dùng. Ví dụ: trên các thiết bị dựa trên ARM64, bạn có thể bật tính năng tăng tốc ARMv8 CE (Phần mở rộng mật mã) bằng cách đặt các tuỳ chọn cấu hình hạt nhân sau:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Để cải thiện hiệu suất và giảm mức sử dụng điện năng hơn nữa, nhà sản xuất thiết bị cũng có thể cân nhắc triển khai phần cứng mã hoá cùng dòng, giúp mã hoá/giải mã dữ liệu trong khi dữ liệu đang được chuyển đến/từ thiết bị lưu trữ. Nhân Android phổ biến (phiên bản 4.14 trở lên) chứa một khung cho phép sử dụng tính năng mã hoá cùng dòng khi có hỗ trợ phần cứng và trình điều khiển của nhà cung cấp. Bạn có thể bật khung mã hoá cùng dòng bằng cách đặt các tuỳ chọn cấu hình hạt nhân sau:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Nếu thiết bị của bạn sử dụng bộ nhớ dựa trên UFS, hãy bật cả:

CONFIG_SCSI_UFS_CRYPTO=y

Nếu thiết bị của bạn sử dụng bộ nhớ dựa trên eMMC, hãy bật cả:

CONFIG_MMC_CRYPTO=y

Bật tính năng mã hoá dựa trên tệp

Để bật FBE trên một thiết bị, bạn cần bật tính năng này trên bộ nhớ trong (userdata). Thao tác này cũng tự động bật FBE trên bộ nhớ thích ứng; tuy nhiên, bạn có thể ghi đè định dạng mã hoá trên bộ nhớ thích ứng nếu cần.

Bộ nhớ trong

FBE được bật bằng cách thêm tuỳ chọn fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] vào cột fs_mgr_flags của dòng fstab cho userdata. Tuỳ chọn này xác định định dạng mã hoá trên bộ nhớ trong. Nó chứa tối đa ba tham số được phân tách bằng dấu hai chấm:

• Tham số contents_encryption_mode xác định thuật toán mã hoá nào được dùng để mã hoá nội dung tệp. Giá trị này có thể là aes-256-xts hoặc adiantum. Kể từ Android 11, bạn cũng có thể để trống tham số này để chỉ định thuật toán mặc định là aes-256-xts.
• Tham số filenames_encryption_mode xác định thuật toán mã hoá nào được dùng để mã hoá tên tệp. Giá trị này có thể là aes-256-cts, aes-256-heh, adiantum hoặc aes-256-hctr2. Nếu không được chỉ định, thì giá trị mặc định sẽ là aes-256-cts nếu contents_encryption_mode là aes-256-xts, hoặc là adiantum nếu contents_encryption_mode là adiantum.
• Tham số flags (mới trong Android 11) là danh sách các cờ được phân tách bằng ký tự +. Các cờ sau đây được hỗ trợ:
  • Cờ v1 chọn chính sách mã hoá phiên bản 1; cờ v2 chọn chính sách mã hoá phiên bản 2. Chính sách mã hoá phiên bản 2 sử dụng hàm dẫn xuất khoá an toàn và linh hoạt hơn. Giá trị mặc định là v2 nếu thiết bị chạy Android 11 trở lên (theo xác định của ro.product.first_api_level) hoặc v1 nếu thiết bị chạy Android 10 trở xuống.
  • Cờ inlinecrypt_optimized chọn một định dạng mã hoá được tối ưu hoá cho phần cứng mã hoá cùng dòng không xử lý hiệu quả số lượng lớn khoá. Hệ thống thực hiện việc này bằng cách chỉ lấy một khoá mã hoá nội dung tệp cho mỗi khoá CE hoặc DE, thay vì một khoá cho mỗi tệp. Việc tạo IV (vectơ khởi tạo) được điều chỉnh cho phù hợp.
  • Cờ emmc_optimized tương tự như inlinecrypt_optimized, nhưng cũng chọn một phương thức tạo IV giới hạn IV ở mức 32 bit. Bạn chỉ nên sử dụng cờ này trên phần cứng mã hoá cùng dòng tuân thủ thông số kỹ thuật JEDEC eMMC phiên bản 5.2, do đó chỉ hỗ trợ IV 32 bit. Trên phần cứng mã hoá cùng dòng khác, hãy sử dụng inlinecrypt_optimized. Bạn không bao giờ được sử dụng cờ này trên bộ nhớ dựa trên UFS; thông số kỹ thuật của UFS cho phép sử dụng IV 64 bit.
  • Trên các thiết bị hỗ trợ khoá mã hoá cùng dòng được bọc bằng phần cứng, bạn có thể bọc khoá FBE bằng phần cứng bằng cách thêm cờ wrappedkey hoặc wrappedkey_v0. wrappedkey là phiên bản hiện đại; bạn chỉ nên sử dụng wrappedkey_v0 trên các thiết bị không hỗ trợ wrappedkey hoặc đã chạy wrappedkey_v0. Để biết thêm thông tin, hãy xem bài viết Bật khoá được gói.
  • Cờ dusize_4k buộc kích thước đơn vị dữ liệu mã hoá phải là 4096 byte ngay cả khi kích thước khối hệ thống tệp không phải là 4096 byte. Kích thước đơn vị dữ liệu mã hoá là mức độ chi tiết của việc mã hoá nội dung tệp. Cờ này có từ Android 15. Bạn chỉ nên dùng cờ này để bật tính năng mã hoá cùng dòng bằng phần cứng không hỗ trợ đơn vị dữ liệu lớn hơn 4.096 byte, trên thiết bị sử dụng kích thước trang lớn hơn 4.096 byte và sử dụng hệ thống tệp f2fs.

Nếu bạn không sử dụng phần cứng mã hoá cùng dòng, thì chế độ cài đặt nên dùng cho hầu hết các thiết bị là fileencryption=aes-256-xts. Nếu bạn đang sử dụng phần cứng mã hoá cùng dòng, thì chế độ cài đặt được đề xuất cho hầu hết các thiết bị là fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (hoặc tương đương fileencryption=::inlinecrypt_optimized). Trên các thiết bị không có bất kỳ hình thức tăng tốc AES nào, bạn có thể sử dụng Adiantum thay cho AES bằng cách đặt fileencryption=adiantum.

Kể từ Android 14, AES-HCTR2 là chế độ mã hoá tên tệp ưu tiên cho các thiết bị có lệnh mật mã học tăng tốc. Tuy nhiên, chỉ các nhân Android mới hơn mới hỗ trợ AES-HCTR2. Trong một bản phát hành Android trong tương lai, chế độ này dự kiến sẽ trở thành chế độ mặc định để mã hoá tên tệp. Nếu nhân hệ điều hành của bạn hỗ trợ AES-HCTR2, thì bạn có thể bật tính năng này để mã hoá tên tệp bằng cách đặt filenames_encryption_mode thành aes-256-hctr2. Trong trường hợp đơn giản nhất, việc này sẽ được thực hiện bằng fileencryption=aes-256-xts:aes-256-hctr2.

Trên các thiết bị chạy Android 10 trở xuống, fileencryption=ice cũng được chấp nhận để chỉ định việc sử dụng chế độ mã hoá nội dung tệp FSCRYPT_MODE_PRIVATE. Chế độ này không được các nhân Android phổ biến triển khai, nhưng có thể được các nhà cung cấp triển khai bằng cách sử dụng các bản vá nhân tuỳ chỉnh. Định dạng trên ổ đĩa do chế độ này tạo ra là định dạng dành riêng cho nhà cung cấp. Trên các thiết bị chạy Android 11 trở lên, chế độ này không còn được cho phép và bạn phải sử dụng định dạng mã hoá tiêu chuẩn.

Theo mặc định, việc mã hoá nội dung tệp được thực hiện bằng API mật mã của nhân hệ điều hành Linux. Nếu bạn muốn sử dụng phần cứng mã hoá cùng dòng, hãy thêm tuỳ chọn gắn inlinecrypt. Ví dụ: một dòng fstab đầy đủ có thể có dạng như sau:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Bộ nhớ thích ứng

Kể từ Android 9, bạn có thể sử dụng đồng thời FBE và bộ nhớ thích ứng.

Việc chỉ định tuỳ chọn fstab fileencryption cho userdata cũng tự động bật cả FBE và mã hoá siêu dữ liệu trên bộ nhớ thích ứng. Tuy nhiên, bạn có thể ghi đè định dạng mã hoá siêu dữ liệu hoặc FBE trên bộ nhớ thích ứng bằng cách đặt các thuộc tính trong PRODUCT_PROPERTY_OVERRIDES.

Trên các thiết bị chạy Android 11 trở lên, hãy sử dụng các thuộc tính sau:

• ro.crypto.volume.options (mới trong Android 11) chọn định dạng mã hoá FBE trên bộ nhớ thích ứng. Tệp này có cú pháp giống như đối số cho tuỳ chọn fileencryption fstab và sử dụng cùng một giá trị mặc định. Hãy xem các đề xuất cho fileencryption ở trên để biết nên sử dụng gì ở đây.
• ro.crypto.volume.metadata.encryption chọn định dạng mã hoá siêu dữ liệu trên bộ nhớ thích ứng. Hãy xem tài liệu về việc mã hoá siêu dữ liệu.

Trên các thiết bị chạy Android 10 trở xuống, hãy sử dụng các thuộc tính sau:

• ro.crypto.volume.contents_mode chọn chế độ mã hoá nội dung. Trường này tương đương với trường đầu tiên được phân tách bằng dấu hai chấm của ro.crypto.volume.options.
• ro.crypto.volume.filenames_mode chọn chế độ mã hoá tên tệp. Trường này tương đương với trường thứ hai được phân tách bằng dấu hai chấm của ro.crypto.volume.options, ngoại trừ việc giá trị mặc định trên các thiết bị chạy Android 10 trở xuống là aes-256-heh. Trên hầu hết các thiết bị, bạn cần ghi đè rõ ràng giá trị này thành aes-256-cts.
• ro.crypto.fde_algorithm và ro.crypto.fde_sector_size chọn định dạng mã hoá siêu dữ liệu trên bộ nhớ thích ứng. Hãy xem tài liệu về việc mã hoá siêu dữ liệu.

Tích hợp với KeyMint

Bạn nên khởi động KeyMint HAL trong lớp early_hal. Điều này là do FBE yêu cầu KeyMint phải sẵn sàng xử lý các yêu cầu theo giai đoạn khởi động post-fs-data, tức là khi vold thiết lập các khoá ban đầu.

Loại trừ thư mục

init áp dụng khoá DE hệ thống cho tất cả thư mục cấp cao nhất của /data, ngoại trừ các thư mục không được mã hoá, chẳng hạn như thư mục chứa chính khoá DE hệ thống và các thư mục chứa thư mục CE hoặc DE của người dùng. Khoá mã hoá được áp dụng đệ quy và không thể bị ghi đè bởi các thư mục con.

Trong Android 11 trở lên, khoá mà init áp dụng cho các thư mục có thể được kiểm soát bằng đối số encryption=<action> cho lệnh mkdir trong tập lệnh khởi động. Các giá trị có thể có của <action> được ghi lại trong README cho ngôn ngữ khởi động Android.

Trong Android 10, các thao tác mã hoá init được cố định giá trị trong mã ở vị trí sau:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Trong Android 9 trở xuống, vị trí là:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Bạn có thể thêm các trường hợp ngoại lệ để ngăn một số thư mục nhất định bị mã hoá. Nếu thực hiện các sửa đổi thuộc loại này, thì nhà sản xuất thiết bị phải đưa vào chính sách SELinux chỉ cấp quyền truy cập cho những ứng dụng cần sử dụng thư mục không mã hoá. Thao tác này sẽ loại trừ tất cả ứng dụng không đáng tin cậy.

Trường hợp sử dụng duy nhất được chấp nhận cho việc này là để hỗ trợ các chức năng OTA cũ.

Hỗ trợ tính năng Khởi động trực tiếp trong các ứng dụng hệ thống

Giúp ứng dụng nhận biết chế độ Khởi động trực tiếp

Để hỗ trợ di chuyển nhanh các ứng dụng hệ thống, có hai thuộc tính mới có thể được đặt ở cấp ứng dụng. Thuộc tính defaultToDeviceProtectedStorage chỉ dành cho các ứng dụng hệ thống. Thuộc tính directBootAware dành cho tất cả mọi người.

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

Thuộc tính directBootAware ở cấp ứng dụng là cách viết tắt để đánh dấu tất cả thành phần trong ứng dụng là có khả năng nhận biết quá trình mã hoá.

Thuộc tính defaultToDeviceProtectedStorage chuyển hướng vị trí lưu trữ ứng dụng mặc định để trỏ đến bộ nhớ DE thay vì trỏ đến bộ nhớ CE. Các ứng dụng hệ thống sử dụng cờ này phải kiểm tra kỹ lưỡng tất cả dữ liệu được lưu trữ ở vị trí mặc định, đồng thời thay đổi đường dẫn của dữ liệu nhạy cảm để sử dụng bộ nhớ CE. Nhà sản xuất thiết bị sử dụng lựa chọn này nên kiểm tra kỹ dữ liệu mà họ đang lưu trữ để đảm bảo dữ liệu đó không chứa thông tin cá nhân.

Khi chạy ở chế độ này, bạn có thể sử dụng các API hệ thống sau để quản lý rõ ràng một Ngữ cảnh được bộ nhớ CE hỗ trợ khi cần, tương đương với các API được thiết bị bảo vệ.

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

Hỗ trợ nhiều người dùng

Mỗi người dùng trong môi trường nhiều người dùng sẽ nhận được một khoá mã hoá riêng. Mỗi người dùng đều có hai khoá: khoá DE và khoá CE. Người dùng 0 phải đăng nhập vào thiết bị trước vì đây là người dùng đặc biệt. Điều này phù hợp với việc sử dụng Quản trị thiết bị.

Ứng dụng nhận biết tiền mã hoá tương tác giữa người dùng theo cách sau: INTERACT_ACROSS_USERS và INTERACT_ACROSS_USERS_FULL cho phép một ứng dụng hoạt động trên tất cả người dùng trên thiết bị. Tuy nhiên, các ứng dụng đó chỉ có thể truy cập vào các thư mục được mã hoá bằng CE cho những người dùng đã được mở khoá.

Một ứng dụng có thể tương tác tự do trên các vùng DE, nhưng việc một người dùng mở khoá không có nghĩa là tất cả người dùng trên thiết bị đều được mở khoá. Ứng dụng nên kiểm tra trạng thái này trước khi cố gắng truy cập vào các khu vực này.

Mỗi mã nhận dạng người dùng trong hồ sơ công việc cũng nhận được hai khoá: DE và CE. Khi phương thức xác thực công việc được đáp ứng, người dùng hồ sơ sẽ được mở khoá và KeyMint (trong TEE) có thể cung cấp khoá TEE của hồ sơ.

Xử lý thông tin cập nhật

Phân vùng khôi phục không thể truy cập vào bộ nhớ được bảo vệ bằng DE trên phân vùng dữ liệu người dùng. Bạn nên hỗ trợ OTA bằng bản cập nhật hệ thống A/B cho các thiết bị triển khai FBE. Vì OTA có thể được áp dụng trong quá trình hoạt động bình thường, nên bạn không cần khôi phục để truy cập vào dữ liệu trên ổ đĩa đã mã hoá.

Khi sử dụng giải pháp OTA cũ, cần có chế độ khôi phục để truy cập vào tệp OTA trên phân vùng userdata:

1. Tạo thư mục cấp cao nhất (ví dụ: misc_ne) trong phân vùng userdata.
2. Định cấu hình thư mục cấp cao nhất này để không mã hoá (xem phần Loại trừ thư mục).
3. Tạo một thư mục trong thư mục cấp cao nhất để lưu giữ các gói OTA.
4. Thêm quy tắc SELinux và bối cảnh tệp để kiểm soát quyền truy cập vào thư mục này và nội dung của thư mục. Chỉ quy trình hoặc ứng dụng nhận bản cập nhật qua mạng không dây mới có thể đọc và ghi vào thư mục này. Không có ứng dụng hoặc quy trình nào khác có quyền truy cập vào thư mục này.

Xác nhận kết quả

Để đảm bảo phiên bản đã triển khai của tính năng hoạt động như dự kiến, trước tiên, hãy chạy nhiều chương trình kiểm thử mã hoá CTS, chẳng hạn như DirectBootHostTest và EncryptionTest.

Nếu thiết bị đang chạy Android 11 trở lên, hãy chạy cả vts_kernel_encryption_test:

atest vts_kernel_encryption_test

hoặc:

vts-tradefed run vts -m vts_kernel_encryption_test

Ngoài ra, nhà sản xuất thiết bị có thể thực hiện các quy trình kiểm thử thủ công sau đây. Trên một thiết bị đã bật FBE:

• Kiểm tra để đảm bảo ro.crypto.state tồn tại
  • Đảm bảo ro.crypto.state được mã hoá
• Kiểm tra để đảm bảo ro.crypto.type tồn tại
  • Đảm bảo ro.crypto.type được đặt thành file

Ngoài ra, người kiểm thử có thể xác minh rằng bộ nhớ CE đã bị khoá trước khi thiết bị được mở khoá lần đầu tiên kể từ khi khởi động. Để thực hiện việc này, hãy sử dụng bản dựng userdebug hoặc eng, đặt mã PIN, hình mở khoá hoặc mật khẩu cho người dùng chính rồi khởi động lại thiết bị. Trước khi mở khoá thiết bị, hãy chạy lệnh sau để kiểm tra bộ nhớ CE của người dùng chính. Nếu thiết bị sử dụng Chế độ người dùng hệ thống không có giao diện người dùng (hầu hết các thiết bị Ô tô), thì người dùng chính là người dùng 10, vì vậy, hãy chạy:

adb root; adb shell ls /data/user/10

Trên các thiết bị khác (hầu hết các thiết bị không phải Automotive), người dùng chính là người dùng 0, vì vậy, hãy chạy:

adb root; adb shell ls /data/user/0

Xác minh rằng tên tệp được liệt kê được mã hoá Base64, cho biết rằng tên tệp được mã hoá và khoá để giải mã tên tệp chưa có sẵn. Nếu tên tệp được liệt kê dưới dạng văn bản thuần tuý, thì tức là đã xảy ra lỗi.

Nhà sản xuất thiết bị cũng nên khám phá việc chạy các thử nghiệm Linux ngược dòng cho fscrypt trên thiết bị hoặc hạt nhân của họ. Các thử nghiệm này là một phần của bộ kiểm thử hệ thống tệp xfstests. Tuy nhiên, các thử nghiệm ngược dòng này không được Android hỗ trợ chính thức.

Thông tin chi tiết về việc triển khai AOSP

Phần này cung cấp thông tin chi tiết về cách triển khai AOSP và mô tả cách hoạt động của tính năng mã hoá dựa trên tệp. Nhà sản xuất thiết bị không cần phải thực hiện bất kỳ thay đổi nào tại đây để sử dụng FBE và tính năng Khởi động trực tiếp trên thiết bị của họ.

mã hoá fscrypt

Cách triển khai AOSP sử dụng phương thức mã hoá "fscrypt" (được ext4 và f2fs hỗ trợ) trong hạt nhân và thường được định cấu hình để:

• Mã hoá nội dung tệp bằng AES-256 ở chế độ XTS
• Mã hoá tên tệp bằng AES-256 ở chế độ CBC-CTS

Mã hoá Adiantum cũng được hỗ trợ. Khi bạn bật tính năng mã hoá Adiantum, cả nội dung và tên tệp đều được mã hoá bằng Adiantum.

fscrypt hỗ trợ hai phiên bản chính sách mã hoá: phiên bản 1 và phiên bản 2. Phiên bản 1 không còn được dùng nữa và các yêu cầu của CDD đối với thiết bị chạy Android 11 trở lên chỉ tương thích với phiên bản 2. Chính sách mã hoá phiên bản 2 sử dụng HKDF-SHA512 để lấy khoá mã hoá thực tế từ khoá do không gian người dùng cung cấp.

Để biết thêm thông tin về fscrypt, hãy xem tài liệu về nhân ngược dòng.

Lớp lưu trữ

Bảng sau đây liệt kê chi tiết hơn về các khoá FBE và thư mục mà các khoá này bảo vệ:

Lưu trữ và bảo vệ khoá

Tất cả khoá FBE đều do vold quản lý và được lưu trữ dưới dạng mã hoá trên ổ đĩa, ngoại trừ khoá cho mỗi lần khởi động không được lưu trữ. Bảng sau đây liệt kê các vị trí lưu trữ nhiều khoá FBE:

Như trong bảng trước, hầu hết các khoá FBE đều được lưu trữ trong các thư mục được mã hoá bằng một khoá FBE khác. Không thể mở khoá các khoá cho đến khi lớp lưu trữ chứa các khoá đó được mở khoá.

vold cũng áp dụng một lớp mã hoá cho tất cả khoá FBE. Mọi khoá ngoài khoá CE cho bộ nhớ trong đều được mã hoá bằng AES-256-GCM bằng khoá Kho khoá riêng không được hiển thị bên ngoài TEE. Điều này đảm bảo rằng các khoá FBE không thể mở khoá trừ phi hệ điều hành đáng tin cậy đã khởi động, theo quy định của tính năng Xác minh quy trình khởi động. Khả năng chống khôi phục cũng được yêu cầu trên khoá Keystore, cho phép xoá khoá FBE một cách an toàn trên các thiết bị mà KeyMint hỗ trợ khả năng chống khôi phục. Để dự phòng trong trường hợp không có khả năng chống khôi phục, hàm băm SHA-512 của 16384 byte ngẫu nhiên được lưu trữ trong tệp secdiscardable lưu trữ cùng với khoá sẽ được dùng làm Tag::APPLICATION_ID của khoá Keystore. Bạn cần khôi phục tất cả các byte này để khôi phục khoá FBE.

Khoá CE cho bộ nhớ trong được bảo vệ ở mức độ mạnh hơn để đảm bảo không thể mở khoá nếu không biết Yếu tố kiến thức về màn hình khoá (LSKF) của người dùng (mã PIN, hình mở khoá hoặc mật khẩu), mã thông báo đặt lại mật mã an toàn hoặc cả khoá phía máy khách và phía máy chủ cho thao tác Tiếp tục khi khởi động lại. Bạn chỉ được phép tạo mã thông báo đặt lại mật mã cho hồ sơ công việc và thiết bị được quản lý hoàn toàn.

Để đạt được điều này, vold mã hoá từng khoá CE cho bộ nhớ trong bằng khoá AES-256-GCM bắt nguồn từ mật khẩu tổng hợp của người dùng. Mật khẩu tổng hợp là một mật khẩu mã hoá có độ hỗn loạn cao, không thể thay đổi và được tạo ngẫu nhiên cho mỗi người dùng. LockSettingsService trong system_server quản lý mật khẩu tổng hợp và các cách bảo vệ mật khẩu đó.

Để bảo vệ mật khẩu tổng hợp bằng LSKF, trước tiên, LockSettingsService sẽ kéo dài LSKF bằng cách truyền mật khẩu đó qua scrypt, nhắm đến thời gian khoảng 25 mili giây và mức sử dụng bộ nhớ khoảng 2 MiB. Vì LSKF thường ngắn nên bước này thường không mang lại nhiều tính bảo mật. Lớp bảo mật chính là Phần tử bảo mật (SE) hoặc giới hạn tốc độ do TEE thực thi được mô tả dưới đây.

Nếu thiết bị triển khai Weaver HAL, thì LockSettingsService sẽ liên kết LSKF kéo dài với một bí mật ngẫu nhiên có entropy cao được lưu trữ trong SE hoặc TEE bằng Weaver. Sau đó, LockSettingsService sẽ mã hoá mật khẩu tổng hợp hai lần: lần đầu tiên bằng khoá phần mềm bắt nguồn từ LSKF kéo dài và bí mật Weaver, và lần thứ hai bằng khoá Kho khoá không liên kết với xác thực. Điều này giúp SE hoặc TEE thực thi giới hạn số lần đoán LSKF.

Nếu thiết bị không triển khai Weaver, thì LockSettingsService sẽ sử dụng LSKF kéo dài làm mật khẩu Gatekeeper. Sau đó, LockSettingsService sẽ mã hoá mật khẩu tổng hợp hai lần: lần đầu tiên bằng khoá phần mềm bắt nguồn từ LSKF kéo dài và hàm băm của tệp secdiscardable, lần thứ hai bằng khoá Kho khoá được liên kết xác thực với quy trình đăng ký Gatekeeper. Điều này giúp giới hạn số lần đoán LSKF theo quy định của TEE.

Khi LSKF thay đổi, LockSettingsService sẽ xoá tất cả thông tin liên quan đến việc liên kết mật khẩu tổng hợp với LSKF cũ. Trên các thiết bị hỗ trợ Weaver hoặc khoá Keystore có khả năng chống khôi phục về phiên bản cũ, việc này đảm bảo xoá an toàn liên kết cũ. Vì lý do này, các biện pháp bảo vệ được mô tả ở đây sẽ được áp dụng ngay cả khi người dùng không có LSKF.