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

Файловое шифрование

Android 7.0 и выше поддерживает шифрование на основе файлов (FBE). Файловое шифрование позволяет шифровать разные файлы разными ключами, которые можно разблокировать независимо.

В этой статье описывается, как включить шифрование на основе файлов на новых устройствах и как системные приложения могут использовать API-интерфейсы прямой загрузки, чтобы предложить пользователям наилучший и максимально безопасный опыт.

Прямая загрузка

Шифрование на основе файлов обеспечивает новую функцию Android 7.0, которая называется Direct Boot . Прямая загрузка позволяет зашифрованным устройствам загружаться прямо на экран блокировки. Ранее на зашифрованных устройствах, использующих полнодисковое шифрование (FDE), пользователям необходимо было предоставить учетные данные, прежде чем к каким-либо данным можно будет получить доступ, не позволяя телефону выполнять все, кроме самых основных операций. Например, аварийные сигналы не могли работать, службы доступности были недоступны, и телефоны не могли принимать вызовы, но были ограничены только основными операциями набора номера в экстренных ситуациях.

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

На устройстве с поддержкой FBE каждый пользователь устройства имеет два хранилища, доступных для приложений:

  • Хранилище с шифрованием учетных данных (CE), которое является хранилищем по умолчанию и доступно только после того, как пользователь разблокировал устройство.
  • Хранилище Device Encrypted (DE), которое является хранилищем, доступным как в режиме прямой загрузки, так и после того, как пользователь разблокировал устройство.

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

API Direct Boot позволяет приложениям с поддержкой шифрования получать доступ к каждой из этих областей. Существуют изменения в жизненном цикле приложения, чтобы учесть необходимость уведомлять приложения, когда хранилище CE пользователя разблокировано в ответ на первый ввод учетных данных на экране блокировки или в случае рабочего профиля, предоставляющего рабочую задачу . Устройства под управлением Android 7.0 должны поддерживать эти новые API и жизненные циклы независимо от того, реализуют ли они FBE или нет. Хотя без FBE, DE и CE хранилище всегда будет в разблокированном состоянии.

Полная реализация файлового шифрования в файловых системах Ext4 и F2FS предоставляется в Android Open Source Project (AOSP) и должна быть включена только на устройствах, которые соответствуют требованиям. Производители, выбирающие использование FBE, могут пожелать изучить способы оптимизации функции на основе используемой системы на кристалле (SoC).

Все необходимые пакеты в AOSP были обновлены для обеспечения прямой загрузки. Однако, если производители устройств используют настроенные версии этих приложений, они хотят убедиться, что есть как минимум пакеты с поддержкой прямой загрузки, предоставляющие следующие услуги:

  • Услуги телефонии и номеронабиратель
  • Способ ввода паролей в экран блокировки

Примеры и источник

Android предоставляет эталонную реализацию шифрования на основе файлов, в которой vold ( system / vold ) предоставляет функциональные возможности для управления устройствами хранения и томами на Android. Добавление FBE предоставляет vold несколько новых команд для поддержки управления ключами для ключей CE и DE нескольких пользователей. В дополнение к основным изменениям для использования возможностей шифрования на основе файлов в ядре, многие системные пакеты, включая экран блокировки и SystemUI, были изменены для поддержки функций FBE и Direct Boot. Это включает:

  • AOSP Dialer (пакеты / приложения / Dialer)
  • Настольные часы (пакеты / приложения / DeskClock)
  • LatinIME (пакеты / входные методы / LatinIME) *
  • Настройки приложения (пакеты / приложения / настройки) *
  • SystemUI (рамки / базы / пакеты / SystemUI) *

* Системные приложения, которые используют атрибут манифеста defaultToDeviceProtectedStorage

Дополнительные примеры приложений и служб, поддерживающих шифрование, можно найти, выполнив команду mangrep directBootAware в mangrep directBootAware frameworks или packages дерева исходного кода AOSP.

зависимости

Для безопасного использования реализации FBE в AOSP устройству необходимо соответствовать следующим зависимостям:

  • Поддержка ядра для шифрования Ext4 или F2FS.
  • Поддержка Keymaster с HAL версии 1.0 или 2.0. Keymaster 0.3 не поддерживается, поскольку он не обеспечивает необходимые возможности и не обеспечивает достаточную защиту для ключей шифрования.
  • Keymaster / Keystore и Gatekeeper должны быть реализованы в среде Trusted Execution Environment (TEE), чтобы обеспечить защиту ключей DE, чтобы неавторизованная ОС (пользовательская ОС, установленная на устройстве) не могла просто запросить ключи DE.
  • Аппаратный корень доверия и проверенная загрузка, связанные с инициализацией администратора ключей, необходимы для обеспечения того, чтобы учетные данные шифрования устройства не были доступны для несанкционированной операционной системы.

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

Реализация

Прежде всего, такие приложения, как будильники, телефон, специальные возможности должны быть сделаны для Android: directBootAware согласно документации разработчика Direct Boot .

Поддержка ядра

Поддержка ядра для шифрования Ext4 и F2FS доступна в распространенных ядрах Android версии 3.18 и выше. Чтобы включить его в ядре версии 5.1 или выше, используйте:

CONFIG_FS_ENCRYPTION=y

Для более старых версий ядра, используйте CONFIG_EXT4_ENCRYPTION=y , если ваше устройство userdata файловой системы Ext4, или использование CONFIG_F2FS_FS_ENCRYPTION=y , если свое устройство , userdata файловая система f2fs.

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

В дополнение к функциональной поддержке шифрования Ext4 или F2FS производители устройств должны также включить криптографическое ускорение, чтобы ускорить шифрование на основе файлов и улучшить взаимодействие с пользователем. Например, на устройствах на базе ARM64 ускорение ARMv8 CE (Cryptography Extensions) можно включить, задав следующие параметры конфигурации ядра:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Для дальнейшего повышения производительности и снижения энергопотребления производители устройств могут также рассмотреть возможность использования встроенного аппаратного шифрования , которое шифрует / дешифрует данные, когда они находятся на пути к / от устройства хранения. Общие ядра Android (версия 4.14 и выше) содержат структуру, которая позволяет использовать встроенное шифрование, когда доступна поддержка оборудования и драйверов поставщиков. Платформу встроенного шифрования можно включить, задав следующие параметры конфигурации ядра:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Если ваше устройство использует хранилище на основе UFS, также включите:

CONFIG_SCSI_UFS_CRYPTO=y

Если ваше устройство использует хранилище на основе eMMC, также включите:

CONFIG_MMC_CRYPTO=y

Включение файлового шифрования

Включение FBE на устройстве требует включения его во внутреннем хранилище ( userdata ). Это также автоматически включает FBE в приемлемом хранилище; однако формат шифрования в приемлемом хранилище может быть переопределен при необходимости.

Внутренняя память

НЭП включен путем добавления опции fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] в колонке fs_mgr_flags в fstab линии для userdata . Эта опция определяет формат шифрования во внутренней памяти. Он содержит до трех разделенных двоеточиями параметров:

  • Параметр contents_encryption_mode определяет, какой криптографический алгоритм используется для шифрования содержимого файла. Это может быть aes-256-xts или adiantum .
  • Параметр filenames_encryption_mode определяет, какой криптографический алгоритм используется для шифрования имен файлов. Это может быть aes-256-cts , aes-256-heh или adiantum . Если не указано, то по умолчанию aes-256-cts , если contents_encryption_mode является aes-256-xts или adiantum если contents_encryption_mode является adiantum .
  • Параметр flags , новый в Android R, представляет собой список флагов, разделенных символом + . Поддерживаются следующие флаги:
    • Флаг v1 выбирает политики шифрования версии 1; флаг v2 выбирает политики шифрования версии 2. В политиках шифрования версии 2 используется более безопасная и гибкая функция получения ключей . По умолчанию v2, если устройство запущено на Android R или выше (как определено ro.product.first_api_level ), или v1, если устройство запущено на Android 10 или ниже.
    • Флаг inlinecrypt_optimized выбирает формат шифрования, оптимизированный для оборудования встроенного шифрования, которое не эффективно обрабатывает большое количество ключей. Это достигается путем получения только одного ключа шифрования содержимого файла на ключ CE или DE, а не одного на файл. Генерация IV (векторов инициализации) корректируется соответственно.
    • Флаг emmc_optimized подобен inlinecrypt_optimized , но он также выбирает метод генерации IV, который ограничивает IV 32 битами. Этот флаг следует использовать только на оборудовании для встроенного шифрования, которое соответствует спецификации JEDEC eMMC v5.2 и поэтому поддерживает только 32-разрядные IV. На другом оборудовании для встроенного шифрования используйте вместо этого inlinecrypt_optimized . Этот флаг никогда не должен использоваться в хранилище на основе UFS; спецификация UFS позволяет использовать 64-битные IV.
    • Флаг wrappedkey_v0 позволяет использовать аппаратные ключи. При включении ключи FBE не генерируются программным обеспечением, а генерируются Keymaster с использованием тега STORAGE_KEY . Затем каждый ключ FBE, фактически предоставленный ядру, является ключом STORAGE_KEY экспортированным из Keymaster, что оборачивает его эфемерным ключом для каждой загрузки. Затем ядро ​​предоставляет упакованные ключи непосредственно оборудованию для встроенного шифрования. При правильной реализации, развернутые ключи никогда не присутствуют в системной памяти, и скомпрометированный завернутый ключ не может использоваться после перезагрузки. Этот флаг требует аппаратной поддержки, поддержки Keymaster для STORAGE_KEY , поддержки драйвера ядра, inlinecrypt монтирования inlinecrypt_optimized и флагов inlinecrypt_optimized или emmc_optimized .

Если вы не используете оборудование для встроенного шифрования, для большинства устройств рекомендуется использовать fileencryption=aes-256-xts . Если вы используете оборудование для встроенного шифрования, для большинства устройств рекомендуется использовать fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized . На устройствах без какой-либо формы ускорения AES вместо AES можно использовать Adiantum , установив fileencryption=adiantum .

На устройствах с Android 10 или ниже, fileencryption=ice также допускается для указания использования режима шифрования содержимого файла FSCRYPT_MODE_PRIVATE . Этот режим не реализован обычными ядрами Android, но может быть реализован поставщиками, использующими пользовательские патчи ядра. Формат на диске, создаваемый этим режимом, зависел от поставщика. На устройствах, запускаемых с Android R или выше, этот режим больше не разрешен, и вместо него должен использоваться стандартный формат шифрования.

По умолчанию шифрование содержимого файла выполняется с помощью API-интерфейса шифрования ядра Linux. Если вы хотите вместо этого использовать аппаратное шифрование, также добавьте inlinecrypt монтирования inlinecrypt . Например, полная строка fstab может выглядеть так:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic ,inlinecrypt wait ,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Приемлемое хранение

Начиная с Android 9, FBE и адаптируемое хранилище могут использоваться вместе.

Указание fileencryption опции FSTAB для userdata также автоматически включает как НЭП и метаданных шифрования на усыновлен хранения. Однако вы можете переопределить форматы шифрования FBE и / или метаданных в приемлемом хранилище, установив свойства в PRODUCT_PROPERTY_OVERRIDES .

На устройствах с Android R или выше используйте следующие свойства:

  • ro.crypto.volume.options (новый в Android R) выбирает формат шифрования FBE в приемлемом хранилище. Он имеет тот же синтаксис, что и аргумент для опции fileencryption fstab, и использует те же значения по умолчанию. См. Рекомендации по fileencryption выше для того, что использовать здесь.
  • ro.crypto.volume.metadata.encryption выбирает формат шифрования метаданных в приемлемом хранилище. Смотрите документацию по шифрованию метаданных .

На устройствах с Android 10 или ниже используйте следующие свойства:

  • ro.crypto.volume.contents_mode выбирает режим шифрования содержимого. Это эквивалентно первому разделенному двоеточиями полю ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode выбирает режим шифрования имен файлов. Это эквивалентно второму разделенному двоеточиями полю ro.crypto.volume.options , за исключением того, что по умолчанию на устройствах, запущенных с Android 10 или ниже, aes-256-heh . На большинстве устройств это должно быть явно переопределено на aes-256-cts .
  • ro.crypto.fde_algorithm и ro.crypto.fde_sector_size выбирают формат шифрования метаданных в приемлемом хранилище. Смотрите документацию по шифрованию метаданных .

Интеграция с Keymaster

Генерация ключей и управление vold ключей ядра осуществляется vold . Реализация AOSP FBE требует, чтобы устройство поддерживало Keymaster HAL версии 1.0 или выше. Более ранние версии Keymaster HAL не поддерживаются.

При первой загрузке ключи пользователя 0 генерируются и устанавливаются в начале процесса загрузки. К тому времени, когда фаза init on-post-fs завершится, Мастер ключей должен быть готов к обработке запросов. На устройствах Pixel это выполняется с помощью блока сценариев, который обеспечивает запуск Keymaster до монтирования /data .

Политика шифрования

Файловое шифрование применяет политику шифрования на уровне каталога. Когда устройство в userdata раздела сначала создаются, основные структуры и политики применяются к init скриптов. Эти сценарии инициируют создание ключей CE и DE первого пользователя (пользователя 0), а также определяют, какие каталоги должны быть зашифрованы этими ключами. При создании дополнительных пользователей и профилей необходимые дополнительные ключи создаются и сохраняются в хранилище ключей; их учетные данные и места хранения устройств создаются, и политика шифрования связывает эти ключи с этими каталогами.

В Android R и выше политика шифрования больше не жестко закодирована в централизованном месте, а определяется аргументами команд mkdir в сценариях инициализации. В каталогах, зашифрованных с помощью системного ключа DE, используется encryption=Require , в то время как в незашифрованных каталогах (или каталогах, подкаталоги которых зашифрованы с помощью пользовательских ключей) используется encryption=None .

В Android 10 политика шифрования была жестко задана в этом месте:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

В Android 9 и более ранних версиях это место было:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

Единственный известный приемлемый вариант использования этого - поддержка устаревших возможностей OTA.

Поддержка Direct Boot в системных приложениях

Создание приложений Direct Boot в курсе

Чтобы упростить быструю миграцию системных приложений, на уровне приложений можно установить два новых атрибута. Атрибут defaultToDeviceProtectedStorage доступен только для системных приложений. directBootAware доступен всем.

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

directBootAware на уровне приложения - это directBootAware обозначение для маркировки всех компонентов приложения как поддерживающих шифрование.

Атрибут defaultToDeviceProtectedStorage перенаправляет местоположение хранилища приложения по умолчанию, чтобы указывать на хранилище DE, а не на хранилище CE. Системные приложения, использующие этот флаг, должны тщательно проверять все данные, хранящиеся в расположении по умолчанию, и изменять пути к конфиденциальным данным, чтобы использовать хранилище CE. Производители устройств, использующие эту опцию, должны тщательно проверять данные, которые они хранят, чтобы убедиться, что они не содержат личной информации.

При работе в этом режиме доступны следующие системные API-интерфейсы для явного управления контекстом, поддерживаемым хранилищем CE при необходимости, что эквивалентно их аналогам с защитой устройства.

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

Поддержка нескольких пользователей

Каждый пользователь в многопользовательской среде получает отдельный ключ шифрования. Каждый пользователь получает два ключа: ключ DE и CE. Пользователь 0 должен сначала войти в устройство, поскольку он является специальным пользователем. Это актуально для использования Администрированием устройства .

Зашифрованные приложения взаимодействуют между пользователями следующим образом: INTERACT_ACROSS_USERS и INTERACT_ACROSS_USERS_FULL позволяют приложению действовать через всех пользователей на устройстве. Однако эти приложения смогут получать доступ только к каталогам с шифрованием CE для пользователей, которые уже разблокированы.

Приложение может иметь возможность свободно взаимодействовать между областями DE, но один пользователь разблокирован не означает, что все пользователи устройства разблокированы. Приложение должно проверить этот статус, прежде чем пытаться получить доступ к этим областям.

Каждый идентификатор пользователя рабочего профиля также получает два ключа: DE и CE. Когда рабочая задача выполнена, пользователь профиля разблокируется, и Мастер ключей (в TEE) может предоставить ключ TEE профиля.

Обработка обновлений

Раздел восстановления не может получить доступ к защищенному DE-хранилищу в разделе пользовательских данных. Устройствам, реализующим FBE, настоятельно рекомендуется поддерживать OTA с использованием обновлений системы A / B. Поскольку OTA может применяться во время нормальной работы, нет необходимости в восстановлении для доступа к данным на зашифрованном диске.

При использовании устаревшего решения OTA, которое требует восстановления , чтобы получить доступ к файлу OTA на userdata раздела:

  1. Создайте директорию верхнего уровня (например misc_ne ) в userdata раздела.
  2. Добавьте этот каталог верхнего уровня в исключение политики шифрования (см. Выше Политику шифрования ).
  3. Создайте каталог в каталоге верхнего уровня для хранения OTA-пакетов.
  4. Добавьте правило SELinux и контексты файла для управления доступом к этой папке и ее содержимому. Только процесс или приложения, получающие обновления OTA, должны иметь возможность читать и записывать в эту папку. Ни одно другое приложение или процесс не должно иметь доступа к этой папке.

Проверка

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

Если устройство работает под управлением Android R или выше, также запустите VtsKernelEncryptionTest :

atest vts_kernel_encryption_test

или:

vts-tradefed run vts -m VtsKernelEncryptionTest

Кроме того, производители устройств могут выполнять следующие ручные тесты. На устройстве с включенным FBE:

  • Убедитесь, что ro.crypto.state существует
    • Убедитесь, что ro.crypto.state зашифрован
  • Убедитесь, что ro.crypto.type существует
    • Убедитесь, что ro.crypto.type установлен в file

Кроме того, тестеры могут загрузить экземпляр пользовательской userdebug с установленным на основном пользователе userdebug блокировки. Затем adb в устройство adb shell и используйте su чтобы стать пользователем root. Убедитесь, что /data/data содержит зашифрованные имена файлов; если это не так, что-то не так.

Производителям устройств также рекомендуется изучить запуск тестов Linux для fscrypt на своих устройствах или ядрах. Эти тесты являются частью набора тестов файловой системы xfstests. Тем не менее, эти исходные тесты официально не поддерживаются Android.

Детали реализации AOSP

В этом разделе приведены подробные сведения о реализации AOSP и описано, как работает шифрование на основе файлов. Для производителей устройств не должно быть необходимости вносить здесь какие-либо изменения, чтобы использовать FBE и Direct Boot на своих устройствах.

шифрование fscrypt

Реализация AOSP использует в ядре шифрование "fscrypt" (поддерживается ext4 и f2fs) и обычно настраивается на:

  • Зашифруйте содержимое файла с помощью AES-256 в режиме XTS
  • Зашифруйте имена файлов с помощью AES-256 в режиме CBC-CTS

Шифрование Adiantum также поддерживается. Когда включено шифрование Adiantum, содержимое и имена файлов шифруются с помощью Adiantum.

Для получения дополнительной информации о fscrypt, см. Документацию ядра ядра .

Ключ вывода

Файловые ключи шифрования, которые являются 512-битными ключами, хранятся в зашифрованном виде другим ключом (256-битным ключом AES-GCM), хранящимся в TEE. Чтобы использовать этот ключ TEE, необходимо выполнить три требования:

  • Аутентификационный токен
  • Растянутые полномочия
  • «Секретный хеш»

Аутентификационный токен является токеном с криптографической аутентификацией, сгенерированным Gatekeeper при успешном входе пользователя в систему. TEE откажется использовать ключ, если не указан правильный токен аутентификации. Если у пользователя нет учетных данных, то токен аутентификации не используется и не нужен.

Растянутые учетные данные - это учетные данные пользователя после посола и растяжения с использованием алгоритма scrypt . vold данные фактически хешируются один раз в службе настроек блокировки, а затем передаются в vold для передачи в scrypt . Это криптографически связано с ключом в TEE со всеми гарантиями, которые применяются к KM_TAG_APPLICATION_ID . Если у пользователя нет учетных данных, то растянутые учетные данные не используются и не нужны.

Этот secdiscardable hash представляет собой 512-битный хэш случайного 16-килобайтного файла, который хранится вместе с другой информацией, используемой для восстановления ключа, такой как начальное число. Этот файл надежно удаляется при удалении ключа или шифруется по-новому; Эта дополнительная защита гарантирует, что злоумышленник должен восстановить каждый бит этого надежно удаленного файла, чтобы восстановить ключ. Это криптографически связано с ключом в TEE со всеми гарантиями, которые применяются к KM_TAG_APPLICATION_ID .

В большинстве случаев ключи FBE также подвергаются дополнительному этапу получения ключа в ядре для генерации подключей, фактически используемых для шифрования, например ключей для каждого файла или режима. Для политик шифрования версии 2 для этого используется HKDF-SHA512.