Google 致力于为黑人社区推动种族平等。查看具体举措
Эта страница переведена с помощью Cloud Translation API.
Switch to English

Хранилище ключей с аппаратной поддержкой

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

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

В 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 для поддержки аттестации ID . Аттестация идентификатора предоставляет ограниченный и дополнительный механизм для строгой проверки идентификаторов оборудования, таких как серийный номер устройства, название продукта и идентификатор телефона (IMEI / MEID). Чтобы реализовать это дополнение, измените схему аттестации ASN.1, добавив аттестацию идентификатора. Реализации Keymaster должны найти какой-то безопасный способ извлечения соответствующих элементов данных, а также определить механизм для безопасного и постоянного отключения функции.

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

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

Глоссарий

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

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

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

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

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

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

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

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

Архитектура

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

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

Доступ к Keymaster

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

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

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

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

Keymaster 1 HAL полностью несовместим с ранее выпущенными HAL, например, Keymaster 0.2 и 0.3. Для облегчения взаимодействия на устройствах под управлением Android 5.0 и более ранних версий, запущенных со старыми HAL Keymaster, Keystore предоставляет адаптер, который реализует HAL Keymaster 1 с вызовами существующей аппаратной библиотеки. Результат не может обеспечить полный набор функций Keymaster 1 HAL. В частности, он поддерживает только алгоритмы 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);

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

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 для ключевого 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 . Реализация по умолчанию обеспечивает обратную совместимость для устройств с HALS старого стиля keymaster0, keymaster1 или keymaster2.