Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Шифрование метаданных

Android 7.0 и выше поддерживает шифрование на основе файлов (FBE). FBE позволяет шифровать разные файлы разными ключами, которые можно разблокировать независимо. Эти ключи используются для шифрования как содержимого файла, так и имени файла. Когда используется FBE, другая информация, такая как макеты каталогов, размеры файлов, разрешения и время создания / изменения, не шифруется. В совокупности эта другая информация называется метаданными файловой системы.

В Android 9 появилась поддержка шифрования метаданных. При шифровании метаданных один ключ, присутствующий во время загрузки, шифрует любой контент, не зашифрованный FBE. Этот ключ защищен Keymaster, который в свою очередь защищен проверенной загрузкой.

Шифрование метаданных всегда включено в приемлемом хранилище всякий раз, когда включен FBE. Шифрование метаданных также может быть включено во внутреннем хранилище.

Реализация на внутреннем хранилище

Вы можете настроить шифрование метаданных во внутреннем хранилище новых устройств, настроив файловую систему metadata , изменив последовательность инициализации и включив шифрование метаданных в файле fstab устройства.

Предпосылки

Шифрование метаданных можно настроить только при первом форматировании раздела данных. В результате эта функция только для новых устройств; это не то, что ОТА должен изменить.

Шифрование метаданных требует, чтобы в вашем ядре был включен модуль dm-default-key . В Android R и выше, dm-default-key поддерживается общими ядрами Android версии 4.14 и выше. Эта версия dm-default-key использует аппаратную и независимую от поставщика среду шифрования, называемую blk-crypto .

Чтобы включить dm-default-key , используйте:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
CONFIG_DM_DEFAULT_KEY=y

dm-default-key использует встроенное аппаратное шифрование (оборудование, которое шифрует / дешифрует данные, когда они находятся на пути к устройству хранения и обратно), когда оно доступно. Если вы не будете использовать встроенное аппаратное шифрование, также необходимо включить откат к криптографическому API ядра:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Если вы не используете встроенное аппаратное шифрование, вам также следует включить любое доступное ускорение на базе процессора, как рекомендуется в документации FBE .

В Android 10 и ниже, dm-default-key не поддерживалось общим ядром Android. Поэтому поставщики должны были реализовать dm-default-key .

Настроить файловую систему метаданных

Поскольку ничто в разделе пользовательских данных не может быть прочитано до тех пор, пока не появится ключ шифрования метаданных, в таблице разделов должен быть выделен отдельный раздел, называемый «разделом метаданных», для хранения двоичных объектов мастера ключей, защищающих этот ключ. Раздел метаданных должен быть 16 МБ.

fstab.hardware должна быть запись для файловой системы метаданных, которая находится в этом разделе и монтирующая его в /metadata , включая флаг formattable чтобы обеспечить ее форматирование во время загрузки. Файловая система f2fs не работает на небольших разделах; вместо этого мы рекомендуем использовать ext4. Например:

/dev/block/bootdevice/by-name/metadata              /metadata          ext4        noatime,nosuid,nodev,discard                          wait,check,formattable

Чтобы убедиться, что точка монтирования /metadata существует, добавьте следующую строку в BoardConfig-common.mk :

BOARD_USES_METADATA_PARTITION := true

Изменения в последовательности инициализации

Когда используется шифрование метаданных, vold должен быть запущен до /data монтируется. Чтобы обеспечить его init.hardware.rc достаточно рано, добавьте следующий init.hardware.rc в init.hardware.rc :

# We need vold early for metadata encryption
on early-fs
    start vold

Keymaster должен быть запущен и готов, прежде чем init попытается смонтировать /data .

init.hardware.rc уже должна содержаться инструкция mount_all которая монтирует /data сама в разделе on late-fs . Перед этой строкой добавьте директиву для wait_for_keymaster службы wait_for_keymaster :

on late-fs
   … 
    # Wait for keymaster
    exec_start wait_for_keymaster

    # Mount RW partitions which need run fsck
    mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

Включение шифрования метаданных

Наконец , добавьте keydirectory=/metadata/vold/metadata_encryption к колонку fs_mgr_flags в fstab записи для userdata . Например, полная строка fstab может выглядеть так:

/dev/block/bootdevice/by-name/userdata              /data              f2fs        noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized ,keydirectory=/metadata/vold/metadata_encryption ,quota,formattable

По умолчанию алгоритмом шифрования метаданных во внутренней памяти является AES-256-XTS. Это можно переопределить, установив параметр metadata_encryption , также в столбце fs_mgr_flags :

  • На устройствах без ускорения AES шифрование Adiantum можно включить, установив metadata_encryption=adiantum .
  • На устройствах, которые поддерживают аппаратно-упакованные ключи, которые непосредственно предоставляются аппаратному шифрованию, ключ шифрования метаданных можно сделать аппаратно-упакованным, установив metadata_encryption=aes-256-xts:wrappedkey_v0 . См. Документацию FBE для получения дополнительной информации об аппаратных ключах и их предварительных условиях.

Поскольку интерфейс ядра для dm-default-key изменился в Android R, вам также необходимо убедиться, что вы установили правильное значение для PRODUCT_SHIPPING_API_LEVEL в device.mk . Например, если ваше устройство запускается с Android R (уровень API 30), device.mk должен содержать:

PRODUCT_SHIPPING_API_LEVEL := 30

Вы также можете установить следующее системное свойство для принудительного использования нового API dm-default-key независимо от уровня API доставки:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.dm_default_key.options_format.version=2

Проверка

Чтобы убедиться, что шифрование метаданных включено и работает правильно, запустите тесты, описанные ниже. Также помните об общих проблемах, описанных ниже.

тесты

Начните с выполнения следующей команды, чтобы убедиться, что шифрование метаданных включено во внутренней памяти:

adb root
adb shell dmctl table userdata

Вывод должен быть похож на:

Targets in the device-mapper table for userdata:
0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors

Если вы переопределите настройки шифрования по умолчанию, установив опцию metadata_encryption в fstab устройства, то выходные данные будут немного отличаться от приведенных выше. Например, если вы включили шифрование Adiantum , третье поле будет xchacha12,aes-adiantum-plain64 вместо aes-xts-plain64 .

Затем запустите VtsKernelEncryptionTest, чтобы проверить правильность шифрования метаданных и FBE:

atest vts_kernel_encryption_test

или:

vts-tradefed run vts -m VtsKernelEncryptionTest

Общие проблемы

Во время вызова mount_all , который монтирует раздел с зашифрованными метаданными /data раздел /data , init запускает инструмент vdc. В подключает VDC инструмента для vold над binder для настройки метаданных зашифрованы устройств и смонтировать раздел. На время этого вызова init блокируется, и попытки либо прочитать, либо установить свойства init будут блокироваться до завершения mount_all . Если на этом этапе какая-либо часть работы vold прямо или косвенно блокируется при чтении или установке свойства, возникает тупик. Важно убедиться, что vold может завершить работу по чтению ключей, взаимодействию с Keymaster и монтированию каталога данных без дальнейшего взаимодействия с init .

Если Keymaster не в полной мере , когда начался mount_all работает, она не будет реагировать на vold , пока он прочитал некоторые свойства из init , в результате чего точно тупика описан. Размещение exec_start wait_for_keymaster над соответствующим mount_all как указано, гарантирует, что Keymaster заранее полностью запущен, и, таким образом, избегает этой тупиковой ситуации.

Конфигурация на приемлемом хранилище

Начиная с Android 9, форма шифрования метаданных всегда включена в пригодном для хранения хранилище всякий раз, когда FBE включен, даже когда шифрование метаданных не включено во внутреннем хранилище.

В AOSP существует две реализации шифрования метаданных в приемлемом хранилище: устаревшая, основанная на dm-crypt , и более новая, основанная на dm-default-key . Чтобы убедиться, что для вашего устройства выбрана правильная реализация, убедитесь, что вы установили правильное значение для PRODUCT_SHIPPING_API_LEVEL в device.mk . Например, если ваше устройство запускается с Android R (уровень API 30), device.mk должен содержать:

PRODUCT_SHIPPING_API_LEVEL := 30

Вы также можете установить следующие системные свойства, чтобы принудительно использовать новый метод шифрования метаданных тома (и новую версию политики FBE по умолчанию) независимо от уровня API доставки:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.volume.metadata.method=dm-default-key \
    ro.crypto.dm_default_key.options_format.version=2 \
    ro.crypto.volume.options=::v2

Текущий метод

На устройствах, запускаемых с Android R или выше, для шифрования метаданных на подходящем хранилище используется модуль ядра dm-default-key , как и на внутреннем хранилище. См. Предварительные условия выше, для которых параметры конфигурации ядра должны быть включены. Обратите внимание, что встроенное аппаратное шифрование, которое работает во внутренней памяти устройства, может быть недоступно для приемлемой памяти, и, следовательно, может потребоваться CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y .

По умолчанию в методе шифрования метаданных тома dm-default-key используется алгоритм шифрования AES-256-XTS с криптосекторами размером 4096 байт. Алгоритм можно переопределить, установив системное свойство ro.crypto.volume.metadata.encryption . Значение этого свойства имеет тот же синтаксис, что и опция fstab metadata_encryption описанная выше. Например, на устройствах без ускорения AES шифрование Adiantum можно включить, установив ro.crypto.volume.metadata.encryption=adiantum .

Устаревший метод

На устройствах, работающих с Android 10 или ниже, для шифрования метаданных в приемлемом хранилище используется модуль ядра dm-crypt а не dm-default-key :

CONFIG_DM_CRYPT=y

В отличие от метода dm-default-key метод dm-crypt заставляет содержимое файла шифроваться дважды: один раз с помощью ключа FBE и один раз с ключом шифрования метаданных. Такое двойное шифрование снижает производительность и не требуется для достижения целей безопасности шифрования метаданных, поскольку Android гарантирует, что ключи FBE по меньшей мере так же трудно взломать, как и ключ шифрования метаданных. Поставщики могут выполнить настройки ядра, чтобы избежать двойного шифрования, в частности, реализуя опцию allow_encrypt_override которую Android передает в dm-crypt когда системное свойство ro.crypto.allow_encrypt_override установлено в значение true . Эти настройки не поддерживаются общим ядром Android.

По умолчанию в методе шифрования метаданных тома dm-crypt используется алгоритм шифрования AES-128-CBC с ESSIV и 512-байтовыми криптографическими секторами. Это можно изменить, установив следующие системные свойства (которые также используются для FDE):

  • ro.crypto.fde_algorithm выбирает алгоритм шифрования метаданных. Возможны варианты aes-128-cbc и adiantum . Adiantum можно использовать только в том случае, если в устройстве отсутствует ускорение AES.
  • ro.crypto.fde_sector_size выбирает размер ro.crypto.fde_sector_size . Возможны варианты 512, 1024, 2048 и 4096. Для шифрования Adiantum используйте 4096.