Функции

На этой странице содержится информация о криптографических функциях Android Keystore , предоставляемых базовой реализацией KeyMint (или Keymaster).

Криптографические примитивы

Keystore предоставляет следующие категории операций:

• Создание ключей, результатом чего является закрытый или секретный ключевой материал, доступный только для защищенной среды. Клиенты могут создавать ключи следующими способами:
  • Генерация нового ключа
  • Импорт незашифрованного ключевого материала
  • Импорт зашифрованного ключевого материала
• Подтверждение ключа: создание асимметричного ключа генерирует сертификат, содержащий часть открытого ключа пары ключей. Этот сертификат опционально также содержит информацию о метаданных ключа и состоянии устройства, все подписано цепочкой ключей, связывающей их с доверенным корнем.
• Криптографические операции:
  • Симметричное шифрование и дешифрование (AES, 3DES)
  • Асимметричное дешифрование (RSA)
  • Асимметричная подпись (ECDSA, RSA)
  • Симметричное подписание и проверка (HMAC)
  • Асимметричное соглашение о ключе (ECDH)

Обратите внимание, что Keystore и KeyMint не обрабатывают операции с открытыми ключами для асимметричных ключей.

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

Примитивы и режимы, которые должны поддерживаться реализацией KeyMint, описаны в спецификации интерфейса HAL IKeyMintDevice .

Базовая реализация KeyMint должна выполнять генерацию случайных чисел для поддержки генерации ключей и создания рандомизированных векторов заполнения или инициализации (IV). Для поддержки этого система Android периодически предоставляет дополнительную энтропию реализации KeyMint.

Контроль доступа по ключу

Аппаратные ключи, которые никогда не могут быть извлечены из устройства, не обеспечивают достаточной безопасности, если злоумышленник может использовать их по своему усмотрению (хотя они более безопасны, чем ключи, которые могут быть украдены). Таким образом, крайне важно, чтобы Keystore обеспечивал контроль доступа.

Элементы управления доступом определяются как «список авторизации» пар тег/значение. Теги авторизации представляют собой 32-битные целые числа, а значения — различные типы. Некоторые теги могут повторяться для указания нескольких значений. Возможность повторения тега указывается в интерфейсе HAL KeyMint (ранее Keymaster).

Поддерживаемые значения тегов определены в файле Tag.aidl , и каждое связано с TagType , который указывает тип связанного значения (например, целое число или байты), а также может ли оно повторяться для указания нескольких поддерживаемых значений.

Когда KeyMint создает ключ, вызывающая сторона указывает список авторизации для ключа. Этот список изменяется Keystore и KeyMint для добавления дополнительных ограничений, а базовая реализация KeyMint кодирует окончательный список авторизации в возвращаемый keyblob. Закодированный список авторизации криптографически связан с keyblob, так что любая попытка изменить список авторизации (включая упорядочение) приводит к недействительному keyblob, который нельзя использовать для криптографических операций.

Аппаратное и программное обеспечение

Не все безопасные аппаратные реализации содержат одинаковые функции. Для поддержки различных подходов KeyMint различает безопасное и небезопасное принудительное исполнение контроля доступа, или аппаратное и программное принудительное исполнение, соответственно.

Это представлено в API KeyMint с помощью поля securityLevel типа KeyCharacteristics . Защищенное оборудование отвечает за размещение авторизаций в KeyCharacteristics с соответствующим уровнем безопасности на основе того, что оно может обеспечить. Эта информация также представлена ​​в записях подтверждения для асимметричных ключей: характеристики ключа для SecurityLevel::TRUSTED_ENVIRONMENT или SecurityLevel::STRONGBOX отображаются в списке hardwareEnforced , а характеристики для SecurityLevel::SOFTWARE или SecurityLevel::KEYSTORE отображаются в списке softwareEnforced .

Например, ограничения на дату и временной интервал, когда ключ может быть использован, обычно не применяются безопасной средой, поскольку у нее нет надежного доступа к информации о дате и времени. В результате авторизации, такие как Tag::ORIGINATION_EXPIRE_DATETIME применяются Keystore в Android и будут иметь SecurityLevel::KEYSTORE .

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

Разрешения на создание криптографических сообщений

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

• Tag::ALGORITHM
• Tag::KEY_SIZE
• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::CALLER_NONCE
• Tag::DIGEST
• Tag::MGF_DIGEST

Следующие теги являются повторяющимися, что означает, что с одним ключом можно связать несколько значений:

• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::DIGEST
• Tag::MGF_DIGEST

Значение, которое будет использоваться, указывается во время операции.

Цель

Ключи имеют связанный набор целей, выраженный как одна или несколько записей авторизации с Tag::PURPOSE , который определяет, как их можно использовать. Цели определены в KeyPurpose.aidl .

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

Импорт ключа

KeyMint поддерживает импорт:

• Асимметричные пары ключей в формате PKCS#8 с кодировкой DER (без шифрования на основе пароля)
• Симметричные ключи как необработанные байты

Чтобы гарантировать, что импортированные ключи можно отличить от безопасно сгенерированных ключей, Tag::ORIGIN включен в соответствующий список авторизации ключей. Например, если ключ был сгенерирован в защищенном оборудовании, Tag::ORIGIN со значением KeyOrigin::GENERATED находится в списке hw_enforced характеристик ключа, в то время как ключ, импортированный в защищенное оборудование, имеет значение KeyOrigin::IMPORTED .

Аутентификация пользователя

Безопасные реализации KeyMint не реализуют аутентификацию пользователя, но зависят от других доверенных приложений, которые это делают. Интерфейс, реализуемый этими приложениями, см. на странице Gatekeeper .

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

• Tag::USER_SECURE_ID имеет 64-битное числовое значение, указывающее защищенный идентификатор пользователя , который предоставляется в защищенном токене аутентификации для разблокировки использования ключа. При повторении ключ может быть использован, если любое из значений предоставляется в защищенном токене аутентификации.

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

• Tag::NO_AUTHENTICATION_REQUIRED указывает на то, что аутентификация пользователя не требуется, хотя доступ к ключу по-прежнему ограничен приложением-владельцем (и любыми приложениями, которым он предоставляет доступ).
• Tag::AUTH_TIMEOUT — числовое значение, указывающее в секундах, насколько свежей должна быть аутентификация пользователя для авторизации использования ключа. Тайм-ауты не пересекают перезагрузки; после перезагрузки все аутентификации становятся недействительными. Тайм-аут может быть установлен на большое значение, чтобы указать, что аутентификация требуется один раз за загрузку (2^32 секунды — это ~136 лет; предположительно, устройства Android перезагружаются чаще).

Требуется разблокированное устройство

Ключи с Tag::UNLOCKED_DEVICE_REQUIRED можно использовать только пока устройство разблокировано. Подробную семантику см. в KeyProtection.Builder#setUnlockedDeviceRequired(boolean) .

UNLOCKED_DEVICE_REQUIRED обеспечивается Keystore, а не KeyMint. Однако в Android 12 и выше Keystore криптографически защищает ключи UNLOCKED_DEVICE_REQUIRED , пока устройство заблокировано, чтобы гарантировать, что в большинстве случаев их нельзя будет использовать, даже если Keystore будет скомпрометирован, пока устройство заблокировано.

Для достижения этого Keystore «супершифрует» все ключи UNLOCKED_DEVICE_REQUIRED перед сохранением их в своей базе данных и, когда это возможно, защищает ключи супершифрования (суперключи), пока устройство заблокировано таким образом, что их можно восстановить только путем успешной разблокировки устройства. (Термин «супершифрование» используется потому, что этот уровень шифрования применяется в дополнение к уровню шифрования, который KeyMint уже применяет ко всем ключам.)

У каждого пользователя (включая профили) есть два суперключа, связанных с UNLOCKED_DEVICE_REQUIRED :

• Симметричный суперключ UnlockedDeviceRequired. Это ключ AES‑256‑GCM. Он шифрует ключи UNLOCKED_DEVICE_REQUIRED , которые импортируются или генерируются, когда устройство разблокировано для пользователя.
• Асимметричный суперключ UnlockedDeviceRequired. Это пара ключей ECDH P‑521. Он шифрует ключи UNLOCKED_DEVICE_REQUIRED , которые импортируются или генерируются, когда устройство заблокировано для пользователя. Ключи, зашифрованные этим асимметричным ключом, повторно шифруются симметричным ключом при первом использовании (что может произойти только при разблокированном устройстве).

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

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

• Если у пользователя включен только PIN-код, шаблон или пароль, то Keystore обнуляет секретные части своих кэшированных суперключей. Это делает суперключи восстанавливаемыми только через зашифрованную копию в базе данных, которую можно расшифровать только с помощью эквивалента PIN-кода, шаблона или пароля.
• Если у пользователя есть только биометрические данные класса 3 («сильные») и включен PIN-код, шаблон или пароль, то Keystore обеспечивает возможность восстановления суперключей с помощью любых зарегистрированных биометрических данных класса 3 пользователя (обычно отпечатков пальцев) в качестве альтернативы эквиваленту PIN-кода, шаблона или пароля. Для этого он генерирует новый ключ AES-256-GCM, шифрует им секретные части суперключей, импортирует ключ AES-256-GCM в KeyMint как биометрически привязанный ключ, требующий успешной биометрической аутентификации в течение последних 15 секунд, и обнуляет копии всех этих ключей в открытом виде.
• Если у пользователя включена биометрическая защита класса 1 («удобная»), биометрическая защита класса 2 («слабая») или активный агент доверия разблокировки, то Keystore сохраняет суперключи в кэше в виде открытого текста. В этом случае криптографическая защита для ключей UNLOCKED_DEVICE_REQUIRED не предоставляется. Пользователи могут избежать этого менее безопасного отката, не включив эти методы разблокировки. Наиболее распространенными методами разблокировки, которые попадают в эти категории, являются разблокировка по лицу на многих устройствах и разблокировка с помощью сопряженных умных часов.

Когда устройство разблокировано для пользователя, Keystore восстанавливает суперключи пользователя UnlockedDeviceRequired, если это возможно. Для разблокировки с помощью PIN-кода, шаблона или эквивалента пароля он расшифровывает копию этих ключей, хранящуюся в базе данных. В противном случае он проверяет, сохранил ли он копию этих ключей, зашифрованную с помощью биометрического ключа, и если да, пытается расшифровать ее. Это удается только в том случае, если пользователь успешно прошел аутентификацию с помощью биометрии класса 3 в течение последних 15 секунд, что обеспечивается KeyMint (не Keystore).

Привязка клиента

Привязка клиента, ассоциация ключа с определенным клиентским приложением, выполняется через необязательный идентификатор клиента и некоторые необязательные данные клиента ( Tag::APPLICATION_ID и Tag::APPLICATION_DATA соответственно). Keystore обрабатывает эти значения как непрозрачные BLOB-объекты, гарантируя только то, что те же BLOB-объекты, представленные во время генерации/импорта ключа, представлены для каждого использования и идентичны байт в байт. Данные привязки клиента не возвращаются KeyMint. Вызывающий должен знать их, чтобы использовать ключ.

Эта функция недоступна для приложений.

Истечение срока действия

Keystore поддерживает ограничение использования ключа по дате. Начало действия ключа и истечение срока действия ключа могут быть связаны с ключом, и Keystore отказывается выполнять операции с ключом, если текущая дата/время находятся за пределами допустимого диапазона. Диапазон действия ключа указывается с помощью тегов Tag::ACTIVE_DATETIME , Tag::ORIGINATION_EXPIRE_DATETIME и Tag::USAGE_EXPIRE_DATETIME . Различие между «происхождением» и «использованием» основано на том, используется ли ключ для «создания» нового шифротекста/подписи и т. д. или для «использования» существующего шифротекста/подписи и т. д. Обратите внимание, что это различие не отображается для приложений.

Теги Tag::ACTIVE_DATETIME , Tag::ORIGINATION_EXPIRE_DATETIME и Tag::USAGE_EXPIRE_DATETIME являются необязательными. Если теги отсутствуют, предполагается, что рассматриваемый ключ всегда может быть использован для расшифровки/проверки сообщений.

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

Корень доверия привязки

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

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

Повторная загрузка генератора случайных чисел

Поскольку защищенное оборудование генерирует случайные числа для ключевого материала и векторов инициализации (IV), а также поскольку аппаратные генераторы случайных чисел не всегда могут быть полностью надежными, KeyMint HAL предоставляет интерфейс, позволяющий Keystore предоставлять дополнительную энтропию, которая подмешивается к генерируемым случайным числам.

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