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

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

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

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

Шифрование файлов на основе позволяет новую функцию , введенную в Android 7.0 под названием Direct загрузки . Прямая загрузка позволяет зашифрованным устройствам загружаться прямо на экран блокировки. Ранее на криптографических устройств с использованием полного шифрования диска (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 обеспечивает эталонную реализацию шифрования на основе файлов, в которых Волд ( система / Волд ) обеспечивает функциональные возможности для управления устройствами хранения данных и томами на Android. Добавление FBE предоставляет vold несколько новых команд для поддержки управления ключами CE и DE нескольких пользователей. В дополнении к основному изменяется , чтобы использовать основанные на файлы шифрование возможности в ядре, многие системные пакеты , включая LockScreen и SystemUI были модифицированы для поддержки НЭПА и прямая загрузка особенности. Это включает:

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

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

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

Зависимости

Чтобы безопасно использовать реализацию FBE в AOSP, устройство должно соответствовать следующим зависимостям:

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

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

Реализация

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

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

Поддержка ядра для шифрования 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 , который ограничивает капельницы до 32 бит. Этот флаг следует использовать только на оборудовании для встроенного шифрования, которое соответствует спецификации JEDEC eMMC v5.2 и, следовательно, поддерживает только 32-битные IV. На других аппаратных средств встроенного шифрования, используйте inlinecrypt_optimized вместо этого. Этот флаг никогда не следует использовать в хранилище на основе UFS; спецификация UFS позволяет использовать 64-битные IV.
    • На устройствах , которые поддерживают аппаратно-обернуты ключей , то wrappedkey_v0 флаг позволяет использовать аппаратные обернутых ключей для НЭПА. Это может быть использовано только в сочетании с inlinecrypt опции монтирования, и либо inlinecrypt_optimized или emmc_optimized флага.

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

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

По умолчанию шифрование содержимого файла выполняется с помощью криптографического API ядра Linux. Если вы хотите использовать встроенное аппаратное шифрование вместо этого, также добавить 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, НЭП и оптимизируется для хранения могут быть использованы вместе.

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

На устройствах, запущенных с Android 11 или более поздней версии, используйте следующие свойства:

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

При первой загрузке ключи пользователя 0 генерируются и устанавливаются в самом начале процесса загрузки. К тому времени on-post-fs фазы init завершается, 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 должен сначала войти в устройство, так как это специальный пользователь. Это уместно для администрирования устройства использований.

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

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

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

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

Раздел восстановления не может получить доступ к защищенному DE хранилищу в разделе пользовательских данных. Устройства , реализующие НЭП настоятельно рекомендуется поддержка 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 экземпляр с набором LockScreen на основном пользователе. Затем adb оболочки в устройство и использовать su , чтобы стать корнем. Убедитесь , /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, должны быть выполнены три требования:

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

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

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

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

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