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.