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

Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Android 7.0 trở lên hỗ trợ tính năng mã hoá dựa trên tệp (FBE). Phương thức 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 các 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 bắt buộc 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 cho phép 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 đến 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 xác thực trước khi có thể truy cập vào bất kỳ dữ liệu nào, ngăn điện thoại thực hiện tất cả thao tác ngoại trừ các thao tác cơ bản nhất. Ví dụ: chuông báo không hoạt động, không có dịch vụ hỗ trợ tiếp cận và điện thoại không nhận được cuộc gọi mà chỉ có thể thực hiện các thao tác cơ bản của trình quay số khẩn cấp.

Với việc giới thiệu phương thức 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 phương thức mã hoá, các ứng dụng này có thể hoạt động trong một ngữ 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 xác thực, đồng thời 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 của 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 phân tách 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 vì quá trình mã hoá không còn chỉ dựa trên 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ó một số 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á để phản hồi việc nhập thông tin xác thực lần đầu tiên trên 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 phương thức triển khai đầy đủ 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 các nhà sản xuất thiết bị sử dụng các phiên bản tuỳ chỉnh của các ứng dụng này, họ muốn đảm bảo ít nhất có các gói nhận biết 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 để nhập mật khẩu vào màn hình khoá

Ví dụ và nguồn

Android cung cấp cách triển khai tham chiếu của phương thức mã hoá dựa trên tệp, trong đó vùng nhớ khối xếp (system/vold) cung cấp chức năng quản lý thiết bị lưu trữ và các phương tiện 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 khoá CE và DE của nhiều người dùng. Ngoài các thay đổi cốt lõi để sử dụng các tính năng mã hoá dựa trên tệp trong hạt nhân, nhiều gói hệ thống bao gồm 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. bao gồm:

• Trình quay số AOSP (packages/apps/Dialer)
• Đồng hồ để bàn (packages/apps/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ụ nhận biết được phương thức 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 cách 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 phương thức mã hoá Ext4 hoặc mã hoá F2FS.
• Hỗ trợ Keymaster với HAL phiên bản 1.0 trở lên. Không hỗ trợ Keymaster 0.3 vì phiên bản này không cung cấp các chức năng cần thiết hoặc đảm bảo bảo vệ đầy đủ cho các khoá mã hoá.
• Bạn phải triển khai Keymaster/Keystore và Gatekeeper trong Môi trường thực thi đáng tin cậy (TEE) để bảo vệ các khoá DE, nhờ đó, hệ điều hành trái phép (hệ điều hành tuỳ chỉnh được cài đặt trên thiết bị) không thể chỉ yêu cầu các khoá DE.
• Bạn phải liên kết Gốc tin cậy phần cứng và Xác minh quy trình khởi động với quá trình khởi chạy Keymaster để đảm bảo rằng hệ điều hành trái phép không thể truy cập vào 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à tính năng hỗ trợ tiếp cận phải được tạo android:directBootAware theo tài liệu dành cho nhà phát triển về tính năng Khởi động trực tiếp.

Hỗ trợ nhân

Hỗ trợ hạt nhân cho phương thức mã hoá Ext4 và F2FS có trong các hạt nhân phổ biến của Android, phiên bản 3.18 trở lên. Để bật tính năng này trong một hạt nhân phiên bản 5.1 trở lên, hãy sử dụng:

CONFIG_FS_ENCRYPTION=y

Đối với các hạt nhân cũ, 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ớ có thể sử dụng hoặc sử dụng mã hoá siêu dữ liệu trên bộ nhớ trong, hãy bật 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 cho phương thức 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 (Tiện ích mã hoá) 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, 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á nội tuyến. Phần cứng này sẽ mã hoá/giải mã dữ liệu trong khi dữ liệu đang chuyển đến/từ thiết bị lưu trữ. Hạt nhân chung của Android (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á nội tuyến 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á nội tuyến 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 thiết bị, bạn phải 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ớ có thể chuyển đổi; tuy nhiên, bạn có thể ghi đè định dạng mã hoá trên bộ nhớ có thể chuyển đổi nếu cần.

Bộ nhớ trong

Bạn có thể bật FBE 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. Tệp này chứa tối đa 3 tham số được phân tách bằng dấu hai chấm:

• Thông số contents_encryption_mode xác định thuật toán mật mã dùng để mã hoá nội dung tệp. Đó có thể là aes-256-xts hoặc adiantum. Kể từ Android 11, bạn cũng có thể để trống để 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ật mã 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, giá trị mặc định sẽ là aes-256-cts nếu contents_encryption_mode là aes-256-xts hoặc adiantum nếu contents_encryption_mode là adiantum.
• Tham số flags (mới trong Android 11) là một danh sách 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. Mặc định là phiên bản 2 nếu thiết bị chạy trên Android 11 trở lên (do ro.product.first_api_level xác định) hoặc phiên bản 1 nếu thiết bị chạy trên 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ả một lượng lớn khoá. Phương thức này 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. Quá trình 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á nội tuyến tuân thủ thông số kỹ thuật JEDEC eMMC v5.2 và do đó chỉ hỗ trợ IV 32 bit. Trên các 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 UFS cho phép sử dụng IV 64 bit.
  • Trên các thiết bị hỗ trợ khoá được gói bằng phần cứng, cờ wrappedkey_v0 cho phép sử dụng khoá được gói bằng phần cứng cho FBE. Bạn chỉ có thể sử dụng tính năng này kết hợp với tuỳ chọn gắn inlinecrypt và cờ inlinecrypt_optimized hoặc emmc_optimized.
  • 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 quá trình mã hoá nội dung tệp. Cờ này có từ Android 15. Bạn chỉ nên sử dụng cờ này để bật tính năng sử dụng phần cứng mã hoá nội tuyến không hỗ trợ các đơn vị dữ liệu lớn hơn 4096 byte, trên một thiết bị sử dụng kích thước trang lớn hơn 4096 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á nội tuyến, chế độ cài đặt được đề xuất 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á nội tuyến, 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 với 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 vì 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ó hướng dẫn mã hoá tăng tốc. Tuy nhiên, chỉ các hạt 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, phương thức này dự kiến sẽ trở thành chế độ mặc định để mã hoá tên tệp. Nếu hạt nhân của bạn có hỗ trợ AES-HCTR2, bạn có thể bật hạt nhân 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, bạn có thể thực hiện việc này 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 hạt nhân phổ biến của Android triển khai, nhưng các nhà cung cấp có thể triển khai chế độ này bằng cách sử dụng các bản vá hạt nhân tuỳ chỉnh. Định dạng trên ổ đĩa do chế độ này tạo ra là 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á chuẩn.

Theo mặc định, quá trình mã hoá nội dung tệp được thực hiện bằng API mã hoá của nhân Linux. Nếu bạn muốn sử dụng phần cứng mã hoá nội tuyến, hãy thêm tuỳ chọn gắn inlinecrypt. Ví dụ: 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 cùng lúc FBE và bộ nhớ có thể chuyển đổi.

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ớ có thể sử dụng. Tuy nhiên, bạn có thể ghi đè các định dạng mã hoá siêu dữ liệu hoặc FBE trên bộ nhớ có thể chuyển đổi 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ớ có thể chuyển đổi. Tệp này có cú pháp giống như đối số cho tuỳ chọn fstab fileencryption và sử dụng cùng các giá trị mặc định. Hãy xem các đề xuất cho fileencryption ở trên để biết nội dung cần sử dụng tại đây.
• ro.crypto.volume.metadata.encryption chọn định dạng mã hoá siêu dữ liệu trên bộ nhớ có thể chuyển đổi. 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. Giá trị 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. Giá trị 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ừ 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 thiết bị, bạn cần ghi đè giá trị này thành aes-256-cts một cách rõ ràng.
• 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ớ có thể chuyển đổi. Xem tài liệu về việc mã hoá siêu dữ liệu.

Tích hợp với Keymaster

Bạn nên bắt đầu Keymaster HAL trong lớp early_hal. Điều này là do FBE yêu cầu Keymaster 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 của 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 phải được mã hoá, chẳng hạn như thư mục chứa chính khoá DE của 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á á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 mã hoá cứng vào vị trí sau:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Trong Android 9 trở xuống, vị trí này 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 không được mã hoá. Nếu thực hiện các sửa đổi loại này, 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 các ứng dụng cần sử dụng thư mục chưa mã hoá. Thao tác này sẽ loại trừ tất cả cá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 tính 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ợ việc di chuyển nhanh các ứng dụng hệ thống, bạn có thể đặt hai thuộc tính mới ở cấp ứng dụng. Thuộc tính defaultToDeviceProtectedStorage chỉ dành cho các ứng dụng hệ thống. Mọi người đều có thể sử dụng thuộc tính directBootAware.

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

Thuộc tính directBootAware ở cấp ứng dụng là viết tắt để đánh dấu tất cả cá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 sẽ 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 và thay đổi đường dẫn của dữ liệu nhạy cảm để sử dụng bộ nhớ CE. Các nhà sản xuất thiết bị sử dụng tuỳ chọn này phải 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 đây để quản lý rõ ràng một Ngữ cảnh được lưu trữ trên bộ nhớ CE khi cần, tương đương với các API tương ứng được Bảo vệ thiết bị.

• 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 sẽ nhận được hai khoá: khoá DE và khoá CE. Trước tiên, Người dùng 0 phải đăng nhập vào thiết bị 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 lý thiết bị.

Các ứng dụng nhận biết được tiền mã hoá tương tác với người dùng theo cách sau: INTERACT_ACROSS_USERS và INTERACT_ACROSS_USERS_FULL cho phép ứng dụng hoạt động trên tất cả người dùng trên thiết bị. Tuy nhiên, những ứ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 khu vực DE, nhưng việc một người dùng được 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 đáp ứng được thử thách công việc, người dùng hồ sơ sẽ được mở khoá và Keymaster (trong TEE) có thể cung cấp khoá TEE của hồ sơ.

Xử lý nội dung 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 userdata. Các thiết bị triển khai FBE nên hỗ trợ OTA bằng cách sử dụng cập nhật hệ thống A/B. 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 dữ liệu trên ổ được mã hoá.

Khi sử dụng giải pháp OTA cũ, bạn cần 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 được 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 trữ các gói OTA.
4. Thêm quy tắc SELinux và ngữ 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 OTA 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 kiểm thử thủ công sau. 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 bạn đã đặt ro.crypto.type 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à chưa có khoá để giải mã. Nếu tên tệp được liệt kê ở dạng văn bản thuần tuý, thì có gì đó không ổn.

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

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 thực hiện 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

Quá trình triển khai AOSP sử dụng phương thức mã hoá "fscrypt" (do ext4 và f2fs hỗ trợ) trong 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

Công nghệ mã hoá Adiantum cũng được hỗ trợ. Khi bạn bật tính năng mã hoá Adiantum, cả nội dung tệp 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ừ các 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 cấp trên.

Lớp bộ nhớ

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

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á 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 khoá FBE được lưu trữ trong các thư mục được mã hoá bằng một khoá FBE khác. Bạn không thể mở khoá các khoá cho đến khi lớp bộ nhớ 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 trừ khoá CE cho bộ nhớ trong đều được mã hoá bằng AES-256-GCM bằng khoá Keystore (Kho khoá) riêng không hiển thị bên ngoài TEE. Điều này đảm bảo rằng không thể mở khoá các khoá FBE trừ phi hệ điều hành đáng tin cậy đã khởi động, như được thực thi bởi tính năng Khởi động được xác minh. Khả năng chống rollback cũng được yêu cầu trên khoá Kho khoá, cho phép xoá khoá FBE một cách an toàn trên các thiết bị mà Keymaster hỗ trợ khả năng chống rollback. Là phương án dự phòng tốt nhất khi không có khả năng chống rollback, hàm băm SHA-512 gồm 16384 byte ngẫu nhiên được lưu trữ trong tệp secdiscardable được lưu trữ cùng với khoá được dùng làm Tag::APPLICATION_ID của khoá Kho khoá. 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 độ cao hơn để đảm bảo rằng không thể mở khoá khoá này nếu không biết Hệ số kiến thức khoá màn hình (LSKF) (mã PIN, hình mở khoá hoặc mật khẩu) của người dùng, mã xác thực đặt lại mật khẩu 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 tạo mã đặ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 cách sử dụ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 khoá mật mã có độ hỗn loạn cao, không thể thay đổi đượ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 giãn LSKF bằng cách truyền 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à Thành phần bảo mật (SE) hoặc giới hạn tốc độ do TEE thực thi được mô tả bên dưới.

Nếu thiết bị có một Phần tử bảo mật (SE), thì LockSettingsService sẽ ánh xạ LSKF đã kéo giãn đến một bí mật ngẫu nhiên có độ hỗn loạn cao được lưu trữ trong SE bằng cách sử dụng Weaver HAL. Sau đó, LockSettingsService 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 được kéo giãn và khoá bí mật Weaver, 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 cung cấp giới hạn tốc độ do SE thực thi đối với các lần đoán LSKF.

Nếu thiết bị không có SE, thì LockSettingsService sẽ sử dụng LSKF đã kéo giãn làm mật khẩu Cổng bảo vệ. 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 được kéo giãn và hàm băm của tệp có thể loại bỏ sec, lần thứ hai bằng khoá Kho khoá được liên kết với xác thực để đăng ký Gatekeeper. Điều này cung cấp giới hạn tốc độ do TEE thực thi đối với các lần đoán LSKF.

Khi LSKF thay đổi, LockSettingsService sẽ xoá tất cả thông tin liên kết với 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á Kho khoá chống rollback, việc này đảm bảo xoá liên kết cũ một cách an toàn. 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.