Функции

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

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

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

  • Генерация ключей
  • Импорт и экспорт асимметричных ключей (без переноса ключей)
  • Импорт необработанных симметричных ключей (без упаковки ключей)
  • Асимметричное шифрование и дешифрование с соответствующими режимами заполнения
  • Асимметричная подпись и проверка с дайджестом и соответствующими режимами заполнения
  • Симметричное шифрование и дешифрование в соответствующих режимах, включая режим 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 )
  • ЭЦДСА
    • Поддерживается поддержка 224, 256, 384 и 521-битных ключей с использованием кривых NIST P-224, P-256, P-384 и P-521 соответственно.
    • Режимы дайджеста для ECDSA:
      • Нет дайджеста (устарело, будет удалено в будущем)
      • ША-256
  • АЕС
    • Поддерживаются 128 и 256-битные ключи.
    • CBC , CTR, ECB и GCM. Реализация GCM не позволяет использовать теги размером менее 96 бит или длину одноразового номера, отличную от 96 бит.
    • Режимы PaddingMode::NONE и PaddingMode::PKCS7 поддерживаются для режимов CBC и ECB. Без заполнения шифрование в режиме CBC или ECB завершается ошибкой, если входные данные не кратны размеру блока.
  • HMAC SHA-256 с любым размером ключа не менее 32 байт.

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

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

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

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

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

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

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

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

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

ENUM : значения многих тегов определены в перечислениях. Например, возможные значения TAG::PURPOSE определены в enum 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 различает безопасное и небезопасное обеспечение контроля доступа во всем мире, а также аппаратное и программное обеспечение, соответственно.

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

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

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

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

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

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

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

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