Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.
Trang này được dịch bởi Cloud Translation API.
Switch to English

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ể.

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 gọi 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 điện thoại thực hiện tất cả các hoạt động trừ những thao tác cơ bản nhất. Ví dụ: báo thức 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 nhưng chỉ giới hạn ở các hoạt động quay số khẩn cấp cơ bản.

Với sự ra đời của mã hóa dựa trên tệp (FBE) và các API mới để làm cho các ứng dụng nhận biết được 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 đăng nhập 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ó hai vị trí lưu trữ có sẵn cho các ứng dụng:

  • Bộ nhớ đượ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ộ nhớ 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 an toàn hơn vì nó cho phép nhiều người dùng được bảo vệ cùng một 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 ứng dụng để đáp ứng nhu cầu thông báo cho các ứng dụng khi bộ nhớ CE của người dùng được mở khóa để đáp ứng với việc nhập thông tin đăng nhập đầu tiên ở màn hình khóa hoặc trong trường hợp hồ sơ công việc cung cấp một 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ù, không có FBE, bộ nhớ 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 tham chiếu mã hóa dựa trên tệp, trong đó vold ( hệ thống / vold ) cung cấp chức năng quản lý thiết bị lưu trữ và khối lượng 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à Direct Boot. 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 / inputmethods / 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 tệp kê khai defaultToDeviceProtectedStorage

Có thể tìm thấy thêm ví dụ về các ứng dụng và dịch vụ có nhận dạng 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.

Sự 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ỗ trợ Kernel cho mã hóa Ext4 hoặc mã hóa F2FS.
  • Hỗ trợ Keymaster với phiên bản HAL 1.0 hoặc 2.0. 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 đủ 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 bảo vệ cho các khóa DE để một hệ điều hành trái phép (hệ điều hành tùy chỉnh được đưa vào thiết bị) không thể yêu cầu khóa DE một cách đơn giản.
  • Bắt buộc phải có Gốc tin cậyKhởi động đã xác minh của phần cứng liên kết với khởi tạo keymaster để đảm bảo rằng hệ điều hành trái phép không thể truy cập được thông tin đăng nhập Mã hóa thiết bị.

Lưu ý : Các chính sách lưu trữ được áp dụng cho một thư mục và tất cả các thư mục con của nó. Các nhà sản xuất nên giới hạn nội dung không được mã hóa vào thư mục OTA và thư mục chứa khóa giải mã hệ thống. Hầu hết nội dung phải nằm trong bộ nhớ được mã hóa thông tin xác thực thay vì bộ nhớ được mã hóa trên thiết bị.

Thực hiện

Đầu tiên và quan trọng nhất, các ứng dụng như đồng hồ báo thức, điện thoại, các tính năng trợ năng nên được tạo thành android: directBootAware theo tài liệu dành cho nhà phát triển Direct Boot .

Hỗ trợ Kernel

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

CONFIG_FS_ENCRYPTION=y

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

Nếu thiết bị của bạn sẽ 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 tùy chọn cấu hình hạt nhân cần thiết cho 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ật mã để 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, tăng tốc ARMv8 CE (Phần mở rộng mật mã) có thể được kích hoạt bằng cách đặt các tùy 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 hơn nữa hiệu suất và giảm mức sử dụng điện nă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 , phần cứng này sẽ mã hóa / giải mã dữ liệu khi đang trên đường đến / đi từ thiết bị lưu trữ. Các hạt nhân phổ biến của Android (phiên bản 4.14 trở lên) chứa một khuôn khổ cho phép sử dụng mã hóa nội tuyến khi hỗ trợ phần cứng và trình điều khiển của nhà cung cấp. Khung mã hóa nội tuyến có thể được kích hoạt bằng cách thiết lập các tùy 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:

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 mã hóa dựa trên tệp

Tạo điều kiện cho FBE trên một thiết bị yêu cầu bật nó trên bộ nhớ trong ( userdata ). Điều này cũng tự động bật FBE trên bộ nhớ có thể sử dụng; tuy nhiên, định dạng mã hóa trên bộ nhớ có thể sử dụng có thể bị ghi đè nếu cần thiết.

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]] đến fs_mgr_flags cột của fstab dòng 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:

  • Các contents_encryption_mode tham số định nghĩa mà thuật toán mã hóa được sử dụng để mã hóa nội dung file. Nó có thể là aes-256-xts hoặc adiantum . Vì Android 11, nó cũng có thể được để 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ã nào được sử dụng để mã hóa tên tệp. Nó có thể là aes-256-cts , aes-256-heh hoặc adiantum . Nếu không quy định, nó mặc định là aes-256-cts nếu contents_encryption_modeaes-256-xts , hoặc để adiantum nếu contents_encryption_modeadiantum .
  • 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 được hỗ trợ:
    • Cờ v1 chọn các 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. 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ị 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ý số lượng lớn khóa một cách hiệu quả. 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 trên mỗi khóa CE hoặc DE, thay vì một khóa trên 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 nó cũng chọn phương pháp tạo IV giới hạn IVs ở 32 bit. Cờ này chỉ nên được sử dụng trên phần cứng mã hóa nội tuyến tuân thủ đặc điểm kỹ thuậ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, hãy sử dụng inlinecrypt_optimized thay thế. Cờ này không bao giờ được sử dụng trên bộ lưu trữ dựa trên UFS; đặc tả UFS cho phép sử dụng IV 64-bit.
    • Cờ wrappedkey_v0 cho phép sử dụng các khóa được bọc phần cứng. Khi được bật, các khóa FBE không được tạo bởi phần mềm mà được tạo bởi Keymaster bằng cách sử dụng thẻ STORAGE_KEY . Sau đó, mỗi khóa FBE thực sự được cung cấp cho hạt nhân là khóa STORAGE_KEY xuất từ ​​Keymaster, khiến nó được bọc bằng một khóa tạm thời cho mỗi lần khởi động. Sau đó, hạt nhân cung cấp các khóa được bọc trực tiếp cho phần cứng mã hóa nội tuyến. Khi được triển khai đúng cách, các khóa chưa được bọc sẽ không bao giờ xuất hiện trong bộ nhớ hệ thống và không thể sử dụng khóa được bọc bị xâm phạm sau khi khởi động lại. Cờ này đòi hỏi hỗ trợ phần cứng, hỗ trợ cho Keymaster STORAGE_KEY , hỗ trợ điều khiển hạt nhân, các inlinecrypt gắn kết tùy chọn, và một trong hai inlinecrypt_optimized hoặc emmc_optimized cờ.

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 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, Adiantum có thể được sử dụng thay vì AES bằng cách đặt fileencryption=adiantum .

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 không được thực hiện bởi các nhân phổ biến của Android, nhưng nó có thể được các nhà cung cấp thực hiện 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 nữa 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. Nếu bạn muốn sử dụng phần cứng mã hóa inline thay vào đó, cũng thêm inlinecrypt tùy chọn gắn kết. 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ể được sử dụng có thể được sử dụng cùng nhau.

Xác định fileencryption tùy chọn fstab cho userdata cũng tự động cho phép cả hai FBE và mã hóa siêu dữ liệu vào lưu trữ nhận làm con nuôi. Tuy nhiên, bạn có thể ghi đè các định dạng mã hóa FBE và / hoặc siêu dữ liệu trên bộ nhớ có thể sử 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 (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 cú pháp với đối số của tùy chọn fstab fileencryption và sử dụng các giá trị mặc định giống nhau. Xem các khuyến nghị 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ộ nhớ có thể sử dụng. 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 được phân tách bằng dấu hai chấm đầu tiên của ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode chọn chế độ mã hóa tên tệp. Điều này tương đương với trường được phân tách bằng dấu hai chấm thứ hai của ro.crypto.volume.options , ngoại trừ trường mặc định trên các thiết bị khởi 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_algorithmro.crypto.fde_sector_size chọn định dạng mã hóa siêu dữ liệu trên bộ nhớ có thể sử dụng. Xem tài liệu mã hóa siêu dữ liệu .

Tích hợp với Keymaster

Việc tạo khóa và quản lý khóa hạt nhân được xử lý bởi vold . Việc triển khai AOSP của FBE yêu cầu thiết bị phải hỗ trợ Keymaster HAL phiên bản 1.0 trở lên. Không có hỗ trợ cho các phiên bản trước của Keymaster HAL.

Trong lần khởi động đầu tiên, các khóa của người dùng 0 được tạo và cài đặt sớm trong quá trình khởi động. Vào thời điểm giai đoạn on-post-fs của init hoàn thành, Keymaster phải sẵn sàng xử lý các yêu cầu. Trên thiết bị Pixel, điều này được xử lý bằng cách có một khối tập lệnh đảm bảo Keymaster được khởi động trước khi /data được gắn kết.

Chính sách mã hóa

Mã hóa dựa trên tệp áp dụng chính sách mã hóa ở cấp thư mục. Khi một thiết bị userdata phân vùng đầu tiên được tạo ra, các cấu trúc và chính sách cơ bản được áp dụng bởi các init script. Các tập lệnh này sẽ kích hoạt việc tạo các khóa CE và DE của người dùng đầu tiên (của người dùng 0) cũng như xác định thư mục nào sẽ được mã hóa bằng các khóa này. Khi người dùng và hồ sơ bổ sung được tạo, các khóa bổ sung cần thiết sẽ được tạo và lưu trữ trong kho khóa; thông tin xác thực và vị trí lưu trữ thiết bị của họ được tạo và chính sách mã hóa liên kết các khóa này với các thư mục đó.

Trong Android 11 trở lên, chính sách mã hóa không còn được mã hóa cứng vào một vị trí tập trung nữa mà được xác định bằng các đối số cho các mkdir trong các tập lệnh init. Các thư mục được mã hóa bằng hệ thống DE sử dụng khóa encryption=Require , trong khi các thư mục không được mã hóa (hoặc các thư mục có thư mục con được mã hóa bằng khóa cho mỗi người dùng) sử dụng encryption=None .

Trong Android 10, chính sách mã hóa đã được mã hóa cứng vào vị trí này:

/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 kiểu 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 chấp nhận được duy nhất đã biết cho việc này là hỗ trợ các khả năng OTA cũ.

Hỗ trợ khởi động trực tiếp trong các ứng dụng hệ thống

Làm cho các ứng dụng nhận biết 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ỉ có sẵn 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 đến điểm lưu trữ 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ộ nhớ 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 hỗ trợ bởi bộ nhớ CE khi cần thiết, tương đương với các đối tác được Bảo vệ 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 nhận được một khóa mã hóa riêng. Mỗi người dùng nhận được hai khóa: một khóa DE và một khóa CE. Người dùng 0 phải đăng nhập vào thiết bị trước tiên vì đó là một 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 người dùng theo cách này: INTERACT_ACROSS_USERSINTERACT_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 đó sẽ chỉ có thể truy cập vào các thư mục được mã hóa CE cho những 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 đã 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 cố gắng truy cập 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 đáp ứng được thách thức công việc, người dùng cấu hình được mở khóa và Keymaster (trong TEE) có thể cung cấp khóa TEE của cấu hình.

Xử lý các bản 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ởi 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 nghị 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 một giải pháp OTA di sản, đòi hỏi phục hồi để truy cập các tập tin OTA trên userdata phân vùng:

  1. Tạo một thư mục cấp cao nhất (ví dụ misc_ne ) trong userdata phân vùng.
  2. Thêm thư mục cấp cao nhất này vào ngoại lệ chính sách mã hóa (xem Chính sách mã hóa ở trên).
  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 được 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 hoạt động như dự kiến, trước tiên hãy chạy nhiều bài kiểm tra mã hóa CTS, chẳng hạn như DirectBootHostTestEncryptionTest .

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

atest vts_kernel_encryption_test

hoặc là:

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 thử nghiệm thủ công sau đây. Trên thiết bị đã bật FBE:

  • Kiểm tra xem có tồn tại ro.crypto.state 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 dùng 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 các tên tệp được mã hóa; nếu nó không, 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 các bài kiểm tra Linux ngược dòng cho fscrypt trên thiết bị hoặc hạt 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 bài kiểm tra 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 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 thiết phải 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ã 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 hạt nhân và thường được định cấu hình để:

  • Mã hóa nội dung tệp với AES-256 ở chế độ XTS
  • Mã hóa tên tệp với 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.

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

Dẫn xuất chính

Khóa mã hóa dựa trên tệp, là khóa 512 bit, được lưu trữ mã hóa bằng khóa khác (khóa AES-GCM 256 bit) được giữ trong TEE. Để sử dụng khóa TEE này, bạn phải đáp ứng ba yêu cầu:

  • Mã thông báo xác thực
  • Thông tin đăng nhập kéo dài
  • "Hàm băm có thể hủy bỏ thứ tự"

thông báo xác thực là mã thông báo xác thực bằng mật mã được tạo bởi Gatekeeper khi người dùng đăng nhập thành công. TEE sẽ từ chối sử dụng khóa trừ khi mã xác thực chính xác được cung cấp. Nếu người dùng không có thông tin xác thực, thì không cần sử dụng mã thông báo xác thực.

Thông tin đăng nhập được kéo dàithông tin đăng nhập của người dùng sau khi ướp muối và kéo dài bằng thuật toán scrypt . Thông tin xác thực thực sự được băm một lần trong dịch vụ cài đặt khóa trước khi được chuyển cho vold để chuyển sang scrypt . Điều này được liên kết bằng mật mã với khóa trong TEE với tất cả các đảm bảo áp dụng cho KM_TAG_APPLICATION_ID . Nếu người dùng không có thông tin đăng nhập, thì không cần sử dụng thông tin xác thực kéo dài nào.

secdiscardable hashsecdiscardable hash 512-bit của tệp ngẫu nhiên 16 KB được lưu trữ cùng với thông tin khác được sử dụng để tạo lại khóa, chẳng hạn như hạt giống. Tệp này được xóa an toàn khi khóa bị xóa hoặc nó được mã hóa theo cách mới; bảo vệ bổ sung này đảm bảo kẻ tấn công phải khôi phục từng bit của tệp đã xóa an toàn này để khôi phục khóa. Điều này được liên kết bằng mật mã với khóa trong TEE với tất cả các đảm bảo áp dụng cho KM_TAG_APPLICATION_ID .

Trong hầu hết các trường hợp, các khóa FBE cũng phải trải qua một bước dẫn xuất khóa bổ sung trong hạt nhân để tạo ra các khóa con thực sự được sử dụng để mã hóa, ví dụ: khóa cho mỗi tệp hoặc cho mỗi chế độ. Đối với chính sách mã hóa phiên bản 2, HKDF-SHA512 được sử dụng cho việc này.