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.

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 tập tin dựa trên phép một tính năng mới được giới thiệu trong Android 7.0 gọi là Boot 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ị mã hóa bằng mã hóa toàn bộ ổ đĩa (FDE), người sử dụng cần thiết để cung cấp thông tin trước khi bất kỳ dữ liệu có thể được truy cập, ngăn chặn điện thoại từ thực hiện tất cả nhưng cơ bản nhất của hoạt động. 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ó thay đổi đối với vòng đời ứng dụng để thích ứng với nhu cầu để thông báo cho các ứng dụng khi lưu trữ CE của người dùng được mở khóa để đáp ứng với thông tin cách nhập đầu tiên vào 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ách thức 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 một thực hiện tham chiếu của mã hóa tập tin dựa trên, trong đó Vold ( system / Vold ) cung cấp các chức năng để quản lý các 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 cốt lõi thay đổi để sử dụng mã hóa tập tin dựa trên khả năng trong kernel, nhiều gói hệ thống bao gồm các lockscreen và SystemUI đã được sửa đổi để hỗ trợ các FBE và các tính năng Boot 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 / inputmethods / LatinIME) *
  • Ứng dụng Cài đặt (gói / ứng dụng / Cài đặt) *
  • SystemUI (khung / cơ sở / gói / SystemUI) *

* Ứng dụng hệ thống có sử dụng defaultToDeviceProtectedStorage thuộc tính biểu hiện

Nhiều ví dụ về các ứng dụng và dịch vụ được mã hóa ý thức có thể được tìm thấy bằng cách chạy lệnh mangrep directBootAware trong khung hoặc gói thư mục 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:

  • Kernel Hỗ trợ mã hóa hoặc mã hóa Ext4 F2FS.
  • Keymaster Hỗ trợ với một 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 thực hiện trong một Trusted Execution Environment (TEE) để cung cấp bảo vệ cho các phím DE để cho một hệ điều hành không được phép (OS tùy chỉnh lóe lên thiết bị) không thể chỉ đơn giản là yêu cầu các phím DE.
  • Phần cứng Gốc của Trustđã kích hoạt Boot ràng buộc với khởi keymaster là cần thiết để đảm bảo rằng các thông tin Mã hóa thiết bị không thể truy cập bởi một hệ điều hành không được phép.

Lưu ý: chính sách lưu trữ được áp dụng vào 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

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

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ợ lưu trữ nhận làm con nuôi hoặc sẽ sử dụng mã hóa siêu dữ liệu vào bộ nhớ trong, cũng kích hoạt các tùy chọn cấu hình kernel cần thiết cho việc mã hóa siêu dữ liệu như mô tả trong tài liệu hướng dẫn 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

Tiếp tục cải thiện hiệu suất và giảm sử dụng điện, sản xuất thiết bị cũng có thể xem xét việc thực hiện phần cứng mã hóa nội tuyến, mã hóa / giải mã dữ liệu trong khi nó đang trên đường đến / từ các thiết bị lưu trữ. Các hạt nhân chung 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 có 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.

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 . Kể từ khi Android 11 nó cũng có thể được bỏ trống để xác định thuật toán mặc định, đó là aes-256-xts .
  • Các filenames_encryption_mode tham số định nghĩa mà thuật toán mã hóa được sử dụng để mã hóa tên tập tin. 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 .
  • Các flags tham số, mới trong Android 11, là một danh sách các cờ ngăn cách bởi + nhân vật. Các cờ sau được hỗ trợ:
    • Các v1 chính sách phiên bản 1 mã hóa cờ Selects; các v2 phiên bản 2 chính sách mã hóa cờ lựa chọn. Phiên bản 2 chính sách mã hóa sử dụng một an toàn hơn và linh hoạt chức năng nguồn gốc quan trọng . Giá trị mặc định là v2 nếu thiết bị ra mắt trên Android 11 hoặc cao hơn (được xác định bởi ro.product.first_api_level ), hoặc v1 nếu thiết bị ra mắt trên Android 10 hoặc thấp hơn.
    • Các inlinecrypt_optimized cờ chọn một định dạng mã hóa được tối ưu hóa cho phần cứng mã hóa nội tuyến mà không xử lý một số lượng lớn các phím 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ác emmc_optimized cờ cũng tương tự như inlinecrypt_optimized , nhưng nó cũng chọn một phương pháp thế hệ IV rằng giới hạn IV đến 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, 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.
    • Trên các thiết bị đó hỗ trợ các phím phần cứng bao bọc , các wrappedkey_v0 cờ cho phép việc sử dụng các phím phần cứng bọc cho FBE. Điều này chỉ có thể được sử dụng kết hợp với các inlinecrypt tùy chọn gắn kết, 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ác thiết lập khuyến cáo đối với 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ác thiết lập khuyến cáo đối với 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ị mà không cần bất kỳ hình thức AES tăng tốc, Adiantum có thể được sử dụng thay AES bằng cách thiết lập fileencryption=adiantum .

Trên các thiết bị đó ra mắt với Android 10 hoặc thấp hơn, fileencryption=ice cũng được chấp nhận để xác định việc sử dụng các FSCRYPT_MODE_PRIVATE tập tin chế độ nội dung mã hóa. 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 đầy đủ fstab dòng có thể trông giống như:

/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ừ khi Android 9, FBE và lưu trữ nhận làm con nuôi 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 đè lên FBE và / hoặc các định dạng mã hóa siêu dữ liệu vào lưu trữ nhận làm con nuôi bằng cách thiết lập 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 về lưu trữ nhận làm con nuôi. Nó có cú pháp tương tự như là đối số cho fileencryption tùy chọn fstab, và nó sử dụng giá trị mặc định tương tự. Xem các khuyến nghị cho fileencryption trên cho những gì để sử dụng ở đây.
  • ro.crypto.volume.metadata.encryption chọn định dạng mã hóa siêu dữ liệu vào lưu trữ nhận làm con nuôi. Xem các 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 lựa chọn chế độ nội dung mã hóa. Đây là tương đương với các lĩnh vực ruột-tách ra đầu tiên của ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode lựa chọn chế độ mã hóa tên tập tin. Đây là tương đương với các lĩnh vực ruột-tách thứ hai của ro.crypto.volume.options , ngoại trừ việc mặc định trên các thiết bị ra mắt với Android 10 hoặc thấp hơn là aes-256-heh . Trên hầu hết các thiết bị, điều này cần phải được ghi đè một cách rõ ràng để aes-256-cts .
  • ro.crypto.fde_algorithmro.crypto.fde_sector_size chọn định dạng mã hóa siêu dữ liệu vào lưu trữ nhận làm con nuôi. Xem các tài liệu mã hóa siêu dữ liệu .

Tích hợp với Keymaster

Thế hệ các phím và quản lý keyring 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 on-post-fs giai đoạn của init hoàn tất, các Keymaster phải sẵn sàng để xử lý yêu cầu. Trên các thiết bị Pixel, điều này được xử lý bởi có một khối kịch bản đảm bảo Keymaster được bắt đầu trước /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 (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 và cao hơn, chính sách mã hóa không còn được mã hóa trong một vị trí trung tâm, nhưng thay vì được xác định bởi đối số cho các mkdir lệnh trong init script. Thư mục được mã hóa với hệ thống DE sử dụng chìa khóa encryption=Require , trong khi thư mục được mã hóa (hoặc thư mục có thư mục con được mã hóa với các phím 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 các thư mục nhất định không được mã hóa. Nếu sửa đổi này loại được thực hiện sau đó các nhà sản xuất thiết bị nên bao gồm các chính sách SELinux rằng chỉ cấp quyền truy cập đến các ứng nhu cầu sử dụng các thư mục đượ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. Các defaultToDeviceProtectedStorage thuộc tính chỉ dành cho các ứng dụng hệ thống. Các directBootAware thuộc tính có sẵn cho tất cả.

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

Các directBootAware thuộc tính ở cấp ứng dụng là viết tắt cho đánh dấu tất cả các thành phần trong ứng dụng như là mã hóa nhận thức được.

Các defaultToDeviceProtectedStorage thuộc tính chuyển hướng vị trí lưu trữ ứng dụng mặc định đến thời điểm tại lưu trữ DE thay vì chỉ vào lưu trữ 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. Đây là thích hợp cho quản lý thiết bị sử dụng.

Ứng dụng Crypto-aware tương tác qua sử dụng theo cách này: INTERACT_ACROSS_USERSINTERACT_ACROSS_USERS_FULL cho phép một ứng dụng để hoạt động trên tất cả những người sử 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. Thiết bị triển khai FBE được khuyến khích mạnh mẽ để hỗ trợ OTA 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 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 để trừ chính sách mã hóa (xem chính sách Encryption 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ậ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 các phiên bản được thực hiện trong những tác phẩm đặc trưng như dự định, đầu tiên 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 hoặc cao hơn, cũng chạy 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 thử nghiệm thủ công sau đây. Trên thiết bị đã bật FBE:

  • Kiểm tra xem ro.crypto.state tồn tại
    • Đảm bảo ro.crypto.state được mã hóa
  • Kiểm tra xem ro.crypto.type tồn tại
    • Đảm bảo ro.crypto.type được thiết lập để file

Ngoài ra, xét nghiệm có thể khởi động một userdebug dụ với một bộ lockscreen 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. Hãy chắc chắn rằng /data/data chứa tên tập tin được mã hóa; nếu nó không, cái gì đó là sai.

Sản xuất thiết bị cũng được khuyến khích để khám phá chạy thử nghiệm Linux thượng nguồn cho fscrypt trên các 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, xem tài liệu hạt nhân ở thượng nguồn .

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ự"

Các auth thẻ là một mã hóa đã xác thực thẻ được tạo ra bởi Gatekeeper khi người dùng đăng nhập thành công. Các TEE sẽ từ chối sử dụng phím trừ khi thẻ auth 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.

Các chứng chỉ kéo dài là chứng chỉ người dùng sau khi ướp muối và kéo dài với scrypt thuật toán. Các chứng chỉ được thực băm một lần trong dịch vụ cài đặt khóa trước khi được truyền cho vold cho đi để scrypt . Này được mã hóa ràng buộc để chìa khóa trong TEE với tất cả các bảo đảm á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.

Các secdiscardable hash là một băm 512-bit của một tập tin 16 KB ngẫu nhiên được lưu trữ cùng với các thông tin khác sử dụng để tái tạo lại chìa khóa, ví dụ 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. Này được mã hóa ràng buộc để chìa khóa trong TEE với tất cả các bảo đảm á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.