Authentication

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

• Поставщик услуг и хранилища криптографических ключей. Хранит криптографические ключи и предоставляет стандартные криптографические процедуры на их основе. Android поддерживает аппаратное хранилище ключей и KeyMint (ранее Keymaster) для криптографических сервисов, включая аппаратное криптографическое хранилище ключей, которое может включать доверенную среду выполнения (TEE) или защищенный элемент (SE), например, StrongBox.
• Аутентификаторы пользователей. Подтверждают присутствие пользователя и/или успешную аутентификацию. Android поддерживает Gatekeeper для аутентификации по PIN-коду/графическому ключу/паролю и Fingerprint для аутентификации по отпечаткам пальцев. Устройства с Android 9 и более поздними версиями могут использовать BiometricPrompt в качестве единой точки интеграции для отпечатков пальцев и других биометрических данных. Эти компоненты передают данные о состоянии аутентификации в службу хранилища ключей через аутентифицированный канал. ( Система Android Keystore на уровне фреймворка также поддерживается службой хранилища ключей.)

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

Реализации поставщиков обычно также делятся на две части, соединенные механизмом связи, специфичным для поставщика:

• Служба HAL работает как системный процесс Android, получая запросы Binder от системы Android.
• Доверенное приложение (TA) работает в безопасной среде, выполняя реальные безопасные операции.

Зачисление

При первой загрузке устройства после сброса к заводским настройкам все аутентификаторы готовы к получению регистрационных данных от пользователя. Пользователь должен сначала зарегистрировать PIN-код, графический ключ или пароль в Gatekeeper (или Weaver, если доступно). Эта первоначальная регистрация создаёт случайно сгенерированный 64-битный безопасный идентификатор пользователя (SID), который служит идентификатором пользователя и токеном привязки для криптографических данных пользователя. Этот SID пользователя криптографически связан с паролем пользователя; успешная аутентификация в Gatekeeper приводит к созданию токенов AuthToken, содержащих SID пользователя для этого пароля.

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

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

Аутентификация

В этом разделе описывается типичный процесс аутентификации, включающий взаимодействие между несколькими компонентами как в Android, так и в защищённой среде. Обратите внимание, что все защищённые компоненты используют общий секретный ключ HMAC (на каждую загрузку), который они используют для аутентификации сообщений друг друга.

После того как пользователь настроил учетные данные и получил идентификатор безопасности (SID), он может начать аутентификацию, которая начинается с предоставления пользователем PIN-кода, шаблона, пароля, отпечатка пальца или других надежных биометрических данных.

Рисунок 1. Процесс аутентификации

1. Пользователь предоставляет метод аутентификации, и соответствующая служба делает запрос к службе HAL.
   • Для получения PIN-кода, шаблона или пароля LockSettingsService отправляет запрос к gatekeeperd .
   • Процессы биометрической аутентификации зависят от версии Android. На устройствах под управлением Android 8.x и ниже FingerprintService отправляет запрос к fingerprintd . На устройствах под управлением Android 9 и выше BiometricPrompt отправляет запрос к соответствующему демону биометрической аутентификации (например, fingerprintd для отпечатков пальцев или faced для лица), используя соответствующий класс Biometric Manager , такой как FingerprintManager или FaceManager . Независимо от версии, биометрическая аутентификация выполняется асинхронно после отправки запроса.
2. Служба HAL отправляет данные своему партнеру TA, который генерирует AuthToken:
   • Для аутентификации по PIN-коду/шаблону/паролю gatekeeperd отправляет PIN-код, шаблон или хэш пароля в Gatekeeper TA в TEE через службу Gatekeeper HAL. Если аутентификация в TEE прошла успешно, Gatekeeper TA выдаёт AuthToken, содержащий соответствующий SID пользователя (подписанный общим ключом HMAC).
   • Для аутентификации по отпечаткам пальцев fingerprintd отслеживает события отпечатков пальцев и отправляет данные в Fingerprint TA в TEE через Fingerprint HAL. Если аутентификация в TEE прошла успешно, Fingerprint TA выдаёт AuthToken (подписанный ключом AuthToken HMAC).
   • Для других видов биометрической аутентификации соответствующий биометрический демон прослушивает биометрическое событие и отправляет его в соответствующую биометрическую службу HAL и TA.
3. Демон получает подписанный AuthToken и передает его в службу хранилища ключей через расширение интерфейса Binder службы хранилища ключей. ( gatekeeperd также уведомляет службу хранилища ключей о повторной блокировке устройства и изменении пароля устройства.)
4. Служба хранилища ключей передаёт токены аутентификации (AuthTokens) в KeyMint и проверяет их, используя ключ, общий с Gatekeeper и поддерживаемым биометрическим компонентом TEE. KeyMint считает временную метку в токене временем последней аутентификации и принимает решение о выпуске ключа (разрешить приложению использовать ключ) на основе этой временной метки.

Процесс аутентификации не требует прямого взаимодействия между ТА в защищенной среде: токены аутентификации передаются от ТА-аутентификатора к сервису keystore2 в Android, который, в свою очередь, передаёт их сервису KeyMint TA. Это также позволяет сервису keystore2 быстро отклонять запросы, которые заведомо обречены на неудачу, поскольку он знает о доступных токенах аутентификации в системе, что позволяет избежать потенциально дорогостоящего межпроцессного взаимодействия (IPC) в TEE.

Формат AuthToken

Формат AuthToken задан спецификацией AIDL в HardwareAuthToken.aidl .

Процесс загрузки устройства

При каждой загрузке устройства ключ HMAC AuthToken должен быть сгенерирован и передан всем компонентам TEE (Gatekeeper, KeyMint и поддерживаемым биометрическим трастлетам). Таким образом, для дополнительной защиты от атак повторного воспроизведения ключ HMAC должен генерироваться случайным образом при каждой перезагрузке устройства.

Существует два распространенных способа, с помощью которых ТА получают доступ к этому общему ключу HMAC:

• Соглашение о совместном секрете: служба keystore2 реализует протокол многостороннего согласования ключей при запуске устройства, обеспечивая безопасное формирование ключа HMAC между участвующими TA. Однако участвующие TA должны иметь доступ к общему предварительно заданному секрету.
• Прямой доступ: ТА, находящиеся в одной и той же защищенной среде, могут использовать внутренний механизм межпроцессного взаимодействия (зависящий от платформы) для совместного использования ключа HMAC.

В любом случае ключ HMAC ни в коем случае не должен быть доступен за пределами TEE.

Операционная система Trusty , работающая параллельно с Android, является примером TEE, но вместо неё можно использовать и другие TEE. Trusty использует внутреннюю систему IPC для прямого взаимодействия между KeyMint и Gatekeeper или соответствующим биометрическим трастлетом. Ключ HMAC хранится исключительно в KeyMint; Fingerprint и Gatekeeper запрашивают ключ у KeyMint для каждого использования, не сохраняя и не кэшируя его значение.

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