Mã hóa dựa trên tệp

Android 7.0 trở lên hỗ trợ mã hóa dựa trên tệp (FBE). Mã hóa dựa trên tệp cho phép các tệp khác nhau được mã hóa bằng các khóa khác nhau có thể được mở khóa độc lập.

Bài viết này mô tả cách bật mã hóa 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 để cung cấp cho người dùng trải nghiệm tốt nhất, an toàn nhất có thể.

Tất cả các thiết bị khởi chạy với Android 10 trở lên đều phải sử dụng mã hóa dựa trên tệp.

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

Mã hóa 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 . Direct Boot cho phép các thiết bị được mã hóa khởi động thẳng vào màn hình khóa. Trước đây, trên các thiết bị được mã hóa sử dụng mã hóa 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 bất kỳ dữ liệu nào, ngăn không cho điện thoại thực hiện tất cả trừ những thao tác cơ bản nhất. Ví dụ: chuông báo không thể hoạt động, dịch vụ trợ năng không khả dụng và điện thoại không thể nhận cuộc gọi mà chỉ giới hạn ở các thao tác quay số khẩn cấp cơ bản.

Với việc giới thiệu mã hóa dựa trên tệp (FBE) và các API mới giúp các ứng dụng nhận biết mã hóa, 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 của họ trong khi vẫn bảo vệ thông tin cá nhân của người dùng.

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

• Bộ lưu trữ được mã hóa thông tin xác thực (CE), là vị trí lưu trữ mặc định và chỉ khả dụng sau khi người dùng đã mở khóa thiết bị.
• Bộ lưu trữ được mã hóa thiết bị (DE), là vị trí lưu trữ khả dụng cả trong chế độ Khởi động trực tiếp và sau khi người dùng đã mở khóa thiết bị.

Sự tách biệt này làm cho hồ sơ công việc trở nên an toàn hơn vì nó cho phép nhiều người dùng được bảo vệ cùng lúc vì mã hóa 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 nhận biết mã hóa truy cập 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ộ lưu trữ CE của người dùng được mở khóa để phản hồi lại lần đầu tiên nhập thông tin đăng nhập ở màn hình khóa hoặc trong trường hợp hồ sơ công việc đưa ra 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. Mặc dù, nếu không có FBE, bộ lưu trữ DE và CE sẽ luôn ở trạng thái mở khóa.

Việc triển khai hoàn chỉnh mã hóa dựa trên tệp trên hệ thống 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 hóa 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 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 tùy chỉnh của các ứ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 khóa

Ví dụ và nguồn

Android cung cấp triển khai mã hóa dựa trên tệp tham chiếu, trong đó vold ( system/vold ) cung cấp chức năng quản lý ổ đĩa và thiết bị lưu trữ 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ý khóa cho các khóa 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ã hóa dựa trên tệp trong nhân , nhiều gói hệ thống bao gồm màn hình khóa 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 các:

• Trình quay số AOSP (gói/ứng dụng/Trình quay số)
• Đồng hồ để bàn (gói/ứng dụng/DeskClock)
• LatinIME (gói/phương thức nhập/LatinIME)*
• Cài đặt Ứng dụng (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 thuộc tính tệp kê khai defaultToDeviceProtectedStorage

Có thể tìm thấy nhiều ví dụ khác về các ứng dụng và dịch vụ nhận biết mã hóa 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ụ thuộc

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

• Hạt nhân Hỗ trợ mã hóa Ext4 hoặc mã hóa F2FS.
• Hỗ trợ Keymaster với HAL phiên bản 1.0 trở lên. Không có hỗ trợ cho Keymaster 0.3 vì điều đó không cung cấp các khả năng cần thiết hoặc đảm bảo đủ khả năng bảo vệ cho các khóa mã hóa.
• Keymaster/ Keystore và Gatekeeper phải được triển khai trong Môi trường thực thi tin cậy (TEE) để cung cấp khả năng bảo vệ cho các khóa DE sao cho một hệ điều hành trái phép (hệ điều hành tùy chỉnh được cài đặt trên thiết bị) không thể yêu cầu các khóa DE một cách đơn giản.
• Root phần cứng đáng tin cậy và Khởi động được xác minh ràng buộc với khởi tạo Keymaster là bắt buộc để đảm bảo rằng các khóa DE không thể truy cập được bởi một hệ điều hành trái phép.

Thực hiện

Trước hết, các ứng dụng như đồng hồ báo thức, điện thoại và các tính năng trợ năng phải được tạo thành android:directBootAware theo tài liệu dành cho nhà phát triển Direct Boot .

hỗ trợ hạt nhân

Hỗ trợ hạt nhân cho mã hóa Ext4 và F2FS có sẵn trong các hạt nhân thông thường của Android, phiên bản 3.18 trở lên. Để kích hoạt nó trong kernel phiên bản 5.1 trở lên, hãy sử dụng:

CONFIG_FS_ENCRYPTION=y

Đối với các 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ớ có thể chấp nhận hoặc sẽ sử dụng mã hóa siêu dữ liệu trên bộ nhớ trong, hãy bật các tùy chọn cấu hình hạt nhân cần thiết để mã hóa siêu dữ liệu như được mô tả trong tài liệu mã hóa siêu dữ liệu .

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

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Để cải thiện hơn nữa hiệu suất và giảm mức sử dụng năng lượng, các nhà sản xuất thiết bị cũng có thể xem xét triển khai phần cứng mã hóa nội tuyến , giúp mã hóa/giải mã dữ liệu trong khi dữ liệu đang trên đường đến/từ thiết bị lưu trữ. Các nhân chung của Android (phiên bản 4.14 trở lên) chứa một khung cho phép mã hóa nội tuyến được sử dụng khi có hỗ trợ trình điều khiển của nhà cung cấp và phần cứng. Khung mã hóa nội tuyến có thể được bật bằng cách đặt các tùy chọn cấu hình kernel 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ộ lưu trữ 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

Kích hoạt mã hóa dựa trên tập tin

Kích hoạt FBE trên thiết bị yêu cầu kích hoạt nó trên bộ nhớ trong ( userdata ). Điều này cũng tự động kích hoạt FBE trên bộ nhớ có thể chấp nhận được; tuy nhiên, định dạng mã hóa trên bộ lưu trữ có thể chấp nhận có thể bị ghi đè nếu cần.

Lưu trữ nội bộ

FBE được kích hoạt bằng cách thêm tùy chọn fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] vào cột fs_mgr_flags của dòng fstab cho userdata . Tùy chọn này xác định định dạng mã hóa 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ã hóa nào được sử dụng để mã hóa nội dung tệp. Nó có thể là aes-256-xts hoặc adiantum . Kể từ Android 11, 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ã hóa nào được sử dụng để mã hóa tên tệp. Nó có thể là aes-256-cts , aes-256-heh , adiantum hoặc aes-256-hctr2 . Nếu không được chỉ định, nó sẽ mặc định là aes-256-cts contents_encryption_mode là aes-256-xts hoặc là adiantum 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ã hóa phiên bản 1; cờ v2 chọn chính sách mã hóa phiên bản 2. Chính sách mã hóa phiên bản 2 sử dụng chức năng dẫn xuất khóa linh hoạt và an toàn hơn. Giá trị mặc định là v2 nếu thiết bị khởi 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ị khởi chạy trên Android 10 trở xuống.
  • Cờ inlinecrypt_optimized chọn định dạng mã hóa được tối ưu hóa cho phần cứng mã hóa nội tuyến không xử lý hiệu quả số lượng lớn khóa. Nó thực hiện điều này bằng cách chỉ lấy một khóa mã hóa nội dung tệp cho mỗi khóa CE hoặc DE, thay vì một khóa cho mỗi tệp. Việc tạo IV (vectơ khởi tạo) được điều chỉnh tương ứng.
  • Cờ emmc_optimized tương tự như inlinecrypt_optimized nhưng nó cũng chọn phương pháp tạo IV giới hạn IV ở 32 bit. Chỉ nên sử dụng cờ này trên phần cứng mã hóa nội tuyến tuân thủ đặc tả JEDEC eMMC v5.2 và do đó chỉ hỗ trợ IV 32 bit. Trên phần cứng mã hóa nội tuyến khác, thay vào đó hãy sử dụng inlinecrypt_optimized . Cờ này không bao giờ được sử dụng trên bộ lưu trữ dựa trên UFS; đặc điểm kỹ thuật UFS cho phép sử dụng IV 64 bit.
  • Trên các thiết bị hỗ trợ phím bọc phần cứng , cờ wrappedkey_v0 cho phép sử dụng khóa bọc phần cứng cho FBE. Điều này chỉ có thể được sử dụng kết hợp với tùy chọn gắn inlinecrypt và cờ inlinecrypt_optimized hoặc emmc_optimized .

Nếu bạn không sử dụng phần cứng mã hóa nội tuyến, 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ã hóa nội tuyến, 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, Adiantum có thể được sử dụng thay vì AES bằng cách đặt fileencryption=adiantum .

Kể từ Android 14 (AOSP thử nghiệm), AES-HCTR2 là chế độ mã hóa tên tệp ưu tiên cho các thiết bị có hướng dẫn mã hóa 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, nó được lên kế hoạch trở thành chế độ mặc định để mã hóa tên tệp. Nếu hạt nhân của bạn có hỗ trợ AES-HCTR2, thì hạt nhân đó có thể được bật để mã hóa 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, điều 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ã hóa nội dung tệp FSCRYPT_MODE_PRIVATE . Chế độ này chưa được các nhân thông thường của Android triển khai, nhưng nó 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 tùy 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 phép và thay vào đó phải sử dụng định dạng mã hóa tiêu chuẩn.

Theo mặc định, mã hóa nội dung tệp được thực hiện bằng API mật mã của nhân Linux. Thay vào đó, nếu bạn muốn sử dụng phần cứng mã hóa nội tuyến, hãy thêm tùy chọn gắn inlinecrypt . Ví dụ: một dòng fstab đầy đủ có thể trô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

lưu trữ có thể chấp nhận

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

Việc chỉ định tùy chọn fstab fileencryption tệp cho userdata cũng tự động bật cả mã hóa FBE và siêu dữ liệu trên bộ nhớ có thể chấp nhận. Tuy nhiên, bạn có thể ghi đè định dạng mã hóa FBE và/hoặc siêu dữ liệu trên bộ nhớ có thể chấp nhận bằng cách đặt 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ã hóa FBE trên bộ nhớ có thể chấp nhận. Nó có cùng một cú pháp như đối số cho tùy chọn fileencryption fstab và nó sử dụng cùng các giá trị mặc định. Xem các đề xuất về fileencryption ở trên để biết cách sử dụng tại đây.
• ro.crypto.volume.metadata.encryption chọn định dạng mã hóa siêu dữ liệu trên bộ lưu trữ có thể chấp nhận. Xem tài liệu mã hóa 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ã hóa nội dung. Đ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 chế độ mã hóa 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ừ trường 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ị, điều này cần được ghi đè rõ ràng thành aes-256-cts .
• ro.crypto.fde_algorithm và ro.crypto.fde_sector_size chọn định dạng mã hóa siêu dữ liệu trên bộ nhớ có thể chấp nhận. Xem tài liệu mã hóa siêu dữ liệu .

Tích hợp với Keymaster

Keymaster HAL nên được bắt đầu như một phần của lớp early_hal . Điều này là do FBE yêu cầu Keymaster sẵn sàng xử lý các yêu cầu ở giai đoạn khởi động post-fs-data , đó là khi vold thiết lập các khóa ban đầu.

Loại trừ các thư mục

init áp dụng khóa DE hệ thống cho tất cả các thư mục cấp cao nhất của /data , ngoại trừ các thư mục không được mã hóa: thư mục chứa chính khóa 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. Các khóa mã hóa được áp dụng theo cách đệ quy và không thể bị ghi đè bởi các thư mục con.

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

Trong Android 10, các hành động mã hóa init được mã hóa cứng vào vị trí sau:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Trong Android 9 trở về trước, vị trí là:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Có thể thêm các ngoại lệ để ngăn một số thư mục nhất định không được mã hóa. Nếu các sửa đổi thuộc loại này được thực hiện thì nhà sản xuất thiết bị nên bao gồm các 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 không được mã hóa. Điều 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 điều này là hỗ trợ các khả năng OTA cũ.

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

Nhận biết các ứng dụng Khởi động trực tiếp

Để tạo điều kiện di chuyển nhanh chóng 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ỉ khả dụng cho các ứng dụng hệ thống. Thuộc tính directBootAware có sẵn cho tất cả.

<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ả các thành phần trong ứng dụng là nhận biết mã hóa.

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ỏ vào bộ nhớ CE. Các ứng dụng hệ thống sử dụng cờ này phải kiểm tra cẩn thận 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ộ lưu trữ CE. Các nhà sản xuất thiết bị sử dụng tùy chọn này nên kiểm tra cẩn thận dữ liệu mà họ đang lưu trữ để đảm bảo rằng dữ liệu đó 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 lưu trữ CE hỗ trợ khi cần, tương đương với các đối tác được Bảo vệ bởi thiết bị của chúng.

• 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 khóa mã hóa riêng. Mỗi người dùng nhận được hai khóa: khóa DE và khóa 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 thích hợp cho việc sử dụng Quản trị thiết bị .

Các ứng dụng nhận biết tiền điện tử tương tác giữa những người dùng theo cách này: 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, những ứng dụng đó sẽ chỉ có thể truy cập các thư mục được mã hóa CE cho người dùng đã được mở khóa.

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

Mỗi ID người dùng hồ sơ công việc cũng nhận được hai khóa: DE và CE. Khi hoàn thành thử thách công việc, người dùng hồ sơ được mở khóa và Keymaster (trong TEE) có thể cung cấp khóa TEE của hồ sơ.

Xử lý cập nhật

Phân vùng khôi phục không thể truy cập bộ lưu trữ được bảo vệ bằng DE trên phân vùng dữ liệu người dùng. Các thiết bị triển khai FBE được khuyến khích mạnh mẽ để hỗ trợ OTA bằng cách sử dụng các bản 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 không cần khôi phục để truy cập dữ liệu trên ổ đĩa được mã hóa.

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

1. Tạo một 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ã hóa (xem Loại trừ thư mục ).
3. Tạo một thư mục trong thư mục cấp cao nhất để chứa 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ỉ 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.

Thẩm định

Để đảm bảo phiên bản được triển khai của tính năng này hoạt động như dự kiến, trước tiên hãy chạy nhiều thử nghiệm mã hóa 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, các nhà sản xuất thiết bị có thể thực hiện các kiểm tra thủ công sau. Trên thiết bị có 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ã hóa
• Kiểm tra xem ro.crypto.type có tồn tại không
  • Đảm bảo ro.crypto.type được đặt thành file

Ngoài ra, người kiểm tra có thể khởi động phiên bản userdebug với màn hình khóa được đặt trên người dùng chính. Sau đó adb shell vào thiết bị và sử dụng su để trở thành root. Đảm bảo /data/data chứa tên tệp được mã hóa; nếu không, một cái gì đó là sai.

Các nhà sản xuất thiết bị cũng được khuyến khích khám phá việc chạy thử nghiệm Linux ngược dòng cho fscrypt trên thiết bị hoặc nhân của họ. Các bài kiểm tra này là một phần của bộ kiểm tra 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.

Chi tiết triển khai AOSP

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

mã hóa fscrypt

Việc triển khai AOSP sử dụng mã hóa "fscrypt" (được hỗ trợ bởi ext4 và f2fs) trong nhân và thường được định cấu hình để:

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

Mã hóa Adiantum cũng được hỗ trợ. Khi mã hóa Adiantum được bật, cả nội dung tệp và tên tệp đều được mã hóa 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 CDD đối với các 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ã hóa phiên bản 2 sử dụng HKDF-SHA512 để lấy giá trị thực tế các khóa mã hóa từ các khóa 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 kernel ngược dòng .

lớp lưu trữ

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

Lưu trữ và bảo vệ chìa khóa

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

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

vold cũng áp dụng một lớp mã hóa cho tất cả các khóa FBE. Mọi khóa ngoài khóa CE dành cho bộ nhớ trong đều được mã hóa bằng AES-256-GCM bằng cách sử dụng khóa Kho lưu trữ khóa riêng không được hiển thị bên ngoài TEE. Điều này đảm bảo rằng không thể mở khóa các khóa FBE trừ khi hệ điều hành đáng tin cậy đã khởi động, như được thực thi bởi Khởi động được xác minh . Khả năng chống quay ngược cũng được yêu cầu trên khóa Kho khóa, cho phép xóa các khóa FBE một cách an toàn trên các thiết bị mà Keymaster hỗ trợ khả năng chống quay ngược. Là một phương án dự phòng với nỗ lực tốt nhất khi không có tính năng kháng lùi, hàm băm SHA-512 gồm 16384 byte ngẫu nhiên được lưu trữ trong tệp secdiscardable loại bỏ được lưu trữ cùng với khóa được sử dụng làm thẻ ID ứng dụng của khóa Keystore. Tất cả các byte này cần được khôi phục để khôi phục khóa FBE.

Các khóa CE dành cho bộ nhớ trong nhận được mức độ bảo vệ mạnh hơn để đảm bảo rằng chúng không thể được mở khóa nếu không biết Yếu tố Kiến thức Màn hình Khóa (LSKF) (PIN, hình mở khóa hoặc mật khẩu) của người dùng, mã thông báo đặt lại mật khẩu an toàn hoặc cả hai mã phía máy khách và các phím phía máy chủ cho thao tác Resume-on-Reboot . Mã thông báo đặt lại mật mã chỉ được phép tạo 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ã hóa từng khóa CE cho bộ nhớ trong bằng khóa AES-256-GCM được 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ã hóa entropy cao bất biến đượ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á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 kéo dài LSKF bằng cách chuyển nó qua scrypt , nhắm mục tiêu thời gian khoảng 25 mili giây và mức sử dụng bộ nhớ khoảng 2 MiB. Vì các LSKF thường ngắn nên bước này thường không cung cấp nhiều 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ỷ lệ do TEE thực thi được mô tả bên dưới.

Nếu thiết bị có Phần tử bảo mật (SE), thì LockSettingsService sẽ ánh xạ LSKF kéo dài thành bí mật ngẫu nhiên có entropy cao được lưu trữ trong SE bằng cách sử dụng Weaver HAL . LockSettingsService sau đó mã hóa mật khẩu tổng hợp hai lần: lần đầu tiên bằng khóa phần mềm có nguồn gốc từ LSKF kéo dài và bí mật của Weaver, lần thứ hai bằng khóa Keystore không bị ràng buộc 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 dự đoán LSKF.

Nếu thiết bị không có SE, thì LockSettingsService thay vào đó sử dụng LSKF kéo dài làm mật khẩu Gatekeeper . LockSettingsService sau đó mã hóa mật khẩu tổng hợp hai lần: lần đầu tiên bằng khóa phần mềm được lấy từ LSKF kéo dài và hàm băm của tệp có thể loại bỏ được và lần thứ hai bằng khóa Keystore được xác thực liên kết với đăng ký Gatekeeper. Điều này cung cấp giới hạn tỷ lệ dự đoán LSKF do TEE thực thi.

Khi LSKF được thay đổi, LockSettingsService sẽ xóa 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 khóa Keystore chống rollback, điều này đảm bảo xóa 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 được áp dụng ngay cả khi người dùng không có LSKF.