Authentication

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

  • Поставщик услуг и хранилища криптографических ключей. Android Keystore предоставляет аппаратно-поддерживаемые криптографические услуги для приложений. Система Android Keystore на уровне фреймворка поддерживается системной службой keystore2 . Это, в свою очередь, основано на базовой реализации поставщика KeyMint (ранее Keymaster), которая гарантирует, что ключевой материал доступен только в аппаратно-поддерживаемой защищенной среде, такой как Trusted Execution Environment (TEE) или Secure Element (SE).
  • Аутентификаторы пользователя. Подтверждают успешную аутентификацию пользователя. Android поддерживает следующие компоненты аутентификации:
    • Контроллер аутентификации по ПИН-коду, шаблону или паролю в TEE.
    • (Опционально) Weaver для аутентификации по PIN-коду, шаблону или паролю в защищенном элементе.
    • Отпечаток пальца для аутентификации отпечатков пальцев.
    • Другие методы биометрической аутентификации. Устройства, которые поставляются с Android 9 или выше, могут использовать BiometricPrompt как единую точку интеграции для отпечатков пальцев и дополнительных биометрических данных.
    Эти компоненты сообщают о своем состоянии аутентификации службе keystore2 с помощью аппаратных токенов аутентификации (AuthTokens) .

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

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

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

Зачисление

При первой загрузке устройства после сброса к заводским настройкам все аутентификаторы готовы принимать регистрации учетных данных от пользователя. Пользователь должен изначально зарегистрировать PIN-код, шаблон или пароль с помощью Gatekeeper (или Weaver, если доступно). Эта первоначальная регистрация создает случайно сгенерированный 64-битный защищенный идентификатор пользователя (SID), который служит идентификатором для пользователя и связывающим токеном для криптографического материала пользователя. Этот SID пользователя криптографически связан с паролем пользователя; успешные аутентификации в Gatekeeper приводят к AuthTokens, которые содержат 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 передается в системную службу keystore2 через интерфейс Binder.
  4. Служба keystore2 прикрепляет AuthTokens к запросу KeyMint (ранее Keymaster) на выполнение криптографических операций. Служба KeyMint HAL передает их в KeyMint TA, который проверяет их с помощью ключа HMAC, общего с Gatekeeper и поддерживаемыми биометрическими компонентами TEE. KeyMint доверяет временной метке в токене как последнему времени аутентификации, решает, разрешить ли использование ключа, на основе временной метки.

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

Authtoken Format

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

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

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

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

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

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

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