Authentication

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

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

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

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

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

Регистрация

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

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

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

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

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

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

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

  1. Пользователь предоставляет способ аутентификации, а связанный сервис отправляет запрос в HAL.
    • Если вы используете PIN-код, графический ключ или пароль, LockSettingsService отправляет запрос в gatekeeperd.
    • Процесс биометрической аутентификации зависит от версии Android. На устройствах с Android 8.x и более ранними версиями FingerprintService отправляет запрос в fingerprintd. На устройствах с Android 9 и более поздними версиями BiometricPrompt отправляет запрос в соответствующий демон биометрии (например, fingerprintd для отпечатков пальцев или faced для лица), используя подходящий класс BiometricManager, например FingerprintManager или FaceManager. Независимо от версии, биометрическая аутентификация выполняется асинхронно после отправки запроса.
  2. Сервис HAL отправляет данные в соответствующее доверенное приложение, которое генерирует 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, подписанный ключом HMAC токена AuthToken.
    • Для других видов биометрической аутентификации соответствующий демон прослушивает биометрическое событие и отправляет его в соответствующий сервис HAL и доверенное приложение.
  3. Полученный подписанный токен AuthToken передается в системный сервис keystore2 через интерфейс Binder.
  4. Сервис keystore2 прикрепляет токены AuthToken к запросу, чтобы KeyMint (ранее Keymaster) мог выполнять криптографические операции. Сервис KeyMint HAL передает их в KeyMint TA, который проверяет их с помощью ключа HMAC, используемого совместно с Gatekeeper и поддерживаемыми биометрическими компонентами TEE. KeyMint доверяет временной метке в токене как времени последней аутентификации и решает, разрешить ли использование ключа, на основе этой метки.

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

Формат AuthToken

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

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

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

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

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

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

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

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