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

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

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

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

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

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

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

  • Хранилище с шифрованием учетных данных (CE), которое является местом хранения по умолчанию и доступно только после того, как пользователь разблокирует устройство.
  • Зашифрованное хранилище устройства (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 дерева mangrep directBootAware 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

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

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

Внутреннее хранилище

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

  • Параметр contents_encryption_mode определяет, какой криптографический алгоритм используется для шифрования содержимого файла. Это может быть как aes-256-xts и adiantum . Начиная с Android 11, его также можно оставить пустым, чтобы указать алгоритм по умолчанию, которым является aes-256-xts .
  • Параметр 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 11, представляет собой список флагов, разделенных знаком + . Поддерживаются следующие флаги:
    • Флаг v1 выбирает политики шифрования версии 1; флаг v2 выбирает политики шифрования версии 2. Политики шифрования версии 2 используют более безопасную и гибкую функцию получения ключей . По умолчанию это v2, если устройство запущено на Android 11 или выше (как определено 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 флаг wrappedkey_v0 позволяет использовать ключи с wrappedkey_v0 для FBE. Это можно использовать только в сочетании с inlinecrypt монтирования inlinecrypt_optimized и флагом inlinecrypt_optimized или emmc_optimized .

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

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

По умолчанию шифрование содержимого файла выполняется с помощью криптографического 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 11 или более поздней версии, используйте следующие свойства:

  • ro.crypto.volume.options (новое в Android 11) выбирает формат шифрования FBE для адаптируемого хранилища. Он имеет тот же синтаксис, что и аргумент fileencryption fstab fileencryption , и использует те же значения по умолчанию. См. Рекомендации по fileencryption выше, чтобы узнать, что использовать здесь.
  • ro.crypto.volume.metadata.encryption выбирает формат шифрования метаданных для 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 . Реализация FBE в AOSP требует, чтобы устройство поддерживало Keymaster HAL версии 1.0 или более поздней. Более ранние версии Keymaster HAL не поддерживаются.

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

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

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

В Android 11 и более поздних версиях политика шифрования больше не жестко привязана к централизованному расположению, а определяется аргументами команд 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.

Поддержка прямой загрузки в системных приложениях

Обеспечение осведомленности о прямой загрузке приложений

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

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

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 11 или выше, также запустите vts_kernel_encryption_test :

atest vts_kernel_encryption_test

или же:

vts-tradefed run vts -m vts_kernel_encryption_test

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

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

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

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

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

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

шифрование fscrypt

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

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

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

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

Ключевые выводы

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

  • Токен авторизации
  • Растянутые учетные данные
  • «Секундискартируемый хеш»

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

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

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

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