Функции

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

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

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

  • Генерация ключей
  • Импорт и экспорт асимметричных ключей (без переноса ключей)
  • Импорт необработанных симметричных ключей (без переноса ключей)
  • Асимметричное шифрование и дешифрование с соответствующими режимами заполнения.
  • Асимметричное подписание и проверка с дайджестом и соответствующими режимами заполнения.
  • Симметричное шифрование и дешифрование в соответствующих режимах, включая режим AEAD.
  • Генерация и проверка симметричных кодов аутентификации сообщений

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

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

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

Все реализации Keymaster обеспечивают:

  • ЮАР
    • Поддержка 2048, 3072 и 4096-битных ключей.
    • Поддержка публичного показателя F4 (2^16+1)
    • Режимы заполнения для подписи RSA:
      • RSASSA-PSS ( PaddingMode::RSA_PSS )
      • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
    • Режимы дайджеста для подписи RSA:
      • ША-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:
      • Нет дайджеста (устарело, будет удалено в будущем)
      • ША-256
  • АЕС
    • Поддерживаются 128- и 256-битные ключи.
    • CBC , CTR, ECB и GCM. Реализация GCM не позволяет использовать теги длиной менее 96 бит или длину nonce, отличную от 96 бит.
    • Режимы заполнения PaddingMode::NONE и PaddingMode::PKCS7 поддерживаются для режимов CBC и ECB. Без заполнения шифрование в режиме CBC или ECB завершается неудачно, если входные данные не кратны размеру блока.
  • HMAC SHA-256 с любым размером ключа до 32 байт.

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

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

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

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

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

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

Для 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 .

UINT : 32-битные целые числа без знака. Пример: TAG::KEY_SIZE

UINT_REP : То же, что и UINT , за исключением того, что тег может повторяться в списке авторизации. Повторение указывает на несколько разрешенных значений.

ULONG : 64-битные целые числа без знака. Пример: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : То же, что и ULONG , за исключением того, что тег может повторяться в списке авторизации. Повторение указывает на несколько разрешенных значений.

DATE : значения даты/времени, выраженные в миллисекундах с 1 января 1970 года. Пример: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL : Правда или ложь. Тег типа BOOL считается «ложным», если тег отсутствует, и «истиным», если он присутствует. Пример: TAG::ROLLBACK_RESISTANT

BIGNUM : целые числа произвольной длины, выраженные в виде массива байтов в порядке обратного байта. Пример: TAG::RSA_PUBLIC_EXPONENT

BYTES : последовательность байтов. Пример: TAG::ROOT_OF_TRUST

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

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

Все реализации:

  • Обеспечьте точное соответствие (не принудительное исполнение) всех разрешений. Списки полномочий в больших двоичных объектах ключей точно соответствуют полномочиям, возвращаемым во время создания ключей, включая их порядок. Любое несоответствие приводит к диагностике ошибок.
  • Объявите полномочия, семантические значения которых применяются.

Механизм API для объявления аппаратных авторизаций находится в структуре keymaster_key_characteristics_t . Он делит список авторизации на два подсписка: hw_enforced и sw_enforced . Безопасное оборудование отвечает за размещение соответствующих значений в каждом из них в зависимости от того, что оно может обеспечить.

Кроме того, Keystore реализует программное обеспечение всех авторизаций, независимо от того, выполняются ли они безопасным оборудованием или нет.

Например, рассмотрим реализацию на основе TrustZone, которая не поддерживает истечение срока действия ключа. Ключ со сроком действия все равно может быть создан. Список авторизации этого ключа будет включать тег TAG::ORIGINATION_EXPIRE_DATETIME с датой истечения срока действия. При запросе к хранилищу ключей ключевых характеристик этот тег будет найден в списке sw_enforced , и защищенное оборудование не будет применять требование об истечении срока действия. Однако попытки использовать ключ после истечения срока его действия будут отклонены хранилищем ключей.

Если затем устройство будет обновлено с использованием безопасного оборудования, которое поддерживает срок действия, то при запросе ключевых характеристик будет найден TAG::ORIGINATION_EXPIRE_DATETIME в списке hw_enforced , и попытки использовать ключ после истечения срока действия завершится неудачей, даже если хранилище ключей каким-либо образом подорвано или обойдено. .

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

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

Следующие теги используются для определения криптографических характеристик операций с использованием связанного ключа: TAG::ALGORITHM , TAG::KEY_SIZE , TAG::BLOCK_MODE , TAG::PADDING , TAG::CALLER_NONCE и TAG::DIGEST

TAG::PADDING , TAG::DIGEST и PaddingMode::BLOCK_MODE являются повторяемыми, что означает, что с одним ключом может быть связано несколько значений, а используемое значение указывается во время операции.

Цель

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

  • KeyPurpose::ENCRYPT
  • KeyPurpose::DECRYPT
  • KeyPurpose::SIGN
  • KeyPurpose::VERIFY

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

Импорт и экспорт

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

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

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

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

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

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

  • TAG::ALL_USERS указывает, что ключ может использоваться всеми пользователями. Если они присутствуют, TAG::USER_ID и TAG::USER_SECURE_ID отсутствуют.
  • TAG::USER_ID имеет числовое значение, определяющее идентификатор авторизованного пользователя. Обратите внимание, что это идентификатор пользователя Android (для многопользовательской работы), а не UID приложения, и он применяется только незащищенным программным обеспечением. Если присутствует, TAG::ALL_USERS отсутствует.
  • TAG::USER_SECURE_ID имеет 64-битное числовое значение, определяющее безопасный идентификатор пользователя, который предоставляется в безопасном токене аутентификации для разблокировки использования ключа. При повторении ключ можно использовать, если какое-либо из значений указано в токене безопасной аутентификации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привязка корня доверия

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

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

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

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

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

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

Скорость

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

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

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

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

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

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

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

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