Функции

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

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

Компания Keystore предоставляет следующие категории услуг:

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

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

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

В дополнение к перечисленному выше, существует еще одна услуга, предоставляемая реализациями KeyMint (ранее Keymaster), которая не доступна через API: генерация случайных чисел. Она используется внутри системы для генерации ключей, векторов инициализации (IV), случайного заполнения и других элементов защищенных протоколов, требующих случайности.

Необходимые примитивы

Все реализации KeyMint предоставляют следующие возможности:

• ЮАР
  • Поддержка ключей 2048, 3072 и 4096 бит.
  • Поддержка публичного показателя F4 (2^16+1)
  • Режимы заполнения для подписи RSA:
    • RSASSA-PSS ( PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
  • Режимы дайджеста для подписи RSA:
    • SHA-256
  • Режимы заполнения для шифрования/дешифрования RSA:
    • Без подкладки
    • RSAES-OAEP ( PaddingMode::RSA_OAEP )
    • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
• ECDSA
  • Поддерживаются ключи размером 224, 256, 384 и 521 бит, с использованием кривых NIST P-224, P-256, P-384 и P-521 соответственно.
  • Режимы дайджеста для ECDSA:
    • Функция "Нет дайджеста" (устарела, будет удалена в будущем)
    • SHA-256
• АЭС
  • Поддерживаются ключи 128 и 256 бит.
  • CBC , CTR, ECB и GCM. Реализация GCM не допускает использования тегов меньше 96 бит или длин одноразовых чисел, отличных от 96 бит.
  • Для режимов CBC и ECB поддерживаются режимы заполнения PaddingMode::NONE и PaddingMode::PKCS7 . Без заполнения шифрование в режимах CBC или ECB завершается неудачей, если размер входных данных не кратен размеру блока.
• HMAC SHA-256 , с любым размером ключа не менее 32 байт.

Для реализаций KeyMint настоятельно рекомендуется использовать SHA1 и другие члены семейства SHA2 (SHA-224, SHA384 и SHA512). Keystore предоставляет их программно, если аппаратная реализация KeyMint их не предоставляет.

Некоторые примитивы также рекомендуются для обеспечения совместимости с другими системами:

• Уменьшенные размеры ключей для RSA
• Произвольные публичные экспоненты для RSA

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

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

Контроль доступа определяется как «список авторизации», состоящий из пар тег/значение. Теги авторизации представляют собой 32-битные целые числа, а значения могут быть различных типов. Некоторые теги могут повторяться для указания нескольких значений. Возможность повторения тега указывается в интерфейсе KeyMint HAL. При создании ключа вызывающая сторона указывает список авторизации. Реализация KeyMint, лежащая в основе Keystore, изменяет этот список, чтобы указать некоторую дополнительную информацию, например, имеет ли ключ защиту от отката, и возвращает «окончательный» список авторизации, закодированный в возвращаемом блоке ключа. Любая попытка использовать ключ для какой-либо криптографической операции завершится неудачей, если окончательный список авторизации будет изменен.

Для Keymaster 2 и более ранних версий набор возможных тегов определяется в перечислении keymaster_authorization_tag_t и является постоянно фиксированным (хотя может быть расширен). Имена тегов имели префикс KM_TAG . Для указания типа используются четыре старших бита идентификаторов тегов.

В Keymaster 3 префикс KM_TAG был изменен на Tag:: .

Возможные типы включают:

ENUM : Значения многих тегов определены в перечислениях. Например, возможные значения TAG::PURPOSE определены в перечислении keymaster_purpose_t .

ENUM_REP : То же самое, что и ENUM , за исключением того, что тег может повторяться в списке авторизации. Повторение указывает на наличие нескольких разрешенных значений. Например, ключ шифрования, скорее всего, будет иметь KeyPurpose::ENCRYPT и KeyPurpose::DECRYPT .

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

Аппаратное и программное обеспечение для обеспечения соблюдения правил

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

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

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

Импорт ключей

Keymaster поддерживает только экспорт открытых ключей в формате X.509, а также импорт следующих ключей:

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

Для того чтобы импортированные ключи можно было отличить от ключей, сгенерированных безопасным способом, в соответствующий список авторизации ключей включается Tag::ORIGIN . Например, если ключ был сгенерирован на защищенном оборудовании, в списке характеристик ключа hw_enforced будет найден Tag::ORIGIN со значением KeyOrigin::GENERATED , тогда как ключ, импортированный на защищенное оборудование, будет иметь значение 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 будет скомпрометирован во время блокировки устройства.

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

UnlockedDeviceRequired super keys

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

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

• Симметричный суперключ UnlockedDeviceRequired. Это ключ AES‑256‑GCM. Он шифрует ключи UNLOCKED_DEVICE_REQUIRED , которые импортируются, генерируются или используются, когда устройство разблокировано для пользователя.
• Асимметричный суперключ UnlockedDeviceRequired. Это пара ключей ECDH P-521. Он шифрует ключи UNLOCKED_DEVICE_REQUIRED , импортированные или сгенерированные, когда устройство заблокировано для пользователя. Для получения дополнительной информации см. раздел «Хранение ключей, когда устройство заблокировано» .

Создание и защита суперключей

При создании пользователя Keystore генерирует суперключи UnlockedDeviceRequired и сохраняет их в своей базе данных, зашифрованные (косвенно) с помощью синтетического пароля пользователя:

1. Системный сервер формирует пароль хранилища ключей пользователя на основе его синтетического пароля с помощью модуля KDF SP800‑108.
2. Системный сервер передает пароль пользователя из хранилища ключей в хранилище ключей.
3. Keystore генерирует суперключи пользователя.
4. Для каждой из суперклавиш пользователя:
   1. Keystore генерирует случайную соль.
   2. Keystore генерирует ключ AES-256-GCM из пароля пользователя и соли, используя алгоритм HKDF-SHA256.
   3. Keystore шифрует секретную часть суперключа с помощью ключа AES-256-GCM.
   4. В хранилище ключей (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).

Сохранение ключей при заблокированном устройстве.

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

• Шифрование (импорт или генерация ключа UNLOCKED_DEVICE_REQUIRED , пока устройство заблокировано):
  1. Keystore генерирует новую временную пару ключей ECDH P-521.
  2. Keystore генерирует общий секрет путем согласования ключей ECDH между закрытым ключом этой временной пары ключей и открытой половиной асимметричного суперключа UnlockedDeviceRequired.
  3. Keystore генерирует случайную соль.
  4. Keystore вычисляет ключ AES-256-GCM из общего секрета и соли, используя алгоритм HKDF-SHA256.
  5. Keystore шифрует ключ UNLOCKED_DEVICE_REQUIRED с помощью ключа AES‑256‑GCM.
  6. В базе данных Keystore хранятся зашифрованный ключ UNLOCKED_DEVICE_REQUIRED , соль и открытая половина пары временных ключей.
• Расшифровка (с использованием созданного ключа UNLOCKED_DEVICE_REQUIRED , пока устройство разблокировано):
  1. Keystore загружает из своей базы данных зашифрованный ключ UNLOCKED_DEVICE_REQUIRED , соль и открытую половину пары временных ключей.
  2. Keystore генерирует общий секрет путем согласования ключей ECDH между открытой половиной пары временных ключей и закрытой половиной асимметричного суперключа UnlockedDeviceRequired. Закрытый ключ доступен, поскольку устройство разблокировано.
  3. Keystore генерирует ключ AES-256-GCM из общего секрета и соли, используя алгоритм HKDF-SHA256. Этот ключ AES-256-GCM идентичен ключу, полученному в процессе шифрования.
  4. Keystore расшифровывает ключ UNLOCKED_DEVICE_REQUIRED используя ключ AES‑256‑GCM.
  5. Keystore повторно шифрует ключ UNLOCKED_DEVICE_REQUIRED используя симметричный суперключ UnlockedDeviceRequired. Это не влияет на свойства безопасности ключа, но позволяет быстрее получить к нему доступ в дальнейшем.

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

1. Сгенерируйте ключ AES-256-GCM вне хранилища ключей.
2. Шифрование данных с использованием ключа AES‑256‑GCM.
3. Импортируйте ключ AES‑256‑GCM в Keystore, установив параметр защиты ключа setUnlockedDeviceRequired(true) .
4. Обнулите исходную копию ключа.

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

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

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

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

Срок действия

Keystore поддерживает ограничение использования ключей по дате. Начало действия ключа и истечение срока его действия могут быть связаны с ключом, и Keymaster отказывается выполнять операции с ключом, если текущая дата/время выходит за пределы допустимого диапазона. Диапазон действия ключа указывается с помощью тегов 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 операционной системой, установленной злоумышленником.

Автономные ключи

Некоторые защищенные аппаратные средства KeyMint могут хранить ключевой материал внутри себя и возвращать дескрипторы вместо зашифрованного ключевого материала. Или могут быть другие случаи, когда ключи нельзя использовать до тех пор, пока не станет доступен какой-либо другой компонент небезопасной или безопасной системы. KeyMint HAL позволяет вызывающей стороне запросить, чтобы ключ был «автономным», используя тег TAG::STANDALONE , что означает, что не требуются никакие ресурсы, кроме самого BLOB-объекта и работающей системы KeyMint. Теги, связанные с ключом, можно проверить, является ли ключ автономным. В настоящее время определены только два значения:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

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

Скорость

При создании объекта максимальная скорость его использования может быть указана с помощью TAG::MIN_SECONDS_BETWEEN_OPS . Реализации TrustZone отказываются выполнять криптографические операции с этим ключом, если операция была выполнена менее чем за TAG::MIN_SECONDS_BETWEEN_OPS секунд до этого.

Простой подход к реализации ограничений скорости заключается в использовании таблицы идентификаторов ключей и меток времени последнего использования. Эта таблица имеет ограниченный размер, но вмещает как минимум 16 записей. В случае, если таблица заполнена и ни одна запись не может быть обновлена ​​или удалена, защищенные аппаратные реализации переходят в режим «безопасного отказа», предпочитая отклонять все операции с ключами, скорость которых ограничена, до тех пор, пока не истечет срок действия одной из записей. Допустимо, чтобы все записи истекали при перезагрузке.

Количество использований ключей за одну загрузку также можно ограничить значением TAG::MAX_USES_PER_BOOT . Для этого также требуется таблица отслеживания, которая вмещает как минимум четыре ключа и обеспечивает отказоустойчивость. Обратите внимание, что приложения не могут создавать ключи с ограничением на количество загрузок. Эта функция не доступна через Keystore и зарезервирована для системных операций.

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

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

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

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