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

Android 7.0 trở lên hỗ trợ phương thức 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á một cách độ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 cũng như cách các ứng dụng hệ thống có thể sử dụng Direct Boot API để cung cấp cho người dùng trải nghiệm tốt nhất, bảo mật nhất có thể.

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

Với sự ra mắt của phương thức mã hoá dựa trên tệp (FBE) và các API mới giúp các ứng dụng này nhận biết được mã hoá, các ứng dụng này có thể hoạt động trong một ngữ cảnh giới hạn. Điều này có thể xảy ra trước khi người dùng cung cấp 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ữ có sẵn cho các ứng dụng:

• Bộ nhớ được mã hoá thông tin xác thực (CE) là vị trí lưu trữ mặc định và chỉ dùng được sau khi người dùng mở khoá thiết bị.
• Bộ nhớ được mã hoá theo 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 có nhiều hồ sơ công việc người dùng cần được bảo vệ tại thời điểm này do việc mã hoá không còn chỉ dựa trên mật khẩu thời gian khởi động.

Direct Boot API cho phép các ứng dụng nhận biết được mã hoá truy cập vào từng nền tảng ngoại tuyến. Vòng đời của ứng dụng cần được thay đổi để đá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 lần đầu nhập thông tin đăng nhập trên màn hình khoá hoặc trong trường hợp có hồ sơ công việc cung cấp một cơ quan thử thách. Các thiết bị chạy Android 7.0 phải hỗ trợ các API và bất kể chúng có triển khai FBE hay không. Mặc dù, không có Bộ nhớ FBE, DE và CE sẽ luôn ở trạng thái mở khoá.

Triển khai hoàn chỉnh phương thức mã hoá dựa trên tệp trên tệp Ext4 và F2FS được cung cấp trong Dự án nguồn mở Android (AOSP) và chỉ cần được bật 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ể muốn khám phá các cách tối ưu hoá tính năng 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 được tính năng khởi động trực tiếp. Tuy nhiên, khi nhà sản xuất thiết bị sử dụng các phiên bản tuỳ chỉnh của những ứng dụng này, họ sẽ muốn đảm bảo ở mức tối thiểu 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 phương thức triển khai tham chiếu của phương thức mã hoá dựa trên tệp, trong đó phiên bản cũ (system/vold) cung cấp chức năng quản lý thiết bị lưu trữ và âm lượng trên Android. Việc thêm 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 ra về những thay đổi chính để sử dụng giải pháp dựa trên tệp khả năng mã hoá trong 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ợ FBE và Direct Các tính năng khởi động. Những quốc gia/khu vực này bao gồm:

• Trình quay số AOSP (gói/ứng dụng/Trình quay số)
• Đồng hồ bàn (gói/ứng dụng/DeskWatch)
• LatinIME (gói/phương thức nhập/LatinIME)*
• Ứng dụng Cài đặt (gói/ứng dụng/Cài đặt)*
• SystemUI (khung/cơ sở/gói/SystemUI)*

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

Ví dụ khác về các ứng dụng và dịch vụ có khả năng nhận biết quá trình mã hoá có thể là tìm thấy bằng cách chạy lệnh mangrep directBootAware trong thư mục khung hoặc gói của AOSP (Dự án nguồn mở Android) cây nguồn.

Phần phụ thuộc

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

• Hỗ trợ kernel để mã hoá Ext4 hoặc mã hoá F2FS.
• Keymaster Hỗ trợ bằng HAL phiên bản 1.0 trở lên. Không có hỗ trợ cho Keymaster 0.3 vì không cung cấp các tính năng cần thiết hoặc đảm bảo đủ khả năng bảo vệ cho khoá mã hoá.
• Keymaster/Kho khoá và Trình giữ cổng phải được triển khai trong một quy trình Thực thi đáng tin cậy Môi trường (TEE) để cung cấp tính năng bảo vệ cho các khoá DE sao cho hệ điều hành trái phép (hệ điều hành tuỳ chỉnh được cài đặt ROM trên thiết bị) không thể chỉ yêu cầu Khoá DE.
• Hardware Root of Trust (Nguồn gốc phần cứng đáng tin cậy) và Xác minh quy trình khởi động liên kết với quá trình khởi chạy Keymaster để đảm bảo các khoá DE không có thể truy cập bởi hệ điều hành chưa được cấp phép.

Triển khai

Đầu tiên và quan trọng nhất là 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ạo android:directBootAware theo lệnh Direct Khởi động tài liệu dành cho nhà phát triển.

Hỗ trợ kernel

Hỗ trợ hạt nhân cho mã hoá Ext4 và F2FS có trong Android chung nhân hệ điều hành, phiên bản 3.18 trở lên. Cách bật tính năng này trong nhân hệ điều hành phiên bản 5.1 hoặc cao hơn, hãy sử dụng:

CONFIG_FS_ENCRYPTION=y

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

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

Ngoài hỗ trợ chức năng cho mã hoá Ext4 hoặc F2FS, thiết bị thì nhà sản xuất cũng nên bật tính năng tăng tốc bằng mật mã để 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ụ: bật Các thiết bị dựa trên ARM64, có thể tăng tốc ARMv8 CE (Tiện ích mã hoá) bật bằng cách đặt các tuỳ chọn cấu hình nhân sau đây:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Để nâng cao hiệu suất hơn nữa và giảm mức sử dụng điện năng, nhà sản xuất thiết bị có thể cũng cân nhắc việc triển khai phần cứng mã hoá nội tuyến, mã hoá/giải mã dữ liệu trong quá trình truyền đến/từ thiết bị lưu trữ. Các nhân phổ biến của Android (phiên bản 4.14 trở lên) chứa một khung cho phép sử dụng phương thức mã hoá cùng dòng khi phần cứng và dịch vụ hỗ trợ trình điều khiển của nhà cung cấp sẵn có. 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 nhân sau đây:

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, bạn cũng hãy bật:

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 FBE trên bộ nhớ trong (userdata). Thao tác này cũng tự động bật FBE trên bộ nhớ; tuy nhiên, định dạng mã hoá trên bộ nhớ áp dụng có thể bị ghi đè nếu cần.

Bộ nhớ trong

FBE được bật bằng cách thêm lựa 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á nội bộ bộ nhớ. Tệp này chứa tối đa 3 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ậ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 trường 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ật mã được sử dụng để mã hoá tên tệp. 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 gửi đến 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ự. Sau đây là các cờ được hỗ trợ:
  • Cờ v1 chọn các chính sách mã hoá phiên bản 1; thời gian Cờ v2 chọn chính sách mã hoá phiên bản 2. Phiên bản 2 chính sách mã hoá sử dụng chức năng 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 trên Android 11 trở lên (như được xác định bởi ro.product.first_api_level) hoặc v1 nếu thiết bị chạy trên Android 10 hoặc thấp hơn.
  • Cờ inlinecrypt_optimized chọn một phương thức mã hoá được tối ưu hóa cho phần cứng mã hóa cùng dòng không xử lý hiệu quả số lượng lớn phím. Quá trình này thực hiện điều này bằng cách lấy chỉ một khoá mã hoá nội dung tệp cho mỗi khoá CE hoặc DE, thay vì một thông số cho mỗi tệp. Việc tạo IV (vectơ khởi tạo) là được điều chỉnh cho phù hợp.
  • Cờ emmc_optimized tương tự như inlinecrypt_optimized, nhưng đồng thời cũng chọn IV để giới hạn IV ở 32 bit. Cờ này chỉ để sử dụng trên phần cứng mã hoá cùng dòng tuân thủ Thông số kỹ thuật JEDEC eMMC v5.2 nên chỉ hỗ trợ phiên bản 32 bit IV. Trên các phần cứng mã hoá cùng dòng khác, hãy sử dụng Hãy inlinecrypt_optimized. Cờ này không bao giờ được được sử dụng 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ợ có bao bọc phần cứng , cờ wrappedkey_v0 cho phép sử dụng phím bọc phần cứng cho FBE. Chỉ có thể sử dụng kết hợp các tính năng này với tuỳ chọn gắn kết inlinecrypt và inlinecrypt_optimized hoặc emmc_optimized cờ.
  • Cờ dusize_4k buộc kích thước đơn vị dữ liệu mã hoá 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à độ chi tiết của tệp mã hoá nội dung. Cờ này có từ Android 15 (thử nghiệm AOSP). Bạn chỉ nên sử dụng cờ này để bật việc sử dụng phần cứng mã hoá cùng dòng không hỗ trợ dữ liệu các đơn vị lớn hơn 4096 byte trên 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á cùng dòng, chế độ cài đặt được đề xuất cho hầu hết thiết bị là fileencryption=aes-256-xts. Nếu bạn đang sử dụng cùng dòng 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). Bật các thiết bị không có bất kỳ dạng tăng tốc AES nào, thì Adiantum có thể được dùng thay cho AES bằng cách cài đặt fileencryption=adiantum.

Kể từ Android 14, AES-HCTR2 là chế độ mã hoá tên tệp được ưu tiên cho các thiết bị có hướng dẫn 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 được lên kế hoạch trở thành chế độ mặc định cho tên tệp mã hoá. Nếu nhân hệ điều hành của bạn có hỗ trợ AES-HCTR2, thì bạn có thể bật chế độ 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 với 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 là chưa được các nhân phổ biến của Android triển khai, nhưng nó có thể được triển khai bằng bằng cách sử dụng bản vá nhân hệ điều hành tuỳ chỉnh. Định dạng trên ổ đĩa do chế độ này tạo ra là dành riêng cho từng 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 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 nhân hệ điều hành Linux mật mã học. Nếu muốn sử dụng phần cứng mã hoá cùng dòng, hãy thêm tuỳ chọn gắn kết inlinecrypt. Ví dụ: bản đầy đủ Dòng fstab 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ớ tích hợp

Kể từ Android 9, FBE và bộ nhớ tối đa có thể được sử dụng cùng nhau.

Chỉ định tuỳ chọn thẻ fstab fileencryption cho userdata cũng tự động bật cả FBE và mã hoá siêu dữ liệu trên dữ liệu có thể áp dụng bộ nhớ. Tuy nhiên, bạn có thể ghi đè FBE và/hoặc định dạng mã hoá siêu dữ liệu trên bộ nhớ có thể áp dụ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 (tính năng mới trong Android 11) chọn định dạng mã hoá FBE trên bộ nhớ thích ứng. Hàm này có cú pháp giống như đối số cho Tuỳ chọn fstab fileencryption và sử dụng cùng một giá trị mặc định. Xem các đề xuất cho fileencryption ở trên để biết những việc cần làm sử dụng tại đây.
• ro.crypto.volume.metadata.encryption chọn siêu dữ liệu trên bộ nhớ có thể sử dụng. Xem siêu dữ liệu tài liệu mã hoá.

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 nội dung chế độ mã hoá. Điều 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 tên tệp chế độ mã hoá. Điều 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ừ chế độ mặc định trên các thiết bị được phát hành cùng với Android 10 trở xuống aes-256-heh Trên hầu hết các thiết bị, bạn cần nêu rõ điều này bị ghi đè thành aes-256-cts.
• ro.crypto.fde_algorithm và ro.crypto.fde_sector_size chọn phương thức mã hoá siêu dữ liệu trên bộ nhớ thích hợp. Xem siêu dữ liệu tài liệu mã hoá.

Tích hợp với Keymaster

Lớp HAL Keymaster phải được khởi động như một phần của lớp early_hal. Lý do là 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, 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 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 theo cách đệ quy và không thể bị thư mục con ghi đè.

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

Trên Android 10, các hành động 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í là:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Bạn có thể thêm trường hợp ngoại lệ để ngăn một số thư mục nhất định bị được mã hoá hoàn toàn. Nếu bạn sửa đổi kiểu này thì thiết bị nhà sản xuất nên bao gồm Các chính sách SELinux chỉ cấp quyền truy cập vào các ứng dụng cần sử dụng thư mục chưa mã hoá. Điều 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 được chấp nhận duy nhất đã biết cho trường hợp này là hỗ trợ OTA cũ các chức năng khác nhau.

Hỗ trợ Direct Boot trong các ứng dụng hệ thống

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

Có hai thuộc tính mới giúp di chuyển nhanh các ứng dụng hệ thống có thể được thiết lập ở cấp ứng dụng. Chiến lược phát hành đĩa đơn Thuộc tính defaultToDeviceProtectedStorage chỉ dành cho ứng dụng hệ thống. Tất cả 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ả thành phần trong ứng dụng đều có khả năng nhận biết quá trình mã hoá.

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

Khi chạy ở chế độ này, các API Hệ thống sau đây có sẵn để quản lý rõ ràng Ngữ cảnh được bộ nhớ CE hỗ trợ khi cần. tương đương với các phiên bản Được bảo vệ của 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 nhận được hai khoá: một khoá DE và một khoá CE. Người dùng 0 phải đăng nhập vào thiết bị trước tiên một người dùng đặc biệt. Điều này phù hợp với Thiết bị Mục đích sử dụng Quản trị.

Các ứng dụng nhận biết 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 với tất cả người dùng trên thiết bị. Tuy nhiên, những việc đó thì ứng dụng chỉ có thể truy cập vào các thư mục được mã hoá CE đối với người dùng đã được mở khoá.

Một ứng dụng có thể tương tác tự do trên khắp các khu vực Đức, nhưng chỉ 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á. Chiến lược phát hành đĩa đơn ứng dụng sẽ 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 hồ sơ công việc cũng nhận được hai khoá: DE và CE. Khi thử thách công việc được đáp ứng, người dùng hồ 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 dữ liệu người dùng. Bạn nên sử dụng các thiết bị triển khai FBE để hỗ trợ OTA bằng cách sử dụng bản cập nhật hệ thống A/B. Như OTA có thể được áp dụng trong quá trình hoạt động bình thường, 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 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 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à 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 nó. Chỉ nên quy trình hoặc ứng dụng nhận bản cập nhật OTA có thể đọc và ghi vào thư mục này. Không có đơn đăng ký hoặc quy trình nào khác sẽ 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 bài kiểm tra mã hoá CTS, chẳng hạn như DirectBootHostTest và EncryptTest.

Nếu thiết bị đang chạy Android 11 trở lên, hãy chạy cả phiên bản 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 tra thủ công sau đây. Trên thiết bị đã bật FBE:

• Kiểm tra xem ro.crypto.state có tồn tại không
  • Đảm bảo ro.crypto.state đã được mã hoá
• Kiểm tra xem ro.crypto.type có tồn tại không
  • Đả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ó đượ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 của người dùng chính và khởi động lại thiết bị. Trước khi mở khoá thiết bị, 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 Hệ thống không có giao diện người dùng Chế độ người dùng (hầu hết thiết bị Automotive), 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 là thiết bị không dùng ô tô), người dùng chính là người dùng 0. Do đó, chạy:

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

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

Nhà sản xuất thiết bị cũng nên tìm hiểu cách chạy quy trình kiểm thử Linux ngược dòng cho fscrypt trên thiết bị của họ hoặc nhân hệ điều hành. 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, những kiểm thử 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 (Dự án nguồn mở Android)

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 thức phương thức mã hoá dựa trên tệp. Không cần thiết đối với nhà sản xuất thiết bị để thực hiện bất kỳ thay đổi nào ở đây để sử dụng FBE và Direct Boot trên thiết bị của họ.

mã hoá fscrypt

Phương thức triển khai AOSP sử dụng "fscrypt" mã hóa (được hỗ trợ bởi ext4 và f2fs) 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

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

fscrypt hỗ trợ hai phiên bản chính sách mã hóa: phiên bản 1 và phiên bản 2. Phiên bản 1 không được dùng nữa và các yêu cầu của CDD đối với các thiết bị chạy bằng 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ề kernel ngược dòng.

Lớp bộ nhớ

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

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

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

Như được trình bày trong bảng trước, hầu hết các 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á khoá khi chưa hết bộ nhớ lớp chứa các từ khoá đó đã được mở khoá.

vold cũng áp dụng một lớp mã hoá cho mọi khoá FBE. Mọi phím ngoài khoá CE cho bộ nhớ trong, được mã hoá bằng AES-256-GCM bằng chính mã Khóa Keystore (kho khoá) không được được hiển thị bên ngoài TEE. Điều này đảm bảo rằng các phím FBE sẽ không thể mở khoá được trừ phi hệ điều hành đáng tin cậy đã khởi động, như được thực thi bởi quy trình Xác minh quy trình khởi động. Khôi phục trở kháng cũng được yêu cầu trên khoá Kho khoá, khoá này cho phép các khoá FBE sẽ được xoá một cách an toàn trên các thiết bị mà Keymaster hỗ trợ tính năng chống khôi phục. Như phương pháp dự phòng nỗ lực tối đa khi không có khả năng chống khôi phục, SHA-512 hàm băm của 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 mã ứng dụng của khoá Kho khoá. Cần phải khôi phục tất cả các byte này để khôi phục phím FBE.

Khoá CE cho bộ nhớ trong có mức độ bảo vệ mạnh mẽ hơn để đảm bảo chúng không thể mở khoá nếu không biết Màn hình khoá của người dùng Yếu tố kiến thức (LSKF) (mã PIN, hình mở khoá hoặc mật khẩu), một bảo mật mã đặt lại mật mã hoặc cả khoá phía máy khách và khoá phía máy chủ để 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à hoàn toàn thiết bị được quản lý.

Để đạ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 lấy 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 bí mật mã hoá có độ entropy cao bất biến và được tạo ngẫu nhiên cho mỗi người dùng. LockSettingsService inch system_server quản lý mật khẩu tổng hợp và cách thức dữ liệu đó được bảo vệ.

Để bảo vệ mật khẩu tổng hợp bằng LSKF, Trước tiên, LockSettingsService mở rộng LSKF bằng cách truyền qua LSKF scrypt, nhắm mục tiêu trong khoảng thời gian khoảng 25 mili giây và thời gian 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 bảo mật. Lớp bảo mật chính là lớp Bảo mật Giới hạn tốc độ của phần tử (SE) hoặc do TEE thực thi như mô tả dưới đây.

Nếu thiết bị có một Phần tử bảo mật (SE), thì LockSettingsService ánh xạ LSKF kéo dài với bí mật ngẫu nhiên có entropy cao được lưu trữ trong SE bằng cách sử dụng HAL Weaver. LockSettingsService sau đó mã hoá mật khẩu tổng hợp hai lần: lần đầu tiên bằng một khoá phần mềm lấy từ kéo dài LSKF và bí mật Weaver, đồng thời thứ hai với Kho khoá không bị ràng buộc xác thực . Điều này giúp giới hạn tỷ lệ được thực thi bởi SE đối với các dự đoán LSKF.

Nếu thiết bị không có SE, thì hãy LockSettingsService sử dụng LSKF kéo dài làm Người trực điện thoại mật khẩu. Sau đó, LockSettingsService sẽ mã hoá mật khẩu tổng hợp hai lần: đầu tiên bằng một khoá phần mềm lấy từ LSKF kéo dài và hàm băm của một tệp có thể tách rời và thứ hai với một khoá Kho khoá được ràng buộc xác thực với Đăng ký người trực điện thoại. Điều này giúp giới hạn tỷ lệ được thực thi bởi TEE của các dự đoán LSKF.

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 mật khẩu cũ ứng dụng kém an toàn. Trên những thiết bị hỗ trợ khoá Weaver hoặc khoá Kho khoá chống khôi phục, tính năng 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ệ mô tả ở đây được áp dụng ngay cả khi người dùng không có LSKF.