Authentication

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

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

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

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

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

Зачисление

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

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

формат AuthToken

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

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

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

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

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

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

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

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