Эта страница переведена с помощью Cloud Translation API.

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

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

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

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

Реализация на внутренней памяти

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

Предпосылки

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

Метаданные шифрование требует, чтобы dm-default-key модуль будет включен в ядре. В Android 11 и выше, 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

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

В 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 :

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

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

init.hardware.rc уже должен содержать mount_all инструкцию , которая монтирует /data себя в on late-fs строфы. Перед этой линии, добавьте директиву EXEC в 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 (или , что эквивалентно metadata_encryption=:wrappedkey_v0 , как и aes-256-xts является алгоритм по умолчанию).

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

PRODUCT_SHIPPING_API_LEVEL := 30

Кроме того, можно установить следующее системное свойство , чтобы заставить использование нового dm-default-key API независимо от груза уровня 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 .

Затем запустите vts_kernel_encryption_test проверить правильность шифрования метаданных и НЭП:

atest vts_kernel_encryption_test

или:

vts-tradefed run vts -m vts_kernel_encryption_test

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

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

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

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

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

В AOSP, есть две реализаций метаданных шифрования на усыновлен хранения: устаревшей один на основе dm-crypt , и новый, основанные на dm-default-key . Для того, чтобы гарантировать , что правильное применение выбрано для вашего устройства, убедитесь , что вы установили правильное значение для PRODUCT_SHIPPING_API_LEVEL в device.mk . Например, если ваши запуски устройств с Android 11 (уровень 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 запуска 11 или выше, шифрование метаданных на усыновлен хранения использует dm-default-key модуль ядра, так же , как во внутренней памяти. Смотрите предпосылки выше , для которых параметры конфигурации ядра для включения. Обратите внимание , что встроенное аппаратного шифрования , который работает на внутренней памяти устройства могут быть недоступны на усыновлен хранения, и , таким образом CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y может потребоваться.

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

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

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

CONFIG_DM_CRYPT=y

В отличии от dm-default-key способа dm-crypt метод вызывает содержимое файла зашифровано дважды: один раз с ключом НЭПА и один раз с помощью ключа шифрования метаданных. Это двойное шифрование снижает производительность и не требуется для достижения целей безопасности, связанных с шифрованием метаданных, поскольку 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 Выбор размера крипто сектора. Возможные варианты: 512, 1024, 2048 и 4096. Для шифрования Adiantum используйте 4096.