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

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

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

Компоненты Gatekeeper, Fingerprint и Biometric работают с Keystore и другими компонентами для поддержки использования аппаратных токенов аутентификации (AuthTokens).

Регистрация

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

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

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

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

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

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

Формат AuthToken

Чтобы обеспечить совместное использование токена и совместимость между языками и компонентами, формат AuthToken описан в hw_auth_token.h . Формат представляет собой простой протокол сериализации с полями фиксированного размера.

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

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

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

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

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