Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Keystore с аппаратной поддержкой

Наличие надежной среды выполнения в системе на кристалле (SoC) дает возможность устройствам Android предоставлять аппаратные, надежные службы безопасности для ОС Android, для платформ и даже для сторонних приложений. Разработчики, ищущие специфичные для Android расширения, должны зайти в android.security.keystore .

До версии Android 6.0 в Android уже был простой аппаратный API-интерфейс криптографических служб, предоставляемый версиями 0.2 и 0.3 уровня аппаратного абстрагирования от ключей (HAL). Keystore обеспечивает операции цифровой подписи и проверки, а также генерацию и импорт пар ключей асимметричной подписи. Это уже реализовано на многих устройствах, но есть много целей безопасности, которые не могут быть легко достигнуты только с помощью API подписи. Keystore в Android 6.0 расширяет API Keystore, предоставляя более широкий спектр возможностей.

В Android 6.0 в Keystore добавлены симметричные криптографические примитивы , AES и HMAC, а также система контроля доступа для ключей с аппаратной поддержкой. Контроль доступа указывается при генерации ключа и применяется в течение всего срока действия ключа. Ключи могут быть ограничены для использования только после аутентификации пользователя и только для указанных целей или с указанными криптографическими параметрами. Для получения дополнительной информации см. Страницы « Теги авторизации и функции» .

В дополнение к расширению спектра криптографических примитивов, Keystore в Android 6.0 добавляет следующее:

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

В Android 7.0 в Keymaster 2 добавлена ​​поддержка аттестации ключей и привязки версий. Аттестация ключа предоставляет сертификаты открытых ключей, которые содержат подробное описание ключа и его элементов управления доступом, чтобы обеспечить возможность удаленной проверки существования ключа на защищенном оборудовании и его конфигурации.

Привязка версии связывает ключи с версией операционной системы и версии патча. Это гарантирует, что злоумышленник, обнаруживший уязвимость в старой версии системы или программного обеспечения TEE, не сможет откатить устройство до уязвимой версии и использовать ключи, созданные в более новой версии. Кроме того, когда ключ с заданной версией и уровнем исправления используется на устройстве, которое было обновлено до более новой версии или уровня исправления, ключ обновляется, прежде чем его можно использовать, и предыдущая версия ключа становится недействительной. Когда устройство модернизируется, клавиши «растягиваются» вперед вместе с устройством, но любое возвращение устройства к предыдущему выпуску приводит к невозможности использования ключей.

В Android 8.0 Keymaster 3 перешел от уровня аппаратной абстракции (HAL) C-структуры старого стиля к интерфейсу HAL C ++, созданному из определения в новом языке определения аппаратного интерфейса (HIDL). Как часть изменения, многие типы аргументов изменились, хотя типы и методы имеют непосредственное соответствие со старыми типами и методами структуры HAL. Смотрите страницу Функции для более подробной информации.

В дополнение к этой версии интерфейса, Android 8.0 расширяет функцию аттестации Keymaster 2 для поддержки аттестации идентификаторов . Аттестация идентификатора предоставляет ограниченный и необязательный механизм для строгой проверки идентификаторов оборудования, таких как серийный номер устройства, название продукта и идентификатор телефона (IMEI / MEID). Чтобы реализовать это дополнение, измените схему аттестации ASN.1, чтобы добавить аттестацию идентификатора. Реализации Keymaster должны найти какой-то безопасный способ извлечения соответствующих элементов данных, а также определить механизм для безопасного и окончательного отключения функции.

В Android 9 обновления включают в себя:

  • Обновление до Keymaster 4
  • Поддержка встроенных безопасных элементов
  • Поддержка безопасного импорта ключей
  • Поддержка шифрования 3DES
  • Изменения в привязке версий, так что boot.img и system.img имеют отдельно установленные версии, чтобы разрешить независимые обновления

глоссарий

Вот краткий обзор компонентов Keystore и их взаимосвязей.

AndroidKeystore - это Android Framework API и компонент, используемый приложениями для доступа к функциональности Keystore. Он реализован как расширение стандартных API-интерфейсов архитектуры криптографии Java и состоит из кода Java, который выполняется в собственном пространстве процессов приложения. AndroidKeystore выполняет запросы приложений на поведение хранилища ключей, перенаправляя их демону хранилища ключей.

Демон хранилища ключей - это системный демон Android, который обеспечивает доступ ко всем функциям хранилища ключей через API Binder . Он отвечает за хранение «больших двоичных объектов», которые содержат фактический материал секретного ключа в зашифрованном виде, поэтому Keystore может хранить его, но не использовать и не раскрывать.

keymasterd - это HIDL-сервер, который предоставляет доступ к TA Keymaster. (Это имя не стандартизировано и предназначено для концептуальных целей.)

Keymaster TA (доверенное приложение) - это программное обеспечение, работающее в безопасном контексте, чаще всего в TrustZone на SoC ARM, которое обеспечивает все безопасные операции Keystore, имеет доступ к исходному материалу ключа, проверяет все условия контроля доступа для ключей. , и т.д.

LockSettingsService - системный компонент Android, отвечающий за аутентификацию пользователя, пароль и отпечаток пальца. Он не является частью Keystore, но важен, потому что многие ключевые операции Keystore требуют аутентификации пользователя. LockSettingsService взаимодействует с TA Gatekeeper и Fingerprint TA для получения токенов аутентификации, которые он предоставляет демону хранилища ключей и которые в конечном итоге используются приложением Keymaster TA.

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

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

Архитектура

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

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

Доступ к Keymaster

Рисунок 1. Доступ к Keymaster

Внутри устройства Android «клиент» Keymaster HAL состоит из нескольких слоев (например, приложение, инфраструктура, демон Keystore), но это может быть проигнорировано для целей этого документа. Это означает, что описанный API-интерфейс Keymaster HAL является низкоуровневым, используется внутренними компонентами платформы и не предоставляется разработчикам приложений. API более высокого уровня описан на сайте разработчика Android .

Цель Keymaster HAL не состоит в том, чтобы реализовать алгоритмы, чувствительные к безопасности, а только для маршалирования и демаршалирования запросов в безопасный мир. Формат провода определяется реализацией.

Совместимость с предыдущими версиями

Keymaster 1 HAL полностью несовместим с ранее выпущенными HAL, например, Keymaster 0.2 и 0.3. Для облегчения взаимодействия на устройствах под управлением Android 5.0 и более ранних версий, которые были запущены с более старыми HAL Keymaster, Keystore предоставляет адаптер, который реализует HAL Keymaster 1 с вызовами в существующую аппаратную библиотеку. Результат не может обеспечить полный набор функций в HAL Keymaster 1. В частности, он поддерживает только алгоритмы RSA и ECDSA, и все действия по авторизации ключей выполняются адаптером в небезопасном мире.

Keymaster 2 дополнительно упростил интерфейс HAL, удалив методы get_supported_* и позволив методу finish() принимать ввод. Это уменьшает количество обращений к TEE в тех случаях, когда ввод доступен одновременно, и упрощает реализацию расшифровки AEAD.

В Android 8.0 Keymaster 3 перешел от HAL C-структуры старого стиля к интерфейсу HAL C ++, созданному из определения на новом языке определения аппаратного интерфейса (HIDL). Реализация HAL нового стиля создается путем создания подкласса сгенерированного класса IKeymasterDevice и реализации чисто виртуальных методов. В рамках этого изменения изменились многие типы аргументов, хотя типы и методы имеют непосредственное соответствие со старыми типами и методами структуры HAL.

HIDL обзор

Язык определения аппаратного интерфейса (HIDL) обеспечивает независимый от языка реализации механизм для определения аппаратных интерфейсов. Инструменты HIDL в настоящее время поддерживают генерацию интерфейсов C ++ и Java. Ожидается, что большинство разработчиков Trusted Execution Environment (TEE) найдут инструмент C ++ более удобным, поэтому в этом документе обсуждается только представление C ++.

Интерфейсы HIDL состоят из набора методов, выраженных как:

  methodName( INPUT ARGUMENTS ) generates ( RESULT ARGUMENTS );

Существуют различные предопределенные типы, и HAL могут определять новые перечисляемые и структурные типы. Для получения более подробной информации о HIDL см. Раздел «Справочные материалы» .

Пример метода из Keymaster 3 IKeymasterDevice.hal :

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

Это эквивалентно следующему из keymaster2 HAL:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

В версии HIDL аргумент dev удален, потому что он неявный. Аргумент params больше не является структурой, содержащей указатель, ссылающийся на массив объектов key_parameter_t , а представляет собой vec (вектор), содержащий объекты KeyParameter . Возвращаемые значения перечислены в предложении « generates », включая вектор значений uint8_t для ключевого объекта.

Виртуальный метод C ++, сгенерированный компилятором HIDL:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

Где generate_cb - это указатель на функцию, определенный как:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

То есть, generate_cb - это функция, которая принимает возвращаемые значения, указанные в предложении generate. Класс реализации HAL переопределяет этот метод generateKey и вызывает указатель на функцию generate_cb чтобы вернуть результат операции вызывающей стороне. Обратите внимание, что вызов указателя функции является синхронным . Вызывающая сторона вызывает generateKey а generateKey вызывает указатель предоставленной функции, которая выполняется до конца, возвращая управление реализации generateKey , которая затем возвращается вызывающей стороне.

Для подробного примера смотрите реализацию по умолчанию в hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . Реализация по умолчанию обеспечивает обратную совместимость для устройств со старым ключом keymaster0, keymaster1 или keymaster2 HALS.