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

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

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

Все устройства с ОС Android 10 и выше обязаны использовать шифрование файлов.

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

Шифрование файлов позволяет использовать новую функцию, представленную в Android 7.0, под названием Direct Boot . 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 в каталоге frameworks или packages исходного дерева AOSP.

Зависимости

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

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

Выполнение

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

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

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-hctr2 . Если не указано иное, по умолчанию используется 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 позволяет использовать аппаратно защищённые ключи для FBE. Этот флаг можно использовать только в сочетании с опцией монтирования inlinecrypt и флагом inlinecrypt_optimized или emmc_optimized .
  • Флаг dusize_4k устанавливает размер блока данных шифрования равным 4096 байт, даже если размер блока файловой системы отличается от 4096 байт. Размер блока данных шифрования определяет степень детализации шифрования содержимого файла. Этот флаг доступен начиная с Android 15. Этот флаг следует использовать только для включения встроенного аппаратного обеспечения шифрования, не поддерживающего блоки данных размером более 4096 байт, на устройстве с размером страницы более 4096 байт и файловой системой f2fs.

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

Начиная с Android 14, AES-HCTR2 является предпочтительным режимом шифрования имён файлов для устройств с ускоренными инструкциями криптографии. Однако только новые ядра Android поддерживают AES-HCTR2. В будущем выпуске Android планируется сделать его режимом по умолчанию для шифрования имён файлов. Если ваше ядро ​​поддерживает AES-HCTR2, его можно включить для шифрования имён файлов, установив параметр filenames_encryption_mode в значение aes-256-hctr2 . В простейшем случае это можно сделать с помощью fileencryption=aes-256-xts:aes-256-hctr2 .

На устройствах с 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, FBE и адаптивное хранилище можно использовать вместе.

Указание параметра fstab fileencryption для userdata также автоматически включает шифрование FBE и метаданных на адаптивном хранилище. Однако вы можете переопределить форматы шифрования FBE или метаданных на адаптивном хранилище, настроив свойства в 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 выбирают формат шифрования метаданных на доступном хранилище. См. документацию по шифрованию метаданных .

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

Уровень HAL KeyMint следует запускать как часть класса early_hal . Это связано с тем, что FBE требует, чтобы KeyMint был готов обрабатывать запросы к моменту загрузки post-fs-data , когда vold устанавливает начальные ключи.

Исключить каталоги

init применяет системный ключ DE ко всем каталогам верхнего уровня /data , за исключением каталогов, которые должны быть незашифрованными, например, каталога, содержащего сам системный ключ DE, и каталогов, содержащих пользовательские каталоги CE или DE. Ключи шифрования применяются рекурсивно и не могут быть переопределены подкаталогами.

В Android 11 и более поздних версиях ключ, применяемый init к каталогам, можно контролировать с помощью аргумента encryption=<action> команды mkdir в скриптах init. Возможные значения <action> описаны в файле README для языка init Android .

В Android 10 действия init шифрования были жестко запрограммированы в следующем месте:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

В Android 9 и более ранних версиях местоположение было следующим:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

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

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

Включите поддержку Direct Boot в приложениях

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

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

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

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

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

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

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

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

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

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

Каждый идентификатор пользователя рабочего профиля также получает два ключа: DE и CE. После выполнения рабочего задания профиль пользователя разблокируется, и KeyMint (в 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

Кроме того, тестировщики могут проверить, заблокировано ли хранилище CE до первой разблокировки устройства после загрузки. Для этого используйте сборку userdebug или eng , установите PIN-код, графический ключ или пароль для основного пользователя и перезагрузите устройство. Перед разблокировкой устройства выполните следующую команду, чтобы проверить хранилище CE основного пользователя. Если устройство использует режим пользователя Headless System (большинство автомобильных устройств), основным пользователем будет пользователь 10, поэтому выполните:

adb root; adb shell ls /data/user/10

На других устройствах (большинстве неавтомобильных устройств) основным пользователем является пользователь 0, поэтому выполните:

adb root; adb shell ls /data/user/0

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

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

Подробности реализации AOSP

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

шифрование fscrypt

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

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

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

fscrypt поддерживает две версии политик шифрования: версию 1 и версию 2. Версия 1 устарела, а требования CDD для устройств с Android 11 и выше совместимы только с версией 2. Политики шифрования версии 2 используют HKDF-SHA512 для получения фактических ключей шифрования из ключей, предоставленных пространством пользователя.

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

Классы хранения

В следующей таблице более подробно перечислены ключи FBE и каталоги, которые они защищают:

Хранение и защита ключей

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

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

vold также применяет слой шифрования ко всем ключам FBE. Каждый ключ, кроме ключей CE для внутреннего хранилища, шифруется с помощью AES-256-GCM с использованием собственного ключа хранилища ключей , который не раскрывается за пределами TEE. Это гарантирует, что ключи FBE не могут быть разблокированы, пока не загрузится доверенная операционная система, как это обеспечивается Verified Boot . Для ключа хранилища ключей также запрашивается устойчивость к откату, что позволяет безопасно удалять ключи FBE на устройствах, где KeyMint поддерживает устойчивость к откату. В качестве наилучшего запасного варианта на случай, когда устойчивость к откату недоступна, в качестве Tag::APPLICATION_ID ключа хранилища ключей используется хэш SHA-512 из 16384 случайных байтов, хранящийся в файле secdiscardable , который хранится вместе с ключом. Все эти байты необходимо восстановить для восстановления ключа FBE.

Ключи CE для внутреннего хранилища получили усиленный уровень защиты, гарантирующий невозможность разблокировки без знания фактора знания экрана блокировки (LSKF) пользователя (PIN-кода, графического ключа или пароля), безопасного токена сброса пароля или обоих ключей (клиентского и серверного) для возобновления работы при перезагрузке . Токены сброса пароля разрешено создавать только для рабочих профилей и полностью управляемых устройств .

Для этого vold шифрует каждый ключ CE для внутреннего хранилища с помощью ключа AES-256-GCM, полученного из синтетического пароля пользователя. Синтетический пароль представляет собой неизменяемый высокоэнтропийный криптографический секрет, который генерируется случайным образом для каждого пользователя. LockSettingsService в system_server управляет синтетическим паролем и способами его защиты.

Чтобы защитить синтетический пароль с помощью LSKF, LockSettingsService сначала растягивает LSKF, пропуская его через scrypt , устанавливая время выполнения около 25 мс и использование памяти около 2 МБ. Поскольку LSKF обычно короткие, этот шаг обычно не обеспечивает высокой безопасности. Основной уровень безопасности — это Secure Element (SE) или ограничение скорости на основе TEE, описанное ниже.

Если устройство имеет элемент безопасности (SE), то LockSettingsService сопоставляет растянутый LSKF со случайным секретом с высокой энтропией, хранящимся в SE, используя Weaver HAL . Затем LockSettingsService дважды шифрует синтетический пароль: сначала с помощью программного ключа, полученного из растянутого LSKF и секрета Weaver, а затем с помощью ключа хранилища ключей без привязки к аутентификации. Это обеспечивает ограничение скорости перебора LSKF, обеспечиваемое SE.

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

При изменении LSKF LockSettingsService удаляет всю информацию, связанную с привязкой синтетического пароля к старому LSKF. На устройствах с поддержкой ключей Weaver или ключей Keystore, устойчивых к откату, это гарантирует безопасное удаление старой привязки. Поэтому описанные здесь меры защиты применяются даже при отсутствии у пользователя LSKF.