Аппаратное хранилище ключей

Наличие доверенной среды выполнения (TEE) в системе на кристалле (SoC) открывает для устройств Android возможность предоставлять аппаратно-поддерживаемые надежные службы безопасности для операционной системы Android, служб платформы и даже сторонних приложений (в виде специфичных для Android расширений стандартной архитектуры криптографии Java, см. KeyGenParameterSpec ).

Глоссарий

Здесь представлен краткий обзор компонентов хранилища ключей и их взаимосвязей.

AndroidKeyStore
AndroidKeyStore обрабатывает запросы приложения к функциям хранилища ключей, перенаправляя их демону хранилища ключей.
демон хранилища ключей
Системный демон Android, предоставляющий доступ ко всей функциональности Keystore через API Binder . Этот демон отвечает за хранение keyblobs, созданных базовой реализацией KeyMint (или Keymaster), которые содержат секретный ключевой материал, зашифрованный таким образом, чтобы Keystore мог их хранить, но не мог использовать или раскрывать.
Сервис KeyMint HAL
Сервер AIDL, реализующий HAL IKeyMintDevice и обеспечивающий доступ к базовому TA KeyMint.
Приложение KeyMint, которому доверяют (TA)
Программное обеспечение, работающее в защищенной среде, чаще всего в TrustZone на ARM SoC, обеспечивает все безопасные криптографические операции. Это приложение имеет доступ к исходным ключевым данным и проверяет все условия контроля доступа к ключам, прежде чем разрешить их использование.
LockSettingsService
Компонент системы Android, отвечающий за аутентификацию пользователя, как по паролю, так и по отпечатку пальца. Он не является частью Keystore, но важен, поскольку Keystore поддерживает концепцию ключей, привязанных к аутентификации : ключей, которые можно использовать только после аутентификации пользователя. LockSettingsService взаимодействует с Gatekeeper TA и Fingerprint TA для получения токенов аутентификации, которые он предоставляет демону Keystore, а те, в свою очередь, используются KeyMint TA.
Привратник ТА
Компонент, работающий в защищенной среде и отвечающий за аутентификацию паролей пользователей и генерацию токенов аутентификации, используется для подтверждения техническому специалисту KeyMint факта проведения аутентификации для конкретного пользователя в определенный момент времени.
Дайверская ассистентка по отпечаткам пальцев
Компонент, работающий в защищенной среде и отвечающий за аутентификацию отпечатков пальцев пользователей и генерацию токенов аутентификации, используется для подтверждения техническому специалисту KeyMint факта проведения аутентификации для конкретного пользователя в определенный момент времени.

Архитектура

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

KeyMint HAL — это предоставляемый производителем сервис, используемый службой Keystore для обеспечения аппаратной поддержки криптографических услуг. Для обеспечения безопасности данных закрытого ключа реализации HAL не выполняют никаких конфиденциальных операций в пользовательском пространстве или даже в пространстве ядра. Вместо этого служба KeyMint HAL, работающая в Android, делегирует конфиденциальные операции TA, работающему в защищенной среде, как правило, путем сериализации и десериализации запросов в определенном формате передачи данных, заданном реализацией.

В результате получилась следующая архитектура:

Доступ к KeyMint

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

API KeyMint HAL — это низкоуровневый API, используемый внутренними компонентами платформы и не доступный разработчикам приложений. Более высокоуровневый Java API, доступный приложениям, описан на сайте разработчиков Android .

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

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

Домены хранилища ключей

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

Приложения Android получают доступ к Keystore, используя стандартную архитектуру криптографии Java, которая идентифицирует ключи с помощью строкового псевдонима. Этот метод идентификации внутренне сопоставляется с доменом APP Keystore; UID вызывающего приложения также включается для различения ключей разных приложений, предотвращая доступ одного приложения к ключам другого.

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

Однако приложение может предоставить доступ к ключу другому приложению (идентифицируемому по UID). Эта операция предоставления доступа возвращает уникальный идентификатор, который используется в качестве идентификатора для дескрипторов ключей в домене GRANT . При этом контроль доступа по-прежнему осуществляется: даже если третье приложение обнаружит идентификатор ключа получателя, оно не сможет его использовать.

Keystore также поддерживает два других домена для дескрипторов ключей, которые используются для других системных компонентов и недоступны для ключей, созданных приложением:

  • Домен BLOB указывает на отсутствие идентификатора ключа в дескрипторе ключа; вместо этого дескриптор ключа содержит сам keyblob, а клиент управляет хранением keyblob. Это используется клиентами (например, vold ), которым необходимо получить доступ к Keystore до монтирования раздела данных.
  • Домен SELINUX позволяет системным компонентам совместно использовать ключи, при этом доступ регулируется числовым идентификатором, соответствующим метке SELinux (см. политику SELinux для keystore_key ).

Политика SELinux для keystore_key

Значения идентификаторов, используемые для дескрипторов ключей Domain::SELINUX настраиваются в файле политики SELinux keystore2_key_context . Каждая строка в этих файлах сопоставляет числовое значение с меткой SELinux, например:

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share Keystore keys.
102            u:object_r:wifi_key:s0

Компоненту, которому необходим доступ к ключу с ID 102 в домене SELINUX , должна быть назначена соответствующая политика SELinux. Например, чтобы разрешить wpa_supplicant получать и использовать эти ключи, добавьте следующую строку в hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Числовые идентификаторы ключей Domain::SELINUX разделены на диапазоны для поддержки различных разделов без конфликтов:

Раздел Диапазон Файлы конфигурации
Система 0 ... 9,999 /system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
Расширенная система 10 000 ... 19 999 /system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
Продукт 20 000 ... 29 999 /product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
Продавец 30 000 ... 39 999 /vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

Для системного раздела заданы следующие конкретные значения:

Идентификатор пространства имен этикетка SEPolicy UID Описание
0 su_key Н/Д Ключ суперпользователя. Используется только для тестирования в отладочных и инженерных сборках. Неактуален для пользовательских сборок.
1 shell_key Н/Д Пространство имен доступно для оболочки. В основном используется для тестирования, но может использоваться и в пользовательских сборках из командной строки.
100 vold_key Н/Д Предназначено для использования компанией Vold.
101 odsign_key Н/Д Используется демоном подписи, установленным на устройстве.
102 wifi_key AID_WIFI(1010) Используется подсистемой Wi-Fi Android, включая wpa_supplicant .
103 locksettings_key Н/Д Используется службой LockSettingsService
120 resume_on_reboot_key AID_SYSTEM(1000) Используется системным сервером Android для поддержки возобновления работы после перезагрузки.

Векторы доступа

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

Системные разрешения

В дополнение к настройкам доступа для каждого ключа, описанным в политике SELinux для keystore_key , в следующей таблице описаны другие разрешения SELinux, необходимые для выполнения различных системных операций и операций обслуживания:

Разрешение Значение
add_auth Необходим для добавления токенов аутентификации в хранилище ключей; используется поставщиками аутентификации, такими как Gatekeeper или BiometricManager .
clear_ns Необходим для удаления всех ключей в определенном пространстве имен; используется в качестве операции обслуживания при удалении приложений.
list Этот параметр необходим системе для перечисления ключей по различным свойствам, таким как право собственности или принадлежность к системе аутентификации. Разрешение не требуется для вызывающих функций, перечисляющих собственные пространства имен (это регулируется разрешением get_info ).
lock Необходимо для уведомления хранилища ключей о том, что устройство заблокировано, что, в свою очередь, приводит к удалению суперключей, гарантируя недоступность ключей, привязанных к аутентификации.
unlock Необходимо уведомить хранилище ключей о разблокировке устройства, восстановив доступ к суперключам, защищающим ключи, привязанные к аутентификации.
reset Необходимо для сброса хранилища ключей до заводских настроек, удаления всех ключей, не являющихся критически важными для работы операционной системы Android.

История

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

Android 6.0

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

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

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

Android 7.0

В Android 7.0 Keymaster 2 добавил поддержку аттестации ключей и привязки версий.

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

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

Android 8.0

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

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

Android 9

В Android 9 были внесены следующие обновления:

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

Android 10

В Android 10 была представлена ​​версия 4.1 Keymaster HAL, в которую были добавлены следующие функции:

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

Android 12

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

  • Поддержка ключевого соглашения ECDH
  • Поддержка пользовательских ключей аттестации.
  • Поддержка клавиш с ограниченным количеством применений.

В Android 12 также включена новая версия системного демона хранилища ключей, переписанная на Rust и известная как keystore2

Android 13

В Android 13 добавлена ​​версия 2 HAL KeyMint, которая обеспечивает поддержку Curve25519 как для подписи, так и для согласования ключей.